TECHNICAL FIELDThe present application generally relates to suspending and resuming transactions through wireless beacon communications and more specifically to utilizing wireless beacons to receive user information that is then associated with one or more scanned items the user wishes to purchase.
BACKGROUNDA user may visit a merchant location to select items or services that the user wishes to purchase. For certain purchases, this may require the user to begin a transaction but not complete the transaction until a later time period. For example, the user may request copies to be made of a book, and may then have to later return to the copier to receive the copies and pay for the transaction. For other purchases, the user may select items for purchase but wish to continue shopping after selecting the items. A user may be shopping for large electronics or may wish to scan items in for a transaction and continue shopping if lines are significantly long. Moreover, at other times it may be useful for the user to suspend the transaction when the merchant is required to later complete the sale of the selected items or services. Thus, the transaction is left open and needs to be resumed at a later time period. However, without collecting some user information and/or providing the user with identification for the transaction, the user may not be able to later recall the transaction. Additionally, collection of user information may be difficult and time consuming, and users may opt to forego providing such information, which may lead to poor customer experiences.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment;
FIG. 2 is an exemplary merchant location environment with users selecting items for purchase and suspending transactions for the items until arrival at a checkout line, according to an embodiment;
FIG. 3 is an exemplary system environment showing display screens of a user device, an employee device, and a merchant device when suspending and resuming a transaction, according to an embodiment;
FIG. 4 is a flowchart of an exemplary process for suspending and resuming transactions through wireless beacon communications, according to an embodiment; and
FIG. 5 is a block diagram of a computer system suitable for implementing one or more components inFIG. 1, according to an embodiment.
Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.
DETAILED DESCRIPTIONProvided are methods that provide for suspending and resuming transactions through wireless beacon communications. Systems suitable for practicing methods of the present disclosure are also provided.
Various locations may provide short range wireless communications with a user device, such as through wireless beacons using one or more of Bluetooth Low Energy (BLE) communication protocol, LTE Direct communication protocol, WiFi communication protocol, etc. These beacons may be set up at a location and communicate with user devices to alert users of check-in services through their device. The beacons may provide additional functionality, such as establishing a connection with the user devices to establish, suspend, and/or resume transactions. The beacons may communicate with the devices directly, including information stored in the beacons. The beacons may also enable communication between the user device and a device attached to, or in communication with, the beacon, such as a device of a merchant and/or the merchant's employee.
A merchant may offer suspension and resumption of transactions using the aforementioned wireless beacons at a merchant location. A merchant location may correspond to a retail store, a shopping market, a mall location, or other physical location where a user, such as a consumer or purchaser, may visit to purchase items. However, in other embodiments, the location employing wireless beacons as discussed below may correspond to a location having a line where the wireless beacons may collect initial information for a user and later recall the information. The merchant location may utilize short range wireless beacons at the merchant location to communicate with a user device that the user possesses. For example, the short range wireless beacons may be established throughout the merchant location in order to effect a check-in and/or reception of user information when the user is at the location. The beacons may employ BLE, LTE Direct, WiFi, or other communications that emit a signal receivable by the user's device. The communication may include an identifier for the beacon, the user, the merchant, and/or a payment provider that provides payment services between the user and the merchant.
A user may set up a user device to passively monitor for BLE, LTE Direct, WiFi, or other communication signals from the beacon. When the user device detects the signal and verifies the one or more identifiers, both the user device and the beacon may ramp up in power and establish a connection, where the connection may further enable the user device to communicate with the merchant and/or an employee through a device in possession of the merchant/employee. The user device may provide some check-in information, identifier, or other identification information (e.g., payment information) to the merchant/employee, which may later be used to identify a transaction. The beacon may be connected to a networked device at the merchant location, or the beacon may include network functionality to communicate with other devices and/or servers. Thus, the beacon enables the user device to establish a connection, communicate check-in information (e.g., an identifier for the user), and/or initiate a check-in with the merchant. The check-in may be completed automatically when the user device is in range of the beacon, or may be completed after prompting the user to check-in when the user device is in range of the beacon.
As previously discussed, once a connection is first established with the user device and the beacon, check-in information and/or other information may be received. The user may then bring selected items or services to an employee to scan the items/services in for a transaction. In other embodiments, the user may perform the scanning themselves, such as through the user device or a scanner provided with a shopping cart/basket. Once the items/services have been scanned and entered, a transaction for the items/services may be generated with the merchant. The transaction and transaction information may be stored with the identification information received from the previous connection. The identification information may be retrieved for storage with the transaction using a second connection between a wireless beacon corresponding to the scanner and the user device of the user. For example, when an employee of the merchant approaches the user and scans the user's items, an identifier may be recalled for the user and associated with the transaction generated for the items. The user may then choose to complete a transaction for the selected items/services, or may suspend the transaction for resuming, processing, and completing later.
If the user chooses to suspend the transaction, the transaction may be stored with the identifier for later recall. User information, payment information, and/or incentive information (e.g., loyalty accounts, discounts, etc.) may also be stored with the transaction and/or determined using the received identification information for the user. A transaction code may be provided to the user for resuming the transaction when the user is ready. In other embodiments, the transaction may later be resumed by the user using another connection between the user device and another wireless beacon located at, nearby, or connected to a point of sale (PoS) or checkout device. Once the transaction is resumed, the user may provide a payment instrument, such as a payment account with a payment provider, and a payment for the transaction may be processed. Incentives may be applied to the transaction prior to processing the payment. If the user has continued shopping after suspending the transaction, additional items/services the user wishes to purchase may be added to the transaction. The transaction may be suspended if a merchant employee is required to provide the items/services to the user (e.g., retrieve from a stockroom, remove security tags, provide items for a requested service, etc.). Thus, the transaction may be resumed when the user is ready to pick up their items/services in another line or area. Therefore, when the transaction is resumed and/or a payment is processed, the merchant may provide the purchased items/services to the user.
FIG. 1 is a block diagram of a networkedsystem100 suitable for implementing the processes described herein, according to an embodiment. As shown,system100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary device and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated inFIG. 1 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.
System100 includes auser102, a user device110, anemployee device130 having ascanner134 and awireless beacon136, amerchant device140, andpayment provider server160 in communication over anetwork170.User102, such as a consumer or other shopper at a merchant location, may arrive at the merchant location corresponding toemployee device130 andmerchant device140. The merchant location may offer one or more items/services for sale touser102.User102 may establish a check-in with the merchant location and may select one or more items/services to purchase. The items/services may be scanned by an employee at the merchant location usingemployee device130. In other embodiments,employee device130 may be provided with a cart or basket, whichuser102 may utilize to scan and hold selected items/services for purchase. Once the items/services are scanned, a transaction may be generated and associated with user identification information (e.g., an identifier) provided during the check-in.User102 may then suspend the transaction withmerchant device140. Whenuser102 is ready to resume the transaction,user102 may utilizepayment provider server160 to provide payment for the transaction.
User device110,employee device130,scanner134,wireless beacon136,merchant device140, andpayment provider server160 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components ofsystem100, and/or accessible overnetwork170.
User device110 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication withemployee device130,wireless beacon136,merchant device140, and/orpayment provider server160. For example, in one embodiment, user device110 may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a user device is shown, the user device may be managed or controlled by any suitable processing device. Although only one user device is shown, a plurality of user devices may function similarly.
User device110 ofFIG. 1 contains a check-inapplication112, apayment application120,other applications114, adatabase116, and acommunication module118. Check-inapplication112,payment application120, andother applications114 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments, user device110 may include additional or different software as required.
Check-inapplication112 may be used byuser102 of user device110 to complete a check-in foruser102 at a location corresponding toemployee device130/merchant device140 and establish a connection withwireless beacon136. Check-inapplication112 may correspond to an application utilized by user device110 withmerchant device140 to complete a check-in for the merchant location. The check-in withmerchant device140 may correspond to a process to log in to a user account ofuser102 with merchant device140 (orpayment provider server160 ifpayment provider server160 provides check-in services). In other embodiments, the check-in may provide and/or verify the identity ofuser102, including transmission of an identifier foruser102 and/or user device110 or other identification information (e.g., personal information, payment/financial information, a loyalty account identifier, etc.). The check-in may be completed overnetwork170 withmerchant device140. In such embodiments, check-inapplication112 may correspond more generally to a browser application configured to communicate withmerchant device140. In other embodiments, the check-in may be completed when user device110 connects to a wireless beacon established at the merchant location. In such embodiments, check-in application may connect to the wireless beacon (including wireless beacon136) as explained below in reference to the connection withwireless beacon136, and the aforementioned identification information may be provided towireless beacon136 andmerchant device140.
Check-inapplication112 may also cause user device110 to connect towireless beacon136 to assist in suspending a transaction for items scanned in byscanner134. In this regard, check-inapplication112 may receive short range wireless communications fromwireless beacon136 at the merchant location and transmit information towireless beacon136. In various embodiments, the information transmitted towireless beacon136 and/or another wireless beacon may correspond to check-in information for a check-in process with merchant device140 (orpayment provider server160 ifpayment provider server160 provides check-in services). In such embodiments, the check-in information may include an identifier or other identification information foruser102 as previously discussed. The check-in information may be provided towireless beacon136 or another wireless beacon by check-inapplication112 prior to scanning in items/service for a transaction byemployee device130. In other embodiments, the check-in information may be transmitted towireless beacon136 whenemployee device130 is scanning in items/service for a transaction foruser102.
Once check-in information, an identifier, and/or other identification information is transmitted by check-inapplication112, check-inapplication112 may connect towireless beacon136 during scanning of items for a transaction.Wireless beacon136 may be range limited to a small area aroundemployee device130, such as approximately 3 feet, 1 foot, 6 inches, or other small area where only user device110 may connect with wireless beacon136 (e.g., an average distance betweenuser102 and a store employee operatingemployee device130. Thus, check-inapplication112 may connect withwireless beacon136 whenuser102 isnearby wireless beacon136 with user device110.
Check-inapplication112 may execute in the background of an operating system of user device110 and be configured to establish the connections, usingcommunication module118 of user device110, withwireless beacon136. The connection may be established with or without user input fromuser102. For example,wireless beacon136 may broadcast a token, such as a universally unique identifier (UUID), for reception by check-inapplication112, as will be explained in more detail herein. Check-inapplication112 may utilizecommunication module118 of user device110 to receive the token fromwireless beacon136. If check-inapplication112 acknowledges the UUID as identifyingwireless beacon136,merchant device140, and/or payment provider server160 (e.g., if check-inapplication112 determines the UUID corresponds to a request to complete a check-in), check-inapplication112 may transmit an identifier (or other identification information) corresponding touser102 and/or user device110 back to thewireless beacon136. Check-inapplication112 may utilizecommunication module118 of user device110 to communicate with wireless beacon136 (e.g., over near field communication, Bluetooth, Bluetooth Low Energy, radio, infrared, LTE Direct, or other connection). The identifier from user device110 may include, be transmitted with, concatenated with, or otherwise bundled with the identifier received from thewireless beacon136. In other embodiments, different information may be transmitted towireless beacon136, such as a name or other personal information foruser102, a loyalty account foruser102 with the merchant, payment information foruser102, etc. Thus, the information transmitted towireless beacon136 does not need to be utilized to process and/or complete a check-in withmerchant device140 when information foruser102 has already be received from a previous check-in.
Once a connection is established withwireless beacon136, user device110 may be checked-in withmerchant device140 ifuser102 has not previously been checked-in. Once connected towireless beacon136, the identifier or other identification information foruser102 may be associated with a transaction. For example, an employee for the merchant location may useemployee device130 to scan one or more items/services for purchase byuser102 into a transaction, as will be explained in more detail herein. Once the transaction is established and generated, the identifier may be used to identify the transaction associated withuser102.User102 may then instruct the employee to suspend the transaction verbally or may utilizepayment application120 to suspend the transaction, such as through an instruction toemployee device130. Once the transaction is suspended,user102 may later recall the transaction using a transaction code provided touser102 or through a connection between user device110 and another wireless beacon at, nearby, or connected tomerchant device140. The transaction code may be provided touser102 throughpayment application120 fromemployee device130, may be a physical token, chip, or other item containing the transaction code, or may be verbally given touser102. In embodiments, where the transaction is resumed using a new connection between user device110 and a wireless beacon corresponding tomerchant device140, check-inapplication120 may connect to the wireless beacon as described above.
Payment application120 may be used, for example, to provide a convenient interface to permituser102 to select payment options and provide payment for items and/or services. For example,payment application120 may be implemented as an application having a user interface enabling the user to enter payment options for storage by user device110, provide payment to a merchant (e.g., through merchant device140), and complete a transaction for the items and/or services using a payment instrument (e.g., a payment account with payment provider server160). In certain embodiments,payment application120 may correspond more generally to a web browser configured to view information available over the Internet or access a website corresponding to a payment provider.
Payment application120 may receive a transaction code used to resume a suspended transaction fromemployee device130. The transaction code may later be transmitted tomerchant device140 to resume the transaction. Thus,payment application120 may transmit the transaction code tomerchant device140. Once the transaction is resumed,user102 may add additional items/services to the transaction (e.g., by scanning one or more additional items/service into the transaction) and/or the transaction may be processed with a payment and completed.Payment application120 may also provide stored incentives (e.g., loyalty account benefits, discounts, coupons, etc.) tomerchant device140 for use with the suspended transaction. The incentives may be provided when the transaction is suspended and/or when a payment for a transaction is being processed.
Payment application120 may be configured to provide payment tomerchant device140. In this regard,payment application120 may correspond to an application that may provide an interface whereuser102 may view a transaction for one or more items scanned byemployee device130. Additionally,user102 may generate a payment request for the transaction tomerchant device140. The payment request may provide a payment instrument, such as a credit/debit card, checking account, payment account, etc. Where a payment account is utilized,payment application120 may instructpayment provider server160 to provide payment for the transaction to the merchant. The payment request may correspond to a token including the selected payment instrument foruser102. The payment instrument may include an account identifier, payment card, bank account, etc. Once the payment request is generated,user102 may authorize the payment request for transmission tomerchant device140 and/orpayment provider server160 in order to effectuate a payment to the merchant.Payment application120 may transmit the payment request topayment provider server160 with an identifier for the merchant in order to complete the payment to the merchant. In other embodiments,payment application120 may transmit the payment request as a token with a payment instrument and identifier foruser102 tomerchant device140 for completion by the merchant.
In various embodiments, one or more features of check-inapplication112 and/orpayment application120 may be incorporated in the same application so as to provide their respective features in one application.
User device110 includesother applications114 as may be desired in particular embodiments to provide features to user device110. For example,other applications114 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork170, or other types of applications.Other applications114 may also include email, texting, voice and IM applications that allow a user to send and receive emails, calls, texts, and other notifications throughnetwork170. In various embodiments,other applications114 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server160.Other applications114 may include browser, social networking, and/or mapping applications. Various applications, features, and/or processes ofother applications114 may be used in conjunction with check-inapplication112 and/orpayment application120.Other applications114 may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.
User device110 may further includedatabase116 which may include, for example, identifiers such as operating system registry entries, cookies associated with check-inapplication112,payment application120, and/orother applications114, identifiers associated with hardware of user device110, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. Identifiers indatabase116 may be used by a payment/credit provider, such aspayment provider server160, to associate user device110 with a particular account maintained by the payment/credit provider.Database116 may include user device tokens and/or encryption keys, including an encryption key ofwireless beacon136,merchant device140, and/orpayment provider server160.Database116 may include identifying information for tokens enabling check-inapplication112 to identifyemployee device130,wireless beacon136,merchant device140, and/orpayment provider server160 when receiving a corresponding check-in token. In various embodiments,database116 may store information used to identify a suspended transaction, such as a transaction code or other identifier enabling identification of the suspended transaction.
User device110 includes at least onecommunication module118 adapted to communicate withemployee device130,wireless beacon136,merchant device140, and/orpayment provider server160. In various embodiments,communication module118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.Communication module118 may communicate directly withwireless beacon136 using short range communications, such as Bluetooth Low Energy, LTE Direct, radio frequency, infrared, Bluetooth, and near field communications.
Employee device130 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with user device110,merchant device140, and/orpayment provider server160. For example, in one embodiment,employee device130 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS®) and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a device is shown, the device may be managed or controlled by any suitable processing device. Although only one employee device is shown, a plurality of employee devices may function similarly.
Employee device130 ofFIG. 1 contains ascanning application132,scanner134,wireless beacon136, and acommunication module138.Scanning application132 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,employee device130 may include additional or different software as required.
Scanning application132 may correspond to an application having features and processes that interface withscanner134 to enable a merchant employee correspond toemployee device130 to enter information for one or more items and/or services selected byuser102 for purchase toemployee device130 and generate a transaction. In this regard, the merchant employee may utilizeemployee device130 to input the information, such as throughscanner134 and scanning/reading a barcode, QR code, or other readable information for the item/service (e.g., on a box, display panel, etc., for the item/service). In other embodiments, other input processes may be utilized to input information for the selected item(s)/service(s) toscanning application132.
Once the item(s)/service(s) for purchase byuser102 are entered by scanningapplication132 using, in various embodiments,scanner134, a transaction for the item(s)/service(s) may be determined and generated. The transaction may include transaction information having a name or identifier of the selected item(s)/service(s), a total cost and/or cost of each item/service, incentives applied to the transaction, payment information foruser102 to use for the transaction, and/or other information used to complete the transaction.Employee device130 may receive and/or access check-in information, an identifier, and/or other identification information foruser102. Such identification information may be received from user device110 based on a connection between user device110 and a wireless beacon (e.g., wireless beacon136), as previously discussed.Scanning application132 may associate the transaction with identification foruser102, such as the identifier, personal and/or payment information, or other information received fromuser102. Once the transaction and the identification are associated,user102 may choose to complete the transaction by providing payment for the transaction, in various embodiments, usingpayment provider server160.
In other embodiments,user102 may wish to suspend the transaction and later resume the transaction, for example, if services are required to be rendered touser102, if an employee at the merchant location is required to retrieve the item(s) in the transaction foruser102, ifuser102 wishes to continue shopping, or other circumstance. In such examples,user102 may choose to suspend the transaction withemployee device130 so that the transaction can later be resumed and processed withmerchant device140.User102 may inform the merchant employee to suspend the transaction usingscanning application132. When the transaction is suspended, the transaction and the identifier or other identification information foruser102 may be stored byemployee device130 and/or transmitted tomerchant device140 for storage.
While the transaction is suspended, no additional processing for the transaction (e.g., a payment) may be performed.User102 may be given a transaction code to recall the transaction later. The transaction code may be displayed to the merchant employee and/oruser102 onemployee device130. In other embodiments,user102 may receive a print out, token, RFID tag, or other physical possession that may store or display the transaction code. In other embodiments, the transaction may be stored with the identifier foruser102 and/or user device110 that was transmitted towireless beacon136. In such embodiments, the transaction may later be recalled when user device110 connects to another wireless beacon corresponding tomerchant device140 and transmits the identifier to the wireless beacon. Thus,merchant device140 may retrieve the transaction using the identifier foruser102/user device110 when user device110 is in proximity tomerchant device140.
User102 may update the transaction prior to processing and completing a payment for the transaction. For example,user102 may have one or more items/services added to the transaction, removed from the transaction, or updated in the transaction (e.g., with incentives or discounts for the selected item(s)/service(s)).User102 may utilize the transaction code to resume and update the transaction withemployee device130 or another employee device. In other embodiments,user102 may update the transaction on user device110 using the transaction code to recall and resume the transaction. Once the transaction is updated, a new transaction code may be generated or the previous transaction code may be further used. Onceuser102 is ready to complete the transaction by providing payment for the transaction,user102 may resume the transaction withmerchant device140 using the transaction code or through a connection to a wireless beacon corresponding tomerchant device140, as will be explained in more detail herein.
Scanner134 may correspond to a device and associated software (e.g., scanning application132) utilized to input items and/or services for a transaction.Scanner134 may include hardware utilized to capture information for item(s)/service(s) selected byuser102 for purchase. In this regard,scanner134 may correspond to an optical device (e.g., infrared scanner, camera, etc.) that may capture an alphanumeric code, bar code, QR code, text, or other data for an item or service and determine the item/service for entry into a transaction.Scanner134 may determine the item/service through a database ofemployee device140 and/or a remote database, such as adatabase146 ofmerchant device140. Oncescanner134 has received the item/service information,scanning application132 may add the item/service to a transaction, as previously discussed.
Wireless beacon136 may correspond to a device used withemployee device130 to connect to user device110, establish check-in information, and/or enableemployee device130 to associate an identifier foruser102/user device110 with a transaction.Wireless beacon136 may be implemented using any appropriate hardware and software configured for wireless communication with user device110. For example, in one embodiment,wireless beacon136 may be implemented as a dongle device including a hardware processor and a communication module, for example, connected toemployee device130.Wireless beacon136 may also be implemented as devices incorporated withinemployee device130. Additionally, a wireless beacon, such as one initially establishing check-in information at the merchant location and/or one corresponding tomerchant device140 for use in resuming a transaction, may also act as a stand-alone device including a processor, communication module, and/or network interface component configured to communicate with user device110,employee device130,merchant device140, and/orpayment provider server160. Althoughwireless beacon136 is described singly with respect toemployee device130, a plurality of wireless beacons may established at the merchant location, as previously discussed, and/or each associated with a plurality of employee devices.
Wireless beacon136 ofFIG. 1 contains processes, procedures, and/or applications, for example, a software program, executable by a hardware processor configured to interact with user device110,employee device130, and/ormerchant device140. Thus, regardless of the implementation ofwireless beacon136 as discussed above,wireless beacon136 may utilize a connection/check-in process and include or be connected to a communication module. In other embodiments,wireless beacon136 may include additional or different hardware and software as required.
Wireless beacon136 may include and/or execute an application for transmitting requests to establish a connection between a device (e.g., user device110) andwireless beacon136. The requests may be unique towireless beacon136, thereby identifyingwireless beacon136.Wireless beacon136 may utilize short range wireless communications ofwireless beacon136 to transmit the requests to establish a connection, including an identifier such as a Universally Unique Identifier (UUID). If user device110 receives a request to establish the connection withwireless beacon136 and responds with an identifier foruser102/user device110 (potentially including the UUID and other information necessary to effectuate a check-in foruser102, as previously discussed),wireless beacon136 to ramp up in power and create a connection between user device110 andwireless beacon136.
Wireless beacon136 may transmit the request to establish the connection as a short range wireless communication (e.g. a BLE protocol communication) including a “wake up” process for check-inapplication112 of user device110 and/or a token forwireless beacon136. In other embodiments, the request and/or connection may utilize near field communication, radio communication, infrared communication, or Bluetooth communication. Additionally, althoughwireless beacon136 may utilize BLE protocol communications to effectuate an “always on” type service where the UUID and “wake up” process are transmitted continuously or at some interval, other communication protocols used to provide an “always on” service may include QUALCOMM® LTE Direct or similar device-to-device communication technology. BLE and LTE Direct may both be utilized to provide discovery of nearby devices to wireless beacon136 (e.g., user device110) and establishment of a connection for data transfers. In other embodiments,wireless beacon136 may correspond to other devices, such as WiFi capable devices, near field communication devices, etc.
The request may be specific to user device110 by including information that is specific touser102 and/or user device110, such as a name, identifier, or user device identifier. The information specific touser102 may be determined from a user account ofuser102 or other information previously provided toemployee device130 and/or merchant device140 (e.g., a previous check-in, a loyalty account, etc.). Thus, in certain embodiments, only user device110 will pick up and authenticate the request, for example, ifuser102 has previously performed a check-in with themerchant device140. Afterwireless beacon136 receives an identifier from user device110,wireless beacon136 may determineuser102 is in proximity towireless beacon136.Wireless beacon136 may pass the identifier (and any other device's identifiers where applicable) toemployee device130 and/ormerchant device140 toassociate user102 withwireless beacon136.
Wireless beacon136 may utilize a communication module withinwireless beacon136 and/orcommunication module138 to pass the check-in information and/or identifier foruser102/user device110 tomerchant device140. Thus,wireless beacon136 and/oremployee device130 includescommunication module138 adapted to communicate with user device110 and/ormerchant device140.Communication module138 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.Communication module138 may also communicate with user device110 and/ormerchant device140 using short range communications, such as Bluetooth Low Energy, LTE Direct, WiFi, radio frequency, infrared, Bluetooth, and near field communications.
Merchant device140 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with user device110,employee device130,wireless beacon136, and/orpayment provider server160.Merchant device140 may correspond to a device utilized to complete a check-in foruser102 at a merchant location corresponding tomerchant device140.Merchant device140 may further be used to resume a suspended transaction and process and payment for the transaction. Thus,merchant device140 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS®) and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a merchant device is shown, the merchant device may be managed or controlled by any suitable processing device. Although only one merchant device is shown, a plurality of merchant devices may function similarly. Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference tomerchant device140 may be included inpayment provider server160, and vice versa.
Merchant device140 ofFIG. 1 contains a check-inapplication142, asales application150,other applications144, adatabase146, and acommunication module148. Check-inapplication142,sales application150 andother applications144 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,merchant device140 may include additional or different software as required.
Check-inapplication142 may correspond to processes to complete a check-in with user device110 for a merchant location corresponding to merchant device140 (e.g., a merchant storefront, an event venue, a transportation provider location including airports and train stations, or another service provider location). Thus, check-inapplication142 may correspond to the merchant device side application configured to receive check-in information (e.g., user account information, an identifier foruser102/user device110, user payment and/or person information, or other identification information foruser102/user device110) from user device110 and complete the check-in. The check-in request may include log in information for a user account withmerchant device140 and/orpayment provider server160 and thus complete the check-in withuser102 by verifying the account information. For example, the check-in information may include an identifier or other account information for a user/payment account ofuser102. However, in embodiments where a user account has not been previously established byuser102, check-inapplication142 may receive otherinformation identifying user102, including a user name/identifier, user device identifier, an identifier for an account with another entity, or other information.
As previously discussed, check-inapplication142 may perform a check-in foruser102 by receiving identification information foruser102 overnetwork170, from a wireless beacon established at the merchant location, and/or fromemployee device130 when user device110 connects towireless beacon136. Once check-in is completed between user device110 andmerchant device140, check-inapplication142 may be utilized to transmit and receive information corresponding touser102. Such information may include payment information, transaction codes, and/or identifiers used to resume a suspended transaction. In various embodiments, onceuser102 wishes to resume a transaction that has been suspended, check-inapplication142 may receive the request to resume the transaction and request the transaction be loaded tosales application150 fromemployee device130 and/ordatabase146.
Sales application150 may be used, for example, to provide a convenient interface to permit a merchant, salesperson, and/or other employee utilizingmerchant device140 to enter, view, and/or process items/services user102 wishes to purchase. For example,sales application150 may be implemented as an application having a user interface enabling the user ofmerchant device140 to enter the items/services user102 has selected for purchase (e.g., through input by the user and/oruser102, scanning the items/services, loading a suspended transaction of scanned items/services, etc.).Sales application150 may further enable the merchant to view the items/services for purchase byuser102 in a transaction, enter coupons and/or discounts for the transaction, edit the transaction including adding, removing, and/or modifying items/services, or other functions with regard to the selected transaction. Once the items/services have been arranged into a transaction, a total may be calculated and the transaction may be engaged withuser102 to complete payment for the selected items/services.
As previously discussed, a transaction may be loaded tosales application150 using a transaction code supplied byuser102 and/or user device110. The transaction code may recall a transaction that has been suspended and stored todatabase146, for example, whenemployee device130 generates the transaction anduser102 chooses to suspend the transaction. The transaction may also be recalled when user device110 connects to a wireless beacon at, nearby, and/or connected tomerchant device140. Thus, merchant device110 may receive a request to resume a transaction whenuser102 and/or user device110 provides a transaction code to resume the transaction and/or when user device110 is within a proximity tomerchant device140 and may connect tomerchant device140 and/or a wireless beacon corresponding tomerchant device140. Once the transaction is resumed, it may be processed and completed by receiving a payment instrument to complete a payment for the transaction and processing a payment using the payment instrument.
Sales application150 may request payment covering the transaction fromuser102.Sales application150 may receive a payment instrument fromuser102 to complete the transaction for the selected items/services. The payment instrument may correspond to cash, payment cards, checks, and/or payment accounts withpayment provider server160, in various embodiments. Once a transaction is processed and/or completed bysales application150 for the transaction, a transaction history (e.g., receipt) may be generated and provided to one or more ofuser102, user device110, and/orpayment provider server160. The transaction history may be stored todatabase146 and/or provided touser102, such as through a printout and/or electronic documentation with user device110.
Merchant device140 includesother applications144 as may be desired in particular embodiments to provide features tomerchant device140. For example,other applications144 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork170, or other types of applications. In various embodiments,other applications144 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server160.Other applications144 may contain other software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.
Merchant device140 may further includedatabase146 which may include, for example, identifiers such as operating system registry entries, cookies associated with check-inapplication142,sales application150, and/orother applications144, identifiers associated with hardware ofmerchant device140, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. In one embodiment, identifiers indatabase146 may be used bypayment provider server160 toassociate merchant device140 with a particular account maintained bypayment provider server160.Database146 may also storeuser102′s information, including check-in information, an identifier, or other identification information foruser102 received from a check-in byuser102 and/or a connection between user device110 and a wireless beacon (e.g., wireless beacon136).Database146 may include suspended transactions foruser102 with the identification information.
Merchant device140 includes at least onecommunication module148 adapted to communicate with user device110,employee device130,wireless beacon136, and/orpayment provider server160. In various embodiments,communication module148 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.Communication module148 may communicate directly withwireless beacon136 using short range communications, such as Bluetooth Low Energy, LTE Direct, radio frequency, infrared, Bluetooth, and near field communications.
Payment provider server160 may be maintained, for example, by an online payment service provider, which may provide payment services and/or processing for financial transactions on behalf of a user. In this regard,payment provider server160 includes one or more processing applications which may be configured to interact with user device110 and/ormerchant device140 to facilitate payment for a transaction. In one example,payment provider server160 may be provided by PAYPAL®, Inc. of San Jose, Calif., USA. However, in other embodiments,payment provider server160 may be maintained by or include a credit provider, financial services provider, financial data provider, and/or other service provider, which may provide payment services touser102 and/or the merchant. Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference topayment provider server160 may be included inmerchant device140, and vice versa.
Payment provider server160 ofFIG. 1 includes a transaction processing application162,other applications164, adatabase166, and anetwork interface component168. Transaction processing application162 andother applications164 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,payment provider server160 may include additional or different software as required, such as a check-in application as discussed in reference tomerchant device140, where those features are instead provided bypayment provider server160.
Transaction processing application162 may be configured to receive information from and/or transmit information to user device110 and/ormerchant device140 for processing and completion of financial transactions. Transaction processing application162 may include one or more applications to process financial transaction information fromuser102 and merchant formerchant device140 by receiving a request to complete transaction for items and/or services offered by the merchant The request may correspond to a payment fromuser102 to the merchant. The payment may include a user account identifier or other payment information (e.g. a credit/debit card or checking account) foruser102 and a receiving account for the merchant Additionally, the payment may include a payment amount and terms of payment. Transaction processing application162 may complete the transaction by providing payment to the merchant through the receiving account/payment information. Additionally, transaction processing application162 may provide transaction histories, including receipts, to user device110 and/ormerchant device140 for completion and documentation of the financial transaction. For example, a transaction history may be provided to user device110 and/ormerchant device140 to allow for the merchant to view the transaction and provide the items and/or services touser102.
In various embodiments,payment provider server160 includesother applications164 as may be desired in particular embodiments to provide features topayment provider server160. For example,other applications164 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) overnetwork170, or other types of applications.Other applications164 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user.
Additionally,payment provider server160 includesdatabase166. As previously discussed,user102 and/or the merchant may establish one or more payment accounts withpayment provider server160. User accounts indatabase166 may include merchant/user information, such as name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data.User102 and/or the merchant may link to their respective payment accounts through a user, merchant, and/or device identifier. Thus, when an identifier is transmitted topayment provider server160, e.g. from user device110 and/ormerchant device140, a payment account belonging touser102 and/or the merchant may be found. In other embodiments,user102 and/or the merchant may not have previously established a payment account and may provide other financial information topayment provider server160 to complete financial transactions, as previously discussed.
In various embodiments,payment provider server160 includes at least onenetwork interface component168 adapted to communicate user device110 and/ormerchant device140 overnetwork170. In various embodiments,network interface component168 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.
Network170 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments,network170 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus,network170 may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components ofsystem100.
FIG. 2 is an exemplary merchant location environment with users selecting items for purchase and suspending transactions for the items until arrival at a checkout line, according to an embodiment.Environment200 ofFIG. 2 includes auser202autilizing auser device210a,auser202butilizing auser device210b,and auser202cutilizing auser device210call corresponding generally touser102 utilizing user device110, respectively, ofFIG. 1. Moreover,environment200 includes anemployee device230 and amerchant device240 corresponding generally towireless beacon136 ofFIG. 1.
FIG. 2 shows amerchant store280 corresponding to a merchant storefront, retail location, or other physical place where users202a-202cmay shop for items/services, select one or more item/service for purchase, and engage in a transaction for the selected item(s)/service(s).Merchant store280 includes ashelf282aand ashelf282bwhere the merchant corresponding tomerchant store280 may place items for sale to users202a-202c.Users202a-202cmay previously have established a check-in withmerchant store280.User202amay place items into acart284 while browsingshelf282a.When placing items intocart284,user202amay scan the items in using a scanner withuser device210a(e.g., a camera and/or mobile phone application) that enters the information for the selected items to a transaction. Alternatively,cart284 may be equipped with a scanner, such as an infrared scanner, that may enter in the items to a transaction. In other embodiments,user202amay be required to visit with amerchant employee204 in order to scan the selected items incart284 into a transaction. Once items are entered to a transaction, the transaction may be suspended byuser202auntiluser202ahas received the items, completed shopping, and wishes to pay for the transaction. The previous check-in throughuser device210amay supply an identifier for use with suspending the transaction.
Ifmerchant store280 does not allow for self-scanning/entering of items to a transaction,user202bmay request thatmerchant employee204 enter anitem286 thatuser202bhas selected fromshelf282binto a transaction. Thus,user202bmay presentitem286 tomerchant employee204.Merchant employee204 may utilizeemployee device230 to scan initem286 into a transaction.User device210bmay have previously established a check-in withmerchant store280 to supply an identifier used with the transaction. Thus,employee device230 may include a wireless beacon that connects withuser device210band recalls the identifier. In other embodiments, the identifier may be supplied whenuser device210bandemployee device230 connect. Once the identifier is supplied toemployee device230, the identifier may be stored with the transaction anduser202bmay request the transaction foritem286 be suspended. As previously discussed, in some embodiments,merchant employee204 may provideuser202bwith a transaction code when suspending the transaction.
Once a user is ready to resume the transaction, such as if the user wishes to process a payment for the transaction, the user may approachmerchant device240 to process the transaction. Thus,user202carrives atmerchant device240 withuser device210cin order to resume and complete the transaction.User202cand/oruser device210cmay supply a transaction code tomerchant device240 in order to recall the transaction. However, in other embodiments,merchant device240 may include a wireless beacon within, nearby, and/or connected tomerchant device240 that connects withuser device210c.Thus, onceuser device210cand the wireless beacon connect,merchant device240 may be supplied with the identifier for the transaction, and the transaction may be recalled and resumed. Once the transaction is retrieved,user202cmay engage in a payment for the transaction.
FIG. 3 is an exemplary system environment showing display screens of a user device, an employee device, and a merchant device when suspending and resuming a transaction, according to an embodiment.Environment300 includes a user device310, anemployee device330, and amerchant device340 corresponding generally to user device110,employee device130, andmerchant device140, respectively, ofFIG. 1.
Employee device330 displays ascanning application interface332 corresponding generally to the processes and features described in reference toscanning application132 ofFIG. 1. As previously discussed,employee device330 may be utilized to generate a transaction from one or more items/services entered/scanned byemployee device330. In this regard,scanning application interface332 includes a transaction A1000 having scanned items1002, a user A identifier1004, and a suspend transaction1006 process. Scanned items1002 may include a list of the item(s)/service(s) in a transaction, and may include information about the item(s)/service(s), such as price, availability, stock room location, description, etc. Scanned items1002 may be populated after entering the item(s)/service(s) intoemployee device330 by a merchant employee. Transaction A1000 further includes user A identifier1004, which may correspond to an identifier or other identification information for the user of user device310 that wishes to purchase scanned items1002. The merchant employee corresponding toemployee device330 may further select to suspend transaction A1000 using suspend transaction1006 process. If the merchant employee suspends the transaction, the merchant employee may view transaction code1008, which may be provided to the user of user device310. The merchant employee may further transmit the suspended transaction A1000 tomerchant device340 for resuming later by selecting a transmit to register1010 process.
User device310 displays apayment application interface320 corresponding generally to the processes and features described in reference topayment application120 ofFIG. 1.Payment application interface320 includes a suspended transaction322 and atransaction code324. As previously discussed, the user of user device310 may have suspended transaction A1000. Thus, suspended transaction322 may appear to the user inpayment application interface320 so that the user may view the transaction and choose to resume and edit or pay as necessary. In order to recall the transaction withmerchant device340, the user may viewtransaction code324, which may include the code from transaction action code1008 and further include a process to transmit the transaction code tomerchant device340.
Merchant device340 displays a sales application interface350 corresponding generally to the processes and features described in reference tosales application150 ofFIG. 1. Sales application interface350 may be utilized to process a payment for the transaction. Sales application interface350 may load the transaction for payment after the user of user device310 requests to resume the transaction. Thus, once the user requests to resume the transaction, sales application interface350 includes a transaction352 having a payment status354 and a receipt356. Transaction352 may display the selected item(s)/service(s) for purchase by the user, such as scanned items1002. Once the user is ready to pay, payment status354 may display whether the payment for transaction352 has been processed, is pending, or has been rejected. Further, receipt356 may be utilized to provide a transaction history and documentation of payment for transaction352.
FIG. 4 is a flowchart of an exemplary process for suspending and resuming transactions through wireless beacon communications, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.
Atstep402, a transaction for a user is determined using an item selected by the user for purchase. The transaction may be determined by scanning at least one item or service using a barcode scanner or a QR code scanner. An employee at a merchant location may perform the scanning of the item using an employee device that includes a wireless beacon connected to the employee device. In other embodiments, the item may be scanned by the user when the user places the item in a holding basket, wherein the holding basket includes a wireless beacon. Thus, atstep404, the transaction is stored with an identifier for the user when a user device for the user connects to a wireless beacon for a merchant, wherein the identifier is accessed from check-in information for the user. The user device and the wireless beacon may connect using one of near field communication, radio communication, infrared communication, Bluetooth communication, Bluetooth Low Energy (BLE) communication, LTE Direct communication, and WiFi communication.
The check-in information may be received using a connection between the user device and another wireless beacon, wherein the first wireless beacon is connected to an employee device for an employee at the merchant location, and wherein the second wireless beacon is located at the merchant location, such as near a merchant payment device, POS device, and/or checkout device. For example, the second wireless beacon may be further located near a checkout line. The check-in information may also be received after the user completes a check-in for the merchant location over a network connection.
The transaction is accessed for a checkout or payment process by the user, atstep406. The transaction may be accessed by a merchant point of sale or checkout device using a transaction code, where the transaction code is previously generated that identifies the transaction and is communicated to the user. The transaction code may be communicated to the user device, wherein the user device communicates the transaction code to a point of sale or checkout device during the checkout/payment process. In various embodiments, prior to payment, another item or service may be added to the transaction, which may be updated. Additionally, incentives for the user may be accessed and processed with the transaction during payment. Thus, a payment for the transaction may be processed, for example, using a payment account with a payment provider.
FIG. 5 is a block diagram of a computer system suitable for implementing one or more components inFIG. 1, according to an embodiment. In various embodiments, the user device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers may be implemented ascomputer system500 in a manner as follows.
Computer system500 includes a bus502 or other communication mechanism for communicating information data, signals, and information between various components ofcomputer system500. Components include an input/output (I/O)component504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus502. I/O component504 may also include an output component, such as adisplay511 and a cursor control513 (such as a keyboard, keypad, mouse, etc.). An optional audio input/output component505 may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component505 may allow the user to hear audio. A transceiver ornetwork interface506 transmits and receives signals betweencomputer system500 and other devices, such as another user device, service device, or a service provider server vianetwork170. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One ormore processors512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display oncomputer system500 or transmission to other devices via acommunication link518. Processor(s)512 may also control transmission of information, such as cookies or IP addresses, to other devices.
Components ofcomputer system500 also include a system memory component514 (e.g., RAM), a static storage component516 (e.g., ROM), and/or adisk drive517.Computer system500 performs specific operations by processor(s)512 and other components by executing one or more sequences of instructions contained insystem memory component514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s)512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such assystem memory component514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus502. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.
Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.
In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed bycomputer system500. In various other embodiments of the present disclosure, a plurality ofcomputer systems500 coupled bycommunication link518 to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.
Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.
Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.