Systems and methods for detected-capability-based authentication of a mobile device for performing an access operation with a local device

Information

  • Patent Grant
  • 12356184
  • Patent Number
    12,356,184
  • Date Filed
    Friday, October 27, 2023
    2 years ago
  • Date Issued
    Tuesday, July 8, 2025
    5 months ago
Abstract
In some embodiments, based on a wireless signal of a mobile device (e.g., obtained by a local device) the mobile device and a first authentication capability of the mobile device may be detected. Based on the detection of the mobile device, the mobile device may present access initiation options on a user interface of the mobile device. Based on a selection of a first option of the access initiation options via the user interface to initiate an access request for an access operation with the local device, an authentication request may be generated, where the authentication request is associated with the first authentication capability and with a first authentication tier. For example, the authentication request may be generated based on (i) the first authentication capability being detected as an authentication capability of the mobile device and (ii) the first authentication tier corresponding to an access amount of the access request.
Description
SUMMARY

In some embodiments, based on a wireless signal of a mobile device (e.g., obtained by a local device) the mobile device and a first authentication capability of the mobile device may be detected. Based on the detection of the mobile device, presentation instructions may be transmitted to the mobile device to present access initiation options on a user interface of the mobile device. Based on a selection of a first option of the access initiation options via the user interface to initiate an access request for an access operation with the local device, an authentication request may be generated, where the authentication request is associated with the first authentication capability and with a first authentication tier. As an example, the authentication request may be generated based on (i) the first authentication capability being detected as an authentication capability of the mobile device and (ii) the first authentication tier corresponding to an access amount of the access request. In some embodiments, based on a detection of a fingerprint scanner being on the mobile device, a fingerprint authentication capability of the mobile device may be detected. Based on detecting the fingerprint authentication capability of the mobile device, the authentication request may be generated to include a prompt related to fingerprint scanning.


In some embodiments, in connection with the authentication request, authentication data (e.g., for completing the access operation with the local device) may be obtained from the mobile device. Based on the authentication data, access to the local device (e.g., for completing the access operation with the local device) may be granted. In some embodiments, based on the authentication data, dispensing instructions may be transmitted to the local device to dispense one or more items from within the local device to complete the access operation with the local device.


In some embodiments, the mobile device may be initially detected as being within a first predetermined distance of the local device (e.g., while the mobile device is not within a second predetermined distance of the local device), where the access initiation options are presented on the user interface of the mobile device based on the initial detection of the mobile device as being within the first predetermined distance. In some embodiments, the mobile device may be subsequently detected as being within the first and second predetermined distances of the local device. Based on the authentication data and the mobile device being detected as being within the first and second predetermined distances of the local device, the dispensing instructions may be transmitted to the local device to dispense one or more items from within the local device to complete the access operation with the local device.


It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the disclosed embodiments, as claimed. It should be understood that the disclosure, in its broadest sense, could be practiced without having one or more features of these aspects and embodiments.





BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the description, serve to explain the disclosed principles.



FIG. 1 is a block diagram of an exemplary system, consistent with disclosed embodiments;



FIG. 2 is a block diagram of an exemplary computer system, consistent with disclosed embodiments;



FIG. 3 is a flowchart of an exemplary process for detecting and identifying a customer with a user device, consistent with disclosed embodiments;



FIG. 4 is a flowchart of an exemplary process for an alternative embodiment for detecting and identifying a customer with a user device, consistent with disclosed embodiments;



FIG. 5 is a flowchart of an exemplary process for detecting and identifying a customer with a user device, consistent with disclosed embodiments;



FIG. 6 is a flowchart of an exemplary process for detecting and identifying a customer with a user device, consistent with disclosed embodiments;



FIG. 7 is a flowchart of an exemplary process for an alternative embodiment for detecting and identifying a customer with a user device, consistent with disclosed embodiments;



FIG. 8 is a flowchart of an exemplary process for detecting and identifying a recipient of a money transfer with a user device, consistent with disclosed embodiments;



FIG. 9 is a flowchart of an exemplary process for authenticating a financial transaction, consistent with disclosed embodiments;



FIG. 10 is a flowchart of an exemplary process for authenticating a financial transaction in a multi-tiered authentication system, consistent with disclosed embodiments;



FIG. 11 is a flowchart of an exemplary process for authenticating a particular tier in a multi-tiered authentication system, consistent with disclosed embodiments;



FIG. 12 is a flowchart of an exemplary process for authenticating a financial transaction when customer data is held by a third party, consistent with disclosed embodiments;



FIG. 13 is a flowchart of an exemplary multi-tiered authentication process relating to an ATM withdrawal transaction, consistent with disclosed embodiments;



FIG. 14 is a flowchart of an exemplary process for making a deposit, consistent with the disclosed embodiments;



FIG. 15 is a flowchart of an exemplary process for placing an order for certified funds, consistent with the disclosed embodiments;



FIG. 16 is a flowchart of an exemplary process for ordering a new or reissue debit card, consistent with the disclosed embodiments; and



FIG. 17 is a flowchart of an exemplary process for submitting a change order, consistent with the disclosed embodiments.





DETAILED DESCRIPTION

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings and disclosed herein. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.



FIG. 1 shows a diagram of an exemplary system 100, consistent with disclosed embodiments. As shown in FIG. 1, system 100 may include a user device 110, a financial service provider device 120 (or device 120), a local financial service provider device 130 (or device 130), and a network 140 to facilitate communication among the components of system 100 may vary. Thus, system 100 may further include other components that perform or assist in the performance of one or more processes consistent with the disclosed embodiments. The components and arrangements shown in FIG. 1 are not intended to limit the disclosed embodiments, as the components used to implement the disclosed processes and features may vary.


In accordance with disclosed embodiments, a detection and identification system 100 may include device 120. Device 120 may be a system associated with a financial service provider (not shown), such as a bank, a credit card company, a lender, brokerage firm, or any other type of financial service entity that generates, provides, manages, and maintains financial service accounts, etc., for one or more users. Device 120 may be one or more computing systems that are configured to execute software instructions stored on one or more memory devices to perform one or more operations consistent with the disclosed embodiments. For example, device 120 may include one or more memory device(s) storing data and software instructions, and one or more processor(s) configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art. Device 120 may include one or more general purpose computers, mainframe computers, or any combination of these types of components.


In certain embodiments, device 120 may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that cause a processor to perform one or more operations consistent with the disclosed embodiments. Device 120 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example, device 120 may represent distributed servers that are remotely located and communicate over a public network (e.g., network 140) or a dedicated network, such as a LAN, for a financial service provider. An exemplary computing system consistent with device 120 is discussed in additional detail with respect to FIG. 2, below.


Device 120 may include or may access one or more storage devices configured to store data and/or software instructions used by one or more processors of device 120 to perform operations consistent with disclosed embodiments. For example, device 120 may include memory 230 configured to store one or more software programs that performs several functions when executed by a processor. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, device 120 may include memory that stores a single program or multiple programs. Additionally, device 120 may execute one or more programs located remotely from device 120. For example, device 120 may access one or more remote programs stored in memory included with a remote component that, when executed, perform operations consistent with the disclosed embodiments. In certain aspects, device 120 may include server software that generates, maintains, and provides services associated with financial account management. In other aspects, device 120 may connect separate server(s) or similar computing devices that generate, maintain, and provide services associated with financial data for a financial service provider associated with device 120.


System 100 may also include one or more local devices 130. Local devices may include, for example, ATMs or detection devices in local FSP branches. Local device 130 may include one or more memory device(s) that store data that may be used for performing one or more processes consistent with the disclosed embodiments. For example, local device 130 may include one or more memory device(s) storing data and software instructions, and one or more processor(s) configured to use the data and execute the software instructions to perform computing functions and operations known to those skilled in the art. In certain aspects, local device 130 may additionally, or alternatively, include one or more servers or other types of computer devices, which may be configured to execute software instructions stored in memory to perform one or more processes consistent with the disclosed embodiments.


Local device 130 may further include server(s) that are configured to execute stored software instructions to perform operations associated with collecting, storing, and accessing biometric data, including one or more processes associated with gathering biometric data from a variety of sources, compiling the data, and organizing the data into easily accessible profiles. Local device 130 may include one or more servers that may be a general-purpose computer, a mainframe computer, or any combination of these components. In certain embodiments, local device 130 (or a system including local device 130) may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that cause a processor to perform one or more operations consistent with the disclosed embodiments. A local device 130 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example, local device 130 may represent distributed servers that are remotely located and communicate over a public network (e.g., network 140) or a dedicated network, such as a LAN. An exemplary computer system consistent with local device 130 is discussed in additional detail with respect to FIG. 2. In certain embodiments, a third party may operate the components associated with local device 130. Additionally or alternatively, local device 130 may be a part or subpart of device 120.


System 100 may further include one or more user devices 110. A user may operate a user device 110, which may be a desktop computer, laptop, tablet, smartphone, multifunctional watch, pair of multifunctional glasses, tracking device, or any suitable device with computing capability. User device 110 may include one or more processor(s) and memory device(s) known to those skilled in the art. For example, user device 110 may include memory device(s) that store data and software instructions that, when executed by one or more processor(s), perform operations consistent with the disclosed embodiments. In one aspect, user device 110 may have a financial application installed thereon, which may enable user device 110 to communicate with device 120 via network 140. For instance, user device 110 may be a smartphone or tablet or the like that executes a stored mobile application that performs online banking operations. In other embodiments, user device 110 may connect to device 120 through use of browser software stored and executed by user device 110. User device 110 may be configured to execute software instructions to allow a user to access information stored in device 120, such as, for example, financial information related to recent purchase transactions, financial discounts, financial statements, account information, rewards program information and the like. Additionally, user device 110 may be configured to execute software instructions that initiate and conduct transactions with device 120, such as, for example, ATM withdrawals, wire transfers, debit card PIN resets, and call center transactions. An exemplary computer system consistent with user device 110 is discussed in additional detail with respect to FIG. 2.


A user may operate user device 110 to perform one or more operations consistent with the disclosed embodiments. In one aspect, a user may be a customer of a financial service provider. For instance, a financial service provider may maintain a financial service account (e.g., checking account, savings account, debit card account, or credit card account) for the user that the user may use to purchase goods and/or services. Additionally or alternatively, the user may use user device 110 and the financial service account (for example, through a mobile application installed on user device 110) to withdraw cash from an ATM, contact a customer call center, transfer or wire money, or reset their debit account PIN.


A user may further operate user device 110 in order to be detected and recognized by local device 130. For example, user device 110 may detect, through the use of network 140, a local device 130 in its immediate proximity. Additionally or alternatively, local device 130 may detect user device 110 in its immediate proximity. User device 110 may then connect to local device 130 in order to initiate, conduct, or complete a financial transaction without the need for the user to interface directly with Device 130.


System 100 may also include one or more biometric databases 150. Biometric database 150 may include one or more memory device(s) that store data that may be used for performing one or more processes consistent with the disclosed embodiment. In certain aspects, biometric database 150 may additionally, or alternatively, include one or more servers or other types of computer devices. The biometric database 150 may include one or more server(s), which may be one or more computing devices configured to execute software instructions stored in memory to perform one or more processes consistent with the disclosed embodiments. For example, biometric database 150 may include one or more memory device(s) storing data and software instructions, and one or more processor(s) configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art.


Biometric database 150 may further include server(s) that are configured to execute stored software instructions to perform operations associated with collecting, storing, and accessing biometric data, including one or more processes associated with gathering biometric data from a variety of sources, compiling the data, and organizing the data into easily accessible profiles. Biometric database 150 may include one or more servers that may be a general-purpose computer, a mainframe computer, or any combination of these components. In certain embodiments, biometric database 150 (or a system including biometric database 150) may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with the disclosed embodiments. A biometric database 150 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example, biometric database 150 may represent distributed servers that are remotely located and communicate over a public network (e.g., network 140) or a dedicated network, such as a LAN. An exemplary computer system consistent with biometric database 150 is discussed in additional detail with respect to FIG. 2.


In certain embodiments, biometric database 150 may be associated with an entity, such as a company, organization, agency, etc. In some embodiments, the biometric database entity may be a different entity than a financial service provider associated with device 120. In certain aspects, a user or user(s) affiliated with a biometric database entity may operate one or more components associated with biometric database 150 to collect and maintain biometric data. In other embodiments, biometric database 150 may be associated with a financial service provider or other entity associated with device 120. For example, biometric database 150 may be a part or subpart of device 120.


Network 140 may comprise any type of computer networking arrangement used to exchange data. For example, network 140 may be the Internet, a private data network, a virtual private network using a public network, a Wi-Fi network, a LAN or WAN network, and/or other suitable connections that may enable information exchange among various components of the system 100. Network 140 may also include a public switched telephone network (“PSTN”) and/or a wireless cellular network. Network 140 may be a secured network or unsecured network. In other embodiments, one or more components of system 100 may communicate directly through a dedicated communication link(s), such as links between user device 110, device 120, and local device 130.


Additionally or alternatively, network 140 may include a direct communication network. Direct communications may use any suitable technologies, including, for example, BLUETOOTH™, BLUETOOTH LE™ (BLE), Wi-Fi, near field communications (NFC), or other suitable communication methods that provide a medium for transmitting data between separate devices. In certain embodiments, user device 110 and local device 130 may connect and communicate through a direct communications network.


Other components known to one of ordinary skill in the art may be included in system 100 to process, transmit, provide, and receive information consistent with the disclosed embodiments.


In the context of ATMs, although mobile applications exist, certain transactions still require human intervention or human interface with a machine, such as an ATM. For example, typical cash withdrawal systems require human interface with the ATM or teller. Requiring that certain transactions be conducted in person with a representative of a financial account provider at the physical location of the transaction creates an inconvenience for the customer, who would prefer to initiate and authorize these transactions remotely and without having to take time to provide additional information on a machine or to a teller or to carry additional cards or account information.


Current mechanisms for identifying a customer vary by channel (mobile, online, in person), requiring the customer to remember his or her credentials for each distinct channel. For example, a customer may be required to remember a username and password, social security number, account number, and ATM Pin number, depending on the channel they use to conduct financial transactions. Additionally, customers may be required to carry with them debit or ATM cards.


Further, some typical identification systems are unappealing to customers who would like to conduct private transactions in a private location. For example, allowing a customer to initiate an ATM withdrawal using a smartphone, tablet or computer from a private location (such as their own home, office, car, etc.), rather than requiring him or her to enter their information at a public ATM, may allow the customer to feel more secure with their financial information. Further, allowing a customer to conduct a transaction without swiping a debit or ATM card allows the customer to avoid the risk of exposing his or her financial information to ATM skimmers or other fraudulent devices. Further, giving the customer the option of using the smaller screen of a smart phone or tablet allows the customer to feel secure that the smaller form factor of the smartphone or tablet allows them to keep their personal information (account number, pin, balances, types of accounts) private from other people “looking over their shoulder” when it is displayed on the ATM screen.


The above elements may allow customers to feel safer, as they are required to spend less time at an ATM while conducting financial transactions. For example, because customers are required to conduct less physical interaction at the ATM (e.g., no card swipe, no pin entry, no selection of account and amount, etc.), the time the customer is at the ATM is greatly reduced. This may give the customer a greater sense of physical security. It may also reduce the customer's chance of being robbed after getting cash, which for some customers is a severe and legitimate concern.


