Source: http://www.google.com/patents/US20060283943?dq=5636223
Timestamp: 2017-03-27 05:03:22
Document Index: 183872981

Matched Legal Cases: ['art 108', 'art 108', 'art 108', 'art 108', 'art 108', 'art 400', 'art 500']

Patent US20060283943 - Systems and methods for merchandise checkout - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsSystems and methods for recognizing and identifying items located on the lower shelf of a shopping cart in a checkout lane of a retail store environment for the purpose of reducing or preventing loss or fraud and increasing the efficiency of a checkout process. The system includes one or more visual...http://www.google.com/patents/US20060283943?utm_source=gb-gplus-sharePatent US20060283943 - Systems and methods for merchandise checkoutAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20060283943 A1Publication typeApplicationApplication numberUS 11/466,371Publication dateDec 21, 2006Filing dateAug 22, 2006Priority dateFeb 27, 2004Also published asUS7100824, US8267316, US20050189411, US20130018741, WO2005088570A1Publication number11466371, 466371, US 2006/0283943 A1, US 2006/283943 A1, US 20060283943 A1, US 20060283943A1, US 2006283943 A1, US 2006283943A1, US-A1-20060283943, US-A1-2006283943, US2006/0283943A1, US2006/283943A1, US20060283943 A1, US20060283943A1, US2006283943 A1, US2006283943A1InventorsJim Ostrowski, Luis Goncalves, Micheal Cremean, Alex Simonini, Alec HudnutOriginal AssigneeEvolution Robotics Retail, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (26), Referenced by (53), Classifications (28), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetSystems and methods for merchandise checkout
DETAILED DESCRIPTION OF THE INVENTION [0034] The following detailed description is of the best currently contemplated modes of carrying out the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims. [0035] Broadly, the present invention provides systems and methods through which one or more visual sensors, such as one or more cameras, operatively coupled to a computer system can view, recognize and identify items for check out. For example, the items may be checked out for purchase in a store, and as a further example, the items may be located on the lower shelf of a shopping cart in the checkout lane of a store environment. The retail store environment can correspond to any environment in which shopping carts or other similar means of carrying items are used. One or more visual sensors can be placed at locations in a checkout register lane such that when a shopping cart moves into the register lane, a part of the shopping cart, such as the lower shelf, is within the field of view of the visual sensor(s). In contrast to the prior art which merely allows detection, in the present invention, visual features present on one or more objects within the field of view of the visual sensor(s) can be automatically detected as well as recognized, and then associated with one or more instructions, commands, or actions. The present invention can be applied, for example, to a point of sale replacing a conventional UPC barcode and/or manual checkout system with enhanced check out speed. In addition, the present invention may be used to identify various objects on other moving means, such as luggage on a moving conveyor belt. [0036] FIG. 1 is a partial cut-away view of a system 100 for merchandise checkout in accordance with one embodiment of the present invention. FIG. 1 illustrates an exemplary application of the system 100 that has a capability to recognize and identify objects on a moveable structure. For the purpose of illustration, the system 100 is described as a tool for recognizing items 116 carried on a lower shelf 114 of a shopping cart 108 and preventing bottom-of-the-basket loss only. However, it should be apparent to those of ordinary skill that the system 100 can also be used to recognize and identify objects in various applications based on the same principles as described hereinafter. For example, the system 100 may be used to capture images of items on a moving conveyor belt that may be a part of an automatic checkout system in a retail store environment or an automatic luggage checking system. [0037] As illustrated in FIG. 1, the checkout lane 100 includes an aisle 102 and a checkout counter 104. The system 100 includes a visual sensor 118 a, a checkout subsystem 106 and a processing unit 103 that may include a computer system and/or databases. In one embodiment, the system 100 may include additional visual sensor 118 b that may be used at a second location facing the shopping cart 108. Details of the system 100 will be given in following sections in connection with FIGS. 2A-5. For simplicity, only two visual sensors 118 a-b and one checkout subsystem 106 are shown in FIG. 1. However, it should be apparent to those of ordinary skill that any number of visual sensors and checkout subsystems may be used without deviating from the sprit and scope of the present invention. [0038] A checkout subsystem 106, such as a cash register or a point of sale (POS) subsystem, may rest on the checkout counter 104 and include one or more input devices. Exemplary input devices may include a barcode scanner, a scale, a keyboard, keypad, touch screen, card reader, and the like. In one embodiment, the checkout subsystem 106 may correspond to a checkout terminal used by a checker or cashier. In another embodiment, the checkout subsystem 106 may correspond to a self-service checkout terminal. [0039] As illustrated in FIG. 1, the visual sensor 118 a may be affixed to the checkout counter 104, but it will be understood that in other embodiments, the visual sensor 118 a may be integrated with the checkout counter 104, may be floor mounted, may be mounted in a separate housing, and the like. Each of the visual sensors 118 a-b may be a digital camera with a CCD imager, a CMOS imager, an infrared imager, and the like. The visual sensors 118 a-b may include normal lenses or special lenses, such as wide-angle lenses, fish-eye lenses, omni-directional lenses, and the like. Further, the lens may include reflective surfaces, such as planar, parabolic, or conical mirrors, which may be used to provide a relatively large field of view or multiple viewpoints. [0040] During checkout, a shopping cart 108 may occupy the aisle 102. The shopping cart 108 may include a basket 110 and a lower shelf 114. One or more items 112 may be carried in the basket 110, and one or more items 116 may be carried on the lower shelf 114. In one embodiment, the visual sensors 118 a-b may be located such that the item 116 may be at least partially within the field of view of the visual sensors 118 a-b. As will be described in greater detail later in connection with FIG. 4, the visual sensors 118 a-b may be used to recognize the presence and identity of the items 116 and provide an indication or instruction to the checkout subsystem 106. In another embodiment, the visual sensors 118 a-b may be located such that the items 112 in the basket 110 may be checked out using the system 100. [0041] FIG. 2A is a schematic diagram of one embodiment 200 of the system for merchandise checkout in FIG. 1. It will be understood that the system 200 may be implemented in a variety of ways, such as by dedicated hardware, by software executed by a microprocessor, by firmware and/or computer readable medium executed by a microprocessor or by a combination of both dedicated hardware and software. Also, for simplicity, only one visual sensor 202 and one checkout subsystem 206 are shown in FIG. 2A. However, it should be apparent to those of ordinary skill that any number of visual sensors and checkout subsystems may be used without deviating from the sprit and scope of the present invention. [0042] The visual sensor 202 may continuously capture images at a predetermined rate and compare two consecutive images to detect motion of an object that is at least partially within the field of view of the visual sensor 202. Thus, when a customer carries one or more items 116 on, for example, the lower shelf 114 of the shopping cart 108 and moves into the checkout lane 100, the visual sensor 202 may recognize the presence of the items 116 and send visual data 204 to the computer 206 that may process the visual data 204. In one embodiment, the visual data 204 may include the visual images of the one or more items 116. In another embodiment, an IR detector may be used to detect motion of an object. [0043] It will be understood that the visual sensor 202 may communicate with the computer 206 via an appropriate interface, such as a direct connection or a networked connection. This interface may be hard wired or wireless. Examples of interface standards that may be used include, but are not limited to, Ethernet, IEEE 802.11, Bluetooth, Universal Serial Bus, FireWire, S-Video, NTSC composite, frame grabber, and the like. [0044] The computer 206 may analyze the visual data 204 provided by the visual sensor 202 and identify visual features of the visual data 204. In one example, the features may be identified using an object recognition process that can identify visual features of an image. In another embodiment, the visual features may correspond to scale-invariant features. The concept of scale-invariant feature transformation (SIFT) has been extensively described by David G. Lowe, “Object Recognition from Local Scale-Invariant Features,” Proceedings of the International Conference on Computer Vision, Corfu, Greece, September, 1999 and by David G. Lowe, “Local Feature View Clustering for 3D Object Recognition,” Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, Kauai, Hi., December, 2001; both of which are incorporated herein by reference. [0045] It is noted that the present invention teaches an object recognition process that comprises two steps; (1) feature extraction and (2) recognize the object using the extracted features. However, It is not necessary to extract the features to recognize the object. [0046] The computer 206 may be a PC, a server computer, or the like, and may be equipped with a network communication device such as a network interface card, a modem, infra-red (IR) port, or other network connection device suitable for connecting to a network. The computer 206 may be connected to a network such as a local area network or a wide area network, such that information, including information about merchandise sold by the store, may be accessed from the computer 206. The information may be stored on a central computer system, such as a network fileserver, a mainframe, a secure Internet site, and the like. Furthermore, the computer 206 may execute an appropriate operating system. The appropriate operating system may include, but is not limited to, operating systems such as Linux, Unix, VxWorks®, QNX® Neutrino®, Microsoft® Windows® 3.1, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® NT, Microsoft® Windows® 2000, Microsoft® Windows® Me, Microsoft® Windows® XP, Apple® MacOS®, IBM OS/2®, Microsoft® Windows® CE, or Palm OS®. As is conventional, the appropriate operating system may advantageously include a communications protocol implementation that handles incoming and outgoing message traffic passed over the network. [0047] The computer 206 may be connected to a server 218 that may provide the database information 214 stored in an Object Database 222 and/or a Log Data Storage 224. The server 218 may send a query to the computer 206. A query is an interrogating process initiated by the Supervisor Application 220 residing in the server 218 to acquire Log Data from the computer 206 regarding the status of the computer 206, transactional information, cashier identification, time stamp of a transaction and the like. The computer 206, after receiving a query 214 from the server 218, may retrieve information from the log data 216 to pass on relevant information back to the server 218, thereby answering the interrogation. A Supervisor Application 220 in the server 218 may control the flow of information therethrough and manage the Object Database 222 and Log Data Storage 224. When the system 200 operates in a “training” mode, the server 218 may store all or at least part of the analyzed visual data, such as features descriptors and coordinates associated with the identified features, along with other relevant information in the Object Database 222. The Object Database 222 will be discussed in greater detail later in connection with FIG. 3. [0048] It will be understood that during system training, it may be convenient to use a visual sensor that is not connected to a checkout subsystem and positioned near the floor. For example, training images may be captured in a photography studio or on a “workbench,” which can result in higher-quality training images and less physical strain on a human system trainer. Further, it will be understood that during system training, the computer 206 may not need to output match data 208. In one embodiment, the features of the training images may be captured and stored in the Object Database 222. [0049] When the system 200 operates in an “operation” mode, the computer 206 may compare the visual features with the database information 214 that may include a plurality of known objects stored in the Object Database 222. If the computer 206 finds a match in the database information 214, it may return match data 208 to the checkout subsystem 206. Examples of appropriate match data will be discussed in greater detail later in connection with FIG. 3. The server 218 may provide the computer 206 with an updated, or synchronized copy of the Object Database 222 at regular intervals, such as once per hour or once per day, or when an update is requested by the computer 206 or triggered by a human user. [0050] When the computer 206 cannot find a match, it may send a signal to the checkout subsystem 212 that may subsequently display a query on a monitor and request the operator of the checkout subsystem 212 to take an appropriate action, such as identifying the item 116 associated with the query and providing the information of the item 116 using an input device connected to the checkout subsystem 212. [0051] In the operational mode, the checkout subsystem 212 may provide transaction data 210 to the computer 206. Subsequently, the computer 206 may send log data 216 to the server 218 that may store the data in the Object Database 222, wherein the log data 216 may include data for one or more transactions. In one embodiment, the computer 206 may store the transaction data 210 locally and provide the server 218 with the stored transaction data for storage in the Object Database 222 at regular intervals, such as once per hour or once per day. [0052] The server 218, Object Database 222 and Log Data Storage 224 may be connected to a network such as a local area network or a wide area network, such that information, including information from the Object Database 222 and the Log Data Storage 224, can be accessed remotely. Furthermore, the server 208 may execute an appropriate operating system. The appropriate operating system may include but is not limited to operating systems such as Linux, Unix, Microsoft® Windows® 3.1, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® NT, Microsoft® Windows® 2000, Microsoft® Windows® Me, Microsoft® Windows® XP, Apple® MacOS®, or IBM OS/2®. As is conventional, the appropriate operating system may advantageously include a communications protocol implementation that handles incoming and outgoing message traffic passed over the network. [0053] When the checkout subsystem 212 receives the match data 208 from the computer 206, the checkout subsystem 212 may take one or more of a wide variety of actions. In one embodiment, the checkout subsystem 212 may provide a visual and/or audible indication that a match has been found for the operator of the checkout subsystem 212. In one example, the indication may include the name of the object. In another embodiment, the checkout subsystem 212 may automatically add the item or object associated with the identified match to a list or table of items for purchase without any action required from the operator of the checkout subsystem 212. It will be understood that the list or table may be maintained in the checkout system 212 memory. In one embodiment, when the entry of merchandise or items or purchase is complete, a receipt of the items and their corresponding prices may be generated at least partly from the list or table. The checkout system 212 may also store an electronic log of the item, with a designation that it was sent by the computer 206. [0054] FIG. 2B is a schematic diagram of another embodiment 230 of the system for merchandise checkout in FIG. 1. It will be understood that the system 230 may be similar to the system 200 in FIG. 2A with some differences. Firstly, the system 230 may optionally include a feature extractor 238 for analyzing visual data 236 sent by a visual sensor 234 to extract features. The feature extractor 238 may be dedicated hardware. The feature extractor 238 may also send visual display data 240 to a checkout subsystem 242 that may include a display monitor for displaying the visual display data 240. Secondly, in the system 200, the computer 206 may analyze the visual data 204 to extract features, recognize the items associated with the visual data 204 using the extracted features and send the match data 208 to the checkout subsystem 212. In contrast, in the system 230, the feature extractor 238 may analyze the visual data 236 to extract features and send the analyzed visual data 244 to the server 246 that may subsequently recognize the items. As a consequence, the server 246 may send the match data 248 to the checkout subsystem 242. Thirdly, in the system 200, the checkout subsystem 212 may send transaction log data to the server 218 via the computer 206, while, in the system 230, the checkout subsystem 242 may send the transaction log data 250 to the server 246 directly. It is noted that both systems 200 and 230 may use the same object recognition technique, such as SIFT method, even though different components may perform the process of analysis and recognition. Fourthly, the server 246 may include a recognition application 245. [0055] It is noted that the system 230 may operate without the visual display data 240. In an alternative embodiment of the system 230, the visual display data 240 may be included in the match data 248. [0056] It will be understood that the components of the system 230 may communicate with one another via connection mechanisms similar to those of the system 200. For example, the visual sensor 234 may communicate with the server 246 via an appropriate interface, such as a direct connection or a networked connection, wherein examples of interface standards may include, but are not limited to, Ethernet, IEEE 802.11, Bluetooth, Universal Serial Bus, FireWire, S-Video, NTSC composite, frame grabber, and the like. Likewise, the Object Database 252 and the Log Data Storage 254 may be similar to their counterparts of FIG. 2A. [0057] The server 246 may execute an appropriate operating system. The appropriate operating system may include but is not limited to operating systems such as Linux, Unix, Microsoft® Windows® 3.1, Microsoft® Windows® 95, Microsoft® Windows® 98, Microsoft® Windows® NT, Microsoft® Windows® 2000, Microsoft® Windows® Me, Microsoft® Windows® XP, Apple® MacOS®, or IBM OS/2®. As is conventional, the appropriate operating system may advantageously include a communications protocol implementation that handles incoming and outgoing message traffic passed over the network. [0058] The system 230 may operate in an operation mode and a training mode. In the operation mode, when the checkout subsystem 242 receives match data 248 from the server 246, the checkout subsystem 242 may take actions similar to those performed by the checkout subsystem 212. In the operational mode, the checkout subsystem 242 may provide transaction log data 250 to the server 246. Subsequently, the server 246 may store the data in the Object Database 252. In one embodiment, the checkout subsystem 242 may store the match data 248 locally and provide the server 246 with the match data for storage in the Object Database 252 at regular intervals, such as once per hour or once per day. [0059] FIG. 2C is a schematic diagram of another embodiment 260 of the system for merchandise checkout in FIG. 1. The system 260 may be similar to the system 230 in FIG. 2B with a difference that the functionality of the feature extractor 238 may be implemented in a checkout subsystem 268. As illustrated in FIG. 2C, a visual sensor 262 may send visual data 264 to a checkout subsystem 268 that may analyze the data to generate analyzed visual data 272. In an alternative embodiment, the visual data 264 may be provided as an input to a server 274 via the checkout subsystem 268 if the server 274 has the capability to analyze the input and recognize the item associated with the input. In this alternative embodiment, the server 274 may receive the unmodified visual data 264 via the checkout subsystem 268, and perform the analysis and feature extraction of the unmodified visual data 264. [0060] Optionally, a feature extractor 266 may be used to extract features and generate analyzed visual data. The visual extractor 266 may be implemented within a visual sensor unit as shown in FIG. 2B or may be separate from the visual sensor. In this case, the checkout subsystem 268 may simply pass the analyzed visual data 272 to the server 274. [0061] The system 260 may operate in an operation mode and a training mode. In the operation mode, the checkout subsystem 268 may store a local copy of the Object Database 276, which advantageously may allow the matching process to occur relatively quickly. In the training mode, the server 274 may provide the checkout subsystem 268 with an updated, or synchronized copy of the Object Database 276 at regular intervals, such as once per hour or once per day, or when an update is requested by the checkout subsystem 268. [0062] When the system 260 operates in the operation mode, the server 274 may send the match data 270 to the checkout subsystem 268. Subsequently, the checkout subsystem 268 may take actions similar to those performed by the checkout subsystem 242. The server 274 may also provide the match data to a Log Data Storage 278. It will be understood that the match data provided to the Log Data Storage 278 can be the same as or can differ from the match data 270 provided to the checkout subsystem 268. In one embodiment, the match data provided to the Log Data Storage 278 may include an associated timestamp, but the match data 270 provided to the checkout subsystem 268 may not include a timestamp. The Log Data Storage 278, as well as examples of appropriate match data provided for the Log Data Storage 278, will be discussed in greater detail later in connection with FIG. 3. In an alternative embodiment, the checkout subsystem 268 may store match data locally and provide the server 274 with the match data for storage in the Log Data Storage 278 at regular intervals, such as once per hour or once per day. [0063] It will be understood that the component of the system 260 may communicate with one another via connection mechanisms similar to those of the system 230. Also, it is noted that the Object Database 276 and Log Data Storage 278 may be similar to their counterparts of FIG. 2B and explained in the following sections in connection with FIG. 3. [0064] Optionally, the server 274 can reside inside the checkout subsystem 268 using the same processing and memory power in the checkout subsystem 268 to run both the supervisor application 275 and recognition application 273. [0065] FIG. 3 is a schematic diagram of an Object Database 302 and Log Data Storage 312 (or, equivalently, log data storage database) illustrating an example of a relational database structure in accordance with one embodiment of the present invention. It will be understood by one of ordinary skill in the art that a database may be implemented on an addressable storage medium and may be implemented using a variety of different types of addressable storage mediums. For example, the Object Database 302 and/or the Log Data Storage 312 may be entirely contained in a single device or may be spread over several devices, computers, or servers in a network. The Object Database 302 and/or the Log Data Storage 312 may be implemented in such devices as memory chips, hard drives, optical drives, and the like. Though the databases 302 and 312 have the form of a relational database, one of ordinary skill in the art will recognize that each of the databases may also be, by way of example, an object-oriented database, a hierarchical database, a lightweight directory access protocol (LDAP) directory, an object-oriented-relational database, and the like. The databases may conform to any database standard, or may even conform to a non-standard private specification. The databases 302 and 312 may also be implemented utilizing any number of commercially available database products, such as, by way of example, Oracle® from Oracle Corporation, SQL Server and Access from Microsoft Corporation, Sybase® from Sybase, Incorporated, and the like. [0066] The databases 302 and 312 may utilize a relational database management system (RDBMS). In a RDBMS, the data may be stored in the form of tables. Conceptually, data within the table may be stored within fields, which may be arranged into columns and rows. Each field may contain one item of information. Each column within a table may be identified by its column name one type of information, such as a value for a SIFT feature descriptor. For clarity, column names may be illustrated in the tables of FIG. 3. [0067] A record, also known as a tuple, may contain a collection of fields constituting a complete set of information. In one embodiment, the ordering of rows may not matter, as the desired row may be identified by examination of the contents of the fields in at least one of the columns or by a combination of fields. Typically, a field with a unique identifier, such as an integer, may be used to identify a related collection of fields conveniently. [0068] As illustrated in FIG. 3, by way of example, two tables 304 and 306 may be included in the Object Database 302, and one table 314 may be included in the Log Data Storage 312. The exemplary data structures represented by the five tables in FIG. 3 illustrate a convenient way to maintain data such that an embodiment using the data structures can efficiently store and retrieve the data therein. The tables for the Object Database 302 may include a Feature Table 304, and an optional Object Recognition Table 306. [0069] The Feature Table 304 may store data relating to the identification of an object and a view. For example, a view can be characterized by a plurality of features. The Feature Table 304 may include fields for an Object ID, a View ID, a Feature ID for each feature stored, a Feature Coordinates for each feature stored, and a Feature Descriptor associated with each feature stored, view name field, an object name field. The Object ID field and the View ID field may be used to identify the records that correspond to a particular view of a particular object. A view of an object may be typically characterized by a plurality of features. Accordingly, the Feature ID field may be used to identify records that correspond to a particular feature of a view. The View ID field for a record may be used to identify the particular view corresponding to the feature and may be used to identify related records for other features of the view. The Object ID field for a record may used to identify the particular object corresponding to the feature and may be used to identify related records for other views of the object and/or other features associated with the object. The Feature Descriptor field may be used to store visual information about the feature such that the feature may be readily identified when the visual sensor observes the view or object again. The Feature Coordinate field may be used to store the coordinates of the feature. This may provide a reference for calculations that depend at least in part on the spatial relationships between multiple features. An Object Name field may be used to store the name of the object and may be used to store the price of the object. The Feature Table 308 may, optionally, store additional information associated with the object. The View Name field may be used to store the name of the view. For example, it may be convenient to construct a view name by appending a spatial designation to the corresponding object name. As an illustration, if an object name is “Cola 24-Pack,” and the object is packaged in the shape of a box, it may be convenient to name the associated views “Cola 24-Pack Top View,” “Cola 24-Pack Bottom View,” “Cola 24-Pack Front View,” “Cola 24-Pack Back View,” “Cola 24-Pack Left View,” and “Cola 24-Pack Right View.”
[0070] The optional Object Recognition Table 306 may include the Feature Descriptor field, the Object ID field (such as a Universal Product Code), the View ID field, and the Feature ID field. The optional Object Recognition Table 306 may advantageously be indexed by the Feature Descriptor, which may facilitate the matching of observed images to views and/or objects. [0071] The illustrated Log Data Storage 312 includes an Output Table 314. The Output Table 314 may include fields for an Object ID, a View ID, a Camera ID, a Timestamp, and an Image. The system may append records to the Output Table 314 as it recognizes objects during operation. This may advantageously provide a system administrator with the ability to track, log, and report the objects recognized by the system. In one embodiment, when the Output Table 314 receives inputs from multiple visual sensors, the Camera ID field for a record may be used to identify the particular visual sensor associated with the record. The Image field for a record may be used to store the image associated with the record. [0072] FIG. 4 is a flowchart 400 that illustrates a process for recognizing and identifying objects in accordance with one embodiment of the present invention. It will be appreciated by those of the ordinary skill that the illustrated process may be modified in a variety of ways without departing from the spirit and scope of the present invention. For example, in another embodiment, various portions of the illustrated process may be combined, be rearranged in an alternate sequence, be removed, and the like. In addition, it should be noted that the process may be performed in a variety of ways, such as by software executing in a general-purpose computer, by firmware and/or computer readable medium executed by a microprocessor, by dedicated hardware, and the like. [0073] At the start of the process illustrated in FIG. 4, the system 100 has already been trained or programmed to recognize selected objects. [0074] The process may begin in a state 402. In the state 402, a visual sensor, such as a camera, may capture an image of an object to make visual data. In one embodiment, the visual sensor may continuously capture images at a predetermined rate. The process may advance from the state 402 to a state 404. [0075] In the state 404, which is an optional step, two or more consecutive images may be compared to determine if motion of an item has been detected. If motion is detected, the process may proceed to another optional step 406. Otherwise, the visual sensor may capture more images. Motion detection is an optional feature of the system. It is used to limit the amount of computation. If the computer is fast enough, this may not be necessary at all. [0076] In the optional state 406, the process may analyze the visual data acquired in the state 404 to extract visual features. As mentioned above, the process of analyzing the visual data may be performed by a computer 206, a feature extractor 238, a checkout system 268 or a server 274 (shown in FIGS. 2A-C). A variety of visual recognition techniques may be used, and it will be understood by one of ordinary skill in the art that an appropriate visual recognition technique may depend on a variety of factors, such as the visual sensor used and/or the visual features used. In one embodiment, the visual features may be identified using an object recognition process that can identify visual features. In one example, the visual features may correspond to SIFT features. Next, the process may advance from the state 406 to a state 408. [0077] In the state 408, the identified visual features may be compared to visual features stored in a database, such as an Object Database 222. In one embodiment, the comparison may be done using the SIFT method described earlier. The process may find one match, may find multiple matches, or may find no matches. In one embodiment, if the process finds multiple matches, it may, based on one or more measures of the quality of the matches, designate one match, such as the match with the highest value of an associated quality measure, as the best match. Optionally, a match confidence may be associated with a match, wherein the confidence is a variable that is set by adjusting a parameter with a range, such as 0% to 100%, that relates to the fraction of the features that are recognized as matching between the visual data and a particular stored image, or stored set of features. If the match confidence does not exceed a pre-determined threshold, such as a 90% confidence level, the match may not be used. In one embodiment, if the process finds multiple matches with match confidence that exceed the pre-determined threshold, the process may return all such matches. The process may advance from the state 408 to a decision block 410. [0078] In the decision block 410, a determination may be made as to whether the process found a match in the state 408. If the process does not identify a match in the state 408, the process may return to the state 402 to acquire another image. If the process identifies a match in the state 408, the process may proceed to an optional decision block 412. [0079] In the optional decision block 412, a determination may be made as to whether the match found in the state 408 is considered reliable. In one embodiment, when a match is found, the system 100 may optionally wait for one or more extra cycles to compare the matched object from these extra cycles, so that the system 100 can more reliably determine the true object. In one implementation, the system 100 may verify that the matched object is identically recognized for two or more cycles before determining a reliable match. Another implementation may compute the statistical probability that each object that can be recognized is present over several cycles. In another embodiment, a match may be considered reliable if the value of the associated quality measure or associated confidence exceeds a predetermined threshold. In another embodiment, a match may be considered reliable if the number of identified features exceeds a predetermined threshold. In another embodiment, a secondary process, such as matching against a smaller database, may be used to compare this match to any others present. In yet another embodiment, the optional decision block 412 may not be used, and the match may always be considered reliable. [0080] If the optional decision block 412 determines that the match is not considered reliable, the process may return to the state 402 to acquire another image. If the process determines that the match is considered reliable, the process may proceed to a state 414. [0081] In the state 414, the process may send a recognition alert, where the recognition alert may be followed by one or more actions. Exemplary action may be displaying item information on a display monitor of a checkout subsystem, adding the item to a shopping list, sending match data to a checkout subsystem, storing match data into Log Data Storage, or the actions described in connection with FIGS. 1 and 2. [0082] FIG. 5 is a flowchart 500 that illustrates a process for training the system 100 in accordance with one embodiment of the present invention. It will be appreciated by those of ordinary skill that the illustrated process may be modified in a variety of ways without departing from the spirit and scope of the present invention. For example, in another embodiment, various portions of the illustrated process may be combined, be rearranged in an alternate sequence, be removed, and the like. In addition, it should be noted that the process may be performed in a variety of ways, such as by software executing in a general-purpose computer, by firmware and/or computer readable medium executed by a microprocessor, by dedicated hardware, and the like. [0083] The process may begin in a state 502. In the state 502, the process may receive visual data of an item from a visual sensor, such as a camera. As described earlier, it may be convenient, during system training, to use a visual sensor that is not connected to a checkout subsystem positioned near the floor. For example, training images may be captured in a photography studio or on a “workbench,” which may result in higher-quality training images and less physical strain on a human system trainer. The process may advance from the state 502 to a state 504. In one embodiment, the system may receive electronic data from the manufacturer of the item, where the electronic data may include information associated with the item, such as merchandise specifications and visual images. [0084] In the state 504, the process may receive data associated with the image received in the state 502. Data associated with an image may include, for example, the distance between the visual sensor and the object of the image at the time of image capture, may include an object name, may include a view name, may include an object ID, may include a view ID, may include a unique identifier, may include a text string associated with the object of the image, may include a name of a computer file (such as a sound clip, a movie clip, or other media file) associated with the image, may include a price of the object of the image, may include the UPC associated with the object of the image, and may include a flag indicating that the object of the image is a relatively high security-risk item. The associated data may be manually entered, may be automatically generated or retrieved, or a combination of both. For example, in one embodiment, the operator of the system 100 may input all of the associated data manually. In another embodiment, one or more of the associated data items, such as the object ID or the view ID, may be generated automatically, such as sequentially, by the system. In another embodiment, one or more of the associated data items may be generated through another input method. For example, a UPC associated with an image may be inputted using a barcode scanner. [0085] Several images may be taken at different angles or poses with respect to a specific item. Preferably, each face of an item that needs to be recognized should be captured. In one embodiment, all such faces of a given object may be associated with the same object ID, but associated with different view IDs. [0086] Additionally, if an item that needs to be recognized is relatively malleable and/or deformable, such as a bag of pet food or a bag or charcoal briquettes, several images may be taken at different deformations of the item. It may be beneficial to capture a relatively high-resolution image, such as a close-up, of the most visually distinctive regions of the object, such as the product logo. It may also be beneficial to capture a relatively high-resolution image of the least malleable portions of the item. In one embodiment, all such deformations and close-ups captured of a given object may be associated with the same object ID, but associated with different view IDs. The process may advance from the state 504 to a state 506. [0087] In the state 506, the process may store the image received in the state 502 and the associated data collected in the state 504. In one embodiment, the system 100 may store the image and the associated data in a database, which was described earlier in connection with FIGS. 2A-C. The process may advance to a decision block 508. [0088] In the decision block 508, the process may determine whether or not there are additional images to capture. In one embodiment, the system 100 may ask user whether or not there are additional images to capture, and the user's response may determine the action taken by the process. In this embodiment, the query to the user may be displayed on a checkout subsystem and the user may respond via the input devices of the checkout subsystem. If there are additional images to capture, the process may return to the state 502 to receive an additional image. If there are no additional images to capture, the process may proceed to a state 510. [0089] In the state 510, the process may perform a training subprocess on the captured image or images. In one embodiment, the process may scan the database that contains the images stored in the state 506, select images that have not been trained, and run the training subroutine on the untrained images. For each untrained image, the system 100 may analyze the image, find the features present in the image and save the features in the Object Database 222. The process may advance to an optional state 512. [0090] In the optional state 512, the process may delete the images on which the system 100 was trained in the state 510. In one embodiment, the matching process described earlier in connection with FIG. 4 may use the features associated with a trained image and may not use the actual trained image. Advantageously, deleting the trained images may reduce the amount of disk space or memory required to store the Object Database. Then, the process may end and be repeated as desired. [0091] In one embodiment, the system may be trained prior to its initial use, and additional training may be performed repeatedly. It will be understood that the number of training images acquired in different training cycles may vary in a wide range. [0092] As described above, embodiments of the system and method may advantageously permit one or more visual sensors, such as one or more cameras, operatively coupled to a computer system to view and recognize items located on, for example, the lower shelf of a shopping cart in the checkout lane of a retail store environment. These techniques can advantageously be used for the purpose of reducing or preventing loss or fraud. [0093] It should be understood, of course, that the foregoing relates to exemplary embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4929819 *Dec 12, 1988May 29, 1990Ncr CorporationMethod and apparatus for customer performed article scanning in self-service shoppingUS5115888 *Feb 4, 1991May 26, 1992Howard SchneiderSelf-serve checkout systemUS5495097 *Sep 14, 1993Feb 27, 1996Symbol Technologies, Inc.Plurality of scan units with scan stitchingUS5543607 *Nov 14, 1994Aug 6, 1996Hitachi, Ltd.Self check-out system and POS systemUS5609223 *May 30, 1995Mar 11, 1997Kabushiki Kaisha TecCheckout system with automatic registration of articles by bar code or physical feature recognitionUS5883968 *Feb 9, 1996Mar 16, 1999Aw Computer Systems, Inc.System and methods for preventing fraud in retail environments, including the detection of empty and non-empty shopping cartsUS5967264 *May 1, 1998Oct 19, 1999Ncr CorporationMethod of monitoring item shuffling in a post-scan area of a self-service checkout terminalUS6069696 *Jun 7, 1996May 30, 2000Psc Scanning, Inc.Object recognition system and methodUS6179206 *Dec 7, 1998Jan 30, 2001Fujitsu LimitedElectronic shopping system having self-scanning price check and purchasing terminalUS6236736 *Feb 6, 1998May 22, 2001Ncr CorporationMethod and apparatus for detecting movement patterns at a self-service checkout terminalUS6332573 *Nov 10, 1998Dec 25, 2001Ncr CorporationProduce data collector and produce recognition systemUS6363366 *Aug 31, 1998Mar 26, 2002David L. HentyProduce identification and pricing system for checkoutsUS6550583 *Aug 21, 2000Apr 22, 2003Optimal Robotics Corp.Apparatus for self-serve checkout of large order purchasesUS6598791 *Jan 19, 2001Jul 29, 2003Psc Scanning, Inc.Self-checkout system and method including item buffer for item security verificationUS6606579 *Aug 16, 2000Aug 12, 2003Ncr CorporationMethod of combining spectral data with non-spectral data in a produce recognition systemUS6915008 *Mar 8, 2002Jul 5, 2005Point Grey Research Inc.Method and apparatus for multi-nodal, three-dimensional imagingUS7044370 *Jul 1, 2002May 16, 2006Ecr Software CorporationCheckout system with a flexible security verification systemUS7246745 *Feb 2, 2005Jul 24, 2007Evolution Robotics Retail, Inc.Method of merchandising for checkout lanesUS7337960 *Feb 28, 2005Mar 4, 2008Evolution Robotics, Inc.Systems and methods for merchandise automatic checkoutUS7477780 *Nov 5, 2002Jan 13, 2009Evryx Technologies, Inc.Image capture and identification system and processUS20020138374 *Feb 11, 2002Sep 26, 2002Jennings Andrew JohnItem recognition method and apparatusUS20030184440 *Mar 28, 2002Oct 2, 2003Ballantyne William JohnMethod and apparatus for detecting items on the bottom tray of a cartUS20050060324 *Nov 13, 2003Mar 17, 2005Jerry JohnsonSystem and method for creation and maintenance of a rich content or content-centric electronic catalogUS20050173527 *Feb 11, 2004Aug 11, 2005International Business Machines CorporationProduct checkout system with anti-theft deviceUS20060118627 *Dec 8, 2004Jun 8, 2006Eugene JosephPulsed illumination in imaging readerUS20090152348 *Feb 29, 2008Jun 18, 2009Jim OstrowskiSystems and methods for merchandise automatic checkout* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7660747Dec 1, 2005Feb 9, 2010Media Cart Holdings, Inc.Media enabled shopping cart system with point of sale identification and methodUS7679522Mar 26, 2007Mar 16, 2010Media Cart Holdings, Inc.Media enhanced shopping systems with electronic queuingUS7714723Mar 25, 2007May 11, 2010Media Cart Holdings, Inc.RFID dense reader/automatic gain controlUS7741808Mar 25, 2007Jun 22, 2010Media Cart Holdings, Inc.Bi-directional charging/integrated power management unitUS7762458 *Mar 25, 2007Jul 27, 2010Media Cart Holdings, Inc.Media enabled shopping system user interfaceUS7782194Mar 25, 2007Aug 24, 2010Media Cart Holdings, Inc.Cart coordinator/deployment managerUS7839284Oct 5, 2007Nov 23, 2010Oossite Technologies Inc.Monitoring of shopping cart bottom trayUS7883012Oct 17, 2006Feb 8, 2011Datalogic Scanning, Inc.Integrated data reader and bottom-of-basket item detectorUS7909248Aug 18, 2008Mar 22, 2011Evolution Robotics Retail, Inc.Self checkout with visual recognitionUS7934647 *Jan 22, 2010May 3, 2011Darla MimsIn-cart grocery tabulation system and associated methodUS8068674 *Sep 4, 2007Nov 29, 2011Evolution Robotics Retail, Inc.UPC substitution fraud preventionUS8146811 *Mar 12, 2008Apr 3, 2012Stoplift, Inc.Cart inspection for suspicious itemsUS8165349Nov 29, 2008Apr 24, 2012International Business Machines CorporationAnalyzing repetitive sequential eventsUS8196822Mar 21, 2011Jun 12, 2012Evolution Robotics Retail, Inc.Self checkout with visual recognitionUS8430311Feb 29, 2008Apr 30, 2013Datalogic ADC, Inc.Systems and methods for merchandise automatic checkoutUS8430312 *Apr 2, 2012Apr 30, 2013Stoplift, Inc.Cart inspection for suspicious itemsUS8448859Sep 4, 2009May 28, 2013Datalogic ADC, Inc.System and method for preventing cashier and customer fraud at retail checkoutUS8459558Jul 8, 2010Jun 11, 2013Wincor Nixdorf International GmbhDevice and method for optically scanning a machine-readable markingUS8474715Jun 11, 2012Jul 2, 2013Datalogic ADC, Inc.Self checkout with visual recognitionUS8494909 *Feb 9, 2010Jul 23, 2013Datalogic ADC, Inc.Automatic learning in a merchandise checkout system with visual recognitionUS8590789Sep 14, 2011Nov 26, 2013Metrologic Instruments, Inc.Scanner with wake-up modeUS8627946Feb 21, 2012Jan 14, 2014Wincor Nixdorf International GmbhDevice for detecting itemsUS8638380 *May 4, 2012Jan 28, 2014Toshiba Global CommerceLocation-aware event detectionUS8740085Feb 10, 2012Jun 3, 2014Honeywell International Inc.System having imaging assembly for use in output of image dataUS8886559Oct 7, 2010Nov 11, 2014Wincor Nixdorf International GmbhMobile product detecting system and method thereforUS8960409Feb 21, 2012Feb 24, 2015Wincor Nixdorf International GmbhTransport unit and method of operating sameUS9064161Jun 8, 2007Jun 23, 2015Datalogic ADC, Inc.System and method for detecting generic items in image sequenceUS9152828May 28, 2013Oct 6, 2015Datalogic ADC, Inc.System and method for preventing cashier and customer fraud at retail checkoutUS9165173 *May 29, 2013Oct 20, 2015Ncr CorporationSecurity method using an imaging barcode readerUS9208620Sep 3, 2009Dec 8, 2015Stamps.Com, Inc.Systems and methods for payment of postage indicia after the point of generationUS9299229Nov 29, 2008Mar 29, 2016Toshiba Global Commerce Solutions Holdings CorporationDetecting primitive events at checkoutUS9477955 *Jul 22, 2013Oct 25, 2016Datalogic ADC, Inc.Automatic learning in a merchandise checkout system with visual recognitionUS9595029Oct 4, 2013Mar 14, 2017Ecr Software CorporationSystem and method for self-checkout, scan portal, and pay station environmentsUS20070080219 *Sep 28, 2006Apr 12, 2007Garver Roy AFixed self-checkout station with cradle for communicating with portable self-scanning unitsUS20070084918 *Oct 17, 2006Apr 19, 2007Psc Scanning, Inc.Integrated data reader and bottom-of-basket item detectorUS20080088444 *Oct 5, 2007Apr 17, 2008Rosebush Paul SMonitoring of shopping cart bottom trayUS20080226129 *Mar 12, 2008Sep 18, 2008Malay KunduCart Inspection for Suspicious ItemsUS20080230603 *Mar 25, 2007Sep 25, 2008Media Cart Holdings, Inc.Media enabled shopping system user interfaceUS20090060259 *Sep 4, 2007Mar 5, 2009Luis GoncalvesUpc substitution fraud preventionUS20090152348 *Feb 29, 2008Jun 18, 2009Jim OstrowskiSystems and methods for merchandise automatic checkoutUS20100030685 *Jul 30, 2008Feb 4, 2010Bobbitt Russell PTransaction analysisUS20100114623 *Oct 31, 2008May 6, 2010International Business Machines CorporationUsing detailed process information at a point of saleUS20100134624 *Nov 29, 2008Jun 3, 2010International Business Machines CorporationDetecting primitive events at checkoutUS20100135528 *Nov 29, 2008Jun 3, 2010International Business Machines CorporationAnalyzing repetitive sequential eventsUS20100217678 *Feb 9, 2010Aug 26, 2010Goncalves Luis FAutomatic learning in a merchandise checkout system with visual recognitionUS20110215147 *Mar 21, 2011Sep 8, 2011Evolution Robotics Retail, Inc.Self checkout with visual recognitionUS20120048921 *Aug 29, 2011Mar 1, 2012Toshiba Tec Kabushiki KaishaCode reading apparatus and sales registration apparatusUS20120188377 *Apr 2, 2012Jul 26, 2012Malay KunduCart inspection for suspicious itemsUS20120218414 *May 4, 2012Aug 30, 2012International Business Machines CorporationLocation-Aware Event DetectionUS20130304595 *Jul 22, 2013Nov 14, 2013Datalogic ADC, Inc.Automatic learning in a merchandise checkout system with visual recognitionUS20140353382 *May 29, 2013Dec 4, 2014Ncr CorporationSecurity method using an imaging barcode readerWO2008077580A1 *Dec 20, 2007Jul 3, 2008Walter Steven RosenbaumSystem and method for detecting fraudulent transactions of items having item-identifying indiciaWO2011038849A1 *Sep 21, 2010Apr 7, 2011Wincor Nixdorf International GmbhSystem for a self-service product detection station and method for said system* Cited by examinerClassifications U.S. Classification235/383, 235/454International ClassificationG08B13/196, A47F9/04, G07F7/02, G08B13/194, G07G1/00, G07G3/00, G06K15/00, G06K7/10Cooperative ClassificationG07G1/0063, G07G3/003, A47F9/045, G07F7/02, G08B13/19671, G07G3/00, G08B13/1961, G07G1/0036, G06Q20/343European ClassificationG07G1/00C2D2, G07F7/02, G07G1/00C, A47F9/04C, G08B13/196S3, G08B13/196A4, G07G3/00, G06Q20/343, G07G3/00BLegal EventsDateCodeEventDescriptionAug 14, 2012ASAssignmentOwner name: DATALOGIC ADC, INC., OREGONFree format text: MERGER;ASSIGNOR:EVOLUTION ROBOTICS RETAIL, INC.;REEL/FRAME:028782/0048Effective date: 20120601Owner name: EVOLUTION ROBOTICS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OSTROWSKI, JIM;GONCALVES, LUIS;CREMEAN, MICHAEL;AND OTHERS;REEL/FRAME:028782/0004Effective date: 20041221Owner name: EVOLUTION ROBOTICS RETAIL, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EVOLUTION ROBOTICS, INC.;REEL/FRAME:028782/0033Effective date: 20051230Mar 9, 2016FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services