Mobile cart reconciliation

Disclosed herein is a method where a consumer employs a device associated with the user to scans tags associated with items for purchase. The consumer can pay for the items using the device associated with the user. A point of sale (“POS”) terminal or other such device associated with the merchant scans tags associated with items associated with the user and reconciles the items scanned by the device associated with the user with the items scanned by the device associated with the merchant.

TECHNICAL FIELD

The present disclosure relates generally to point of sale systems and methods.

BACKGROUND

Typical point of sale systems, such as are frequently employed by retailers, require a customer to wait in line for an available clerk. The clerk empties the contents of their cart and each item purchased is scanned one at a time (or once per type of item) at a checkout (point of sale or “POS”) terminal. There are several problems with this process. Waiting for an available clerk can cause a bottleneck, especially if staffing levels are insufficient. The process of scanning individual items is time consuming. In addition, the consumer may not be aware of the total price of items in their cart and may not have sufficient funds to pay for them causing embarrassment to the consumer.

SUMMARY

In accordance with an example embodiment, there is disclosed herein a method where a consumer employs a device associated with the user to scans tags associated with items for purchase. The consumer can pay for the items using the device associated with the user. A point of sale (“POS”) terminal or other such device associated with the merchant scans tags associated with items associated with the user and reconciles the items scanned by the device associated with the user with the items scanned by the device associated with the merchant. Further embodiments include methods, apparatus, and computer readable mediums of instructions with instructions for implementing the methodologies described herein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

This description provides examples not intended to limit the scope of the appended claims. The figures generally indicate the features of the examples, where it is understood and appreciated that like reference numerals are used to refer to like elements. Reference in the specification to “one embodiment” or “an embodiment” or “an example embodiment” means that a particular feature, structure, or characteristic described is included in at least one embodiment described herein and does not imply that the feature, structure, or characteristic is present in all embodiments described herein.

FIG. 1is a block diagram of a system100for purchasing an item102that employs a “mobile cart” and a reconciliation of the mobile cart with a “physical cart.” The customer (not shown) employs a customer device104to scan a tag106associated with the item102for purchase. The customer may employ the customer device104to pay for the item. The customer then proceeds to checkout. A merchant device108associated with the merchant scans the tag106associated with the item102. Merchant device logic110in the merchant device108communicates with customer device logic112in the customer device104to reconcile the item scanned by the consumer device104with the item scanned by the merchant device108. If the item102scanned by the customer device104matches the item102scanned by the merchant device108, then the merchant device108accepts payment from customer device104.

The items scanned by the customer device104may be referred to herein as the mobile cart. The items scanned by the merchant device108may be referred to herein as the physical cart. In an example embodiment, the customer device104is a mobile device associated with the customer. For example, the customer device104may be a smartphone.

In an example embodiment, the customer device104comprises customer device logic112, a scanner118, and a wireless transceiver120. The customer device logic112is operable to control the operation of the device and implement the functionality described herein. “Logic”, as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or need, logic may include a software controlled microprocessor, discrete logic such as an application specific integrated circuit (ASIC), a programmable/programmed logic device, memory device containing instructions, or the like, or combinational logic embodied in hardware. Logic may also be fully embodied as software that performs the desired functionality when executed by a processor.

The scanner118is operable to scan the tag106of item102. In an example embodiment, the scanner118is an optical scanner. For example, scanner118may be operable to scan a bar code, or a quick response (QR) code, a Universal Product Code (UPC), or any combination of two or more of a bar code, QR code, and UPC code. In another example embodiment, the scanner118is operable to scan an infra-red (IR) tag. In still another example embodiment, the scanner118is a wireless scanner, such as a Radio Frequency Identification (RFID) scanner. For example, the scanner118is operable to employ a contactless protocol such as near field communication (NFC), a personal area network protocol such as BLUETOOTH, wireless local area network protocol such as WI-FI, or a combination of two or more wireless protocols such as NFC, BLUETOOTH, and WIFI. In particular embodiments, the scanner118is operable to scan a combination of two or more of optical, IR, and RFID tags.

The wireless transceiver120may employ a wireless protocol such as WI-FI or cellular data for communicating with the merchant device108. As will be described in more detail herein, the wireless transceiver120can be employed by customer device logic112to obtain pricing information for item102, provide data representative of scanned items, and/or provide payment information.

The item102may be any item that the merchant is offering for sale. The tag104may comprise any suitable tag that scan be scanned, including but not limited to, active, passive, semi-passive RFID, NFC, infra-red tag, optical (e.g., UPC). In an example embodiment, the tag may comprise two or more types of tags (e.g., a UPC tag and a BLUETOOTH tag) which may be joined together in one tag or be implemented in two separate tags.

In an example embodiment, each item102has a tag106that is unique to that item. In another example embodiment, like items may have like tags (e.g., 12 ounce boxes of Lucky Charms may have tags that provide the same data that is different from tags on 24 ounce boxes of Lucky Charms or any other type of cereal).

In an example embodiment, the merchant device108is located in a checkout area116of the merchant's establishment. The merchant device108comprises merchant device (or point of sale “POS”) logic110for providing the functionality described herein, a wireless transceiver122for communicating with the customer device104, and a scanner114. The wireless transceiver may employ any suitable protocol such as WIFI. The scanner114may employ any suitable protocol for scanning item102. For example, the scanner may suitably comprise any one or more of the optical, IR, and wireless scanners described herein.

Although not shown, those skilled in the art car readily appreciate the merchant device108may be coupled with devices to indicate to the customer whether a transaction was approved or not approved. For example, the merchant device may be coupled with a gate that opens when the transaction is approved. As another example, the merchant device108may be coupled with one or more lights to indicate whether a transaction was approved (e.g., yellow means in progress, green means approved, and red means not approved or a problem has been encountered).

