CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to U.S. Provisional Patent Application No. 62/492,695 entitled "Method and Apparatus For Object Status Detection," filed on May 1, 2017 by Fu et al., which is incorporated herein by reference in its entirety.

BACKGROUND

[0001] Environments in which inventories of objects are managed, such as products for purchase in a retail environment, may be complex and fluid. For example, a given environment may contain a wide variety of objects with different attributes (size, shape, price and the like). Further, the placement and quantity of the objects in the environment may change frequently. Still further, imaging conditions such as lighting may be variable both over time and at different locations in the environment. These factors may reduce the accuracy with which information concerning the objects may be collected within the environment.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0002] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.

[0003] FIG. 1 is a schematic of a mobile automation system.

[0004] FIG. 2 is a block diagram of certain internal hardware components of the server in the system of FIG. 1.

[0005] FIG. 3 is a flowchart of a method of object status detection.

[0006] FIGS. 4A and 4B depict example input data to the method of FIG. 3

[0007] FIG. 5 depicts the location of the input data of FIG. 4 in a common frame of reference. [0008] FIG. 6 illustrates location-based merging of input data.

[0009] FIGS. 7 A and 7B are examples of reference data for use in the method of FIG. 3.

[0010] FIG. 8 illustrates the comparison of the input data of FIG. 4A with the reference data of FIG. 7A.

[0011] FIG. 9 illustrates the comparison of the input data of FIG. 4b with the reference data of FIG. 7B.

[0012] FIG. 10 is a flowchart of a method of status classification.

[0013] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0014] The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

DETAILED DESCRIPTION

[0015] Environments such as warehouses, retail locations (e.g. grocery stores) and the like typically contain a wide variety of products supported on shelves, for selection and purchase by customers. As a result, the composition of the set of products supported by any given shelf module varies over time, as products are removed and, in some cases, replaced by customers. Products that have been partially or fully depleted typically require restocking, and products that have been incorrectly replaced (referred to as "plugs") typically require relocation to the correct position on the shelves. The detection of restocking or plug issues is conventionally performed by human employees, via visual assessment of the shelves and manual barcode scanning. This form of detection is labor-intensive and therefore costly, as well as error-prone.

[0016] Attempts to automate the detection of product status issues such as those mentioned above are complicated by the fluid nature of the environment in which an autonomous data capture system is required to operate. Among other difficulties, digital images of the shelves vary in quality depending on the available lighting, the presence of visual obstructions, and the like. Further, the breadth of products present on the shelves and the variations in their positioning on the shelves reduces the accuracy of machine-generated status detection.

[0017] Examples disclosed herein are directed to a method of object status detection for objects supported by a shelf, from shelf image data, including: obtaining a plurality of images of a shelf, each image including an indication of a gap on the shelf between the objects; registering the images to a common frame of reference; identifying a subset of the gaps having overlapping locations in the common frame of reference; generating a consolidated gap indication from the subset; obtaining reference data including (i) identifiers for the objects and (ii) prescribed locations for the objects within the common frame of reference; based on a comparison of the consolidated gap indication with the reference data, selecting a target object identifier from the reference data; and generating and presenting a status notification for the target product identifier.

[0018] FIG. 1 depicts a mobile automation system 100 in accordance with the teachings of this disclosure. The system 100 includes a server 101 in communication with at least one mobile automation apparatus 103 (also referred to herein simply as the apparatus

103) and at least one mobile device 105 via communication links 107, illustrated in the present example as including wireless links. The system 100 is deployed, in the illustrated example, in a retail environment including a plurality of shelf modules 110 each supporting a plurality of products 112. The shelf modules 110 are typically arranged in a plurality of aisles, each of which includes a plurality of modules aligned end-to-end. More specifically, the apparatus 103 is deployed within the retail environment, and communicates with the server 101 (via the link 107) to navigate, either fully or partially autonomously, the length of at least a portion of the shelves 110.

The apparatus 103 is equipped with a plurality of navigation and data capture sensors

104, such as image sensors (e.g. one or more digital cameras) and depth sensors (e.g. one or more Light Detection and Ranging (LIDAR) sensors), and is further configured to employ the sensors to capture shelf data. In the present example, the apparatus 103 is configured to capture a series of digital images of the shelves 110, as well as a series of depth measurements, each describing the distance and direction between the apparatus 103 and one or more points on a shelf 110, such as the shelf itself or the product disposed on the shelf.

