Patent Application
20240257225
Retail entities often provide customers with multiple ways to purchase items. The ability to use one or more of these ways of purchasing can simplify shopping and purchasing items for many customers. There is a need to further enhance retail shopping and/or purchasing.
Disclosed herein are embodiments of systems, apparatuses and methods pertaining to purchasing through customer devices. This description includes drawings, wherein:
Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. Certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. The terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.
The following description is not to be taken in a limiting sense, but is made merely for the purpose of describing the general principles of exemplary embodiments. Reference throughout this specification to “one embodiment,” “an embodiment,” “some embodiments”, “an implementation”, “some implementations”, “some applications”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” “in some embodiments”, “in some implementations”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Some embodiments enable customers, while at a retail facility, to select items they intend to purchase during a purchase session as they move through the retail facility, and using a mobile computing device to identify the items and incorporate those items into a virtual cart. Through an application executed on the computing device, the customer can further complete a purchase of the items incorporated into the virtual cart during that session. It has been identified, however, that it can be further beneficial to enable a customer to further purchase one or more additional items through the mobile device without the customer having to leave the retail facility (i.e., enabling subsequent purchase sessions without having to exit and reenter the retail facility). Accordingly, some embodiments provide systems that computing devices through communications over a distributed communication network to enable the initiation of one or more subsequent additional purchase sessions to purchase one or more additional products associated with one of those additional sessions. Still further, the multiple sessions associated with a single customer can be linked as a single transaction enabling a subsequent confirmation that items each of the separate sessions during a single audit process, which may or may not be completed without increasing communication bandwidth and/or introducing additional undesirable delay.
Further, the one or more purchase control systems 102 can be in communication over the one or more communications networks 104 with customer computing devices 110, each associated with a respective customer and temporarily at the retail facility as the customers are at one of the retail facilities shopping for items to purchase. At least some of the customer computing devices can store and execute one or more customer applications (APPs), including but not limited to a cart compile and/or self-purchase application (APP) 112. The cart compile APP 112 enables the customer to identify, through the customer computing device 110 one or more items intended to be purchased, and in some instances complete a purchase of the one or more items identified. Such identification of items for purchase can be identified through one or more methods and/or techniques, such as but not limited to selection from a listing of one or more items displayed on the computing device, image recognition of an item, optical scanning of a unique optically scannable identifier (e.g., barcode, QR code, etc.), optical character recognition (OCR), other such methods or a combination of two or more of such methods. For example, the item recognition can be achieved through one or more methods as described in one or more of U.S. Pat. No. 10,121,133 entitled Method For Self-Checkout With A Mobile Device; U.S. Pat. No. 10,872,326 entitled Systems And Methods Of Product Recognition Through Multi-Model Image Processing; and U.S. Pat. No. 11,263,682 entitled System And Method For Coupling A User Computing Device And A Point Of Sale Device; each of which is incorporated herein by reference in its entirety.
The purchase enabling system 100, in some embodiments, further includes and/or is in communication with one or more databases 114 that store various information. Such databases can include but are not limited one or more product databases 114a of the retail entity, one or more inventory databases 114b of the retail entity, one or more transaction databases 114c, one or more delivery resource databases, one or more application programming interface (API) databases storing multiple different APIs, other such databases, or a combination of two or more of such databases. In some embodiments the product database 114a includes one or more product computer storage and/or memory systems communicatively coupled with the distributed communication network 104 and stores product information comprising product identifying information for a plurality of different products, and sets of product characteristics information each corresponding to a respective one of the plurality of different products. The product characteristic information can include, for example, size information, dimensions information, weight information, ingredient information, color information, quantity information, purchase restriction information (e.g., age restriction, prescription requirement information, quantity restriction, legal restrictions, and/or other such restriction information), handling restrictions and/or instructions information, pricing information, related products information (e.g., pairing, relevance to, use with, often purchased with, etc.), other such information, or typically a combination of two or more of such information.
One or more inventory databases 114b of the retail entity, in some embodiments, comprise one or more inventory computer storage and/or memory systems communicatively coupled with the communication network 104 and store product quantity information at one or more locations and/or storage locations corresponding to each of at least a subset of the plurality of different products that are available from a respective one of each of multiple different retail facilities and/or locations. The inventory information, in some embodiments, may include pricing, shipment data, demand data, other such information, or a combination of such information relative to one or more of the products.
The transaction databases 114c, in some embodiments, in some embodiments, comprise one or more transaction computer storage and/or memory systems communicatively coupled with the communication network 104, that can be configured to maintain transaction information about multiple different pending and/or completed purchase transactions between different customers and one or more retail entities. The transaction information can include but is not limited state and/or status information about transactions, customer identifying information of a respective customer implementing or that implemented the transaction, products identifying information associated with respective transactions, transaction identifier information, whether the transaction is a multi-session transaction, number of pending, completed and/or aborted purchase sessions linked to a transaction, session identification information, error information, other such information, or a combination of two or more of such information.
Other databases can include, for example, one or more delivery resource databases can maintain information about, but not limited to, delivery vehicles relative to one or more locations and/or facilities, delivery scheduling relative to one or more locations and/or facilities, resource capabilities and/or availabilities (e.g., expected and/or maximum product movement rates, product storage capabilities and/or availabilities, predicted future capabilities and/or availabilities (e.g., based on up coming events, holidays, associate availabilities, etc.), other such factors, or a combination of two or more of such factors) relative to one or more locations and/or facilities, other such information or a combination of two or more of such information. Other databases may be included and/or accessible to the retail purchase enabling system 100.
The purchase enabling system 100 can further includes and/or be in communication with one or more point of sale (POS) systems 116. The POS systems 116 can include, but are not limited to, associate operated point of sale (POS) systems operated by an associate employee of the retail facility, self-checkout point of sale (POS) systems that enable customers to scan and pay for items, and/or other such point of sale systems. The POS systems typically include and/or are in communication with one or more scanning systems (e.g., barcode scanners, QR code scanners, RFID scanners, etc.) and/or other sensors systems (e.g., scales, optical sensors, imaging systems, etc.), from which the POS system can receive item information about items being purchased.
The purchase enabling system 100, in some embodiments, can include and/or be in communication with an inventory system 120 that can track inventory levels to provide information to customers, associates and other systems. In some implementations the inventory system can initiate orders and/or shipments for additional items at one or more retail facilities, direct the restocking of shelves and/or displays of one or more retail facilities, track item demand, other such functions, and typically a combination of two or more of such functionality. Some embodiments further include and/or are in communication with one or more item retrieval systems 122 at one or more retail facilities that can receive item information based on purchases and/or orders of respective items, and control the retrieval of the one or more items from one or more retail facilities. Such retrieval may be in preparation for product delivery, product pickup or other method of providing a purchased product to a user. In some embodiments, the product retrieval system 122 can include and/or be in communication with one or more robotic retrieval devices, associate computing devices 106, conveyor systems, packaging systems, item route control systems, other such systems, and typically a combination of two or more of such systems that can cooperatively be controlled to retrieve products for restocking and/or to provide to customers (e.g., directly within a retail facility, routed to a pickup location, and/or delivered to one or more locations). Some embodiments further include and/or are in communication with one or more delivery control systems 124 each associated with one or more retail facilities from which products can be retrieved and delivered. The delivery control systems 124, at least in part, can be configured to schedule and manage product deliveries for restocking, for other facilities and/or for customers. In some implementations, for example, the delivery control system coordinates deliveries based on locations and allocates the collection of products to one or more particular vehicles, in part, in attempts to focus delivery routes and reduce travel times between deliveries. Other such factors can be taken into account by the delivery control systems 124 to manage delivery and control delivery systems and/or vehicles (e.g., trucks, vans, drones, third party delivery services, etc.).
Still referring to
In some implementations, the customer can complete the purchase of the one or more items directly through the cart compile APP 112. Additionally or alternatively, the customer may take advantage of a point of sale (POS) system operated by an associate employee of the retail facility, a self-checkout point of sale (POS) system to complete the purchase of the one or more items, and/or other such method. When completing through the cart compile APP 112, some items may have purchase restriction conditions that are to be evaluated and/or satisfied before the sale of at least that item. For example, some items have age restriction conditions that are to be met prior to a sale of that item being finalized and/or before the customer can take the item from the retail facility. Other restriction conditions can include, but are not limited to a confirmation of identification of the customer (e.g., prescription medicines, pre-ordered items, items exceeding a particular value, etc.), safety object removal restriction condition to remove one or more objects from an item (e.g., theft prevention object), other such restriction conditions or a combination of two or more of such restriction conditions. Still further, in some instances and/or at some retail facilities, the customer may be subject to a checkout or exit audit by one or more retail facility associate (e.g., an employee of the retail facility, an automated audit system (e.g., include multiple RFID tag readers and/or scanners), or other such associate). In some embodiments, the associate can utilize one or more associate computing devices 106, which can identify items, obtain information about products purchased, obtain customer information, and/or other such actions. Based on this information the associate computing device 106 and/or the associate operating the associate computing device can confirm purchases, finalize and complete purchase transactions (e.g., following the confirmation of satisfying one or more restriction conditions, determine that items have been identified in a virtual cart, and/or other such conditions), confirming payment method, and/or other such actions.
The purchase enabling system 100, in some embodiments, beneficially enables customers to establish multiple different purchase sessions in performing shopping. As one non-limiting example, a customer may complete the purchase of a first set of one or more items, and then realize that they want to purchase one or more additional items. As another non-limiting example, a customer may want to purchase a first set of one or more items using a first payment method, and purchase one or more other sets of one or more items using one or more different payment methods. Accordingly, some embodiments enable the implementation of multiple purchase sessions that allow the customer to purchase items, use different payment methods, other such actions where it may be beneficial to group one or more items, or a combination of two or more such actions.
The purchase control system 102, implemented through one or more purchase control circuits, can be configured to receive a session notification to initiate an additional purchase session from a customer computing device 110, which is associated with a particular customer. Again, in some implementations, the customer computing device 110 may be executing a cart compile APP 112 that provides the session notification. The session notification to initiate an additional purchase session may be received in response to an activation by the customer of an additional purchase option provided on a confirmation user interface and/or other user interface displayed on the customer computing device 110. Further, in some instances, the addition purchase session option my be presented in association with a first purchase session where the customer has identified a first set of one or more items to purchase relative to that first purchase session, such as in response to selecting a check-out option designating a completion and desire to purchase the items corresponding to a first virtual cart, a selection of an additional purchase session option when customer desires to use a different method of payment for one or more items, and/or other such instances where a customer may desire to initiate a separate purchase session. As one non-limiting example, the customer may build a first virtual cart by scanning one or more items using the customer computing device 110, and select a check-out option and designate a payment method for those items in completing the sale of the one or more items. Subsequent to the check-out the customer may identify one or more additional items to purchase, and select through a user interface displayed by the cart compile APP 112 (e.g., selection of a “Purchase More Items” option displayed on a purchase confirmation user interface presented to the customer in response to completing a check-out through the cart compile APP 112).
In response to the session notification, the purchase control system 102 can establish a second purchase session. In some embodiments, the purchase control system 102 identifies a customer with which the second purchase session is to be established, such as based on the cart compile APP 112 providing customer identifying information, customer computing device identifying information, previous session identifying information, other such identifying information, or a combination of two or more of such identifying information. The purchase control system 102 can utilize the identifying information to confirm that a previous session was established and associated with the customer. Further, in some embodiments, the purchase control system 102 and/or cart compile APP 112 link the second purchase session with the first purchase session. Still further, the linking between the first purchase session and the second purchase session in some embodiments provides an associated single purchase transaction linking the first purchase session and the second purchase session. In instances where the first purchase session is already linked as a single transaction with one or more additional purchase sessions, the second purchase session is further linked to the single transaction linking the second purchase session with the first purchase session as well as the one or more additional purchase sessions. As such, some embodiments enables the linking of two or more purchase sessions, and in some instances are linked as a single transaction. In some implementations, the first purchase session is already linked to the single purchase transaction prior to the establishing of the second purchase session (e.g., the single transaction is established at the time the first purchase session is initiated and linked with the single transaction). In other instances, the single transaction is established in response to the session notification, and both the first and second purchase sessions are linked to the single transaction. The association of the multiple purchase sessions as a single transaction enables the multiple purchased sessions to be cooperatively identified. For example, in some implementations, the transaction is assigned a transaction identifier that is associated with respective session identifiers for each of the linked purchase sessions. As such, the single transaction identifier can be used as reference to the multiple sessions.
A second virtual cart can be initiated for the second purchase session with the second virtual cart considered separate and different than the first virtual cart corresponding to the first purchase session. In some implementations, the purchase control system 102 directs the cart compile APP 112 to initiate the second virtual cart within the cart compile APP 112 and enables the customer to identify one or more additional items to be incorporated into the second virtual cart. In some embodiments, the cart compile APP 112 can add one or more items to the second virtual cart and maintains the second virtual cart local on the customer computing device. Cart information can periodically be communicated to the purchase control circuit and/or at the time of completing the purchase of the items added to the second virtual cart. In other implementations, the cart compile APP 112 can communicate item identifying information for each item identified to be purchased, and the purchase control system incorporates the item identifying information into the second virtual cart, with cart information being provided to the customer computing device to display the update to the second virtual cart. As such, the item identifying information can be incorporate into a second virtual cart, associated with the second purchase session, for each of one or more items identified, through the customer computing device 110, by the customer and intended to be purchased by the customer in association with the second purchase session.
Based on the linking of the multiple purchase sessions (e.g., first purchase session and the second purchase session) as a single transaction, the purchase control system 102 can establish transaction identifying information that corresponds to each of the multiple linked purchase sessions. Similarly, as introduced above, in some implementations, the purchases implemented by the customer through the cart compile APP 112 are confirmed and/or audited, such as audited by one or more associates of the retail facility prior to the customer leaving the retail facility with purchased items. In some embodiments, the purchase control system 102 can cause a final authentication of the single transaction in authenticating at a single time both the first session and the second session, instead of having an authentication of the first session and separately causing an authentication of the second session as separate acts. The single transaction enables the confirmation of purchase of any item of the multiple items from any of the multiple purchase sessions linked to the single transaction. This can increase the speed of the audit while still providing level of security and/or theft prevention, and in some instances prevents a check-out audit of a multiple session transaction from being longer that a single session transaction check-out audit, when audit does not result in issues, error and/or other factors that have to be addressed prior to completing the check-out audit.
In some embodiments, the check-out audit is simplified through the use of a single transaction identification that enables an associate computing device 106 being used as part of the check-out audit to quickly and easily access purchase session information for each purchase session linked as part of the single transaction. In some instances, this can include the customer computing device 110 displaying transaction identifying information that can be used by an associate computing device 106 to access the transaction information, including information for each of the multiple purchase sessions linked as the single transaction. The purchase control circuit can be configured, in some embodiments, to communicate transaction information to the customer computing device 110 with information from each of the multiple purchase sessions of the single transaction (e.g., information corresponding to both of the first purchase session and the second purchase session). Further, this information can control the customer computing device 110 in displaying a single transaction optical machine-readable representation corresponding to the single transaction. Such machine-readable representations can be a quick response (QR) or matrix code, barcode, string of alphanumeric and/or symbol characters, other such machine-readable codes, or a combination of two or more of such codes. The single optical machine-readable representation can encode dynamically generated unique session identifiers of each purchase session linked to the single transaction. For example, the single optical machine-readable representation can include a first unique session identifier corresponding to the first purchase session and a second unique session identifier corresponding to the second purchase session, when the single transaction links the first purchase session and the second purchase session. Typically, the unique session identifiers are generated by the purchase control system 102. In other instances, however, the unique session identifiers may be generated by the cart compile APP 112 (e.g., in response to detecting an activation or selection of a “Purchase More Items” option).
The exit audit APP 108 can similarly provide information about the transaction and/or sessions of a multi-session transaction. For example, an audit user interface may be displayed in response to scanning a transaction code. The audit user interface can identify the transaction as a single session transaction or a multi-session transaction. Similarly, options may be provided to get details about different sessions, such as an option to see identifiers and/or codes of each session, item lists of one or more of the sessions, indications of purchase restriction conditions and/or other such information.
In some embodiments, the cart compile APP 112 being executed by the customer computing device 110 uses the received transaction information to dynamically generate, locally by the customer computing device, the transaction optical machine-readable representation 252 that encodes dynamically generated unique session identifiers of each purchase session linked to the single transaction. In other implementations, a purchase control circuit generates the transaction optical machine-readable representation corresponding to the single transaction, and communicates the information of the transaction optical machine-readable representation of the single transaction to enable the customer computing device, typically through the cart compile APP, to display the optical machine-readable representation corresponding to the single transaction. This single transaction optical machine-readable representation corresponds to the single transaction and can be used in a purchase confirmation process, enable customer and/or others to access details about one or more of the multiple purchase sessions of the single transaction and/or other such uses.
As introduced above, in some instances a customer may be asked to confirm some or all of the purchases made through the cart compile APP 112 and/or other purchases. The associate computing devices 106 can, in some implementations, be used to help in performing an exit audit of customer purchases. The associate computing devices 106 can include one or more associate device control circuit that are configured to execute the exit audit APP 108 and to communicate via the distributed communication network 104 with the mobile purchase control system 102. Each of the associate computing devices 106, in executing the exit audit APP 108, can be configured to identify multiple scanned unique session identifiers of the single transaction. In some instances, the exit audit APP can extract and decoded the one or more unique session identifiers from the transaction optical machine-readable representation 252. For example, the optical machine-readable representation may be scanned by a barcode scanner and information provided to the exit audit APP, the exit audit APP may control an imaging system of the associate computing device to capture one or more images of the optical machine-readable representation and decode the unique session identifiers, communicate some or all of the image and/or information extracted from the image to a separate processing system and receive the unique session identifiers based on that processing, other such methods or a combination of two or more of such methods.
In some embodiments, customer computing device 110 can display the transaction optical machine-readable representation enabling the displayed transaction optical machine-readable representation to be scanned, or otherwise processed by the associate computing device 106, or other scanning or imaging system. For example, a scanning device may be positioned proximate to where an associate is intended to perform the audit, and customer can scan the transaction optical machine-readable representation. The scanning device can communicate the information to the associate computing device and/or a separate processing device that communicates the relevant session identifiers and/or information about products purchased in each session. In other embodiments, the customer device may additionally or alternatively display optical machine-readable representations of each purchase session encoding the session identifier. Each of the multiple scanned unique session identifiers corresponds to one of multiple purchase sessions linked to the single transaction and/or correspond to purchase sessions that have not yet been audited or otherwise confirmed. The associate device control circuit in executing the exit audit APP 108 can be configured to cause the associate computing device 106 to display, in response to identifying the purchase sessions of the single transaction, a listing of session identifiers of each of the multiple sessions linked to the single transition and/or display in association with a respective one of the session identifiers a listing of one or more item purchased through the respective purchase session.
The audit may include providing instructions to the associate through the associate computing device, to confirm one or more products attempting to be taken from the retail facility by the customer have been purchased. In some embodiments, the exit audit APP 108 receives item identifier information from a scanning device (e.g., barcode scanner, imaging device, RFID scanner device, etc.) and/or enables the utilization of a camera system of the associate computing device 106 to capture one or more images of a respective item and obtain or otherwise extract identifying information of the respective item (e.g., barcode of the item, QR code of the item, OCR of text, color pattern recognition, etc.), and identify one or more items attempting to be removed from the retail facility by the customer. Using the session identifier the exit audit APP 108 can obtain listings of products associated with each of the one or more purchase sessions of the single transaction, and can be configured to confirm that each of the item identifiers obtained by scanning or the like is included in at least one of the multiple sessions.
The audit confirmation may not require a confirmation of all items attempting to be removed by the customer, and instead may be limited. The limit may be a fixed number (e.g., scan any three items, scan any five items, scan any 10 items), may be based on a number of items associated with the multiple purchase sessions, may be based on the number of purchase sessions of a single transaction, may be based on a cost of one or more items, may be based on a total cost of one or more sessions, may be based on a total cost of the sessions of a single transaction, other such factor or a combination of two or more of such factors. The exit audit APP 108, in some instances, can provide instructions to the associate directing the associate regarding the number of items to scan and/or specific items to be scanned. Further, in some instances, the exit audit APP 108 can cause the associate computing device 106 to display an audit and/or purchase confirmation user interface in response to confirming the items identified were included in one of the purchase sessions. An audit confirmation may be communicated to the purchase control system 102, which in turn may provide a customer audit confirmation to the customer computing device 110 to control the customer computing device to display a customer audit and/or purchase confirmation user interface.
The sale of one or more items of a given purchase session may be finalized and payment obtained by the purchase control system 102 in response to the user authorizing check-out and/or other payment authorization (e.g., by selection of a payment method, and confirming an authorization for the retail entity to obtain payment via the selected payment method). In other instances, the final sale and receipt of payment may not occur at the time the customer completes a check-out, and instead payment may be finalized and received following the exit audit and/or in response to confirming that one or more purchase restriction conditions are satisfied and/or completed. As introduced above, some products, purchase sessions and/or transactions are associated with one or more purchase restriction conditions. Accordingly, the exit audit can be used, in some instances, to confirm the satisfaction of the one or more purchase restriction conditions.
The purchase control system 102 can be configured to identify that one of the purchase sessions of a single transaction includes at least one item having a purchase restriction condition. Depending on the type of purchase restriction condition, the purchase control system 102 can incorporate restriction information into the transaction information that can be provided to the customer computing device 110 and/or associate computing devices 106 corresponding to the multiple purchase sessions. In some embodiments, the detection of a purchase restricted item (e.g., age restriction) in a first one session of the multi-session transaction can cause the first session to be designated as a purchase restricted session. Additionally or alternatively, in some instances the multi-session single transaction with which the first session is linked can be designated as a purchase restricted transaction based on the one or more sessions including the item having a restriction condition. This designation of the single transaction as a purchase restricted transaction, in some instances, can be implemented regardless of whether any of the other purchases session of the single transaction include an item with a purchase restriction. Some embodiments can designate one or more other linked sessions or all of the sessions linked in the multi-session transaction to similarly be designated as purchase restricted sessions linking the restriction condition across two or more of the other checkout sessions based on the link to the first session including the purchase restricted item. Accordingly, the exit audit of such a purchase restriction designated single transaction, in some embodiments, cannot be finalized until the restriction condition is satisfied, the purchase session having the purchase restricted item is aborted and/or the purchase restricted item is removed from the respective session. Further, the purchase control system 102, in compiling the transaction information to be communicated the customer computing device and/or the associate computing devices 106 cause the customer computing device 110 and/or associate computing device to indicate in relation to the optical machine-readable representation corresponding to the single transaction and/or the identification of the single transaction that the single transaction is a purchase restricted transaction and/or one or more purchase sessions is a purchase restricted session. Such restriction designation can include substantially any relevant designation, such as but not limited to a different color scheme, textual notice, a header, flashing of one or more objects of a displayed interface, a different shape and/or kind of optical machine-readable representation, other such designations, or a combination of two or more of such designations. For example, the information from the purchase control system 102 can control the customer computing device 110 when displaying a purchase confirmation user interface 250 to display the optical machine-readable representation 252 in a different color (e.g., red or other color), incorporate a header and/or a textual restriction notification 260 (e.g., indicating a type of restriction condition, such as but not limited to an age restriction condition).
The purchase control system 102 can further be configured in communicating the transaction information to include a transaction restriction notification that provides some control over the customer computing device causing the customer computing device, when displaying the optical machine-readable representation 252, to include a displayed designation (e.g., change in color, color pattern, header, textual content, flashing, etc.) indicating that the single transaction is a purchase restricted transaction. Additionally or alternatively, the display of the transaction machine-readable representation 252 (and/or session machine-readable representations) and/or purchase confirmation user interface 250 can include or be accompanied with the display of one or more instructions to take one or more action to satisfy the purchase restriction condition. The instructions may be directed to the customer and/or the associate performing the audit. Similarly, the associate computing device 106 in implementing the exit audit APP 108 can further be configured, upon scanning the transaction machine-readable representation 252 and/or the session machine-readable representations, to display a restriction condition designation (e.g., change in color, color pattern, header, textual content, flashing, etc.) indicating that the single transaction is a purchase restricted transaction, and/or instructions to take one or more action to satisfy the purchase restriction condition. The instructions can include, but is not limited to, instructions to confirm a customer's age, instructions to confirm a customer's identification, directing the removal of anti-theft and/or protection features, other such instructions, or a combination of two or more of such instructions.
Similarly, in executing the exit audit APP 108, an associate device control circuit of an associate computing device can be configured to identify, in response to scanning the optical machine-readable representation 252, that the transaction and/or a first item of a first session of the multi-session transaction has a purchase restriction condition, and display a restriction condition user interface that, in some implementations, can include an entry option that is configured to receive a current condition corresponding to the purchase restriction condition. For example, the entry option may include a one or more fields to enter a customer's date of birth, an option to activate an imaging system to capture an image of a customer's government issued identification and image processing to determine whether corresponding age satisfies an age restriction, and/or other such entry options. The exit audit APP 108 can receive a current condition response based on interaction of an associate through the restriction condition user interface, and determine whether the restriction condition is satisfied. The evaluation of the received condition information may, for some restriction conditions, be processed by the exit audit app. In other instances, the received condition information may be communicated to the purchase control system 102 for processing and/or evaluation, with a response communicated back to the associate computing device. In some instances, when it is determined, based on the received current condition, that the purchase restriction condition is unsatisfied, the exit audit APP 108 can prevent authorization of a completion of a sale of at least the first item in at least the first session. In some instances, the exit audit APP 108 can prevent authorization of a completion of sales of all items in at least the first session in response to confirming, based on the current condition, the purchase restriction condition is unsatisfied.
Further, in some embodiments, the failure to satisfy one or more purchase restriction conditions can result in an error condition. Other error conditions can occur during the exit audit. Such errors may include a failure to receive payment. As introduced above, some sessions may not be finalized and payment received until one or more conditions are satisfied, such as confirming satisfaction of one or more purchase restrictions, or other conditions. Other embodiments may finalize and receive payment upon the exit audit being completed.
Accordingly, should the receipt of payment be unsuccessful at the time of the exit audit, an error condition typically results. Similarly, should a failure to satisfy a restriction condition occur, and error condition can result.
In response to a failure of one or more purchase restriction conditions and/or other errors, an error notification may be communicated from the purchase control system 102 and/or the associate computing device 106 to the customer computing device 110 to control the customer computing device to display the error notification. In some instances, the error notification identifies the corresponding purchase session that has experienced the error and/or failed to satisfy a purchase restriction. Some embodiments may further provide a user selectable abort option displayed in an error notification user interface displayed through the customer computing device 110 and/or the associate computing device 106. For example, should an age restriction condition of an item associated with a first purchase session of the multi-session transaction be unsatisfied at the exit audit, an error user interface may be displayed on the customer computing device 110 and/or the associate computing device 106 with an abort option. The customer, through the customer computing device 110, or the associate through the associate computing device can initiate a session abort of the first session, or in some instances a transaction abort option. The cart compile APP 112 or the exit audit APP 108 can communicate the abort notification to the purchase control system. The purchase control system 102 can abort the first session of the single transaction in response to receiving an abort notification communicated from the customer computing device or the associate computing device based on a selection by the customer or associate of the abort option. The aborting of one of the sessions of the multi-session transaction, however, does not necessarily require aborting the entire transaction. Accordingly, the purchase control system 102 can abort the first transaction, which can include preventing receiving payment and/or refunding payment for those items in the first session, while maintaining one or more other purchase session as active and as part of the single transaction.
Other errors and/or conditions may result during the exit audit. The purchase control system and exit audit APP 108 can be configured to respond to different error conditions. For example, an error condition may result when an item is scanned during the exit audit and determined that the scanned item is not included in any of the purchase sessions of the single transaction (e.g., the customer incorrectly scanned the item and thus the item was not added to a virtual cart, the customer inadvertently did not scan the item to incorporate the item into a virtual cart, etc.). In such instances, the exit audit APP 108 can notify the associate of the error and direct the associate to inquire whether the customer wants to leave without the item or purchase the item. In those instances where the customer wants to purchase the item the customer may initiate another purchase session (e.g., through the purchase more items option in the purchase confirmation user interface), assuming a session limit for the particular single transaction has not been reached. Similarly, some embodiments enable the automatic initiation of an additional purchase session, assuming a session limit has not been reached, as part of the single transaction.
In some embodiments, the purchase control system 102 can be configured to automatically establish, in response to a determination at an associate computing device 106 that an identification of a first item attempting to be removed from the retail facility by the customer in association with other items of the single transaction is not an item included in one of the multiple sessions of the single transaction, an additional purchase session corresponding to an additional virtual cart automatically implemented. Further, the purchase control system can automatically incorporate, without further interaction, at least a first item identifier of the first item into the additional virtual cart. This additional purchase session can additionally be linked with the single transaction and/or other one or more sessions of a single transaction. In those instances where there is only a single purchase session at exit audit, a single transaction may be established in response to the establishing of the additional purchase session and linking between the initial purchase session and the additional purchase session. Purchase session information corresponding to the additionally created purchase session and/or virtual cart information of the additional virtual cart can be communicated to the customer computing device and the cart compile APP 112 can be configured to cause the customer computing device to display the additionally created virtual cart on the customer computing device. This can allow the customer to view the cart, confirm the item or items in the cart and complete the sale, which may include allowing the customer to select a method of payment and/or preform other options. By allowing the multiple sessions, a customer can select different methods of payment for different purchase sessions. In some embodiments, a customer can view a first virtual cart, select one or more items from that first cart to be virtually moved into a second virtual cart. The creation of the second virtual cart can induce a second purchase session to be initiated and linked with the first purchase session. The sale of these separate sessions can then allow the customer to use the same or different methods of payment for the separate sessions. Similarly, the check out of different sessions can, in some embodiments, include an option to allow the customer to select a method of payment and/or enter a new method of payment. As such, different methods of payment can be used for different purchase sessions.
Additionally or alternatively, the purchase control system 102 can provide virtual cart information to an associate computing device, such as the associate computing device being used to perform the exit audit or another associate computing device to which the customer is directed as a result of an error condition. The associate computing device may be configured to display a virtual cart user interface with a check-out option that the associate can allow the customer to activate or an associate can select in response to verbal authorization from the customer to complete the sale. Again, the newly created purchase session is linked as part of the single transaction and the exit audit can be re-activated and/or continued to finalize the sale and complete the exit audit.
The detection of one or more errors at the exit audit can additionally or alternatively result in a failure to complete the sale of one or more items of one or more sessions or the entire single transaction. The purchase control circuit 102, in some embodiments, can instead direct the customer to a point of sale (POS) system to complete the sale of one or more items through traditional purchasing methods instead of through the cart compile APP 112. In some instances, the purchase control system 102 can receive, from an associate computing device 106, one or more scanned unique session identifiers and/or a transaction identifier extracted and decoded by the associate computing device from the transaction optical machine-readable representation 252 or one or more session machine-readable representations 254a-b in response to optically scanning the optical machine-readable representation displayed by the customer computing device corresponding to the single transaction, or one or more sessions. Each of the multiple session identifiers corresponding to one of the multiple purchase sessions linked relative to the single transaction. The purchase control system can be notified of and/or determine an error condition associated with one or more sessions of the transaction. Based on the error and/or a failure to cure the error condition, the purchase control system can communicate a point of sale (POS) notification to the customer computing device 110 to control the customer computing device to display an error user interface directing the customer to return to a POS system 116 to complete a sale of the one or more items associated with the first session. The purchase control system 102 can abort the one or more sessions associated with the error condition, or the entire transaction should the error correspond to each session of the transaction. The purchase control system 102, in some implementations, can additionally or alternatively communicate an associate POS notification to the associate computing device 106 to control the associate computing device to display an error instruction user interface notifying that the customer is to return to a POS system 116 to complete a sale of the one or more items associated with the error session or sessions.
An associate computing device, executing the exit audit APP 108 through one or more associate device control circuits, can be configured to identify, from a listing of recent POS purchase sessions, a POS purchase session corresponding to the customer. Based on the correlation with the customer, the customer computing device can cause a merging to link the POS purchase session with the single transaction. This linking of POS purchase sessions with the single transaction enables customers to take advantage of POS systems 116 in addition to purchases through the customer computing devices. Similarly, a customer may be directed to a POS system 116 when an error condition cannot be satisfied, a purchase restriction condition cannot be satisfied, or other such situations. As such, the purchase control system 102 and/or the associate computing device 106 can establish a link between the one or more POS purchase sessions and one or more purchase sessions executed through the customer computing device 110. Such POS purchase session linking with one or more customer computing device purchase sessions may be based on one or more factors such as but not limited to the POS purchase session being associated with the particular customer (e.g., through a customer number, customer payment method, and/or other customer identifying information), a time correlation (e.g., the POS purchase session occurred within a threshold time of one or more of the customer device purchase sessions), location correlation (e.g., the POS purchase session occurred at a same retail facility as one or more of the customer device purchase sessions, at locations that are within a threshold distance, etc.), item correlation, other such factors, or a combination of two or more of such factors.
In some implementations, for example, an error condition may be associated with a first purchase session of a transaction, and the customer may be directed to complete the sale through a POS system 116. At the POS system, the customer may present a session optical machine-readable representation displayed on the customer computing device 110 that can be scanned at the POS system enabling the POS system to pull up item information for each of one or more items of the purchase session, and complete a sale of one or more items of the purchase session and establish a POS purchase session that corresponds to the customer device purchase session, and a correlation between the POS purchase session that corresponds to the customer device purchase session. Additionally or alternatively, the associate computing device 106, through the execution of the exit audit APP 108, may identify a purchase session based on scanning of the optical machine-readable representation of the transaction that was aborted or otherwise had an unresolved error condition. Based on that purchase session associated with that customer, the exit audit APP can identify a POS purchase session corresponding to that aborted purchase session or purchase session in an error state, and establish a link between the POS purchase session and the one or more other purchase sessions of the single transaction. The exit audit APP 108 can preform the final authentication, at the single time, of the single transaction comprising one or more customer device purchase sessions and one or more POS purchase sessions.
In some embodiments, the purchase control system 102 can be configured to receive a POS purchase notification from a POS system 116 at a retail facility. The POS purchase notification can include a customer identification exclusively associated with a particular customer and an additional item identification information for each of one or more additional items purchased through the POS system 116 in a POS purchase session. The purchase control system 102 can link, in response to the POS purchase notification and based on the customer identification, the POS purchase session to the single transaction such that the POS purchase session is one of the multiple purchase sessions linked with the single transaction. The linking can, in some instances be based on identifying the single transaction associated with the customer and identify a threshold relationship between the single transaction and the POS purchase session. The exit audit APP 108 can use the single transaction information to confirm scanned items have been purchased in one of the multiple purchase sessions, including the POS purchase session.
In step 310, item identification information can be incorporated into a second virtual cart for each of one or more items identified, through the customer computing device, by the customer and intended to be purchased by the customer in association with the additional purchase session. The second virtual cart can be associated with the additional purchase session, and is different than a first virtual cart associated with the first purchase session. In step 312, it can be identified that the first session includes a first item having a purchase restriction condition. In step 314, the single transaction can be designated as a purchase restricted transaction based on the first session including the first item that is associated with a purchase restriction condition. In step 316, transaction information can be communicated to the customer computing device 110, via the communication network 104. The transaction information can comprise information from both of the first purchase session and the additional purchase session and can control the customer computing device 110 in displaying an optical machine-readable representation corresponding to the single transaction and encoding dynamically generated unique session identifiers of each purchase session linked to the single transaction comprising a first unique session identifier corresponding to the first purchase session and a second unique session identifier corresponding to the additional purchase session. In some embodiments, the communication of the transaction information can comprises communicating a transaction restriction notification causing the customer computing device, when displaying the optical machine-readable representation, to include a displayed designation indicating that the single transaction is a purchase restricted transaction and further display instructions to take a first action to satisfy the purchase restriction condition.
In step 320, multiple scanned unique session identifiers can be identified, via an exit audit APP 108 executed on an associate device control circuit of an associate computing device 106. The session identifiers can be extracted and decoded from the optical machine-readable representation in response to optically scanning, via the associate computing device, the optical machine-readable representation displayed by the customer computing device corresponding to the single transaction. Each of the multiple scanned unique session identifiers can correspond to one of multiple purchase sessions linked to the single transaction. In step 322, a POS purchase session can be identified, from a listing of recent point of sale (POS) purchase sessions, that corresponds to the first purchase session, and the POS purchase session can be merged to link with the single transaction. In some embodiments, the identification of the POS purchase session can be in response to identifying, via the exit audit APP 108 and in response to scanning the optical machine-readable representation of the single transaction displayed on the customer computing device, the first purchase session is in an error state.
In step 324 item identifying information can be received for each of multiple physical items associated with the customer. The item identifying information can, in some embodiments, be captured by the associate computing device 106. In step 326, it can be confirmed, by the exit audit APP 108, that each of the item identifiers is included in at least one of the multiple sessions of the single transaction. When an item is not identified as associated with one of the multiple purchase sessions, some embodiments advance to step 330 where it can be determined whether to create an additional purchase session. When an additional purchase session is to be established, the process 300 can advance to step 332, where a third purchase session automatically establishing corresponding to a third virtual cart automatically implemented and at least a first item identifier of the first item can be incorporated into the third virtual cart. In step 334 the third purchase session is additionally linked to other purchase sessions of the single transaction. Some embodiments alternatively advance to step 336 where an abort notification can be received from the customer computing device 110. The abort notification can correspond to one of the purchase sessions linked to the single transaction, such as a purchase session associated with an error and/or unsatisfied purchase restriction. The identified session can be abort while maintaining as active one or more other purchase sessions linked to the single transaction.
In step 340, it can be identified, via an exit audit APP executed on an associate device control circuit of an associate computing device and in response to scanning the optical machine-readable representation, the first session comprises at a first item having a purchase restriction condition. In step 342, a restriction condition user interface can be caused to be displayed on the associate computing device 106 and/or the customer computing device 110. In some embodiments, the restriction condition user interface can be configured to receive a current condition corresponding to the purchase restriction condition. In step 344, a current condition response can be received based on interaction of an associate through the restriction condition user interface.
In step 346, it can be determined whether the restriction condition is satisfied. When the restriction condition is satisfied, some embodiments advance to step 348 causing a final authentication of the single transaction in authenticating at a single time both the first session and the second session. When the restriction is not satisfied, some embodiments determine in step 350 whether one or more of the purchase sessions and/or the single transaction should be aborted. When a session should be aborted, the process can return to step 336. In step 352, an error condition associated with the first session of the transaction can be determined. In step 354, a point of sale (POS) notification can be communicated to the customer computing device 110 to control the customer computing device to display an error user interface directing the customer to return to a POS system 116 to complete a sale of the one or more items associated with the first session. Some embodiments additionally or alternatively advance to step 356 where authorization of a completion of sales of at least the first item in at least the first session can be prevented in response to confirming, based on the current condition, the purchase restriction condition is unsatisfied.
In step 403, the machine-readable representation can be presented to an exit audit associate. The machine-readable representation can be displayed by the customer computing device 110, presented on a printed receipt, or otherwise presented. In step 404, the audit associate can use an associate computing device 106 to scan the displayed machine-readable representation of the transaction and in some instances obtain checkout session identifiers (ID). In step 405, the exit audit APP 108 can in some embodiments determine whether transaction information has already been received (e.g., cached) at the associate computing device (e.g., if all session IDs are locally saved). This can include, in some instances, checks to determine (e.g., via one or more Websockets) whether one or more QR codes have previously been scanned and determine whether there are any earlier session and/or transaction QR code information in cache. When information is not fully local, the process in some instances can advance to step 406 where transaction information can be acquired. This acquisition may utilize some or all of the information obtained from the scan and decoding of information from the machine-readable representation. The acquisition, in some implementations can be a check over one or more websockets (e.g., GET v3 checkouts by customer) and/or through one or more application program interface (API). The checkout information can include POS session information, mobile purchase session information and/or other relevant purchase session information. In some embodiments, in step 407, the transaction information is received at the associate computing device (e.g., cached in local memory). The process 400 can return to step 405 to confirm transaction information is available. Some embodiments include step 406b where a connection is established with one or more databases storing session and/or checkout information, and step 406c where session information is periodically and/or in response to one or more triggers forwarded to update information on the associate computing device 106 and/or a database readily accessible to the associate computing device (e.g., a websocket checkout event retrieval).
In step 408, the exit audit APP 108 evaluates the information of the transaction and the overall states of the transactions to confirm the extracted session IDs correspond to actual, and the transaction should proceed to the audit (e.g., transaction and/or session QR IDs exit). When one or more session IDs are invalid or other error conditions are detected, the process identifies an audit failure error and exits the audit process in step 409 (e.g., checkout process is in an incorrect state, not actionable, APP error, possible fraudulent activity, etc.). This can include notifying the associate and/or the customer through respective computing devices. When the session IDs are actionable, the process 400 can advance to step 410 to confirm that each session associated with a transaction is ready for the audit process (e.g., sessions are “checkout-finalized” or ready to confirm a purchase restriction condition).
In step 411, determine a state of one or more of the purchase sessions and/or whether there are one or more sessions that have one or more purchase restriction conditions (e.g., age verification, customer identification, etc.). When a restriction condition is applicable (e.g., age verification), the process can advance to step 412 where the process can confirm whether the data is to be received in relation to the restriction condition and/or whether the restriction is dependent on other actions. The process, in step 414, can in some embodiments implement one or more APIs to acquire relevant input information and confirming restriction condition information. In step 415, information can be communicated to the associate computing device and/or the customer computing device to display information about the restriction condition and/or whether one or more products is to be removed based on a failure to satisfy one or more restriction conditions. In step 416, it can be determined whether restriction conditions have been satisfied.
When it is determined in step 411 that the states of the purchase session do not correspond to restriction conditions and/or following the confirmation in step 416 that restriction conditions are satisfied, the process can advance to step 417 where it can be determined by the exit audit APP 108 and/or the purchase control system 102 whether there is one or more POS sessions and/or other purchase sessions (e.g., purchased directly from an associate (e.g., concierge purchase session), and/or other such purchase sessions) that are linked or are to be linked to the single transaction (e.g., based on customer identifying information associated with the POS, a transaction identifier and/or session identifier associated with the POS session and corresponding to the single transaction, timing of the POS session relative to one or more customer device POS sessions, location information, other such factors, or a combination of two or more of such factors). When there are POS sessions, the process advances to step 418 where the one or more POS sessions and/or other purchase sessions are identified, merged and/or linked with one or more of the purchase sessions of the single transaction.
In step 420, the audit of the composite of the multiple purchase sessions of the transaction is performed and it is determined whether the exit audit is approved. When the audit some embodiments advance to step 421 where a post audit API is called. This post audit in some embodiments can include a verification of items. Such confirmation can include, for example, the customer associate scanning a predefined number of randomly selected items and the exit audit APP can confirm those identified items are included in one of the purchase sessions, and/or evaluate for other potential errors (e.g., fraud conditions, payment failure, etc.). In some embodiments, the number of items is independent of the number of sessions of the single transaction, which can avoid introducing additional delays. In other implementations and/or based on other conditions, the number of items to be scanned may vary. The number of items may be conditional on the number of sessions, the number of items, the frequency of purchasing by the customer, pricing of one or more items, pricing of the items of the transaction, other such factors, or a combination of such factors.
In step 422, it can be determined whether the API response confirms the audit is completed (e.g., scanned items are within one of the sessions). When completed, the process 400 can advance to step 423 where notification is designated at the associate computing device 106 and/or customer computing device 110, and the customer can exit the retail facility at step 424. When it is determined in step 420 that the audit is not approved (e.g., detection of potential fraud, failure to obtain payment, etc.), the process in some embodiments advance to step 425 to perform exit handling and notify the customer of the potential error. The one or more sessions can be aborted, and/or some embodiments provide step 426 that allows the customer to go to a POS system and complete purchases.
Some embodiments include step 430 following a detection of one or more error conditions in steps 416 and/or 422, where an error type is identified. Some embodiments include step 431 following a detection of one or more error conditions in steps 416 and/or 422 where the customer is given an option to retry to incorporate products into one or more sessions and/or to take items to a POS system. The customer can be given the opportunity to abandon one or more sessions and/or retry one or more sessions in step 439. With some errors, the process cannot continue, and the process advances to step 432 and terminated. Other errors may indicate further processing of one or more sessions is being performed (e.g., obtaining payment, etc.), and the process enters step 433 to wait a period of time and re-initiate the audit process.
Some errors can identify when one session is successfully audited, while an error occurred in one or more other sessions. In some of these instances, the process can advance to step 435, where the session identifiers are obtained for those that successfully passed audits, and in step 436 the one or more sessions that were not successfully audited because of one or more errors are identified. The customer computing device and/or the associate computing device are notified of unaudited sessions, and the customer is given an opportunity to allow the system to generate a new composite transaction of the remaining sessions, where a new machine-readable representation of the new composite transaction can be used to restart the audit process of the remaining sessions. In some embodiments, when an error is detected the process advances to step 440 to determine one or more sessions that have not completed audit. In step 441, it can be determined whether one or more remaining sessions are abandonable. In step 442, the customer is presented with an option to abandon and/or retry one or more of the sessions. Other embodiments enable the partial auditing of one or more sessions. For example, when an age restriction error is detected, each session of a transaction can be evaluated for the age restriction condition. It can be determined for each that have the age restriction condition whether age restricted items can be removed from the session. When they can be removed, the associate is instructed to remove the item(s) and attempt to reauthorize payment for remaining items of the session. A composite listing of items to be removed can be communicated to the associate computing device and/or the customer computing device. In other instances, it is determined whether a session can be abandoned. When it is abandonable, the session may be abandoned. This process can be repeated for each session of the transaction. When one or more sessions remain that do not include the age restriction condition, the process can return to step 403 or other relevant step (e.g., step 410, 411) to attempt the audit again with the remaining sessions without the age restriction condition because of the removal of age restricted items.
In some instances, a transaction with a single session cannot be retried through the mobile purchasing when certain error conditions occur, such as a detection of a potential fraud error. As such, the customer can elect to return to a POS system or leave the items and cancel any potential purchase. Other embodiments, when one or more other sessions are linked, the process may allow one session to be abandoned while allow customer to complete the audit on one or more other sessions.
In other instances, in step 505, it can be determined whether an audit has been confirmed. In some instances, for example, the audit can be conducted by the display of the machine-readable representation of the session on the customer computing device 110, the scanning by the associate computing device 106, and the confirmation of one or more items in accordance with identified one or more sessions. When the audit is confirmed, the customer can leave the retail facility at step 507. As described above, in some instances the audit can include the confirmation and/or attempted satisfaction 508 of one or more purchase restriction conditions (e.g., age confirmation). Additionally or alternatively, the audit can identify one or more items that were not included in a purchase session. In step 510, item identification for the one or more items not included in a purchase session can be obtained (e.g., scanning by an associate computing device 106 and/or customer computing device 110). Some embodiments include step 511 where an additional purchase session can automatically be created, and the one or more items not in a purchase session can be added to the additional purchase session. Some embodiments additionally or alternatively automatically generate an additional virtual cart and incorporate the identified items into the additional virtual cart.
In step 506, an additional purchase session is initiated and linked as a single transaction with the one or more previous pending sessions corresponding to the customer. In some implementations, the cart compile APP 112 can save a multi-session transaction state. In step 512 it can be determined whether one or more additional items are identified (e.g., scanned, selected from a listing, etc.) or of another action is performed, such as user selecting a “Back” option or a “cancel session” option. The cancelling of the session can, in some embodiments, cause the process to return to step 505 to proceed with an exit audit. Alternatively, the process can continue to receive one or more item identifying information for one or more items to be added to the additional session, and continue to update the transaction state information. The cart compile APP 112 in some implementations can display a cart user interface listing the one or more items in the current virtual cart and/or other relevant information (e.g., pricing, quantities selected, etc.). In step 514, it can be determined whether the customer intends to add additional items, causing the process to return to continue to incorporate one or more additional items (e.g., scan of another item), cancels the current session, which can cause the process to return to step 505, whether the customer initiates a check-out process, and/or other such action.
In response to a check-out option selection, the process 500 can advance to step 515 (
The checkout process for the session can be initiated, and in some embodiments, the process 500 includes decision step 516, where payment method information can be selected and/or added (e.g., step 517), identify a selection of an option to return to view the cart and/or add additional items (e.g., step 514), whether to active payment, and/or other such actions. For example, when the customer activates a payment option (e.g., virtually slides a displayed payment option), the process can advance to step 518 that can trigger the purchase control system 102 to initiate calls to determine whether payment can be completed, whether payment has been declined, whether there is a potential fraud condition, whether there is other errors and/or logic errors (e.g., causing the process to advance to decision step 540), and/or other such actions. For example, when there is a payment decline, the process may return to step 516 to cause the cart compile APP to display an error and/or information about the decline. This may also provide the customer to initiate an alternative method of payment. Similarly, when fraud activity is detected, some embodiments advance to step 519 where a payment decision is implemented.
In some embodiments, a payment flagged can be a customer choice (e.g., presented through a user interface on the customer computing device) after the purchase control system indicate a potential fraud activity. This can provide the customer with options, such as cancel the checkout (remove items from cart), implement a POS session to complete purchase it at a POS system, and/or other such options. In some instances, in response to a potential fraud indication, subsequent sessions may be prevented until resolved (e.g., purchase through a POS system), which can notify the purchase control system to enable additional sessions when a session limit has not been reached.
This can enable the customer to remove 520 one or more items from a cart, request a transfer in step 521 to a POS system (e.g., causing the process to advance to step 505, which may result in a multi-session state being adjusted and/or cleared), and/or other such actions. The POS transfer can be completed and the transaction reverted to a previous transaction state and/or previous linked session, which can then allow the customer to take other actions and/or advance to the exit audit.
When a payment method is successful the multi-session transaction state can be updated and the process can advance to step 523 where the cart compile APP and/or the purchase control system can determine whether a purchase session limit has been reached, and the cart compile APP can cause the display of a purchase confirmation user interface. When a session limit has been reached, the purchase confirmation user interface does not include an option to initiate further purchases and/or another session. In some embodiments, the purchase confirmation user interface further displays one or more machine-readable representations (e.g., machine-readable representation of the transaction), which can encode a transaction identifier, one or more purchase session identifiers, other relevant information (e.g., latest session ID, total item count, total amount, timing, user identifier information, retail facility information, other such information, etc.), or a combination of two or more of such information. In step 524, an exit audit can be performed. Again, in some implementations, the associate computing device can scan the displayed machine-readable representation(s) and preform an audit process, such as one of the audit processes described above and further below. The audit can include the confirmation and/or attempted satisfaction of one or more purchase restriction conditions (e.g., step 525). When the audit is completed and successful, the process 500 can authorize the transaction in step 526, typically with the customer exiting the facility.
In some embodiments, when the audit fails the process 500 can initiate another purchase session when a session limit has not been reached, such as returning to step 506. Similarly, the failure of the audit, such as because of a failure to satisfy a purchase restriction condition (e.g., age) can cause the process to advance to step 527 where the cart compile APP 112 and/or the exit audit APP 108 can display instructions to remove one or more items corresponding to the failed purchase restrictions (e.g., remove one or more alcoholic beverage items) from the customer. Some embodiments include step 528 where after removal of the failed purchase restricted items, the payment may be reauthorized (e.g., removal of items would reduce the total cost, and reauthorization for the reduced cost). When payment is successful, the process can return to the audit step 524. In some embodiments, when fraud activity is detected the process 500 may advance to step 519. In other instances, when payment is declined, some embodiments, can optionally initiate an additional purchase session and/or additional virtual cart in step 530, which may include the automatic population of the additional virtual cart. Following the initiation of the additional virtual cart, the process 500 in some implementations can return to step 511.
As described above, in some error events in step 518 can cause the process to shift to decision step 540 where the error can be evaluated (e.g., invalid checkout state, unrecognized session identifier, unrecognized transaction identifier, etc.) and/or a state of one or more sessions can be evaluated. Based on the error, some embodiments identify in step 541 when a state of a purchase session is not resumable, and return to step 514 enabling the customer to populate the virtual cart with one or more items that were not finalized due to the earlier error condition. Additionally or alternatively, one or more sessions can be identified in step 542 as resumable (e.g., information is still available and valid), and the process may return to an audit step (e.g., step 505 and/or 524).
The multiple sessions enable customers that have already checked out of a session, and remember an item they forgot to purchase, to initiate an additional session to purchase one or more items, assuming a session limit has not been reached. Additionally or alternatively, some embodiments enable customers to utilize multi-session transactions to purchase items using two or more different methods of payment (e.g., a customer wants to use both EBT Food and cash to pay for items, but only 1 EBT payment method is allowed per transaction; a business customer wants to split their personal and business items; etc.). The establishment of different sessions can, in some implementations, allow the customer to specify a different payment methods for different sessions. Multiple sessions can allow the use of the mobile cart compile APP to seamlessly tie multiple sessions together into a unified transaction checkout experience that enables exit associates to review the combined sessions at the same time instead of independently, resulting in no additional friction to the audit experience.
The backend purchase control system 102, in some embodiments, implements one or more APIs that that link multiple purchase sessions for a given customer together. The sessions can be dependent on one or more factors, such as customer, retail facility, location, time, date, other such information or a combination of such information. A data structures can be created to send data to the cart compile APP 112 and/or exit audit APP 108 for processing. In some implementations, each session of a transaction can be independent, while being linked and enabling one or more of the sessions to be associated with one or more purchase restrictions. When a session contains a restriction condition item (e.g., an age restricted item) then the transaction can be designated a purchase restricted session for subsequent verification that the condition is satisfied (e.g., marked as age verification). Similarly, the exit audit APP 108 can implement APIs in implementing audits and restriction condition evaluations in verifying the sessions and transaction. The QR code or other encoded code used by the exit audit APP can include linked data and other relevant information to effectively obtain session information and/or authenticate. This transaction QR code utilized in combination with the associate APIs allows the exit audit APP 108 to scan a single QR code to pull up information for the sessions of a transaction.
The cart compile APP 112 further includes an additional option to initiate an additional session to be linked with one or more other sessions as a single transaction. Similarly, a confirmation of purchase user interface can include a notification that the transaction is a multi-session transaction, one or more option to view identifiers of the multiple sessions, one or more options to view item lists from one or more of the sessions and/or other such options. In some embodiments, the exit audit APP 108 similarly provides an option to initiate on behalf of the customer one or more additional sessions to be linked as a single transaction. This option and the flow can be controlled in part, in some implementations, by feature flags and session limits. With multiple sessions, some embodiments enable multiple different types of virtual carts a customer can establish. For example, one type would be a cart with no restricted items. Another cart may be a mixed type of cart with normal and restricted items. A further cart may be considered a restricted with only restricted items. Each session is executed independent of other sessions, while still being linked as a single transaction. Therefore, customers can have different types of carts and/or items for each transaction. Additionally or alternatively, customers can use different payment methods for different sessions. This allows customers to separate purchases (e.g., business vs. personal), make purchases using different payments (e.g., EBT Food and Cash), and other such advantages.
The linking of sessions simplifies the audit process and, in some instances, avoids introducing added delays or added complexity. The single transaction QR code enables access to information for each of the multiple sessions. Also, receipt details can be accessed to show the sessions and details of the transaction. Further, the audit can enable the exit associate to scan one or more products that can be identified as being included in any one of the sessions, and thus avoids the complexity of identifying products for particular sessions. Fraud protection is further enhanced based on the fraud evaluation across the multiple sessions, while decreasing unintentional fraud rejections for subsequent session in part based on a lack of fraud in a first session. During the audit process when an item is detected that is not included in one of the sessions, the exit associate can watch the customer implement an additional session and pay for that session to incorporate the identified item, and/or automatically initiate an additional session linked to the transaction and scan one or more items to be added to an additional virtual cart for which the customer can authorize payment.
Further, the circuits, circuitry, systems, devices, processes, methods, techniques, functionality, services, servers, sources and the like described herein may be utilized, implemented and/or run on many different types of devices and/or systems.
By way of example, the system 600 may comprise one or more control circuits or processor modules 612, one or more memory 614, and one or more communication links, paths, buses or the like 618. Some embodiments may include one or more user interfaces 616, and/or one or more internal and/or external power sources or supplies 640. The control circuit 612 can be implemented through one or more processors, microprocessors, central processing unit, logic, local digital storage, firmware, software, and/or other control hardware and/or software, and may be used to execute or assist in executing the steps of the processes, methods, functionality and techniques described herein, and control various communications, decisions, programs, content, listings, services, interfaces, logging, reporting, etc. Further, in some embodiments, the control circuit 612 can be part of control circuitry and/or a control system 610, which may be implemented through one or more processors with access to one or more memory 614 that can store instructions, code and the like that is implemented by the control circuit and/or processors to implement intended functionality. In some applications, the control circuit and/or memory may be distributed over a communications network (e.g., LAN, WAN, Internet) providing distributed and/or redundant processing and functionality. Again, the system 600 may be used to implement one or more of the above or below, or parts of, components, circuits, systems, processes and the like.
The user interface 616 can allow a user to interact with the system 600 and receive information through the system. In some instances, the user interface 616 includes a display 622 and/or one or more user inputs 624, such as buttons, touch screen, track ball, keyboard, mouse, etc., which can be part of or wired or wirelessly coupled with the system 600. Typically, the system 600 further includes one or more communication interfaces, ports, transceivers 620 and the like allowing the system 600 to communicate over a communication bus, a distributed computer and/or communication network 104 (e.g., a local area network (LAN), the Internet, wide area network (WAN), etc.), communication link 618, other networks or communication channels with other devices and/or other such communications or combination of two or more of such communication methods. Further the transceiver 620 can be configured for wired, wireless, optical, fiber optical cable, satellite, or other such communication configurations or combinations of two or more of such communications. Some embodiments include one or more input/output (I/O) ports 634 that allow one or more devices to couple with the system 600. The I/O ports can be substantially any relevant port or combinations of ports, such as but not limited to USB, Ethernet, or other such ports. The I/O interface 634 can be configured to allow wired and/or wireless communication coupling to external components. For example, the I/O interface can provide wired communication and/or wireless communication (e.g., Wi-Fi, Bluetooth, cellular, RF, and/or other such wireless communication), and in some instances may include any known wired and/or wireless interfacing device, circuit and/or connecting device, such as but not limited to one or more transmitters, receivers, transceivers, or combination of two or more of such devices.
In some embodiments, the system may include one or more sensors 626 to provide information to the system and/or sensor information that is communicated to another component, such as the central control system, a delivery vehicle, etc. The sensors can include substantially any relevant sensor, such as optical-based scanning sensors to sense and read optical patterns (e.g., bar codes, QR codes, etc.), imaging systems, distance measurement sensors (e.g., optical units, sound/ultrasound units, etc.), radio frequency identification (RFID) tag reader sensors capable of reading RFID tags in proximity to the sensor, and other such sensors. The foregoing examples are intended to be illustrative and are not intended to convey an exhaustive listing of all possible sensors. Instead, it will be understood that these teachings will accommodate sensing any of a wide variety of circumstances in a given application setting.
The system 600 comprises an example of a control and/or processor-based system with the control circuit 612. Again, the control circuit 612 can be implemented through one or more processors, controllers, central processing units, logic, software and the like. Further, in some implementations the control circuit 612 may provide multiprocessor functionality.
The memory 614, which can be accessed by the control circuit 612, typically includes one or more processor-readable and/or computer-readable media accessed by at least the control circuit 612, and can include volatile and/or nonvolatile media, such as RAM, ROM, EEPROM, flash memory and/or other memory technology. Further, the memory 614 is shown as internal to the control system 610; however, the memory 614 can be internal, external or a combination of internal and external memory. Similarly, some or all of the memory 614 can be internal, external or a combination of internal and external memory of the control circuit 612. The external memory can be substantially any relevant memory such as, but not limited to, solid-state storage devices or drives, hard drive, one or more of universal serial bus (USB) stick or drive, flash memory secure digital (SD) card, other memory cards, and other such memory or combinations of two or more of such memory, and some or all of the memory may be distributed at multiple locations over the computer network 104. The memory 614 can store code, software, executables, scripts, data, content, lists, programming, programs, log or history data, user information, customer information, product information, and the like. While
In some embodiments, systems and corresponding methods performed by the systems to control a mobile device in purchasing items, comprise: a product database; a transaction database; a mobile purchase control circuit communicatively coupled over a distributed communication network with the product database, the transaction database, wherein the purchase control circuit is configured to: receive a session notification from a mobile customer computing device, associated with a customer and executing a cart compile application, to initiate an additional purchase session in response to an activation by the customer of an additional purchase option provided on a confirmation user interface displayed, in association with a first purchase session, on the customer computing device; establish, in response to the session notification, a second purchase session, and link the first purchase session and the second purchase session as a single transaction; incorporate into a second virtual cart, associated with the second purchase session and different than a first virtual cart associated with the first purchase session, item identification information for each of one or more items identified, through the customer computing device, by the customer and intended to be purchased by the customer in association with the second purchase session; and cause a final authentication of the single transaction in authenticating at a single time of both the first session and the second session.
Some embodiments provide methods of controlling a mobile device in purchasing items, comprising: receiving, at a mobile purchase control circuit and from over a distributed communication network, a session notification from a mobile customer computing device, associated with a customer and executing a cart compile application, to initiate an additional purchase session in response to an activation by the customer of an additional purchase option provided on a confirmation user interface displayed, in association with a first purchase session, on the customer computing device; establishing a second purchase session, in response to the session notification; linking the first purchase session and the second purchase session as a single transaction; incorporating into a second virtual cart, associated with the second purchase session and different than a first virtual cart associated with the first purchase session, item identification information for each of one or more items identified, through the customer computing device, by the customer and intended to be purchased by the customer in association with the second purchase session; and causing a final authentication of the single transaction in authenticating at a single time both the first session and the second session.
Those skilled in the art will recognize that a wide variety of other modifications, alterations, and combinations can also be made with respect to the above-described embodiments without departing from the scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.