As described herein, some embodiments provide systems and methods for enabling a customer to send cash from his or her account to another customer or even to someone who is not a customer. For example, certain embodiments may allow a customer to enter the phone number or email of a recipient, and initiate a message to the owner of the phone or email account informing them that they have cash and that they can go to an ATM to withdraw that cash. When arriving at the ATM, and once identified by the ATM, the recipient may receive another message with a one-time pin that will be deactivated in a specified time frame. The recipient can use that one time pin to retrieve the cash from the ATM. Additionally or alternatively, BLE beacons, NFC, or a unique high pitch frequency that the microphone on the smartphone would detect, or some other type of sensor that can associate the ATM device with the mobile device, may be used in lieu of a one-time pin to authenticate the mobile device at the ATM. Certain aspects of the disclosed embodiments may attract new customers and encourage current customers to use the financial service provider's accounts and services more often.


Some embodiments provide improved systems and methods for detecting and identifying a customer with a mobile device conducting a financial transaction. For example, some embodiments may enable customers to conduct a broader range of financial transactions through mobile channels, such as a mobile application on a mobile device, without having to physically enter information on a machine or provide the information to an individual such as a teller. Certain disclosed embodiments may provide services that are valuable to both consumers and financial service providers. For example, aspects of the disclosed embodiments may provide a user with a process for conducting financial transactions from a mobile channel without the need to physically enter the financial information to a machine or teller, which may save time and effort for the user and limit the exposure of customer data and personal information. Moreover, certain aspects of the disclosed embodiments may attract new customers and encourage current customers to use the financial service provider's accounts and services more often.



FIG. 2 shows a diagram of an exemplary computing system 200 illustrating a computing system configuration that may be associated with device 120, local device 130, biometric database 150, and/or user device 110, consistent with disclosed embodiments. In some embodiments, computing system 200 may include one or more processors 210, one or more memories 230, and one or more input/output (I/O) devices 220. In some embodiments, computing system 200 may take the form of a server, general purpose computer, a mainframe computer, laptop, smartphone, mobile device, or any combination of these components. In certain embodiments, computing system 200 (or a system including computing system 200) may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that cause a processor to perform one or more operations consistent with the disclosed embodiments. Computing system 200 may be standalone, or it may be part of a subsystem, which may be part of a larger system.


Processor 210 may include one or more known processing devices, such as a microprocessor from the Pentium™ or Xeon™ family manufactured by Intel™, the Turion™ family manufactured by AMO™, or any of various processors manufactured by Sun Microsystems. Processor 210 may constitute a single core or multiple core processor that executes parallel processes simultaneously. For example, processor 210 may be a single core processor configured with virtual processing technologies. In certain embodiments, processor 210 may use logical processors to simultaneously execute and control multiple processes. Processor 210 may implement virtual machine technologies, or other known technologies to provide the ability to execute, control, run, manipulate, store, etc., multiple software processes, applications, programs, etc. In another embodiment, processor 210 may include a multiple-core processor arrangement (e.g., dual, quad core, etc.) configured to provide parallel processing functionalities to allow computing system 200 to execute multiple processes simultaneously. One of ordinary skill in the art would understand that other types of processor arrangements could be implemented that provide for the capabilities disclosed herein. The disclosed embodiments are not limited to any type of processor(s) configured in computing system 200.


Memory 230 may include one or more storage devices configured to store instructions used by processor 210 to perform functions related to the disclosed embodiments. For example, memory 230 may be configured with one or more software instructions, such as program(s) 236 that may perform one or more operations when executed by processor 210. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory 230 may include a program 236 that performs the functions of computing system 200, or program 236 could comprise multiple programs. Additionally, processor 210 may execute one or more programs located remotely from computing system 200. For example, device 120, biometric database 150, or user device 110, may, via computing system 200 (or variants thereof), access one or more remote programs that, when executed, perform functions related to certain disclosed embodiments. Processor 210 may further execute one or more programs located in database 240. In some embodiments, programs 236 may be stored in an external storage device, such as a cloud server located outside of computing system 200, and processor 210 may execute programs 236 remotely.


Programs executed by processor 210 may cause processor 210 to execute one or more processes related to financial services provided to users including, but not limited to, processing credit and debit card transactions, checking transactions, fund deposits and withdrawals, transferring money between financial accounts, lending loans, processing payments for credit card and loan accounts, processing orders for certified funds, processing orders for new or reissue debit cards, and processing ATM cash withdrawals.


Memory 230 may also store data that may reflect any type of information in any format that the system may use to perform operations consistent with the disclosed embodiments. Memory 230 may store instructions to enable processor 210 to execute one or more applications, such as server applications, an authentication application, network communication processes, and any other type of application or software. Alternatively, the instructions, application programs, etc., may be stored in an external storage (not shown) in communication with computing system 200 via network 140 or any other suitable network. Memory 230 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium.


Memory 230 may include transaction data 232. Transaction data 232 may include information related to financial transactions initiated by a user. For example, transaction data may include a user identifier and a transaction type. The user identifier may be a credit or debit card number, an account number, or another means for identifying the user initiating the financial transaction. The transaction type may include an indicator of the type of transaction the user is initiating, such as, ATM cash withdrawal, debit PIN reset, money wire or transfer, call to the customer service center, ordering a new or reissue debit card, ordering certified funds, or other transactions requiring user authentication. Transaction data 232 may also include authentication data obtained from the user for the purposes of authorizing the transaction, for example, by verifying the authenticity of provided biometric data as compared to stored biometric data. Additionally or alternatively, transaction data 232 may be stored in database 240 or in an external storage (not shown) in communication with computing system 200 via network 140 or any other suitable network.


Memory 230 may further include customer data 234. Customer data 234 may include information about particular customers of the financial service provider. For example, client data 234 may include clients' account information, debit or credit card information, history of purchase transactions, financial statements, credit score, risk profile, username and password, debit card PIN, home and work locations, and/or biometric information. Additionally, customer data 234 may include user device identification information, such as, for example, a phone number, email address, IP address, BLUETOOTH™ signature, or other device identifier. Alternatively customer data 234 may be stored in database 240 or in an external storage (not shown) in communication with computing system 200 via network 140 or any other suitable network.


Processor 210 may analyze transaction data 232 in reference to customer data 234. For example, processor 210 may analyze transaction data to determine which client with information stored in client information 234 is initiating the financial transaction. Processor 210 may access the particular user's customer information to determine their account information, debit or credit card information, history of purchase transactions, financial statements, credit score, risk profile, username and password, debit card PIN, home and work locations, and/or authentication data.


I/O devices 220 may be one or more device that is configured to allow data to be received and/or transmitted by computing system 200. I/O devices 220 may include one or more digital and/or analog communication devices that allow computing system 200 to communicate with other machines and devices, such as other components of system 100 shown in FIG. 1. For example, computing system 200 may include interface components, which may provide interfaces to one or more input devices, such as one or more keyboards, mouse devices, and the like, which may enable computing system 200 to receive input from an operator of device 120 (not shown).


Computing system 200 may also contain one or more database(s) 240. Alternatively, computing system 200 may be communicatively connected to one or more database(s) 240. Computing system 200 may be communicatively connected to database(s) 240 through network 140. Database 240 may include one or more memory devices that store information and are accessed and/or managed through computing system 200. By way of example, database(s) 240 may include Oracle™ databases, Sybase™ databases, or other relational databases or non-relational databases, such as Hadoop sequence files, HBase, or Cassandra. The databases or other files may include, for example, data and information related to the source and destination of a network request and the data contained in the request, etc. Systems and methods of disclosed embodiments, however, are not limited to separate databases. Database 240 may include computing components (e.g., database management system, database server, etc.) configured to receive and process requests for data stored in memory devices of database(s) 240 and to provide data from database 240.


As discussed above, device 120 may include at least one computing system 200. Further, although sometimes discussed here in relation to device 120, it should be understood that variations of computing system 200 may be used by other components of system 100, including local device 130 and user device 110. Computing system 200 may be a single server or may be configured as a distributed computer system including multiple servers or computers that interoperate to perform one or more of the processes and functionalities associated with the disclosed embodiments.


In some aspects, local device 130 and/or user device 110 may include the same or similar configuration and/or components of computing system 200. For example, computing system 200, when implemented in local device 130, may include hardware and/or software installed therein for performing one or more processes disclosed herein.



FIG. 3 shows an exemplary detection and identification process, consistent with disclosed embodiments. Process 300 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 300 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 310, device 120 may receive transaction data. In one aspect, device 120 may receive transaction data from user device 110. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. The user device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, a user operating user device 110 may enter information requesting a monetary withdrawal of funds from a financial service account provided by a financial service provider (e.g., an entity associated with device 120), or additionally or alternatively may enter information requesting an alternative financial transaction, such as ordering certified funds, depositing money, and/or transferring funds. User device 110 may be configured to generate an interface to request transaction data from the user regarding the withdrawal. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments.


Transaction data may include a type of transaction and a customer identifier. A type of transaction may include, for example, an ATM withdrawal, a money transfer or wire, a debit card PIN reset, a deposit, a check cashing, ordering certified funds, ordering a new or reissued debit card, etc. If the type of transaction is, for example, an ATM withdrawal, money transfer or wire, deposit, ordering of certified funds or cashier's checks, a change order, or check cashing, transaction data may further include an amount. In certain embodiments, transaction data may include other data relating to transactions that is known to those skilled in the art, such as transaction amount, timestamp information, entity identifier, account identifier(s), etc.


In certain aspects, device 120 and/or local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., a customer) operating a mobile device is within a predetermined distance or range of distance(s) of local device 130 (e.g., step 320). For example, in certain aspects, local device 130 may determine whether a user (e.g., a customer) operating a mobile device is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting, through network 140 (Wi-Fi, BLE, NFC, etc.), user device 110. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Exemplary and non-limiting operations associated with detecting whether a user (or user device 110) is within a predetermined proximity of local device 130 is described below in connection with FIG. 5.


Device 120 and/or local device 130 may detect user device 110 within the necessary threshold proximity. In certain embodiments, local device 130 may receive authentication data from user device 110 (step 330). For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, heartbeat or pulse pattern, or palm vein scan.


At step 340, device 120 may authenticate and authorize the transaction. In some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130, via network 140, that the transaction has been authenticated and authorized. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data. Additional embodiments relating to authenticating and authorizing transactions are disclosed below.


At step 350, local device 130 may complete the transaction. Local device 130 may, for example, dispense cash from an ATM, indicate that a deposit has been successfully processed, notify a teller that the user has been authorized for a cash withdrawal, provide certified funds or cashier's checks, notify the customer that the new or replacement debit card has been ordered, complete the user's initiated transaction, and/or other operations. In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized).


As a non-limiting example of such embodiments, a user operating user device 110 may provide transaction data via user device 110. In some aspects, user device 110 may execute software that requests and receives transaction data (e.g., account withdrawal request including account number, amount, etc.) and provides the transaction data to local device 130 when communication between devices 110 and 130 has been established based on the proximity threshold determination processes disclosed herein.


Local device 130 may be configured to authenticate the transaction. In some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


Local device 130 may complete an authenticated transaction by, for example, automatically dispensing cash in the amount of the withdrawal request, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.).



FIG. 4 shows an alternative exemplary detection and identification process 400, consistent with disclosed embodiments. Process 400 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a tangible computer-readable medium storage device, such as a memory device. It is to be understood, however, that one or more steps of process 400 may be implemented by other components of system 100 (shown or now shown), including user device 110.


At step 410, as also discussed with reference to FIG. 3, device 120 and/or local device 130 may detect a user carrying a user device 110. In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting, through network 140 (Wi-Fi, BLE, NFC, etc.), user device 110. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Exemplary and non-limiting operations associated with detecting whether a user (or user device 110) is within a predetermined proximity of local device 130 is described below in connection with FIG. 5.


Alternatively, device 120 may detect a customer with user device 110. For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 with respect to local device 130.


At step 420, user device 110 may prompt the user to initiate a financial transaction. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction. For example, device 120 may generate and provide information that may be used in an interface that is displayed by user device 110 via a display device. Additionally or alternatively, local device 130 may transmit a signal to user device 110, for example, via BLE or NFC networks, indicating that user device 110 is within a threshold distance from local device 130. In some embodiments, user device 110 may display a prompt to the user. For example, the prompt may be a message displayed on user device 110. For example, the prompt may be an email, text message, message within a mobile application, or pop-up, among other things.


Alternatively, local device 130 may transmit a signal to device 120, which may then transmit a signal to user device 110 indicating that it is within a threshold distance of a local device 130. For example, user device 110 may be configured to detect local device 130. In certain embodiments, user device 110 operating a mobile application may locate and detect local device 130 via signals transmitted over for example, BLE or NFC networks. Device 120 may transmit a signal to user device 110 that may cause user device 110 to display a prompt to the user. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction. The prompt may be displayed within a mobile application running on user device 110. The prompt may contain, for example, a selection of possible transactions a user may initiate on user device 110.


At step 430, as also discussed with reference to FIG. 3, device 120 may receive transaction data from user device 110. User device 110 may be operating a mobile application associated with the financial service provider that transmits transaction data via network 140 to device 120. A user may enter and transmit transaction data into user device 110 manually per transaction, for example, by typing it on a keyboard or other input device (not shown). In certain embodiments, user device 110 may enter and transmit transaction data automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, a user device 110 may enter information requesting a monetary withdrawal of funds from a financial service account provided by a financial service provider (e.g., an entity associated with device 120), a deposit of funds into a financial service account provided by a financial service provider, or ordering certified funds from a financial service provider associated with a financial service account. User device 110 may be configured to generate an interface to request transaction data from the user regarding the withdrawal, deposit, or order. User device 110 may receive the user input of transaction data, and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments.


At step 440, device 120 and/or local device 130 may receive authentication data from user device 110. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, heartbeat or pulse pattern, or palm vein scan.


At step 450, device 120 may authenticate and authorize the transaction. In some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 may be determined by the amount of the transaction. For example, a higher transaction amount (e.g., withdrawal, deposit, ordering of certified funds) may require additional or more secure authentication data.


At step 460, device 120 and/or local device 130 may complete the transaction. For example device 120 may be configured to transmit a signal to local device 130 indicating that the transaction has been authenticated. Local device 130 may complete an authenticated transaction by, for example, automatically dispensing cash in the amount of the withdrawal request, automatically authorizing certified funds, and/or automatically ordering a new or reissued debit card, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.) or without requiring the user to enter a branch location. For example, in some embodiments, device 120 may generate and provide data to local device 130 that causes local device 130 to dispense cash in the amount of the withdrawal request. Local device 130 may, for example, dispense cash from an ATM, indicate that a deposit has been successfully processed, notify a teller that the user has been authorized for a cash withdrawal, authorize order for certified funds, notify the user that their order for a new or reissue debit card has been processed, or otherwise complete the user's initiated transaction.



FIG. 5 shows an exemplary detection and identification process 500, consistent with disclosed embodiments. Process 500 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 500 may be implemented by other components of system 100 (shown or not shown), including local device 130 and/or user device 110.