[0019] The server 101 includes a special purpose imaging controller, such as a processor 120, specifically designed to control the mobile automation apparatus 103 to capture data, obtain the captured data via the communications interface 124 and store the captured data in a repository 132 in the memory 122. The server 101 is further configured to perform various post-processing operations on the captured data and to detect the status of the products 112 on the shelves 110. When certain status indicators are detected by the imaging processor 120, the server 101 is also configured to transmit status notifications (e.g. notifications indicating that products are out-of-stock, low stock or misplaced) to the mobile device 105. The processor 120 is interconnected with a non- transitory computer readable storage medium, such as a memory 122, having stored thereon computer readable instructions for detecting out of stock and/or low stock inventory on the shelves 110, as discussed in further detail below. The memory 122 includes a combination of volatile (e.g. Random Access Memory or RAM) and non-volatile memory (e.g. read only memory or ROM, Electrically Erasable Programmable Read Only Memory or EEPROM, flash memory). The processor 120 and the memory 122 each comprise one or more integrated circuits. In one embodiment, to increase reliability and processing speed of high volume of sensor data collected by the mobile automation apparatus 103, a specially designed integrated circuit, such as a Field Programmable Gate Array (FPGA), is designed to detect out of stock and/or low stock inventory discussed herein, either alternatively or in addition to the imaging controller/processor 120 and memory 122. As those of skill in the art will realize, the mobile automation apparatus 103 also includes one or more controllers or processors and/or FPGAs, in communication with the controller 120, specifically configured to control navigational and/or data capture aspects of the apparatus 103.

[0020] The server 101 also includes a communications interface 124 interconnected with the processor 120. The communications interface 124 includes suitable hardware

(e.g. transmitters, receivers, network interface controllers and the like) allowing the server 101 to communicate with other computing devices - particularly the apparatus

103 and the mobile device 105 - via the links 107. The links 107 may be direct links, or links that traverse one or more networks, including both local and wide-area networks. The specific components of the communications interface 124 are selected based on the type of network or other links that the server 101 is required to communicate over. In the present example, a wireless local-area network is implemented within the retail environment via the deployment of one or more wireless access points. The links 107 therefore include both wireless links between the apparatus 103 and the mobile device 105 and the above-mentioned access points, and a wired link (e.g. an Ethernet-based link) between the server 101 and the access point.

[0021] The memory 122 stores a plurality of applications, each including a plurality of computer readable instructions executable by the processor 120. The execution of the above-mentioned instructions by the processor 120 configures the server 101 to perform various actions discussed herein. The applications stored in the memory 122 include a control application 128, which may also be implemented as a suite of logically distinct applications. In general, via execution of the control application 128 or subcomponents thereof, the processor 120 is configured to implement various functionality. The processor 120, as configured via the execution of the control application 128, is also referred to herein as the controller 120. As will now be apparent, some or all of the functionality implemented by the controller 120 described below may also be performed by preconfigured hardware elements (e.g. one or more ASICs) rather than by execution of the control application 128 by the processor 120.

[0022] In the present example, in particular, the server 101 is configured via the execution of the control application 128 by the processor 120, to process input data including image and depth data captured by the apparatus 103, as well as attributes (e.g. of gaps between products 112 on the shelves 110, and identifiers of the products 112) derived from the image and depth data, to generate status notifications relating to the products 112.

[0023] Turning now to FIG. 2, before describing the operation of the application 128 to detect out of stock, low stock and/or plug inventory, certain components of the application 128 will be described in greater detail. As will be apparent to those skilled in the art, in other examples the components of the application 128 may be separated into distinct applications, or combined into other sets of components. Some or all of the components illustrated in FIG. 2 may also be implemented as dedicated hardware components, such as one or more Application-Specific Integrated Circuits (ASICs) or FPGAs. For example, in one embodiment, to improve reliability and processing speed, at least some of the components of FIG. 2 are programmed directly into the imaging controller 120, which may be an FPGA or an ASIC having circuit and memory configuration specifically designed to optimize high volume image processing for the detection of high volume sensor data being received from the mobile automation apparatus 103. In such an embodiment, some or all of the control application 128, discussed below, is embodied in FPGA or ASIC chip logic.