In an example embodiment, when a customer desires to purchase an item102, the customer employs scanner118to scan the tag106associated with item102and obtain data representative of the item102. Customer device logic112determines a price for the item102based on the data representative of the item obtained from tag106. In an example embodiment, the price may be included with the data representative of the item obtained by scanner118from tag106. In another example embodiment, the customer device logic112employs wireless transceiver120to communicate with the merchant device108to obtain a price for the item. In an example embodiment, when the customer is done shopping, customer device logic112sends payment information via wireless transceiver120to merchant device108. As the customer enters checkout area116, the scanner114associated merchant (or point of sale) device108scans tag106of item102. The merchant device108also obtains data representative of item102and payment information from the customer device104via wireless interface122.

The merchant device logic110verifies (reconciles) the data representative of the item102scanned by the (e.g., mobile) customer device104associated with the customer (the mobile cart) matches the data representative of the item102scanned by the (e.g., point of sale) merchant device108associated with the merchant (the physical cart). If the mobile cart does not match the physical cart, the merchant device logic110may cause corrective actions to be taken. For example, the merchant device108may comprise a display which can show a comparison of the mobile cart and physical cart to facilitate reconciliation. As another example, the merchant device logic110may provide the data representative of the physical cart to the customer device104to enable the customer to employ the customer device104to reconcile the mobile cart and physical cart. In particular embodiments, the merchant device logic110may notify a merchant employee of the problem.

Upon successfully reconciling the mobile cart with the physical cart, the (point of sale) merchant device108accepts payment from the (mobile) customer device104associated with the customer. In an example embodiment, the customer device104may obtain payment information prior to the customer approaching the checkout area116and/or the merchant device108scanning the tag106of item102. As those skilled in the art can readily appreciate, obtaining payment information prior to the customer approaching the checkout area116and/or prior to the merchant device108scanning the tag of item102can help minimize the amount of time the customer has to remain in the checkout area116. In particular embodiments, the customer device104may obtain the payment after the mobile cart and physical cart have been reconciled.

In an example embodiment, the customer device logic112may obtain data representative of coupons in the customer's possession via customer device scanner118. Coupon information may be presented to the merchant device108as part of the payment for the item102.

FIG. 2is a block diagram illustrating an example of a system200for purchasing a plurality of items102A,102B. In this example, the customer has placed the items into a cart202. However, those skilled in the art should readily appreciate that the principles described herein are applicable to situations where the customer does not use a cart202(e.g., the customer carries the items to checkout area116).

As inFIG. 1, the customer scans tags106A,106B associated with items102A and102B respectively with customer device scanner118associated with customer device104. Although in the present example the customer device104is shown and described as being separate from cart202, those skilled in the art can readily appreciate that in some embodiments the customer device104can be embodied into cart202.

In an example embodiment, pricing information may be embodied in tag106A and/or106B. In an example embodiment, where pricing information is not embodied on tag106A and/or106B, the customer device logic112can cause wireless transceiver120to communicate (e.g., send data representative of the item obtained from the tag) with the wireless transceiver122associated with the merchant device108or another device associated with the merchant to obtain the price of item102A and/or102B as illustrated by204. The merchant device (or other device associated with the merchant) responds with the pricing information as illustrated by206. In an example embodiment where pricing information is included on the tag106A and/or106B, the customer device logic112may communicate with merchant device108to verify pricing information. For example, the customer may entitled to a discount (e.g., for being a member of a loyalty program) which may not be present on tags106A and/or106B. By communicating with merchant device108, the customer device logic112may obtain data about discounts. In an example embodiment, the merchant device108determines whether the customer is entitled to discounts and sends data representative of any available discounts to customer device104.

Upon the customer indicating they have completed making their purchase, the customer device104obtains payment information from the customer (which as described herein supra may include coupon data). Similar to the example inFIG. 1, payment information may be provided by the customer at any time (e.g., before, during, or after) the customer approaches the checkout area116and/or the cart (physical cart)202is scanned by scanner114.

The merchant device logic110verifies (reconciles) the data representative of the item scanned by the (e.g., mobile) customer device104associated with the customer (the mobile cart) matches the data representative of the items102A,102B scanned by the (e.g., point of sale) merchant device108associated with the merchant (the physical cart). If the mobile cart does not match the physical cart, the merchant device logic110may cause corrective actions to be taken. For example, the merchant device108may comprise a display which can show a comparison of the mobile cart and physical cart to facilitate reconciliation. As another example, the merchant device logic110may provide the data representative of the physical cart to the customer device104to enable the customer to employ the customer device104to reconcile the mobile cart and physical cart. In particular embodiments, the merchant device logic110may notify a merchant employee of the problem.

Upon successfully reconciling the mobile cart with the physical cart, the (point of sale) merchant device108accepts payment from the (mobile) customer device104associated with the customer as indicated by208. As those skilled in the art can readily appreciate, the payment process may entail the exchange of one or more messages between the customer device104and the merchant device108. For example the customer device may send payment information to the merchant device108and the merchant device may send a signal to the customer device102indicating whether the payment was accepted. In an example embodiment, the customer device104may obtain payment information prior to the customer approaching the checkout area and/or the merchant device108scanning the tags106A,106B associated with items102A,102B respectively, however, in particular embodiments, the customer device104may obtain the payment after the mobile cart and physical cart have been reconciled.

In an example embodiment, the customer device logic112may obtain data representative of coupons in the customer's possession via customer device scanner118. Coupon information may be presented to the merchant device108as part of the payment for the item102.

Although the examples just presented illustrates two items being purchased, those skilled in the art should readily appreciate that the number of items chosen for this example were chosen for ease of illustration and that the principles described herein may be applied to any physically realizable number of items. Thus, the example embodiments described herein should not be construed as limited to the number of items provided in the examples described herein.

FIG. 3is a block diagram illustrating an example of a system300for purchasing a plurality of items, where more than of a particular item is purchased. In the illustrated example, more than one of item102A, designated as102A1and102A2are purchased. In this example, the customer has placed the items102A1,102A2, and102B into a cart202. However, those skilled in the art should readily appreciate that the principles described herein are applicable to situations where the customer does not use a cart202(e.g., the customer carries the items to checkout area116).

In an example embodiment, tags106A1,106A2for like items (e.g.,102A1and102A2) are the same. Thus, the tags106A1,106A2provide the same data when scanned.