At step 510, device 120 and/or local device 130 may receive an identification signal transmitted by user device 110 that may, for example, identify a particular user device. For example, user device 110 may be configured to transmit an identification signal. In certain embodiments, user device 110 may be configured to transmit an identification signal when user device 110 is operating a mobile application associated with the financial service provider. For example, user device 110 may be configured to transmit an identification signal via BLE, NFC, Wi-Fi, or other appropriate networks. In some embodiments, local device 130 may be configured to detect an identification signal transmitted by user device 110 via, for example, BLE or NFC. Additionally or alternatively, local device 130 may detect an identification signal transmitted by user device 110 via Wi-Fi or any other suitable network, such as network 140. The identification signal may contain identification information such as device information pertaining to particular user device 110. In certain embodiments, the information signal may contain location information. For example, Device 130 may be configured to detect a location of user device 110 based on the information signal. In some embodiments, Device 130 may detect the distance between user device 110 and Device 130. Additionally or alternatively, the identification signal may contain customer identification data such as an account number, username, or other personal identifier.


In certain aspects device 120 may receive the identification signal. For example, user device 110 may transmit the identification signal to device 120. Additionally or alternatively, local device 130 may communicate with device 120, for example, via network 140 (step 520). For example, Device 130 may transmit the identification information received from user device 110 to device 120. Additionally or alternatively, user device 110 may connect directly to device 120 to transmit identification data.


Device 120 may be configured to identify one or more customer accounts based on the identification data (step 530). For example, the identification data may contain a customer identifier. A customer identifier may indicate a customer account stored on, for example, device 120, consistent with the disclosed embodiments, that corresponds to a particular customer. In one aspect, a customer account may relate to the particular user initiating a financial transaction. For example, a customer account may relate to a customer (user) operating user device 110 that provided the identification signal to local device 130. Device 120 may be configured to authenticate the transaction. For example, in some embodiments, device 120 may execute software that determines, receives, and processes information associated with the identified customer account to authenticate the transaction initiated by user device 110.



FIG. 6 shows an exemplary authentication process for detecting and identifying a customer with a user device conducting an ATM withdrawal, consistent with disclosed embodiments. Process 600 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 600 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 610, device 120 may receive transaction data related to an ATM withdrawal, as previously discussed with reference to FIGS. 3 and 4. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. The user device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, user device 110 may enter information requesting a monetary withdrawal of funds from a financial service account, such as, in this case, an ATM provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the withdrawal. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments


Local device 130 may detect the customer with a user device 110 at an ATM (step 620). In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting, through network 140 (Wi-Fi, BLE, NFC, etc.), user device 110. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130 may first detect the customer (step 620) and then receive the transaction data (step 610), as described with reference to FIG. 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction. Initiating a financial transaction, for example, may cause user device 110 to transmit transaction data to local device 130.


In certain embodiments, device 120 may determine whether user device 110 is at the local device 130 (e.g., ATM) (step 620). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. In one aspect, device 120 may be configured to execute software that relates the distance of user device 110 to local device 130 to a distance of the customer associated with user device 110. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 (and, for instance, the customer) with respect to local device 130.


At step 630, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 640, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized). For example, the message to user device 110 may be a text message, email, message within a mobile application, or other message. In certain embodiments, the message may be displayed to the user via local device 130, or the ATM. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations, may be displayed to the user via the screen or display of local device 130.


At step 650, local device 130, an ATM, for example, may dispense cash to the user consistent with the amount indicated in the transaction data. Local device 130 may, for example, automatically dispense cash in the amount of the withdrawal request, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.). In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated. Additionally, device 120 may transmit information to local device 130 indicating that local device 130 should dispense cash in the transaction amount.


In certain embodiments, cash dispensing may complete the transaction. Prior to dispensing the cash, local device 130, embodied as an ATM, may display to the user a message indicating that the transaction is processing and that the cash is dispensing. For example, device 120 and/or local device 130 may be configured to generate and provide a message to the user. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations, may be displayed to the user via the screen or display of local device 130. Similarly, following dispensing the cash, local device 130 may display to the user a message indicating that the transaction is complete.



FIG. 7 shows an alternative exemplary process 700 for detecting and identifying a customer conducting an ATM withdrawal, consistent with disclosed embodiments. Process 700 may be performed by processor 210 of, for example, device 120 and/or local device 130 (in this case, an ATM) executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 700 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 710, local device 130 may detect a customer with user device 110 in a local device 130 queue (e.g., an ATM queue). For example, there may be a walk-up line for the ATM, or the customer may be in line for a drive-up ATM. Local device 130 may detect the customer with user device 110 as described in detail with reference to FIGS. 3 and 5. For example, local device 130 may receive an identification signal from user device 110, as described with reference to FIG. 5. Further, local device 130 may detect user device 110 within the necessary threshold proximity, as described, for example with reference to FIG. 3. Additionally, local device 130 may detect that the customer with user device 110 is currently in a queue, rather than in position to use the ATM. Local device 130 may determine that the customer (user) is currently in a queue by detecting that the customer is more than, for example, three feet, five feet, etc., away from local device 130.


Alternatively, device 120 may detect a customer with user device 110 in a local device 130 queue (e.g., an ATM queue). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 with respect to local device 130.


At step 720, user device 110 may prompt the user to initiate a financial transaction while in the ATM queue. Device 120 may generate and provide data to user device 110 that may cause user device 110 to display a prompt to the user. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction, as described in detail with reference to FIG. 4. For example, device 120 may cause user device 110 to display a prompt to the user when it detects that the physical location of user device 110 with respect to local device 130 is less than a threshold distance. Alternatively, local device 130 may transmit a signal to user device 110 indicating that it is within range, which may then cause user device 110 to display a prompt to the user. The prompt may contain, for example, a selection of possible transactions a user may initiate on user device 110.


At step 730, device 120 and/or local device 130 may receive the transaction data as described with reference to FIG. 4. For example, a user device 110 may enter information requesting a monetary withdrawal of funds from a financial service account provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the withdrawal. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments.


At step 740, local device 130 may then detect the customer with user device 110 at the ATM. Local device 130 may detect the customer with a within a certain threshold distance, as described in detail with reference to FIG. 6. For example, in certain aspects, local device 130 may determine whether a user (customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting, through network 140 (Wi-Fi, BLE, NFC, etc.), user device 110. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130, such as an ATM, may have a particular location that the user may hold his or her user device 110 next to in order to indicate that they are first in the queue.


Alternatively, device 120 may detect a customer with user device 110 at the local device 130 (e.g., ATM). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 with respect to local device 130. For example, if the location of user device 110 is within, for example, six inches of the ATM, device 120 may determine that user device 110 is at the ATM.


At step 750, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 760, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. In some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal, via network 140, to local device 130 that the transaction has been authenticated and authorized. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data. At step 770, local device 130, e.g. an ATM, may dispense cash to the user consistent with the amount indicated in the transaction data, as described in detail with reference to FIG. 6.



FIG. 8 shows an exemplary process 800 process for detecting and identifying a recipient of a money transfer, consistent with disclosed embodiments. Process 800 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 800 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 810, device 120 may receive transaction data related to a money transfer. Device 120 may receive transaction data as discussed in detail with reference to FIG. 4. For example, a user device 110 may enter information requesting a monetary withdrawal of funds from a financial service account provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the withdrawal. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments. Transaction data may include, for example, the sender's account information, an amount, and recipient information. Recipient information may include, for example, an identifier such as a phone number, email address, social security number, or financial service account number.


At step 820, user device 110 may notify the recipient that they have a pending money transfer. User device 110 may notify the recipient, for example, by email, text message, or an alert in a mobile application. Device 120 may be configured to generate a notification message to a recipient based on the recipient information entered by the sender. For example, device 120 may generate a message to a particular recipient and transmit the message to user device 110 of a recipient for display to the recipient in accordance with the disclosed embodiments. A recipient with a pending transfer may go to an ATM, branch location, or other local device 130 in order to withdraw or collect their cash. Local device 130 may detect the recipient with a user device 110 (step 830) the same way it would detect a regular customer with a user device 110, as described in detail with respect to FIGS. 3 and 5. Alternatively, device 120 may detect the recipient with a user device 110. For example, device 120 may be configured to execute software that performs processes to determine whether the recipient with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 with respect to local device 130.


At step 840, local device 130 and/or device 120 may receive authentication data for the recipient. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, or biometric data, or other data associated with user identification methods (e.g., SureSwipesM or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, heartbeat or pulse pattern, or palm vein scan. Device 120 and/or local device 130 may receive authentication data as described in detail with respect to FIGS. 3 and 4.


At step 850, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in some embodiments, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130, via network 140, that the transaction has been authenticated and authorized. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


At step 860, device 120 and/or local device 130 may complete the transaction, as described in detail with reference to FIGS. 3 and 4. In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated. Additionally, device 120 may transmit information to local device 130 indicating that local device 130 should dispense cash in the transaction amount. For example, local device 130 may, for example, dispense cash from an ATM, indicate that a deposit has been successfully processed, notify a teller that the user has been authorized for a cash withdrawal, complete the user's initiated transaction, and/or other operations. In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized).


The disclosed embodiments include methods and systems to provide customer recognition and identification techniques. In certain aspects, certain additional elements may be implemented to provide processes to authenticate a transaction conducted by a customer based on authentication levels. For example, FIGS. 9 through 13 relate to exemplary embodiments for authentication processes.



FIG. 9 shows an exemplary financial authorization process, consistent with disclosed embodiments. Process 900 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 900 may be implemented by other components of system 100 (shown or not shown}, including biometric database 150 and/or user device 110. At step 910, device 120 may receive transaction data. In one aspect, device 120 may receive transaction data from user device 110. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. User device 100 may transmit transaction data via network 140 to device 120. Transaction data may be entered and transmitted manually per transaction into user device 110 by a user, for example by typing it on a keyboard or other input device (not shown). Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110.


Transaction data may include a type of transaction and a customer identifier. A type of transaction may include, for example, an ATM withdrawal, a money transfer or wire, a change order, a debit card PIN reset, or a call center transaction. If the type of transaction is, for example, an ATM withdrawal, a money transfer or wire, or a change order, transaction data may further include an amount. In certain embodiments, transaction data may include other data relating to transactions that is known to those skilled in the art, such as transaction amount, timestamp information, entity identifier, account identifier(s), etc.


At step 920, device 120 may identify a customer account associated with the transaction data. Device 120 may identify the customer account, for example, based upon the customer identifier that may be included in the received transaction data. The associated customer account may be any type of financial account, such as, for example, a debit account, checking account, savings account, or credit card account.


At step 930, device 120 may determine an authentication tier level associated with the transaction. Each transaction may be associated with a tier level. Additionally, each user may have a different tier level associated with each transaction. The tier level may indicate how many data security points must be verified before device 120 may authorize the requested transaction. Security data points may include, for example, a username and password, a GPS location, a phone number or device identifier, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Security data points may additionally include biometric data, such as, for example, fingerprint, retina or iris scan, heartbeat or pulse pattern, facial recognition, voice recognition, or palm vein scan. Each data security point may correspond to a different tier. For example, biometric data may relate to a higher tier (more secure) than a username and password (less secure).


At step 940, device 120 may receive authentication data. In some embodiments, device 120 may prompt the user to enter authentication data through user device 110. The authentication data requested by device 120 may correspond to the authentication tier level. For example, if the requested transaction required an authentication tier level two, the user may be prompted first to enter, for example, a username and password to satisfy tier one. Then, the user may be prompted to enter, for example, biometric data such as a fingerprint scan, vocal recording, retina or iris scan, heartbeat or pulse pattern, facial scan or palm scan.


The user may provide authentication data via user device 110, and device 120 may receive the authentication data (step 940). The form of authentication data provided by the user may be dependent on the type of user device 110 the user is operating. For example, certain user devices may have a fingerprint scanner, but not a retina scanner. Device 120 may detect the capabilities of user device 110 when prompting the user to enter authentication data. Alternatively, device 120 may prompt the user with a plurality of choices of authentication data the user may choose to enter, and the user may then select the option that corresponds with the capabilities of his or her particular user device 110.


At step 950, device 120 may determine if the received authentication data satisfies the determined authentication tier. For example, if the authentication tier level for a particular transaction is 2, a user may first be prompted for a username and password; however, this data will not satisfy the required authentication tier. Device 120 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user for additional authentication data. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the required authentication tier is satisfied or a threshold is met to deny the transaction. For example, once the received authentication data is satisfied (step 950—yes), device 120 may authorize the requested transaction (step 960). If however, the received transaction does not satisfy the required authentication tier, for example, because the biometric data does not match, the username and password are incorrect, the user is attempting to access his account through an unknown mobile device, etc. (step 950—no), device 120 may deny the transaction (step 970). In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized).



FIG. 10 shows an exemplary multi-tiered authentication process 1000, consistent with disclosed embodiments. Process 1000 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1000 may be implemented by other components of system 100 (shown or now shown), including biometric database 150 and/or user device 110.


At step 1005, as also discussed with reference to FIG. 9, device 120 may determine an authentication tier level for a particular transaction. Each transaction may be associated with a tier level. Additionally, different users associated with different user device(s) 110 may have a different tier level associated with each transaction. In certain aspects, different users may be customer(s) or potential customers of the financial service provider associated with device 120. The tier level may indicate how many data security points must be verified before device 120 may authorize the requested transaction. Security data points may include, for example, a username and password, a GPS location, a phone number or device identifier, or other data associated with user identification (e.g., SureSwipesM or the like). Security data points may additionally include biometric data, such as, for example, fingerprint, retina or iris scan, heartbeat or pulse pattern, facial recognition, voice recognition, or palm vein scan. Each data security point may correspond to a different tier. For example, biometric data may relate to a higher tier (more secure) than a username and password (less secure).


Assuming the authentication tier level determined in step 1005 is greater than one, device 120 may prompt the user to provide authentication data sufficient to satisfy the first authentication tier (step 1010). Device 120 may then receive authentication data (step 1015). Device 120 may receive authentication data from, for example, user device 110. Authentication data may be entered manually by the user (e.g., username and password) or may be automatically transmitted to device 120 by user device 110 (e.g., GPS data, phone or device identifier, etc.).


Device 120 may then determine if the authentication data received satisfies the first authentication tier (step 1020). Device 120 may determine if the authentication data satisfies the first tier by comparing the received authentication data with the stored customer information. Customer information may be stored, for example, in memory 230 or database 240. Customer information may additionally or alternatively be stored in biometric database 150. Biometric database 150 may be operated by the financial service provider. Alternatively, biometric database 150 may be operated and maintained by an independent third party or government entity. If the authentication data does not satisfy tier one (step 1020—no}, for example, because the incorrect information was entered and there is not a match between the authentication data and the stored customer data, device 120 may deny the transaction. If the authentication data satisfies tier one (step 1020—yes), device 120 may indicate that the first tier of authentication has been satisfied and then move on to the next tier.


At step 1030, device 120 again may prompt the user to provide authentication data. This time, the prompted authentication data may respond to the second tier. For example, second tier authentication data may indicate a higher level of security. For example, second tier authentication data may include GPS location, phone or device identification information, or user biometric data. If the requested second tier authentication data is related to user device 110 (e.g., GPS location or device identification information), the request for authentication data, as well as the responsive transmission of the requested data, may occur automatically and transparent to the user.


Similar to that discussed above in connection with a tier one operation, at step 1035, device 120 may receive the authentication data, and then at step 1040, device 120 may determine if the received authentication data satisfies the second tier. If the authentication data does not satisfy the tier (step 1040—no), for example, because incorrect information was received, device 120 may deny the transaction (step 1045). Alternatively, if the received authentication data satisfies the tier (step 1040—yes), device 120 may then determine if there are additional authentication tiers that need to be satisfied before the particular transaction can be authorized (step 1050). If there are no additional tiers (step 1050—no), then device 120 may authorize the transaction. If, however, there are additional authentication tiers for the particular transaction (step 1050—yes), device 120 repeats the process beginning with step 1030 again, and continues to do so until all authorization tiers are satisfied. In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized).