[0024] The control application 128, in brief, includes components configured to obtain input data depicting certain attributes of shelves 110, to process the input data for comparison with reference data, and to generate product status notifications (such as out of stock, low stock, and plug notifications) based on the comparison.

[0025] More specifically, in the present example, the control application 128 includes an image pre-processor 200 configured to obtain and process input data depicting a shelf 110 and products 112. The control application 128 also includes a reference generator 202 configured to generate reference data relating to the shelf 110, for use by a comparator 204, which is configured to compare the reference data and the input data to identify mismatches therebetween. The control application 128 also includes a classifier 208, configured to classify the output of the comparator 204 (that is, the mismatches mentioned above). Further, the control application 128 includes a validator configured to validate the output of the classifier 208, as well as a notifier 216 configured to generate status notifications based on the output of the classifier 208 and the validator 212.

[0026] The functionality of the control application 128 will now be described in greater detail, with reference to the components illustrated in FIG. 2. Turning to FIG. 3, a method 300 of object status detection is shown. The method 300 will be described in conjunction with its performance on the system 100 as described above.

[0027] The performance of the method 300 begins at block 305, at which the controller 120, and in particular the image pre-processor 200, is configured to obtain input data including at least one shelf image and at least one indicator of an attribute derived from the shelf image. The shelf image is, in the present example, a digital image (e.g. an RGB image) depicting a region of a shelf 110 and the products 112 supported by that region of shelf. In some examples, the above-mentioned indicators include gap indicators. Turning to FIG. 4 A, an input image 400 is shown, including two gap indicators 408-1 and 408-2. Each gap indicator 408 defines a bounding box indicating, relative to the image 400, the location of a gap between products 112, where a back 412 of the shelf 110 is visible. In the present example, as shown in FIG. 4A, the gap indicators 408 are obtained at block 305 as an overlay on the image 400. In other examples, the gap indicators are obtained instead as metadata fields included with the image 400, or as a distinct set of values (e.g. bounding box coordinates) along with the image 400. In other examples, the above-mentioned gap indicators are obtained as a binary gap mask, indicating areas of the image 400 that have been classified as gaps (e.g. with a high intensity) and areas of the image 400 that have not been classified as gaps (e.g. with a low intensity).

[0028] In other examples, referring to FIG. 4B, the indicators include object indicators 416 (of which three examples 416-1, 416-2 and 416-3 are illustrated). Each object indicator 416 includes an object identifier 420, such as a SKU number, text string or the like corresponding to a product 112. In the example illustrated in FIG. 4B, the object identifiers 420-1, 420-2 and 420-3 are text strings identifying respective products 112. Each object indicator 416 also includes an object location 424 within the image 400. In the illustrated example, the object locations 424-1, 424-2 and 424-3 are obtained at block 305 as bounding boxes overlaid on the image 400. In other examples, the object locations 424 and the object identifiers 420 are contained in metadata fields of the image 400, or are received as distinct data (e.g. a separate file) associated with the image 400. More specifically, the control application 128 includes a product recognition engine configured to compare various image features of the image 400 to a database of product models and to select product models having image features that match those in the image 400. For each selected product model, the product recognition engine is configured to insert into the image 400 or otherwise associate with the image 400 an indicator 416 including a location of the matching image features, as well as an object identifier 424 corresponding to those features.

[0029] At block 305, the image pre-processor 200 is also configured to obtain depth measurements corresponding to the image 400. The depth measurements and the images obtained at block 305 are typically captured substantially simultaneously by the apparatus 103 and stored in the repository 132. Therefore, at block 305 the image preprocessor 200 is configured to retrieve the image 400 and the depth measurements from the repository. The depth measurements are registered with the image 400 in the present example; that is, each depth measurement is assigned a location (e.g. pixel coordinates) within the image 400. In other examples, if the above registration has not yet been completed, the image pre-processor 200 is configured to register the depth measurements to the image 400.

[0030] Further, the image pre-processor 200 is configured, in the present example, to segment the above-mentioned depth measurements based on the indicators shown in FIG.4. That is, the image pre-processor 200 is configured to project the bounding boxes defined by the indicators 408 or 416 onto the depth measurements, and to thereby assign a subset of the depth measurements to each bounding box. As will now be apparent, such segmentation assembles groups of depth measurements that correspond to individual gaps (for the indicators 408) and machine-recognized products 112 (for the indicators 416).

[0031] Returning to FIG. 3, at block 310, the image pre-processor 200 is configured to register the input data to a common frame of reference. The common frame of reference is a previously defined coordinate system for the retail (or other) environment containing the shelves 110. Turning to FIG. 5, an origin 500 is depicted, defining a coordinate system; thus, each shelf 110 as well as any other objects within the retail environment can be assigned coordinates relative to the origin 500. At block 310, the image pre-processor 200 is therefore configured to identify a region of the shelves 110 depicted by the image 400 obtained at block 305. The identification of such a region is based, in the present example, on navigation data generated by the apparatus at the time that the image 400 and depth measurements were captured, and stored in the repository 132. For example, in the present performance of block 310, the image pre-processor 200 identifies that the image 400 and corresponding depth measurements depict a region 504 of the shelves 110.

[0032] At block 315, the image pre-processor 200 is configured to merge indicators that overlap in the common frame of reference. More specifically, the input data obtained at block 305 includes a plurality of images depicting overlapping portions of a shelf 110, in some examples. The apparatus 103 typically captures a stream of images while traveling along the shelves 110, and therefore each region of each shelf 110 is typically depicted in more than one capture image. At block 305, therefore, the image pre-processor 200 obtains a set of adjacent images (i.e. a set of images captured in sequence by the apparatus 103). FIG. 6 depicts the image 400, as well as a second image 600 depicting a region of the shelf 110 that overlaps with the region depicted by the image 400.

[0033] At block 315, the image pre-processor 200 is configured to register the images 400 and 600 with each other (i.e. to a common set of pixel coordinates), for example by applying a suitable image feature registration operation (e.g. edge and blob identification and matching) to the images 400 and 600. A registered image 604 resulting from the registration of the images 400 and 600 is also shown in FIG. 6, with the products 112 and the shelf omitted for simplicity. Having registered the images 400 and 600, the image pre-processor 200 is configured to identify subsets of the indicators (that is, subsets among the gap indicators 408-1, 408-2, 408-1 ' and 408-2', in the example of FIG. 6) that have overlapping locations in the registered image 604. As seen in FIG. 6, the gap indicators from the image 600 are overlaid, with heavier line weights, with the gap indicators from the image 400.

[0034] The gap indicators 408 and 408', while overlapping, do not overlap perfectly, for example due to the different physical positions of the apparatus 103 during the capture of the images 400 and 600, and due to imaging artifacts (e.g. lighting or contrast changes) in the images 400 and 600 that affect the detection of gaps by the control application 128. The image pre-processor 200 is configured, for each subset of overlapping indicators (i.e. two subsets in the illustrated example, indicators 408-1 and

408-1 ', and indicators 408-2 and 408-2'), to select one of the overlapping indicators for further processing via the method 300. For example, the input data can include a confidence level associated with each indicator 408, determined during the generation of the input data (i.e. of the gap indicators or the object indicators). In such examples, the image pre-processor 200 is configured to select the one indicator 408 from each subset with the highest confidence value. In other examples, the image pre-processor

200 is configured to generate a consolidated indicator, consisting of the overlapping area within each subset. Two such consolidated indicators 608-1 and 608-2 are shown in FIG. 6. In other examples, the performance of block 315 is omitted for the indicators 416 (i.e. the object indicators), or for the indicators 408 (i.e. the gap indicators), or both.

[0035] Referring again to FIG. 3, at block 320, the comparator 204 is configured to obtain, for example from the repository 132, reference data corresponding to the location depicted by the input data in the common frame of reference (that is the location 504, as shown in FIG. 5), and to register the reference data with the input data obtained at block 305. Turning to FIGS. 7A and 7B, two examples of reference data are shown. FIG. 7A, in particular, illustrates a portion of a reference planogram 700, containing reference indicators 704-1, 704-2 and 704-3. Each indicator 704 defines a reference location, for example via a bounding box within the common frame of reference. Each indicator 704 also includes a product identifier, such as a text string (as shown in FIG. 7A), a SKU number or the like. In addition, the indicators 704 can each include a facing number indicating the number of adjacent products having the same identifier that are expected to be within the corresponding bounding box. Thus, the indicator 704-3 indicates that within the specified bounding box, two adjacent boxes of "Acme Crunch" are expected to be present on the shelf 110.