In an example embodiment, each tag106A1,106A2, and1068has a unique code. For example, even though tags106A1and106A2are on a like item (e.g., a hammer), the data on each tag is different.

As inFIGS. 1 and 2, the customer scans tags106A1,106A2, and106B associated with items102A1,102A2, and1026respectively with customer device104. Although in the present example the customer device104is shown and described as being separate from cart202, those skilled in the art can readily appreciate that in some embodiments the customer device104can be embodied into cart202.

In an example embodiment, pricing information may be embodied in tags102A1,102A2, and/or1028. In an example embodiment, where pricing information is not embodied on tags102A1,102A2, and/or1028, the customer device logic112can cause wireless transceiver120to communicate (e.g., send data representative of the item obtained from the tag) with the wireless transceiver122associated with the merchant device108or another device associated with the merchant to obtain the price of item102A1,102A2, and/or1028as illustrated by204. The merchant device (or other device associated with the merchant) responds with the pricing information as illustrated by206. In an example embodiment where pricing information is included on the tags1106A1,106A2, and/or106B of items102A1,102A2, and/or102B respectively, the customer device logic112may communicate with merchant device108to verify pricing information. For example, the customer may entitled to a discount (e.g., for being a member of a loyalty program) which may not be present on tags102A1,102A2, and/or102B. By communicating with merchant device108, the customer device logic112may obtain data about discounts.

Upon the customer indicating they have completed making their purchase, the customer device104obtains payment information from the customer (which as described herein supra may include coupon data). Similar to the examples inFIGS. 1 and 2, payment information may be provided by the customer at any time (e.g., before, during, or after) the customer approaches the checkout area116and/or the cart (physical cart)202is scanned by scanner114.

The merchant device logic110verifies (reconciles) the data representative of the item scanned by the (e.g., mobile) customer device104associated with the customer (the mobile cart) matches the data representative of the items102A1,102A2, and102B scanned by the (e.g., point of sale) merchant device108associated with the merchant (the physical cart). If the mobile cart does not match the physical cart, the merchant device logic110may cause corrective actions to be taken. For example, the merchant device108may comprise a display which can show a comparison of the mobile cart and physical cart to facilitate reconciliation. As another example, the merchant device logic110may provide the data representative of the physical cart to the customer device104to enable the customer to employ the customer device104to reconcile the mobile cart and physical cart. In particular embodiments, the merchant device logic110may notify a merchant employee of the problem.

Upon successfully reconciling the mobile cart with the physical cart, the (point of sale) merchant device108accepts payment from the (mobile) customer device104associated with the customer. In an example embodiment, the customer device104may obtain payment information prior to the customer approaching the checkout area and/or the merchant device108scanning the tag106associated with item102, however, in particular embodiments, the customer device104may obtain the payment after the mobile cart and physical cart have been reconciled.

In an example embodiment, the customer device logic112may obtain data representative of coupons in the customer's possession via customer device scanner118. Coupon information may be presented to the merchant device108as part of the payment for the item102.

Although the examples just presented illustrates two items being purchased, those skilled in the art should readily appreciate that the number of items chosen for this example were chosen for ease of illustration and that the principles described herein may be applied to any physically realizable number of items. Thus, the example embodiments described herein should not be construed as limited to the number of items provided in the examples described herein.

FIG. 4is a block diagram illustrating a more detailed example of a system400that provides for mobile cart reconciliation. In this example, a plurality of merchant devices108A and108B are coupled with a network402. A wireless access point (AP)404is coupled to network404that enables the access point404and the merchant devices108A,108B to communicate with additional merchant systems406. Some examples of additional merchant systems include, but are not limited to, databases410that contain product pricing information sorted by tag identification, customer loyalty program data412, logic414for verifying coupons, payment processing logic416, and any other databases and logic that may be employed by the merchant. In an example embodiment, one or more financial networks408are coupled with network402that enables payment processing logic416to contact customer financial institutions (e.g., banks, credit card companies, etc.) to verify payment and debit the customer's account.

In an example embodiment, one or more wireless access points404are distributed in the merchant's establishment allowing customer device104to communicate with the merchant. As illustrated inFIG. 4, this can allow the customer device104to obtain price information for an item based on tag data. However, those skilled in the art can readily appreciate that the one or more APs404may provide many other functions. For example, the merchant can send data representative of specials or discounts to the customer device104.

In an example embodiment, the customer may choose either merchant device108A or merchant device108B for checkout. The customer merely approaches the checkout area116A or116associated with the desired checkout108A or108B respectively. As described herein, the scanner associated with the selected checkout area scans the items102A,102B in cart202(the physical cart) and obtains data representative of the items scanned by customer device104(the mobile cart) and if the physical cart and mobile cart match (reconciled), the selected merchant device obtains payment information from the customer device104. The payment is processed by payment processing logic416which can communicate with the financial network408to obtain payment from the customer's account.

FIG. 5is a block diagram illustrating an example of a merchant device108. In an example embodiment, the merchant device108comprises merchant device logic110, a scanner114, wireless transceiver122, a payment module502, and a user interface504.

As described herein, the scanner114may suitably comprise an optical and/or RFID scanner. In an example embodiment, the scanner114is operable to scan UPC codes, barcodes, and/or 2-Dimensional barcodes (e.g., QR codes) on tags. In another example the embodiment, the scanner114is operable to scan IR tags. In yet another example embodiment, the scanner114is operable to scan RFID tags employing any suitable technology, including but not limited to, wireless local area network (“WLAN”), such as WIFI, personal area network (“PAN”), such as BLUETOOTH, and/or a contactless protocol such as NFC. In particular embodiments, the scanner114is operable to scan a combination or optical and/or wireless technologies.

In an example embodiment, the wireless transceiver122is operable to communicate with customer devices, such as customer device108. The wireless transceiver may use any suitable wireless technology, such as for example WIFI or BLUETOOTH.

In an example embodiment, the payment module502is operable to obtain payment information for items (or goods) scanned by scanner114. The payment data may be obtained via wireless transceiver122. In an example embodiment, the payment module502is coupled via network402(FIG. 4) to merchant payment logic406and/or financial networks408to process a payment.