FIG. 11 shows an exemplary authentication process 1100, consistent with disclosed embodiments. Process 1100 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1100 may be implemented by other components of system 100 (shown or not shown), including biometric database 150 and/or user device 110.


At step 1110, device 120 may receive authentication data, as discussed previously with respect to FIGS. 9 and 10. At step 1120, device 120 may access customer identification data. Customer identification data may be stored, for example, in memory 230 or database 240 of device 120. Additionally or alternatively, customer identification data may be stored in biometric database 150. Customer identification data may include any stored data related to a customer that may correspond to the authentication data requested of a customer in order to validate the customer's identity for authentication purposes. For example, customer data may include a username and password, a known GPS location (e.g., the customer's home or work location), a device identifier (e.g., phone number, device serial number, IP address, etc.). Customer data may further include biometric data, such as, for example, fingerprints, retina and/or iris scans, heartbeat or pulse pattern, palm vein scan, facial image, or voice recording.


At step 1130, device 120 may compare the received authentication data to determine if it matches the stored customer identification data. If the received authentication data does not match the customer identification data (step 1140—no), device 120 may deny the transaction (step 1150). In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) that the transaction was denied. If the received authentication data matches the corresponding customer data (step 1140—yes), device 120 may indicate that the authentication tier is satisfied (step 1160). For example, device 120 may be configured to execute software that generates information used to provide an indication reflecting the status of the authentication analysis, whether a transaction is authorized, etc. For example, in some embodiments, device 120 may be configured to provide information to user device 110 that device 110 may use to generate and provide a message in an interface presented in a display device of user device 110. For instance, user device 110 may be configured, based on information provided by device 120 to display a message on a display device that the authentication tier is satisfied or that a transaction has been authorized. Additionally or alternatively, device 120 may internally indicate that the tier is satisfied, transparent to the user, by cither prompting the user for authentication data relating to the next authentication tier, or if the final tier is satisfied, by authorizing the transaction. If the satisfied authentication tier corresponds to the determined authentication tier level required for the transaction, device 120 may authorize the transaction.



FIG. 12 shows an exemplary authentication process when the customer identification data is stored on a remote biometric database 150, consistent with disclosed embodiments. Process 1200 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1200 may be implemented by other components of system 100 (shown or not shown), including biometric database 150 and/or user device 110.


At step 1210, device 120 may receive authentication data, as discussed in detail with respect to FIGS. 9 and 10. At step 1220, device 120 may request corresponding customer identification data from biometric database 150. Requesting customer identification data may include, for example, requesting access to biometric database 150. Additionally or alternatively, requesting customer identification data may include, for example, requesting biometric database 150 to transmit the necessary information to device 120, for example, via network 140. Additionally or alternatively, requesting customer identification data may include device 120 transmitting the received authentication data to biometric database 150, and allowing biometric database 150 to conduct the validation and authentication. At step 1230, device 120 may receive corresponding customer identification data from biometric database 150.


At step 1240, device 120 may compare the received authentication data with the corresponding customer identification data received or accessed in step 1230. Additionally or alternatively, step 1240 may be performed by biometric database 150. Based on the comparison, device 120 (or alternatively biometric database 150) may determine if the received authentication data matches the customer identification data (step 1250). If the received authentication data does not match the stored customer identification data (step 1250—no), device 120 may deny the transaction (step 1260). In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) that the transaction was denied. If the received authentication data matches the customer identification data (step 1250—yes), device 120 may then then indicate that the authentication tier is satisfied (step 1270). For example, device 120 may be configured to execute software that generates information used to provide an indication reflecting the status of the authentication analysis, whether a transaction is authorized, etc. For example, in some embodiments, device 120 may be configured to provide information to user device 110 that user device 110 may use to generate and provide a message in an interface presented in a display device of user device 110. For instance, user device 110 may be configured, based on information provided by device 120 to display a message to the user that the authentication tier is satisfied or notifying the user that the transaction has been authorized. Additionally or alternatively, device 120 may internally indicate that the tier is satisfied, transparent to the user, by either prompting the user for authentication data relating to the next authentication tier, or if the final tier is satisfied, by authorizing the transaction. If the satisfied authentication tier corresponds to the determined authentication tier level required for the transaction, device 120 may authorize the transaction.



FIG. 13 shows an exemplary authentication process 1300, consistent with disclosed embodiments, relating to an ATM withdrawal transaction. Process 1300 may be performed by processor 210 of, for example, device 120 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1300 may be implemented by other components of system 100 (shown or not shown), including biometric database 150 and/or user device 110.


At step 1310, device 120 may receive transaction data related to an ATM cash withdrawal. For example, a user may indicate through a mobile application installed on user device 110 that he or she wishes to make an ATM withdrawal. At step 1320, device 120 may then identify a customer account associated with the transaction. Device 120 may identify the customer account by locating the matching customer account based on the transaction data. Additionally or alternatively, the mobile application on user device 110 the customer may be operating to initiate the transaction may require the user to log into a user account. If the user is logged into a user account on the mobile application, user device 110 may then automatically transmit the necessary information to device 120 in order for device 120 to identify the corresponding customer account.


Device 120 may then determine the withdrawal amount (step 1330). The withdrawal amount may be automatically transmitted to device 120 by user device 110 when the user initiates the ATM withdrawal transaction. Additionally or alternatively, the withdrawal amount may be included in the transaction data received by device 120 at step 1310. Based on the customer account and the withdrawal amount, device 120 may then determine an authentication tier level for the transaction (step 1340). For example, the higher the withdrawal amount, the higher the authentication tier level may be in order to have the withdrawal transaction authorized.


At step 1350, device 120 may receive authentication data, as discussed in detail with respect FIGS. 9 and 10. Device 120 (or alternatively biometric database 150) may then determine if the received authentication data matches the customer identification data, and therefore satisfies the authentication tier (step 1360). Device 120 (or biometric database 150) may determine if the received authentication data matches the customer identification data by conducting a comparison as discussed in detail with respect to FIG. 6. If the received authentication data does not match the stored customer identification data, and therefore does not satisfy the authentication tier, (step 1360—no), device 120 may deny the transaction (step 1370). In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) that the transaction was denied. If the received authentication data matches the customer identification data (step 1360—yes), device 120 may then then indicate that the authentication tier is satisfied. For example, device 120 may be configured to execute software that generates information used to provide an indication reflecting the status of the authentication analysis, whether a transaction is authorized, etc. For example, in some embodiments, device 120 may be configured to provide information to user device 110 that device 110 may use to generate and provide a message in an interface presented in a display device of user device 110. For instance, user device 110 may be configured, based on information provided by device 120 to display a message to the user that the authentication tier is satisfied or notifying the user that the transaction has been authorized. Additionally or alternatively, device 120 may internally indicate that the tier is satisfied, transparent to the user, by either prompting the user for authentication data relating to the next authentication tier, or if the final tier is satisfied, by authorizing the transaction. If the satisfied authentication tier corresponds to the determined authentication tier level required for the transaction, device 120 may authorize the transaction and allow the withdrawal (step 1380).



FIG. 14 shows an exemplary process for depositing funds, consistent with disclosed embodiments. Process 1400 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1400 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 1410, device 120 may receive transaction data related to a deposit of funds. As previously discussed with reference to FIGS. 3 and 4, for example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. The user device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively or additionally, local device 130 may receive the transaction data from user device 110. For example, user device 110 may enter information requesting to deposit funds into a financial service account at an ATM provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the deposit. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments


Local device 130 may detect the customer with a user device 110 at an ATM (step 1420). In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130, in this case an ATM. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting user device 110, through network 140 (Wi-Fi, BLE, NFC, etc.), for example. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130 may first detect the customer (step 1420) and then receive the transaction data (step 1410), as described with reference to FIG. 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction. Initiating a financial transaction, for example, may cause user device 110 to transmit transaction data to local device 130.


In certain embodiments, device 120 may determine whether user device 110 is at the local device 130 (e.g., ATM) (step 1420). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. In one aspect, device 120 may be configured to execute software that relates the distance of user device 110 to local device 130, to a distance of the customer associated with user device 110. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 (and, for instance, the customer) with respect to local device 130.


At step 1430, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipesM or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 1440, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in one embodiment, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized). For example, the message to user device 110 may be a text message, email, message within a mobile application, or other message. In certain embodiments, the message may be displayed to the user via local device 130, or the ATM. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations, may be displayed to the user via the screen or display of local device 130.


At step 1450, local device 130 (e.g., the ATM) may receive cash or a check consistent with the amount indicated in the transaction data. Local device 130 may, for example, receive cash or a check in the amount of the deposit request, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.). In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated.


In certain embodiments, inserting cash or a check into the ATM may complete the transaction. Prior to or following the insertion of cash or a check, the ATM may display to the user a message indicating that the transaction is processing. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations, may be displayed to the user via the screen or display of local device 130. Similarly, following insertion of the cash or check, the ATM may display to the user a message indicating that the transaction is complete.



FIG. 15 shows an exemplary process for ordering certified funds or cashier's checks, consistent with disclosed embodiments. Process 1500 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1500 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 1510, device 120 may receive transaction data related to a deposit of funds, as previously discussed with reference to FIGS. 3 and 4. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. User device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example, by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, user device 110 may enter information requesting certified funds from a financial service provider. User device 110 may be configured to generate an interface to request transaction data from the user regarding the certified funds. User device 110 may receive the user input of transaction data, and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments.


Local device 130 may detect the customer with a user device 110 at an ATM or within a branch location (step 1520). In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting user device 110, through network 140 (Wi-Fi, BLE, NFC, etc.), for example. User device 110 may be required to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130 may first detect the customer (step 1420) and then receive the transaction data (step 1510), as described with reference to FIG. 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction. Initiating a financial transaction, for example, may cause user device 110 to transmit transaction data to local device 130.


In certain embodiments, device 120 may determine whether user device 110 is at the local device 130 (e.g., ATM) (step 1520). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. In one aspect, device 120 may be configured to execute software that relates the distance of user device 110 to local device 130, to a distance of the customer associated with user device 110. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 (and, for instance, the customer) with respect to local device 130.


At step 1530, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipesM or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 1540, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in one embodiment, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized). For example, the message to user device 110 may be a text message, email, message within a mobile application, or other message. In certain embodiments, the message may be displayed to the user via local device 130, or the ATM. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations may be displayed to the user via the screen or display of local device 130.


At step 1550, local device 130, the ATM, may print and dispense a cashier's check consistent with the information indicated by the user in the transaction data. Local device 130 may, for example, print and dispense a cashier's check, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.). In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated.


In certain embodiments, printing and dispensing the cashier's check by the ATM may complete the transaction. Prior to or during the printing and dispensing of the cashier's check, the ATM may display to the user a message indicating that the transaction is processing. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations, may be displayed to the user via the screen or display of local device 130. Similarly, following printing and dispensing the cashier's check, the ATM may display to the user a message indicating that the transaction is complete.



FIG. 16 shows an exemplary process for ordering a new or reissue debit card, consistent with disclosed embodiments. Process 1600 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1600 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 1610, device 120 may receive transaction data related to ordering a new or reissue debit card, as previously discussed with reference to FIGS. 3 and 4. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. User device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example, by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, user device 110 may enter information requesting a new or reissued debit card related to a financial service account provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the request. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments. Transaction data for ordering a new or reissue debit card may include, for example, an account number and card design.


Local device 130 may detect the customer with a user device 110 at an ATM (step 1620). In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting user device 110, through network 140 (Wi-Fi, BLE, NFC, etc.), for example. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130 may first detect the customer (step 1620) and then receive the transaction data (step 1610), as described with reference to FIG. 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction, such as the ordering of a new or reissue debit card. Initiating a financial transaction, for example, may cause user device 110 to transmit transaction data related to the order to local device 130.


In certain embodiments, device 120 may determine whether user device 110 is at the local device 130 (e.g., ATM) (step 1620). For example, device 120 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. In one aspect, device 120 may be configured to execute software that relates the distance of user device 110 to local device 130, to a distance of the customer associated with user device 110. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 (and, for instance, the customer) with respect to local device 130.


At step 1630, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 1640, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in one embodiment, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized). For example, the message to user device 110 may be a text message, email, message within a mobile application, or other message. In certain embodiments, the message may be displayed to the user via local device 130, or the ATM. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations may be displayed to the user via the screen or display of local device 130.


At step 1650, local device 130, the ATM, may print and dispense a debit card as ordered. Local device 130 may, for example, print and dispense the requested debit card, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.). In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated.


In certain embodiments, printing and dispensing the debit card may complete the transaction. Prior to or following the printing and dispensing of the debit card, the ATM may display to the user a message indicating that the transaction is processing. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations may be displayed to the user via the screen or display of local device 130. Similarly, following dispensing the debit card, the ATM may display to the user a message indicating that the transaction is complete.



FIG. 17 shows an exemplary process for submitting a change order, consistent with disclosed embodiments. A change order may be submitted by the owner of a small business who may submit large bills in exchange for small bills, for example, in order to be able to make change for customers throughout the day. Additionally or alternatively, a change order may be submitted to exchange a quantity of small bills for larger bills. Process 1700 may be performed by processor 210 of, for example, device 120 and/or local device 130 executing instructions encoded on a computer-readable medium storage device. It is to be understood, however, that one or more steps of process 1700 may be implemented by other components of system 100 (shown or not shown), including user device 110.


At step 1710, device 120 may receive transaction data related to a change order, as previously discussed with reference to FIGS. 3 and 4. As an example, user device 110 may execute a mobile application associated with the financial service provider associated with device 120. User device 110 may transmit transaction data via network 140 to device 120. Transaction data may be entered manually into user device 110 by a user, for example, by typing it on a keyboard or other input device (not shown), using voice recognition software, etc. Transaction data may also be entered and transmitted automatically, for example, by a mobile application on user device 110. Alternatively, local device 130 may receive the transaction data from user device 110. For example, user device 110 may enter information requesting a change order related to a financial service account provided by a financial service provider (e.g., an entity associated with device 120). User device 110 may be configured to generate an interface to request transaction data from the user regarding the request. User device 110 may receive the user input of transaction data and store the received transaction data for processing in accordance with one or more operations consistent with the disclosed embodiments. Transaction data for ordering a change order may include, for example, the denomination of bills they would like to exchange, the denomination of bills they would like to receive, and a location where they would like to make the exchange if the customer is not already at a branch or ATM location.


Local device 130 may detect the customer with a user device 110 at an ATM (step 1720). In certain aspects, local device 130 may be configured to execute software that performs processes to determine whether a user (e.g., customer) with a user device 110 is within a predetermined distance or range of distance(s) of local device 130. For example, in certain aspects, local device 130 may determine whether a user (e.g., customer) with a user device 110 is within one foot, two feet, six inches, etc., of local device 130. For instance, local device 130 may detect the customer by detecting user device 110, through network 140 (Wi-Fi, BLE, NFC, etc.), for example. User device 110 may need to be detected at a certain threshold distance before local device 130 will connect and communicate with user device 110. For example, user device 110 may need to be within 6 inches of local device 130 before the devices connect to conduct the transaction. Additionally or alternatively, local device 130 may first detect the customer (step 1720) and then receive the transaction data (step 1710). For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to initiate a financial transaction, such as the change order. Initiating a financial transaction, for example, may cause user device 110 to transmit transaction data related to the order to local device 130.