[0036] FIG. 7B depicts another example form of reference data obtained at block 320. In particular, FIG. 7B depicts reference data 710 comprising a shelf image (e.g. an RGB image) including a plurality of reference object indicators. Each reference object indicator includes a reference location 714-1, 714-2, 714-3, 714-4 (illustrated as bounding boxes in the present example), and an associated reference product identifier 718-1, 718-2, 718-3, 718-4. The reference data 710, which may also be referred to as a realogram, is retrieved from the repository 132. In addition, the reference data 710 includes depth measurements segmented to each of the bounding boxes 714 as described above in connection with the performance of block 305.

[0037] Prior to its retrieval, the reference data 710 may be generated or updated by the reference generator 202. In particular, the reference generator 202 is configured to perform blocks 305, 310 and in some examples 315) of the method 300 in isolation, under "full stock" conditions in the retail environment. That is, the apparatus 103 can be configured to traverse the shelves 110 and capture image data and depth measurements, when the retail environment is fully stocked with the products 112. The capture of input data for use in reference data generation is performed a predetermined time intervals. For example, reference data capture may be performed once per day before the retail environment is open to customers. Other suitable time periods can also be used for reference data capture.

[0038] The reference generator 202, having obtained input image and depth data, is configured to obtain the reference object indicators as shown in FIGS. 7 A and 7B by providing the input data to the above-mentioned product recognition engine. As will now be apparent, the reference generator 202 receives from the product recognition engine the reference locations 714 and the reference object identifiers 718. The reference generator 202 is then configured to store the image, as well as the reference object indicators, in the repository 132 in association with a location within the common frame of reference.

[0039] At block 325, responsive to obtaining the reference data, the comparator 204 is configured to determine whether any mismatches exist between the reference data retrieved at block 320 and the input data obtained and processed at blocks 305-315. In some examples, in which the input data includes the gap indicators 408, the comparator 204 is configured to retrieve the planogram 700 as reference data, and to determine whether the gap indicators 408 overlap with any of the reference indicators 704. When the determination is negative (i.e. no gap indicators overlap with any of the reference indicators 704), the performance of the method 300 advances to block 335, which is discussed below. However, in the present example performance, as seen in FIG. 8, the registration of the input data with the planogram 700 reveals that the gap indicators 408 - shown as projections 800-1 and 800-2 over the planogram 700 - overlap with all three of the reference indicators 704.

[0040] FIG. 9 illustrates the registration of the input data including the object indicators 416 with the realogram 710. When the input data includes the object indicators 416, the comparator 204 is configured to retrieve the realogram 710 and determine whether any of the reference object indicators 714 and 718 are not represented in the input data, as well as whether any of the object indicators 416 are not represented in the reference data 710. As seen in FIG. 9, two reference indicators are not represented in the input data, as shown by the shaded areas 900-1 and 900-2 corresponding to the reference indicators for the product "Juice" and the product "Acme Crunch" respectively. Further, one object indicator included in the input data is not represented in the reference data 710, as shown by the shaded area 900-3 corresponding to the object indicator 416-3 for the product "Acme Cola".

[0041] Returning to FIG. 3, following an affirmative determination at block 325, the comparator 204 is configured to provide the mismatched object identifiers, also referred to as target object identifiers, to the classifier 208. At block 330, the classifier 208 is configured to assign, to each target object identifier, one of a plurality of preconfigured status types. In the present example, the status types include an out of stock (OOS) status, a low stock (LS) status, and a plug (PL) status. As will be apparent to those skilled in the art, an OOS status indicates that the corresponding product is depleted from the shelf 110 and requires replenishment. An LS status indicates that the corresponding product, although not entirely depleted, is nearing depletion. A PL status indicates that the corresponding product has been misplaced on the shelf 110 - that is, the corresponding product, according to the reference data, was not expected in the location at which it has been detected.

[0042] When a mismatch indicates that an object identifier in the input data is not represented in the reference data, as shown in FIG. 9 in connection with the "Acme Cola" product, the classifier 208 is configured to assign a PL status type to the object identifier. When the mismatch indicates the reverse scenario, however - that is, an object identifier in the reference data that is not represented in the input data - the classifier 208 is configured to perform the classification process shown in FIG. 10 to select one of the OOS and LS status for the relevant object identifier.

[0043] Referring to FIG. 10, at block 1005 the classifier 208 is configured to determine the degree of coverage of the mismatch identified at block 325. In the case of mismatches revealed by the gap indicators 408, at block 1005 the classifier 208 is configured to determine a proportion of at least one reference object indicator that overlaps with the gap indicator 408. Referring again to FIG. 8, for example, as shown by the shaded area 800-1, the gap indicator 408-1 overlaps entirely with the reference indicator 704-2 (i.e. overlaps 100% of the area defined by the reference indicator 704- 2), and also overlaps with about 12% of the area of the reference indicator 704-1. Turning to FIG. 9, the shaded areas 900-1 and 900-2 indicate that the entirety of the reference location indicators 714-2 and 714-4 are not represented in the input data (i.e. the degree of coverage of the mismatches detected in association with the reference indicators 714-2 and 714-4 is 100%).

[0044] In some examples, the classifier 208 is configured to determine the degree of coverage as a number of facings expected from the reference data but not represented in the input data, rather than a percentage as discussed above. To determine a number of missing facings when the input data includes the gap indicators 408, the classifier 208 is configured to determine a facing width for the relevant product from the reference data. In the present example, referring to FIG. 7, each reference indicator 704 in the planogram 700 defines a total width of the region expected to contain a given product, as well as a number of facings of that product. The facing width is therefore determined by dividing the total indicator width by the facing number from the planogram. In other examples, the planogram may also contain data defining the width of each facing (i.e. the width of the product). Returning to FIG. 10, therefore, the classifier 208 is configured to determine a facing width for the mismatched object indicator, and to determine how many facing widths are covered by a given gap indicator 408. As shown in FIG. 8, the degree of coverage represented by the shaded area 800-1 corresponds to one facing of the "Juice" product, and to about 12% of one facing of the "Acme Dog Food" product. The shaded area 800-2, meanwhile, covers about 70% of one facing for the "Acme Crunch" product.

[0045] The classifier 208 is configured to adjust facing numbers covered by mismatches, for example based on preconfigured thresholds. For example, if the degree of coverage determined at block 1005 is greater than 65%, the classifier 208 is configured to adjust the degree of coverage to one facing. Conversely, if the degree of coverage is less than 50%, the classifier 208 is configured to set the degree of coverage to zero facings (as such low coverage may be a result of expected spaces between products 112, rather than spaces indicating missing products).

[0046] When the input data includes the object indicators 416, the classifier 208 is configured to determine a degree of coverage in facings by counting the number of adjacent reference indicators having the same product identifier that are not represented in the input data. As seen from FIG. 9, in the present example the degree of coverage of the shaded areas 900-1 and 900-2 are one facing each.

[0047] At block 1010, having determined a degree of coverage of the mismatches identified at block 325, the classifier 208 is configured to determine whether each degree of coverage meets or exceeds an upper threshold. The upper threshold can be set as a percentage (e.g. 90% of the area of a planogram indicator 704), or as a number of facings. Typically, the upper threshold corresponds to all expected facings of the mismatched product. Thus, the upper threshold for the reference indicator 704-2 is one facing, and the determination at block 1010 for the shaded area 800-1 is affirmative. However, the upper threshold for the reference indicator 704-3 is two, and the determination at block 1010 for the shaded area 800-2 is therefore negative.