In an example embodiment, the user interface504is employed to communicate information to the customer. For example, when a payment has been accepted, the payment module502may cause a message to be output (displayed and/or audio) indicating the transaction has completed and the customer may exit the checkout area. In another example embodiment, if the mobile cart and physical cart do not match, the user interface504can be employed to assist in reconciliation. For example, the user interface may employ a display to output goods scanned by scan114. In particular embodiments, the display of user interface504displays both goods scanned by the scanner114and the items that the customer device has indicated were scanned. In an example embodiment, the user interface504comprises a keyboard, display, and/or a touch screen enable a customer to request assistance.

In an example embodiment, the user interface further comprises a payment input, such as a card reader, cash acceptor or recycler, check acceptor, or a combination of inputs that can allow the customer to pay for the items and/or pay for additional items (for example additional items determined during reconciliation that were not previously paid for), and/or request the scanner114to re-scan the physical cart (for example after removing or adding items to the cart).

In an example embodiment, the merchant device logic110obtains data representative of items from tags scanned the (merchant or point of sale or “POS”) scanner114. The merchant device logic110receives a request to pay for the items scanned by the scanner114. The request comprises data representative of a payment amount. The merchant device determines an amount owed from the data representative of items scanned by the scanner114. The merchant device logic110compares the amount owed with the payment amount. The merchant device logic110accepts the request to pay for the items scanned by the scanner114responsive to determining the amount owed matches the payment amount. In an example embodiment, the merchant device logic110causes the payment module502to process the payment responsive to determining the amount owed matches the payment amount.

In an example embodiment, the merchant device logic110rejects a first request to pay for the items scanned by the scanner114responsive to the comparing of the items the scanned114(the amount owed) does not match the payment amount. This can occur where the customer may have inadvertently (or maybe intentionally) does not scan an item that is being checked out (e.g., carried by the customer and/or in a cart).

If the amount owed does not match the payment amount, the customer may determine whether an item that was scanned by scanner114was not scanned by their customer (e.g., mobile) device. If the customer determines that there was an item that was not scanned by the customer device, the customer may then scan the item with the customer device and adjust the payment accordingly.

Alternatively, the customer may remove an item from their cart (or was being carried by the customer, or even an item that may have been left in the checkout area by a previous customer). The customer may then either using the customer device request a re-scan of the items (which may be requested by the customer via the customer device which would be received by wireless transceiver122or via the user interface504) that will cause the scanner114to re-scan the items. The amount owed is updated based on the re-scan of the items. If the payment equals the updated amount owed, merchant device logic110will cause the payment module502to process the payment.

FIG. 6is a block diagram illustrating an example of a customer device104. In an example embodiment, the customer device104comprises customer device logic112, a scanner118, a wireless transceiver120, and a user interface602.

As described herein, the scanner118may suitably comprise an optical and/or RFID scanner. In an example embodiment, the scanner118is operable to scan UPC codes, barcodes, and/or 2-Dimensional barcodes (e.g., QR codes) on tags. In another example the embodiment, the scanner118is operable to scan IR tags. In yet another example embodiment, the scanner118is operable to scan RFID tags employing any suitable technology, including but not limited to, wireless local area network (“WLAN”), such as WIFI, personal area network (“PAN”), such as BLUETOOTH, and/or a contactless protocol such as NFC. In particular embodiments, the scanner118is operable to scan a combination or optical and/or wireless technologies.

The customer device logic112obtains tag data from scanner118. The customer device logic112maintains a list of items associated with the scanned tags. The item data may be obtained from the tag, or the customer device logic112may employ wireless transceiver120to obtain data representative of items scanned by scanner118.

In an example embodiment, the customer employs the user interface602to provide payment information. Payment information may be preset (e.g., saved credit card or bank account information) and/or may be input by the customer via the user interface602. In an example embodiment, the customer can obtain a running total and/or view items scanned for purchase via the user interface602.

In an example embodiment, the scanner118scans a tag of an item for purchase. The tag providing data representative of the item. The customer device logic112maintains a current amount due of the scanned item (or items) for purchase. The customer device logic112obtains payment for the current amount due. As described herein, the payment data may be preset and/or input by the customer when the customer is done purchasing items. In an example embodiment, a request for payment is received from a merchant computer system via wireless transceiver120. The customer device logic112provides the payment to a merchant computing system responsive to the request for payment via wireless transceiver120. In particular embodiments, the customer device logic112may automatically send payment information upon detecting that the customer device104is in a checkout area. In yet another example embodiment, the customer employs user interface602to request a payment be sent to the merchant.

In an example embodiment, the scanner118scans a plurality of tags of items for purchase, the plurality of tags providing data representative of a plurality of respective items. The customer device logic112maintains a current amount due that is updated responsive to scanning each of the plurality of tags.

In an example embodiment, a request is received to remove an item for purchase from the plurality of respective items. For example, the customer may employ user interface602to indicate the customer is no longer interested in purchasing a particular item. The customer employs scanner112to scan a tag associated with the item to be removed. The customer device logic112updates the current amount due responsive to scanning the tag associated with the item to be removed.

In an example embodiment, the customer device logic112receives a signal indicating an amount due indicated by a scan of items by a point of sale device does not match the current amount due via wireless transceiver120. The user interface602provides an interface that allows adjusting the amount of payment to match the amount due indicated by the scan by the point of sale device. In another example embodiment, data representative of the items scanned by the merchant is received via wireless transceiver120. The user interface602outputs (either visually or audibly) the items scanned by merchant device. In yet another example embodiment, the user interface provides an interface that allows the customer to request assistance.

In an example embodiment, the customer device logic112is operable to send data representative of a tag scanned by scanner118to a merchant computing system via wireless transceiver120. The customer device logic112receives data representative of a price for the item from the merchant computer system responsive to sending the data representative of the tag to the merchant computing system via wireless interface120. In another example embodiment, the data representative of the item obtained from the tag by scanner118comprises a price of the item.

FIG. 7is a block diagram illustrating an example of a user interface700for a customer device. In an example embodiment, the user interface700is employed by user interface602of customer device104. User interface700may be implemented on a touch screen interface or on a combination of a display and a keypad.

In an example embodiment, the user interface700comprises a current total display702, s scan new item input704, remove item input706, price check input708, and a checkout/pay input710. The current total display702maintains a current total of the items scanned (mobile cart) for purchase. This can allow a customer to determine if they are over budget. The scan new item input704is employed by the customer to add a new item into the mobile cart. The remove item input706is employed by the customer to remove an item from the mobile cart. For example, if the customer decides not to purchase something and is removing the item from their cart, the would use the remove item input706and then scan the tag associated with the item to remove the item from the mobile cart. The price check input708enables the customer to obtain the price of an item which may help in determining whether to purchase the item. The checkout/pay input710is can be employed by the customer to initiate checkout (e.g., scanning of the physical cart) and/or provide payment information (e.g., account information).

FIG. 8is a block diagram illustrating an example of an item with a RFID tag106C that is scanned by both a customer device and a merchanted device. For example, the RFID tag106C may be operable to be scanned by WLAN (e.g., WIFI and/or PAN (e.g., BLUETOOTH) scanners. As those skilled in the art can readily appreciate, RFID tag106C may employ any suitable wireless technology.

FIG. 9is a block diagram illustrating an example of an item with a radio frequency identification tag106C1and optical tag106C2. For example, the optical tag106C2may be scanned by the customer device scanner118whereas the RFID tag106C1may be scanned by the merchant device scanner114. Examples of optical technologies that may be employed by tag106C2include, but are not limited to, UPC, barcode, QR code, IR or a combination of optical technologies. Examples of RFIC technologies that may be employed by tag106C1include, but are not limited to WIFI, BLUETOOTH, or a combination of wireless technologies. Although tags106C1and106C2are illustrated as separate tags, those skilled in the art can readily appreciate that this is merely for ease of illustration as in an example embodiment tags106C1and106C2are embodied on the same substrate.

FIG. 10is a block diagram illustrating an example of an item102with a first RFID tag106C3for scanning by a customer device and a second RFID tag106C4for scanning by a merchant device. As those skilled in the art can readily appreciate, different protocols may be employed by tags106C3and106C4. For example, tag106C3may comprise one or more of WIFI, BLUETOOTH, NFC and tag106C4may comprise one or more of WIFI or BLUETOOTH. For example, the customer may employ NFC (a contactless protocol) to scan a tag associated with the item when putting the item into the mobile cart while the merchant device may employ WIFI (a WLAN protocol) to scan the tag associated with the item for the physical cart. Although tags106C3and106C4are illustrated as separate tags, those skilled in the art can readily appreciate that this is merely for ease of illustration as in an example embodiment tags106C3and106C4are embodied on the same substrate.

Although the above descriptions refer to items with tags on them, those skilled in the art should readily appreciate that in some embodiments the tag may be separate from an item. For example, when buying produce, the items may be weighed and a “tag” can be associated with the item which may comprise a barcode or other data that indicates the amount of the purchase (e.g., quantity, price per unit, total price, or a combination thereof). A physical tag may be provided to be placed on the item, however, an example embodiment, the customer device may send data representative of untagged items as part of the reconciliation process.

FIG. 11is a block diagram that illustrates a computer system1100upon which an example embodiment may be implemented. Computer system1100may be employed to implement merchant device logic110(FIGS. 1-5) customer device logic112(FIGS. 1-4 and 6), and/or payment module502(FIG. 5).

Computer system1100includes a bus1102or other communication mechanism for communicating information and a processor1104coupled with bus1102for processing information. Computer system1100also includes a main memory1106, such as random access memory (RAM) or other dynamic storage device coupled to bus1102for storing information and instructions to be executed by processor1104. Main memory1106also may be used for storing a temporary variable or other intermediate information during execution of instructions to be executed by processor1104. Computer system1100further includes a read only memory (ROM)1108or other static storage device coupled to bus1102for storing static information and instructions for processor1104. A storage device1110, such as a magnetic disk or optical disk, is provided and coupled to bus1102for storing information and instructions.

Computer system1100may be coupled via bus1102to a display1112such as a cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED) for displaying information to a computer user. An input device1114, such as a keyboard including alphanumeric and other keys is coupled to bus1102for communicating information and command selections to processor1104. Another type of user input device is cursor control1116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor1104and for controlling cursor movement on display1112. This input device typically has two degrees of freedom in two axes, a first axis (e.g. x) and a second axis (e.g. y) that allows the device to specify positions in a plane. In an example embodiment, the display1112, input device114and/or cursor control116may be integrated into a touch screen display.

An aspect of the example embodiment is related to the use of computer system1100for. According to an example embodiment, mobile cart reconciliation is provided by computer system1100in response to processor1104executing one or more sequences of one or more instructions contained in main memory1106. Such instructions may be read into main memory1106from another computer-readable medium, such as storage device1110. Execution of the sequence of instructions contained in main memory1106causes processor1104to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory1106. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement an example embodiment. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor1104for execution. Such a medium may take many forms, including but not limited to non-volatile media. Non-volatile media include for example optical or magnetic disks, such as storage device1110. Common forms of computer-readable media include for example floppy disk, a flexible disk, hard disk, magnetic cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASHPROM, CD, DVD or any other memory chip or cartridge, or any other medium from which a computer can read.

In an example embodiment, computer system1100also includes a communication interface1118coupled to bus1102. Communication interface1118provides a two-way data communication coupling computer system1100to a network link1120that is connected to a local network1122. This enables computer system1100to communicate with other external devices. For example communication interface1118may allow customer device104to communicate with merchant device108and visa versa.

Network link1120typically provides data communication through one or more networks to other data devices. For example, network link1120may comprise one or more wireless and/or wireless links.

In view of the foregoing structural and functional features described above, methodologies in accordance with example embodiments will be better appreciated with reference toFIGS. 12-17. While, for purposes of simplicity of explanation, the methodologies ofFIGS. 12-17are shown and described as executing serially, it is to be understood and appreciated that the example embodiments described herein are not limited by the illustrated orders, as some aspects could occur in different orders and/or concurrently with other aspects from that shown and described herein. Moreover, not all illustrated features described herein may be required to implement a methodology in accordance with an example embodiment. The methodologies described herein are suitably adapted to be implemented in hardware, software when executed by a processor, or a combination thereof.

FIG. 12is a block diagram illustrating a methodology1200for mobile cart reconciliation where payment is made before checkout. As described herein, portions of the methodology1200may be performed by merchant device logic110(FIGS. 1-5) customer device logic112(FIGS. 1-4 and 6), payment module502(FIG. 5), and/or computer system1100(FIG. 11).

At1202, data representative of an item is obtained by scanning a tag associated with the item by a device associated with a customer (e.g., customer device104, such as a mobile device). As described herein, the tag may be any suitable type of tag. The data may include a description of the item (for example brand, model number) and/or pricing information. For example, tag may be an optical tag such as scan a bar code, quick response (QR) code, a Universal Product Code (UPC), or in particular embodiments a combination of two or more of a bar code, QR code, and UPC code. In another example embodiment, the tag is an infra-red (IR) tag. In still another example embodiment, the tag is a Radio Frequency Identification (RFID) scanner that may employ any suitable wireless protocol, such as a contactless protocol (e.g., NFC), a PAN protocol (e.g., BLUETOOTH) or a WLAN protocol (e.g., WI-FI).

In an example embodiment, the data obtained from the tags for like items (e.g., same product) is the same. In another example embodiment, each item, including like items, has a unique tag.

As indicated at1204, the customer (e.g., mobile) device tracks items for purchase (the mobile cart). If the customer desires to purchase another item, actions1202and1204are repeated. Actions1202and1204may be repeated as often as desired by the customer. The customer may purchase any physically realizable number of items.

At1206, the customer provides payment information. In an example embodiment, the payment information is based on a sum of the items scanned and tracked (the mobile cart). The payment information may include account information (e.g., credit, checking, etc.) which can be debited by the merchant.

At1208, a merchant device (e.g., merchant device108described herein) scans the items brought to a checkout area by the customer (which may be carried to the checkout or be in a cart) by scanning the tags associated with the items by a scanner associated with a point of sale device associated with a merchant (e.g., the physical cart).

At1210, the merchant device verifies (reconciles) whether the physical cart matches the mobile cart. If the physical cart matches the mobile cart (YES), the payment is accepted and the methodology1200is done as indicated by1212.

However, if at1210the mobile cart and the physical cart do not match (NO), then corrective action may be taken as indicated by1214. For example, a comparison can be made of the mobile cart and physical cart to reconcile the mobile cart and physical cart. If there was an item scanned by the physical cart that is not present in the mobile cart, the customer may have the option to scan a tag associated with the item with the customer device104or scan opt to discard the item. The customer also has the option to adjust the payment as indicated by1206. As another example, if the customer physical cart shows less items than the mobile cart (e.g., the customer may have returned an item to the shelf and forgot to indicate the item was returned in the mobile cart), the customer may adjust the mobile cart.

After corrective action is taken, the physical cart is again scanned and reconciled with the mobile cart. If the mobile cart matches the physical cart (YES) then the payment is accepted and the process is completed as indicated by1212otherwise (NO), corrective action can again be taken as indicated by1214.

FIG. 13is a block diagram illustrating a methodology1300for mobile cart reconciliation where payment is made after checkout. As described herein, portions of the methodology1300may be performed by merchant device logic110(FIGS. 1-5) customer device logic112(FIGS. 1-4 and 6), payment module502(FIG. 5), and/or computer system1100(FIG. 11).

At1302, data representative of an item is obtained by scanning a tag associated with the item by a device associated with a customer (e.g., customer device104, such as a mobile device). As described herein, the tag may be any suitable type of tag. The data may include a description of the item (for example brand, model number) and/or pricing information. For example, tag may be an optical tag such as scan a bar code, quick response (QR) code, a Universal Product Code (UPC), or in particular embodiments a combination of two or more of a bar code, QR code, and UPC code. In another example embodiment, the tag is an infra-red (IR) tag. In still another example embodiment, the tag is a Radio Frequency Identification (RFID) scanner that may employ any suitable wireless protocol, such as a contactless protocol (e.g., NFC), a PAN protocol (e.g., BLUETOOTH) or a WLAN protocol (e.g., WI-FI).

In an example embodiment, the data obtained from the tags for like items (e.g., same product) is the same. In another example embodiment, each item, including like items, has a unique tag.

As indicated at1304, the customer (e.g., mobile) device tracks items for purchase (the mobile cart). If the customer desires to purchase another item, actions1302and1304are repeated. Actions1302and1304may be repeated as often as desired by the customer. The customer may purchase any physically realizable number of items.

At1306, a merchant device (e.g., merchant device108described herein) scans the items brought to a checkout area by the customer (which may be carried to the checkout or be in a cart) by scanning the tags associated with the items by a scanner associated with a point of sale device associated with a merchant (e.g., the physical cart).

At1308, the merchant device verifies (reconciles) whether the physical cart matches the mobile cart. If the physical cart matches the mobile cart (YES), at1310, the customer provides payment information. In an example embodiment, the payment information is based on a sum of the items scanned and tracked (the mobile cart). The payment information may include account information (e.g., credit, checking, etc.) which can be debited by the merchant.

However, if at1308the mobile cart and the physical cart do not match (NO), then corrective action may be taken as indicated by1312. For example, a comparison can be made of the mobile cart and physical cart to reconcile the mobile cart and physical cart. If there was an item scanned by the physical cart that is not present in the mobile cart, the customer may have the option to scan a tag associated with the item with the customer device104or scan opt to discard the item. As another example, if the customer physical cart shows less items than the mobile cart (e.g., the customer may have returned an item to the shelf and forgot to indicate the item was returned in the mobile cart), the customer may adjust the mobile cart.

After corrective action is taken, the physical cart is again scanned and reconciled with the mobile cart. If the mobile cart matches the physical cart (YES) then the payment is obtained at1310; otherwise (NO), corrective action can again be taken as indicated by1312.

