US20230237490A1 - Authentication transaction - Google Patents
Authentication transaction Download PDFInfo
- Publication number
- US20230237490A1 US20230237490A1 US18/295,989 US202318295989A US2023237490A1 US 20230237490 A1 US20230237490 A1 US 20230237490A1 US 202318295989 A US202318295989 A US 202318295989A US 2023237490 A1 US2023237490 A1 US 2023237490A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- computing device
- user
- financial institution
- request message
- 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.)
- Pending
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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
-
- 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
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- 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/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
- G06Q20/1085—Remote banking, e.g. home banking involving automatic teller machines [ATMs]
-
- 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/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/206—Point-of-sale [POS] network systems comprising security or operator identification provisions, e.g. password entry
-
- 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]
- G06Q20/3221—Access to banking information through 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/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]
- G06Q20/3223—Realising banking transactions through 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/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/326—Payment applications installed on the mobile devices
- G06Q20/3267—In-app payments
-
- 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- 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
- G06Q20/401—Transaction verification
Definitions
- Embodiments described herein generally relate to authentication, for example and without limitation, authentication including initiating a transaction to a user account for authentication.
- Authentication methods are used by parties to an electronic transaction to verify the identity of a counter party.
- FIG. 1 is a diagram showing an example of an environment for authentication utilizing a transaction to a financial account of a user.
- FIG. 2 is a diagram showing another example of the environment of FIG. 1 with additional components.
- FIG. 3 is a block diagram showing an example architecture of a mobile computing device.
- FIG. 4 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user.
- FIG. 5 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user involving a user mobile computing device and a second user computing device.
- FIG. 6 is a timing diagram showing one example of an authentication used in the context of a payment from the user to a merchant.
- FIG. 7 is a timing diagram showing one example of an authentication used between a user and an automated teller machine (ATM).
- ATM automated teller machine
- FIG. 8 is a flowchart showing one example of a process flow that may be executed by a financial institution system, point of service (POS) device, automated teller machine ATM or other counterparty to a user service request to determine whether to request an authentication transaction.
- POS point of service
- FIG. 9 is a flowchart showing one example of a process flow an authentication utilizing one or more block chains.
- FIG. 10 is a block diagram showing one example of a software architecture for a computing device.
- FIG. 11 is a block diagram illustrating a computing device hardware architecture, within which a set or sequence of instructions can be executed to cause the machine to perform examples of any one of the methodologies discussed herein.
- Various examples described herein are directed to authentication that includes a transaction to a user’s financial account.
- the user may request access to a financial service provided by a financial institution through a financial institution system.
- the user may make the request from a financial services application executing at a computing device, such as a mobile computing device.
- a financial services application executing at a computing device, such as a mobile computing device.
- the user may be a customer of the financial institution.
- the financial service may be any suitable financial service offered by the financial institution including, for example, an account management service, an online bill pay service, a loan application service, etc.
- both the user and the financial institution system may verify the identity of the other at least in part through a transaction to a financial account of the user, such as a financial account held at the financial institution.
- a financial account of the user such as a financial account held at the financial institution.
- the financial institution system may send a transaction request to a second server system requesting a transaction to the account of the user.
- the transaction may be a credit or debit to the account, such as of a small amount, such as a few cents.
- the transaction may include both a credit and an equivalent debit to the user’s account.
- the second server system may be a wallet management system programmed to manage one or more financial accounts of the user.
- the transaction request may include transaction description data including a transaction amount and an identity of the financial account.
- the second server system may prompt the user to authorize the requested transaction.
- the second server system may send a transaction request message to a mobile wallet application executing at the mobile computing device of the user.
- the user may receive the transaction request message and reply to the second server system with a transaction authorization message, for example, via the mobile wallet application.
- the transaction authorization message may include identifying data from the user, such as, for example, user name data including a user name, password data including a password, personal identification number (PIN) data including a PIN, biometric data captured from the user, etc.
- PIN personal identification number
- the second server system may verify the identifying data and continue and/or complete the transaction.
- the second server system may send the financial institution system a transaction confirmation message indicating that the user has authorized the transactions.
- the financial institution system may send the user a
- both the user and the financial institution may utilize the transaction process to verify the identity of the other.
- the user may be unlikely to authorize the transaction if it is unexpected. Accordingly, the party that authorizes the transaction is likely to be the same party that made the initial access request to the financial institution system.
- the user may verify its identity to the second server system with the identifying data provided with the transaction authorization. The user, on the other hand, may receive data regarding the transaction from both from the second server system and from the financial institution system.
- some examples may utilize transactions to a user financial account to authenticate users and service provider systems in other contexts.
- the user may request access to a service provided by a first server system.
- the first server system may send to the second server system a transaction request requesting the transaction to the financial account of the user.
- the second server system may prompt a mobile computing device of the user to authorize the transaction and send a transaction confirmation message to the financial institution system.
- the financial institution system may send a transaction summary message to the user.
- FIG. 1 is a diagram showing an example of an environment 10 for authentication utilizing a transaction to a financial account of a user 3 .
- the user 3 utilizes a mobile computing device 2 .
- Other components in the environment 10 may include a financial institution system 6 and a wallet management system 4 .
- the mobile computing device 2 may be or include any computing device suitable for executing authentication of a user 3 as described herein.
- Example mobile computing devices 2 may include smart phones, tablet computers, laptop computers, smart watches, etc.
- the mobile computing device 2 executes a financial services application 20 and a mobile wallet application 22 .
- the financial services application 20 may be a client-side and/or web application suitable for accessing one or more financial services of a financial institution.
- the financial services application 20 may be in communication with the financial institution system 6 , as described herein.
- the user 3 in some examples, is a customer of the financial institution and may hold one or more financial accounts at the financial institution system.
- the mobile wallet application 22 may be a client-side and/or web application suitable for managing payments to or from one or more financial accounts of the user 3 .
- the mobile wallet application 22 may implement a mobile wallet service for the user 3 , for example, in conjunction with the wallet management system 4 .
- the mobile wallet application 22 may enable the user 3 to make payments to and/or from various financial accounts, such as, for example, credit card accounts, debit accounts, line-of-credit accounts, checking accounts, savings accounts, etc.
- Examples of mobile wallet services that may be used for authentication as described herein include APPLE PAY, GOOGLE WALLET, SOFTCARD, etc.
- One or more accounts managed by the mobile wallet service may be held by the user 3 with the financial institution system 6 .
- the financial institution system 6 may be any suitable computing system for providing users, such as the user 3 , with one or more financial services, such as an account management service, an online bill pay service, a loan application service, etc.
- the financial institution system 6 may be configured to communicate with the mobile computing device 2 and with the financial services application 20 described herein.
- the financial institution system 6 may be configured to communicate with another computing device of the user 3 in addition to or instead of the mobile computing device 2 .
- the financial institution system 6 may comprise one or more computing devices, such as servers, configured to operate as described herein. Computing devices making up the financial institution system 6 may be located at a single geographic location and/or may be distributed across multiple geographic locations.
- the financial institution system 6 may be implemented in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations of the financial institution system 6 may be performed by a group of computing devices, with these operations being accessible via a network and/or via one or more appropriate interfaces (e.g., an Application Program Interface (API)).
- SaaS software as a service
- API Application Program Interface
- the wallet management system 4 may be any suitable computing system for providing users, such as the user 3 with a mobile wallet service.
- the wallet management system 4 may be configured to communicate with the mobile computing device 2 and with the mobile wallet application 22 described herein.
- the wallet management system 4 may comprise one or more computing devices, such as servers, configured to operate as described herein. Computing devices making up the wallet management system 4 may be located at a single geographic location and/or may be distributed across multiple geographic locations.
- the wallet management system 4 may be implemented in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations of the wallet management system 4 may be performed by a group of computing devices, with these operations being accessible via a network and/or via one or more appropriate interfaces (e.g., an Application Program Interface (API)).
- API Application Program Interface
- FIG. 1 also shows an example workflow for authentication in the environment 10 .
- the mobile computing device 2 e.g., the financial services application 20
- the access request message 8 may comprise a request to access one or more financial services offered by the financial institution system 6 .
- the access request message 8 is sent at the beginning of a communication session between the financial services application 20 and the financial institution system 6 , for example, as part of a sign-in process.
- the access request message 8 may be sent when the mobile computing device 2 requests access to a particular financial service offered by the financial institution system 6 (e.g., after an initial sign-in).
- the financial institution system 6 may direct a transaction request message 11 to the wallet management system 4 .
- the transaction request message 11 may request that the wallet management system 4 initiate a transaction to a financial account of the user 3 .
- the transaction request message 11 may include transaction data describing the user 3 such as, for example, a name of the user 3 , an account number of a financial account held by the user, etc.
- the transaction request message 11 may also include financial institution system data describing the financial institution system 6 .
- the transaction request message 11 may include a requested transaction amount or in some examples, the transaction request message 11 may request a transaction without specifying the transaction amount. For example, the wallet management system 4 may select the amount of the transaction.
- the wallet management system 4 may have or request authentication of the financial institution system 6 .
- the financial institution system 6 may provide a digital certificate indicating its identity (e.g., its association with an implementing financial institution). Any other form of digital authentication may be used.
- the financial institution authenticates itself to the wallet management system 4 , it may do so at or about the time that the transaction request message 11 is sent or, in some examples, may do so prior to the sending of the transaction request message 11 .
- the wallet management system 4 upon receiving the transaction request message 11 , may send a transaction authorization request message 12 to the mobile wallet application 22 executing at the mobile computing device 2 .
- the transaction authorization request message 12 may comprise data instructing the mobile wallet application 22 to prompt the user 3 to authorize the transaction.
- the mobile device e.g., the mobile wallet application 22
- the transaction authorization request message may also include data describing the transaction including, for example, a transaction amount, a counterparty to the transaction, etc.
- the transaction authorization request message 12 may cause the mobile wallet application 22 to display the following message at the mobile computing device 2 : Financial Institution X would like to apply a credit of $0.07 to your account Y. Do you authorize this transaction?
- the transaction may include multiple credits and/or debits to the user’s financial account, for example, credits and debits that offset and/or sum to zero.
- Financial Institution X would like to apply a credit of $0.07 and a debit of $0.07 to your account Y. Do you authorize this transaction?
- the transaction authorization request may also include data describing the nature of the access request message 8 .
- Financial Institution X would like to apply a credit of $0.07 cents to your account Y as part of your request to access a financial service at Financial Institution X. Do you authorize this transaction?
- the message may specify the financial service that was requested. Although a transaction amount of $0.07 is listed in these examples, any suitable transaction amount may be used including, in some examples, transaction amounts that are fractions of a cent.
- the user 3 may authorize the requested transaction, for example, if the user 3 expects the transaction request and/or recognizes the source. For example, if the access request message 8 is sent by an imposter, and not by the user 3 , then the user 3 may not authorize the transaction. Also, for example, if the user 3 does not recognize the requesting party (e.g., the financial institution or Financial Institution system 6 ), then the user may not authorize the transaction.
- the requesting party e.g., the financial institution or Financial Institution system 6
- the user 3 may provide authorization in any suitable manner.
- authorization may be performed through the mobile wallet application 22 .
- the mobile wallet application 22 may prompt the user 3 to provide identifying data.
- the identifying data may include, for example, a user name, a password, a personal identification number (PIN).
- the mobile wallet application 22 may prompt the user 3 to provide biometric data.
- Biometric data may include any data describing the user’s person.
- the mobile computing device 2 may include a touch sensor suitable for capturing a fingerprint of the user.
- the biometric data may include a representation of the user’s fingerprint.
- the mobile computing device 2 may include a camera suitable for capturing an image of the user 3 (e.g., the user’s face).
- the biometric data may include an image of the user (e.g., the user’s face).
- the mobile computing device 2 may include an optical scanner suitable to capture a retinal scan of the user’s eye.
- the biometric data may include data describing the retinal scan.
- the mobile wallet application 22 may send a transaction authorization message 14 to the wallet management system 4 .
- the transaction authorization message 14 may include authorization data indicating the user’s authorization of the transaction.
- the transaction authorization message 14 may also include the identity data and/or biometric data received from the user 3 .
- the wallet management system 4 may receive the transaction authorization message 14 .
- the wallet management system 4 may determine whether the identity data and/or biometric data matches reference identity data and/or reference biometric data for the user 3 stored at and/or otherwise accessible to the wallet management system 4 .
- reference identity data including a password may be referred to as reference password data. If the identity and/or biometric data contained in the transaction authorization message 14 matches the reference user identity data for the user 3 , the wallet management system 4 may complete the transaction.
- the wallet management system 4 may complete the transaction in any suitable manner.
- the wallet management system 4 may communicate with a system associated with an organization that holds the financial account on behalf of the user 3 .
- the wallet management system 4 may communicate with a system implemented by the credit card company associated with the credit card account.
- the wallet management system 4 may communicate with a system implemented by the retail bank.
- the wallet management system 4 may also send a transaction confirmation message 16 to the financial institution system 6 .
- the transaction confirmation message 16 may include data indicating that the user 3 has authorized the transaction.
- the transaction confirmation message 16 may also include data describing the transaction such as, for example, the transaction amount, timestamp data indicating a time of one or more processing steps for executing the transaction (e.g., transaction completion, request, etc.).
- the financial institution system 6 may receive the transaction confirmation message 16 and may generate a transaction summary message 18 and send it to the mobile computing device 2 (e.g., the financial services application 20 ).
- the transaction confirmation message 16 may include some or all of the data describing the transaction.
- the transaction summary message 18 may include transaction summary data summarizing the transaction to the mobile device 2 .
- the financial institution system 6 may also approve the access request message 8 .
- FIG. 2 is a diagram showing another example of the environment 10 of FIG. 1 with additional components.
- FIG. 2 shows user computing devices 2 A, 2 B, 36 , as well as an example point-of-sale (POS) device 30 and an example automated teller machine (ATM) 32 .
- User computing devices may include example mobile computing devices 2 A, 2 B and an additional computing device 36 .
- Mobile computing devices 2 A, 2 B may be used by the user 3 to authorize an authentication transaction, as described herein.
- Mobile computing devices 2 A, 2 B may include any suitable type of computing device or devices.
- mobile computing device 2 A may be a mobile phone.
- Mobile computing device 2 B may be a tablet computer. Any other suitable type of mobile computing device may be used.
- mobile computing devices, such as 2 A, 2 B may be configured to communicate in a wireless manner.
- FIG. 2 also shows the POS device 30 and ATM 32 . These devices, in some examples, may be part of authentication as described herein.
- the POS device 30 may be a device associated with any party that receives payments, such as an online or bricks-and-mortar merchant.
- the POS device 30 may comprise a processing unit and various other computing components.
- the POS device 30 may be or comprise a computing device configured, for example, according to one or more of the hardware or software architectures described herein.
- the POS device 30 may be configured to communicate with a mobile computing device 2 A, 2 B (e.g., a mobile wallet application 22 executing at the mobile computing device 2 A, 2 B) using any suitable contact or a contactless medium.
- a mobile computing device 2 A, 2 B e.g., a mobile wallet application 22 executing at the mobile computing device 2 A, 2 B
- the POS device 30 may be configured to communicate with a mobile computing device 2 A, 2 B utilizing a short range communication medium such as, a Bluetooth connection, a Bluetooth LE connection, a Near Field Communications (NFC) connection, an infrared connection, etc.
- a short range communication medium such as, a Bluetooth connection, a Bluetooth LE connection, a Near Field Communications (NFC) connection, an infrared connection, etc.
- the POS device 30 may request an authentication transaction, for example, when the user 3 requests that a payment be made to a retailer associated with the POS device 30 .
- the payment may be the service accessed by the user 3 .
- the ATM 32 may be implemented by a financial institution and/or a third party administrator to provide the user 3 with financial services, such as, for example, cash withdrawals, balance checks, etc.
- the ATM 32 may comprise a processing unit and various other computing components.
- the ATM 32 may be or comprise a computing device configured, for example, according to one or more of the hardware or software architectures described herein.
- the ATM 32 may request an authentication transaction, for example, when the user request a financial service from the ATM 32 .
- FIG. 2 shows a single example of various components, in some examples, additional instances of users 3 , mobile computing devices 2 A, 2 B, computing devices 36 , wallet management systems 4 , financial institution systems 6 , ATMs 32 and/or POS devices 30 may be included in additional to or instead of those shown.
- FIG. 2 also shows an optional block miner system 5 .
- the block miner system 5 may be present in some examples where block chains of transaction authentications are utilized to identify the user 3 and/or a counterparty, such as the financial institution system 6 , the POS device 30 , the ATM 32 , etc. Although one block miner system 5 is shown, additional block miner systems 5 may be included. Block miner systems 5 may be implemented by any suitable party. Additional examples describing the use of block chains of transaction authentications are described herein, for example, with respect to FIG. 9 .
- the various components 2 A, 2 B, 5 , 6 , 30 , 32 , 36 , etc. of the environment 10 may be in communication with one another via a network 120 .
- the network 120 may be or comprise any suitable network element operated according to any suitable network protocol.
- one or more portions of network 120 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a Wi-Fi network, a WiMax network, another type of network, or a combination of two or more such networks.
- VPN virtual private network
- LAN local area network
- WLAN wireless LAN
- WAN wide area network
- WWAN wireless WAN
- MAN metropolitan area network
- PSTN Public Switched
- FIG. 3 is a block diagram showing an example architecture 300 of a mobile computing device. Any of the mobile computing devices 2 , 2 A, 2 B, for example, may be implemented according to the architecture 300 .
- the architecture 300 comprises a processor unit 310 .
- the processor unit 310 may include one or more processors. Any of a variety of different types of commercially available processors suitable for mobile computing devices may be used (for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor).
- a memory 320 such as a Random Access Memory (RAM), a Flash memory, or other type of memory or data storage, is typically accessible to the processor.
- the memory 320 may be adapted to store an operating system (OS) 330 , as well as application programs 340 .
- OS operating system
- application programs 340 application programs
- the processor unit 310 may be coupled, either directly or via appropriate intermediary hardware, to a display 350 and to one or more input/output (I/O) devices 360 , such as a keypad, a touch panel sensor, a microphone, and the like.
- I/O devices 360 may include one or more devices for receiving biometric data from a user (e.g., the user 3 ).
- Such I/O devices 360 may include a touch sensor for capturing fingerprint data, a camera for capturing one or more images of the user, a retinal scanner, or any other suitable devices.
- the processor 310 may be coupled to a transceiver 370 that interfaces with an antenna 390 .
- the transceiver 370 may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna 390 , depending on the nature of the mobile computing device implemented by the architecture 300 . Although one transceiver 370 is shown, in some examples, the architecture 300 includes additional transceivers. For example, a wireless transceiver may be utilized to communicate according to an IEEE 802.11 specification, such as Wi-Fi and/or to a short range communication medium. Some short range communication mediums, such as NFC, may utilize a separate, dedicated transceiver. Further, in some configurations, a GPS receiver 380 may also make use of the antenna 390 to receive GPS signals.
- FIG. 4 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user.
- the authentication illustrated by the workflow of FIG. 1 may be implemented according to the timing shown in FIG. 4 .
- the timing diagram shows three parties, a financial institution system 106 , a wallet management system 104 and a mobile computing device 102 .
- the mobile computing device 102 may send to the financial institution system 106 an access request message 118 .
- the access request message 118 may initiate the authentication. In some examples, however, the financial institution system 106 may initiate the authentication by soliciting the access request 108 with an access solicitation message.
- the financial institution system 106 may send to the wallet management system 104 a transaction request message 110 .
- the wallet management system may send the mobile computing device 102 (e.g., a mobile wallet application executing at the mobile computing device) a transaction authorization request 112 .
- the mobile computing device 102 may provide a transaction authorization message 114 .
- the transaction authorization message 114 may include identifying information and/or biometric information as described.
- the wallet management system 104 may send a transaction confirmation message 116 to the financial institution system indicating that the user has confirmed the transaction.
- the financial institution system 106 may send a transaction summary message 118 to the mobile computing device 102 .
- the timing shown by the timing diagram may be modified from what is shown in FIG. 4 .
- the financial institution system 106 may send the transaction summary message 118 before receiving the transaction confirmation message 116 .
- FIG. 5 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user involving a user mobile computing device 102 and a second user computing device 136 .
- the second user computing device 136 may be or include, for example, a desktop computer, a laptop computer, etc.
- the second user computing device 136 may execute a financial services application for accessing financial services executed by the financial institution system 106 .
- the user may utilize the second user computing device 136 to send an access request message 151 to the financial institution system.
- the access request message 151 may include a request to access one or more financial services offered by the financial institution system 106 .
- the financial institution system 106 may send a transaction request message 152 to the wallet management system 104 .
- the transaction request message 152 may include data requesting that the wallet management system 104 initiate a transaction to a financial account of the user.
- the wallet management system 104 may send a transaction request authorization request message 154 to the mobile computing device 102 of the user.
- the mobile computing device 102 and/or a mobile wallet application executing at the mobile computing device may be associated with the selected user and/or financial account at the wallet management system 104 .
- the mobile computing device 102 may respond to the transaction authorization request message 154 by sending to the wallet management system 104 a transaction authorization message 156 , which may include user identity and/or biometric data, as described herein.
- the wallet management system 104 may send to the financial institution system 106 a transaction confirmation message 158 indicating that the transaction has been authorized by the user.
- the financial institution system 106 may send a transaction summary message 160 to the second user computing device 136 .
- Various modifications to the timing of the messages of the timing diagram may also be made, for example, as described herein.
- FIG. 6 is a timing diagram showing one example of an authentication used in the context of a payment from the user to a merchant.
- the merchant may receive an indication that that the proffered payment is legitimate (e.g., actually proffered by the user who is the owner of the account used for the payment).
- the user may receive an indication that the recipient of the payment is actually the merchant and not a third party (e.g., a third party engaged in a phishing operation to obtain the user’s account credentials).
- the merchant or other recipient of a payment from the user is represented as POS device 130 .
- all or part of the functionality ascribed to the POS device 130 may be executed by other components associated with the payee such as, for example, a payment server (not shown).
- the mobile computing device 102 may send to the POS device 130 a payment request message 202 .
- the payment request message 202 may include data describing a payment to be made to a payee, such as a merchant.
- the data may include, for example, an amount of the payment, a financial account of the user from which the payment is to be made, etc.
- the user and the payee may engage in a transaction where the payee provides goods and/or services to the user and the user is to provide the payment in return.
- the payment request message 202 may be send by a mobile wallet application executing at the mobile computing device 102 .
- the mobile computing device may communicate with the POS device 130 in any suitable manner including, for example, via a short range communication medium.
- the POS device 130 may send to the financial institution system 106 a authentication request message 204 .
- the financial institution system 106 may administer the financial account of the user from which the payment is to be made.
- the authentication request message 204 may request that the financial institution system 106 initiate an authentication.
- the financial institution system 106 may send a transaction request message 206 to the wallet management system 104 .
- the transaction request message 206 may request that the wallet management system 104 initiate a transaction, as described herein.
- the wallet management system 104 may send a transaction authorization request message 208 to the mobile computing device 102 (e.g., a mobile wallet application executing at the mobile computing device 102 ).
- the mobile computing device 102 may provide a transaction authorization message 210 .
- the transaction authorization message 210 may include user identity data and/or biometric data as described herein.
- the wallet management system 104 may also send to the financial institution system a transaction summary message 212 including data describing the transaction, as described herein.
- the financial institution system may send a second transaction summary message 214 to the mobile computing device, which may serve to authenticate the POS device 130 to the mobile computing device 102 .
- the transaction summary message 214 may include data describing the transaction, as described herein, including, for example, a transaction amount, a transaction timestamp, etc.
- the financial institution system 106 may send a transaction success message 216 to the POS device 130 .
- the transaction success message 216 may indicate to the POS device 130 that the transaction has been successfully completed, which may serve as an authentication of the mobile computing device 102 to the POS device 130 .
- the financial institution system 106 may be omitted.
- the POS device 130 may send the authentication request message 204 directly to the wallet management system 104 .
- the wallet management system 104 may send a transaction summary message to the mobile computing device 102 .
- the wallet management system 104 may send a transaction success message to the mobile computing device.
- authentication as described herein may be executed to authenticate the user to an ATM 132 and the ATM 132 to the user.
- the user may use the ATM 132 to access a financial service related to a financial account.
- the ATM 132 may be a third-party ATM, implemented by a bank other than the financial institution administering the user’s financial account.
- FIG. 7 is a timing diagram showing one example of an authentication used between the user 103 and the ATM 132 .
- the user 103 may begin the transaction by sending an access request message 252 to the ATM 132 .
- sending the access request message 252 may include allowing the ATM 132 to read an ATM or other card of the user 103 for accessing the user’s financial institution services.
- the ATM 132 may identify the relevant financial institution from information provided in the access request message 252 .
- the user 103 may affirmatively request the authentication transaction.
- the ATM 132 may send an authentication request message 254 to the financial institution system 106 .
- the authentication request message 254 may requested an authentication transaction.
- the financial institution system 106 may send a transaction request message 256 to the wallet management system 104 .
- the wallet management system 104 may send a transaction authorization request message 258 to the mobile computing device 102 of the user 103 (e.g., to a mobile wallet application executing at the mobile computing device 102 ).
- the mobile computing device may send a transaction authorization message 260 to the wallet management system 104 .
- the transaction authorization message 260 may include identity data and/or biometric data describing the user 103 .
- the wallet management system 104 may send a transaction confirmation message 262 to the financial institution system 106 indicating that the user 103 has authorized the authentication transaction.
- the financial institution system 106 may send a transaction summary 264 to the mobile computing device 102 .
- the financial institution system 106 may also send a transaction success message 266 to the ATM 132 .
- the transaction success message 266 may include data indicating to the ATM 132 that the authentication transaction was authorized and/or completed.
- FIG. 8 is a flowchart showing one example of a process flow 400 that may be executed by a financial institution system 106 , POS device 130 , ATM 132 or other counterparty (referred to in FIG. 8 as the counterparty system) to a user service request to determine whether to request an authentication transaction.
- the counterparty system may receive an access request message.
- the access request message may be received directly from a user 103 , such as the access request 252 to the ATM 132 described above.
- the access request may also be received from a mobile computing device 102 and/or other computing device 136 of the user 103 .
- the counterparty system may determine whether access request included and/or was accompanied by a request for an authentication transaction. If yes, the counterparty may proceed to a transaction sign-in at action 410 . For example, the counterparty may request that the wallet management system 104 initiate a transaction at the mobile computing device 102 of the user.
- the counterparty system may determine at action 406 whether an authentication transaction is required for the user 103 and/or an account of the user implicated by the access request.
- the financial institution system 106 and/or other counterparty my require the user 103 to use an authentication transaction, for example, if fraudulent or potentially fraudulent activity has been detected on an account of the user, the counterparty may request an authentication transaction.
- the counterparty e.g., the POS device 130 , ATM 132 , etc.
- the counterparty may query the financial institution system 106 to determine whether an authentication transaction is required for the user 103 . If not, then the counterparty and user may proceed to a standard sign-in at action 408 .
- a standard sign-in may include suitable authentication from the user 103 such as, for example, a user name and password. If an authentication transaction is required for the user, then the authentication transaction sign-in may be performed, as described herein, at action 410 .
- Authentication transactions may be real transactions made to the user’s financial account. Therefore, in some examples, authentication transactions may appear on a user’s statement. In some examples, authentication transactions may be broken into a separate category or location on the user’s statements. For example, transactions with a balance less than a threshold balance (e.g., 15 cents) may be considered authentication transactions and, therefore, may be listed at a distinct location on the user’s statement. In some examples, the financial institution system 106 may generate a user statement with authentication transactions (e.g., transactions on the user’s financial account below a threshold amount) at a separate position distinct from a listing of other transactions on the account.
- a threshold balance e.g. 15 cents
- FIG. 9 is a flowchart showing one example of a process flow 500 for an authentication utilizing one or more block chains.
- the process flow 500 includes two columns 501 , 503 .
- Actions in the column 503 may be executed by a user computing device, such as any of the user computing devices 2 A, 2 B, 36 described herein.
- Actions in column 501 may be executed by a counterparty.
- the counterparty may be any party to be authenticated to the user device (or a user thereof) utilizing the authentications described herein.
- the counter party may be the financial institution system 106 .
- the counterparty may be the POS device 130 .
- the counterparty may be the ATM 132 .
- the user device and the counterparty utilize a transaction block chain in addition to the transactions shown and described herein.
- the user device may comprise a user block chain data structure where each link in the block chain represents a transaction authentication conducted with a counterparty, such as a financial institution system, ATM, POS device, etc.
- the counterparty may comprise a counterparty block chain data structure where each link represents a transaction authentication conducted with a user device.
- the user device and/or counterparty may verify the block chain of the other party.
- the user device may send an access request message 505 to the counterparty.
- the access request message 505 may be similar to the other access request messages described herein.
- the access request message 505 may be or include a payment request.
- the counterparty may receive the access request message 505 at action 504 .
- the counterparty may verify a user block chain.
- the counterparty may verify the user block chain, for example, by verifying a cryptographic signature of the user and/or of a transaction counterparty for some or all of the links of the user block chain.
- the transaction counterparty for a link of the user block chain may be any counterparty with whom the user device has transacted including, for example, the counterparty of column 501 .
- the user block chain may be publicly available.
- the counterparty may already possess the user block chain and/or may request it from a third party (e.g., a block miner system) or from the user device.
- verifying the user block chain may be computationally expensive. Accordingly, the counterparty may utilize one or more block miner systems 5 to verify the user block chain.
- the user device may verify the counterparty block chain.
- the user device may verify the counterparty block chain, for example, by verifying a cryptographic signature of the counterparty and/or of a transaction user device for some or all of the links of the counterparty block chain.
- the transaction user device for a link of the counterparty block chain may be any user device with whom the user device has transacted including, for example, the user device of column 503 .
- the counterparty block chain may be publicly available.
- the user device may already possess the counterparty block chain and/or may request it from a third party (e.g., a block miner system) or from the counterparty.
- verifying the counterparty block chain may be computationally expensive. Accordingly, the user device may utilize one or more block miner systems 5 to verify the counterparty block chain.
- the user device and counterparty may engage in a transaction authentication, for example, as illustrated herein in FIG. 1 and FIGS. 4 - 7 .
- the user device may generate a new user block for the user block chain at action 512 .
- the counterparty may generate a new counterparty block for the counterparty block chain at action 514 .
- the new blocks may be transmitted, for example, to one or more block miner systems, which may verify the blocks and add them to the respective user and counterparty block chains.
- FIG. 10 is a block diagram 900 showing one example of a software architecture 902 for a computing device.
- the architecture 902 maybe used in conjunction with various hardware architectures, for example, as described herein.
- FIG. 10 is merely a non-limiting example of a software architecture and many other architectures may be implemented to facilitate the functionality described herein.
- the software architecture 902 may be executed on hardware such as, for example, a mobile computing device 2 , 2 A, 2 B, 102 , 130 , all or part of a wallet management system 4 , 104 , all or part of a financial institution system 6 , 106 , all or part of a POS device 30 , 130 , all or part of an ATM 32 , 132 , etc.
- a representative hardware layer 904 is illustrated and can represent, for example, any of the above referenced computing devices. In some examples, the hardware layer 904 may be implemented according to the architecture 300 of FIG. 3 and/or the architecture 1100 of FIG. 11 .
- the representative hardware layer 904 comprises one or more processing units 906 having associated executable instructions 908 .
- Executable instructions 908 represent the executable instructions of the software architecture 902 , including implementation of the methods, modules, components, and so forth of FIGS. 1 - 2 and 4 - 8 .
- Hardware layer 904 also includes memory and/or storage modules 910 , which also have executable instructions 908 .
- Hardware layer 904 may also comprise other hardware as indicated by other hardware 912 which represents any other hardware of the hardware layer 904 , such as the other hardware illustrated as part of hardware architecture 1100 .
- the software 902 may be conceptualized as a stack of layers where each layer provides particular functionality.
- the software 902 may include layers such as an operating system 914 , libraries 916 , frameworks/middleware 918 , applications 920 and presentation layer 944 .
- the applications 920 and/or other components within the layers may invoke application programming interface (API) calls 924 through the software stack and receive a response, returned values, and so forth illustrated as messages 926 in response to the API calls 924 .
- API application programming interface
- the layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks / middleware layer 918 , while others may provide such a layer. Other software architectures may include additional or different layers.
- the operating system 914 may manage hardware resources and provide common services.
- the operating system 914 may include, for example, a kernel 928 , services 930 , and drivers 932 .
- the kernel 928 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on.
- the services 930 may provide other common services for the other software layers.
- the drivers 932 may be responsible for controlling or interfacing with the underlying hardware.
- the drivers 932 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, NFC drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.
- serial communication drivers e.g., Universal Serial Bus (USB) drivers
- Wi-Fi® drivers e.g., Wi-Fi® drivers
- NFC drivers e.g., NFC drivers
- audio drivers e.g., audio drivers, power management drivers, and so forth depending on the hardware configuration.
- the libraries 916 may provide a common infrastructure that may be utilized by the applications 920 and/or other components and/or layers.
- the libraries 916 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 914 functionality (e.g., kernel 928 , services 930 and/or drivers 932 ).
- the libraries 916 may include system 934 libraries (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like.
- libraries 916 may include API libraries 936 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render 2 D and 9 D in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like.
- the libraries 916 may also include a wide variety of other libraries 938 to provide many other APIs to the applications 920 and other software components/modules.
- the frameworks 918 may provide a higher-level common infrastructure that may be utilized by the applications 920 and/or other software components/modules.
- the frameworks 918 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth.
- GUI graphic user interface
- the frameworks 918 may provide a broad spectrum of other APIs that may be utilized by the applications 920 and/or other software components/modules, some of which may be specific to a particular operating system or platform.
- the applications 920 includes built-in applications 940 and/or third party applications 942 .
- built-in applications 940 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application.
- Third party applications 942 may include any of the built in applications as well as a broad assortment of other applications.
- the third party application 942 e.g., an application developed using the AndroidTM or iOSTM software development kit (SDK) by an entity other than the vendor of the particular platform
- the third party application 942 may be mobile software running on a mobile operating system such as iOSTM, AndroidTM, Windows® Phone, or other mobile computing device operating systems.
- the third party application 942 may invoke the API calls 924 provided by the mobile operating system such as operating system 914 to facilitate functionality described herein.
- the applications 920 may utilize built in operating system functions (e.g., kernel 928 , services 930 and/or drivers 932 ), libraries (e.g., system 934 , APIs 936 , and other libraries 938 ), frameworks / middleware 918 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems interactions with a user may occur through a presentation layer, such as presentation layer 944 . In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
- Some software architectures utilize virtual machines.
- the wallet manager system 104 and/or financial institution systems 106 may be executed on one or more virtual machines executed at one or more server computing machines. In the example of FIG. 10 , this is illustrated by virtual machine 948 .
- a virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware computing device.
- a virtual machine is hosted by a host operating system (operating system 914 ) and typically, although not always, has a virtual machine monitor 946 , which manages the operation of the virtual machine as well as the interface with the host operating system (i.e., operating system 914 ).
- a software architecture executes within the virtual machine such as an operating system 950 , libraries 952 , frameworks / middleware 954 , applications 956 and/or presentation layer 958 .
- These layers of software architecture executing within the virtual machine 948 can be the same as corresponding layers previously described or may be different.
- FIG. 11 is a block diagram illustrating a computing device hardware architecture 1100 , within which a set or sequence of instructions can be executed to cause the machine to perform examples of any one of the methodologies discussed herein.
- the architecture 1100 may execute the software architecture 902 described with respect to FIG. 10 .
- the architecture 1100 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the architecture 1100 may operate in the capacity of either a server or a client machine in server-client network environments, or it may act as a peer machine in peer-to-peer (or distributed) network environments.
- the architecture 1100 can be implemented in a personal computer (PC), a tablet PC, a hybrid tablet, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA personal digital assistant
- Example architecture 1100 includes a processor unit 1102 comprising at least one processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.).
- the architecture 1100 may further comprise a main memory 1104 and a static memory 1106 , which communicate with each other via a link 1108 (e.g., bus).
- the architecture 1100 can further include a video display unit 1110 , an alphanumeric input device 1112 (e.g., a keyboard), and a user interface (UI) navigation device 1114 (e.g., a mouse).
- UI user interface
- the video display unit 1110 , input device 1112 and UI navigation device 1114 are incorporated into a touch screen display.
- the architecture 1100 may additionally include a storage device 1116 (e.g., a drive unit), a signal generation device 1118 (e.g., a speaker), a network interface device 1120 , and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
- a storage device 1116 e.g., a drive unit
- a signal generation device 1118 e.g., a speaker
- a network interface device 1120 e.g., a Wi-Fi
- sensors not shown, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
- GPS global positioning system
- the storage device 1116 includes a machine-readable medium 1122 on which is stored one or more sets of data structures and instructions 1124 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein.
- the instructions 1124 can also reside, completely or at least partially, within the main memory 1104 , static memory 1106 , and/or within the processor 1102 during execution thereof by the architecture 1100 , with the main memory 1104 , static memory 1106 , and the processor 1102 also constituting machine-readable media.
- Instructions stored at the machine-readable medium 1122 may include, for example, instructions for implementing the software architecture 902 , instructions for executing any of the features described herein, etc.
- machine-readable medium 1122 is illustrated in an example to be a single medium, the term “machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 1124 .
- the term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions.
- the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.
- machine-readable media include non-volatile memory, including, but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
- semiconductor memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)
- EPROM electrically programmable read-only memory
- EEPROM electrically erasable programmable read-only memory
- flash memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)
- flash memory devices e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEP
- the instructions 1124 can further be transmitted or received over a communications network 1126 using a transmission medium via the network interface device 1120 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).
- Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi, 3G, and 6G LTE/LTE-A or WiMAX networks).
- POTS plain old telephone
- wireless data networks e.g., Wi-Fi, 3G, and 6G LTE/LTE-A or WiMAX networks.
- transmission medium shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
- a component may be configured in any suitable manner.
- a component that is or that includes a computing device may be configured with suitable software instructions that program the computing device.
- a component may also be configured by virtue of its hardware arrangement or in any other suitable manner.
Abstract
Various examples are directed to systems and methods for authentication transactions. A mobile computing device may send to a financial institution system, an access request message. The mobile computing device may receive from a second server system, a transaction request message requesting authorization for a transaction on an account associated with the mobile computing device, the transaction request including a transaction amount. The mobile computing device may prompt a user of the mobile computing device to authorize the transaction. The mobile computing device may receive, from the financial institution system, summary data describing the transaction amount.
Description
- This application is a divisional of U.S. Pat. Application Serial No. 17/006,183, which is a divisional of U.S. Pat. Application Serial No. 15/180,711, filed Jun. 13, 2016, now issued as U.S. Pat. No. 10,762,505, each of which are incorporated by reference herein in their entirety.
- Embodiments described herein generally relate to authentication, for example and without limitation, authentication including initiating a transaction to a user account for authentication.
- Authentication methods are used by parties to an electronic transaction to verify the identity of a counter party.
- In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not of limitation, in the figures of the accompanying drawings, in which;
-
FIG. 1 is a diagram showing an example of an environment for authentication utilizing a transaction to a financial account of a user. -
FIG. 2 is a diagram showing another example of the environment ofFIG. 1 with additional components. -
FIG. 3 is a block diagram showing an example architecture of a mobile computing device. -
FIG. 4 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user. -
FIG. 5 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user involving a user mobile computing device and a second user computing device. -
FIG. 6 is a timing diagram showing one example of an authentication used in the context of a payment from the user to a merchant. -
FIG. 7 is a timing diagram showing one example of an authentication used between a user and an automated teller machine (ATM). -
FIG. 8 is a flowchart showing one example of a process flow that may be executed by a financial institution system, point of service (POS) device, automated teller machine ATM or other counterparty to a user service request to determine whether to request an authentication transaction. -
FIG. 9 is a flowchart showing one example of a process flow an authentication utilizing one or more block chains. -
FIG. 10 is a block diagram showing one example of a software architecture for a computing device. -
FIG. 11 is a block diagram illustrating a computing device hardware architecture, within which a set or sequence of instructions can be executed to cause the machine to perform examples of any one of the methodologies discussed herein. - Various examples described herein are directed to authentication that includes a transaction to a user’s financial account. The user may request access to a financial service provided by a financial institution through a financial institution system. The user may make the request from a financial services application executing at a computing device, such as a mobile computing device. For example, the user may be a customer of the financial institution. The financial service may be any suitable financial service offered by the financial institution including, for example, an account management service, an online bill pay service, a loan application service, etc.
- In some examples, both the user and the financial institution system may verify the identity of the other at least in part through a transaction to a financial account of the user, such as a financial account held at the financial institution. For example, upon receiving the access request from the user, the financial institution system may send a transaction request to a second server system requesting a transaction to the account of the user. The transaction may be a credit or debit to the account, such as of a small amount, such as a few cents. In some examples, the transaction may include both a credit and an equivalent debit to the user’s account.
- The second server system may be a wallet management system programmed to manage one or more financial accounts of the user. The transaction request may include transaction description data including a transaction amount and an identity of the financial account. The second server system may prompt the user to authorize the requested transaction. For example, the second server system may send a transaction request message to a mobile wallet application executing at the mobile computing device of the user. The user may receive the transaction request message and reply to the second server system with a transaction authorization message, for example, via the mobile wallet application. In some examples, the transaction authorization message may include identifying data from the user, such as, for example, user name data including a user name, password data including a password, personal identification number (PIN) data including a PIN, biometric data captured from the user, etc. The second server system may verify the identifying data and continue and/or complete the transaction. The second server system may send the financial institution system a transaction confirmation message indicating that the user has authorized the transactions. The financial institution system may send the user a transaction summary message including transaction amount data.
- In some examples, both the user and the financial institution may utilize the transaction process to verify the identity of the other. For example, the user may be unlikely to authorize the transaction if it is unexpected. Accordingly, the party that authorizes the transaction is likely to be the same party that made the initial access request to the financial institution system. Also, the user may verify its identity to the second server system with the identifying data provided with the transaction authorization. The user, on the other hand, may receive data regarding the transaction from both from the second server system and from the financial institution system.
- Although the example above is described between a user and a financial system, some examples may utilize transactions to a user financial account to authenticate users and service provider systems in other contexts. For example, the user may request access to a service provided by a first server system. The first server system may send to the second server system a transaction request requesting the transaction to the financial account of the user. The second server system may prompt a mobile computing device of the user to authorize the transaction and send a transaction confirmation message to the financial institution system. The financial institution system may send a transaction summary message to the user.
-
FIG. 1 is a diagram showing an example of anenvironment 10 for authentication utilizing a transaction to a financial account of auser 3. In the example ofFIG. 1 , theuser 3 utilizes amobile computing device 2. Other components in theenvironment 10 may include afinancial institution system 6 and awallet management system 4. - The
mobile computing device 2 may be or include any computing device suitable for executing authentication of auser 3 as described herein. Examplemobile computing devices 2 may include smart phones, tablet computers, laptop computers, smart watches, etc. In the example ofFIG. 1 , themobile computing device 2 executes afinancial services application 20 and amobile wallet application 22. Thefinancial services application 20 may be a client-side and/or web application suitable for accessing one or more financial services of a financial institution. For example, thefinancial services application 20 may be in communication with thefinancial institution system 6, as described herein. Theuser 3, in some examples, is a customer of the financial institution and may hold one or more financial accounts at the financial institution system. - The
mobile wallet application 22 may be a client-side and/or web application suitable for managing payments to or from one or more financial accounts of theuser 3. Themobile wallet application 22 may implement a mobile wallet service for theuser 3, for example, in conjunction with thewallet management system 4. Themobile wallet application 22 may enable theuser 3 to make payments to and/or from various financial accounts, such as, for example, credit card accounts, debit accounts, line-of-credit accounts, checking accounts, savings accounts, etc. Examples of mobile wallet services that may be used for authentication as described herein include APPLE PAY, GOOGLE WALLET, SOFTCARD, etc. One or more accounts managed by the mobile wallet service may be held by theuser 3 with thefinancial institution system 6. - The
financial institution system 6 may be any suitable computing system for providing users, such as theuser 3, with one or more financial services, such as an account management service, an online bill pay service, a loan application service, etc. For example, thefinancial institution system 6 may be configured to communicate with themobile computing device 2 and with thefinancial services application 20 described herein. In some examples, thefinancial institution system 6 may be configured to communicate with another computing device of theuser 3 in addition to or instead of themobile computing device 2. Thefinancial institution system 6 may comprise one or more computing devices, such as servers, configured to operate as described herein. Computing devices making up thefinancial institution system 6 may be located at a single geographic location and/or may be distributed across multiple geographic locations. In some examples, thefinancial institution system 6 may be implemented in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations of thefinancial institution system 6 may be performed by a group of computing devices, with these operations being accessible via a network and/or via one or more appropriate interfaces (e.g., an Application Program Interface (API)). - The
wallet management system 4 may be any suitable computing system for providing users, such as theuser 3 with a mobile wallet service. Thewallet management system 4 may be configured to communicate with themobile computing device 2 and with themobile wallet application 22 described herein. Thewallet management system 4 may comprise one or more computing devices, such as servers, configured to operate as described herein. Computing devices making up thewallet management system 4 may be located at a single geographic location and/or may be distributed across multiple geographic locations. In some examples, thewallet management system 4 may be implemented in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations of thewallet management system 4 may be performed by a group of computing devices, with these operations being accessible via a network and/or via one or more appropriate interfaces (e.g., an Application Program Interface (API)). -
FIG. 1 also shows an example workflow for authentication in theenvironment 10. The mobile computing device 2 (e.g., the financial services application 20) may send anaccess request message 8 to the financial institution system. Theaccess request message 8 may comprise a request to access one or more financial services offered by thefinancial institution system 6. In some examples, theaccess request message 8 is sent at the beginning of a communication session between thefinancial services application 20 and thefinancial institution system 6, for example, as part of a sign-in process. In some examples, theaccess request message 8 may be sent when themobile computing device 2 requests access to a particular financial service offered by the financial institution system 6 (e.g., after an initial sign-in). - In response to the access request, the
financial institution system 6 may direct atransaction request message 11 to thewallet management system 4. Thetransaction request message 11 may request that thewallet management system 4 initiate a transaction to a financial account of theuser 3. Thetransaction request message 11 may include transaction data describing theuser 3 such as, for example, a name of theuser 3, an account number of a financial account held by the user, etc. Thetransaction request message 11 may also include financial institution system data describing thefinancial institution system 6. In some examples, thetransaction request message 11 may include a requested transaction amount or in some examples, thetransaction request message 11 may request a transaction without specifying the transaction amount. For example, thewallet management system 4 may select the amount of the transaction. In some examples, thewallet management system 4 may have or request authentication of thefinancial institution system 6. For example, thefinancial institution system 6 may provide a digital certificate indicating its identity (e.g., its association with an implementing financial institution). Any other form of digital authentication may be used. When the financial institution authenticates itself to thewallet management system 4, it may do so at or about the time that thetransaction request message 11 is sent or, in some examples, may do so prior to the sending of thetransaction request message 11. - The
wallet management system 4, upon receiving thetransaction request message 11, may send a transactionauthorization request message 12 to themobile wallet application 22 executing at themobile computing device 2. In some examples, the transactionauthorization request message 12 may comprise data instructing themobile wallet application 22 to prompt theuser 3 to authorize the transaction. The mobile device (e.g., the mobile wallet application 22) may prompt theuser 3 to authorize the transaction. In some examples, the transaction authorization request message may also include data describing the transaction including, for example, a transaction amount, a counterparty to the transaction, etc. In an example, the transactionauthorization request message 12 may cause themobile wallet application 22 to display the following message at the mobile computing device 2:
Financial Institution X would like to apply a credit of $0.07 to your account Y. Do you authorize this transaction?
In some examples, the transaction may include multiple credits and/or debits to the user’s financial account, for example, credits and debits that offset and/or sum to zero. Accordingly, another example message that themobile wallet application 22 may cause to display at themobile computing device 2 is below:
Financial Institution X would like to apply a credit of $0.07 and a debit of $0.07 to your account Y. Do you authorize this transaction?
In some examples, the transaction authorization request may also include data describing the nature of theaccess request message 8. For example, another message that themobile wallet application 22 may cause to display at themobile computing device 2 is below:
Financial Institution X would like to apply a credit of $0.07 cents to your account Y as part of your request to access a financial service at Financial Institution X. Do you authorize this transaction?
In some examples, the message may specify the financial service that was requested. Although a transaction amount of $0.07 is listed in these examples, any suitable transaction amount may be used including, in some examples, transaction amounts that are fractions of a cent. - The
user 3 may authorize the requested transaction, for example, if theuser 3 expects the transaction request and/or recognizes the source. For example, if theaccess request message 8 is sent by an imposter, and not by theuser 3, then theuser 3 may not authorize the transaction. Also, for example, if theuser 3 does not recognize the requesting party (e.g., the financial institution or Financial Institution system 6), then the user may not authorize the transaction. - Provided that the
user 3 is to authorize the transaction, theuser 3 may provide authorization in any suitable manner. For example, authorization may be performed through themobile wallet application 22. For example, themobile wallet application 22 may prompt theuser 3 to provide identifying data. The identifying data may include, for example, a user name, a password, a personal identification number (PIN). In some examples, themobile wallet application 22 may prompt theuser 3 to provide biometric data. Biometric data may include any data describing the user’s person. In some examples, themobile computing device 2 may include a touch sensor suitable for capturing a fingerprint of the user. For example, the biometric data may include a representation of the user’s fingerprint. In some examples, themobile computing device 2 may include a camera suitable for capturing an image of the user 3 (e.g., the user’s face). For example, the biometric data may include an image of the user (e.g., the user’s face). In some examples, themobile computing device 2 may include an optical scanner suitable to capture a retinal scan of the user’s eye. For example, the biometric data may include data describing the retinal scan. Although several examples of biometric data are provided and may be used in any combination, other types of biometric data may be utilized in addition to or instead of the provided examples. - Upon receiving authorization for the transaction from the
user 3, themobile wallet application 22 may send atransaction authorization message 14 to thewallet management system 4. Thetransaction authorization message 14 may include authorization data indicating the user’s authorization of the transaction. In some examples, thetransaction authorization message 14 may also include the identity data and/or biometric data received from theuser 3. Thewallet management system 4 may receive thetransaction authorization message 14. When thetransaction authorization message 14 includes identity data and/or biometric data, thewallet management system 4, thewallet management system 4 may determine whether the identity data and/or biometric data matches reference identity data and/or reference biometric data for theuser 3 stored at and/or otherwise accessible to thewallet management system 4. For example reference identity data including a password may be referred to as reference password data. If the identity and/or biometric data contained in thetransaction authorization message 14 matches the reference user identity data for theuser 3, thewallet management system 4 may complete the transaction. - The
wallet management system 4 may complete the transaction in any suitable manner. For example, thewallet management system 4 may communicate with a system associated with an organization that holds the financial account on behalf of theuser 3. For example, when the financial account is a credit card account, thewallet management system 4 may communicate with a system implemented by the credit card company associated with the credit card account. Also, for example, when the financial account is a checking, savings, or other suitable account held at a retail bank, thewallet management system 4 may communicate with a system implemented by the retail bank. - The
wallet management system 4 may also send atransaction confirmation message 16 to thefinancial institution system 6. Thetransaction confirmation message 16 may include data indicating that theuser 3 has authorized the transaction. In some examples, thetransaction confirmation message 16 may also include data describing the transaction such as, for example, the transaction amount, timestamp data indicating a time of one or more processing steps for executing the transaction (e.g., transaction completion, request, etc.). Thefinancial institution system 6 may receive thetransaction confirmation message 16 and may generate atransaction summary message 18 and send it to the mobile computing device 2 (e.g., the financial services application 20). Thetransaction confirmation message 16 may include some or all of the data describing the transaction. Thetransaction summary message 18 may include transaction summary data summarizing the transaction to themobile device 2. In some examples, thefinancial institution system 6 may also approve theaccess request message 8. -
FIG. 2 is a diagram showing another example of theenvironment 10 ofFIG. 1 with additional components. For example,FIG. 2 showsuser computing devices device 30 and an example automated teller machine (ATM) 32. User computing devices may include examplemobile computing devices additional computing device 36.Mobile computing devices user 3 to authorize an authentication transaction, as described herein.Mobile computing devices mobile computing device 2A may be a mobile phone.Mobile computing device 2B may be a tablet computer. Any other suitable type of mobile computing device may be used. In some examples, mobile computing devices, such as 2A, 2B may be configured to communicate in a wireless manner. -
FIG. 2 also shows thePOS device 30 andATM 32. These devices, in some examples, may be part of authentication as described herein. ThePOS device 30 may be a device associated with any party that receives payments, such as an online or bricks-and-mortar merchant. ThePOS device 30 may comprise a processing unit and various other computing components. In some examples, thePOS device 30 may be or comprise a computing device configured, for example, according to one or more of the hardware or software architectures described herein. ThePOS device 30 may be configured to communicate with amobile computing device mobile wallet application 22 executing at themobile computing device POS device 30 may be configured to communicate with amobile computing device POS device 30 may request an authentication transaction, for example, when theuser 3 requests that a payment be made to a retailer associated with thePOS device 30. For example, the payment may be the service accessed by theuser 3. - The
ATM 32 may be implemented by a financial institution and/or a third party administrator to provide theuser 3 with financial services, such as, for example, cash withdrawals, balance checks, etc. TheATM 32 may comprise a processing unit and various other computing components. In some examples, theATM 32 may be or comprise a computing device configured, for example, according to one or more of the hardware or software architectures described herein. In some examples, theATM 32 may request an authentication transaction, for example, when the user request a financial service from theATM 32. AlthoughFIG. 2 shows a single example of various components, in some examples, additional instances ofusers 3,mobile computing devices computing devices 36,wallet management systems 4,financial institution systems 6,ATMs 32 and/orPOS devices 30 may be included in additional to or instead of those shown. -
FIG. 2 also shows an optionalblock miner system 5. Theblock miner system 5 may be present in some examples where block chains of transaction authentications are utilized to identify theuser 3 and/or a counterparty, such as thefinancial institution system 6, thePOS device 30, theATM 32, etc. Although oneblock miner system 5 is shown, additionalblock miner systems 5 may be included.Block miner systems 5 may be implemented by any suitable party. Additional examples describing the use of block chains of transaction authentications are described herein, for example, with respect toFIG. 9 . - The
various components environment 10 may be in communication with one another via anetwork 120. Thenetwork 120 may be or comprise any suitable network element operated according to any suitable network protocol. For example, one or more portions ofnetwork 120 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a Wi-Fi network, a WiMax network, another type of network, or a combination of two or more such networks. -
FIG. 3 is a block diagram showing anexample architecture 300 of a mobile computing device. Any of themobile computing devices architecture 300. Thearchitecture 300 comprises aprocessor unit 310. Theprocessor unit 310 may include one or more processors. Any of a variety of different types of commercially available processors suitable for mobile computing devices may be used (for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor). Amemory 320, such as a Random Access Memory (RAM), a Flash memory, or other type of memory or data storage, is typically accessible to the processor. Thememory 320 may be adapted to store an operating system (OS) 330, as well asapplication programs 340. - The
processor unit 310 may be coupled, either directly or via appropriate intermediary hardware, to adisplay 350 and to one or more input/output (I/O)devices 360, such as a keypad, a touch panel sensor, a microphone, and the like. In some examples I/O devices 360 may include one or more devices for receiving biometric data from a user (e.g., the user 3). Such I/O devices 360 may include a touch sensor for capturing fingerprint data, a camera for capturing one or more images of the user, a retinal scanner, or any other suitable devices. Similarly, in some examples, theprocessor 310 may be coupled to atransceiver 370 that interfaces with anantenna 390. Thetransceiver 370 may be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via theantenna 390, depending on the nature of the mobile computing device implemented by thearchitecture 300. Although onetransceiver 370 is shown, in some examples, thearchitecture 300 includes additional transceivers. For example, a wireless transceiver may be utilized to communicate according to an IEEE 802.11 specification, such as Wi-Fi and/or to a short range communication medium. Some short range communication mediums, such as NFC, may utilize a separate, dedicated transceiver. Further, in some configurations, aGPS receiver 380 may also make use of theantenna 390 to receive GPS signals. -
FIG. 4 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user. For example, the authentication illustrated by the workflow ofFIG. 1 may be implemented according to the timing shown inFIG. 4 . The timing diagram shows three parties, afinancial institution system 106, awallet management system 104 and amobile computing device 102. - The mobile computing device 102 (e.g., a financial services application executing at the mobile computing device 102) may send to the
financial institution system 106 anaccess request message 118. Theaccess request message 118 may initiate the authentication. In some examples, however, thefinancial institution system 106 may initiate the authentication by soliciting theaccess request 108 with an access solicitation message. Thefinancial institution system 106 may send to the wallet management system 104 a transaction request message 110. The wallet management system may send the mobile computing device 102 (e.g., a mobile wallet application executing at the mobile computing device) atransaction authorization request 112. In response, themobile computing device 102 may provide a transaction authorization message 114. The transaction authorization message 114 may include identifying information and/or biometric information as described. Thewallet management system 104 may send a transaction confirmation message 116 to the financial institution system indicating that the user has confirmed the transaction. Thefinancial institution system 106 may send atransaction summary message 118 to themobile computing device 102. - In various implementations, the timing shown by the timing diagram may be modified from what is shown in
FIG. 4 . In some examples, thefinancial institution system 106 may send thetransaction summary message 118 before receiving the transaction confirmation message 116. -
FIG. 5 is a timing diagram showing one example of an authentication utilizing a transaction to a financial account of a user involving a usermobile computing device 102 and a seconduser computing device 136. The seconduser computing device 136 may be or include, for example, a desktop computer, a laptop computer, etc. In some examples, the seconduser computing device 136 may execute a financial services application for accessing financial services executed by thefinancial institution system 106. The user may utilize the seconduser computing device 136 to send anaccess request message 151 to the financial institution system. Theaccess request message 151 may include a request to access one or more financial services offered by thefinancial institution system 106. - In response to the
access request message 151, thefinancial institution system 106 may send atransaction request message 152 to thewallet management system 104. Thetransaction request message 152 may include data requesting that thewallet management system 104 initiate a transaction to a financial account of the user. Thewallet management system 104 may send a transaction requestauthorization request message 154 to themobile computing device 102 of the user. For example, themobile computing device 102 and/or a mobile wallet application executing at the mobile computing device may be associated with the selected user and/or financial account at thewallet management system 104. Themobile computing device 102 may respond to the transactionauthorization request message 154 by sending to the wallet management system 104 a transaction authorization message 156, which may include user identity and/or biometric data, as described herein. Thewallet management system 104 may send to the financial institution system 106 atransaction confirmation message 158 indicating that the transaction has been authorized by the user. Thefinancial institution system 106 may send atransaction summary message 160 to the seconduser computing device 136. Various modifications to the timing of the messages of the timing diagram may also be made, for example, as described herein. -
FIG. 6 is a timing diagram showing one example of an authentication used in the context of a payment from the user to a merchant. For example, when a user requests a payment to a merchant, it may be desirable for the user and merchant to authenticate one another. In this way, the merchant may receive an indication that that the proffered payment is legitimate (e.g., actually proffered by the user who is the owner of the account used for the payment). Further, the user may receive an indication that the recipient of the payment is actually the merchant and not a third party (e.g., a third party engaged in a phishing operation to obtain the user’s account credentials). - According to the timing diagram of
FIG. 6 , the merchant or other recipient of a payment from the user (e.g., the payee) is represented asPOS device 130. In some examples, all or part of the functionality ascribed to thePOS device 130 may be executed by other components associated with the payee such as, for example, a payment server (not shown). Themobile computing device 102 may send to the POS device 130 a payment request message 202. The payment request message 202 may include data describing a payment to be made to a payee, such as a merchant. The data may include, for example, an amount of the payment, a financial account of the user from which the payment is to be made, etc. For example, the user and the payee may engage in a transaction where the payee provides goods and/or services to the user and the user is to provide the payment in return. In some examples, the payment request message 202 may be send by a mobile wallet application executing at themobile computing device 102. The mobile computing device may communicate with thePOS device 130 in any suitable manner including, for example, via a short range communication medium. - The
POS device 130 may send to the financial institution system 106 a authentication request message 204. For example, thefinancial institution system 106 may administer the financial account of the user from which the payment is to be made. The authentication request message 204 may request that thefinancial institution system 106 initiate an authentication. Thefinancial institution system 106 may send a transaction request message 206 to thewallet management system 104. The transaction request message 206 may request that thewallet management system 104 initiate a transaction, as described herein. Thewallet management system 104 may send a transactionauthorization request message 208 to the mobile computing device 102 (e.g., a mobile wallet application executing at the mobile computing device 102). In response to the transaction authorization request message, themobile computing device 102 may provide atransaction authorization message 210. Thetransaction authorization message 210 may include user identity data and/or biometric data as described herein. - The
wallet management system 104 may also send to the financial institution system a transaction summary message 212 including data describing the transaction, as described herein. The financial institution system may send a secondtransaction summary message 214 to the mobile computing device, which may serve to authenticate thePOS device 130 to themobile computing device 102. Thetransaction summary message 214, for example, may include data describing the transaction, as described herein, including, for example, a transaction amount, a transaction timestamp, etc. In some examples, thefinancial institution system 106 may send atransaction success message 216 to thePOS device 130. Thetransaction success message 216 may indicate to thePOS device 130 that the transaction has been successfully completed, which may serve as an authentication of themobile computing device 102 to thePOS device 130. - In some examples of the authentication of
FIG. 6 , thefinancial institution system 106 may be omitted. For example, thePOS device 130 may send the authentication request message 204 directly to thewallet management system 104. For example, thewallet management system 104 may send a transaction summary message to themobile computing device 102. Further, thewallet management system 104 may send a transaction success message to the mobile computing device. - In some examples, authentication as described herein may be executed to authenticate the user to an
ATM 132 and theATM 132 to the user. For example, the user may use theATM 132 to access a financial service related to a financial account. TheATM 132, in some examples, may be a third-party ATM, implemented by a bank other than the financial institution administering the user’s financial account. For example, it may be desirable for the user to verify that theATM 132 is legitimately in communication with the user’s financial institution and not engaged in a phishing operation to steal the user’s log-in credentials. Also, it may be desirable for theATM 132 to verify that the user is a legitimate customer of the financial institution. -
FIG. 7 is a timing diagram showing one example of an authentication used between theuser 103 and theATM 132. Theuser 103 may begin the transaction by sending anaccess request message 252 to theATM 132. For example, sending theaccess request message 252 may include allowing theATM 132 to read an ATM or other card of theuser 103 for accessing the user’s financial institution services. TheATM 132 may identify the relevant financial institution from information provided in theaccess request message 252. In some examples, theuser 103 may affirmatively request the authentication transaction. - The
ATM 132 may send anauthentication request message 254 to thefinancial institution system 106. Theauthentication request message 254 may requested an authentication transaction. Thefinancial institution system 106 may send atransaction request message 256 to thewallet management system 104. In response, thewallet management system 104 may send a transactionauthorization request message 258 to themobile computing device 102 of the user 103 (e.g., to a mobile wallet application executing at the mobile computing device 102). The mobile computing device may send atransaction authorization message 260 to thewallet management system 104. As described herein, thetransaction authorization message 260 may include identity data and/or biometric data describing theuser 103. Thewallet management system 104 may send atransaction confirmation message 262 to thefinancial institution system 106 indicating that theuser 103 has authorized the authentication transaction. Thefinancial institution system 106 may send atransaction summary 264 to themobile computing device 102. Thefinancial institution system 106 may also send atransaction success message 266 to theATM 132. Thetransaction success message 266 may include data indicating to theATM 132 that the authentication transaction was authorized and/or completed. - In some examples, the user may access financial services, initiate a payment, access an ATM, etc. without using an authentication transaction as described herein. Authentication transactions may be requested by the user and/or by any other component of the environment.
FIG. 8 is a flowchart showing one example of aprocess flow 400 that may be executed by afinancial institution system 106,POS device 130,ATM 132 or other counterparty (referred to inFIG. 8 as the counterparty system) to a user service request to determine whether to request an authentication transaction. - At
action 402, the counterparty system may receive an access request message. The access request message may be received directly from auser 103, such as theaccess request 252 to theATM 132 described above. The access request may also be received from amobile computing device 102 and/orother computing device 136 of theuser 103. Ataction 404, the counterparty system may determine whether access request included and/or was accompanied by a request for an authentication transaction. If yes, the counterparty may proceed to a transaction sign-in ataction 410. For example, the counterparty may request that thewallet management system 104 initiate a transaction at themobile computing device 102 of the user. - If not, the counterparty system may determine at
action 406 whether an authentication transaction is required for theuser 103 and/or an account of the user implicated by the access request. In some examples, thefinancial institution system 106 and/or other counterparty my require theuser 103 to use an authentication transaction, for example, if fraudulent or potentially fraudulent activity has been detected on an account of the user, the counterparty may request an authentication transaction. In some examples, when the counterparty is not thefinancial institution system 106, the counterparty (e.g., thePOS device 130,ATM 132, etc.) may query thefinancial institution system 106 to determine whether an authentication transaction is required for theuser 103. If not, then the counterparty and user may proceed to a standard sign-in ataction 408. A standard sign-in may include suitable authentication from theuser 103 such as, for example, a user name and password. If an authentication transaction is required for the user, then the authentication transaction sign-in may be performed, as described herein, ataction 410. - Authentication transactions, as described herein, may be real transactions made to the user’s financial account. Therefore, in some examples, authentication transactions may appear on a user’s statement. In some examples, authentication transactions may be broken into a separate category or location on the user’s statements. For example, transactions with a balance less than a threshold balance (e.g., 15 cents) may be considered authentication transactions and, therefore, may be listed at a distinct location on the user’s statement. In some examples, the
financial institution system 106 may generate a user statement with authentication transactions (e.g., transactions on the user’s financial account below a threshold amount) at a separate position distinct from a listing of other transactions on the account. -
FIG. 9 is a flowchart showing one example of aprocess flow 500 for an authentication utilizing one or more block chains. Theprocess flow 500 includes twocolumns column 503 may be executed by a user computing device, such as any of theuser computing devices column 501 may be executed by a counterparty. The counterparty may be any party to be authenticated to the user device (or a user thereof) utilizing the authentications described herein. For example, with respect to the timing diagram ofFIGS. 4-5 , the counter party may be thefinancial institution system 106. With respect to the timing diagram ofFIG. 6 , the counterparty may be thePOS device 130. With respect to the timing diagram ofFIG. 7 , the counterparty may be theATM 132. - Generally, in the
process flow 500, the user device and the counterparty utilize a transaction block chain in addition to the transactions shown and described herein. For example, the user device may comprise a user block chain data structure where each link in the block chain represents a transaction authentication conducted with a counterparty, such as a financial institution system, ATM, POS device, etc. Similarly, the counterparty may comprise a counterparty block chain data structure where each link represents a transaction authentication conducted with a user device. In addition to the transaction authentications described herein, the user device and/or counterparty may verify the block chain of the other party. - At
action 502, the user device may send anaccess request message 505 to the counterparty. Theaccess request message 505 may be similar to the other access request messages described herein. In some examples, (e.g., where the counterparty is a POS device), theaccess request message 505 may be or include a payment request. The counterparty may receive theaccess request message 505 ataction 504. At action 508, the counterparty may verify a user block chain. The counterparty may verify the user block chain, for example, by verifying a cryptographic signature of the user and/or of a transaction counterparty for some or all of the links of the user block chain. The transaction counterparty for a link of the user block chain may be any counterparty with whom the user device has transacted including, for example, the counterparty ofcolumn 501. In some examples, the user block chain may be publicly available. For example, the counterparty may already possess the user block chain and/or may request it from a third party (e.g., a block miner system) or from the user device. Also, in some examples, verifying the user block chain may be computationally expensive. Accordingly, the counterparty may utilize one or moreblock miner systems 5 to verify the user block chain. - At
action 506, the user device may verify the counterparty block chain. The user device may verify the counterparty block chain, for example, by verifying a cryptographic signature of the counterparty and/or of a transaction user device for some or all of the links of the counterparty block chain. The transaction user device for a link of the counterparty block chain may be any user device with whom the user device has transacted including, for example, the user device ofcolumn 503. In some examples, the counterparty block chain may be publicly available. For example, the user device may already possess the counterparty block chain and/or may request it from a third party (e.g., a block miner system) or from the counterparty. Also, in some examples, verifying the counterparty block chain may be computationally expensive. Accordingly, the user device may utilize one or moreblock miner systems 5 to verify the counterparty block chain. - At
action 510, the user device and counterparty may engage in a transaction authentication, for example, as illustrated herein inFIG. 1 andFIGS. 4-7 . At the conclusion of the authentication, for example if the authentication is successful, the user device may generate a new user block for the user block chain at action 512. Similarly, the counterparty may generate a new counterparty block for the counterparty block chain ataction 514. The new blocks may be transmitted, for example, to one or more block miner systems, which may verify the blocks and add them to the respective user and counterparty block chains. -
FIG. 10 is a block diagram 900 showing one example of asoftware architecture 902 for a computing device. Thearchitecture 902 maybe used in conjunction with various hardware architectures, for example, as described herein.FIG. 10 is merely a non-limiting example of a software architecture and many other architectures may be implemented to facilitate the functionality described herein. Thesoftware architecture 902 may be executed on hardware such as, for example, amobile computing device wallet management system financial institution system POS device ATM representative hardware layer 904 is illustrated and can represent, for example, any of the above referenced computing devices. In some examples, thehardware layer 904 may be implemented according to thearchitecture 300 ofFIG. 3 and/or thearchitecture 1100 ofFIG. 11 . - The
representative hardware layer 904 comprises one ormore processing units 906 having associatedexecutable instructions 908.Executable instructions 908 represent the executable instructions of thesoftware architecture 902, including implementation of the methods, modules, components, and so forth ofFIGS. 1-2 and 4-8 .Hardware layer 904 also includes memory and/orstorage modules 910, which also haveexecutable instructions 908.Hardware layer 904 may also comprise other hardware as indicated byother hardware 912 which represents any other hardware of thehardware layer 904, such as the other hardware illustrated as part ofhardware architecture 1100. - In the example architecture of
FIG. 10 , thesoftware 902 may be conceptualized as a stack of layers where each layer provides particular functionality. For example, thesoftware 902 may include layers such as anoperating system 914,libraries 916, frameworks/middleware 918,applications 920 andpresentation layer 944. Operationally, theapplications 920 and/or other components within the layers may invoke application programming interface (API) calls 924 through the software stack and receive a response, returned values, and so forth illustrated as messages 926 in response to the API calls 924. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks /middleware layer 918, while others may provide such a layer. Other software architectures may include additional or different layers. - The
operating system 914 may manage hardware resources and provide common services. Theoperating system 914 may include, for example, akernel 928,services 930, anddrivers 932. Thekernel 928 may act as an abstraction layer between the hardware and the other software layers. For example, thekernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. Theservices 930 may provide other common services for the other software layers. Thedrivers 932 may be responsible for controlling or interfacing with the underlying hardware. For instance, thedrivers 932 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, NFC drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration. - The
libraries 916 may provide a common infrastructure that may be utilized by theapplications 920 and/or other components and/or layers. Thelibraries 916 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with theunderlying operating system 914 functionality (e.g.,kernel 928,services 930 and/or drivers 932). Thelibraries 916 may includesystem 934 libraries (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, thelibraries 916 may includeAPI libraries 936 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render 2D and 9D in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. Thelibraries 916 may also include a wide variety ofother libraries 938 to provide many other APIs to theapplications 920 and other software components/modules. - The frameworks 918 (also sometimes referred to as middleware) may provide a higher-level common infrastructure that may be utilized by the
applications 920 and/or other software components/modules. For example, theframeworks 918 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. Theframeworks 918 may provide a broad spectrum of other APIs that may be utilized by theapplications 920 and/or other software components/modules, some of which may be specific to a particular operating system or platform. - The
applications 920 includes built-inapplications 940 and/orthird party applications 942. Examples of representative built-inapplications 940 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application.Third party applications 942 may include any of the built in applications as well as a broad assortment of other applications. In a specific example, the third party application 942 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile computing device operating systems. In this example, thethird party application 942 may invoke the API calls 924 provided by the mobile operating system such asoperating system 914 to facilitate functionality described herein. - The
applications 920 may utilize built in operating system functions (e.g.,kernel 928,services 930 and/or drivers 932), libraries (e.g.,system 934,APIs 936, and other libraries 938), frameworks /middleware 918 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems interactions with a user may occur through a presentation layer, such aspresentation layer 944. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user. - Some software architectures utilize virtual machines. For example, the
wallet manager system 104 and/orfinancial institution systems 106 may be executed on one or more virtual machines executed at one or more server computing machines. In the example ofFIG. 10 , this is illustrated byvirtual machine 948. A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware computing device. A virtual machine is hosted by a host operating system (operating system 914) and typically, although not always, has avirtual machine monitor 946, which manages the operation of the virtual machine as well as the interface with the host operating system (i.e., operating system 914). A software architecture executes within the virtual machine such as anoperating system 950,libraries 952, frameworks /middleware 954,applications 956 and/orpresentation layer 958. These layers of software architecture executing within thevirtual machine 948 can be the same as corresponding layers previously described or may be different. -
FIG. 11 is a block diagram illustrating a computingdevice hardware architecture 1100, within which a set or sequence of instructions can be executed to cause the machine to perform examples of any one of the methodologies discussed herein. For example, thearchitecture 1100 may execute thesoftware architecture 902 described with respect toFIG. 10 . Thearchitecture 1100 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, thearchitecture 1100 may operate in the capacity of either a server or a client machine in server-client network environments, or it may act as a peer machine in peer-to-peer (or distributed) network environments. Thearchitecture 1100 can be implemented in a personal computer (PC), a tablet PC, a hybrid tablet, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. -
Example architecture 1100 includes aprocessor unit 1102 comprising at least one processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.). Thearchitecture 1100 may further comprise amain memory 1104 and astatic memory 1106, which communicate with each other via a link 1108 (e.g., bus). Thearchitecture 1100 can further include avideo display unit 1110, an alphanumeric input device 1112 (e.g., a keyboard), and a user interface (UI) navigation device 1114 (e.g., a mouse). In some examples, thevideo display unit 1110,input device 1112 andUI navigation device 1114 are incorporated into a touch screen display. Thearchitecture 1100 may additionally include a storage device 1116 (e.g., a drive unit), a signal generation device 1118 (e.g., a speaker), anetwork interface device 1120, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. - The
storage device 1116 includes a machine-readable medium 1122 on which is stored one or more sets of data structures and instructions 1124 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. Theinstructions 1124 can also reside, completely or at least partially, within themain memory 1104,static memory 1106, and/or within theprocessor 1102 during execution thereof by thearchitecture 1100, with themain memory 1104,static memory 1106, and theprocessor 1102 also constituting machine-readable media. Instructions stored at the machine-readable medium 1122 may include, for example, instructions for implementing thesoftware architecture 902, instructions for executing any of the features described herein, etc. - While the machine-
readable medium 1122 is illustrated in an example to be a single medium, the term “machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one ormore instructions 1124. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including, but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. - The
instructions 1124 can further be transmitted or received over acommunications network 1126 using a transmission medium via thenetwork interface device 1120 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi, 3G, and 6G LTE/LTE-A or WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software. - Various components are described in the present disclosure as being configured in a particular way. A component may be configured in any suitable manner. For example, a component that is or that includes a computing device may be configured with suitable software instructions that program the computing device. A component may also be configured by virtue of its hardware arrangement or in any other suitable manner.
- The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) can be used in combination with others. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure, for example, to comply with 37 C.F.R. §1.72(b) in the United States of America. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
- Also, in the above Detailed Description, various features can be grouped together to streamline the disclosure. However, the claims cannot set forth every feature disclosed herein as embodiments can feature a subset of said features. Further, embodiments can include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
Claims (20)
1. A method comprising:
receiving, by a first computing device, a first access request message, wherein the first computing device comprises at least one processor and a memory in communication with the at least one processor;
sending, by the first computing device and to a server system, a transaction request message requesting a transaction to an account associated with a second computing device;
receiving, by the first computing device and from the server system, transaction data indicating that the transaction is completed; and
sending, by the first computing device and to the second computing device, a transaction summary message comprising transaction summary data describing the transaction.
2. The method of claim 1 , wherein the transaction comprises a debit of a transaction amount to the account and a credit of the transaction amount to the account.
3. The method of claim 1 , wherein the transaction data indicates that the first computing device has authorized the transaction.
4. The method of claim 1 , wherein the transaction data indicates that a second computing device associated with a user of the first computing device has authorized the transaction.
5. The method of claim 1 , wherein the transaction data comprises timestamp data indicating a time associated with the transaction.
6. The method of claim 1 , wherein the first computing device is an automated teller machine (ATM).
7. The method of claim 1 , further comprising determining, by the first computing device, that the first access request message includes a request for the transaction.
8. The method of claim 1 , further comprising:
querying, by the first computing device, a financial institution system; and
receiving, from the financial institution system, an indication that the transaction should be requested.
9. The method of claim 1 , further comprising verifying, by the first computing device, a block chain of the second computing device, wherein the block chain comprises a plurality of transactions including the second computing device.
10. A system comprising:
a first computing device comprising at least one processor programmed to perform operations comprising:
receiving a first access request message, wherein the first computing device comprises at least one processor and a memory in communication with the at least one processor;
sending, to a server system, a transaction request message requesting a transaction to an account associated with a second computing device;
receiving, from the server system, transaction data indicating that the transaction is completed; and
sending, to the second computing device, a transaction summary message comprising transaction summary data describing the transaction.
11. The system of claim 10 , wherein the transaction comprises a debit of a transaction amount to the account and a credit of the transaction amount to the account.
12. The system of claim 10 , wherein the transaction data indicates that the first computing device has authorized the transaction.
13. The system of claim 10 , wherein the transaction data indicates that a second computing device associated with a user of the first computing device has authorized the transaction.
14. The system of claim 10 , wherein the transaction data comprises timestamp data indicating a time associated with the transaction.
15. The system of claim 10 , wherein the first computing device is an automated teller machine (ATM).
16. The system of claim 10 , the operations further comprising determining that the first access request message includes a request for the transaction.
17. The system of claim 10 , the operations further comprising:
querying a financial institution system; and
receiving, from the financial institution system, an indication that the transaction should be requested.
18. The system of claim 10 , the operations further comprising verifying a block chain of the second computing device, wherein the block chain comprises a plurality of transactions including the second computing device.
19. A non-transitory machine-readable medium comprising instructions thereon that, when executed by a first computing device, cause the first computing device to perform operations comprising:
receiving a first access request message, wherein the first computing device comprises at least one processor and a memory in communication with the at least one processor;
sending, to a server system, a transaction request message requesting a transaction to an account associated with a second computing device;
receiving, from the server system, transaction data indicating that the transaction is completed; and
sending, to the second computing device, a transaction summary message comprising transaction summary data describing the transaction.
20. The non-transitory machine-readable medium of claim 19 , wherein the transaction comprises a debit of a transaction amount to the account and a credit of the transaction amount to the account.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/295,989 US20230237490A1 (en) | 2016-06-13 | 2023-04-05 | Authentication transaction |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/180,711 US10762505B1 (en) | 2016-06-13 | 2016-06-13 | Authentication transaction |
US17/006,183 US11694203B1 (en) | 2016-06-13 | 2020-08-28 | Authentication transaction |
US18/295,989 US20230237490A1 (en) | 2016-06-13 | 2023-04-05 | Authentication transaction |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/006,183 Division US11694203B1 (en) | 2016-06-13 | 2020-08-28 | Authentication transaction |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230237490A1 true US20230237490A1 (en) | 2023-07-27 |
Family
ID=72241776
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/180,711 Active 2037-12-15 US10762505B1 (en) | 2016-06-13 | 2016-06-13 | Authentication transaction |
US17/006,183 Active 2036-12-02 US11694203B1 (en) | 2016-06-13 | 2020-08-28 | Authentication transaction |
US18/295,989 Pending US20230237490A1 (en) | 2016-06-13 | 2023-04-05 | Authentication transaction |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/180,711 Active 2037-12-15 US10762505B1 (en) | 2016-06-13 | 2016-06-13 | Authentication transaction |
US17/006,183 Active 2036-12-02 US11694203B1 (en) | 2016-06-13 | 2020-08-28 | Authentication transaction |
Country Status (1)
Country | Link |
---|---|
US (3) | US10762505B1 (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10762505B1 (en) | 2016-06-13 | 2020-09-01 | Wells Fargo Bank, N.A. | Authentication transaction |
US20200153793A1 (en) * | 2017-08-03 | 2020-05-14 | Liquineq AG | Security gateway for high security blockchain systems |
SE542530C2 (en) * | 2017-11-02 | 2020-06-02 | Crunchfish Proximity Ab C/O Crunchfish Ab | Mobile identification using thin client devices |
US11521187B2 (en) * | 2020-04-10 | 2022-12-06 | Ncr Corporation | Wireless device for retrofitting ATMs |
US20210326836A1 (en) * | 2020-04-20 | 2021-10-21 | Wells Fargo Bank, N.A. | Computerized payments for transaction authorization |
Family Cites Families (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7996888B2 (en) | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
EP1769457A4 (en) | 2004-06-25 | 2011-11-02 | Heartland Payment Systems Inc | Payment processing method and system |
US20150020162A1 (en) | 2005-04-26 | 2015-01-15 | Guy Hefetz | Methods for acquiring an internet user's consent to be located |
US8073774B2 (en) | 2005-06-06 | 2011-12-06 | Sms.Ac, Inc. | Billing system and method for micro-transactions |
US7512567B2 (en) * | 2006-06-29 | 2009-03-31 | Yt Acquisition Corporation | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
US20080233918A1 (en) | 2006-09-25 | 2008-09-25 | Sms.Ac | Content owner verification and digital rights management for automated distribution and billing platforms |
JO2532B1 (en) | 2008-03-09 | 2010-09-05 | أنس محمود السهلي محمود | Subscriber Identity Module (SIM) Chip Bank System and Method |
US8301500B2 (en) | 2008-04-02 | 2012-10-30 | Global 1 Enterprises | Ghosting payment account data in a mobile telephone payment transaction system |
US8548428B2 (en) | 2009-01-28 | 2013-10-01 | Headwater Partners I Llc | Device group partitions and settlement platform |
US20100153274A1 (en) | 2008-12-16 | 2010-06-17 | Palo Alto Research Center Incorporated | Method and apparatus for mutual authentication using small payments |
US10255419B1 (en) | 2009-06-03 | 2019-04-09 | James F. Kragh | Identity validation and verification system and associated methods |
CN105407100A (en) | 2010-09-24 | 2016-03-16 | 维萨国际服务协会 | Method And System Using Universal Id And Biometrics |
US20120084203A1 (en) * | 2010-09-30 | 2012-04-05 | The Western Union Company | System and method for secure transactions using device-related fingerprints |
US20120101951A1 (en) | 2010-10-22 | 2012-04-26 | Michael Li | Method and System for Secure Financial Transactions Using Mobile Communications Devices |
US9064257B2 (en) | 2010-11-02 | 2015-06-23 | Homayoon Beigi | Mobile device transaction using multi-factor authentication |
US8831677B2 (en) | 2010-11-17 | 2014-09-09 | Antony-Euclid C. Villa-Real | Customer-controlled instant-response anti-fraud/anti-identity theft devices (with true-personal identity verification), method and systems for secured global applications in personal/business e-banking, e-commerce, e-medical/health insurance checker, e-education/research/invention, e-disaster advisor, e-immigration, e-airport/aircraft security, e-military/e-law enforcement, with or without NFC component and system, with cellular/satellite phone/internet/multi-media functions |
US8352749B2 (en) | 2010-12-17 | 2013-01-08 | Google Inc. | Local trusted services manager for a contactless smart card |
KR101825534B1 (en) | 2011-02-07 | 2018-02-06 | 삼성전자주식회사 | Three Dimensional Semiconductor Memory Device |
US20120209749A1 (en) | 2011-02-16 | 2012-08-16 | Ayman Hammad | Snap mobile payment apparatuses, methods and systems |
US9883387B2 (en) * | 2011-03-24 | 2018-01-30 | Visa International Service Association | Authentication using application authentication element |
US8864022B2 (en) | 2011-05-19 | 2014-10-21 | Bank Of America Corporation | Authentication strategies for remote financial institution services |
US8478990B2 (en) | 2011-06-02 | 2013-07-02 | Cryptite LLC | Mobile transaction methods and devices with three-dimensional colorgram tokens |
US8868902B1 (en) | 2013-07-01 | 2014-10-21 | Cryptite LLC | Characteristically shaped colorgram tokens in mobile transactions |
WO2012174427A2 (en) | 2011-06-16 | 2012-12-20 | OneID Inc. | Method and system for determining authentication levels in transactions |
US8838982B2 (en) | 2011-09-21 | 2014-09-16 | Visa International Service Association | Systems and methods to secure user identification |
US20150379510A1 (en) | 2012-07-10 | 2015-12-31 | Stanley Benjamin Smith | Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain. |
US10192216B2 (en) | 2012-09-11 | 2019-01-29 | Visa International Service Association | Cloud-based virtual wallet NFC apparatuses, methods and systems |
US20160019536A1 (en) | 2012-10-17 | 2016-01-21 | Royal Bank Of Canada | Secure processing of data |
US20140129447A1 (en) | 2012-11-05 | 2014-05-08 | Netnumber, Inc. | System and method for anonymous micro-transactions |
US10270748B2 (en) | 2013-03-22 | 2019-04-23 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
US20160232515A1 (en) | 2013-09-20 | 2016-08-11 | Lucova Inc. | Systems and methods for facilitating mobile commerce interactions between customers and merchants |
US20150095238A1 (en) * | 2013-09-30 | 2015-04-02 | Apple Inc. | Online payments using a secure element of an electronic device |
US10902423B2 (en) * | 2014-09-29 | 2021-01-26 | Mastercard International Incorporated | Method and apparatus for streamlined digital wallet transactions |
US20160125412A1 (en) | 2014-11-05 | 2016-05-05 | Royce E. Cannon | Method and system for preventing identity theft and increasing security on all systems |
US9558493B2 (en) | 2014-11-12 | 2017-01-31 | BenedorTSE LLC | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US10614457B2 (en) | 2014-11-12 | 2020-04-07 | BenedorTSE LLC | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction |
US10990965B2 (en) * | 2014-12-23 | 2021-04-27 | Visa International Service Association | Single sign-on using a secure authentication system |
US11354651B2 (en) | 2015-01-19 | 2022-06-07 | Royal Bank Of Canada | System and method for location-based token transaction processing |
US20160321721A1 (en) | 2015-04-30 | 2016-11-03 | Adam Stein | Systems and methods for anonymized transparent exchange of information |
US20160342989A1 (en) * | 2015-05-21 | 2016-11-24 | Mastercard International Incorporated | Method and system for processing blockchain-based transactions on existing payment networks |
US9940637B2 (en) * | 2015-06-05 | 2018-04-10 | Apple Inc. | User interface for loyalty accounts and private label accounts |
US10387881B2 (en) | 2015-10-02 | 2019-08-20 | Chicago Mercantile Exchange Inc. | Virtual payment processing system |
US20170178124A1 (en) | 2015-12-18 | 2017-06-22 | Facebook, Inc. | Processing secure electronic payment transactions |
US10046228B2 (en) | 2016-05-02 | 2018-08-14 | Bao Tran | Smart device |
US10762505B1 (en) | 2016-06-13 | 2020-09-01 | Wells Fargo Bank, N.A. | Authentication transaction |
EP3583572A4 (en) | 2017-02-15 | 2020-11-25 | Humetrix | Patent-facing mobile technology to assist physician achieve quality measures for value-based payment |
US11157295B2 (en) | 2018-01-02 | 2021-10-26 | Patrick Schur | System and method for providing intelligent operant operating interface and intelligent personal assistant as a service on a crypto secure social media and cross bridge service with continuous prosumer validation based on i-operant+198 tags, i-bubble+198 tags, demojis+198 and demoticons+198 |
US20210326836A1 (en) | 2020-04-20 | 2021-10-21 | Wells Fargo Bank, N.A. | Computerized payments for transaction authorization |
-
2016
- 2016-06-13 US US15/180,711 patent/US10762505B1/en active Active
-
2020
- 2020-08-28 US US17/006,183 patent/US11694203B1/en active Active
-
2023
- 2023-04-05 US US18/295,989 patent/US20230237490A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US10762505B1 (en) | 2020-09-01 |
US11694203B1 (en) | 2023-07-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11106476B2 (en) | Helper software developer kit for native device hybrid applications | |
US20220253826A1 (en) | Systems and methods for configuring a mobile device to automatically initiate payments | |
US11694203B1 (en) | Authentication transaction | |
US11645637B2 (en) | Systems and methods for payment processing on platforms | |
US11663564B1 (en) | Creating and managing private electronic currency | |
US11416834B2 (en) | System and method for third party payment at point of sale terminals | |
US20140279403A1 (en) | Methods and systems for executing mobile currency transactions | |
US20140129448A1 (en) | Cloud-based systems and methods for providing consumer financial data | |
US11682022B1 (en) | Mobile wallet application with payment receipt support | |
US11847656B1 (en) | Fraud prevention tool | |
US20240104550A1 (en) | Mobile wallet with offline payment | |
US11580530B1 (en) | Direct payment authorization path | |
US20210326836A1 (en) | Computerized payments for transaction authorization | |
US10776777B1 (en) | Consolidating application access in a mobile wallet | |
US10984409B1 (en) | Secure elements for mobile wallet applications | |
US10776787B2 (en) | Systems and methods for providing notification services using a digital wallet platform | |
US11792009B2 (en) | Electronic system for generation of authentication tokens using biometric data | |
US20230281608A1 (en) | Processing purchase with authorization token | |
US20240086917A1 (en) | Fraud mitigation using pre-authorization authentication and verification | |
US11558370B2 (en) | Electronic system for generation of authentication tokens using digital footprint | |
US20220300973A1 (en) | Methods and systems for authentication for remote transactions | |
US20210390529A1 (en) | Systems and methods for performing payment transactions using indicia-based associations between user interfaces | |
EP4113410A1 (en) | Enabling a function of an application based on a characteristic of a user device | |
US11113758B1 (en) | User interface for document imaging | |
CN117882073A (en) | Mobile device data security using shared security values |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: WELLS FARGO BANK, N.A., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MORRIS, TIMOTHY H;SMITH, LYNN A;SIGNING DATES FROM 20161003 TO 20171219;REEL/FRAME:063312/0021 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |