US20160110700A1

US20160110700A1 - Transaction audit suggestions based on customer shopping behavior

Info

Publication number: US20160110700A1
Application number: US14/644,888
Authority: US
Inventors: Susan Winter BROSNAN; Daniel Robert GOINS; Patricia Stephany Hogan; David Christopher KLAGES; Jessica Suzanne King SNEAD
Original assignee: Toshiba Global Commerce Solutions Holdings Corp
Current assignee: Toshiba Global Commerce Solutions Holdings Corp
Priority date: 2014-10-15
Filing date: 2015-03-11
Publication date: 2016-04-21
Also published as: US20160110772A1; US20190139375A1; US20190096198A1; US10825068B2; US20160110797A1; US11514497B2; US20160110791A1; US20160110902A1; US9786000B2; US10417878B2; US10672051B2; US20160110751A1; US20160110701A1; US10482724B2; US20200402130A1; US20160109281A1; US11127061B2; US20160110702A1; US10593163B2; US20160110793A1

Abstract

Systems, methods, and computer program products to perform an operation comprising receiving location data identifying a plurality of areas visited by a person in a shopping environment providing self-serve-checkout, identifying, based on the location data, a first product located in a first area of the plurality of areas in the shopping environment visited by the person, and returning an indication to perform an audit to determine whether the person is in possession of the first product without including the first product as part of a purchase completed by the person using self-serve-checkout.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional co-pending U.S. patent application Ser. No. 62/064,323 filed Oct. 15, 2014, which is herein incorporated by reference in its entirety.

BACKGROUND

The present disclosure relates to an integrated shopping environment, and more specifically, to transaction audit suggestions based on customer shopping behavior.
In a store where mobile or self-scan transactions occur as the customer moves about the store, audits are used to deter theft and provide the retailer with a sense of security. While these audits are helpful, the store employees are on their own to determine which items to look for while performing the audit. Currently, when the mobile or self-scan transaction systems processing a purchase determine a transaction requires an audit, the cashier is required to scan a configurable number of items in the shopper's possession, with consequences if any item does not match the transaction. However, the cashier will have to stumble upon unpurchased or unscanned items by chance with this implementation.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a system which provides transaction audit suggestions based on customer shopping behavior, according to one embodiment.

FIG. 2 is a schematic illustrating techniques to provide transaction audit suggestions based on customer shopping behavior, according to one embodiment.

FIG. 3 is a flow chart illustrating a method to provide transaction audit suggestions based on customer shopping behavior, according to one embodiment.

FIG. 4 is a flow chart illustrating a method to monitor customer behavior, according to one embodiment.

FIG. 5 is a flow chart illustrating a method to identify products for audit, according to one embodiment.

DETAILED DESCRIPTION

Embodiments disclosed herein evaluate a customer's shopping behavior to identify specific item types to use to conduct an audit process of a self-checkout operation. Embodiments disclosed herein collect data about the customer as they shop. The collected data may include identifying locations or areas in the store the customer visits, how long the customer spends in areas (or departments) of the store, the number of times the customer visits the area of the store, whether the customer visited areas associated with higher incidences of theft, whether the customer scanned any items for purchase in a given area, and the like. When the customer processes the transaction (using, for example, an application on a mobile checkout device, or a self-checkout kiosk), embodiments disclosed herein evaluate the collected information to identify specific items (or types of items) that a store employee should look for as part of the audit process.
For example, by tracking the customer's mobile device, embodiments disclosed herein may determine that the customer made four trips to a personal care aisle of the store (an area of the store that is associated with high rates of theft), spending a significant amount of time therein, without scanning any items for purchase. Embodiments disclosed herein may leverage this information along with other types of data (such as the customer's data in a customer profile) to identify and return a product that a store employee should look for as part of the audit process. For example, based on the customer's age, income, gender, and other demographic information, embodiments disclosed herein may return one or more of nail polish, razor blades, or baby food as a product to be searched for during the audit process. Once the identified products (or product types) are returned, the store employee may conduct an audit to determine whether the identified products are in the customer's possession (without having been added to the customer's transaction).
For example, considering the following series of exemplary actions:
A customer may enter the store and start the mobile shopping application on the customer's device. As the shopper roams the store, the system keeps track of which areas were visited, for how long, and what was added to the transaction (or not added to the transaction) in that area (via bar code scanning, object recognition or other means). The customer may roam the store and eventually end up in the baby food aisle, where the customer scans 4 baby food items, but places 6 items in the cart. The customer may then go to the personal care aisle and read product details for several brands of razor blades and place one package in the cart without scanning it. The customer may then visit the specialty cheese area and browse for a few minutes, but not add anything to the transaction or the cart. The customer may then finish shopping and go to a pay station. Based on the actions during shopping trip, the cashier is prompted to look for specialty deli, razor blades, and baby items. The cashier may look for specialty deli items, but nothing is found. The cashier may then scan the razor blades, which are then added to the transaction. The cashier may then scan the baby food and is prompted for quantity (6 vs. 4—does not match). The cashier may then scan other items in the cart as required to complete the audit. The store may then process the audit failure as needed.
FIG. 1 is a block diagram illustrating a system 100 which provides transaction audit suggestions based on customer shopping behavior, according to one embodiment. The networked system 100 includes a computer 102. The computer 102 may also be connected to other computers 102 via a network 130. In general, the network 130 may be a telecommunications network and/or a wide area network (WAN). In a particular embodiment, the network 130 is the Internet.
The computer 102 generally includes a processor 104 which obtains instructions and data via a bus 120 from a memory 106 and/or a storage 108. The computer 102 may also include one or more network interface devices 118, input devices 122, and display devices 124 connected to the bus 120. The computer 102 is generally under the control of an operating system (not shown). Examples of operating systems include the UNIX operating system, the 4690 operating system, versions of the Microsoft Windows operating system, and distributions of the Linux operating system. (UNIX is a registered trademark of The Open Group in the United States and other countries. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.) More generally, any operating system supporting the functions disclosed herein may be used. The processor 104 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs. The network interface device 118 may be any type of network communications device allowing the computer 102 to communicate with other computers via the network 130.
The storage 108 is representative of hard-disk drives, solid state drives, flash memory devices, optical media and the like. Generally, the storage 108 stores application programs and data for use by the computer 102. In addition, the memory 106 and the storage 108 may be considered to include memory physically located elsewhere; for example, on another computer coupled to the computer 102 via the bus 120.
The input device 122 may be any device for providing input to the computer 102. For example, a keyboard and/or a mouse may be used. The input device 122 represents a wide variety of input devices, including keyboards, mice, controllers, and so on. Furthermore, the input device 122 may include a set of buttons, switches or other physical device mechanisms for controlling the computer 102. The display device 124 may include output devices such as monitors, touch screen displays, and so on. In the illustrative embodiment, the system 100 also includes a camera 125, which may be any device configured to capture image data. In at least one aspect, the camera 125 comprises a plurality of security cameras in a retail store. The camera(s) 125 may be fixed in place such as one that is mounted from a ceiling or wall by means of a mounting bracket; or, the camera(s) 125 may be movable such as one mounted to an airborne drone capable of being navigated to different positions within a retail environment. A proximity module 119 is any hardware element that can be leveraged to determine a position of a device and/or proximity of the device to other devices. Examples of the proximity module 119 include, without limitation, global positioning system (GPS) radios, Bluetooth® radios, wireless network adapters, near field communications (NFC) radios, iBeacons®, and the like. A microphone 123 is configured to capture and/or record audio. As with the cameras 125, the microphone 123 may be fixed in space, or movable.
As shown, the memory 106 includes a checkout application 112, which is configured to process customer transactions. The customer transactions may include an audit process. As shown, the checkout application 112 includes an audit module 113, which is configured to determine whether to trigger an audit, and if so, identify products (or types of products) for auditing based on the customer's shopping behavior in a retail store. Generally, the audit module 113 and/or the checkout application 112 may track a customer using a proximity module 119 (such as a GPS radio) of a mobile device 150 used by the customer. The audit module 113 may collect multiple types of data describing the customer's shopping habits, such as the different areas of the store visited by the customer, how much time the customer spent in each area, a frequency of visits to each area, and the like. The audit module 113 and/or the checkout application 112 may store the collected data in the tracking data 117. The audit module 113 may consider a plurality of different factors when determining whether to audit a customer, and if so, which items should be subject to the audit. For example, the audit module 113 may consider one or more of: how much time a customer spends in an area of the store, how many times the customer visits a given area of the store, whether the customer scanned any items for purchase (and if so, how many) using the checkout application 112 on their mobile device 150 in a given area, a risk level associated with areas of the store, profit margins for products (or prices of products) in each area of the store visited, and correlations between products that are typically purchased together.
In at least one embodiment, the audit module 113 may compute an audit score for the customer based on the collected tracking data 117 and the configuration data 114. If the audit score exceeds a predefined audit threshold, the audit module 113 may trigger an audit for the customer. In addition (or alternatively), the audit module 113 may compute an audit score for each area of the store visited by the customer based on the collected tracking data 117 and the configuration data 114. If the audit score for a given area of the store exceeds a threshold for that area, the audit module 113 may focus the audit in that area, and return products from that area as the subject of the audit. The audit module 113 may generally consider any factor in generating an audit score for the customer or areas of the store visited by the customer. Although shown as a component of the checkout application 112, in at least one embodiment, the audit module 113 executes as a standalone application. In addition, the checkout application 112 and/or audit module 113 may execute as distributed applications where, for example, some of the audit logic is built into a terminal checkout application and some of the logic is implemented at the store server level.
As shown, the storage 108 includes configuration data 114, transaction data 115, profiles 116, and tracking data 117. The configuration data 114 stores business rules related to audit processes. For example, a first rule in the configuration data 114 may specify that products from areas of the store having higher profit items or higher incidences of theft should be the focus of an audit. As another example, a second rule in the configuration data 114 may specify correlations between products that are typically purchased together, such as peanut butter and jelly or razor blades and shaving cream. As another other example, the configuration data 114 may specify minimum time thresholds, which, if spent in a given area, may indicate a greater likelihood of theft. As still another example, the configuration data 114 may specify average quantities of an item that are typically purchased by a customer, such as seven jars of baby food, three apples, one container of milk, and the like. The audit module 113 may compare the number of items actually scanned by the customer to the average quantity during an audit. If the number of items scanned significantly deviates from the average number of items (e.g., exceeds two standard deviations), the audit module 113 may trigger an audit for extra quantities of the item (for example, if the customer scans one jar of baby food, the audit module 113 would compare this number to the seven jars typically purchased on average, and return the baby food as an item to search for during the audit). As yet another example, the configuration data 114 may include thresholds for number of trips to a particular area of the store, which, if exceeded, trigger an audit for items in that area. The configuration data 114 may also specify different thresholds for audit scores generated by the audit module 113, which, if exceeded, may trigger the audit process. For example, a trusted customer may have a first threshold, while an untrusted customer may have a second threshold, different than the first threshold, which reflects a lower level of trust in the untrusted customer. Doing so may allow the audit module 113 to trigger an audit of the untrusted customer more frequently than an audit of the trusted customer. The configuration data 114 may also include data describing different areas of the store, such a risk level (of a plurality of risk levels) for theft in each area of the store, a profit margin and/or a cost for products in each area of the store, and the like.
The transaction data 115 describes purchases made by customers, which may include the items scanned (and paid for) by a customer. For example, when the customer uses the checkout application 112 on the mobile device 150 to scan a package of cheese, the checkout application 112 may send an indication of the product scan to the transaction data 115 on the computer 102. The profiles 116 may include data describing customers who shop in the retail store. For example, the profiles 116 may include data gathered as part of a customer loyalty program, such as biographical information, preference information, and the like. In addition, the profiles 116 may specify a trust level (of a plurality of trust levels) of the customer, whether the customer was previously caught stealing (or attempting to steal), product purchase patterns, average quantities of products the customer typically purchases, whether the customer typically purchases different items together, and the like. The audit module 113 may leverage this information when determining which items to surface as part of an audit process of the customer during the checkout process. The tracking data 117 includes location data and other data describing a customer's actions when in a retail store. For example, entries in the tracking data 117 may describe a customer's location in a retail store taken at periodic intervals. Doing so may allow the audit module 113 to identify areas of the store (and specific items kept therein) that the customer may have taken items from without scanning the items using the checkout application 112.
As shown, a plurality of mobile devices 150 may execute instances of the checkout application 112. The mobile devices 150 may be a laptop, tablet computer, smartphone, and the like. Users may use the checkout application 112 to purchase items without having to go through a traditional checkout process. For example, a customer may scan different products and pay for the products using the checkout application 112 on the mobile device 150. As shown, the mobile devices 150 also include a proximity module 119, which may be, for example, a GPS radio, as described above. In at least one embodiment, the checkout application 112 on the mobile device 150 also includes an instance of the audit module 113. Generally, the audit module 113 may perform the functionality described herein on the mobile device 150, the computer 102, and/or a combination thereof, where the audit module 113 acts as a distributed application, with the instances of the audit module 113 communicating with each other.
FIG. 2 is a schematic 200 illustrating techniques to provide audit suggestions based on customer shopping behavior, according to one embodiment. As shown, a table 201 reflects data collected by the checkout application 112 and/or the audit module 113. The table 201 includes columns for a customer ID 210, store area 211, time in area 212, and items scanned 213. The customer ID 210 is a unique identifier for a customer. The store area 211 is a description of an area of a retail store, such as “health care,” “beauty,” or “Aisle 6.” The time in area 212 specifies a period of time spent by the customer in the store area 211. The items scanned 213 indicate which, if any, items a customer scanned while in the store area 211. In at least one embodiment, the data stored in the table 201 corresponds to data stored in the tracking data 117.
As shown, the data in table 201 corresponds to a customer having a customer ID of 123456. As shown, the customer visited a plurality of different areas 211 of the store, such as the health care area, deli, and meat/seafood department, and scanned items in different departments, such as oatmeal and shaving cream.
Table 202 reflects example data generated by the audit module 113. As shown, the table 202 includes columns for the store area 211, a theft risk 214, and audit items 215. The theft risk 214 reflects a risk of theft computed by the audit module 113, which may correspond to one of a plurality of different risk levels. In one embodiment, the risk levels may be based on audit scores computed by the audit module 113, with a range of audit scores corresponding to a risk level. The audit items 215 reflect items (if any) from the respective store area that should be subject to an audit. The audit items 215 may be specific items, or may be an instruction to look for items from a department (such as a general instruction to look for items from the seafood department).
Therefore, as shown in table 202, the audit module 113 has computed a “high” risk of theft in the health care area of the store. The audit module 113 may compute this risk of theft based on the data in the table 201 and/or rules in the configuration data 114. For example, as shown in table 201, the customer made three visits to the health care section, spent 2 minutes and 45 seconds in the section (in total), and scanned a bottle of shaving cream. The configuration data 114 may specify that the health care area is an area of high incidences of theft. Based on the data in the table 201, the audit module 113 may determine that the customer spent an amount of time exceeding a threshold (such as 30 seconds), made multiple stops in the health care section, and only scanned a single product in those three trips. Based on the collected data in the table 114 and the fact that the health care area has a high rate of thefts, the audit module 113 may determine the theft risk 214 for customer 123456 in the health care department is high. Accordingly, the audit module 113 may identify an item from the health care department to be a subject of the audit. Therefore, as shown, the audit module 113 returned razor blades as an audit item 215 for the health care section. The audit module 113 may make this determination based on one or more of the correlation between razor blades and shaving cream (which was scanned by the customer) and that razor blades are high profit items which are often stolen.
Similarly, the audit module 113 determined that the baby area 211 has a high risk of theft with regards to customer 123456. The audit module 113, for example, may have determined that the customer made too many trips to the baby department (exceeding a threshold value), spent more than a threshold amount of time in the baby department, and scanned only two cans of baby food. For example, the configuration data 114 may specify that customers (or the customer 123456) typically purchase 6 cans of baby food on average. Because the customer only scanned two cans of baby food, the audit module 113 may determine that the baby department (and/or products sold therein) have a high risk of theft 214. The audit module 113 may use this same information to identify baby food as an audit item 215. That is, the atypical behavior of the customer, combined with the rates of theft of baby food items is used to both identify this as a suspicions transaction and that baby food items should be the focus of an audit.
Further still, the audit module 113 may have determined that the meat/seafood departments have a high risk of theft 214. For example, the audit module 113 may make this determination based on the fact that the customer spent three minutes in the department without scanning any items, while purchasing cocktail sauce and steak sauce, items which are correlated to products in the meat/seafood department (such as shrimp and steak). Based on this information, the audit module 113 may further identify steak and shrimp as audit items 215.
As shown, however, the audit module 113 did not surface audit items 215 for all store areas 214, such as the cereal, condiments, deli, and dairy sections. The audit module 113 determined that these areas had either “low” or “medium” risks of theft 214. The audit module 113 may determine to forego returning items from these areas (or the areas themselves) for any reason, such as one or more of: the theft risk 214, that the customer scanned products in these departments, that the customer only made a single visit to these departments, and that the amount of time the customer spent in these departments.
FIG. 3 is a flow chart illustrating a method 300 to provide transaction audit suggestions based on customer shopping behavior, according to one embodiment. Generally, a computing system executing the steps of the method 300 may identify and return products (or product types) that should be the subject of an audit by an employee in a retail store.
As shown, the method 300 begins at step 310, where a user may configure the parameters of the audit system, such as defining rules, thresholds, and other parameters in the configuration data 114. In at least one embodiment, a set of parameters are predefined in the configuration data 114, and a user may optionally add or modify the predefined parameters at step 310. At step 320, the checkout application 112 and/or the audit module 113 may monitor customer behavior in a retail store. For example, a proximity module 119 of a mobile device 150 of the customer may provide location data describing the areas of a retail store visited by the customer. The instance of the checkout application 112 or the audit module 113 executing on the mobile device 150 or the computer 102 may collect and store this information in the tracking data 117 for later use. Using this information, the audit module 113 or the checkout application 112 may determine which areas of the store the customer visited, how long was spent in each area, a number of times the customer went to each area, and the like.
At step 330, the customer may scan products for purchase in a store using the instance of the checkout application 112 executing on the mobile device 150. At step 340, the customer may initiate the checkout process to pay for their scanned products using the instance of the checkout application 112 executing on the mobile device 150. At step 350, the audit module 113 may identify products (or categories of products) that should be part of an audit (if any). The audit module 113 may use the data collected by monitoring the customer's behavior at step 320, as well as the rules stored in the configuration data 114 when identifying products that should be part of an audit. For example, if a customer spent 10 minutes in a specialty cheese section of a supermarket, did not scan any cheeses, yet bought 3 boxes of crackers, the audit module 113 may identify cheese as an item that an supermarket employee should search for during the audit. At step 360, the employee may perform the audit based on the items returned at step 350. At step 370, the transaction is completed after the customer has paid for the products and the audit has been performed.
FIG. 4 is a flow chart illustrating a method 400 corresponding to step 320 to monitor customer behavior, according to one embodiment. As shown, the method 400 begins at step 410, where the audit module 113 (and/or the checkout application 112) monitors a customer's location using a proximity module 119 of the mobile device 150 used by the customer. For example, using GPS or Wi-Fi location services, the audit module 113 may determine each area the customer visited in a retail store as well as the times the customer was at each area. At step 420, the audit module 113 may execute a loop including steps 430-440 for each area the customer visited. For example, if the customer visits the produce, meat, and dairy sections of a supermarket, the audit module 113 may execute the loop for each of these sections. At step 430, the audit module 113 may determine the number of visits the customer made to the current area and the amount of time the customer spent in the current area. For example, the audit module 113 may determine that the customer spent two minutes in a single visit to the produce department, while spending four minutes over three trips to the meat department, while spending one minute in a single trip to the dairy department of the supermarket. At step 440, the audit module 113 may determine whether the customer scanned any items in the current department. For example, the audit module 113 may determine that the customer scanned no items in the produce department, while scanning various meats in the meat department, and milk and cheese in the dairy department. At step 450, the audit module 113 determines whether the customer visited other areas of the retail store. If the customer visited more areas, the audit module 113 returns to step 420. Otherwise, the audit module 113 proceeds to step 460, where the audit module 113 and/or the checkout application 112 stores the collected data in the tracking data 117. Doing so allows the audit module 113 to identify products for an audit based on the customer's behavior in the retail store.
FIG. 5 is a flow chart illustrating a method 500 corresponding to step 350 to identify products for audit, according to one embodiment. The method begins at step 510, where the audit module 113 executes a loop including steps 520-580 for each area of the store visited by the customer. The audit module 113 may determine the areas visited by the customer based on the data stored in the tracking data 117. At step 520, the audit module 113 may determine whether the current area is a high-theft area (or an area with a high loss margin). For example, the configuration data 114 may define the specialty cheese section as a high-theft area, while defining the cereal section as a low-theft area. At step 530, the audit module 113 may determine whether the customer scanned items in the current area. If the customer scanned products, the audit module 113 may determine that there is a lower likelihood that the customer did not scan other products in the current department. Therefore, the audit module 113 may be less likely to return products from the current department as targets for an audit.
At step 540, the audit module 113 may determine whether the amount of time and/or the number of times the customer visited the current area exceed respective thresholds in the configuration data 114. For example, a time threshold for the meat department may be one minute, while a time threshold for the produce department may be two minutes. If the customer's time in each area exceeds the respective threshold, the audit module 113 may identify a higher likelihood of theft in these areas. The time thresholds may also be thresholds of time in an area without buying (or scanning) an item. Similarly, the threshold number of visits to the meat department may be three visits, while the threshold number of visits to the produce department may be two. If the customer's number of visits to these sections exceeds their respective thresholds, the audit module 113 may determine that these areas may be associated with a higher likelihood of theft based on the customer's behavior.
At step 550, the audit module 113 may determine whether the customer scanned a product that was related (or correlated) to a different product that the customer scanned. For example, if the customer scanned cat litter, the audit module 113 may determine whether the customer also scanned cat food. If the customer did not scan cat food, which could likely be purchased along with the cat litter, the audit module 113 may identify the cat food as a product that should be the subject of an audit. At step 560, the audit module 113 may determine whether the quantity of any items scanned by the customer is within an average quantity threshold for that item. For example, the configuration data 114 may specify that for transactions where cat food is purchased, the average number of units of cat food is 8. Similarly, the customer data in the profiles 116 may specify that a specific customer purchases 10 units of cat food on average. If the threshold for either average is 2 units, and the customer scanned 1 unit of cat food, the audit module 113 may identify that the 1 unit of cat food scanned by the customer is not within either threshold. Therefore, the audit module 113 may determine that the customer may have taken more units of cat food than were scanned, and may identify cat food (or pet products in general) as a subject of an audit.
At step 570, the audit module 113 may compute an audit score for the current section. The audit module 113 may compute the audit score for the current section based on one or more of the determinations made at steps 520-560, the configuration data 114, the transaction data 115, data in the profiles 116, and the tracking data 117. The audit module 113 may use any suitable algorithm to compute an audit score for the current area. At step 580, the audit module 113 may return an item from the current area as the subject of an audit upon determining that the audit score for the current item exceeds an audit threshold for the current department. The audit threshold may be one of a plurality of audit thresholds in the configuration data 114. For example, the meat department may have an audit threshold of 60 (on a scale of 100), while the health and beauty department may have an audit threshold of 40. If the audit score for each section exceeds the respective threshold, the audit module 113 may identify a product (or a product group) from these sections for auditing. The audit module 113 may identify a product based on one or more of the determinations made at steps 520-560. In addition, the audit module 113 may identify a product from a list of products in the configuration data 114.
At step 590, the audit module 113 determines whether the customer visited more areas of the store. If the customer visited more areas of the store, the audit module 113 returns to step 510 to determine whether to identify items from those areas for auditing.
Advantageously, embodiments disclosed herein identify items for an audit based on a customer's behavior in a retail store. By monitoring the customer's location throughout the time in the store, embodiments disclosed herein may make informed decisions on areas of the store that may have been subject to theft. Doing so may improve the accuracy and efficiency of the audit process.
The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the recited features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the recited aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
Aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.”
The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications or related data available in the cloud. For example, the audit module 113 could execute on a computing system in the cloud and surface products to search for as part of an audit of a self-checkout process in a retail store. In such a case, the audit module 113 could identify products and store the identified products at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.

Claims

What is claimed is:

1. A method, comprising:

receiving location data identifying a plurality of areas visited by a person in a shopping environment providing self-serve-checkout;

identifying, based on the location data, a first product located in a first area of the plurality of areas in the shopping environment visited by the person; and

returning, by operation of one or more computer processors, an indication to perform an audit to determine whether the person is in possession of the first product without including the first product as part of a transaction completed by self-serve-checkout.

2. The method of claim 1, further comprising:

receiving data identifying a plurality of products included by the person as part of the transaction, wherein the first product is not included in the plurality of products included by the person.

3. The method of claim 1, wherein the location data specifies one or more of: (i) a total amount of time the person spent in a respective area of the plurality of areas in the shopping environment, (ii) a number of times the person visited the respective area, (iii) an indication that the person added a different product for transaction in the respective area, and (iv) a quantity of the different product added by the person.

4. The method of claim 1, wherein the first product is returned upon determining an audit score computed for the first product exceeds an audit threshold.

5. The method of claim 4, wherein the audit score for the first product is computed based on one or more of: (i) a user profile of the person, (ii) determining that the first area in the shopping environment is a high theft area, (iii) determining that the first product is subject to repeated historical thefts, (iv) a correlation between the first product and a second product, wherein the person added the second product to the transaction, (v) an average quantity of the first product purchased across all transactions in the shopping environment, and (vi) determining that the person spent an amount of time in the first area exceeding a time threshold without adding products to the transaction.

6. The method of claim 1, wherein the location data is generated by at least one of: (i) a wireless data module and (ii) a GPS module of a mobile device possessed by the person.

7. The method of claim 1, wherein the person completes the transaction using self-serve-checkout via at least one of: (i) a mobile checkout application executing on a mobile device, and (ii) a self-scan kiosk in the shopping environment.

8. A system, comprising:

one or more computer processors; and

a memory containing a program, which when executed by the processors, performs an operation comprising:

returning an indication to perform an audit to determine whether the person is in possession of the first product without including the first product as part of a transaction completed by self-serve-checkout.

9. The system of claim 8, the operation further comprising:

10. The system of claim 8, wherein the location data specifies one or more of: (i) a total amount of time the person spent in a respective area of the plurality of areas in the shopping environment, (ii) a number of times the person visited the respective area, (iii) an indication that the person added a different product for transaction in the respective area, and (iv) a quantity of the different product added by the person.

11. The system of claim 8, wherein the first product is returned upon determining an audit score computed for the first product exceeds an audit threshold.

12. The system of claim 11, wherein the audit score for the first product is computed based on one or more of: (i) a user profile of the person, (ii) determining that the first area in the shopping environment is a high theft area, (iii) determining that the first product is subject to repeated historical thefts, (iv) a correlation between the first product and a second product, wherein the person added the second product to the transaction, (v) an average quantity of the first product purchased across all transactions in the shopping environment, and (vi) determining that the person spent an amount of time in the first area exceeding a time threshold without adding products to the transaction.

13. The system of claim 8, wherein the location data is generated by at least one of: (i) a wireless data module and (ii) a GPS module of a mobile device possessed by the person.

14. The system of claim 8, wherein the person completes the transaction using self-serve-checkout via at least one of: (i) a mobile checkout application executing on a mobile device, and (ii) a self-scan kiosk in the shopping environment.

15. A computer program product comprising:

a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code when executed by one or more computer processors performs an operation comprising:

identifying, based on the location data, a first product located in a first area of the plurality of areas in the retail store visited by the person; and

16. The computer program product of claim 15, the operation further comprising:

17. The computer program product of claim 15, wherein the location data specifies one or more of: (i) a total amount of time the person spent in a respective area of the plurality of areas in the shopping environment, (ii) a number of times the person visited the respective area, (iii) an indication that the person added a different product for transaction in the respective area, and (iv) a quantity of the different product added by the person.

18. The computer program product of claim 15, wherein the first product is returned upon determining an audit score computed for the first product exceeds an audit threshold.

19. The computer program product of claim 18, wherein the audit score for the first product is computed based on one or more of: (i) a user profile of the person, (ii) determining that the first area in the shopping environment is a high theft area, (iii) determining that the first product is subject to repeated historical thefts, (iv) a correlation between the first product and a second product, wherein the person added the second product to the transaction, (v) an average quantity of the first product purchased across all transactions in the shopping environment, and (vi) determining that the person spent an amount of time in the first area exceeding a time threshold without adding products to the purchase.

20. The computer program product of claim 15, wherein the location data is generated by at least one of: (i) a wireless data module and (ii) a GPS module of a mobile device possessed by the person, wherein the person completes the purchase using self-serve-checkout via at least one of: (i) a mobile checkout application executing on a mobile device, and (ii) a self-scan kiosk in the shopping environment.