In one aspect, device 120 may be configured to execute software that relates the distance of user device 110 to local device 130, to a distance of the customer associated with user device 110. For example, device 120 may be configured to receive a signal from local device 130 indicating that it has detected a signal from user device 110. Device 120 may then determine the physical location of user device 110 (and, for instance, the customer) with respect to local device 130.


At step 1730, local device 130 and/or device 120 may receive authentication data, as described in detail with respect to FIGS. 3 and 4. For example, user device 110 may be configured to execute software that generates a prompt to (or causes a prompt to be generated to) the user to enter authentication data. The user may then enter the authentication data into user device 110. In certain aspects, the disclosed embodiments may iteratively prompt the user for additional authentication data until the necessary authentication data has been received. In other embodiments, device 120 may receive authentication data through user device 110. If, for example, local device 130 receives the authentication data, the data may then be transmitted to device 120 for authentication. Authentication data may include, for example, a username and password, social security number, ATM pin, biometric data, or other data associated with user identification methods (e.g., SureSwipe8 or the like). Biometric data may include, for example, a fingerprint scan, voice recognition, facial recognition, retina or iris scan, or palm vein scan.


At step 1740, device 120 and/or local device 130 may authenticate and authorize the transaction, as described in detail with respect to FIGS. 3 and 4. For example, in one embodiment, device 120 may authenticate the transaction by comparing the received authentication data with stored customer data corresponding to the particular user. When the customer data matches the authentication data, the transaction may be authenticated, and device 120 may then authorize the transaction. Device 120 may transmit a signal to local device 130 that the transaction has been authenticated and authorized via network 140. Alternatively, local device 130 may authenticate and authorize the transaction independent from device 120. The amount and type of authentication data required for device 120 to authenticate the transaction may be determined by the amount of the transaction. For example, a higher transaction amount may require additional or more secure authentication data.


In certain aspects, device 120 may be configured to generate and provide a message to user device 110 (or some other device) reflecting the results of the authentication operation(s) (e.g., authentication denied and/or transaction denied; authentication accepted and/or transaction authorized). For example, the message to user device 110 may be a text message, email, message within a mobile application, or other message. In certain embodiments, the message may be displayed to the user via local device 130, or the ATM. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations may be displayed to the user via the screen or display of local device 130.


At step 1750, local device 130, the ATM, may receive the bills to be exchanged and dispense the new bills. Local device 130 may, for example, allow for receipt of the bills for exchange and, once the quantity of bills received is confirmed, dispense the requested new denomination of bills, without the user ever having to physically manipulate components of local device 130 (e.g., use a keypad on local device 130, swipe a card, etc.). In certain embodiments, device 120 may be configured to transmit information to local device 130 indicating that the transaction has been authenticated.


In certain embodiments, dispensing the requested denominations of bills may complete the transaction. Prior to or following dispensing, the ATM may display to the user a message indicating that the transaction is processing. For example, local device 130 may contain a screen or other display. In certain embodiments, messages, such as those reflecting the results of authentication operations may be displayed to the user via the screen or display of local device 130. Similarly, following dispensing the requested bills, the ATM may display to the user a message indicating that the transaction is complete.


In some examples, some or all of the logic for the above-described techniques may be implemented as a computer program or application or as a plugin module or subcomponent of another application. The described techniques may be varied and are not limited to the examples or descriptions provided. In some examples, applications may be developed for download to mobile communications and computing devices, e.g., laptops, mobile computers, tablet computers, smart phones, etc., being made available for download by the user either directly from the device or through a website.


Moreover, while illustrative embodiments have been described herein, the scope thereof includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those of skill in the art based on the present disclosure. For example, the number and orientation of components shown in the exemplary systems may be modified. Further, with respect to the exemplary methods illustrated in the attached drawings, the order and sequence of steps may be modified, and steps may be added or deleted.


Thus, the foregoing description has been presented for purposes of illustration. It is not exhaustive and is not limiting to the precise forms or embodiments disclosed. Modifications and adaptations will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments. For example, while a financial service provider has been described herein as the entity detecting and identifying customers, it is to be understood that consistent with disclosed embodiments another entity may provide such services in conjunction with or separate from a financial service provider.


The claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification, which examples are to be construed as non-exclusive. Further, the steps of the disclosed methods may be modified in any manner, including by reordering steps and/or inserting or deleting steps.


Furthermore, although aspects of the disclosed embodiments are described as being associated with data stored in memory and other tangible computer-readable storage mediums, one skilled in the art will appreciate that these aspects can also be stored on and executed from many types of tangible computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM, or other forms of RAM or ROM. Accordingly, the disclosed embodiments are not limited to the above described examples, but instead are defined by the appended claims in light of their full scope of equivalents.

Claims
  • 1. A server system comprising: one or more processors and memory storing instructions that, when executed by the one or more processors, cause operations comprising: in response to (i) a mobile device wirelessly transmitting a short-range wireless signal to a local device local to the mobile device and (ii) the mobile device being detected, based on the short-range wireless signal, as being within a predetermined distance of the local device, providing presentation instructions to present multiple access initiation options on a user interface of the mobile device, the access initiation options comprising a resource withdrawal or transfer, a card reset, or a call center call using the local device;in response to a selection of a first option via the user interface to initiate an access request for an access operation with the local device, generating an authentication request associated with a biometric authentication capability based on the biometric authentication capability (i) being detected by the server system as an authentication capability of the mobile device via interaction with the mobile device and (ii) corresponding to a first authentication tier that is selected by the server system over a second authentication tier due to the first authentication tier (a) corresponding to an access amount of the access request and (b) not corresponding to a different access amount to which the second authentication tier corresponds, the second authentication tier being different from the first authentication tier;obtaining the access amount of the access request from the mobile device via the first option on the user interface;in response to detecting the biometric authentication capability of the mobile device based on a detection of a biometric scanner on the mobile device, generating a prompt for biometric user input to obtain, via the biometric scanner, authentication data for completing the access operation with the local device, wherein the authentication data comprises one or more of fingerprint data, retina scan data, iris scan data, heartbeat pattern data, facial recognition data, voice recognition data, or palm vein scan data;obtaining, from the mobile device via the prompt, the authentication data for completing the access operation with the local device in connection with the authentication request;granting, based on the authentication data, access to the local device for completing the access operation with the local device; andtransmitting, based on the authentication data, an authentication confirmation to the mobile device.
  • 2. The server system of claim 1, the operations further comprising: detecting a fingerprint authentication capability of the mobile device based on a detection of a fingerprint scanner being on the mobile device,wherein generating the authentication request comprises, in response to detecting the fingerprint authentication capability of the mobile device, generating the authentication request to include at least one prompt related to fingerprint scanning.
  • 3. The server system of claim 1, wherein the authentication data comprises one or more of retina scan data, iris scan data, or facial recognition data.
  • 4. A method comprising: executing, by one or more processors of a server system, operations comprising: in response to (i) a mobile device wirelessly transmitting a short-range wireless signal to a local device local to the mobile device and (ii) the mobile device being detected, based on the short-range wireless signal, being within a predetermined distance of the local device, transmitting presentation instructions to the mobile device to present access initiation options on a user interface of the mobile device, the access initiation options comprising a resource withdrawal or transfer, a card reset, or a call center call using the local device;in response to a selection of a first option of the access initiation options via the user interface to initiate an access request for an access operation with the local device, generating an authentication request associated with a biometric authentication capability and with a first authentication tier based on the biometric authentication capability (i) being detected by the server system as an authentication capability of the mobile device via interaction with the mobile device and (ii) corresponding to the first authentication tier, wherein the first authentication tier is selected by the server system for the authentication request over a second authentication tier in connection with the first authentication tier (a) corresponding to an access amount of the access request and (b) not corresponding to a different access amount to which the second authentication tier corresponds, the second authentication tier being different from the first authentication tier;obtaining the access amount of the access request from the mobile device via the first option on the user interface;in response to detecting the biometric authentication capability of the mobile device based on a detection of a biometric scanner on the mobile device, generating a prompt for biometric user input to obtain, via the biometric scanner authentication data for completing the access operation with the local device, wherein the authentication data comprises one or more of fingerprint data, retina scan data, iris scan data, heartbeat pattern data, facial recognition data, voice recognition data, or palm vein scan data;obtaining, from the mobile device via the prompt, the authentication data for completing the access operation with the local device, the authentication data corresponding to the first authentication tier;granting, based on the authentication data, access to the local device for completing the access operation with the local device; andtransmitting, based on the authentication data, an authentication confirmation to the mobile device.
  • 5. The method of claim 4, the operations further comprising: detecting a fingerprint authentication capability of the mobile device based on a detection of a fingerprint scanner being on the mobile device,wherein generating the authentication request comprises, based on detecting the fingerprint authentication capability of the mobile device, generating the authentication request to include at least one prompt related to fingerprint scanning.
  • 6. The method of claim 4, wherein granting access to the local device for completing the access operation with the local device comprises transmitting, based on the authentication data, dispensing instructions to the local device to dispense one or more items from within the local device to complete the access operation with the local device.
  • 7. The method of claim 4, wherein detecting the mobile device comprises detecting the mobile device as being within a first predetermined distance of the local device while the mobile device is not within a second predetermined distance of the local device, the method further comprising: subsequently detecting the mobile device as being within the first and second predetermined distances of the local device; andtransmitting, based on the authentication data and the mobile device being detected as being within the first and second predetermined distances of the local device, dispensing instructions to the local device to dispense one or more items from within the local device to complete the access operation with the local device.
  • 8. The method of claim 4, wherein granting access to the local device comprises granting, based on the authentication data, granting access to the local device, for completing the access operation with the local device, without a user of the mobile device having to physically interact with the local device before the granting of access to the local device.
  • 9. The method of claim 4, wherein the authentication data comprises one or more of retina scan data, iris scan data, heartbeat pattern data, facial recognition data, voice recognition data, or palm vein scan data.
  • 10. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors of a server system, cause operations comprising: in response to (i) a mobile device wirelessly transmitting a short-range wireless signal to a local device local to the mobile device and (ii) the mobile device being detected, based on the short-range wireless signal, being within a predetermined distance of the local device, causing the mobile device to present access initiation options on a user interface of the mobile device, the access initiation options comprising a resource withdrawal or transfer, a card reset, or a call center call using the local device;in connection with a selection of a first option of the access initiation options via the user interface to initiate an access request for an access operation with the local device, generating an authentication request associated with a biometric authentication capability based on the biometric authentication capability (i) being detected by the server system as an authentication capability of the mobile device via interaction with the mobile device and (ii) corresponding to a first authentication tier that is selected over a second authentication tier in connection with the first authentication tier (a) corresponding to an access amount of the access request and (b) not corresponding to a different access amount to which the second authentication tier corresponds, the second authentication tier being different from the first authentication tier;obtaining the access amount of the access request from the mobile device via the first option on the user interface;in response to detecting the biometric authentication capability of the mobile device based on a detection of a biometric scanner on the mobile device, generating a prompt for biometric user input to obtain, via the biometric scanner, authentication data for completing the access operation with the local device, wherein the authentication data comprises one or more of fingerprint data, retina scan data, iris scan data, heartbeat pattern data, facial recognition data, voice recognition data, or palm vein scan data;obtaining, from the mobile device via the prompt, the authentication data for completing the access operation with the local device, the authentication data corresponding to the first authentication tier;granting, based on the authentication data, access to the local device for completing the access operation with the local device; andtransmitting, based on the authentication data, an authentication confirmation to the mobile device.
  • 11. The one or more non-transitory computer-readable media of claim 10, the operations further comprising: detecting a fingerprint authentication capability of the mobile device based on a detection of a fingerprint scanner being on the mobile device,wherein generating the authentication request comprises, based on detecting the fingerprint authentication capability of the mobile device, generating the authentication request to include at least one prompt related to fingerprint scanning.
  • 12. The one or more non-transitory computer-readable media of claim 10, wherein granting access to the local device for completing the access operation with the local device comprises transmitting, based on the authentication data, dispensing instructions to the local device to dispense one or more items from within the local device to complete the access operation with the local device.
  • 13. The one or more non-transitory computer-readable media of claim 10, wherein detecting the mobile device comprises detecting the mobile device as being within a first predetermined distance of the local device while the mobile device is not within a second predetermined distance of the local device, the operations further comprising: subsequently detecting the mobile device as being within the first and second predetermined distances of the local device; andtransmitting, based on the authentication data and the mobile device being detected as being within the first and second predetermined distances of the local device, dispensing instructions to the local device to dispense one or more items from within the local device to complete the access operation with the local device.
  • 14. The one or more non-transitory computer-readable media of claim 10, wherein granting access to the local device comprises granting, based on the authentication data, granting access to the local device, for completing the access operation with the local device, without a user of the mobile device having to physically interact with the local device before the granting of access to the local device.
  • 15. The one or more non-transitory computer-readable media of claim 10, wherein the authentication data comprises one or more of retina scan data, iris scan data, heartbeat pattern data, facial recognition data, voice recognition data, or palm vein scan data.
CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 17/343,241, filed Jun. 9, 2021, which is a continuation of U.S. patent application Ser. No. 16/569,658, filed Sep. 12, 2019, which is a continuation of U.S. patent application Ser. No. 14/680,857, filed Apr. 7, 2015, which claims the benefit of priority of U.S. Provisional Patent Application No. 61/976,703, filed Apr. 8, 2014, and U.S. Provisional Patent Application No. 62/102,857, filed Jan. 13, 2015. The content of the foregoing applications is incorporated herein in its entirety by reference.