FIG. 14is a block diagram illustrating a methodology1400for mobile cart reconciliation performed by a device associated with a customer (such as a mobile device) where payment is made before the mobile cart is reconciled with the physical cart. As described herein, the methodology1400may be performed by customer device logic112(FIGS. 1-4 and 6), payment module502(FIG. 5), and/or computer system1100(FIG. 11).

At1402, the application for the customer device (mobile cart) is started. If the application is already running, the mobile cart may be reset.

At1404, the customer initiates an action. The action may be any action involved in the purchasing process. In the example embodiment illustrated inFIG. 14, the actions may include, but are not limited to, add a new item to the mobile cart, remove (and subtract price) of an item to the mobile cart, request a price check, or signal that purchasing is complete and proceed to checkout.

At1406, the tag associated with an item is scanned. The tag may be any suitable type of tag such as an optical tag (e.g., UPC code, barcode, and/or QR code) or RFID tag (e.g., NFC, WIFI and/or BLUETOOTH). Once the tag is scanned, the selected action is taken. For example, if the selected action is to add an item to the mobile cart (ADD), the item and the price of the item are added to the mobile cart (which maintains a current amount due of scanned items for purchase) as indicated by1408. If the selected action was a price check, at1410the price of the item is displayed on a display associated with the customer device. If the selected action is to remove (or subtract) an item from the mobile cart, then the item is removed from the mobile cart and its price is subtracted from the total value of items in the mobile cart. Although note shown inFIG. 14, as described herein, the tag does not contain the price of the item, the customer device is operable to communicate with a merchant device to obtain the price. In an example embodiment, the customer device may scan a plurality of tags. A description of the items associated with the tags and current amount due are maintained by the mobile cart.

If, at1404, the customer indicates they are done shopping (DONE), at1414payment for the items in the mobile cart (current amount due) is obtained by the customer device. In an example embodiment, the customer inputs the payment. In another example embodiment, the payment is selected from predefined accounts.

Optionally, at1416, the customer device may signal the merchant device to scan the mobile cart (i.e., obtain the physical cart). In another example embodiment, the merchant device automatically detects when the mobile cart has moved into a checkout area to initiate scanning the physical cart.

At1418, the customer device will receive a signal from a device associated with the merchant indicating whether the mobile cart and physical cart matched. If the mobile cart and physical cart match (YES), the payment input at1414is sent to the merchant device and the process is completed as indicated by1420. In an example embodiment, the merchant device sends a signal to the customer device requesting the payment be sent and the customer device sends the payment data to the merchant device responsive to the request.

If, at1418, the mobile cart and physical cart do not match (NO), processing returns to1404where corrective action may be taken by the customer. In an example embodiment, the customer may be provided with a display of either the mobile cart, physical cart, or both to help the customer reconcile the mobile cart and physical cart. For example, if the customer returned an item to the shelf and forgot the remove it from the mobile cart, the customer can update the mobile cart. As another example, if there is an item in the mobile cart that the customer forgot to scan the customer can add the item to the mobile cart. In particular embodiments, the customer is provided with a user interface that allows the customer to request assistance.

Upon reconciling the mobile cart and physical cart, the customer can again indicate they are done at1404. At1414, changes to the payment may be input (e.g., if the payment amount changed) and at1416the merchant device rescans the physical cart. The actions inFIG. 14, including but not limited to actions1404,1414,1416, and1418may be repeated one or more times to complete the transaction.

FIG. 15is a block diagram illustrating a methodology1500for mobile cart reconciliation performed by a device (such as a mobile device) associated with a customer where payment is made after the mobile cart is reconciled with the physical cart. As described herein, portions of the methodology1400may be performed by customer device logic112(FIGS. 1-4 and 6), payment module502(FIG. 5), and/or computer system1100(FIG. 11). As described herein, portions of the methodology1400may be performed by customer device logic112(FIGS. 1-4 and 6), payment module502(FIG. 5), and/or computer system1100(FIG. 11).

At1502, the application for the customer device (mobile cart) is started. If the application is already running, the mobile cart may be reset.

At1504, the customer initiates an action. The action may be any action involved in the purchasing process. In the example embodiment illustrated inFIG. 15, the actions may include, but are not limited to, add a new item to the mobile cart, remove (and subtract price) of an item to the mobile cart, request a price check, or signal that purchasing is complete and proceed to checkout.

At1506, the tag associated with an item is scanned. The tag may be any suitable type of tag such as an optical tag (e.g., UPC code, barcode, and/or QR code) or RFID tag (e.g., NFC, WIFI and/or BLUETOOTH). Once the tag is scanned, the selected action is taken. For example, if the selected action is to add an item to the mobile cart (ADD), the item and the price of the item are added to the mobile cart (which maintains a current amount due of scanned items for purchase) as indicated by1408. If the selected action was a price check, at1410the price of the item is displayed on a display associated with the customer device. If the selected action is to remove (or subtract) an item from the mobile cart, then the item is removed from the mobile cart and its price is subtracted from the total value of items in the mobile cart. Although note shown inFIG. 14, as described herein, the tag does not contain the price of the item, the customer device is operable to communicate with a merchant device to obtain the price. In an example embodiment, the customer scans a plurality of tags. A description of the items associated with the scanned tags and the current amount due are maintained by the mobile cart.

If, at1504, the customer indicates they are done shopping (DONE), optionally at1514, the customer device may signal the merchant device to scan the mobile cart (i.e., obtain the physical cart). In another example embodiment, the merchant device automatically detects when the mobile cart has moved into a checkout area to initiate scanning the physical cart.

At1516, the customer device will receive a signal from a device associated with the merchant indicating whether the mobile cart and physical cart matched. If the mobile cart and physical cart match (YES), at1518payment for the mobile cart (current amount due) is obtained by the customer device and provided to the merchant device. In an example embedment, the customer device receives a signal from the merchant device requesting the payment and the customer device sends the payment in response to the signal. In an example embodiment, the customer inputs the payment. In another example embodiment, the payment is selected from predefined accounts.

