US20200234272A1 - Hands-free processing with a confirmation request - Google Patents

Abstract

An application on a user computing device receives a beacon identifier from a service computing device, generates a first service request token, and transmits the first service request token to the service computing device. The application on the user computing device transmits a first communication comprising the first service request token, an account identifier, and the beacon identifier to a service request processing system. The service request processing system receives, from a service computing device, a request comprising the first service request token and the service request data. The service request processing system determines that the service request exceeds a configured service request limit, communicates, to the application on the user computing device, a request for an authorization of the service request, and receives an authorization for the service request from the application on the user computing device, and processes the service request in response to receiving the authorization.

Description

TECHNICAL FIELD
• The present disclosure relates to conducting hands-free service requests.
BACKGROUND
• When users make service requests at a location, many methods of conducting a service request are available. Identifiers and other data represented by the methods may be communicated to the service system via devices, proximity communication technologies, and other suitable mechanisms.
• Conventional service request processing systems require the user to perform actions to provide identifiers and other data to the service system. For example, the user may be required to actuate a start button or initiate an application. In another example, the user may be required to tap or swipe a user computing device to initiate a service request. Other user interactions may be required by conventional service request processing systems.
SUMMARY
• Techniques herein provide computer-implemented methods to process hands-free service requests when service request limits are exceeded. In an example embodiment, conducting hands-free service requests comprises a server at a service request processing system, a user computing device, and a service computing device. An application on the user computing device receives a beacon identifier from a service computing device, generates a first service request token, and transmits the first service request token to the service computing device, wherein the service computing device associates service request data with the first service request token. The application on the user computing device transmits a first communication comprising the first service request token, an account identifier, and the beacon identifier. The service request processing system receives, from a service request comprising, the first service request token and the service request data. The service request processing system determines, based on the service request data, that the service request exceeds a configured service request limit for hands-free service requests associated with the account identifier. The service request processing system communicates, to the application on the user computing device, a request for an authorization of the service request that exceeds the configured service request limit and receives an authorization for the service request from the application on the user computing device. The service request processing system the service request in response to receiving the authorization.
• In certain other example aspects described herein, systems and computer program products to conduct hands-free service requests are provided.
• These and other aspects, objects, features, and advantages of the example embodiments will become apparent to those having ordinary skill in the art upon consideration of the following detailed description of illustrated example embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram depicting a system for conducting hands-free service requests, in accordance with certain example embodiments.
• FIG. 2 is a block flow diagram depicting a method for conducting hands-free service requests, in accordance with certain example embodiments.
• FIG. 3 is a block flow diagram depicting a method for broadcasting a beacon via a wireless communication, in accordance with certain example embodiments.
• FIG. 4 is a block flow diagram depicting a method for recognizing a beacon, in accordance with certain example embodiments.
• FIG. 5 is a block flow diagram depicting a method for identifying a user and transmitting a service request, in accordance with certain example embodiments.
• FIG. 6 is a block flow diagram depicting a method for identifying a user and transmitting a service request based on voice patterns of a user, in accordance with certain example embodiments.
• FIG. 7 is a block flow diagram depicting a method for conducting hands-free service requests with a confirmation, in accordance with certain example embodiments.
• FIG. 8 is a block flow diagram depicting a method for a processing system to request a confirmation, in accordance with certain example embodiments.
• FIG. 9 is a block diagram depicting a computing machine and module, in accordance with certain example embodiments.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTSOverview
• The example embodiments described herein provide computer-implemented techniques to conduct hands-free payments. In an example embodiment, a user installs a hands-free application on a user computing device. The user maintains a user account on a payment processing system for conducting transactions. A merchant computing device at a merchant location provides a beacon identifier that is received by the user computing device.
• The user computing device generates a token for conducting a transaction and transmits the token to the payment processing system. Upon a verification, the payment processing system transmits the token to the merchant computing device. The merchant computing device stores the token for use in a transaction with the user computing device.
• The user approaches the salesperson to conduct a transaction using the hands-free application. The salesperson initiates the transaction on the merchant computing device and offers a challenge to the user for identification of the user account. In an example, the salesperson asks for the initials of the user. The salesperson inputs the response to the challenge in the merchant computing device. One or more user accounts are displayed to the salesperson for selection based on the input of the response. In an example, a picture and a name of each of the one or more users is displayed. The salesperson identifies the user account on a user interface of the merchant computing device from the one or more users displayed.
• The merchant computing device transmits the transaction details and the token for the user account to the payment processing system. The payment processing system verifies the details of the transaction and the token, and conducts the transaction. The payment processing system may communicate a notification to the user computing device with the transaction data.
• In another example embodiment, when the payment processing system receives the transaction details and the token for the user account from the merchant device, the payment processing system is restricted from conducting the transaction by a configured setting in the user account or in the token. For example, the user account has a configured limit of $50 for hands-free transactions without a user authorization. If the amount of the pending transaction is over $50, the payment processing system transmits an authorization request to the user computing device for the transaction.
• The user device displays a request to the user to input an authorization or a refusal of the transaction. Upon receiving an input of an acceptance, the user computing device creates a second token comprising the authorization of the transaction. The second token is transmitted to the payment processing system. The payment processing system conducts the transaction using the second token.
• In certain example embodiments, instead of a challenge and response, the merchant computing device may use voice recognition software to identify the user. For example, the salesperson may ask the user a question and the merchant computing device receives the audible response. The merchant computing device compares the voice pattern of the user to a database of voice patterns and identifies the user.
• If a strong match exists for any of the stored voice patterns, the hands-free payment application retrieves the user account associated with the matching speaker identification model and conducts the transaction with the user account.
• In another example embodiment, the merchant computing device may capture a picture of the user using a camera module on the merchant computing device. The merchant computing device may match the picture against a local database of pictures. The matching of the pictures may take place on the merchant computing device, at the payment processing system, of in any suitable location. In an example, the merchant computing device may access a database of images and match the image of the that has been captured by the merchant computing device. Upon locating a match, the merchant computing device may verify that the user matches the user account being utilized for the transaction. In another example, the merchant computing device may receive an image from the payment processing system or other location in advance of the consumer approaching the merchant terminal device. For example, the image may be obtained at the time that the consumer enters the store.
• In another example embodiment, the challenges are presented based on risk signals derived from features such as (1) user's risk profile (2) the risk tolerance of merchant and (3) number of users who have checked in to the store. For example, for a low value transaction, the merchant computing device may utilize a simple challenge, but a more complex challenge for a high value transaction. In another example, if only one user is at the location of the merchant, then a complex challenge may not be needed to identify the user.
• By using and relying on the methods and systems described herein, the hands-free application and payment processing system dynamically provide accurate, efficient, secure, and reliable transactions for a user. As such, the systems and methods described herein may be employed to allow the user to conduct a transaction using communications from the user computing device, the merchant computing device, and the payment processing system that are secure and efficient. The user is allowed to conduct hands-free transactions with a confirmation request to allow the user to conduct transactions that are secure and resistant to fraud. The user is allowed to conduct hands-free transactions with a challenge and response to conduct transactions that are secure, efficient, and resistant to fraud. The user is allowed to conduct hands-free transactions with a voice recognition confirmation to conduct transactions that are secure, efficient, and resistant to fraud. The system may use communication between the user computing device and the payment processing system to reduce fraudulent activities by the merchant. Hence, the methods and systems described herein decrease user frustration and permit accurate, secure, efficient, and reliable transactions for a user.
Example System Architectures
• Turning now to the drawings, in which like numerals indicate like (but not necessarily identical) elements throughout the figures, example embodiments are described in detail.
• FIG. 1 is a block diagram depicting asystem100 for conducting hands-free transactions, in accordance with certain example embodiments. As depicted inFIG. 1, thesystem100 includesnetwork computing devices110,130,140, and150 that are configured to communicate with one another via one ormore networks120. In some embodiments, auser101 or asalesperson102 associated with a device must install an application and/or make a feature selection to obtain the benefits of the techniques described herein.
• In example embodiments, thenetwork120 can include a local area network (“LAN”), a wide area network (“WAN”), an intranet, an Internet, storage area network (“SAN”), personal area network (“PAN”), a metropolitan area network (“MAN”), a wireless local area network (“WLAN”), a virtual private network (“VPN”), a cellular or other mobile communication network, Bluetooth, Bluetooth low energy, near field communication (“NFC”), Wi-Fi, or any combination thereof or any other appropriate architecture or system that facilitates the communication of signals, data, and/or messages. Throughout the discussion of example embodiments, it should be understood that the terms “data” and “information” are used interchangeably herein to refer to text, images, audio, video, or any other form of information that can exist in a computer-based environment.
• Eachnetwork computing system110,130,140, and150 includes a device having a communication module capable of transmitting and receiving data over thenetwork120. For example, eachnetwork computing device110,130,140, and150 can include a server, desktop computer, laptop computer, tablet computer, a television with one or more processors embedded therein and/or coupled thereto, smart phone, handheld computer, personal digital assistant (“PDA”), or any other wired or wireless, processor-driven device. In the example embodiment depicted inFIG. 1, thenetwork computing devices110,130,140, and150 are operated byusers101, merchant system operators, payment processing system operators, andsalespersons102, respectively.
• In the examples provided herein, actions performed by theuser101 may be performed by thesalesperson102 in other embodiments. Examples described as being performed by the user computing device110 may be performed by themerchant computing device150 or thepayment processing system140 in other embodiments.
• An example user computing device110 comprises adata storage unit112, acommunication application113, aweb browser114, auser interface115, a global positioning system (“GPS”)module118, and a hands-free payment application116.
• In an example embodiment, thedata storage unit112 comprises a local or remote data storage structure accessible to the user computing device110 suitable for storing information. In an example embodiment, thedata storage unit112 stores encrypted information, such as HTML5 local storage.
• In an example embodiment, theuser101 uses acommunication application113, such as aweb browser114 application or a stand-alone hands-free payment application116, to view, download, upload, or otherwise access documents or web pages via a distributednetwork120.
• In an example embodiment, thecommunication application113 can interact with web servers or other computing devices connected to thenetwork120, including the user computing device110, a point of sale (“POS”) terminal134 associated with amerchant system130 and/or a web server (not depicted) associated with apayment processing system140.
• In an example embodiment, theweb browser114 can enable theuser101 to interact with web pages using the user computing device110.
• In an example embodiment, theuser interface115 enables theuser101 to interact with the hands-free payment application116 and/orweb browser114. For example, theuser interface115 may be a touch screen, a voice-based interface, or any other interface that allows theuser101 to provide input and receive output from an application or module on the user computing device110. In an example embodiment, theuser101 interacts via theuser interface115 with the hands-free payment application116 and/orweb browser114 to configure user accounts on a payment processing system hands-free module141. In another example embodiment, theuser101 interacts via theuser interface115 with the hands-free payment application116 and/or theweb browser114 to enable hands-free payments, if needed.
• In an example embodiment, theGPS module118 communicates with one or more satellites of the Global Positioning System (“GPS”) or other satellite-based location system to determine the location of the user computing device110. In an example embodiment, thedelivery system140 periodically or continuously communicates with theGPS module118 during applicable time periods to determine and log the location of the user computing device110. In another embodiment, the location of the user computing device110 is identified based on Wi-Fi signals, cellular location, or any suitable location identifying technology. Any location determining hardware, software, or combination of hardware and software is represented by theGPS module118.
• In an example embodiment, the hands-free payment application116 is a program, function, routine, applet, or similar entity that exists on and performs its operations on the user computing device110. In certain example embodiments, theuser101 must install the hands-free payment application116 and/or make a feature selection on the user computing device110 to obtain the benefits of the techniques described herein. In an example embodiment, theuser101 may access the hands-free payment application116 on the user computing device110 via theuser interface115. In an example embodiment, the hands-free payment application116 may be associated with thepayment processing system140. In another example embodiment, the application may be associated with themerchant system130. In yet another example embodiment, two hands-free payment applications116 exist, one associated with themerchant system130 and another associated with thepayment processing system140.
• In certain example embodiments, one or more functions herein described as performed by the hands-free payment application116 may also be performed by aweb browser114 application, for example, aweb browser114 application associated with amerchant system website134 or associated with thepayment processing system140. In certain example embodiments, one or more functions herein described as performed by the hands-free payment application116 may also be performed by the user computing device operating system. In certain example embodiments, one or more functions herein described as performed via theweb browser114 may also be performed via the hands-free payment application116.
• In an example embodiment, the user computing device110 communicates with themerchant system130 and thepayment processing system140 via thenetwork120.
• Anexample merchant system130 comprises aserver133,POS terminal134, and adata storage unit132. In an example embodiment, themerchant system130 communicates with apayment processing system140 over thenetwork120. In example embodiments described herein, themerchant system130 is a separate entity from thepayment processing system140. However, in certain other example embodiments, themerchant system130 is associated with apayment processing system140, is a component of another system along with apayment processing system140, comprises apayment processing system140, or is a component of apayment processing system140.
• In an example embodiment, thedata storage unit132 comprises a local or remote data storage structure accessible to themerchant system130 suitable for storing information. In an example embodiment, thedata storage unit132 stores encrypted information, such as HTML5 local storage.
• In an example embodiment, theweb server133 provides content accessible by theuser101 through theweb browser114 and/or hands-free payment application116 on the user computing device110, including but not limited to html documents, images, style sheets, and scripts. In an example embodiment, theserver133 supports themerchant system website134.
• In an example embodiment, thePOS terminal134 comprises a computing device that is configured to accept payments fromusers101, from user computing devices110, or other parties. ThePOS terminal134 may communicate, via the network, with the user computing device110, themerchant server133, themerchant computing device150, thepayment processing system140, or any suitable device or system. ThePOS terminal134 may comprise a barcode scanner, a user interface, a customer display, or any suitable elements to enable thesalesperson102 to initiate and conduct a transaction. ThePOS terminal134 in the example embodiments may comprise a function enabling thesalesperson102 to input an indication that the transaction was conducted with the hands-free application156 on themerchant computing device150, and that thePOS terminal134 should consider the transaction completed.
• An examplepayment processing system140 comprises a payment processing system hands-free module141 and adata storage unit142. In an example embodiment, theuser101 has a user account with thepayment processing system140. In an example embodiment, the payment processing system hands-free module141 manages the user account. For example, the payment processing system hands-free module141 may receive a user's username and password and allow theuser101 to access services provided by thepayment processing system140. In an example embodiment, the payment processing system hands-free module141 communicates with the hands-free payment application116 resident on the user computing device110. In another example embodiment, the payment processing system hands-free module141 communicates with theuser101 via the user computingdevice web browser114. In an example embodiment, the payment processing system hands-free module141 manages the user's digital wallet account.
• In an example embodiment, the payment processing system hands-free module141 communicates with themerchant system130, account issuer systems (not depicted) and/or acquirers (not depicted), or other suitable financial systems (not depicted) to process payments. In an example embodiment, the payment processing system hands-free module141 retrieves user financial account information and credit account information from other financial institutions, from thedata storage unit142, or by communicating with the hands-free payment application116 over thenetwork120. In an example embodiment, the payment processing system hands-free module141 requests a credit authorization from an issuer system through an acquirer system and receives the credit authorization. In an example embodiment, the payment processing system hands-free module141 initiates a bank transfer with a financial institution system. In an example embodiment, the payment processing system hands-free module141 receives the bank transfer or completes a credit card transaction associated with the credit card authorization.
• In certain example embodiments, the payment processing system hands-free module141 creates tokens, verifies tokens, verifies rescue codes, and performs other actions as described herein. In an example embodiment, the payment processing system hands-free module141 generates a receipt of a transaction and transmits the receipt to the user computing device110.
• In an example embodiment, thedata storage unit142 comprises any local or remote data storage structure accessible to the payment processing system hands-free module141 suitable for storing information. In an example embodiment, thedata storage unit142 stores encrypted information, such as HTML5 local storage. In an example embodiment, thedata storage unit142 stores user financial account information and/or user credit account information.
• An examplemerchant computing device150 comprises adata storage unit152, acommunication application153, aweb browser154, auser interface155, and a hands-free payment application156.
• In an example embodiment, thedata storage unit152 comprises a local or remote data storage structure accessible to themerchant computing device150 suitable for storing information. In an example embodiment, thedata storage unit152 stores encrypted information, such as HTML5 local storage.
• In an example embodiment, thesalesperson102 uses acommunication application153, such as aweb browser154 application or a stand-alone hands-free payment application116, to view, download, upload, or otherwise access documents or web pages via a distributednetwork120.
• In an example embodiment, thecommunication application153 can interact with web servers or other computing devices connected to thenetwork120, including themerchant POS terminal134, aweb server133 associated with amerchant system130 and/or a payment processing system hands-free module141.
• In an example embodiment, theweb browser154 can enable thesalesperson102 to interact with web pages using themerchant computing device150. In an example embodiment, thesalesperson102 is able to access transaction information form thePOS terminal134, and access user account information from the user computing device110 and/or the payment processing system hands-free module141.
• In an example embodiment, theuser interface155 enables thesalesperson102 to interact with the hands-free payment application156 and/orweb browser154. For example, theuser interface155 may be a touch screen, a voice-based interface or any other interface that allows thesalesperson102 to provide input and receive output from an application or module on themerchant computing device150. In an example embodiment, thesalesperson102 interacts via theuser interface155 with the hands-free payment application156 and/orweb browser154 to access a user token to conduct a transaction via thepayment processing system140.
• In an example embodiment, the hands-free payment application156 is a program, function, routine, applet, or similar entity that exists on and performs operations on themerchant computing device150. In certain example embodiments, thesalesperson102 must install the hands-free payment application156 and/or make a feature selection on themerchant computing device150 to obtain the benefits of the techniques described herein. In an example embodiment, thesalesperson102 may access the hands-free payment application156 on themerchant computing device150 via theuser interface155. In an example embodiment, the hands-free payment application156 may be associated with themerchant system130. In another example embodiment, the application may be associated with thepayment processing system140. In yet another example embodiment, there are twoapplications156, one associated with themerchant system130 and another associated with thepayment processing system140.
• In certain example embodiments, one or more functions herein described as performed by the hands-free payment application156 may also be performed by aweb browser154 application, for example, aweb browser154 application associated with amerchant system website134 or associated with thepayment processing system140. In certain example embodiments, one or more functions herein described as performed by the hands-free payment application156 may also be performed by the merchant computing device operating system. In certain example embodiments, one or more functions herein described as performed via theweb browser154 may also be performed via the hands-free payment application156.
• In certain alternate example embodiments, themerchant computing device150 may be part of themerchant system130. Themerchant computing device150 functions described herein may be performed by themerchant server133,POS terminal134, or other merchant device.
• It will be appreciated that the network connections shown are example and other means of establishing a communications link between the computers and devices can be used. Moreover, those having ordinary skill in the art having the benefit of the present disclosure will appreciate that the user computing device110, themerchant system130, thePOS terminal134, thepayment processing system140, and themerchant computing device150 illustrated inFIG. 1 can have any of several other suitable computer system configurations. For example, a user computing device110 embodied as a mobile phone or handheld computer may or may not include all the components described above.
• In example embodiments, the network computing devices and any other computing machines associated with the technology presented herein may be any type of computing machine such as, but not limited to, those discussed in more detail with respect toFIG. 9. Furthermore, any modules associated with any of these computing machines, such as modules described herein or any other modules (scripts, web content, software, firmware, or hardware) associated with the technology presented herein may by any of the modules discussed in more detail with respect toFIG. 9. The computing machines discussed herein may communicate with one another as well as other computer machines or communication systems over one or more networks, such asnetwork120. Thenetwork120 may include any type of data or communications network, including any of the network technology discussed with respect toFIG. 9.
Example Processes
• The example methods illustrated inFIGS. 2-8 are described hereinafter with respect to the components of theexample operating environment100. The example methods ofFIGS. 2-8 may also be performed with other systems and in other environments.
• FIG. 2 is a block diagram depicting amethod200 for conducting a hands-free transaction, in accordance with certain example embodiments. Themethod200 is described with reference to the components illustrated inFIG. 1.
• Inblock210, themerchant computing device150 broadcasts a beacon via a wireless communication.Block210 is described in greater detail hereinafter with reference to themethod210 described inFIG. 3.
• FIG. 3 is a block diagram depicting amethod210 for amerchant computing device150 to broadcast a beacon via a wireless communication, in accordance with certain example embodiments. Themethod210 is described with reference to the components illustrated inFIG. 1.
• Inblock310, themerchant system130 registers with thepayment processing system140. For example, themerchant system130 may contact thepayment processing system140 to become associated with the hands-free transaction process. Themerchant system130 may obtain a merchant account, receive the appropriate applications and software, request authorization to participate, or perform any action required by thepayment processing system140.
• Themerchant system130 may use themerchant computing device150, the point of sale (“POS”)terminal134, themerchant server133, or any suitable computing device to request and configure a merchant account. The merchant account may allow themerchant system130 to participate in some or all of the activities described in the methods herein.
• Inblock320, themerchant computing device150 installs a hands-free payment application156. In an example, themerchant computing device150 is registered as an authorized agent of themerchant system130. Themerchant computing device150 may be identified by an alphanumeric identifier, by a provided password, a serial number, or by any suitable manner.
• In an example, themerchant computing device150 downloads the hands-free payment application156 from the payment processing system hands-free module141 over thenetwork120. Themerchant computing device150 may download the hands-free payment application156 from themerchant system server133. Themerchant computing device150 may obtain the hands-free payment application156 from any suitable location. The hands-free payment application156 on themerchant computing device150 may be integrated into an existing account that is shared with themerchant system server133, thePOS terminal134, or any suitable computing device or system. Asalesperson102 or another merchant system operator may be required to make a feature selection to obtain the benefits of the techniques described herein.
• Inblock330, themerchant computing device150 receives a beacon identifier. For example, the hands-free payment application156, themerchant computing device150, themerchant system server133, or another computing device requests a beacon identifier from thepayment processing system140. The beacon may be any wireless signal emitted by themerchant computing device150 comprising a beacon identifier, amerchant system130 identifier, amerchant computing device150 identifier, or other identifier.
• In an example, the beacon identifier is a service set identifier (“SSID”), or other network name or identifier. The beacon identifier may be generated by the payment processing system hands-free module141, themerchant computing device150, themerchant server133, or any suitable computing device. In certain embodiments, the beacon identifier is a unique, but fixed, identifier. That is, a particular beacon identifier may be utilized until changed by the payment processing system hands-free module141, themerchant computing device150, themerchant server133, or any suitable computing device. In an alternate embodiment, the beacon identifier may be unique, but random. That is, the beacon identifier may be changed randomly, or upon any suitable schedule by the payment processing system hands-free module141, themerchant computing device150, themerchant server133, or any suitable computing device.
• The wireless signal emitted by themerchant computing device150 may be any suitable technology, such as Wi-Fi direct, Bluetooth, low-energy Bluetooth, infrared, or any other suitable technology, and themerchant computing device150 may include corresponding hardware and software components to emit the beacon via the associated technology.
• Inblock340, themerchant computing device150 transmits the beacon via wireless communication at the location of themerchant system150. Themerchant computing device150 may be configured to broadcast the wireless signal at only certain times or locations, or continuously. Themerchant computing device150 may limit or extend the strength of the broadcast beacon, if needed. The beacon is receivable and recognizable by other computing devices that are within range of the wireless signal. The beacon may be transmitted on a single communication technology or on a plurality of communication technologies.
• In a certain example embodiment, the beacon identifier is programmed on external communication access points. The merchant hands-free application156 may be used to configure the external communication access point(s). For example, the merchant hands-free application156 may utilize functions of themerchant computing device150 to communicate instructions to the external communication access points. The instructions may include the beacon identifier, the requested communication technology, the time to broadcast, and/or any other suitable instructions. The instructions may be provided by any other suitable computing device.
• The external communication access points may be employed to allow a variety of user computing devices110 to receive the beacon despite differing wireless communication technology capabilities or in various locations in the merchant location. The external communication access points may allow the beacon to be broadcast over a wider area than themerchant computing device150 alone is capable of broadcasting.
• Fromblock340, themethod210 proceeds to block220 ofFIG. 2.
• Returning toFIG. 2, inblock220, the user computing device110 recognizes the merchant computing device beacon.Block220 is described in more detail hereinafter with reference to themethod220 described inFIG. 4.
• FIG. 4 is a block diagram depicting amethod220 for the user computing device110 to recognize the merchant computing device beacon, in accordance with certain example embodiments. Themethod220 is described with reference to the components illustrated inFIG. 1.
• Inblock410, theuser101 registers with thepayment processing system140. For example, theuser101 may contact thepayment processing system140 to register a user account. Theuser101 may obtain a user account number, receive the appropriate applications and software to install on the user computing device110, request authorization to participate in the hands-free payment processing, or perform any action required by thepayment processing system140. Theuser101 may utilize the functions of the user computing device110, such as theuser interface115 and theweb browser114, to register and configure a user account.
• Inblock420, theuser computing device140 installs a hands-free payment application116. For example, the user computing device110 downloads the hands-free payment application116 from the payment processing system hands-free module141 over thenetwork120. The user computing device110 may obtain the hands-free payment application116 from any other suitable location. The hands-free payment application116 on the user computing device110 may be configured with the user account information, user preferences, or other suitable information. Auser101 may be required to make a feature selection to obtain the benefits of the techniques described herein.
• The hands-free payment application116 may provide options, data, configurable alerts, and other suitable features to theuser101. For example, the hands-free payment application116 may comprise a listing of participatingmerchant systems130 and merchant locations. The listing may be updated periodically from thepayment processing system140. The hands-free payment application116 may notify theuser101 when theuser101 is within a configured vicinity of a participatingmerchant system130. The hands-free payment application116 may provide theuser102 with options to update payment preferences. The hands-free payment application116 may provide theuser101 with a listing of recent transactions. The hands-free payment application116 may provide any other suitable information to theuser101.
• Inblock430, the user computing device110 enters a location of themerchant system130. Theuser101 may enter the merchant location carrying theuser computing device101 in a pocket or a bag, in the hands of theuser101, or in any suitable manner. The location of themerchant system130 may be a store location, a kiosk location, or any suitable physical location of amerchant system130. In an alternate example, asalesperson102 may be mobile and arrive at a location of theuser101. For example, themerchant system130 may be a restaurant and thesalesperson102 may be a delivery person possessing amerchant computing device150.
• In certain example embodiments, the hands-free payment application116 alerts theuser101 when theuser101 is in the vicinity of amerchant system130 that accepts hands-free payments. The alert may be provided via a message on the user computing device110, via an email or a text, or in any suitable manner.
• The alert may be based on the location of theuser101 as determined by theGPS module118. For example, the hands-free payment application116 accesses the GPS data from theGPS module118 and compare the GPS location to a list of locations ofmerchant systems130 that accept hands-free payments. If a match results from the comparison, then an alert is generated and provided to the user. The match may result if theuser101 is within a configured distance of themerchant system130.
• The alerts may be configured to alert in any suitable manner. In an example, the alerts may be combined in commercially dense environments or the alerts may be presented individually. In another example, the alerts may be configured to only alert the user101 a configured number of times. For example, the alert may be presented three times, but upon a fourth instance, the alert is not presented. The alerts may be presented as a notification with an audible alert, a vibration, a popup alert on theuser interface115 of the user computing device110, or other suitable alert.
• Inblock440, the user computing device110 recognizes a beacon via wireless communication at the location of themerchant system130 and approves themerchant system130. The user computing device110 may be configured to search for beacons or other wireless signals. Upon entering the range of the signal of themerchant computing device130, the user computing device110 receives the beacon. The user computing device110 interprets the data transmitted in the beacon and recognizes that the beacon is associated with thepayment processing system140 and the hands-free payment application116. The user computing device110 may compare the data from the beacon to a database of beacon data to determine an identity of themerchant system130 associated with the beacon and/or to verify the authenticity of the beacon.
• The hands-free payment application116 interprets the data that is provided in the beacon. For example, the hands-free payment application116 extracts data from the beacon, such as a beacon identifier, a merchant system name, communication technology requirements, or any other suitable information.
• Fromblock440, themethod220 returns to block230 ofFIG. 2.
• Returning toFIG. 2, inblock230, the user computing device110 generates a token for a potential transaction. The token may be any data associated with the user account that is generated by the user computing device110 for secure transmission to another computing device. The token may represent an authorization or acknowledgement by the user computing device110 that the user computing device110 is in communication with a merchant computing device110 and that a transaction may be forthcoming. The token may comprise a user account identifier, the beacon identifier, a user computing device110 identifier, or any suitable data. The token may be encrypted or otherwise configured to only be readable by one or more of the payment processing system hands-free module141, the user computing device110, a financial account server associated with thepayment processing system140, or any suitable computing system. In certain example embodiments herein, the token, or certain portions of the token, is not readable by themerchant computing device150. To generate the token, the user computing device110 may compile all of the data needed for the token into a data file and insert identifiers, labels, or other items to prepare the token for transmission. The token may be generated in response to receiving the beacon from themerchant computing device150. That is, the token is not generated until the user computing device110 recognizes the beacon and recognizes a need to transmit the token based on the identify of themerchant system130, the location of the user computing device110, or any other factors. In an alternate embodiment, the token is created in advance. The token, or a series of tokens, may be created and stored on thedata storage unit112 of the user computing device110. The token may be accessed from the storage location and utilized when requested by the hands-free payment application116.
• The token may provide a time that the token will expire. For example, the token may only be usable for one hour after being generated. In the example, after one hour has elapsed, the token is no longer valid for use and thepayment processing system140 will reject any transaction request including an expired token. In certain example embodiments, the token comprises the beacon identifier, the location of the user computing device110, the user account identifier, or any other suitable data.
• The token may be generated by the hands-free application116, or another function of the user computing device110. For example, an application operating on a secure element of the user computing device110 may generate the token.
• In certain embodiments, a token is not generated by the user computing device110. For example, thepayment processing system140 may generate the token. Thepayment processing system140 may receive, from the user computing device110, a set of authentication data for the user account and generate a token. The authentication data may compriseuser101 data, account data, passwords, user computing device110 data, or any suitable data that may be used to authenticate the user account. The authentication data may be transmitted to thepayment processing system140 when the user computing device110 receives the beacon from themerchant computing device150. The user computing device110 may access the authentication data from a database on thedata storage unit112, or from data stored in the hands-free payment application116. The authentication data is transmitted in a similar fashion as the description of the transmission of the token from the user computing device110 to thepayment processing system140. The token that is generated by thepayment processing system140 is transmitted back to the user computing device110 or to themerchant computing device150 on behalf of the user computing device110.
• Inblock240, the user computing device110 transmits the token to the payment processing system hands-free module141. The user computing device110 may transmit a new token at the time that the user computing device110 recognizes the beacon and the beacon identifier, at a time that a previous token has expired, or upon any suitable schedule. The user computing device110 may transmit the token via an Internet communication over thenetwork120, Bluetooth communication, Wi-Fi communication, cellular connection, or via any suitable communication protocol.
• The payment processing system hands-free module141 approves the token and transaction parameters. The payment processing system hands-free module141 receives the token and any associated information from the user computing device110 and determines if the beacon identifier can be verified.
• For example, the payment processing system hands-free module141 may compare the beacon identifier to a database to determine if the beacon identifier is registered and approved. The payment processing system hands-free module141 may compare a location of the user computing device110, as determined by the global positioning system (“GPS”)module118, to a database of locations associated with the beacon identifiers. If not provided already, the payment processing system hands-free module141 may request the GPS location of the user computing device110 in a communication over thenetwork120 and receive a response from the user computing device110. If the location of the user computing device110 matches the expected location of themerchant computing device150, then the token is verified. Any other suitable criteria for verifying the token may be employed.
• The payment processing system hands-free module141 may verify the user account on thepayment processing system140 to determine if the user account is active and available for transactions. For example, the payment processing system may access the user account and determine if the account has funds available for use as stored value funds, or if the account has a valid credit or debit account associated with the account with which to conduct transaction.
• Inblock250, the payment processing system hands-free module141 transmits the token to amerchant computing device150. If the token is verified, the payment processing system hands-free module141 communicates the token to themerchant computing device150 to allow a hand-free transaction to be conducted. The token provides themerchant computing device150 with the authorization to initiate a transaction on behalf of the user account.
• In an alternate embodiment, the user computing device110 provides the token directly to themerchant computing device150. For example, the user computing device110 generates the token as described inblock230 and transmits the token to themerchant computing device150 instead of to thepayment processing system140. In a certain embodiment, the user computing device110 may require approval from thepayment processing device140 before transmitting the token to themerchant computing device150.
• Alternatively, the user computing device110 may transmit authorization data to the payment processing system. The authentication data may compriseuser101 data, account data, passwords, user computing device110 data, or any suitable data that may be used to authenticate the user account. The authentication data may be transmitted to thepayment processing system140 when the user computing device110 receives the beacon from themerchant computing device150. The user computing device110 may access the authentication data from a database on thedata storage unit112, or from data stored in the hands-free payment application116. The authentication data is transmitted in a similar fashion as the description of the transmission of the token from the user computing device110 to thepayment processing system140. The token is generated by thepayment processing system140 and is transmitted back to the user computing device110. The user computing device110 then transmits the received token to themerchant computing device150.
• Inblock260, thesalesperson102 enters transaction details into themerchant computing device150. In an example, theuser101 selects a product for purchase at the location of themerchant system130. The term “product” includes tangible and intangible products, as well as services. Thesalesperson102 scans the product with a barcode scanner or in any suitable manner enters the product details into themerchant computing device150. The transaction data may include the product identification, the product price, or any other suitable information.
• Inblock270, themerchant computing device150 identifies theuser101 and transmits a transaction request to thepayment processing system140.Block270 is described in more detail hereinafter with reference to themethod270aas described inFIG. 5 and themethod270bas described inFIG. 6.
• FIG. 5 is a block diagram depicting amethod270afor themerchant computing device150 to identify theuser101 and to transmit the transaction request to thepayment processing system140. Themethod270ais described with reference to the components illustrated inFIG. 1.
• Inblock510, thesalesperson102 issues a challenge to theuser101. In an example, thesalesperson102 asks theuser101 for the initials of theuser101. In another example, thesalesperson102 asks theuser101 for the last four digits of the phone number of theuser101. In another example, thesalesperson102 asks theuser101 for a configured password. Any suitable challenge may be issued by thesalesperson102. In an example embodiment, the response to the challenge does not provide any secure or private information.
• Inblock520, theuser101 provides the challenge response to thesalesperson102. As described in the example challenges, the responses may be the initials of theuser101, the last four digits of the phone number of theuser101, or a configured password. Any configured challenge response may be utilized. In certain embodiments, the response may be a spoken response, a hand gesture, a keypad entry, a display of an identification card, or any suitable response.
• Inblock530, thesalesperson102 inputs the challenge response of theuser101. In an example, if theuser101 indicates that the initials of theuser101 are “AC,” then thesalesperson102 inputs “AC” into the hands-free payment application156 of themerchant computing device150. In an example, theuser interface115 of the hands-free payment application156 or themerchant computing device150 displays a request for an entry of the response of theuser101. Thesalesperson102 enters the response via a virtual or physical keyboard, voice dictation, or in any suitable manner. In an alternate example, theuser101 enters the response into theuser interface115 of the hands-free payment application156 or themerchant computing device150
• Inblock540, themerchant computing device150 displays potential users based on the challenge response. A list ofusers101 that are associated with the challenge response are displayed on themerchant computing device150 to thesalesperson102. For example, if ten customers are in the vicinity of themerchant computing device150, then themerchant computing device150 may have received ten pending tokens from thepayment processing system140 associated with the ten customers. When the hands-free payment application156 on themerchant computing device150 receives the challenge response input, only the potential users that are associated with the challenge response are displayed to thesalesperson102.
• In another embodiment, themerchant computing device150 or thepayment processing system140 which processes the challenge, presents additional challenges until there is asingle matching user101 remaining.
• In the example, if thesalesperson102 inputs “AC” as the initials of theuser101 associated with the transaction, then only the potential users with those initials will be displayed to thesalesperson102 by the hands-free payment application156. The hands-free payment application156 accesses a database on themerchant computing device150, thepayment processing system140, or another computing device and identifies the initials of the potential users that have provided tokens. The hands-free payment application156 identifies the one or more potential users that have the initials “AC” and displays the identified user accounts to thesalesperson102. In the example, two of the ten customers that are in the vicinity of themerchant computing device150 have the initials “AC.” The user accounts of the two customers are displayed to thesalesperson102.
• In certain example embodiments, all of the nearby customers who have had tokens transmitted to themerchant computing device150 are presented to thesalesperson102 and the salesperson selects the appropriate user account.
• The hands-free payment application156 may display a picture of the potential user accounts that are presented to thesalesperson102. For example, eachuser101 may associate a picture with a user account. When themerchant computing device150 presents the one or more potential user accounts to thesalesperson102, thesalesperson102 may select the appropriate user account based on the picture matching theuser101 conducting the transaction. Other identifying information may be presented instead of, or in addition to, a picture. For example, the name of the user may be displayed and thesalesperson102 may identify the potential user with that name. Any other suitable identifying information may be presented.
• In an example embodiment, the picture or other identifying information may be transmitted to themerchant computing device150 as a function of the token. In another example, if the picture or other identifying information is not supplied with the token, the identifying information is requested by themerchant computing device150 from thepayment processing system140 and received in a communication over thenetwork120. In another example, the identifying information is requested by themerchant computing device150 from the user computing device110 directly and received in a communication. The identifying information may be received from any suitable source.
• Inblock550, thesalesperson102 selects the user account for the transaction. After identifying the displayed picture of theuser101, thesalesperson102 may input a selection of theuser101 by actuating a user interface control associated with the picture, or by inputting the selection in any suitable manner. If the picture doesn't match any of the potential users, then thesalesperson102 may cancel the transaction, notify theuser101 of the discrepancy, or perform any other suitable action.
• In an example, only a single user account is presented in the list of potential users. If only a single user account is identified, then the method may proceed after thesalesperson102 verifies that the displayed picture matches theuser101. If the picture doesn't match, then thesalesperson102 may cancel the transaction, notify theuser101 of the discrepancy, or perform any other suitable action.
• Inblock560, themerchant computing device150 transmits the transaction request to thepayment processing system140. Thesalesperson102 associates the token that is associated with theuser101 and the selected user account with the transaction data for the product being purchased by theuser101. Thesalesperson102 provides an indication on theuser interface155 of themerchant computing device150 that theuser101 has agreed to the purchase transaction. Themerchant computing device150 transmits the transaction details and token associated with theuser101 to payment processing system hands-free module141 to conduct the transaction.
• Fromblock560, themethod270areturns to block280 ofFIG. 2.
• FIG. 6 is a block flow diagram depicting amethod270bfor amerchant computing device150 to identify auser101 and transmit transaction request to payment processing system based on voice patterns of theuser101, in accordance with certain example embodiments.
• Inblock610, thesalesperson102 approaches the user location. Thesalesperson102 may recognize that theuser101 is prepared to make a purchase. Thesalesperson102 may proceed to an area in the vicinity of theuser101. For example, thesalesperson102 may proceed to an area from which themerchant computing device150 may detect the voice of theuser101. In another example, theuser101 approaches the area of thesalesperson102, such as at a POS terminal134 location.
• Inblock620, themerchant computing device150 captures a voice pattern of theuser101. In certain embodiments, theuser101 must enable this feature in the user account of thepayment processing system140. In the example, the voice of theuser101 may not be captured or analyzed without the permission of theuser101.
• In an example, thesalesperson102 may ask the user101 a question and themerchant computing device150 receives the audible response. In another example, themerchant computing device150 may detect theuser101 speaking without a request from thesalesperson102. For example, theuser101 may approach thesalesperson102 to request assistance with a purchase, and themerchant computing device150 detects the request. In another example, themerchant computing device150 detects theuser101 speaking for any other suitable reason.
• Themerchant computing device150 stores the voice of theuser101 in a storage device, such as thedata storage unit152, or transmits the voice of theuser101 to a third party for analysis and storage. In another example, themerchant computing device150 transmits the voice of theuser101 to thepayment processing system140 to match withusers101 that are in the vicinity of themerchant computing device150.
• Inblock630, themerchant computing device150 matches the token to the user voice pattern. Themerchant computing device150 performs an analysis of voice of theuser101 and identifies a voice pattern. Themerchant computing device150 compares the voice pattern of theuser101 to a database of voice patterns and identifies theuser101 and the associated user account. Themerchant computing device150 associates the token associated with the user account with the pending transaction.
• In an alternate embodiment, the voice pattern of theuser101 is associated with the token of theuser101 that is transmitted to the payment processing system hands-free module141. The voice pattern is transmitted to the merchant computing device along with the token.
• In an example, whenuser101 is checking out, theuser101 makes a statement, such as “I'd like to pay with the hands-free payment application.” The hands-free payment application156 on themerchant computing device150 detects the spoken phrase via the microphone or other input of themerchant computing device150. The spoken phrase is then compared, on the hands-free payment application150, with each of the stored voice pattern for one or more nearby consumers that have contributed tokens.
• In another example, theuser101 responds to a challenge from thesalesperson102. For example, thesalesperson102 may ask for the initials, first name, phone number, or any other response from the101. In another example, a certain phrase is required from theuser101 to ensure a proper voice pattern match. For example, the certain phrase may be “I'm paying hands-free.”
• If a strong match exists for any of the voice patterns, the hands-free payment application156 retrieves the user account associated with the matching voice pattern, and retrieves the remaining information about theuser101.
• Inblock640, themerchant computing device150 displays the user account based on the matching voice pattern. After matching the voice pattern to a user account, themerchant computing device150 presents the user account and any associated information to thesalesperson102 via a user interface of themerchant computing device150. Themerchant computing device150 may access user information, a picture of theuser101, or other suitable data, from the user account on thepayment processing system140 or any other suitable computing device.
• Inblock650, the salesperson selects the displayed user account for the transaction. After verifying the displayed picture of theuser101, or approving the user account for the transaction in any suitable manner, thesalesperson102 may input a selection of theuser101 by actuating a user interface control associated with the picture, or by inputting the selection in any suitable manner.
• Inblock660, themerchant computing device150 transmits the transaction request to thepayment processing system140. Thesalesperson102 associates the token that is associated with theuser101 and the selected user account with the transaction data for the product being purchased by theuser101. Thesalesperson102 may provide an indication on theuser interface155 of themerchant computing device150 that theuser101 has agreed to the purchase transaction. Themerchant computing device150 transmits the transaction details and token associated with theuser101 to payment processing system hands-free module141 to conduct the transaction. In a certain embodiment, themerchant computing device150 may include the challenge and the challenge response in the transaction request.
• Fromblock660, themethod270breturns to block280 ofFIG. 2.
• Inblock280, thepayment processing system140 conducts the transaction and transmits a confirmation to themerchant computing device150. The payment processing system hands-free module141 receives the transaction details and the token from themerchant computing device150 and processes the transaction. The payment processing system hands-free module141 verifies the token as the same token that was previously received from the user computing device110 (or generated by the payment processing system hands-free module141) and provided to themerchant computing device150. If the token is not verified as the same token, then the transaction does not proceed. If the token is not verified, the payment processing system hands-free module141 may request the correct token from themerchant computing device150, decline the transaction, alert a payment processing system hands-free module141 operator, or perform any suitable action to complete or cancel the transaction.
• Upon a verification of the token, the payment processing system hands-free module141 determines if the user account has the funds available for the transaction. In an example, the payment processing system hands-free module141 may apply the transaction by deducting the amount of the transaction from a pool of funds stored in the user account. In another example, the payment processing system hands-free module141 may provide an authorization request to a financial account issuer, such as a credit or debit card, associated with the account. Upon receiving an authorization from the financial account issuer, the payment processing system hands-free module141 proceeds with the transaction. The user account may be funded by any other suitable source, such as a bank account, a stored value account, a debit card, or any suitable source. The payment processing system hands-free module141 debits the appropriate account of theuser101 for the amount of the transaction and credits an account of the merchant for the amount of the transaction.
• The payment processing system hands-free module141 provides a notification to the merchantsystem computing device150 that the transaction is authorized. The authorization may be presented to thesalesperson102 by theuser interface155 of themerchant computing device150. Upon receiving the authorization, thesalesperson102 may provide the product and a receipt to theuser101 or the user computing device110. Upon settlement of the transaction, the payment processing system hands-free module141 provides the funds for the transaction to themerchant system130.
• Inblock290, upon a successful conducting of the transaction, thepayment processing system140 transmits a notification of the successful completion of the transaction to the user computing device110. The notification provides the details of the transaction, such as the transaction amount, the product purchased, and other suitable details. The notification allows theuser101 an opportunity to quickly dispute the charge. For example, thesalesperson102 or themerchant computing device150 may have associated the wrong token with the transaction details. In another example, the transaction details were in error and an incorrect amount was deducted from the user account. Theuser101 receives the notification on the user computing device110 and views the transaction details on theuser interface115. In an alternate example, theuser101 receives the notification from thepayment processing system140 as an email, a text, as a notification on the hands-free payment application, or in any suitable manner. In an alternate embodiment, the notification may be provided by themerchant computing device150. For example, themerchant computing device150 provides a text to the user computing device with the transaction details.
• The notifications, receipts, and other transaction data may be stored in a list on a database or other storage system on the user computing device110, the hands-free payment application116, or any suitable storage location. The notifications, receipts, and other transaction data may be stored in a list on a user account or other location on thepayment processing system140. Theuser101 may access the list to review recent transactions, to seek refunds, or for any suitable reason. In certain examples, the list on the user computing device110 may synchronize with the list on thepayment processing system140 either automatically or when prompted by theuser101.
• FIG. 7 is a block flow diagram depicting amethod700 for a hands-free transaction with a confirmation, in accordance with certain example embodiments. Themethod700 is described with reference to the components illustrated inFIG. 1.
• Block210 throughblock270 are substantially similar to theblocks210 through270 described previously with regard toFIG. 2. InFIG. 7, themethod700 proceeds fromblock270 to block775.
• Inblock775, thepayment processing system140 requests confirmation of the transaction from user computing device110.Block775 is described in more detail hereinafter with reference to themethod775 described inFIG. 8.
• FIG. 8 is a block diagram depicting amethod775 for apayment processing system140 to request confirmation of a transaction from the user computing device110. Themethod775 is described with reference to the components illustrated inFIG. 1.
• Inblock810, the payment processing system hands-free module141 receives the transaction request and the token from themerchant computing device150. The transaction request comprises the transaction amount in addition to other relevant transaction data.
• Inblock820, the payment processing system hands-free module141 determines that the transaction amount is greater than a configured limit on the user account. For example, from the information in the token and the transaction data, the payment processing system hands-free module141 identifies the user account associated with the transaction. The payment processing system hands-free module141 compares the transaction amount to any configured transaction amount limit in the user account. In an example, the limit may be $10, $50, or $100. Any suitable limit may be configured.
• The amount of the transaction limit may be configured by theuser101, the payment processing system hands-free module141, a financial account issuer associated with the user account, or any suitable party. For example, theuser101 may configure a transaction limit during the account setup to protect against a fraudulent transaction. In another example, a financial account issuer associated with the user account may communicate a hands-free transaction limit to the payment processing system hands-free module141 based on the credit history of theuser101 or based any suitable qualifications. In certain embodiments, the transaction limit is obtained by the payment processing system hands-free module141 from data in the token.
• If the transaction amount is greater than the configured limit, then the payment processing system hands-free module141 recognizes that the transaction requires additional authorization. In certain example embodiments, the user account may be configured to require that all transactions may require an authorization. Any other requirement for a transaction may be placed on the user account. For example, theuser101 may configure the account to specify that all transactions with aparticular merchant system130, or a group of merchant systems, require user authorization. In another example, theuser101 may configure the account to specify that all transactions for certain products require user authorization.
• Inblock830, the payment processing system hands-free module141 transmits a request for authorization of the transaction to the user computing device110. The request may be transmitted via the Internet to the hands-free payment application116, transmitted via email or text, or transmitted in any suitable manner. The request for authorization may comprise transaction details sufficient to allow theuser101 to identify the transaction needing approval. The request may include the identity of themerchant system130, a description of the product being purchased, an identification number of the product, an amount of funds required to conduct the transaction, a geographic location of themerchant system130, or any other suitable data.
• Inblock840, the user computing device110 receives an input of a confirmation from theuser101. Along with a presentation of the transaction data, the hands-free payment application116, or other application employing auser interface115, displays a request to theuser101 for an authorization of the transaction. The display may provide a control, or other selectable option for theuser101 to input an option to authorize the transaction or refuse the transaction. If theuser101 authorizes the transaction, theuser101 inputs the selection into theuser interface115 by selecting the appropriate button or other control. In alternate embodiments, the user authorization may be input via a voice control, a swipe or other motion with the user computing device110, or via any other suitable action of theuser101.
• If theuser101 does not authorize a request, then the method may end or the user computing device110 may transmit the refusal of the transaction to the payment processing system hands-free module141. If authorized by theuser101, the user computing device transmits the authorization to thepayment processing system140.
• In block850, upon receiving the authorization of the transaction from theuser101, the user computing device110 generates a second token. The second token is generated in a similar manner as the generation of the first token as described inblock230 ofFIG. 2. In addition to the previously described data associated with the token, the second token comprises the authorization of the transaction as received from the input of theuser101. In an alternate embodiment, a second token is not created. In an example, the authorization is provided to the payment processing system via a communication over thenetwork120.
• Inblock860, the payment processing system hands-free module141 receives the second token and applies the second token to the pending transaction. The payment processing system hands-free module141 discards the original token received from themerchant computing device150 and applies the second token to the transaction. The payment processing system hands-free module141 recognizes the authorization from theuser101 in the token and overrides the limit on the user account. The payment processing system hands-free module141 may be configured not to proceed with a token that does not meet the transaction criteria. A second token that is not bound by a transaction limit lower than the transaction amount may be required.
• In an alternate example, the payment processing system hands-free module141 does not receive the second token to apply to the pending transaction. The user computing device110 provides an authorization from theuser101 to conduct the transaction and override the transaction limit. The payment processing system hands-free module141 overrides the transaction limit in the user account and uses the first token for any further processing of the transaction.
• Fromblock860, themethod775 returns to block280 ofFIG. 7.
• Block280 and block290 are substantially similar to theblocks280 and290 with respect toFIG. 2. The token used to conduct the transaction in the embodiment ofFIG. 7 is the second generated token. In certain alternate embodiments, upon receiving the confirmation from the user computing device110 for the transaction, thepayment processing system140 accesses the original token and utilizes the original token for the transaction. In an example, thepayment processing system140 overrides the transaction limit of the original token based on the authorization of theuser101 and conducts the transaction with the original token.
• In certain example embodiments, thepayment processing system140 will offer incentives tousers101 to utilize the hands-free payment process. Incentives may be offered to themerchant system130, thesalesperson102, and/or theuser101.
• The incentives may be structured in two groups. The first group is “ongoing earnings.” In an example, an ongoing earning type of incentive system is a percentage cash back. In another example, the incentive is a points based loyalty system.
• Another group of incentives is “surprise incentives.” Surprise incentives are not predictable, nor are surprise incentives the same value every time and they can have an amplifying effect at reinvigorating and delighting auser101. Surprise promotions serve the same purpose. An algorithm on the payment processing system hands-free module141 may have a rules engine for handing out gifts, discounts or promotions based on usage patterns of theuser101 as well as overall health of the network.
• Users101 may not know when a gift or discount is available. Theusers101 find out that thepayment processing system140 just picked up the tab after the transaction happens. This creates a delight factor. The system can also be set up to reward repeat/loyal users101 more aggressively.
• In an example, the payment processing system hands-free module141 may monitor the transaction history of the user account and provide a surprise incentive after a configured number of transactions. For example, the third transaction may be funded by thepayment processing system140 and the user account is not charged. In an example, the third transaction is only billed if the total is under a configured amount. In certain example embodiments the transaction that is funded by thepayment processing system140 is selected based on a random selection. For example, an algorithm may be utilized that randomly selects a transaction for funding by thepayment processing system140. In another example, the transaction that is funded by thepayment processing system140 is selected is based on an algorithm that analyzes the transaction history of theuser101 and configures the selection in an appropriate manner. In a certain example embodiment, the payment processing system hands-free module141 may be configured to offer a user account a 1 in 10 chance of having a pending transaction funded by thepayment processing system140. Any odds of winning or other selection criteria may be utilized.
• In another example, the transaction is not fully funded, but is discounted by a configured percentage. For example, an algorithm may be utilized that randomly selects a percentage that will be funded by thepayment processing system140.
• A level of unpredictability in the surprise rewards or discounts encouragesusers101 to more frequently utilize the hands-free payments. Unlike cash back rewards, whereusers101 can get complacent over time,users101 will keep using hands-free payments in the hope of getting rewarded again.
• In another example, the percentage that will be funded by thepayment processing system140 is selected is based on an algorithm that analyzes the transaction history of theuser101 and configures the selection in an appropriate manner. Any suitable surprise discount or reward to the user account may be utilized.
• In certain example embodiments, thepayment processing system140 may provide surprise rewards to a user account based on the number of transactions conducted. For example, when an user account has a greater number of conducted transactions, the amount or the frequency of the rewards or discounts is increased.
• Consumer incentive design parameters getsusers101 over an initial hump and promotes active sign ups. Consumer incentives encourage repeated behavior and build long-term loyalty to thepayment processing system140. Consumer incentives grow stored value and encourageusers101 to link their bank account and maintain a user account with funds available. Consumer incentives build brand awareness sousers101 think hands-free payments is innovative and want to use it everywhere.
• Merchant incentive design parameters contribute to customer loyalty, bring in foot traffic for both new and existing customers, and reduce costs.
• Salesperson102 incentive design parameters cause the salesperson to encourage customers to try hands-free payments and push merchant systems to adopt hands-free payments. Customer service is also improved while using hands-free payments. In an example embodiment, thesalesperson102 may receive a certain percentage, such as 10%, of hands-free orders. Thepayment processing system140 may register thesalesperson102 that conducted the hands-free payment transaction based on details transmitted with the transaction details and provide a payment to thesalesperson102 in the form of a check.
Other Example Embodiments
• FIG. 9 depicts acomputing machine2000 and amodule2050 in accordance with certain example embodiments. Thecomputing machine2000 may correspond to any of the various computers, servers, mobile devices, embedded systems, or computing systems presented herein. Themodule2050 may comprise one or more hardware or software elements configured to facilitate thecomputing machine2000 in performing the various methods and processing functions presented herein. Thecomputing machine2000 may include various internal or attached components such as aprocessor2010,system bus2020,system memory2030,storage media2040, input/output interface2060, and anetwork interface2070 for communicating with anetwork2080.
• Thecomputing machine2000 may be implemented as a conventional computer system, an embedded controller, a laptop, a server, a mobile device, a smartphone, a set-top box, a kiosk, a vehicular information system, one more processors associated with a television, a customized machine, any other hardware platform, or any combination or multiplicity thereof. Thecomputing machine2000 may be a distributed system configured to function using multiple computing machines interconnected via a data network or bus system.
• Theprocessor2010 may be configured to execute code or instructions to perform the operations and functionality described herein, manage request flow and address mappings, and to perform calculations and generate commands. Theprocessor2010 may be configured to monitor and control the operation of the components in thecomputing machine2000. Theprocessor2010 may be a general purpose processor, a processor core, a multiprocessor, a reconfigurable processor, a microcontroller, a digital signal processor (“DSP”), an application specific integrated circuit (“ASIC”), a graphics processing unit (“GPU”), a field programmable gate array (“FPGA”), a programmable logic device (“PLD”), a controller, a state machine, gated logic, discrete hardware components, any other processing unit, or any combination or multiplicity thereof. Theprocessor2010 may be a single processing unit, multiple processing units, a single processing core, multiple processing cores, special purpose processing cores, co-processors, or any combination thereof. According to certain example embodiments, theprocessor2010 along with other components of thecomputing machine2000 may be a virtualized computing machine executing within one or more other computing machines.
• Thesystem memory2030 may include non-volatile memories such as read-only memory (“ROM”), programmable read-only memory (“PROM”), erasable programmable read-only memory (“EPROM”), flash memory, or any other device capable of storing program instructions or data with or without applied power. Thesystem memory2030 may also include volatile memories such as random access memory (“RAM”), static random access memory (“SRAM”), dynamic random access memory (“DRAM”), and synchronous dynamic random access memory (“SDRAM”). Other types of RAM also may be used to implement thesystem memory2030. Thesystem memory2030 may be implemented using a single memory module or multiple memory modules. While thesystem memory2030 is depicted as being part of thecomputing machine2000, one skilled in the art will recognize that thesystem memory2030 may be separate from thecomputing machine2000 without departing from the scope of the subject technology. It should also be appreciated that thesystem memory2030 may include, or operate in conjunction with, a non-volatile storage device such as thestorage media2040.
• Thestorage media2040 may include a hard disk, a floppy disk, a compact disc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), a Blu-ray disc, a magnetic tape, a flash memory, other non-volatile memory device, a solid state drive (“SSD”), any magnetic storage device, any optical storage device, any electrical storage device, any semiconductor storage device, any physical-based storage device, any other data storage device, or any combination or multiplicity thereof. Thestorage media2040 may store one or more operating systems, application programs and program modules such asmodule2050, data, or any other information. Thestorage media2040 may be part of, or connected to, thecomputing machine2000. Thestorage media2040 may also be part of one or more other computing machines that are in communication with thecomputing machine2000 such as servers, database servers, cloud storage, network attached storage, and so forth.
• Themodule2050 may comprise one or more hardware or software elements configured to facilitate thecomputing machine2000 with performing the various methods and processing functions presented herein. Themodule2050 may include one or more sequences of instructions stored as software or firmware in association with thesystem memory2030, thestorage media2040, or both. Thestorage media2040 may therefore represent examples of machine or computer readable media on which instructions or code may be stored for execution by theprocessor2010. Machine or computer readable media may generally refer to any medium or media used to provide instructions to theprocessor2010. Such machine or computer readable media associated with themodule2050 may comprise a computer software product. It should be appreciated that a computer software product comprising themodule2050 may also be associated with one or more processes or methods for delivering themodule2050 to thecomputing machine2000 via thenetwork2080, any signal-bearing medium, or any other communication or delivery technology. Themodule2050 may also comprise hardware circuits or information for configuring hardware circuits such as microcode or configuration information for an FPGA or other PLD.
• The input/output (“I/O”)interface2060 may be configured to couple to one or more external devices, to receive data from the one or more external devices, and to send data to the one or more external devices. Such external devices along with the various internal devices may also be known as peripheral devices. The I/O interface2060 may include both electrical and physical connections for operably coupling the various peripheral devices to thecomputing machine2000 or theprocessor2010. The I/O interface2060 may be configured to communicate data, addresses, and control signals between the peripheral devices, thecomputing machine2000, or theprocessor2010. The I/O interface2060 may be configured to implement any standard interface, such as small computer system interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel, peripheral component interconnect (“PCP”), PCI express (PCIe), serial bus, parallel bus, advanced technology attached (“ATA”), serial ATA (“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, various video buses, and the like. The I/O interface2060 may be configured to implement only one interface or bus technology. Alternatively, the I/O interface2060 may be configured to implement multiple interfaces or bus technologies. The I/O interface2060 may be configured as part of, all of, or to operate in conjunction with, thesystem bus2020. The I/O interface2060 may include one or more buffers for buffering transmissions between one or more external devices, internal devices, thecomputing machine2000, or theprocessor2010.
• The I/O interface2060 may couple thecomputing machine2000 to various input devices including mice, touch-screens, scanners, electronic digitizers, sensors, receivers, touchpads, trackballs, cameras, microphones, keyboards, any other pointing devices, or any combinations thereof. The I/O interface2060 may couple thecomputing machine2000 to various output devices including video displays, speakers, printers, projectors, tactile feedback devices, automation control, robotic components, actuators, motors, fans, solenoids, valves, pumps, transmitters, signal emitters, lights, and so forth.
• Thecomputing machine2000 may operate in a networked environment using logical connections through thenetwork interface2070 to one or more other systems or computing machines across thenetwork2080. Thenetwork2080 may include wide area networks (WAN), local area networks (LAN), intranets, the Internet, wireless access networks, wired networks, mobile networks, telephone networks, optical networks, or combinations thereof. Thenetwork2080 may be packet switched, circuit switched, of any topology, and may use any communication protocol. Communication links within thenetwork2080 may involve various digital or an analog communication media such as fiber optic cables, free-space optics, waveguides, electrical conductors, wireless links, antennas, radio-frequency communications, and so forth.
• Theprocessor2010 may be connected to the other elements of thecomputing machine2000 or the various peripherals discussed herein through thesystem bus2020. It should be appreciated that thesystem bus2020 may be within theprocessor2010, outside theprocessor2010, or both. According to some embodiments, any of theprocessor2010, the other elements of thecomputing machine2000, or the various peripherals discussed herein may be integrated into a single device such as a system on chip (“SOC”), system on package (“SOP”), or ASIC device.
• In situations in which the systems discussed here collect personal information about users, or may make use of personal information, the users may be provided with an opportunity or option to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and/or how to receive content from the content server that may be more relevant to the user. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about the user and used by a content server.
• Embodiments may comprise a computer program that embodies the functions described and illustrated herein, wherein the computer program is implemented in a computer system that comprises instructions stored in a machine-readable medium and a processor that executes the instructions. However, it should be apparent that there could be many different ways of implementing embodiments in computer programming, and the embodiments should not be construed as limited to any one set of computer program instructions. Further, a skilled programmer would be able to write such a computer program to implement an embodiment of the disclosed embodiments based on the appended flow charts and associated description in the application text. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use embodiments. Further, those skilled in the art will appreciate that one or more aspects of embodiments described herein may be performed by hardware, software, or a combination thereof, as may be embodied in one or more computing systems. Moreover, any reference to an act being performed by a computer should not be construed as being performed by a single computer as more than one computer may perform the act.
• The example embodiments described herein can be used with computer hardware and software that perform the methods and processing functions described herein. The systems, methods, and procedures described herein can be embodied in a programmable computer, computer-executable software, or digital circuitry. The software can be stored on computer-readable media. For example, computer-readable media can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, memory stick, optical media, magneto-optical media, CD-ROM, etc. Digital circuitry can include integrated circuits, gate arrays, building block logic, field programmable gate arrays (FPGA), etc.
• The example systems, methods, and acts described in the embodiments presented previously are illustrative, and, in alternative embodiments, certain acts can be performed in a different order, in parallel with one another, omitted entirely, and/or combined between different example embodiments, and/or certain additional acts can be performed, without departing from the scope and spirit of various embodiments. Accordingly, such alternative embodiments are included in the scope of the following claims, which are to be accorded the broadest interpretation so as to encompass such alternate embodiments.
• Although specific embodiments have been described above in detail, the description is merely for purposes of illustration. It should be appreciated, therefore, that many aspects described above are not intended as required or essential elements unless explicitly stated otherwise. Modifications of, and equivalent components or acts corresponding to, the disclosed aspects of the example embodiments, in addition to those described above, can be made by a person of ordinary skill in the art, having the benefit of the present disclosure, without departing from the spirit and scope of embodiments defined in the following claims, the scope of which is to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures.

Claims (20)

What is claimed is:

1. A computer-implemented method to process hands-free service requests when service request limits are exceeded, comprising:

receiving, by an application on a user computing device, a beacon identifier from a service computing device;

generating, by the application on the user computing device, a first service request token;

transmitting, by the application on the user computing device, the first service request token to the service computing device, wherein the service computing device associates service request data with the first service request token;

transmitting, by the application on the user computing device and to one or more computing devices, a first communication comprising the first service request token, an account identifier, and the beacon identifier;

receiving, by the one or more computing devices, the first communication from the application on the user computing device;

receiving, by the one or more computing devices and from the service computing system, a service request comprising the first service request token and the service request data;

determining, by the one or more computing devices and based on the service request data, that the service request exceeds a configured service request limit for hands-free service requests associated with the account identifier;

communicating, by the one or more computing devices and to the application on the user computing device, a request for an authorization of the service request that exceeds the configured service request limit;

receiving, by the one or more computing devices, an authorization for the service request from the application on the user computing device; and

processing, by the one or more computing devices, the service request in response to receiving the authorization.

2. The computer-implemented method ofclaim 1, further comprising determining, by the one or more computing devices, that the configured service request limit indicates that all hands-free service requests associated with the account identifier require user authorization.

3. The computer-implemented method ofclaim 1, wherein user authorization of the service request is received by the user computing device from an input of the user and wherein the user computing device transmits the authorization request to the one or more computing devices in response to receiving the user authorization.

4. The computer-implemented method ofclaim 1, wherein the service request limit associated with the account identifier is configured by one or more of the user and the one or more computing devices.

5. The computer-implemented method ofclaim 1, wherein the service request limit associated with the account identifier is configured by a system associated with the account identifier.

6. The computer-implemented method ofclaim 1, wherein the first service request token provides an authorization for the one or more computing devices to conduct the service request with the account identifier within a scope provided by the first service request token.

7. The computer-implemented method ofclaim 1, wherein the request for the authorization of the service request is communicated in response to determining, by the one or more computing devices, that the service request is received from the service computing device associated with a particular service system.

8. The computer-implemented method ofclaim 1, wherein the authorization of the service request comprises a second service request token from the user computing device, and wherein the transaction is conducted based on the second service request token.

9. The computer-implemented method ofclaim 1, wherein the service request is conducted based on the first service request token.

10. A system to process hands-free service requests when service request limits are exceeded, comprising:

a user computing device, comprising:

a first storage device;

a first application; and

a first processor communicatively coupled to the first storage device, wherein the first processor executes application code instructions that are stored in the first storage device to cause the user computing device to:

receive, by the first application from a service computing device associated with a service computing system, a beacon identifier;

generate, by the first application, a first service request token;

transmit, by the first application to the service computing device, the first service request token, wherein the service computing device associates service request data with the first service request token;

transmit, by the first application to one or more service processing devices, a first communication comprising the first service request token, an account identifier, and the beacon identifier; and

the one or more service processing devices, comprising:

a second storage device; and

a second processor communicatively coupled to the second storage device, wherein the second processor executes application code instructions that are stored in the second storage device to cause the one or more service processing devices to:

receive, from the application on the user computing device, the first communication comprising the first service request token, the account identifier, and the beacon identifier;

receive, from the service computing system, a service request, the service request comprising the first service request token and the service request data;

determine, based on the service request data, that the service request is for an amount greater than a configured service request limit for hands-free service requests associated with account identifier;

communicate, to the application on the user computing device, a request for an authorization of the service request that exceeds the configured service request limit;

receive, from the application on the user computing device, an authorization request for the service request; and

process the service request in response to receiving the authorization request.

11. The system ofclaim 10, wherein the authorization of the service request comprises a second service request token from the user computing device, and wherein the transaction is conducted based on the second service request token.

12. The system ofclaim 10, wherein the service request is conducted based on the first service request token.

13. The system ofclaim 10, wherein the configured service request limit indicates that all hands-free service requests associated with account identifier requires user authorization.

14. The system ofclaim 10, wherein the service request limit for hands-free service requests associated with the account identifier is configured by one or more of the user and the one or more service processing devices.

15. The system ofclaim 10, wherein the service request limit for hands-free service requests associated with the account identifier is configured by a system associated with the account identifier.

16. The system ofclaim 10, wherein the first processor is further configured to execute application code instructions that are stored in the first storage device to cause the user computing device to:

receive, from an input of the user, user authorization of the service request; and

transmit the authorization request to the one or more computing devices in response to receiving the user authorization.

17. The system ofclaim 10, wherein the first service request token provides an authorization for the one or more computing devices to conduct a service request with the account identifier within a scope provided by the first service request token.

18. The system ofclaim 10, wherein the second processor is further configured to execute application code instructions that are stored in the second storage device to cause the one or more service processing devices to determine that the service computing device is associated with a particular service system, wherein the request for the authorization of the service request is communicated in response to determining that the service request is received from the service computing device associated with the particular service system.

19. The system ofclaim 10, wherein the authorization of the service request comprises a second service request token from the user computing device, and wherein the transaction is conducted based on the second service request token.

20. The system ofclaim 10, wherein the service request is conducted based on the first service request token.

Images