US Referenced Citations (970)
Number Name Date Kind
5608778 Partridge, III Mar 1997 A
5668876 Falk Sep 1997 A
5850445 Chan Dec 1998 A
5970144 Chan Oct 1999 A
6167279 Chang Dec 2000 A
6338140 Owens Jan 2002 B1
6418129 Fingerhut Jul 2002 B1
6477370 Sigler Nov 2002 B1
6931538 Sawaguchi Aug 2005 B1
7058180 Ferchichi Jun 2006 B2
7277726 Ahya Oct 2007 B2
7305090 Hayes Dec 2007 B1
7421155 King Sep 2008 B2
7493289 Verosub Feb 2009 B2
7577847 Nguyen Aug 2009 B2
7620008 Hayes Nov 2009 B1
7669232 Jou Feb 2010 B2
7712657 Block May 2010 B1
7812860 King Oct 2010 B2
7865937 White Jan 2011 B1
7882247 Sturniolo Feb 2011 B2
7882538 Palmer Feb 2011 B1
7992776 Ramachandran Aug 2011 B1
8025226 Hopkins, III Sep 2011 B1
8032115 Breau Oct 2011 B1
8051453 Arseneau Nov 2011 B2
8081849 King Dec 2011 B2
8145561 Zhu Mar 2012 B1
8146802 Ramachandran Apr 2012 B1
8179563 King May 2012 B2
8181856 Folk May 2012 B1
8201232 Zhang Jun 2012 B2
8255411 Carpenter Aug 2012 B1
8261094 King Sep 2012 B2
8271786 Pradhan Sep 2012 B1
8280351 Ahmed Oct 2012 B1
8296228 Kloor Oct 2012 B1
8313020 Ramachandran Nov 2012 B2
8346620 King Jan 2013 B2
8346672 Weiner Jan 2013 B1
8370254 Hopkins, III Feb 2013 B1
8370917 Hayes Feb 2013 B1
8392712 Wilson Mar 2013 B1
8418055 King Apr 2013 B2
8442331 King May 2013 B2
8447066 King May 2013 B2
8489624 King Jul 2013 B2
8490868 Kropf Jul 2013 B1
8505090 King Aug 2013 B2
8536976 Headley Sep 2013 B2
8566248 Steele Oct 2013 B1
8566404 Wu Oct 2013 B2
8577804 Bacastow Nov 2013 B1
8584225 Kennedy Nov 2013 B1
8611919 Barnes, Jr. Dec 2013 B2
8613070 Borzycki Dec 2013 B1
8620083 King Dec 2013 B2
8621583 Yang Dec 2013 B2
8626659 Bowman Jan 2014 B1
8639629 Hoffman Jan 2014 B1
8640946 Block Feb 2014 B1
8651373 Block Feb 2014 B1
8655773 Fasoli Feb 2014 B1
8661254 Sama Feb 2014 B1
8684900 Tran Apr 2014 B2
8699379 Kholaif Apr 2014 B2
8700729 Dua Apr 2014 B2
8712857 Adornato Apr 2014 B1
8713418 King Apr 2014 B2
8739059 Rabenold May 2014 B2
8752151 Li Jun 2014 B2
8768306 Ben Ayed Jul 2014 B1
8768838 Hoffman Jul 2014 B1
8781228 King Jul 2014 B2
8812319 Skerpac Aug 2014 B2
8812838 Grajek Aug 2014 B2
8840016 Schott Sep 2014 B1
8874504 King Oct 2014 B2
8924310 Bishop Dec 2014 B2
8925040 Ding Dec 2014 B2
8955149 Baer Feb 2015 B1
8955743 Block Feb 2015 B1
8990235 King Mar 2015 B2
8990891 Chickering Mar 2015 B1
9004352 Graef Apr 2015 B1
9004353 Block Apr 2015 B1
9008447 King Apr 2015 B2
9047728 Irudayam Jun 2015 B1
9065819 Shanmugam Jun 2015 B1
9072118 Zhong Jun 2015 B2
9087354 Hambir Jul 2015 B1
9098687 Hayton Aug 2015 B2
9098961 Block Aug 2015 B1
9119078 Kokubo Aug 2015 B2
9141876 Jones Sep 2015 B1
9143638 King Sep 2015 B2
9143937 Cherian Sep 2015 B2
9154949 Bertz Oct 2015 B1
9154955 Bertz Oct 2015 B1
9160744 Machani Oct 2015 B1
9161227 Bye Oct 2015 B1
9177314 Uzo Nov 2015 B2
9185109 Chen Nov 2015 B2
9189788 Robinson Nov 2015 B1
9195834 Jakobsson Nov 2015 B1
9202035 Manusov Dec 2015 B1
9215075 Poltorak Dec 2015 B1
9224141 Lamba Dec 2015 B1
9246884 Pfab Jan 2016 B1
9268852 King Feb 2016 B2
9292711 Roth Mar 2016 B1
9300645 Rao Mar 2016 B1
9301140 Costigan Mar 2016 B1
9306943 Bailey Apr 2016 B1
9311632 Dent Apr 2016 B1
9323784 King Apr 2016 B2
9355530 Block May 2016 B1
9374368 Roth Jun 2016 B1
9401905 Kowalski Jul 2016 B1
9420397 Sheriff Aug 2016 B1
9455972 Dotan Sep 2016 B1
9456326 McKibben Sep 2016 B2
9479491 Farnsworth Oct 2016 B1
9509676 Johnson Nov 2016 B1
9529502 Prasad Dec 2016 B2
9602501 Ramalingam Mar 2017 B1
9607139 Machani Mar 2017 B1
9619792 Aaron Apr 2017 B1
9645789 Lee May 2017 B1
9668138 Braden May 2017 B2
9699174 Zucker Jul 2017 B2
9710640 Ramalingam Jul 2017 B1
9721111 Cavanaugh Aug 2017 B2
9807819 Zhu Oct 2017 B1
9836739 Borovsky Dec 2017 B1
9839061 Faccin Dec 2017 B2
9858569 Phan Jan 2018 B2
9883437 Abraham Jan 2018 B2
9888385 Oh Feb 2018 B1
9900742 Thoresen Feb 2018 B1
9928379 Hoffer Mar 2018 B1
9980134 Zhang May 2018 B2
10013537 Trachtman Jul 2018 B1
10021670 Bhatt Jul 2018 B1
10055716 Cacheria, III Aug 2018 B2
10055732 Hecht Aug 2018 B1
10142340 Castinado Nov 2018 B2
10148629 Roth Dec 2018 B1
10169587 Nix Jan 2019 B1
10194309 Bari Jan 2019 B2
10296875 Prasad May 2019 B1
10373148 Dixon Aug 2019 B1
10452897 Benkreira Oct 2019 B1
10489132 Bloomcamp Nov 2019 B1
10516668 Stedman Dec 2019 B2
10517126 Manroa Dec 2019 B2
10586229 Hurry Mar 2020 B2
10594990 Lemberger Mar 2020 B1
10657242 Xia May 2020 B1
10685366 Kusens Jun 2020 B2
10692059 Thome Jun 2020 B1
10719804 Lundahl Jul 2020 B1
10789957 Tiwari Sep 2020 B1
10951606 Shahidzadeh Mar 2021 B1
11055393 Dupart Jul 2021 B2
11093589 Lowe Aug 2021 B2
11096059 Shahidzadeh Aug 2021 B1
11151562 Briggs Oct 2021 B2
11159520 Rao Oct 2021 B1
11201863 Kim Dec 2021 B2
11206664 Brown Dec 2021 B2
11258791 Giobbi Feb 2022 B2
11310228 Rao Apr 2022 B1
11354632 Hill Jun 2022 B1
11417068 Burris Aug 2022 B1
11477654 Kahn Oct 2022 B1
11503454 Chughtai Nov 2022 B2
11553481 Brown Jan 2023 B2
11564266 Kahn Jan 2023 B1
11663319 Giraud May 2023 B1
11720073 Akhlaghi Aug 2023 B2
11727386 McGraw, IV Aug 2023 B2
11734960 Wang Aug 2023 B2
11937082 Srinath Bharadwaj Mar 2024 B1
20010052083 Willins Dec 2001 A1
20020029342 Keech Mar 2002 A1
20020055852 Little May 2002 A1
20020058499 Ortiz May 2002 A1
20020089412 Heger Jul 2002 A1
20020169539 Menard Nov 2002 A1
20030051041 Kalavade Mar 2003 A1
20030063581 Shanbhag Apr 2003 A1
20030065805 Barnes, Jr. Apr 2003 A1
20030115261 Mohammed Jun 2003 A1
20030118034 Furukawa Jun 2003 A1
20030120957 Pathiyal Jun 2003 A1
20030129965 Siegel Jul 2003 A1
20030172271 Silvester Sep 2003 A1
20030182194 Choey Sep 2003 A1
20030200184 Dominguez Oct 2003 A1
20030220835 Barnes, Jr. Nov 2003 A1
20040002902 Muehlhaeuser Jan 2004 A1
20040014423 Croome Jan 2004 A1
20040073792 Noble Apr 2004 A1
20040081110 Koskimies Apr 2004 A1
20040098586 Rebo May 2004 A1
20040122774 Studd Jun 2004 A1
20040176134 Goldthwaite Sep 2004 A1
20040192211 Gallagher Sep 2004 A1
20040203563 Menard Oct 2004 A1
20040224662 O'Neil Nov 2004 A1
20040224693 O'Neil Nov 2004 A1
20040225752 O'Neil Nov 2004 A1
20040225878 Costa-Requena Nov 2004 A1
20040225887 O'Neil Nov 2004 A1
20040230489 Goldthwaite Nov 2004 A1
20040236694 Tattan Nov 2004 A1
20040250130 Billharz Dec 2004 A1
20040255137 Ying Dec 2004 A1
20040268142 Karjala Dec 2004 A1
20040268148 Karjala Dec 2004 A1
20050010758 Landrock Jan 2005 A1
20050030939 Roy Feb 2005 A1
20050033847 Roy Feb 2005 A1
20050036498 Clarke Feb 2005 A1
20050036513 Clarke Feb 2005 A1
20050038897 Clarke Feb 2005 A1
20050038915 Clarke Feb 2005 A1
20050041686 Roy Feb 2005 A1
20050065779 Odinak Mar 2005 A1
20050066044 Chaskar Mar 2005 A1
20050123141 Suzuki Jun 2005 A1
20050130586 Gnuschke Jun 2005 A1
20050147249 Gustavsson Jul 2005 A1
20050157688 Rydnell Jul 2005 A1
20050187774 Vuong Aug 2005 A1
20050250473 Brown Nov 2005 A1
20060002556 Paul Jan 2006 A1
20060020679 Hinton Jan 2006 A1
20060020960 Relan Jan 2006 A1
20060021003 Fisher Jan 2006 A1
20060021017 Hinton Jan 2006 A1
20060021018 Hinton Jan 2006 A1
20060048216 Hinton Mar 2006 A1
20060053296 Busboom Mar 2006 A1
20060059110 Madhok Mar 2006 A1
20060074698 Bishop Apr 2006 A1
20060104224 Singh May 2006 A1
20060136332 Ziegler Jun 2006 A1
20060136739 Brock Jun 2006 A1
20060136990 Hinton Jun 2006 A1
20060174004 Asthana Aug 2006 A1
20060206709 Labrou Sep 2006 A1
20060215673 Olvera-Hernandez Sep 2006 A1
20060218628 Hinton Sep 2006 A1
20060224470 Garcia Ruano Oct 2006 A1
20060235700 Wong Oct 2006 A1
20060236382 Hinton Oct 2006 A1
20070002830 Beckemeyer Jan 2007 A1
20070011099 Sheehan Jan 2007 A1
20070047719 Dhawan Mar 2007 A1
20070054655 Fantini Mar 2007 A1
20070057763 Blattner Mar 2007 A1
20070067224 Smith Mar 2007 A1
20070078986 Ethier Apr 2007 A1
20070079136 Vishik Apr 2007 A1
20070088952 Hewitt Apr 2007 A1
20070101358 Ambady May 2007 A1
20070101413 Vishik May 2007 A1
20070106564 Matotek May 2007 A1
20070175986 Petrone Aug 2007 A1
20070186105 Bailey Aug 2007 A1
20070186106 Ting Aug 2007 A1
20070198432 Pitroda Aug 2007 A1
20070204160 Chan Aug 2007 A1
20070208816 Baldwin Sep 2007 A1
20070230393 Sinha Oct 2007 A1
20070245414 Chan Oct 2007 A1
20070254648 Zhang Nov 2007 A1
20070278291 Rans Dec 2007 A1
20070293216 Jiang Dec 2007 A1
20070295805 Ramachandran Dec 2007 A1
20070297610 Chen Dec 2007 A1
20080010665 Hinton Jan 2008 A1
20080016313 Murotake Jan 2008 A1
20080021997 Hinton Jan 2008 A1
20080022043 Adams Jan 2008 A1
20080035724 Vawter Feb 2008 A1
20080043687 Lee Feb 2008 A1
20080059804 Shah Mar 2008 A1
20080085725 Grayson Apr 2008 A1
20080086764 Kulkarni Apr 2008 A1
20080086767 Kulkarni Apr 2008 A1
20080086770 Kulkarni Apr 2008 A1
20080096553 Saksena Apr 2008 A1
20080098225 Baysinger Apr 2008 A1
20080098464 Mizrah Apr 2008 A1
20080101291 Jiang May 2008 A1
20080120698 Ramia May 2008 A1
20080120707 Ramia May 2008 A1
20080147410 Odinak Jun 2008 A1
20080154770 Rutherford Jun 2008 A1
20080172306 Schorr Jul 2008 A1
20080178004 Wei Jul 2008 A1
20080189420 Herrod Aug 2008 A1
20080189774 Ansari Aug 2008 A1
20080208758 Spiker Aug 2008 A1
20080209545 Asano Aug 2008 A1
20080227471 Dankar Sep 2008 A1
20080232588 Christison Sep 2008 A1
20080270534 Xia Oct 2008 A1
20080271126 Saraf Oct 2008 A1
20080300055 Lutnick Dec 2008 A1
20080317439 Wong Dec 2008 A1
20080319794 Carlson Dec 2008 A1
20080319952 Carpenter Dec 2008 A1
20090024506 Houri Jan 2009 A1
20090036126 Morikuni Feb 2009 A1
20090055642 Myers Feb 2009 A1
20090061828 Sigmund Mar 2009 A1
20090067846 Yu Mar 2009 A1
20090070691 Jain Mar 2009 A1
20090070861 Jain Mar 2009 A1
20090108063 Jain Apr 2009 A1
20090117883 Coffing May 2009 A1
20090154671 Weiss Jun 2009 A1
20090158136 Rossano Jun 2009 A1
20090204815 Dennis Aug 2009 A1
20090239510 Sennett Sep 2009 A1
20090240774 Sachtjen Sep 2009 A1
20090248883 Suryanarayana Oct 2009 A1
20090270174 Kelly Oct 2009 A1
20090270175 Kelly Oct 2009 A1
20090271847 Karjala Oct 2009 A1
20090276347 Kargman Nov 2009 A1
20090287921 Zhu Nov 2009 A1
20090288148 Headley Nov 2009 A1
20090296930 Krantz Dec 2009 A1
20090300357 Kumar Dec 2009 A1
20090305671 Luft Dec 2009 A1
20090319616 Lewis, II Dec 2009 A1
20100009657 Dingler Jan 2010 A1
20100012721 Jain Jan 2010 A1
20100017619 Errico Jan 2010 A1
20100024022 Wells Jan 2010 A1
20100027469 Gurajala Feb 2010 A1
20100030651 Matotek Feb 2010 A1
20100042517 Paintin Feb 2010 A1
20100044444 Jain Feb 2010 A1
20100063931 Cole Mar 2010 A1
20100064135 Thakare Mar 2010 A1
20100069035 Johnson Mar 2010 A1
20100091733 Hahn Apr 2010 A1
20100100725 Ozzie Apr 2010 A1
20100107230 Tyagi Apr 2010 A1
20100115114 Headley May 2010 A1
20100125732 Cha May 2010 A1
20100125903 Devarajan May 2010 A1
20100146263 Das Jun 2010 A1
20100151831 Hao Jun 2010 A1
20100161664 Puhl Jun 2010 A1
20100189011 Jing Jul 2010 A1
20100191968 Patil Jul 2010 A1
20100192212 Raleigh Jul 2010 A1
20100198728 Aabye Aug 2010 A1
20100203903 Dingler Aug 2010 A1
20100229224 Etchegoyen Sep 2010 A1
20100262282 Segal Oct 2010 A1
20100264211 Jain Oct 2010 A1
20100273445 Dunn Oct 2010 A1
20100273457 Freeman Oct 2010 A1
20100275010 Ghirardi Oct 2010 A1
20100275249 McCann Oct 2010 A1
20100306228 Carpenter Dec 2010 A1
20100313245 Brandt Dec 2010 A1
20100319062 Danieli Dec 2010 A1
20100325040 Etchegoyen Dec 2010 A1
20110004758 Walker Jan 2011 A1
20110010543 Schmidt Jan 2011 A1
20110016050 Evans Jan 2011 A1
20110026716 Tang Feb 2011 A1
20110035592 Cha Feb 2011 A1
20110047605 Sontag Feb 2011 A1
20110069661 Waytena, Jr. Mar 2011 A1
20110075675 Koodli Mar 2011 A1
20110078243 Carpenter Mar 2011 A1
20110083167 Carpenter Apr 2011 A1
20110087610 Batada Apr 2011 A1
20110092185 Garskof Apr 2011 A1
20110106659 Faith May 2011 A1
20110113245 Varadarajan May 2011 A1
20110119720 Fan May 2011 A1
20110122864 Cherifi May 2011 A1
20110130117 Fan Jun 2011 A1
20110130118 Fan Jun 2011 A1
20110145074 Polizzotto Jun 2011 A1
20110153437 Archer Jun 2011 A1
20110153461 Royyuru Jun 2011 A1
20110154444 Sriraghavan Jun 2011 A1
20110154447 Dennis Jun 2011 A1
20110184865 Mon Jul 2011 A1
20110191237 Faith Aug 2011 A1
20110199963 Shaw Aug 2011 A1
20110202466 Carter Aug 2011 A1
20110202760 Hahn Aug 2011 A1
20110213977 Little Sep 2011 A1
20110219427 Hito Sep 2011 A1
20110225090 Hammad Sep 2011 A1
20110231478 Wheeler Sep 2011 A1
20110235085 Jazayeri Sep 2011 A1
20110237224 Coppinger Sep 2011 A1
20110238573 Varadarajan Sep 2011 A1
20110244798 Daigle Oct 2011 A1
20110246196 Bhaskaran Oct 2011 A1
20110249618 Shaw Oct 2011 A1
20110251892 Laracey Oct 2011 A1
20110258122 Shader Oct 2011 A1
20110270932 Chaturvedi Nov 2011 A1
20110282734 Zurada Nov 2011 A1
20110282789 Carroll Nov 2011 A1
20110289317 Darapu Nov 2011 A1
20110302083 Bhinder Dec 2011 A1
20110302645 Headley Dec 2011 A1
20110307403 Rostampour Dec 2011 A1
20110314153 Bathiche Dec 2011 A1
20110314168 Bathiche Dec 2011 A1
20110314287 Escott Dec 2011 A1
20110320345 Taveau Dec 2011 A1
20120005039 Dorsey Jan 2012 A1
20120005096 Dorsey Jan 2012 A1
20120011007 Blewett Jan 2012 A1
20120011066 Telle Jan 2012 A1
20120023022 Carroll Jan 2012 A1
20120023163 Mangold Jan 2012 A1
20120023558 Rafiq Jan 2012 A1
20120028609 Hruska Feb 2012 A1
20120042367 Papakostas Feb 2012 A1
20120054024 Polizzotto Mar 2012 A1
20120054046 Albisu Mar 2012 A1
20120054785 Yang Mar 2012 A1
20120072979 Cha Mar 2012 A1
20120075062 Osman Mar 2012 A1
20120076117 Montemurro Mar 2012 A1
20120076118 Montemurro Mar 2012 A1
20120078639 Kumar Mar 2012 A1
20120078751 MacPhail Mar 2012 A1
20120088473 Jussila Apr 2012 A1
20120089847 Tu Apr 2012 A1
20120092157 Tran Apr 2012 A1
20120096277 Perez Soria Apr 2012 A1
20120101952 Raleigh Apr 2012 A1
20120123841 Taveau May 2012 A1
20120131121 Snyder May 2012 A1
20120131138 Swenson May 2012 A1
20120136796 Hammad May 2012 A1
20120144198 Har Jun 2012 A1
20120144461 Rathbun Jun 2012 A1
20120149343 Sanka Jun 2012 A1
20120151570 Cooppan Jun 2012 A1
20120157062 Kim Jun 2012 A1
20120160912 Laracey Jun 2012 A1
20120173356 Fan Jul 2012 A1
20120173434 Mardikar Jul 2012 A1
20120179558 Fischer Jul 2012 A1
20120179908 Duma Jul 2012 A1
20120197740 Grigg Aug 2012 A1
20120197743 Grigg Aug 2012 A1
20120197797 Grigg Aug 2012 A1
20120197798 Grigg Aug 2012 A1
20120203557 Odinak Aug 2012 A1
20120214442 Crawford Aug 2012 A1
20120222102 Hirose Aug 2012 A1
20120230189 Fang Sep 2012 A1
20120230555 Miura Sep 2012 A1
20120231844 Coppinger Sep 2012 A1
20120242501 Tran Sep 2012 A1
20120246079 Wilson Sep 2012 A1
20120254959 Schmidt Oct 2012 A1
20120259782 Hammad Oct 2012 A1
20120265684 Singh Oct 2012 A1
20120266258 Tuchman Oct 2012 A1
20120268241 Hanna Oct 2012 A1
20120284516 Errico Nov 2012 A1
20120289191 Puura Nov 2012 A1
20120290609 Britt Nov 2012 A1
20120291124 Maria Nov 2012 A1
20120292388 Hernandez Nov 2012 A1
20120297187 Paya Nov 2012 A1
20120303425 Katzin Nov 2012 A1
20120309351 Dutta Dec 2012 A1
20120310743 Johri Dec 2012 A1
20120319815 Feldman Dec 2012 A1
20120324242 Kirsch Dec 2012 A1
20120330769 Arceo Dec 2012 A1
20130007858 Shah Jan 2013 A1
20130024360 Ballout Jan 2013 A1
20130024947 Holland Jan 2013 A1
20130031604 Esselink Jan 2013 A1
20130044609 Chen Feb 2013 A1
20130044920 Langley Feb 2013 A1
20130046645 Grigg Feb 2013 A1
20130054454 Purves Feb 2013 A1
20130055362 Rathbun Feb 2013 A1
20130069772 Najafi Mar 2013 A1
20130073432 Mulholland Mar 2013 A1
20130081119 Sampas Mar 2013 A1
20130091058 Huster Apr 2013 A1
20130091559 Thun Apr 2013 A1
20130095459 Tran Apr 2013 A1
20130095791 Bennett Apr 2013 A1
20130096916 Pemmaraju Apr 2013 A1
20130097682 Zeljkovic Apr 2013 A1
20130099891 Nandakumar Apr 2013 A1
20130103544 Nandakumar Apr 2013 A1
20130104197 Nandakumar Apr 2013 A1
20130104198 Grim Apr 2013 A1
20130104212 Nandakumar Apr 2013 A1
20130104213 Nandakumar Apr 2013 A1
20130104245 Nandakumar Apr 2013 A1
20130109348 Sharma May 2013 A1
20130111211 Winslow May 2013 A1
20130124410 Kay May 2013 A1
20130124855 Varadarajan May 2013 A1
20130125168 Agnihotri May 2013 A1
20130132277 Naqvi May 2013 A1
20130132568 Dankar May 2013 A1
20130133055 Ali May 2013 A1
20130140358 Graef Jun 2013 A1
20130145148 Shablygin Jun 2013 A1
20130145172 Shablygin Jun 2013 A1
20130145173 Shablygin Jun 2013 A1
20130145420 Ting Jun 2013 A1
20130146657 Graef Jun 2013 A1
20130149996 King Jun 2013 A1
20130151417 Gupta Jun 2013 A1
20130152174 Raley Jun 2013 A1
20130159154 Purves Jun 2013 A1
20130166448 Narayanan Jun 2013 A1
20130169526 Gai Jul 2013 A1
20130169571 Gai Jul 2013 A1
20130173284 Hyde Jul 2013 A1
20130173285 Hyde Jul 2013 A1
20130173299 Hyde Jul 2013 A1
20130173300 Hyde Jul 2013 A1
20130173301 Hyde Jul 2013 A1
20130173302 Hyde Jul 2013 A1
20130173303 Hyde Jul 2013 A1
20130173304 Hyde Jul 2013 A1
20130173305 Hyde Jul 2013 A1
20130174050 Heinonen Jul 2013 A1
20130174241 Cha Jul 2013 A1
20130179188 Hyde Jul 2013 A1
20130179346 Kumnick Jul 2013 A1
20130179681 Benson Jul 2013 A1
20130185618 Macciola Jul 2013 A1
20130189953 Mathews Jul 2013 A1
20130191899 Eldefrawy Jul 2013 A1
20130203350 Etchegoyen Aug 2013 A1
20130208893 Shablygin Aug 2013 A1
20130211940 Vu Aug 2013 A1
20130212674 Boger Aug 2013 A1
20130212704 Shablygin Aug 2013 A1
20130217361 Mohammed Aug 2013 A1
20130219456 Sharma Aug 2013 A1
20130225128 Gomar Aug 2013 A1
20130227651 Schultz Aug 2013 A1
20130227658 Leicher Aug 2013 A1
20130227675 Fujioka Aug 2013 A1
20130232064 Bosch Sep 2013 A1
20130232541 Kapadia Sep 2013 A1
20130238455 Laracey Sep 2013 A1
20130246261 Purves Sep 2013 A1
20130254660 Fujioka Sep 2013 A1
20130262311 Buhrmann Oct 2013 A1
20130263211 Neuman Oct 2013 A1
20130263238 Bidare Oct 2013 A1
20130263280 Cote Oct 2013 A1
20130264384 Wadia Oct 2013 A1
20130265136 Wadia Oct 2013 A1
20130267204 Schultz Oct 2013 A1
20130268687 Schrecker Oct 2013 A1
20130268758 Schrecker Oct 2013 A1
20130268766 Schrecker Oct 2013 A1
20130268767 Schrecker Oct 2013 A1
20130282438 Hunter Oct 2013 A1
20130283349 Liu Oct 2013 A1
20130288647 Turgeman Oct 2013 A1
20130290203 Purves Oct 2013 A1
20130290707 Sinclair Oct 2013 A1
20130291079 Lowe Oct 2013 A1
20130297933 Fiducia Nov 2013 A1
20130298200 Cai Nov 2013 A1
20130301607 McCann Nov 2013 A1
20130305035 Lyne Nov 2013 A1
20130305392 Bar-El Nov 2013 A1
20130311771 Hoggan Nov 2013 A1
20130314208 Risheq Nov 2013 A1
20130325728 Bialostok Dec 2013 A1
20130326009 Morgan Dec 2013 A1
20130331027 Rose Dec 2013 A1
20130332353 Aidasani Dec 2013 A1
20130333011 Quigley Dec 2013 A1
20130333013 Quach Dec 2013 A1
20130339498 Johnson Dec 2013 A1
20130342311 Barbaric Dec 2013 A1
20130343538 Mizikovsky Dec 2013 A1
20130346302 Purves Dec 2013 A1
20130347053 Motoyama Dec 2013 A1
20130347054 Motoyama Dec 2013 A1
20130347055 Motoyama Dec 2013 A1
20140011478 Collins Jan 2014 A1
20140016628 McCann Jan 2014 A1
20140019352 Shrivastava Jan 2014 A1
20140020070 Angal Jan 2014 A1
20140024361 Poon Jan 2014 A1
20140026160 Shrum, Jr. Jan 2014 A1
20140026187 Johnson Jan 2014 A1
20140038650 Wang Feb 2014 A1
20140040051 Ovick Feb 2014 A1
20140040135 Ovick Feb 2014 A1
20140046842 Irudayam Feb 2014 A1
20140050320 Choyi Feb 2014 A1
20140052617 Chawla Feb 2014 A1
20140058938 McClung, III Feb 2014 A1
20140058944 Ballout Feb 2014 A1
20140066013 Mascarenhas Mar 2014 A1
20140068722 Hayat Mar 2014 A1
20140068723 Grim Mar 2014 A1
20140071967 Velasco Mar 2014 A1
20140073288 Velasco Mar 2014 A1
20140073289 Velasco Mar 2014 A1
20140073375 Li Mar 2014 A1
20140081858 Block Mar 2014 A1
20140082707 Egan Mar 2014 A1
20140090018 Svigals Mar 2014 A1
20140090039 Bhow Mar 2014 A1
20140096201 Gupta Apr 2014 A1
20140096215 Hessler Apr 2014 A1
20140098671 Raleigh Apr 2014 A1
20140101426 Senthurpandi Apr 2014 A1
20140101434 Senthurpandi Apr 2014 A1
20140101453 Senthurpandi Apr 2014 A1
20140106710 Rodriguez Apr 2014 A1
20140109178 Barton Apr 2014 A1
20140113556 Kotecha Apr 2014 A1
20140115333 King Apr 2014 A1
20140123224 Nosrati May 2014 A1
20140137199 Hefetz May 2014 A1
20140143064 Tran May 2014 A1
20140143839 Ricci May 2014 A1
20140148123 Raleigh May 2014 A1
20140150059 Uchida May 2014 A1
20140157298 Murphy Jun 2014 A1
20140162598 Villa-Real Jun 2014 A1
20140164254 Dimmick Jun 2014 A1
20140164774 Nord Jun 2014 A1
20140165134 Goldschlag Jun 2014 A1
20140165170 Dmitriev Jun 2014 A1
20140165178 Perrone, II Jun 2014 A1
20140166745 Graef Jun 2014 A1
20140173692 Srinivasan Jun 2014 A1
20140173700 Awan Jun 2014 A1
20140173704 Adams Jun 2014 A1
20140180826 Boal Jun 2014 A1
20140180850 Ackley Jun 2014 A1
20140183269 Glaser Jul 2014 A1
20140187205 Dankar Jul 2014 A1
20140188738 Huxham Jul 2014 A1
20140189808 Mahaffey Jul 2014 A1
20140198687 Raleigh Jul 2014 A1
20140199961 Mohammed Jul 2014 A1
20140199962 Mohammed Jul 2014 A1
20140201517 Corrion Jul 2014 A1
20140201537 Sampas Jul 2014 A1
20140214688 Weiner Jul 2014 A1
20140233831 Palmer Aug 2014 A1
20140236728 Wright Aug 2014 A1
20140237591 Niemela Aug 2014 A1
20140241635 Ruppaner Aug 2014 A1
20140244617 Rose Aug 2014 A1
20140244783 Ortiz Aug 2014 A1
20140245391 Adenuga Aug 2014 A1
20140245459 Ortiz Aug 2014 A1
20140250105 Shankar Sep 2014 A1
20140256251 Caceres Sep 2014 A1
20140258120 Specogna Sep 2014 A1
20140259115 Bakshi Sep 2014 A1
20140259147 L'Heureux Sep 2014 A1
20140263618 McCarthy Sep 2014 A1
20140270126 Torgersrud Sep 2014 A1
20140273824 Fenner Sep 2014 A1
20140279477 Sheets Sep 2014 A1
20140279513 Dodds-Brown Sep 2014 A1
20140281946 Avni Sep 2014 A1
20140282961 Dorfman Sep 2014 A1
20140282985 Joseph Sep 2014 A1
20140283136 Dougherty Sep 2014 A1
20140289116 Polivanyi Sep 2014 A1
20140289833 Briceno Sep 2014 A1
20140289834 Lindemann Sep 2014 A1
20140298430 Tomasik Oct 2014 A1
20140310764 Tippett Oct 2014 A1
20140324638 Khalid Oct 2014 A1
20140331060 Hayton Nov 2014 A1
20140333415 Kursun Nov 2014 A1
20140337221 Hoyos Nov 2014 A1
20140337227 Dua Nov 2014 A1
20140337243 Dutt Nov 2014 A1
20140337949 Hoyos Nov 2014 A1
20140337954 Ahmed Nov 2014 A1
20140341185 Yoon Nov 2014 A1
20140344909 Raji Nov 2014 A1
20140351899 Dennis Nov 2014 A1
20140359722 Schultz Dec 2014 A1
20140372319 Wolovitz Dec 2014 A1
20140376703 Timem Dec 2014 A1
20140379339 Timem Dec 2014 A1
20140379340 Timem Dec 2014 A1
20140379525 Timem Dec 2014 A1
20140380425 Lockett Dec 2014 A1
20150004934 Qian Jan 2015 A1
20150012425 Mathew Jan 2015 A1
20150015365 Ortiz Jan 2015 A1
20150019424 Pourfallah Jan 2015 A1
20150019944 Kalgi Jan 2015 A1
20150025971 Shipley Jan 2015 A1
20150026049 Theurer Jan 2015 A1
20150026055 Calman Jan 2015 A1
20150026056 Calman Jan 2015 A1
20150026057 Calman Jan 2015 A1
20150033289 Caceres Jan 2015 A1
20150035643 Kursun Feb 2015 A1
20150058941 Lyman Feb 2015 A1
20150063661 Lee Mar 2015 A1
20150067785 Donnellan Mar 2015 A1
20150067823 Chatterton Mar 2015 A1
20150072726 Stern Mar 2015 A1
20150073987 Dutt Mar 2015 A1
20150074259 Ansari Mar 2015 A1
20150074745 Stern Mar 2015 A1
20150074764 Stern Mar 2015 A1
20150077326 Kramer Mar 2015 A1
20150089585 Novack Mar 2015 A1
20150089607 Hubner Mar 2015 A1
20150089613 Tippett Mar 2015 A1
20150089621 Khalid Mar 2015 A1
20150095773 Gonsalves Apr 2015 A1
20150096001 Morikuni Apr 2015 A1
20150106265 Stubblefield Apr 2015 A1
20150106869 Cabrera Apr 2015 A1
20150109428 Mechaley, Jr. Apr 2015 A1
20150120549 Khalid Apr 2015 A1
20150120878 Horgan Apr 2015 A1
20150121506 Cavanaugh Apr 2015 A1
20150125832 Tran May 2015 A1
20150134340 Blaisch May 2015 A1
20150142647 Johnson May 2015 A1
20150143116 Tang May 2015 A1
20150156601 Donnellan Jun 2015 A1
20150163121 Mahaffey Jun 2015 A1
20150177978 Kuo Jun 2015 A1
20150181364 Chen Jun 2015 A1
20150181424 Hardy Jun 2015 A1
20150186636 Tharappel Jul 2015 A1
20150186872 Sobol Jul 2015 A1
20150195278 Plotkin Jul 2015 A1
20150215299 Burch Jul 2015 A1
20150215315 Gordon Jul 2015 A1
20150220912 Holdsworth Aug 2015 A1
20150221151 Bacco Aug 2015 A1
20150222604 Ylonen Aug 2015 A1
20150222615 Allain Aug 2015 A1
20150223056 Ludwig Aug 2015 A1
20150227725 Grigg Aug 2015 A1
20150227731 Grigg Aug 2015 A1
20150227734 Mucci Aug 2015 A1
20150242605 Du Aug 2015 A1
20150242609 Zheng Aug 2015 A1
20150244796 Joy Aug 2015 A1
20150244876 Jabara Aug 2015 A1
20150249540 Khalil Sep 2015 A1
20150257004 Shanmugam Sep 2015 A1
20150278495 Yu Oct 2015 A1
20150278556 Avni Oct 2015 A1
20150281888 Muttik Oct 2015 A1
20150287018 Iqbal Oct 2015 A1
20150288687 Heshmati Oct 2015 A1
20150304322 Zaidi Oct 2015 A1
20150319610 Hartog Nov 2015 A1
20150326570 Publicover Nov 2015 A1
20150334554 Song Nov 2015 A1
20150350902 Baxley Dec 2015 A1
20150358400 Bartlett, II Dec 2015 A1
20150373020 Hale Dec 2015 A1
20150381602 Grim Dec 2015 A1
20150381633 Grim Dec 2015 A1
20150382195 Grim Dec 2015 A1
20160006718 Huxham Jan 2016 A1
20160012390 Skaaksrud Jan 2016 A1
20160014102 Gamer Jan 2016 A1
20160014605 Robinton Jan 2016 A1
20160021537 Dennis Jan 2016 A1
20160027016 McGraw Jan 2016 A1
20160028770 Raleigh Jan 2016 A1
20160036810 Kim Feb 2016 A1
20160036825 Manroa Feb 2016 A1
20160037438 Manroa Feb 2016 A1
20160048846 Douglas Feb 2016 A1
20160050203 Hefetz Feb 2016 A1
20160063235 Tussy Mar 2016 A1
20160080937 Pieczul Mar 2016 A1
20160094701 Hund Mar 2016 A1
20160109954 Harris Apr 2016 A1
20160119870 Chang Apr 2016 A1
20160127989 Zhang May 2016 A1
20160165645 Commons Jun 2016 A1
20160174069 Bruner Jun 2016 A1
20160183085 Yerrabommanahalli Jun 2016 A1
20160198341 Fransen Jul 2016 A1
20160212103 Rhoads Jul 2016 A1
20160234690 Michalski Aug 2016 A1
20160248762 Higashibata Aug 2016 A1
20160249396 Kolekar Aug 2016 A1
20160352713 Grissen Dec 2016 A1
20160360406 Shen Dec 2016 A1
20160366586 Gross Dec 2016 A1
20160366587 Gross Dec 2016 A1
20160379211 Hoyos Dec 2016 A1
20170011210 Cheong Jan 2017 A1
20170041791 Zhang Feb 2017 A1
20170041986 Sela Feb 2017 A1
20170064551 Block Mar 2017 A1
20170078260 Shen Mar 2017 A1
20170093846 Lopez Lecube Mar 2017 A1
20170103440 Xing Apr 2017 A1
20170111487 Musial Apr 2017 A1
20170127230 Enriquez May 2017 A1
20170150358 Zhang May 2017 A1
20170156090 Bhumkar Jun 2017 A1
20170169424 Maddocks Jun 2017 A1
20170171754 South Jun 2017 A1
20170251366 Perna Aug 2017 A1
20170264645 Tipton Sep 2017 A1
20170277487 Chang Sep 2017 A1
20170280310 Jain Sep 2017 A1
20170303160 Poltorak Oct 2017 A1
20170346851 Drake Nov 2017 A1
20170364899 Watson Dec 2017 A1
20180014193 Dennis Jan 2018 A1
20180026949 Kimn Jan 2018 A1
20180026973 Le Saint Jan 2018 A1
20180032997 Gordon Feb 2018 A1
20180039990 Lindemann Feb 2018 A1
20180049028 Tali Feb 2018 A1
20180063125 Bryant Mar 2018 A1
20180063764 Bollapalli Mar 2018 A1
20180102008 Dupart Apr 2018 A1
20180103341 Moiyallah, Jr. Apr 2018 A1
20180114387 Klink Apr 2018 A1
20180115897 Einberg Apr 2018 A1
20180160304 Liu Jun 2018 A1
20180181735 Yang Jun 2018 A1
20180204204 Giraudo Jul 2018 A1
20180241577 D'Souza Aug 2018 A1
20180248892 Hefetz Aug 2018 A1
20180270608 Thoresen Sep 2018 A1
20180270612 Thoresen Sep 2018 A1
20180300678 Drako Oct 2018 A1
20180302414 Wagner Oct 2018 A1
20180351375 Baldasare Dec 2018 A1
20180357406 Bolotin Dec 2018 A1
20180368058 Huang Dec 2018 A1
20190080538 Shahidi Mar 2019 A1
20190092280 Oesterling Mar 2019 A1
20190158469 Gonzalez May 2019 A1
20190174011 Jabara Jun 2019 A1
20190180742 Kothari Jun 2019 A1
20190182627 Thoresen Jun 2019 A1
20190213311 Tussy Jul 2019 A1
20190213312 Tussy Jul 2019 A1
20190228178 Sharma Jul 2019 A1
20190263424 Penilla Aug 2019 A1
20190268334 Kurian Aug 2019 A1
20190274046 Lierman Sep 2019 A1
20190288837 St Amant Sep 2019 A1
20190311102 Tussy Oct 2019 A1
20190357049 Tali Nov 2019 A1
20190370699 Chaplow Dec 2019 A1
20200029213 Nölscher Jan 2020 A1
20200042685 Tussy Feb 2020 A1
20200068643 Dowlatkhah Feb 2020 A1
20200092272 Eisen Mar 2020 A1
20200186352 Arora Jun 2020 A1
20200193749 Link, II Jun 2020 A1
20200210988 Woodward Jul 2020 A1
20200228969 Shin Jul 2020 A1
20200236116 Bower Jul 2020 A1
20200259896 Sachs Aug 2020 A1
20200267144 Wagner Aug 2020 A1
20200267553 Wagner Aug 2020 A1
20200275267 Wang Aug 2020 A1
20200275546 Marshal Aug 2020 A1
20200279255 Douglas Sep 2020 A1
20200279269 Wagner Sep 2020 A1
20200293753 Sehgal Sep 2020 A1
20200294042 Day Sep 2020 A1
20200336906 Belhareth Oct 2020 A1
20200383034 Oetting Dec 2020 A1
20200402052 Sloane Dec 2020 A1
20200402334 Conrad Dec 2020 A1
20200403990 Storm Dec 2020 A1
20200412133 Baldasare Dec 2020 A1
20210029540 Sodano Jan 2021 A1
20210067935 Amaral Costa Mar 2021 A1
20210086726 Hassani Mar 2021 A1
20210096559 Diamond Apr 2021 A1
20210097156 Kröselberg Apr 2021 A1
20210105169 Choi Apr 2021 A1
20210112488 Meredith Apr 2021 A1
20210158325 Mimassi May 2021 A1
20210158384 Mimassi May 2021 A1
20210168116 Shulman Jun 2021 A1
20210174321 Rose Jun 2021 A1
20210176242 McDougall Jun 2021 A1
20210206350 Henderson Jul 2021 A1
20210211279 Nix Jul 2021 A1
20210226921 Rose Jul 2021 A1
20210240293 Van Ostrand Aug 2021 A1
20210249882 Baldasare Aug 2021 A1
20210256833 Daoura Aug 2021 A1
20210258774 Ramsay, III Aug 2021 A1
20210265843 Baldasare Aug 2021 A1
20210288951 Rose Sep 2021 A1
20210295304 Iqbal Sep 2021 A1
20210357489 Tali Nov 2021 A1
20210358247 Novozhenets Nov 2021 A1
20210360742 Liao Nov 2021 A1
20210377350 Nelluri Dec 2021 A1
20220014527 Ratnakaram Jan 2022 A1
20220030427 Megerdichian Jan 2022 A1
20220092162 Keith, Jr. Mar 2022 A1
20220092163 Keith, Jr. Mar 2022 A1
20220092164 Keith, Jr. Mar 2022 A1
20220092165 Keith, Jr. Mar 2022 A1
20220103640 Root Mar 2022 A1
20220138746 Rodriguez May 2022 A1
20220166768 Barkan May 2022 A1
20220181887 Baldasare Jun 2022 A1
20220270144 Mimassi Aug 2022 A1
20220272536 Anderson Aug 2022 A1
20220294894 Hefetz Sep 2022 A1
20220303802 Otaka Sep 2022 A1
20220312195 Schnabel Sep 2022 A1
20220394468 Avetisov Dec 2022 A1
20220408263 Hoggat Dec 2022 A1
20230106024 Keith, Jr. Apr 2023 A1
20230111629 Van Wageningen Apr 2023 A1
20230262460 Kunz Aug 2023 A1
20230306548 Potts Sep 2023 A1
20230359714 Cristache Nov 2023 A1
20230394127 Tussy Dec 2023 A1
20240095698 Thimmareddy Mar 2024 A1
20240104533 Thimmareddy Mar 2024 A1
20240127206 Thimmareddy Apr 2024 A1
20240129725 Woo Apr 2024 A1
20240143706 Bacastow May 2024 A1
20240196181 Grayson Jun 2024 A1
20240202297 Bolotin Jun 2024 A1
20240217528 Oh Jul 2024 A1
20250055560 Edge Feb 2025 A1
Foreign Referenced Citations (2)
Number Date Country
2976706 Jan 2016 EP
WO-2023212038 Nov 2023 WO
Non-Patent Literature Citations (12)
Entry
Chean et al “Authentication Scheme using Unique Identification Method with Homomorphic Encryption in Mobile Cloud Computing,” IEEE, pp. 195-200 (Year: 2018).
Shrestha et al “Context-Enhanced Mobile Device Authorization and Authentication,” A Dissertation, pp. 1-186 (Year: 2016).
Lee et al “Fast Authentication in Multi-Hop Infrastructure-based Mobile Communication,” IEEE ICC 2014—Communication and Information Systems Security Symposium, pp. 665-670 (Year: 2014).
Dellutri et al “Local Authentication with Bluetooth enabled Mobile Devices,” IEEE Computer Society, pp. 1-6 (Year: 2005).
Das et al “Designing a Biometric Strategy (Fingerprint) Measure for Enhacing ATM Security in Indian E-Banking System,” International Journal of Information and Communication Technology Research, vol. 1, No. 5, Sep. 2011, pp. 197-203 (Year: 2011).
Clodfelter et al “Biometric Technology in Retailing: Will Consumers Accept Fingerprint Authentication?”, Journal of Retailing and Consumer Services, pp. 181-188 (Year: 2010).
Chen et al “Secondary User Authentication based on Mobile Devices Location,” 2010 Fifth IEEE International Conference on Networking, Architecture and Storage, IEEE Computer Society, pp. 277-281 (Year: 2010).
Biometric-Kerberos Authentication Scheme for Secure Mobile Computing Services, 2013 6th International Congress on Image and Signal Processing (CISP 2013), IEEE, pp. 1-5 (Year: 2013).
Ghazia et al “Comparative Analysis of Access Control Systems on Cloud,” IEEE Computer Society, pp. 41-46 (Year: 2012).
Gusmeroli et al “IoT Access Control Issues: a Capability Based Approach,” IEEE, pp. 787-792.
Shacham et al “The Virtual Device: Expanding Wireless Communication Services through Service Discovery and Session Mobility,” IEEE, pp. 73-81 (Year: 2005).
Akyol et al “Signaling Alternatives in a Wireless ATM Network,” IEEE, pp. 35-49 (Year: 1997).
Related Publications (1)
Number Date Country
20250142325 A1 May 2025 US
Provisional Applications (2)
Number Date Country
62102857 Jan 2015 US
61976703 Apr 2014 US
Continuations (3)
Number Date Country
Parent 17343241 Jun 2021 US
Child 18496831 US
Parent 16569658 Sep 2019 US
Child 17343241 US
Parent 14680857 Apr 2015 US
Child 16569658 US