DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1 and 4-18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 4-18 are rejected under 35 U.S.C. 103 as being unpatentable over Carter et al. (U.S. Patent Application Publication 2021/0287013) in view of Milojevic et al. (U.S. Patent 11,989,763) in view of Brakob et al. (U.S. Patent Application Publication 2023/0004978).
Regarding claim 1, Carter et al. discloses a store exit management system comprising: at least one memory configured to store instructions (paragraph [0260] – the various processors and other computing devices of the system described herein operate collectively as a computing system, preferably under the control of executable program instructions stored on non-volatile memory devices and/or other types of non-transitory storage devices); and at least one processor (paragraph [0260] – a processor may be a microprocessor, a controller, microcontroller, state machine, graphics processor, tensor processor, combinations of the same, or the like – a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors or processor cores, one or more graphics or stream processors, one or more microprocessors in conjunction with a DSP, or any other such configuration - the various processors and other computing devices of the system described herein operate collectively as a computing system, preferably under the control of executable program instructions stored on non-volatile memory devices and/or other types of non-transitory storage devices) configured to execute the instructions to: acquire a payment completion code when a product was registered and paid for (Fig. 19; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy; paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records); acquire a quantity of a payment completion product associated with the payment completion code (paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items); estimate, from an image obtained by imaging goods of the customer leaving a store, a quantity of a product to be taken out by the customer (Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents); detect an abnormality based on the acquired quantity of the payment completion product and the estimated quantity of the product to be taken out (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750)); and output information indicating that the abnormality is detected (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750) – various other types of anti-theft actions may be additionally or alternatively be performed – for example, if a transaction record is found that nearly matches the record of cart contents, but one or more high priced (or high theft risk) items imaged in the cart are missing from the transaction record, the system may prompt store personnel to check the customer’s cart and receipt for the high priced item(s)). However, Carter et al. fails to disclose acquiring a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal; wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and output a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Milojevic et al. reference, Milojevic et al. discloses a store exit management system comprising: a least one processor configured to execute the instructions to: acquire a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal (Figs. 3 and 5; col. 3, lines 57-60 – at block 66, the user device 30 generates a mobile checkout list 23, which may be displayed on the display 32 of the user device 30 based upon the collected mobile checkout image data 37; col 4, lines 1-2 – the user device 30 processes payment based upon the mobile checkout list 23 (Block 68); col. 4, lines 21-37 – the self-checkout verification station 40, at block 84, obtains the mobile checkout list 23 from the user device – moreover, the self-checkout verification station 40 may obtain the mobile checkout list 23 based upon scanning or based upon an identifier displayed on the display 32 of the user device 30 (e.g., a QR code displayed as a confirmation of payment processing), that may be scanned by a camera 43 coupled to the controller 41 of the self-checkout verification station).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had acquired a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal as disclosed by Milojevic et al. in the system disclosed by Carter et al. in order to provide staff or computers at an exit of the retailer store to be able to easily verify that the products being removed from the store have in fact been purchased. However, Carter et al. in view of Milojevic et al. still fails to disclose wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and output a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Brakob et al. reference, Brakob et al. discloses a store exit management system comprising: wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value (Figs. 3 and 4; paragraph [0099] – using one or more of the selected rules, the computer system can determine whether the structured data indicates a benign incident in 404 – for example, rules associated with a first location can identify a security event only when a certain quantity of items are stolen by a shopper – if the computer system determines, from the structured data, that the shopper did not meet the quantity of items threshold, then the computer system can determine that the structured data represents a benign incident for that first location (even if, in a different location, the quantity of items stolen by the shopper may indicate a security event) – in such a case, the process 400 can stop; paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident); based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product (paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend); and output a notification indicating that the abnormality is detected at the determined notification level (paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had outputted a notification indicating that the abnormality is detected at the determined notification level as disclosed by Brakob et al. in the system disclosed by Carter et al. in view of Milojevic et al. in order to alert the proper authorities as determined based on the severity of the crime being committed.
Regarding claim 4, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: detect the abnormality in a case where the estimated quantity of the product to be taken out is larger than the quantity of the payment completion product (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items – if no corresponding payment transaction is found, of if a significant discrepancy is detected (e.g., one or more high price items were detected in the cart but are not included in the partially-matching transaction record), an appropriate anti-theft action can be initiated; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s)[ processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); thresholds are implied in the Carter et al. reference, which will distinguish between a minor discrepancy and a significant discrepancy; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy; the threshold in Milojevic et al. is zero, any discrepancy will create a notification).
Regarding claim 5, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: detect the abnormality in a case where the estimated quantity of the product to be taken out is smaller than the quantity of the payment completion product (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items – if no corresponding payment transaction is found, of if a significant discrepancy is detected (e.g., one or more high price items were detected in the cart but are not included in the partially-matching transaction record), an appropriate anti-theft action can be initiated; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); thresholds are implied in the Carter et al. reference, which will distinguish between a minor discrepancy and a significant discrepancy; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy; the threshold in Milojevic et al. is zero, any discrepancy will create a notification).
Regarding claim 6, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the quantity of the payment completion product is a volume of the payment completion product, and the quantity of the product to be taken out is a volume of the product to be taken out (Carter et al.: Figs. 13, 17, and 19; paragraph [0115] – the load status may represent a range of values associated with an amount of the load of the shopping basket – for example, the range may be a number (e.g., 1 to 5, with 1 empty and 5 fully loaded), a grade (e.g., A to E, where A represents fully loaded and E represents empty), or some other type of score, discriminative or semantic classifier, or probability scaling for a plurality of load levels (e.g., full, ¾ full, ½ full, ¼ full, or empty) – the load status can include a weighted score or value that accounts for the amount of the load as well as an estimate of the value of the load; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents; paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records – the estimated physical volume of the merchandise paid for).
Regarding claim 7, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the quantity of the payment completion product is the number of the payment completion products, and the quantity of the product to be taken out is the number of the products to be taken out (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy).
Regarding claim 8, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: estimate the quantity of the product to be taken out from the image obtained by imaging the goods of the customer leaving the store and an image obtained by imaging goods of the customer before holding the product to be taken out (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0194] – as depicted by block 1310, the camera module 217 may enable its camera/imager 217B in response to the shopping cart entering the store, and may then capture an initial image – in block 1320, the camera module waits for a triggering event representing the possible addition of a merchandise item to the cart’s basket; paragraph [0195] – in response to a triggering event, the camera module 217 captures an image of the basket contents (block 1330) and compares this image to the most recently captured image (block 1340) – based on the comparison or difference operation, the process determines whether a new item has likely been added to the basket (block 1350); paragraph [0196] – the process may then wait for the next trigger event - the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records).
Regarding claim 9, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: control a store exit gate through which the customer leaving the store passes to make the store exit gate impassable in a case where the abnormality is detected (Carter et al.: paragraph [0062] – in some embodiments, the store may utilize a checkout barrier (CB) located at the end of a checkout lane, at the store exit (as illustrated in Fig. 1C), in areas with high value goods, etc. A CB generally includes a gate, barrier, or turnstile that is locked unless a customer is permitted to exit the checkout lane or the store or the high value area (e.g., the customer has paid for the goods) – the CB can then be unlocked to permit the customer to exit (e.g., by pushing against the gate which swings open to permit passage) – after exit, the gate swings closed and locks to prevent other customers from leaving without payment – a CB may be in communication with the store’s CCU, CVUs, CTUs, checkout registers, mobile payment points 35, etc. in order to receive a command to unlock the barrier (or to lock the barrier); paragraph [0204] – if the cart eventually approaches a store exit without any indication of a payment event, the item classifications collected over the course of the shopping session may be used in various ways to determine whether to perform an anti-theft action and/or to select one or more particular anti-theft actions to perform (e.g., wheel lock, activation of store alarm, activation of exit barrier, etc.)).
Regarding claim 10, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: output the number of the payment completion products to a notification device in response to acquisition of the payment completion code (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy).
Regarding claim 11, Carter et al. discloses a store exit management method comprising: acquiring a payment completion code when a product was registered and paid for (Fig. 19; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy; paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records); acquiring a quantity of a payment completion product associated with the payment completion code (paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items); estimating, from an image obtained by imaging goods of the customer leaving a store, a quantity of a product to be taken out by the customer (Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents); detecting an abnormality based on the acquired quantity of the payment completion product and the estimated quantity of the product to be taken out (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750)); and outputting information indicating that the abnormality is detected (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750) – various other types of anti-theft actions may be additionally or alternatively be performed – for example, if a transaction record is found that nearly matches the record of cart contents, but one or more high priced (or high theft risk) items imaged in the cart are missing from the transaction record, the system may prompt store personnel to check the customer’s cart and receipt for the high priced item(s)). However, Carter et al. fails to disclose acquiring a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal; wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and outputting a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Milojevic et al. reference, Milojevic et al. discloses a store exit management method comprising: acquiring a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal (Figs. 3 and 5; col. 3, lines 57-60 – at block 66, the user device 30 generates a mobile checkout list 23, which may be displayed on the display 32 of the user device 30 based upon the collected mobile checkout image data 37; col 4, lines 1-2 – the user device 30 processes payment based upon the mobile checkout list 23 (Block 68); col. 4, lines 21-37 – the self-checkout verification station 40, at block 84, obtains the mobile checkout list 23 from the user device – moreover, the self-checkout verification station 40 may obtain the mobile checkout list 23 based upon scanning or based upon an identifier displayed on the display 32 of the user device 30 (e.g., a QR code displayed as a confirmation of payment processing), that may be scanned by a camera 43 coupled to the controller 41 of the self-checkout verification station).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had acquired a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal as disclosed by Milojevic et al. in the method disclosed by Carter et al. in order to provide staff or computers at an exit of the retailer store to be able to easily verify that the products being removed from the store have in fact been purchased. However, Carter et al. in view of Milojevic et al. still fails to disclose wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and outputting a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Brakob et al. reference, Brakob et al. discloses a store exit management method comprising: wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value (Figs. 3 and 4; paragraph [0099] – using one or more of the selected rules, the computer system can determine whether the structured data indicates a benign incident in 404 – for example, rules associated with a first location can identify a security event only when a certain quantity of items are stolen by a shopper – if the computer system determines, from the structured data, that the shopper did not meet the quantity of items threshold, then the computer system can determine that the structured data represents a benign incident for that first location (even if, in a different location, the quantity of items stolen by the shopper may indicate a security event) – in such a case, the process 400 can stop; paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident); based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product (paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend); and outputting a notification indicating that the abnormality is detected at the determined notification level (paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had outputted a notification indicating that the abnormality is detected at the determined notification level as disclosed by Brakob et al. in the method disclosed by Carter et al. in view of Milojevic et al. in order to alert the proper authorities as determined based on the severity of the crime being committed.
Regarding claim 12, Carter et al. discloses a recording medium that non-transiently records a program for causing a computer to execute the steps of: acquiring a payment completion code when a product was registered and paid for (Fig. 19; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy; paragraph [0211] – Fig. 19 illustrates the types of data records that may be generated and used in the process of Fig. 17 – the top block in Fig. 19 shows an example of an anonymized and augmented transaction record generated by the payment transaction anonymizing system 1820 for a given transaction – further, in some embodiments, the comparisons may be performed using actual transaction records rather than anonymized records); acquiring a quantity of a payment completion product associated with the payment completion code (paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items); estimating, from an image obtained by imaging goods of the customer leaving a store, a quantity of a product to be taken out by the customer (Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents); detecting an abnormality based on the acquired quantity of the payment completion product and the estimated quantity of the product to be taken out (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750)); and outputting information indicating that the abnormality is detected (Figs. 17 and 19; paragraph [0209] - in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750) – various other types of anti-theft actions may be additionally or alternatively be performed – for example, if a transaction record is found that nearly matches the record of cart contents, but one or more high priced (or high theft risk) items imaged in the cart are missing from the transaction record, the system may prompt store personnel to check the customer’s cart and receipt for the high priced item(s)). However, Carter et al. fails to disclose acquiring a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal; wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and outputting a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Milojevic et al. reference, Milojevic et al. discloses a store exit management method comprising: acquiring a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal (Figs. 3 and 5; col. 3, lines 57-60 – at block 66, the user device 30 generates a mobile checkout list 23, which may be displayed on the display 32 of the user device 30 based upon the collected mobile checkout image data 37; col 4, lines 1-2 – the user device 30 processes payment based upon the mobile checkout list 23 (Block 68); col. 4, lines 21-37 – the self-checkout verification station 40, at block 84, obtains the mobile checkout list 23 from the user device – moreover, the self-checkout verification station 40 may obtain the mobile checkout list 23 based upon scanning or based upon an identifier displayed on the display 32 of the user device 30 (e.g., a QR code displayed as a confirmation of payment processing), that may be scanned by a camera 43 coupled to the controller 41 of the self-checkout verification station).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had acquired a payment completion code from a portable terminal operated by a customer when a product was registered and paid for through the portable terminal as disclosed by Milojevic et al. in the method disclosed by Carter et al. in order to provide staff or computers at an exit of the retailer store to be able to easily verify that the products being removed from the store have in fact been purchased. However, Carter et al. in view of Milojevic et al. still fails to disclose wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value; based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product; and outputting a notification indicating that the abnormality is detected at the determined notification level.
Referring to the Brakob et al. reference, Brakob et al. discloses a store exit management method comprising: wherein the abnormality is detected in a case where a difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product exceeds a threshold value (Figs. 3 and 4; paragraph [0099] – using one or more of the selected rules, the computer system can determine whether the structured data indicates a benign incident in 404 – for example, rules associated with a first location can identify a security event only when a certain quantity of items are stolen by a shopper – if the computer system determines, from the structured data, that the shopper did not meet the quantity of items threshold, then the computer system can determine that the structured data represents a benign incident for that first location (even if, in a different location, the quantity of items stolen by the shopper may indicate a security event) – in such a case, the process 400 can stop; paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident); based on the abnormality being detected, determine a notification level based on the difference between the estimated quantity of the product to be taken out and the quantity of the payment completion product (paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend); and outputting a notification indicating that the abnormality is detected at the determined notification level (paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had outputted a notification indicating that the abnormality is detected at the determined notification level as disclosed by Brakob et al. in the method disclosed by Carter et al. in view of Milojevic et al. in order to alert the proper authorities as determined based on the severity of the crime being committed.
Regarding claim 13, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: determine a first notification level if the difference is smaller than a predetermined value (Brakob et al.: Fig. 4; paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend); and determine a second notification level higher than the first notification level if the difference is equal to or larger than the predetermined value (Brakob et al.: Fig. 4; paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Regarding claim 14, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: based on the determined notification level (Brakob et al.: Fig. 4; paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend). However, Carter et al. in view of Milojevic et al. in view of Brakob et al. fails to explicitly disclose outputting the notification in different colors based on the determined notification level. Official Notice is taken that both the concept and advantages of outputting the notification in different colors based on the determined notification levels are both well-known in the art. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have had outputted the notification in different colors based on the determined notification level in the system disclosed by Carter et al. in view of Milojevic et al. in order to easily determine and recognize the threat level.
Regarding claim 15, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: adjust the threshold value using at least one of estimation accuracy of the quantity of the product to be taken out, congestion level of the store, or a past abnormality detection history of the customer (Brakob et al.: (paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Regarding claim 16, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claim 1 including that wherein the at least one processor is further configured to execute the instructions to: determine that the abnormality corresponds to unauthorized taking out of unpaid products in a case where the estimated quantity of the product to be taken out is larger than the quantity of the payment completion products; determine that the abnormality corresponds to leaving behind of paid products in a case where the estimated quantity of the product to be taken out is smaller than the quantity of the payment completion products; and output the notification to different notification devices based on the determination (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items – if no corresponding payment transaction is found, of if a significant discrepancy is detected (e.g., one or more high price items were detected in the cart but are not included in the partially-matching transaction record), an appropriate anti-theft action can be initiated; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); thresholds are implied in the Carter et al. reference, which will distinguish between a minor discrepancy and a significant discrepancy; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy; the threshold in Milojevic et al. is zero, any discrepancy will create a notification; Brakob et al.: paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Regarding claim 17, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claims 1 and 16 including that wherein the at least one processor is further configured to execute the instructions to: output the notification to a notification device for store staff in a case where the estimated quantity of the product to be taken out is larger than the quantity of the payment completion product; and output the notification to a notification device for the customer in a case where the estimated quantity of the product to be taken out is smaller than the quantity of the payment completion product (Carter et al.: Figs. 13, 17, and 19; paragraph [0193] – Fig. 13 illustrates a process that may be implemented by a camera module 217 to capture, pre-process, and upload images of cart contents; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store; paragraph [0205] – a more sophisticated method may involve scoring the cart in terms of overall theft risk – for example, a score can be generated by summing the item prices of any detected high risk items, or by counting the number of detected high theft risk items; paragraph [0208] – in embodiments in which the system builds a record of data describing the imaged items detected in the cart basket (e.g., number of items detected, product categories of these items, product IDs where products are identifiable, etc.), the system can compare this record to associated payment/checkout transaction to assess whether the customer has paid for all of the items – if no corresponding payment transaction is found, of if a significant discrepancy is detected (e.g., one or more high price items were detected in the cart but are not included in the partially-matching transaction record), an appropriate anti-theft action can be initiated; paragraph [0209] – in blocks 1720 and 1730, the system acquires the cart’s path history, compares it checkout point locations to identify a payment point passed by the cart, and looks up the most recent payment transaction(s) processed by the payment point – in some cases, the payment transactions may be anonymized and/or summarized to protect customer privacy – in block 1740, the process determines whether any of these payment transactions “match” the record of cart contents – minor discrepancies may be disregarded for purposes of determining whether a match is found – if no match is found (indicating that the customer likely did not pay for items in the cart), the cart may be prevented from exiting the store (block 1750); thresholds are implied in the Carter et al. reference, which will distinguish between a minor discrepancy and a significant discrepancy; Milojevic et al.: col. 1, lines 45-56 – a self-checkout verification system may include a user device configured to collect user mobile checkout image data from a plurality of products to be purchased in a store during a mobile checkout process, generate a mobile checkout list of the plurality of products to be purchased based upon the collected mobile checkout image data, and process payment based upon the mobile checkout list – the self-checkout verification system may also include a self-checkout verification station in the store and configured to obtain the mobile checkout list from the user device, and collect verification image data from a plurality of products presented for verification – the self-checkout verification station may further be configured to generate a verification list based upon the verification image data, determine a discrepancy between the verification list and the mobile checkout list, and generate and communicate a notification based upon the discrepancy; the threshold in Milojevic et al. is zero, any discrepancy will create a notification; Brakob et al.: paragraph [0100] – if, on the other hand, the computer system determines that the structured data does not represent a benign incident (e.g., the shopper stole more than the quantity of items threshold associated with the first location), then the computer system can proceed to 406 – thus, the computer system can determine in 404 that the structured data represents a security event; paragraph [0101] – in 406, the computer system can determine whether the incident satisfies one or more alerting rule(s) – the alerting rule(s) can be specific to the location that is associated with the structured data – some locations may require multiple alerting rules to be satisfied before the computer system can alert about the incident; paragraph [0102] – the one or more alerting rule(s) can include whether a quantity of solen items is greater than a threshold value (408) – this alerting rule can also indicate different quantity of stolen items based on price of such items and/or type of such items; paragraph [0103] – another alerting rule can be whether a dollar amount of the stolen items is greater than a threshold value (410) – for example, the dollar amount of the stolen items can be different based on quantity of items stolen and/or type of items stolen; paragraph [0104] – another alerting rule can be type of stolen items (412) – the types of stolen items can include electronics, produce, frozen goods, groceries, clothes, office supplies, furniture, baby clothes, toys, books, kitchenware, appliances, sports, etc. – the types of stolen items can also include sub-types, such as vegetables, fruits, bread, meats, and fish for groceries and TVs, headphones, chargers cables, and batteries for electronics; paragraph [0105] – yet another alerting rule can be type of incident (414) – such a rule can be based on location as well as whether safety and security personnel would actually respond to the incident – for example, law enforcement may only respond to theft if it rises from a felony to a crime; paragraph [0106] – another alerting rule can be based on prior history of incident(s) (416); paragraph [0107] – one or more additional or fewer alerting rules can be used by the computer system in 406; paragraph [0108] – if the computer system determines that the incident satisfies one or more or any of the alerting rule(s) that are used in 406-416, then the computer system can alert appropriate parties in 418 – for example, some of the alerting rules may require alerting in-store employees at the store but not law enforcement – some of the alerting rules may require alerting law enforcement but not the in-store employees – some of the alerting rules may require alerting both law enforcement and in-store employees – in yet some implementations, some of the alerting rules may require alerting other relevant stakeholders in the store and/or an enterprise that operates the store – for example, some of the alerting rules may require alerting in-store employees and/or law enforcement in other locations where stores of the same enterprise are located – as a result, parties in the other locations can become aware of potential shoppers to look out for and/or apprehend).
Regarding claim 18, Carter et al. in view of Milojevic et al. in view of Brakob et al. discloses all of the limitations as previously discussed with respect to claims 1 and 8 including that wherein the at least one processor is further configured to execute the instructions to: estimate the quantity of the product to be taken out by: acquiring an image obtained by imaging personal belongings brought by the customer when entering the store before holding the product to be taken out; acquiring the image obtained by imaging goods of the customer leaving the store; and comparing the acquired images to distinguish between personal belongings and the product to be taken out (Carter et al.: Fig. 13; paragraph [0194] – as depicted by block 1310, the camera module 217 may enable its camera/imager 217B in response to the shopping cart entering the store, and may then capture an initial image – any items in the cart at this point will be ordinarily be non-merchandise items, such as purse, reusable shopping bag, backpack, or child – in block 1320, the camera module waits for a triggering event representing the possible addition of a merchandise item to the cart’s basket; paragraph [0195] – in response to a triggering event, the camera module 217 captures an image of the basket contents (block 1330) and compares this image to the most recently captured image (block 1340) – based on the comparison or difference operation, the process determines whether a new item has likely been added to the basket (block 1350) – if a new item is detected, the image – optionally marked to show the region of the newly added item – is uploaded to a CVU or other node for further analysis, preferably together with event metadata for the capture event; paragraph [0196] – the process shown in Fig. 13 may continue until, e.g., the shopping cart passes through an active checkout area or exits the store).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEATHER R JONES whose telephone number is (571)272-7368. The examiner can normally be reached Mon. - Fri.: 9:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Vaughn can be reached at (571)272-3922. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEATHER R JONES/Primary Examiner, Art Unit 2481
March 10, 2026