[0048] When the determination at block 1010 is affirmative, the classifier 208 assigns an OOS status to the relevant reference object identifier at block 1015. When the determination at block 1010 is negative, however, the classifier 208 proceeds to block 1020 to determine whether the degree of coverage meets or exceeds a lower threshold. The classifier 208 can determine the lower threshold based on the expected number of facings of a product, as specified by the reference data 700 or 710. More specifically, the lower threshold is set as the total number of expected facings, minus a minimum number of required facings to avoid the generation of a low stock status notification. Typically, low stock notifications are generated when only one facing remains of a product with a number of expected facings greater than one. Therefore, the lower threshold is typically one facing lower than the total expected number of facings. Thus, if the degree of coverage meets the lower threshold, only one facing of the product remains, and the classifier 208 is configured to assign an LS status to the relevant reference object identifier at block 1025. Referring again to FIG. 8, the LS status is assigned to the mismatch indicated by the shaded area 800-2 (i.e. to the product "Acme Crunch"). When the determination at block 1020 is negative, however, the classifier 208 is configured to assign a "normal" status to the mismatch, indicating that although a product is not fully stocked on the shelf 110, it has not been sufficiently depleted to warrant a low stock notification. [0049] Following the classification process, performance of the method proceeds to block 335. At block 335, the validator 212 is configured to validate the output of the classifier 208, for example based on the depth measurements obtained at block 305. The validation at block 335 includes any one of, or any combination of, several distinct validations. For example, the validator 212 can be configured to obtain a shelf edge location relative to the input data, and to retrieve a known shelf depth (i.e. the distance between the shelf back 412 and the shelf edge). The shelf edge location can be detected from the depth measurements, or can be retrieved from the repository 132. Having obtained the shelf edge location and shelf depth, the validator 212 is configured to determine whether the depth measurements for areas corresponding to any products assigned an OOS status at block 330 are sufficiently beyond the shelf edge to confirm the OOS status. That is, the validator 212 is configured to determine whether the depth measurements corresponding to the shaded area 800-1 are greater than the shelf edge depth by a margin substantially equal to the known shelf depth. If the determination is negative, the corresponding gap indicator 408 may have been incorrect (i.e. a product may be present on the shelf 110 that was detected as a gap). When the determination is negative, the validator 212 is configured to alter the status classification from OOS to PL.

[0050] In other examples, the validator 212 is configured, for a reference object identifier assigned the PL status, to retrieve a segment of depth measurements from the repository 132 corresponding to the relevant reference object identifier. The depth measurements are retrieved from a location in the common frame of reference different than that depicted by the input data, as the product assigned a plug status has been misplaced. Responsive to retrieving the segment of depth measurements, which represent a three-dimensional scan of the plug product, the validator 212 is configured to compare the retrieved reference depth measurements with the segmented depth measurements corresponding to the plug (e.g. the depth measurements corresponding to the shaded area 900-3 in FIG. 9). When the reference depth measurements match the input depth measurements, the plug status is confirmed. Otherwise, the validator 212 is configured to discard the plug status assignment, or alter the assignment to indicate a reduced confidence level, for example. [0051] In further examples, the validator 212 is configured to obtain a shelf edge location as discussed above, and to determine whether the depth measurements segmented with any of the object indicators 416 exceed the depth of the shelf edge location by a configurable threshold. If the threshold is exceeded, the corresponding product is placed towards the shelf back 412, away from the shelf edge. For example, referring to FIG. 9, the obj ect indicator 416 indicates that the product "Acme Dog Food" is present, as expected by the reference realogram 710. However, comparison of the depth measurements corresponding to the object location 424-1 to the shelf edge reveals that the object location 424-1 is further from the shelf edge than a predetermined threshold (e.g. three centimeters). The validator 212 is therefore configured to generate an additional low-stock status assignment, beyond those generated at block 330.

[0052] Following completion of the validation at block 335, at block 340 the notifier is configured to generate one or more status notifications based on the outputs of the classifier 208 and the validator 212. Each status notification includes a product identifier, the status assigned to the product identifier, and the location of the corresponding indicator in the common frame of reference. Table 1 contains a list of status notifications generated based on the examples of input data and reference data discussed above.

Table 1: Status Notifications

[0053] As seen in Table 1, the first, third and fourth rows represent status notifications generated based on classification assigned at block 330, while the second row represents a status notification generated by the validator 212 at block 335. The status notifications are stored in the repository 132, in some examples. In other examples, the status notifications are transmitted directly to a client computing device, such as the mobile device 105.

[0054] In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.

[0055] The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

[0056] Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "has", "having," "includes", "including," "contains", "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises ...a", "has ...a", "includes ...a", "contains ...a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms "a" and "an" are defined as one or more unless explicitly stated otherwise herein. The terms "substantially", "essentially", "approximately", "about" or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0057] It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or "processing devices") such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.

[0058] Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer

(e.g., comprising a processor) to perform a method as described and claimed herein.

Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM

(Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM

(Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable

Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

[0059] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.