If, at1516, the mobile cart and physical cart do not match (NO), processing returns to1504where corrective action may be taken by the customer. Optionally, the customer may be provided with a display of either the mobile cart, physical cart, or both to help the customer reconcile the mobile cart and physical cart. For example, if the customer returned an item to the shelf and forgot the remove it from the mobile cart, the customer can update the mobile cart. As another example, if there is an item in the mobile cart that the customer forgot to scan the customer can add the item to the mobile cart. In particular embodiments, the customer is provided with a user interface that allows the customer to request assistance from the merchant.

Upon reconciling the mobile cart and physical cart, the customer can again indicate they are done at1504. At1514, the merchant device re-scans the physical cart. if the mobile cart and physical cart match (YES) the payment is obtained by the customer device at1518and sent to the merchant device. The actions inFIG. 15, including but not limited to actions1504,1514, and1516may be repeated one or more times to complete the transaction.

FIG. 16is a block diagram illustrating a methodology1600for mobile cart reconciliation performed by a point of sale (POS) system associated with a merchant where payment is made before the mobile cart and physical cart are reconciled. As described herein, the methodology1600may be performed by merchant device logic110(FIGS. 1-5) and/or computer system1100(FIG. 11).

At1602, data from a customer device (the mobile cart) associated with a customer is received. The data is representative of one or more items the customer is requesting to purchase. In an example embodiment, the data comprises the current amount due. In particular embodiments, the data comprises a description and price for each item in the mobile cart.

At1604, payment data is obtained from the customer device. The payment data may comprise financial accounts such as checking or credit card accounts that to debit for payment of the items in the mobile cart. In an example embedment, the merchant device may request the payment data. In particular embodiments, the payment data is sent with the mobile cart data.

At1606, the items being purchased by the customer (physical cart) are scanned by the merchant device. In an example embodiment, the items are contained within a shopping cart, however, those skilled in the art should readily appreciate that the shopping cart is not necessary as the customer may simply carry the items. In an example embodiment, a signal is received from the customer device to checkout which prompts the scan. In another example embodiment, the scan is automatically performed responsive to detecting the customer in a predefined (e.g., checkout) area.

At1608, the merchant device compares (reconciles) the mobile cart with the physical cart. If the mobile cart matches the physical cart (YES), the amount owed matches the payment amount and the payment is accepted. The methodology1600is completed as indicated at1612.

If, at1608, the physical cart does not match the mobile cart (NO), payment for the items is not accepted (the payment is rejected) and corrective action is taken as indicated by1610. In an example embodiment, the corrective action may include displaying the physical contents of the mobile cart and physical cart to the user to facilitate reconciliation. In another example embodiment, the merchant device sends data representative of the physical cart to the customer device which can allow the customer device to assist in reconciliation. The customer may opt to scan an item into the mobile cart that was in the physical cart but not in the mobile cart, or alternatively, remove the item from the mobile cart. The customer may also opt to remove an item that is in the mobile cart that is not in the physical cart (for example if the customer scanned an item into the mobile cart and later decided not to purchase the item but forgot to remove it from the mobile cart. After the corrective action is taken, the payment information may updated at1604(if the payment amount changed) and the physical cart is again scanned at1606. In an example embodiment, the customer device may send a signal requesting a rescan of the physical cart. As those skilled in the art can readily appreciate, actions1610,1604,1606, and1608may be repeated any physically realizable number of times to complete the transaction.

FIG. 17is a block diagram illustrating a methodology1700for mobile cart reconciliation performed by a POS system associated with a merchant where payment is made after the mobile cart and physical cart are reconciled. As described herein, the methodology1700may be performed by merchant device logic110(FIGS. 1-5) and/or computer system1100(FIG. 11).

At1702, data from a customer device (the mobile cart) associated with a customer is received. The data is representative of one or more items the customer is requesting to purchase. In an example embodiment, the data comprises the current amount due. In particular embodiments, the data comprises a description and price for each item in the mobile cart.

At1704, the items being purchased by the customer (physical cart) are scanned by the merchant device. In an example embodiment, the items are contained within a shopping cart, however, those skilled in the art should readily appreciate that the shopping cart is not necessary as the customer may simply carry the items. In an example embodiment, a signal is received from the customer device to checkout which prompts the scan. In another example embodiment, the scan is automatically performed responsive to detecting the customer in a predefined (e.g., checkout) area.

At1706, the merchant device compares (reconciles) the mobile cart with the physical cart. If the mobile cart matches the physical cart (YES), at1710, payment data is obtained from the customer device. The payment data may comprise financial accounts such as checking or credit card accounts that to debit for payment of the items in the mobile cart. In an example embedment, the merchant device may request the payment data.

If, at1706, the physical cart does not match the mobile cart (NO), corrective action is taken as indicated by1708. In an example embodiment, the corrective action may include displaying the physical contents of the mobile cart and physical cart to the user to facilitate reconciliation. In another example embodiment, the merchant device sends data representative of the physical cart to the customer device which can allow the customer device to assist in reconciliation. The customer may opt to scan an item into the mobile cart that was in the physical cart but not in the mobile cart, or alternatively, remove the item from the mobile cart. The customer may also opt to remove an item that is in the mobile cart that is not in the physical cart (for example if the customer scanned an item into the mobile cart and later decided not to purchase the item but forgot to remove it from the mobile cart. After the corrective action is taken, the physical cart is again scanned at1704. In an example embodiment, the customer device may send a signal requesting a rescan of the physical cart. As those skilled in the art can readily appreciate, actions1706,1708, and1704may be repeated any physically realizable number of times to complete the transaction. Once the physical cart and mobile cart match, payment is obtained as indicated at1710.

In the above examples, payment is described as being obtained by the customer device. However, those skilled in the art should readily appreciate that payment may be obtained by the customer device, merchant device, or partial payments may be received by both the customer device and merchant device. Therefore, the example embodiments described herein should not be construed as limited to which device obtains the payment.

Described above are example embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies, but one of ordinary skill in the art will recognize that many further combinations and permutations of the example embodiments are possible. Accordingly, this application is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.