A supermarket self-checkout loss prevention method based on incorrect and missed scanning behavior analysis

Abstract

The present application relates to the technical field of self-checkout terminal transaction detection and control, and particularly relates to a supermarket self-checkout loss prevention method based on wrong scanning and missing scanning behavior analysis. The method comprises the following steps: receiving a transaction session identifier, barcode decoding data, SKU reference weight interval and weight sampling data, generating a to-be-matched scanning event and weight step event and writing into a transaction event context; determining an event correlation time range based on a scanning interval sequence and a weight stable time length, screening time candidate scanning events and weight compatible candidate scanning events; establishing one-to-one association according to a candidate set state, or generating a missing scanning suspicion record, a wrong scanning suspicion record and an association uncertainty record, and writing into a transaction control state; receiving a review operation update event correlation state, and generating a transaction recovery result when a recovery condition is met. The present application reduces repeated attribution and product misplacement in the asynchronous period of continuous scanning and bagging through hierarchical candidate screening, one-to-one association and state write-back.

Description

Technical Field

[0001] This invention relates to the field of transaction detection and control technology for self-service checkout terminals, and in particular to a loss prevention method for supermarket self-service checkout based on the analysis of incorrect or missed scan behavior. Background Technology

[0002] In the field of self-checkout terminal technology, existing solutions typically read product barcode information through scanning devices, obtain product weight information from product master data, and collect weight data through weighing sensors in the bagging area. Some solutions compare the weighing result after scanning the product with a preset weight, and suspend the transaction, restrict payment, or notify staff when the weights do not match. Other solutions use camera devices to identify the scanning and placement actions of the product, and check whether barcode information has been received within the corresponding operation time period.

[0003] Existing weight-based verification solutions often employ a sequential processing approach, waiting for a weight change after scanning each item, or using a fixed time range to associate scan records with weighing results. When customers scan multiple items consecutively and then place them in the bag, or when there is a time delay between scanning and bagging operations, multiple scan records and multiple weight changes may exist simultaneously within the same transaction session. A fixed sequential correspondence or a fixed time range makes it difficult to distinguish the scan record corresponding to the current weight change, easily leading to the reuse of the same scan record, misalignment of item correspondences, and weight changes remaining unassigned for extended periods.

[0004] Existing visual recognition solutions can segment product operation time periods based on images, but they rely on camera equipment and image processing. In self-checkout terminals that only use barcode decoding data and bagging area weight data, there is no direct action boundary between scan records and weight changes. After anomaly verification, some existing solutions mainly update the prompt status or transaction lock status, but the corresponding status between the original scan record and weight change is not updated synchronously, and subsequent product processing may still be affected by the existing anomaly status. Therefore, it is necessary to solve the problem that when continuous barcode scanning and bagging occur asynchronously in self-checkout, it is difficult to match multiple scan records with multiple weight changes and form a correlation result of misscanning and missed scanning events. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a loss prevention method for supermarket self-checkout based on the analysis of incorrect and missed scan behaviors, comprising:

[0006] S100: Receive transaction session identifier, barcode decoding data, SKU baseline weight range, and weight sampling data; bind the barcode decoding data with the product SKU, scanning time, and baseline weight range to generate a matching scanning event; identify weight change segments and calculate the weight difference before and after stabilization to generate a weight step event; write the data into the transaction event context.

[0007] S200. Calculate the scanning interval sequence based on the transaction event context, and determine the event association time range by combining the weight stabilization time of the target weight step event; filter time candidate scanning events from the unassociated unmatched scanning events, and generate a weight compatible candidate scanning event set according to the compatibility relationship between the step amplitude and the benchmark weight range.

[0008] S300 When the weight-compatible candidate scanning event set includes a unique scanning event, a one-to-one association is established and the associated event is updated to a matched status; when the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or includes multiple scanning events, suspected missed scanning records, suspected wrong scanning records, or uncertain association records are generated respectively, and event association results are generated.

[0009] S400: Write the transaction control status based on the event association results; receive the review operation and update the event association status; generate the transaction recovery result when the transaction event context meets the transaction status recovery conditions.

[0010] Furthermore, the barcode scanning event to be matched includes a transaction session identifier, a barcode scanning event identifier, barcode information, product SKU, scanning time, a baseline weight range, and a matching status; the weight step event includes a transaction session identifier, a weight event identifier, an occurrence time, a stabilization time, a step amplitude, a change direction, a stabilization status, and a matching status; the matching status includes a pending matching status, a matched status, a cancelled status, and a timeout status.

[0011] Further, the step of identifying weight change segments and calculating the weight difference before and after stabilization includes: performing a moving average processing on the weight sampling data to calculate the difference between adjacent weight sampling data; extracting weight change segments whose differences continuously exceed the weight noise threshold, and merging adjacent weight change segments with a time interval less than the segment merging threshold; calculating the stable weight difference before and after the merged weight change segment, and generating a positive weight step event or a negative weight step event based on the sign of the stable weight difference.

[0012] Furthermore, determining the event-related time range by combining the weight stabilization duration of the target weight step event includes: calculating the mean and standard deviation of the scanning intervals in the scanning interval sequence; taking the occurrence time of the target weight step event as the end point of the time range, determining the time range corresponding to the sum of the mean scanning interval, the standard deviation of the scanning interval, and the weight stabilization duration as the event-related time range; and writing unassociated, unmatched scanning events whose scanning times fall within the event-related time range into the time candidate scanning events.

[0013] Furthermore, when the weight-compatible candidate barcode scanning event set includes multiple barcode scanning events, the time distance and weight deviation corresponding to each barcode scanning event are calculated respectively; the time distance is the difference between the scanning time and the time when the target weight step event occurs; the weight deviation is the deviation of the step amplitude relative to the corresponding reference weight range; the time distance, the weight deviation, and the queue order of the barcode scanning events in the barcode scanning events to be matched are weighted and calculated to generate candidate association values; when the difference between the smallest candidate association value and the second smallest candidate association value is greater than the candidate discrimination threshold, the barcode scanning event corresponding to the smallest candidate association value is determined as the target barcode scanning event.

[0014] Furthermore, scanning events corresponding to multiple consecutive scanning intervals that are lower than the average scanning interval minus twice the standard deviation of the scanning interval are marked as continuous high-speed scanning status; the duration of the associated time range of the event is increased according to the continuous high-speed scanning status, and the continuous high-speed scanning status is written into the corresponding suspected missed scan record, suspected wrong scan record, or associated uncertain record.

[0015] Furthermore, when the set of weight-compatible candidate scanning events is empty, multiple consecutive scanning events are selected from the time-selective candidate scanning events according to the scanning time sequence; the lower limit and upper limit of the reference weight interval corresponding to the multiple consecutive scanning events are added together; when the step amplitude is between the lower limit and the upper limit after addition, a combination association between the target weight step event and the multiple consecutive scanning events is established, and the target weight step event and the multiple consecutive scanning events are updated to a matched state.

[0016] Further, the system receives product item deletion events or negative weight step events; filters scan events from matched scan events whose baseline weight range is compatible with the step amplitude of the negative weight step event; removes the event association between the filtered scan events and the corresponding positive weight step events; updates the filtered scan events and the positive weight step events to a cancelled or removed state, and rewrites the remaining unassociated unmatched scan events into the transaction event context.

[0017] Further, the step of writing the transaction control status based on the event association results includes: writing a pending review status based on the suspected missed scan record; writing a prohibited payment status based on the suspected wrong scan record and sending a request for assistance to the duty terminal; writing a pending review status based on the uncertain association record; when receiving a rescan operation, writing the newly added unmatched scan event into the transaction event context, and re-filtering the time candidate scan event and the weight compatible candidate scan event; when receiving a product removal operation, updating the corresponding weight step event to the removed status; when receiving a manual confirmation operation, establishing an event association relationship between the confirmed scan event and the corresponding weight step event; and when there are no unmatched positive weight step events, suspected wrong scan records, or uncertain association records in the transaction event context, determining that the transaction event context meets the transaction status recovery conditions.

[0018] Furthermore, the system receives sensor status data from the weighing sensor in the bagging area; the sensor status data indicates that when weight sampling is interrupted, the generation of weight step events is stopped and a degradation processing record is generated; the sensor status data indicates that when the sensor is unstable, the weight change segment that has not formed a stable state is retained in the context of the transaction event; when the product SKU lacks a benchmark weight range, the corresponding barcode scanning event to be matched is updated to a pending verification state.

[0019] The key innovations of this invention include:

[0020] (1) Using the current transaction session as the boundary, the barcode decoding data is bound with the product SKU, scanning time and benchmark weight range to form a barcode scanning event to be matched, and the continuous weight sampling data is converted into a weight step event with occurrence time, step amplitude, change direction and matching status; the two types of events are written into the transaction event context and the event lifecycle is maintained according to the status of pending match, matched, cancelled and timed out.

[0021] (2) Based on the scanning interval sequence of the current transaction session and the weight stability duration of the target weight step event, an event-related time range is formed; from the unrelated unmatched scanning events, time-candidate scanning events and weight-compatible candidate scanning events are sequentially screened to form a hierarchical candidate set jointly limited by time constraints, event state constraints and SKU baseline weight range constraints.

[0022] (3) Based on the number and structure of time-based candidate scanning events and weight-compatible candidate scanning events, establish a one-to-one association between scanning events and weight-step events, or generate suspected missed scanning records, suspected wrong scanning records and uncertain association records respectively; after the association is established, update the matching status of the two types of events synchronously, and update the event association status and transaction event context according to the re-scanning, product removal or manual confirmation operation.

[0023] The following are its main beneficial effects:

[0024] (1) To address the problem that the scanning records and weight changes are independent of each other during continuous scanning and continuous bagging, and the corresponding status is difficult to maintain continuously, the two types of data are converted into events with independent identifiers and matching statuses, so that each scanning and each weight change forms a recordable and updatable event object in the same transaction session; the matched event is removed from the subsequent candidate screening, reducing the situation where the same scanning event or the same weight step event is repeatedly assigned.

[0025] (2) To address the problem that a fixed time range is difficult to adapt to changes in scanning intervals and weighing stability duration, the time range of event association is defined by the scanning interval sequence and the weight stability duration. Then, time candidate filtering and weight compatibility filtering are performed in sequence, so that the scanning event range corresponding to a weight step is simultaneously constrained by transaction time sequence, event status and commodity weight attributes, forming candidate data for subsequent event association.

[0026] (3) To address the issues of missing scanning records, incompatible scanned product weights, and the tendency to use the same abnormal state when multiple scanned products are compatible with weight changes, a candidate set structure is used to form suspected missed scanning records, suspected incorrect scanning records, and associated uncertain records; the review operation updates the specific scanning event, weight step event, and their associated state, so that the transaction control state corresponds to the updated transaction event context. Attached Figure Description

[0027] Figure 1 A flowchart illustrating a method for preventing losses at supermarket self-checkout based on the analysis of incorrect or missed scans, provided as an embodiment of this application;

[0028] Figure 2 This is a structural block diagram of a supermarket self-checkout loss prevention method based on the analysis of incorrect and missed scanning behavior, provided in an embodiment of this application. Detailed Implementation

[0029] Example 1: Refer to Figure 1 This is a flowchart illustrating a method for preventing losses at supermarket self-checkout based on the analysis of incorrect or missed scans, provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0030] S100: Receive transaction session identifier, barcode decoding data, SKU baseline weight range, and weight sampling data; bind the barcode decoding data with the product SKU, scanning time, and baseline weight range to generate a matching scanning event; identify weight change segments and calculate the weight difference before and after stabilization to generate a weight step event; write the data into the transaction event context.

[0031] S200. Calculate the scanning interval sequence based on the transaction event context, and determine the event association time range by combining the weight stabilization time of the target weight step event; filter time candidate scanning events from the unassociated unmatched scanning events, and generate a weight compatible candidate scanning event set according to the compatibility relationship between the step amplitude and the benchmark weight range.

[0032] S300 When the weight-compatible candidate scanning event set includes a unique scanning event, a one-to-one association is established and the associated event is updated to a matched status; when the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or includes multiple scanning events, suspected missed scanning records, suspected wrong scanning records, or uncertain association records are generated respectively, and event association results are generated.

[0033] S400: Write the transaction control status based on the event association results; receive the review operation and update the event association status; generate the transaction recovery result when the transaction event context meets the transaction status recovery conditions.

[0034] Furthermore, the barcode scanning event to be matched includes a transaction session identifier, a barcode scanning event identifier, barcode information, product SKU, scanning time, a baseline weight range, and a matching status; the weight step event includes a transaction session identifier, a weight event identifier, an occurrence time, a stabilization time, a step amplitude, a change direction, a stabilization status, and a matching status; the matching status includes a pending matching status, a matched status, a cancelled status, and a timeout status.

[0035] S100: Receive transaction session identifier, barcode decoding data, SKU baseline weight range, and weight sampling data; bind the barcode decoding data with the product SKU, scanning time, and baseline weight range to generate a matching scanning event; identify weight change segments and calculate the weight difference before and after stabilization to generate a weight step event; write the data into the transaction event context.

[0036] This step is performed by the transaction event generation unit in the self-checkout terminal. The self-checkout terminal includes a barcode scanner, a weighing sensor in the bagging area, a checkout front-end, and a loss prevention processing unit. The barcode scanner outputs barcode decoding data to the loss prevention processing unit, the weighing sensor in the bagging area continuously outputs weight sampling data to the loss prevention processing unit, and the checkout front-end outputs a transaction session identifier when a transaction is established. The transaction session identifier serves as a common index for barcode scanning events, weight step events, event correlation results, and transaction control status within that transaction. After a transaction is completed, canceled, or times out, the loss prevention processing unit stops writing new barcode scanning events and weight step events to that transaction session.

[0037] In one implementation, the POS terminal establishes the current transaction session and generates a transaction session identifier upon receiving the first valid barcode decoding data; in another implementation, the POS terminal establishes the current transaction session when the customer triggers the start of the transaction operation. The transaction session identifier can be formed by combining the POS terminal identifier, transaction serial number, and transaction start time; only one transaction session in a transaction state is maintained at the same self-service POS terminal at a time, and events in different transaction sessions are not cross-correlated.

[0038] After the barcode scanning device completes one barcode decoding, it sends the barcode information, the scanning device identifier, and the decoding completion time to the transaction event generation unit. The transaction event generation unit uses the decoding completion time as the scanning time, or the device time carried in the output message of the scanning device as the scanning time. Based on the barcode information, the transaction event generation unit queries the product master data to obtain the corresponding product SKU and SKU baseline weight range. The SKU baseline weight range includes a baseline weight lower limit and a baseline weight upper limit, which can be derived from a pre-configured weight range in the product master data or a weight range formed based on historical weighing records of the same product.

[0039] When barcode information can be mapped to a valid product SKU, the transaction event generation unit generates a scan event identifier and writes the transaction session identifier, scan event identifier, barcode information, product SKU, scan time, SKU baseline weight range, and matching status into the scan event record. The matching status of newly generated scan events is set to "pending match"; the "pending match" status indicates that the scan event has not yet established an event association with a weight step event and can enter the subsequent time-based candidate scan event filtering. The scan event can also record the entry status of the corresponding transaction product item; the entry status includes valid, deleted, and canceled status. Scan events in the deleted or canceled status will not enter the subsequent candidate filtering.

[0040] The transaction event generation unit generates a separate scanning event for each valid barcode decoding. When the same product SKU is scanned multiple times consecutively, each scan has a different scanning event identifier and scanning time; the transaction event generation unit does not merge scanning events according to product SKU. When the scanning device repeatedly outputs decoded messages with the same content and device serial number within a preset deduplication time, the transaction event generation unit retains the first decoded message and writes subsequent duplicate messages into the decoding duplicate record; when duplicate decoded messages have different device serial numbers, or when the POS front end has generated a new transaction product item, the transaction event generation unit generates separate scanning events.

[0041] When the product master data does not contain a product SKU corresponding to the barcode information, the transaction event generation unit does not generate a barcode scanning event with a baseline weight range to be matched. Instead, it generates a barcode parsing error record and sends the barcode information to the POS front end. When the product SKU has been obtained but the product master data lacks the SKU baseline weight range, the transaction event generation unit generates a barcode scanning event and sets the matching status of this barcode scanning event to "pending review." Barcode scanning events in the "pending review" status are retained in the transaction event context but do not participate in automatic association based on weight compatibility. The POS front end can generate product weight data maintenance prompts or staff review entry points based on the "pending review" status.

[0042] The weighing sensors in the bagging area output weight sampling data in a continuous sampling mode. Each weight sampling data includes a transaction session identifier, weight sampling time, weight sampling value, and sensor status data. After receiving the weight sampling data, the loss prevention processing unit first sorts it according to the weight sampling time; if multiple sampling values ​​appear at the same weight sampling time, they are sorted according to the sampling sequence number output by the data acquisition module. When weight sampling data arrives later than the current processing time, the loss prevention processing unit inserts it into the corresponding sampling position and recalculates the weight change segments that have not yet been encapsulated as weight step events.

[0043] The transaction event generation unit performs a moving average processing on the weight sample data. Let the original weight sample sequence be x1, x2, ..., x... n If the sliding window length is m, then the i-th smoothed weight value can be recorded as the arithmetic mean of the m weight samples within the window; the window length is configured according to the sampling frequency of the weighing sensor in the bagging area and the duration of mechanical vibration. In another embodiment, median value processing can be used instead of sliding average processing; the choice of smoothing method does not change the subsequent processing relationship for generating weight step events based on the weight difference before and after stabilization.

[0044] After smoothing, the transaction event generation unit calculates the difference between adjacent smoothed weight values. When the absolute value of multiple consecutive differences exceeds the weight noise threshold, the corresponding continuous sampling interval is marked as a weight change segment. The weight noise threshold is configured based on the weight fluctuation range of the weighing sensor in the bagging area under no-load conditions. When the time interval between two adjacent weight change segments is less than the segment merging threshold, the transaction event generation unit merges the two weight change segments. The starting point of the merged weight change segment is the starting point of the previous weight change segment, and the ending point is the ending point of the next weight change segment.

[0045] After the weight change segment ends, the transaction event generation unit extracts multiple weight sample values ​​from before and after the weight change segment when the sensor is in a stable state. The stable weight value before the change segment is recorded as the pre-stable weight, and the stable weight value after the change segment is recorded as the post-stable weight. The post-stable weight is subtracted from the pre-stable weight to form the weight difference before and after stabilization. When the weight difference before and after stabilization is positive, a positive weight step event is generated; when the weight difference before and after stabilization is negative, a negative weight step event is generated. The step amplitude in the weight step event is the absolute value of the weight difference before and after stabilization; the direction of change is recorded as positive or negative.

[0046] The sensor's stable state can be formed based on the range, standard deviation, or adjacent differences of multiple consecutive weight sample values. In one embodiment, when the difference between the maximum and minimum values ​​of multiple weight sample values ​​within a preset stabilization time is not greater than a stabilization threshold, this time interval is marked as the sensor's stable state; the time length between the end of the weight change segment and the formation of the stable weight is recorded as the weight stabilization duration. The weight stabilization duration varies with the way the goods are placed, the swinging of the shopping bag, and the mechanical vibration of the weighing platform, and participates in the formation of the event-related time range in S200.

[0047] The transaction event generation unit generates a weight event identifier and writes the transaction session identifier, weight event identifier, occurrence time, stabilization time, step amplitude, direction of change, stable state, and matching state into the weight step event. The occurrence time can be the starting time of the weight change segment; the stabilization time can be the time when the sensor first meets the stable state after the weight change segment ends. The matching state of a newly generated positive weight step event is set to the pending matching state; the matching state of a newly generated negative weight step event is set to the pending processing state and is invoked during the product removal or event association rollback process of S400.

[0048] When sensor status data indicates a weight sampling interruption, the transaction event generation unit stops merging discontinuous weight sampling data before and after the interruption into a single weight change segment and generates a degradation processing record. This record includes the transaction session identifier, the start time of the sampling interruption, the start time of sampling resumption, and an identifier for the incomplete weight change segment. After sampling resumes, the loss prevention processing unit establishes a weight baseline from the new stable weight state, without directly encapsulating the weight difference during the sampling interruption as a product placement event.

[0049] When sensor status data indicates sensor instability, the transaction event generation unit retains the weight change segment that has not yet reached a stable state in the transaction event context and marks it as a weight change segment to be stabilized. After subsequent weight sampling data meets the stability requirements, the weight difference before and after stabilization is calculated. If the stabilization time exceeds the weight event timeout duration, the transaction event generation unit generates a sensor instability record and excludes the weight change segment from the automatic misscan or missed scan generation path.

[0050] In one engineering implementation, the self-checkout terminal establishes a transaction session T001; the barcode scanner outputs the barcode decoding data of product A at 10:00:01.200, and the product master data returns the product SKUA and the baseline weight range [480g, 520g]; the transaction event generation unit generates a barcode scanning event S001 and sets it to a pending matching state. The customer then places product A into the bagging area, and the weight in the bagging area changes from 120g to 618g; the transaction event generation unit identifies the weight change segment, obtains the previous stable weight of 120g and the subsequent stable weight of 618g, and forms a positive weight step event W001 with a step amplitude of 498g. Both the barcode scanning event S001 and the weight step event W001 are written into the transaction event context according to the transaction session identifier T001.

[0051] The transaction event context generated in this step includes a list of barcode scanning events, a list of weight step events, a list of event relationships, a list of anomaly records, sensor status records, and the current transaction control status. Among them, the barcode scanning time, baseline weight range, and matching status of the barcode scanning events to be matched, as well as the occurrence time, weight stabilization duration, step amplitude, and matching status of the positive weight step events, serve as inputs for S200 to construct a set of time-compatible candidate barcode scanning events and weight-compatible candidate barcode scanning events.

[0052] S200. Calculate the scanning interval sequence based on the transaction event context, and determine the event association time range by combining the weight stabilization time of the target weight step event; filter time candidate scanning events from the unassociated unmatched scanning events, and generate a weight compatible candidate scanning event set according to the compatibility relationship between the step amplitude and the benchmark weight range.

[0053] This step is performed by the candidate event construction unit. The candidate event construction unit receives the transaction event context formed in S100; when a new positive weight step event is added to the transaction event context, it sets the positive weight step event as the target weight step event and initiates the time-based candidate barcode scanning event filtering. When a new barcode scanning event arrives, if there is a positive weight step event in the transaction event context that has not yet been associated and has not timed out, the candidate event construction unit can also re-execute this step for the positive weight step event.

[0054] The candidate event construction unit first reads multiple barcode scanning events arranged by scanning time within the current transaction session from the transaction event context; it then calculates the scanning time difference between two adjacent barcode scanning events to generate a barcode scanning interval sequence. The barcode scanning interval sequence only uses barcode scanning events that are in the valid transaction item state; barcode scanning events that have been cancelled, timed out, or whose item state is deleted are not included in the barcode scanning interval calculation. Data repeatedly output by the scanning device at the same time and marked as duplicate decoding records is not written into the barcode scanning interval sequence.

[0055] When the number of valid scan events in the current transaction session is insufficient to form a scan interval sequence, the candidate event construction unit calls the default scan interval parameter in the terminal configuration. The default scan interval parameter can be formed based on the scan interval records of the same self-service checkout terminal in historical transactions, or it can be given by the terminal configuration file. After multiple scan intervals have been formed in the current transaction session, the candidate event construction unit calculates the mean and standard deviation of the scan intervals. The mean scan interval reflects the time distance between adjacent scan operations in the current transaction session, and the standard deviation of the scan interval reflects the dispersion of the scan intervals.

[0056] The candidate event construction unit reads the occurrence time, stabilization time, and weight stabilization duration from the target weight step event. The weight stabilization duration is the time between the stabilization time and the end time of the weight change segment; when the end time of the weight change segment is not separately saved in the weight step event record, the weight stabilization duration can also be formed by subtracting the occurrence time from the stabilization time and subtracting the duration of the weight change. The candidate event construction unit uses the occurrence time of the target weight step event as the end point of the event association time range, and uses the duration corresponding to the sum of the average scanning interval, the standard deviation of the scanning interval, and the weight stabilization duration as the length of the event association time range; the starting point of the event association time range is the time obtained by shifting the occurrence time of the target weight step event forward by the specified duration.

[0057] In one implementation, the event-related time range length L is determined according to L = μ + σ + t. s Formation, where μ is the mean of the scanning interval, σ is the standard deviation of the scanning interval, and t s The sum represents the weight stabilization time for the target weight step event. In another implementation, the transmission time of the self-service checkout terminal's barcode scanning messages or the transmission time of the weight sampling messages can be added to the sum; the added transmission time comes from the communication delay parameters recorded during terminal initialization. The record for forming the event-related time range includes the average barcode scanning interval, the standard deviation of the barcode scanning interval, the weight stabilization time, the start time, and the end time.

[0058] The candidate event construction unit can also identify continuous high-speed scanning status in the current transaction session. Specifically, each scanning interval in the scanning interval sequence is compared with a high-speed scanning threshold formed by subtracting twice the standard deviation of the scanning interval from the mean of the scanning intervals; when a preset number of consecutive scanning intervals are lower than the high-speed scanning threshold, the corresponding multiple scanning events are marked as continuous high-speed scanning status. The preset number can be configured by the self-service checkout terminal; continuous high-speed scanning status only indicates that the intervals between multiple scanning events within the corresponding time period are short, and does not directly generate records of suspected misscanning or missed scanning.

[0059] When the occurrence of the target weight step event falls after the time period corresponding to the continuous high-speed scanning state, the candidate event construction unit adds a high-speed scanning compensation duration to the original event association time range. The high-speed scanning compensation duration can be the product of the standard deviation of the scanning interval and the number of continuous high-speed scanning events, or it can be the compensation duration configured in the terminal. The added event association time range still ends at the occurrence time of the target weight step event. The continuous high-speed scanning state and the compensation duration used are written into the candidate construction record and used as the status field of the corresponding record when an abnormal record is formed in S300.

[0060] After the event association time range is determined, the candidate event construction unit filters candidate QR code events from the transaction event context. During filtering, the transaction session identifier, scanning time, matching status, and transaction item status are simultaneously retrieved. Filtered QR code events should belong to the transaction session containing the target weight step event, have a scanning time within the event association time range, a matching status of "pending matching," and not have established event associations with other weight step events. QR code events in the "matched," "cancelled," "timeout," or "pending review" states are not added to the time candidate QR code event set.

[0061] The candidate event construction unit arranges the scan events that meet the filtering criteria from earliest to latest according to their scan time, generating a time-based candidate scan event set. Each time-based candidate scan event records the scan event identifier, scan time, target weight event identifier, time distance between the scan time and the occurrence time of the target weight step event, product SKU, baseline weight range, and queue order. The queue order indicates the position of the scan event among the currently unassociated, unmatched scan events.

[0062] After forming a set of candidate time-based barcode scanning events, the candidate event construction unit reads the baseline weight range corresponding to each candidate time-based barcode scanning event one by one, and compares the step amplitude of the target weight step event with the baseline weight range. When the step amplitude is between the lower and upper limits of the baseline weight range, the candidate time-based barcode scanning event is marked as weight compatible and written into the set of weight-compatible candidate barcode scanning events; when the step amplitude is less than the lower limit of the baseline weight range or greater than the upper limit of the baseline weight range, the candidate time-based barcode scanning event is marked as weight incompatible.

[0063] In one implementation, the baseline weight range in the product master data already includes product packaging differences and weighing errors, so no additional weight tolerance is needed. In another implementation, the baseline weight range is expanded based on product category or packaging category labels. When using packaging category labels, these labels are derived from the product master data and do not represent the actual shape detection results of the packaged products. The packaging category labels can correspond to different weight tolerance configurations, and the expanded baseline weight lower limit and baseline weight upper limit are used for weight compatibility comparisons.

[0064] When a product SKU lacks a baseline weight range, the corresponding scanning event is not included in the weight-compatible candidate scanning event set. The candidate event construction unit retains the "pending verification" status in this scanning event and writes a missing product weight data marker into the candidate construction record. When the time-based candidate scanning event set corresponding to the target weight step event only contains scanning events pending verification, a suspected misscan record is not directly generated. Instead, the target weight step event and the scanning event pending verification are sent to S300 to form an associated uncertain record.

[0065] In one optional implementation, when the time-based candidate barcode scanning event set is not empty but the weight-compatible candidate barcode scanning event set is empty, the candidate event construction unit performs multiple product combination weight filtering. The candidate event construction unit selects consecutive barcode scanning events within a preset number of ranges from the time-based candidate barcode scanning event set according to the scanning time sequence; it adds the lower limits of the corresponding baseline weight intervals for the selected multiple barcode scanning events to form a combination weight lower limit; and it adds the upper limits of the corresponding baseline weight intervals to form a combination weight upper limit. When the step amplitude of the target weight step event is between the combination weight lower limit and the combination weight upper limit, a combination candidate record is generated.

[0066] Weight filtering for multiple product combinations is restricted to continuous scanning events; scanning events already associated with other weight step events are not included in the combination candidate; combinations containing scanning events in a cancelled or timed-out state are not written into the combination candidate record. When a combination candidate is generated, it is sent to S300; when multiple combination candidates are generated, multiple combination candidates and their corresponding scanning event identifiers are sent to S300 to form an associated indeterminate branch.

[0067] In one engineering implementation, scanning events S101, S102, and S103 are generated sequentially in transaction session T002; their scanning times are 10:05:01.000, 10:05:02.100, and 10:05:03.000, respectively, corresponding to scanning intervals of 1.1s and 0.9s. The target weight step event W101 occurs at 10:05:04.500, with a weight stabilization time of 0.8s and a step amplitude of 502g; the candidate event construction unit forms an event association time range based on the average scanning interval, the standard deviation of the scanning interval, and the weight stabilization time, and filters S101, S102, and S103 from the unassociated matching scanning events. The baseline weight ranges for S101, S102, and S103 are [480g, 520g], [190g, 210g], and [490g, 530g], respectively; thus, a set of weight-compatible candidate barcode scanning events containing S101 and S103 is generated.

[0068] This step ultimately outputs the event association time range, the time candidate scanning event set, the weight compatible candidate scanning event set, the combined candidate record, and the continuous high-speed scanning status; the number of candidates in the time candidate scanning event set, the number of candidates in the weight compatible candidate scanning event set, the time distance of each candidate, the weight deviation, and the queue order, which serve as inputs for S300 to establish event association relationships or generate abnormal records.

[0069] In one specific embodiment:

[0070] S200. Calculate the scanning interval sequence based on the transaction event context, and determine the event association time range by combining the weight stabilization time of the target weight step event; filter time candidate scanning events from the unassociated unmatched scanning events, and generate a weight compatible candidate scanning event set according to the compatibility relationship between the step amplitude and the benchmark weight range.

[0071] The candidate event construction step receives the transaction event context formed by S100; the transaction event context includes a barcode scanning event list, a weight step event list, an event association list, an anomaly record list, sensor status records, and the current transaction control status.

[0072] When a new positive weight step event is added to the transaction event context, the candidate event construction unit sets the positive weight step event as the target weight step event and starts the time-candidate barcode scanning event filtering. To construct the time-candidate barcode scanning events, the candidate event construction unit first reads multiple barcode scanning events arranged by scanning time in the current transaction session from the transaction event context, calculates the scanning time difference between two adjacent barcode scanning events, and forms a scanning interval sequence.

[0073] Suppose there are a total of A scan event that is in the state of a valid transaction item, the scan time is as follows: The time difference between adjacent scans (in The following is given by formula ①:

[0074]

[0075] in, The difference between the scanning times of two adjacent valid scanning events, which is a non-negative real number;

[0076] : The sequence number of the scanning interval, with values ​​ranging from arrive positive integers, where The total number of valid QR code scanning events in the current transaction session ( Formula ① is meaningful.

[0077] : No. The scanning time of each valid scanning event is taken from the "scanning time" field of the scanning event record in S100;

[0078] : No. The scanning time of each valid QR code scanning event, sourced from the same... .

[0079] Formula ① As the basic element of the scanning interval sequence, it is used for subsequent calculation of the mean and standard deviation of the scanning interval.

[0080] When the number of valid QR code scanning events Insufficient to form a scan interval sequence (i.e.) When the candidate event construction unit calls the default scanning interval parameter in the terminal configuration, the candidate event construction unit will then call the default scanning interval parameter in the terminal configuration. and The default scanning interval parameter is formed based on the scanning interval records of the same self-service checkout terminal in historical transactions, or it can be directly given by the terminal configuration file.

[0081] when At that time, the candidate event construction unit calculates the average scanning interval. and the standard deviation of the scanning interval The mean of the scanning interval is calculated using the arithmetic mean, and the standard deviation of the scanning interval is calculated using an unbiased estimate, as given by formulas ② and ③, respectively:

[0082]

[0083]

[0084] in, The average scanning interval reflects the average time distance between adjacent scanning operations in the current transaction session.

[0085] : The total number of QR code scanning events in the current transaction session that are in the state of valid transaction item; when When formula ② is not applicable, it is replaced by the default parameter;

[0086] The total number of scanning intervals is used as the denominator;

[0087] The summation symbol indicates the summation of subscripts. from arrive Accumulate;

[0088] Same as formula ①, the difference between adjacent scanning times;

[0089] Standard deviation of the scanning interval reflects the degree of dispersion of the scanning interval;

[0090] Same as formula ②, total number of valid QR code scanning events; when When, the denominator ,at this time Take the default value ;

[0091] Degrees of freedom (when) hour);

[0092] Same as formula ②, but with the same summation symbol;

[0093] : Same as formula ①;

[0094] : Same as formula ②.

[0095] Formulas ② and ③ , As a key indicator describing the temporal characteristics of scanning behavior in the current transaction session, it is used to construct the time range of event association.

[0096] The candidate event building unit reads the occurrence time from the target weight step event. Stable moment and weight stabilization time The weight stabilization time is the duration between the stabilization point and the end of the weight change segment; if the end of the weight change segment is not separately saved in the weight step event record, then... It is formed by subtracting the occurrence time from the steady time and deducting the duration of the weight change.

[0097] The candidate event construction unit is based on the occurrence time of the target weight step event. The average of the scanning intervals is the end point of the event's associated time range. Standard deviation of scanning interval and weight stabilization time The sum is used as the length of the time range associated with the event. The starting point of the event-related time range is... Move forward The moment that was obtained later.

[0098] This relationship is represented by formula ④:

[0099]

[0100] in, : The length of the time range associated with the event;

[0101] : Same as formula ②;

[0102] : Same as formula ③;

[0103] The weight stabilization time of the target weight step event is taken from the difference between the "stabilization time" and the "occurrence time" of the weight step event record in S100 (or obtained after deducting the duration of the weight change).

[0104] Formula ④ generates The length of the dynamic time window is directly used as the filtering boundary for subsequent candidate QR code scanning events.

[0105] The output of this section includes: scan interval sequence. Average scanning interval Standard deviation of scanning interval Event-related time range length The starting and ending times of the data are written into the candidate construction record and used as input for the subsequent filtering logic of S200 (i.e., Part II below).

[0106] After obtaining the associated time range of the events, the candidate event construction unit filters candidate QR code scanning events from the transaction event context. The filtering criteria simultaneously include the transaction session identifier, scanning time, matching status, and transaction item status: the filtered QR code scanning events should belong to the transaction session in which the target weight step event is located, the scanning time should be within the associated time range of the events (i.e., greater than or equal to the start time and less than or equal to the end time), the matching status should be "pending matching", and no event association relationship should be established with other weight step events.

[0107] Scanning events in the "Matched," "Cancelled," "Timeout," or "Pending Review" states are not included in the time candidate set. The candidate event construction unit arranges the scanning events that meet the filtering criteria from earliest to latest according to their scanning time, generating a time candidate scanning event set. .for Each candidate QR code scanning event in time Record the time of scanning the code. Scan event identifier, product SKU, and baseline weight range And the time distance between the scanning time and the time of the target weight step event. Subsequently, the candidate event construction unit reads the baseline weight range corresponding to each candidate barcode scanning event at each time, and sets the step amplitude of the target weight step event. Compare with the baseline weight range. Step amplitude. The value is given by the "Step Amplitude" field of the weight step event in S100, with the dimension in grams (g).

[0108] To quantify the compatibility between the step amplitude and the baseline weight range, a weight compatibility discriminant function is introduced. Defined by formula ⑤:

[0109]

[0110] in, : Weight compatibility indicator function, output value is Indicates weight compatibility, output value is This indicates that the weights are incompatible;

[0111] Time-based candidate QR code scanning event set One of the candidate events in;

[0112] Candidate events The lower limit of the corresponding baseline weight range is taken from the lower boundary of the "SKU baseline weight range" recorded in the barcode scanning event in S100.

[0113] Candidate events The upper limit of the corresponding baseline weight range is taken from the upper boundary of the same field;

[0114] : The step amplitude of the target weight step event is taken from the "step amplitude" field of the weight step event record in S100;

[0115] curly braces " ": Definition of a piecewise function.

[0116] Formula ⑤ As the weight compatibility result, each time candidate event is marked as having passed the weight compatibility test. The output of this section includes: a set of time candidate barcode scanning events. Weight-compatible candidate QR code scanning event set Time distance of each candidate Queue order. The above sets and indicators serve as direct inputs for S300 to establish event relationships or generate exception records.

[0117] The candidate event construction unit also identifies continuous high-speed scanning states within the current transaction session and adjusts the event association time range as necessary. Specifically, it considers each scanning interval in the scanning interval sequence... With high-speed scanning threshold Comparison, among which .

[0118] When continuous The scanning interval is lower than hour( (As a preset quantity, configured by the self-service checkout terminal), multiple corresponding scanning events are marked as continuous high-speed scanning states. If the occurrence time of the target weight step event falls after the time period corresponding to the continuous high-speed scanning state, the candidate event construction unit is within the original event association time range. Increase the compensation time for high-speed QR code scanning The calculation of the compensation duration is given by formula ⑥:

[0119]

[0120] in, Compensation time for high-speed QR code scanning;

[0121] : Compensation coefficient, with a preset positive real number (default) (), provided by the terminal configuration file;

[0122] : continuously below the high-speed scanning threshold The number of scanning intervals is obtained by statistically analyzing the actual scanning interval sequence;

[0123] : Same as formula ③.

[0124] Numerical example: Let Continuous high-speed scanning quantity , ,but The length of the event-related time range after compensation is [length missing]. Its starting point moves forward accordingly. The continuous high-speed scanning status and the compensation duration used are written into the candidate construction record, and used as the status field of the corresponding record when an abnormal record is formed in S300.

[0125] In addition, when the time-based candidate QR code scanning event set Non-empty and weight-compatible candidate QR code event set When empty, the candidate event building unit performs multiple product combination weight filtering: sorted by scan time from... Select a preset number of consecutive barcode scanning events, add the lower limits of the corresponding baseline weight intervals for the selected events to form a combined weight lower limit, and add the upper limits to form a combined weight upper limit; if the step amplitude of the target weight step event is... If the record is located within the combined weight range, a combined candidate record is generated.

[0126] Combined candidate records and , The output is sent to S300. The output products of this section include: continuous high-speed scanning status flag, compensated time range length, and combined candidate records. The above fields are written into the candidate construction record and used as input to the "Event Association and Anomaly Classification Unit" of S300, which is used to generate associated uncertain records or combined association relationships when there are multiple candidates or combined candidates.

[0127] Technical effect of this section: By fusing the dynamic statistical features of the scanning interval with the weight stability duration, the event association time range is adaptively constructed, and a structured candidate set is generated by using time candidate and weight compatibility two-level filtering, which provides accurate input data for subsequent anomaly classification, and realizes efficient matching and evidence level classification of asynchronous events.

[0128] S300 When the weight-compatible candidate scanning event set includes a unique scanning event, a one-to-one association is established and the associated event is updated to a matched status; when the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or includes multiple scanning events, suspected missed scanning records, suspected wrong scanning records, or uncertain association records are generated respectively, and event association results are generated.

[0129] This step is performed by the event association and anomaly classification unit. The event association and anomaly classification unit receives the target weight step event, time candidate scanning event set, weight compatible candidate scanning event set, combined candidate record, and continuous high-speed scanning status generated by S200; and establishes event association relationships or generates corresponding anomaly records according to the number of records in the candidate set and the candidate differentiation rules.

[0130] When the set of weight-compatible candidate barcode scanning events contains only one barcode scanning event, the event association and anomaly classification unit takes that barcode scanning event as the target barcode scanning event; reads the barcode scanning event identifier of the target barcode scanning event and the weight event identifier of the target weight step event, and generates an event association identifier; and writes the transaction session identifier, event association identifier, barcode scanning event identifier, weight event identifier, association establishment time, and association type into the event association relationship. In this case, the association type is recorded as a single-event association.

[0131] When establishing a one-to-one association, the event association and anomaly classification unit uses the fact that the original barcode scanning event and the original weight step event are still in a pending matching state as the writing condition. After writing the event association, the matching state of the target barcode scanning event and the target weight step event is synchronously updated to a matched state. The state update is completed using the same event update operation; if any event has already been converted to a canceled state, a removed state, or a timeout state before the state update, the event association and anomaly classification unit cancels the current association write and calls S200 again to generate the candidate set.

[0132] Matched barcode scanning events and weight step events will no longer be included in subsequent time and weight compatibility candidate filtering. The event association and anomaly classification unit retains the event association relationship in the transaction event context and writes the other party's event identifier into the barcode scanning event and weight step event respectively. The list of unassociated unmatched barcode scanning events and the list of unassociated positive weight step events in the transaction event context are updated synchronously with the status update.

[0133] In one implementation, when the weight-compatible candidate barcode scanning event set includes multiple barcode scanning events, the event association and anomaly classification unit directly generates an indeterminate association record. In another implementation, the event association and anomaly classification unit first calculates the candidate association values ​​of multiple candidate barcode scanning events, and then selects the target barcode scanning event based on the difference between the candidate association values. Both implementations retain the time distance, weight deviation, and queue order of each barcode scanning event in the candidate set.

[0134] When using candidate correlation values, the event correlation and anomaly classification units calculate the time distance and weight deviation for each candidate scanning event. The time distance is the difference between the scanning time and the time when the target weight step event occurs; the weight deviation can be formed based on the position between the step amplitude and the reference weight interval. When the step amplitude is within the reference weight interval, the weight deviation can be the absolute difference between the step amplitude and the center value of the reference weight interval; alternatively, it can be the smaller of the distances from the step amplitude to the lower limit and upper limit of the reference weight, respectively.

[0135] The event association and anomaly classification unit normalizes time distance, weight deviation, and queue order, and performs weighted calculations according to preset weights to generate candidate association values. Candidate scanning events with shorter time distances, smaller weight deviations, and earlier queue orders correspond to smaller candidate association values. Candidate association values ​​are arranged in ascending order. When the difference between the smallest and second-smallest candidate association values ​​is greater than the candidate differentiation threshold, the scanning event corresponding to the smallest candidate association value is taken as the target scanning event, and a one-to-one association relationship is established. When the difference is not greater than the candidate differentiation threshold, an uncertain association record is generated.

[0136] The candidate differentiation threshold is read from the event association rules of the self-service checkout terminal; different self-service checkout terminals may use different candidate differentiation thresholds. The candidate association value is only used to differentiate between multiple weight-compatible candidates, and is not used to convert weight-incompatible scanning events into weight-compatible scanning events. The weights, normalization results, minimum candidate association value, second-smallest candidate association value, and candidate differentiation threshold used in the candidate association value calculation are written into the event association results.

[0137] When S200 forms a unique combined candidate record, the event association and anomaly classification unit establishes a combined association between the target weight step event and multiple consecutive barcode scanning events in the combined candidate record; the combined association record contains one weight event identifier and multiple barcode scanning event identifiers. After establishing the combined association, the target weight step event and multiple barcode scanning events are updated to a matched state; if any barcode scanning event has already been associated with other weight step events, the combined association is canceled and a new combined candidate record is generated.

[0138] When the set of candidate scanning events is empty, it indicates that there are no unassociated matching scanning events within the event association time range of the target positive weight step event; the event association and anomaly classification unit generates a suspected missed scan record. The suspected missed scan record includes the transaction session identifier, target weight event identifier, occurrence time, step amplitude, event association time range, number of time candidates, continuous high-speed scanning status, sensor stable status, and handling status; the handling status is initially written as the unreviewed status.

[0139] When the time-based candidate barcode scanning event set is not empty and the weight-compatible candidate barcode scanning event set is empty, the event association and anomaly classification unit generates a suspected erroneous scanning record in the absence of a valid combination candidate record. The suspected erroneous scanning record includes the transaction session identifier, target weight event identifier, time-based candidate barcode scanning event identifier, product SKU for each barcode scanning event, each baseline weight range, step amplitude of the target weight step event, weight incompatibility result, continuous high-speed scanning status, and processing status.

[0140] When the time-based candidate barcode scanning event set contains barcode scanning events awaiting review that lack a baseline weight range, or when the weight-compatible candidate barcode scanning event set includes multiple barcode scanning events and the target barcode scanning event cannot be selected based on the candidate differentiation threshold, the event association and anomaly classification unit generates an uncertain association record. The uncertain association record includes the target weight event identifier, multiple candidate barcode scanning event identifiers, candidate association values, candidate set status, missing product weight data marker, and processing status.

[0141] If a target weight step event has not yet reached a stable sensor state, the process of generating suspected missed scan records, suspected erroneous scan records, or normal event association records will not begin; the event association and anomaly classification unit will retain the target weight step event as a state awaiting stabilization. After the sensor stabilizes, S100 will supplement the stabilization time and step amplitude, and S200 and S300 will be called back. The sensor state record indicates that when sampling is interrupted, no suspected erroneous scan records or missed scan records will be generated for weight changes that occur during the sampling interruption period.

[0142] If no candidate scanning events are obtained for a target weight step event within the event association time range, but the target weight step event is still within the backward scanning waiting time, the event association and anomaly classification unit can temporarily suspend the generation of a suspected missed scan record and mark the weight step event as pending scanning. When a new scanning event arrives subsequently, S200 reconstructs the set of candidate scanning events. If no candidate scanning events are found after the backward scanning waiting time expires, then a suspected missed scan record is generated.

[0143] In one engineering implementation, the step amplitude of the target weight step event W201 is 498g; the time candidate barcode scanning event set includes S201 and S202, wherein the reference weight range of S201 is [480g, 520g], and the reference weight range of S202 is [180g, 220g]. The weight-compatible candidate barcode scanning event set only includes S201; the event association and anomaly classification unit establishes a one-to-one association between S201 and W201, and updates them to a matched state.

[0144] In another engineering implementation, the step amplitude of the target weight step event W202 is 750g; there are no matching barcode scanning events within the event association time range, and the event association and anomaly classification unit generates a suspected missed scan record. In yet another engineering implementation, the step amplitude of the target weight step event W203 is 900g; the time candidate barcode scanning event S203 corresponds to the reference weight range [90g, 110g], and there are no valid combination candidates, and the event association and anomaly classification unit generates a suspected mis-scan record.

[0145] This step generates event association results; these results include normal association records, suspected missed scan records, suspected erroneous scan records, or records with uncertain associations, and carry the target weight step event status, candidate set status, continuous high-speed scanning status, and sensor stable status. These event association results serve as input for the S400 to write transaction control status, receive review operations, and update event association status.

[0146] In one specific embodiment:

[0147] S300 When the weight-compatible candidate scanning event set includes a unique scanning event, a one-to-one association is established and the associated event is updated to a matched status; when the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or includes multiple scanning events, suspected missed scanning records, suspected wrong scanning records, or uncertain association records are generated respectively, and event association results are generated.

[0148] The event correlation and anomaly classification steps receive the target weight step event and time candidate barcode scanning event set generated by S200. Weight-compatible candidate QR code scanning event set Combined candidate records and continuous high-speed scanning status.

[0149] This step first targets Each candidate QR code scanning event in Calculate the time distance between it and the target weight step event. and weight deviation The time and distance are directly output by the S200. Given, the dimension is seconds.

[0150] Weight deviation is used to quantify the degree to which the step amplitude value deviates from the reference weight range, when the step amplitude value Located in the benchmark weight range When the step amplitude is within the range, the deviation is taken as a smaller value to reflect the degree of compatibility; when the step amplitude is outside the range, the deviation is taken as a positive value to indicate incompatibility.

[0151] But given The candidates in the middle have been satisfied The weight deviation is only used to distinguish the merits of multiple compatible candidates. Formula ⑦ defines a method for calculating the weight deviation, which is to take the absolute distance from the step amplitude value to the center value of the reference interval:

[0152]

[0153] in, Candidate QR code scanning incident The weight deviation is a non-negative real number.

[0154] : Identifier of candidate QR code scanning events, indicating a set of weight-compatible candidate QR code scanning events. A specific event in the process;

[0155] : The step amplitude of the target weight step event is taken from the "step amplitude" field of the weight step event record in S100;

[0156] Candidate events The lower limit of the corresponding baseline weight range is taken from the lower boundary of the "SKU baseline weight range" recorded in the barcode scanning event in S100.

[0157] Candidate events The upper limit of the corresponding baseline weight range is taken from the upper boundary of the same field;

[0158] : The center value of the reference weight range;

[0159] : Absolute value function.

[0160] Output of Formula ⑦ It is used as a weight deviation index for calculating candidate correlation values ​​in Formula ⑧.

[0161] To comprehensively evaluate the matching degree between each candidate barcode scanning event and the target weight step event, the event correlation and anomaly classification unit considers the time distance. Weight deviation and queue order Normalization is performed, and then a weighted sum is calculated according to preset weights to generate candidate correlation values. Queue order Indicates the position of the candidate event in the unassociated QR code scanning events (a positive integer starting from 1, the smaller the value, the earlier the scanning time).

[0162] Normalization uses min-max scaling to map each metric to... Within an interval, smaller values ​​indicate better performance. Formula ⑧ provides the expression for calculating candidate correlation values:

[0163]

[0164] in, Candidate QR code scanning incident Candidate association values, range of values The smaller the value, the higher the degree of matching;

[0165] Same as above, candidate QR code scanning event identifier;

[0166] Time distance weight, a preset value, is provided by the event association rules of the self-service checkout terminal;

[0167] Candidate events The time distance, i.e. the difference between the scanning time and the time when the target weight step event occurs, is taken from the S200 output;

[0168] Current weight-compatible candidate set The minimum time distance among all candidate values;

[0169] :current The maximum value of the time distance among all candidate values;

[0170] Weight deviation weight, preset value;

[0171] : Weight deviation obtained from formula ⑦;

[0172] :current The minimum value of the weight deviation among all candidate weights;

[0173] :current The maximum value of all candidate weight deviations;

[0174] Queue order weight, preset value;

[0175] Candidate events The queue order represents the position in the unassociated QR code scanning events to be matched (starting from 1), taken from the S200 output;

[0176] :current The maximum value in the queue order.

[0177] Output of Formula ⑧ The overall score for each candidate is written into the event association results and used for difference comparison in formula ⑨.

[0178] The output of this section includes: the weight deviation for each candidate. Candidate correlation values The normalization parameters and weights are written into the event association results and directly called by the second part of this step (formulas 9 and 10 below).

[0179] After obtaining all candidate association values, the event association and anomaly classification unit will categorize the candidates according to... Arrange from smallest to largest to obtain the sequence. ,in To determine whether the optimal candidate is significantly better than the second-best candidate, the difference between the minimum candidate correlation value and the second-minimum candidate correlation value is calculated. As shown in formula ⑨:

[0180]

[0181] in, The difference in candidate correlation values ​​between the best and second-best candidates;

[0182] The second smallest candidate correlation value (second-best candidate) after sorting in ascending order, is the output of formula ⑧;

[0183] The smallest candidate association value after sorting in ascending order (the optimal candidate) is the output of formula ⑧.

[0184] Output of Formula 9 Used for comparison with the candidate discrimination threshold in formula ⑩. The event association and anomaly classification unit reads the candidate discrimination threshold from the event association rules of the self-service checkout terminal. (Dimensionless positive real numbers). The comparison logic is given by the piecewise decision function of formula 10:

[0185]

[0186] in, : Decision result, with values ​​of either the string "unique association" or "association uncertain";

[0187] Size of the set of weight-compatible candidate barcode scanning events;

[0188] The difference obtained from formula ⑨;

[0189] The candidate differentiation threshold is provided by the event association rules of the self-service checkout terminal;

[0190] Conditional expressions: if...then..., and logical "OR" ( ) and “and” ).

[0191] The decision result of Formula 10 directly guides the establishment of event correlations or the generation of anomaly records. The output of this section includes: difference. The decision result and the candidate discrimination threshold used are written into the event association result and used by the third part of this step (Formula 11 and Formula 12 below) to perform specific state updates or anomaly classification.

[0192] Based on the decision result of formula ⑩, the event association and anomaly classification units execute different processing chains. When the decision is "unique association" and When the weight-compatible candidate set contains only one scanning event, that unique scanning event is used as the target scanning event, establishing a one-to-one event association. Before establishing the association, it is necessary to atomically check the current matching state of the target scanning event and the target weight step event: both must still be in the "pending matching state" and not be occupied by other associations. This state check condition is expressed by the formal condition of formula ⑪:

[0193]

[0194] in, : Boolean value, True or False, indicating whether the state update condition is met;

[0195] Target QR code scanning event identifier;

[0196] Target weight step event identifier;

[0197] : A function that reads the current matching status of an event. The return value is taken from the "matching status" field of the event record, and the possible values ​​are strings such as "pending match", "matched", "cancelled", "timeout", "pending review", etc.

[0198] "Pending Match": A string constant indicating that the event is in the pending match state;

[0199] "False": Boolean value False;

[0200] Logical AND operator;

[0201] : A Boolean function that checks whether an event relationship already exists between two events. It queries the "event relationship list" of the transaction event context and returns True or False.

[0202] Numerical example: Set the target QR code scanning event The matching status is "pending matching", and the target weight step event. If the matching status is "pending match" and there is no related record between the two in the event association list, then... This allows associated writes. If the matching status of any event has changed to "matched", then... The event association and exception classification unit cancels the current association write and re-calls S200 to generate the candidate set. When When true, the unit generates an event association identifier, writes the transaction session identifier, event association identifier, barcode scan event identifier, weight event identifier, association establishment time, and association type (single event association or combined association) into the event association relationship, and atomically updates the matching status of the target barcode scan event and the target weight step event to "matched". After the update, the two events will no longer enter the subsequent S200 candidate screening.

[0203] For the unique candidate record formed by S200, the cell establishes a combination association, that is, the association between a weight step event and multiple consecutive scan events. The compatibility determination of the combination association requires that the combined weight range contains the step amplitude, given by formula ⑫:

[0204]

[0205] in, : Boolean value, True or False, indicating whether the combined candidate is compatible with the step amplitude;

[0206] : Indicator function, outputs True if the condition in parentheses is true, otherwise outputs False;

[0207] : For the combined candidate set All events Summation;

[0208] : A set of multiple consecutive scanning events in the combined candidate;

[0209] Same as formula ⑦, candidate events The lower limit of the baseline weight range;

[0210] Same as formula ⑦, candidate events The upper limit of the baseline weight range;

[0211] Same as formula ⑦, the step amplitude of the target weight step event.

[0212] Numerical example: Suppose the combined candidate contains two QR code scanning events. (Benchmark range) )and (Benchmark range) Then the lower limit and upper limit and Target weight step event step amplitude ,satisfy Therefore Establish combined associations.

[0213] If the step amplitude is If the combination is compatible and none of the scanning events in the combination are associated with other weight step events, the unit establishes a combination association and updates the target weight step event and multiple scanning events to the matched state; if any scanning event has been associated, the combination association is canceled and a new combination candidate is generated.

[0214] In cases where a connection cannot be established, the unit generates an exception record based on the candidate set status: when When empty, a suspected missed scan record is generated. Non-empty and When the value is empty and there are no valid candidate combinations, a suspected misscan record is generated. When there are multiple candidates and the decision in Formula 10 is "associated uncertainty", or when the time candidate set contains a barcode scanning event that is to be reviewed but lacks a baseline weight range, an associated uncertainty record is generated.

[0215] All event association results (normal association records, suspected missed scan records, suspected wrong scan records, and uncertain association records), along with the target weight step event status, candidate set status, continuous high-speed scanning status, and sensor stable status, serve as inputs for the S400 to write transaction control status, receive verification operations, and update event association status.

[0216] Technical effects of this section: By constructing a candidate correlation value weighted model and a difference comparison mechanism, uniqueness determination is achieved in multi-candidate scenarios, and atomic state checks are used to prevent duplicate event matching; at the same time, differentiated abnormal records are generated according to the structural state of the candidate set (empty, incompatible, no significant difference among multiple candidates), separating cases of insufficient evidence from cases of clear errors, which significantly improves the robustness and interpretability of the self-service checkout loss prevention system.

[0217] S400: Write the transaction control status based on the event association results; receive the review operation and update the event association status; generate the transaction recovery result when the transaction event context meets the transaction status recovery conditions.

[0218] This step is jointly executed by the transaction status control unit and the processing write-back unit. The transaction status control unit receives the event association results generated by S300 and reads the current transaction status of the POS terminal; the processing write-back unit receives re-scanning operations and product removal operations submitted by customers at the POS terminal, as well as manual confirmation operations submitted by staff through the monitoring terminal. Both the transaction status control status and event status updates are bound to the transaction session identifier.

[0219] When the event association result is a normal association record, the transaction status control unit saves the normal association record in the transaction event context and maintains the current transaction status of the POS front end. The scan event and weight step event corresponding to the normal association record have been updated to the matched status and will no longer enter the subsequent candidate filtering. When the POS front end receives a payment request, the transaction status control unit still needs to check whether there are any unmatched positive weight step events, suspected misscanned records, or uncertain association records in the transaction event context.

[0220] When the event-related results include suspected missed scan records, the transaction status control unit writes the checkout front end to a pending review status. In the pending review status, the checkout front end displays the review entry corresponding to the target weight step event and retains the currently traded product item. Customers can choose to rescan the barcode or remove the product. The pending review status does not delete the suspected missed scan records, and the processing status of the suspected missed scan records remains unreviewed.

[0221] When an event-related result includes a suspected erroneous scan record, the transaction status control unit writes a payment-prohibited state to the POS terminal and sends a request for assistance to the monitoring terminal. The request for assistance includes the transaction session identifier, self-service checkout terminal identifier, target weight event identifier, time-based candidate barcode scanning event identifier, product SKU, baseline weight range, and step value. In the payment-prohibited state, the POS terminal does not execute payment requests; product item deletion, product removal, rescanning, and staff verification operations can still be written into the transaction event context.

[0222] When the event association result includes uncertain records, the transaction status control unit writes the checkout front end to a pending review status. The checkout front end can display the product name, scanning time, and baseline weight range corresponding to multiple candidate barcode scanning events, and staff can also read multiple candidate barcode scanning events from the monitoring terminal. Uncertain records are not directly associated with events; the target weight step event and multiple candidate barcode scanning events remain in a pending matching or pending review status.

[0223] Upon receiving a rescanning operation, the scanning device outputs new barcode decoding data; the transaction event generation unit generates a new barcode scanning event to be matched according to S100 and writes it into the transaction event context of the original transaction session. The processing write-back unit obtains the target weight event identifier corresponding to the original suspected missed scan record or suspected incorrect scan record, and calls S200 to re-filter the time candidate barcode scanning events and weight-compatible candidate barcode scanning events; when the rescanning event and the original target weight step event form a unique weight-compatible candidate, S300 is called to establish the event association relationship, and the processing status of the original abnormal record is updated to the processed status.

[0224] The scan event generated by the rescanning operation has a new scan event identifier and scan time. In one implementation, for the scan event generated by the review operation, the time interval between the occurrence time of the original target weight step event and the rescanning time can be set as the review association time range, instead of using the forward event association time range in the ordinary transaction process. This review association method records the review operation identifier and only associates the original target weight step event that is in an unmatched state.

[0225] When a product removal operation is received, the weighing sensor in the bagging area generates a negative weight change; S100 generates a negative weight step event based on the weight difference before and after the negative stabilization. The write-back unit filters scan events from the matched scan events that have a step amplitude compatible with the reference weight range and the negative weight step event; if the filtering result is unique, the event association between the filtered scan event and the corresponding positive weight step event is removed, the scan event is updated to the canceled or removed state, the corresponding positive weight step event is updated to the removed state, and the negative weight step event is updated to the matched state.

[0226] When a negative weight step event is compatible with the baseline weight range of multiple matched barcode scanning events, the processing and write-back unit generates an uncertain record associated with product removal and keeps the POS front-end in a pending review state. After the staff selects the removed product through the monitoring terminal, the processing and write-back unit removes the event association corresponding to the selected barcode scanning event. When a negative weight step event is incompatible with all matched barcode scanning events, an unidentified product removal record is generated, and the current transaction control state is retained.

[0227] Upon receiving a product item deletion event, the processing write-back unit reads the barcode scanning event corresponding to the deleted product item. If the barcode scanning event is not yet associated with a weight step event, its matching status is updated to "cancelled," and it is removed from the unassociated pending barcode scanning events. If the barcode scanning event is already associated with a positive weight step event, the event association is marked as "pending removal." After the corresponding negative weight step event is formed, the association is removed according to the product removal processing path. When staff confirm that the product has not actually been placed in the bagging area, the barcode scanning event can be directly updated to "cancelled," while retaining other events in the original transaction event context.

[0228] Upon receiving a manual confirmation request, the processing and write-back unit reads the target weight event identifier and the confirmed barcode scan event identifier from the manual confirmation request. If both the confirmed barcode scan event and the target weight step event are in a pending matching or pending verification state, an event association relationship is established between the two, and the status is updated to matched. If the confirmed barcode scan event is already associated with other weight step events, the original event association relationship is not overwritten; instead, an event status conflict record is generated. The monitoring terminal selects to remove the original association or cancel the current manual confirmation based on the event status conflict record.

[0229] For uncertain records formed by the combination of multiple products, the manual confirmation operation can specify multiple barcode scanning events to establish a combined association with a target weight step event; after the processing write-back unit checks that multiple barcode scanning events are not associated with other weight step events, it writes the combined association relationship and updates the multiple barcode scanning events and the target weight step event to the matched status.

[0230] The transaction status control unit checks the transaction status recovery conditions after each event-related status update. The checks include unmatched positive weight step events, suspected misscan records, associated uncertain records, weight change segments to be stabilized, and sensor status records in the current transaction session. If there are no unmatched positive weight step events, unprocessed suspected misscan records, or unprocessed associated uncertain records in the transaction event context, the transaction event context is marked as meeting the transaction status recovery conditions.

[0231] When a weight change segment awaiting stabilization exists in the transaction event context, the transaction status control unit maintains the current pending review state until S100 completes the generation of a weight step event or forms a sensor instability record. If a downgraded processing record corresponding to a weight sampling interruption exists, the transaction status control unit transfers the transaction to the staff review state according to the terminal configuration, or maintains the payment prohibition state. When a product SKU lacks a baseline weight range and the corresponding barcode scanning event is in a pending review state, the barcode scanning event can be updated to a reviewed state after staff confirmation; the reviewed state does not participate in subsequent automatic weight compatibility filtering.

[0232] When the transaction event context meets the conditions for transaction status recovery, the transaction status control unit generates a transaction recovery result and writes a transaction recovery instruction to the POS terminal. The transaction recovery result includes the transaction session identifier, the transaction control status before recovery, the transaction status after recovery, the identifier of the processed exception record, the updated event association, and the recovery time. After receiving the transaction recovery instruction, the POS terminal updates the pending review status or payment prohibition status to the transaction operation status; the original exception record is retained in the transaction event context, and its handling status is updated to the processed status.

[0233] When the transaction event context does not meet the transaction status recovery conditions, the transaction status control unit generates a transaction control record to maintain transaction control. This record includes an identifier for an unmatched positive weight step event, an identifier for an unprocessed suspected misscan record, an identifier for an unprocessed associated uncertain record, and the current transaction control status. Upon subsequent rescanning, product removal, manual confirmation, or changes in sensor status, the write-back unit re-executes the event status update and transaction status recovery condition check.

[0234] In one engineering implementation, a weight step event W301 is generated in transaction session T003. S300 generates a suspected missed scan record because the time-candidate barcode scanning event is empty. The transaction status control unit writes the checkout front-end to a pending review state. The customer rescans product B, and S100 generates a barcode scanning event S301. S200 regenerates a set of time-candidate barcode scanning events and a set of weight-compatible candidate barcode scanning events for W301, making S301 the only weight-compatible candidate. S300 establishes a one-to-one association between S301 and W301. The write-back unit updates the suspected missed scan record to a processed state. Since there are no other unmatched positive weight step events or unprocessed abnormal records in the current transaction session, the transaction status control unit generates a transaction recovery result.

[0235] In another engineering implementation, the barcode scanning event S302 has been associated with the positive weight step event W302; the customer deletes the corresponding transaction item and takes the item out of the bagging area, and the weighing sensor in the bagging area generates a negative weight step event W303. The step amplitude of W303 falls within the reference weight range of S302; the write-back unit removes the event association between S302 and W302, updates S302 to the canceled state, updates W302 to the removed state, and updates W303 to the matched state; the remaining unassociated barcode scanning events to be matched are rewritten into the transaction event context and proceed to the subsequent S200 processing.

[0236] In another engineering implementation, the target weight step event W304 is simultaneously compatible with the weights of both barcode scanning events S303 and S304, and the difference between candidate correlation values ​​is no greater than the candidate distinction threshold. S300 generates an indeterminate correlation record, and the transaction status control unit writes the checkout front end to a pending review status. Staff at the monitoring terminal confirm the correspondence between S304 and W304; the write-back unit establishes a one-to-one association between S304 and W304, updating both to a matched status, while S303 remains in a pending match status and continues to participate in subsequent candidate screening.

[0237] This step ultimately generates the transaction recovery result, maintained transaction control record, disposal write-back record, event association rollback record, product removal record, and updated transaction event context. The updated transaction event context continues to receive barcode decoding data output by the scanning device and weight sampling data output by the weighing sensor in the bagging area. After a new barcode scanning event or a new weight step event is generated, the processing link re-enters S200. After a transaction payment is completed, canceled, or timeout ends, the POS front end updates the transaction session to the ended state, the transaction event context stops receiving new events, and saves the barcode scanning event, weight step event, event association result, transaction control status, and disposal write-back record in that transaction session.

[0238] Example 2: Figure 2 This diagram illustrates a structural block diagram of a supermarket self-checkout loss prevention method based on mis-scanning and missed-scanning behavior analysis according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0239] The transaction event generation module 01 is used to receive a transaction session identifier, barcode decoding data, SKU baseline weight range, and weight sampling data; bind the barcode decoding data with the product SKU, scanning time, and the SKU baseline weight range to generate a matching scanning event; identify weight change segments in the weight sampling data and calculate the weight difference before and after stabilization to generate a weight step event; and write the matching scanning event and the weight step event into the transaction event context. Specifically, the transaction session identifier is provided by the cashier front end when the current transaction is established, the barcode decoding data is provided by the scanning device after barcode decoding, the SKU baseline weight range is obtained according to the product SKU corresponding to the barcode decoding data, and the weight sampling data is continuously provided by the weighing sensor in the bagging area according to the weight sampling time. The transaction event generation module generates a scanning event identifier for each valid barcode decoding data, and writes the transaction session identifier, the scanning event identifier, barcode information, the product SKU, the scanning time, the SKU baseline weight range, and the matching status into the matching scanning event. When the same product SKU appears consecutively, multiple matching scanning events are generated according to different scanning times and are not merged into the same record. The transaction event generation module arranges the weight sampling data according to the weight sampling time, smooths the continuous weight sampling data, and calculates the difference between adjacent weight sampling data. When multiple consecutive differences exceed the weight noise threshold, the corresponding weight change segment is extracted. When the time interval between adjacent weight change segments is less than the change segment merging threshold, the adjacent weight change segments are merged. The transaction event generation module reads the weight sampling data that is in a stable state before and after the weight change segment, forming a pre-stable weight and a post-stable weight. The difference between the post-stable weight and the pre-stable weight generates a step amplitude value, and the direction of change (positive or negative) is recorded based on the direction of the difference. The transaction session identifier, weight event identifier, occurrence time, stabilization time, step amplitude value, direction of change, stable state, and matching state are written into the weight step event. When the weight sampling data has not formed a stable state, the transaction event generation module retains the corresponding weight change segment in the transaction event context and does not generate a complete weight step event. When the weight sampling data is interrupted, the merging of weight change segments before and after the interruption is stopped, and the weight sampling interruption status is recorded in the transaction event context. When a product SKU lacks the SKU baseline weight range, the corresponding barcode scanning event is written into the transaction event context and marked as pending review. The transaction event generation module provides the transaction event context to the candidate event construction module; the transaction event context records multiple QR code scanning events to be matched, multiple weight step events, the occurrence time of each event, the matching status, and the associated status of existing events, for the candidate event construction module to call.

[0240] The candidate event construction module 02, connected to the transaction event generation module, is used to calculate the scanning interval sequence based on the transaction event context, and generate an event-related time range by combining the weight stabilization duration of the target weight step event; it filters time-candidate scanning events whose scanning time falls within the event-related time range from unassociated unmatched scanning events, and generates a weight-compatible candidate scanning event set according to the compatibility relationship between the step amplitude of the target weight step event and the SKU baseline weight range; specifically, the candidate event construction module receives the transaction event context output by the transaction event generation module, and when a positive weight step event in the unmatched state is added to the transaction event context, the positive weight step event is used as the target weight step event. The candidate event construction module arranges multiple unmatched scanning events in the current transaction session according to their scanning time, calculates the scanning time difference between adjacent unmatched scanning events, and generates the scanning interval sequence; scanning events in the matched, cancelled, timed-out, and pending-review states are not written into the scanning interval sequence. The candidate event construction module generates a mean and standard deviation of the scanning intervals based on the scanning interval sequence, and reads the occurrence time, stabilization time, and weight stabilization duration from the target weight step event. Using the occurrence time of the target weight step event as the end point of the time range, the module uses the time lengths corresponding to the mean scanning interval, the standard deviation of the scanning interval, and the weight stabilization duration as the event association time range length to generate the event association time range. When multiple consecutive scanning intervals are lower than the mean scanning interval minus twice the standard deviation of the scanning interval, the candidate event construction module records the corresponding multiple unmatched scanning events as a continuous high-speed scanning state, and increases the time length of the event association time range based on the continuous high-speed scanning state. The candidate event construction module reads unmatched scanning events with the same transaction session identifier as the target weight step event from the transaction event context; and writes scanning events with a matching status of unmatched, no event association established with other weight step events, not revoked, and whose scanning time is within the event association time range into the time candidate scanning events. The time-based candidate barcode scanning event record includes the barcode event identifier, product SKU, scanning time, the SKU's baseline weight range, the time distance between the scanning time and the occurrence time of the target weight step event, and the queue order. The candidate event construction module compares the step amplitude of the target weight step event with the SKU's baseline weight range for each time-based candidate barcode scanning event. When the step amplitude is within the corresponding SKU's baseline weight range, the corresponding time-based candidate barcode scanning event is written into the weight-compatible candidate barcode scanning event set; when the step amplitude is outside the corresponding SKU's baseline weight range, a weight incompatibility state is recorded.When the product SKU corresponding to the time-based candidate barcode scanning event lacks a baseline weight range, the corresponding pending verification status is retained and not written into the weight-compatible candidate barcode scanning event set. The candidate event construction module provides the event association and anomaly classification module with the target weight step event, the event association time range, the time-based candidate barcode scanning event, the weight-compatible candidate barcode scanning event set, and the continuous high-speed scanning status; the event association and anomaly classification module calls the number of time-based candidate barcode scanning events, the number of weight-compatible candidate barcode scanning events, each time distance, each step amplitude value, and each SKU baseline weight range to generate event association results.

[0241] The event association and anomaly classification module 03, connected to the candidate event construction module, is used to establish a one-to-one association between the unique scanning event and the target weight step event when the weight-compatible candidate scanning event set includes a unique scanning event, and update the associated scanning event and weight step event to a matched state; when the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or the weight-compatible candidate scanning event set includes multiple scanning events, it generates suspected missed scanning records, suspected incorrect scanning records, or uncertain association records, and generates event association results; specifically, the event association and anomaly classification module receives the target weight step event, time candidate scanning event, weight-compatible candidate scanning event set, and continuous high-speed scanning status provided by the candidate event construction module, and reads the scanning event matching status, weight step event matching status, and existing event association status in the transaction event context. When the set of weight-compatible candidate barcode scanning events includes a unique barcode scanning event, the event association and anomaly classification module takes the unique barcode scanning event as the target barcode scanning event; it generates an event association identifier and writes the transaction session identifier, the event association identifier, the barcode scanning event identifier of the target barcode scanning event, the weight event identifier of the target weight step event, and the association establishment time into the event association relationship. Before writing the event association relationship, the event association and anomaly classification module reads the matching status of the target barcode scanning event and the target weight step event again; when both are in the pending matching state, they are synchronously updated to the matched state, and the corresponding event identifiers are written into their event records; when either event has been revoked, removed, timed out, or has been associated with another event, the event association relationship is not written, and the status record of reconstructing candidate events is returned to the candidate event construction module. When the time-candidate scanning event is empty, the event association and anomaly classification module generates a suspected missed scan record. The suspected missed scan record records the transaction session identifier, target weight event identifier, step amplitude, event-related time range, number of time candidates, continuous high-speed scanning status, stable status, and unverified status. When the time-candidate scanning event is not empty and the weight-compatible candidate scanning event set is empty, the event association and anomaly classification module generates a suspected incorrect scan record. The suspected incorrect scan record records the target weight event identifier, multiple time-candidate scanning event identifiers, multiple product SKUs, multiple SKU baseline weight ranges, step amplitude, weight incompatibility status, and unverified status.When the weight-compatible candidate barcode scanning event set includes multiple barcode scanning events, the event association and anomaly classification module calculates the time distance, step amplitude, weight deviation relative to the corresponding SKU baseline weight range, and queue order of the multiple barcode scanning events to generate multiple candidate association values. When the difference between the smallest candidate association value and the second smallest candidate association value is greater than the candidate differentiation threshold, the barcode scanning event corresponding to the smallest candidate association value is taken as the target barcode scanning event, and the one-to-one association is established. When the difference is not greater than the candidate differentiation threshold, an association uncertainty record is generated. The association uncertainty record records the target weight event identifier, multiple candidate barcode scanning event identifiers, multiple candidate association values, candidate set status, continuous high-speed scanning status, and unverified status. When the set of weight-compatible candidate barcode scanning events is empty, the event association and anomaly classification module also reads multiple barcode scanning events arranged consecutively according to scanning time from the time-candidate barcode scanning events; it adds the lower limits of the SKU baseline weight range corresponding to the multiple barcode scanning events, and adds the upper limits of the SKU baseline weight range corresponding to the multiple barcode scanning events; when the step amplitude of the target weight step event is between the lower limit and the upper limit after addition, it establishes a combined event association relationship between the target weight step event and the multiple barcode scanning events, and updates the target weight step event and the multiple barcode scanning events to a matched state. The event association and anomaly classification module encapsulates normal event association relationships, suspected missed scan records, suspected wrong scan records, or uncertain association records into the event association result, and provides the event association result to the transaction status control and handling write-back module; the transaction session identifier, target weight event identifier, candidate barcode scanning event identifier, matching state, and unreviewed state in the event association result serve as inputs for the transaction status control and handling write-back module to write the transaction control state and update the event association state.

[0242] The transaction status control and handling write-back module 04, connected to the event association and anomaly classification module, is used to write the transaction control status to the POS front end based on the event association results; receive review operations and update the event status of the scan event to be matched, the weight step event, and their event association status; and generate a transaction recovery result when the updated transaction event context meets the transaction status recovery conditions. Specifically, the transaction status control and handling write-back module receives the event association results output by the event association and anomaly classification module, and generates the corresponding transaction control status based on the normal event association relationships, suspected missed scan records, suspected wrong scan records, or uncertain association records in the event association results. When the event association result includes normal event associations, the transaction status control and handling write-back module retains the current transaction status of the POS front-end and writes the normal event associations into the transaction event context. When the event association result includes suspected missed scan records, a pending review status is written to the POS front-end. When the event association result includes suspected incorrect scan records, a payment prohibition status is written to the POS front-end, and a recall information including transaction session identifier, target weight event identifier, candidate scan event identifier, product SKU, SKU baseline weight range, and step amplitude is sent to the monitoring terminal. When the event association result includes records with uncertain associations, a pending review status is written to the POS front-end, and the matching status of multiple candidate scan events is retained. The transaction status control and handling write-back module receives rescanning operations and product removal operations from the POS front-end, as well as manual confirmation operations from the monitoring terminal. Upon receiving a rescanning operation, the newly generated scan event to be matched is written into the transaction event context, and the corresponding target weight step event is provided to the candidate event construction module to regenerate the time-based candidate scan event and the weight-compatible candidate scan event set. When the regenerated weight-compatible candidate scan event set includes a unique scan event, the event association and anomaly classification module establishes an event association relationship and updates the original suspected missed scan or incorrect scan record to the processed state. Upon receiving a product removal operation, the negative weight step event in the transaction event context is read, and scan events whose SKU baseline weight range is compatible with the step amplitude of the negative weight step event are filtered from the matched scan events. When the filtering result is unique, the event association relationship between the scan event and the corresponding positive weight step event is removed, the scan event is updated to the canceled or removed state, the positive weight step event is updated to the removed state, and the negative weight step event is updated to the matched state. When a manual confirmation operation is received, the identifier of the confirmed barcode scanning event and the corresponding weight event identifier are read. If neither the confirmed barcode scanning event nor the corresponding weight step event has been associated with any other event, the event association relationship between the two is written and the two are updated to a matched state. If either event has been associated with any other event, the original event association relationship is retained and an event state conflict record is generated.After each review operation is completed, the transaction status control and handling write-back module rereads the transaction event context. If the transaction event context does not contain any unmatched positive weight step events, unprocessed suspected misscanning records, or unprocessed associated uncertain records, the transaction event context is marked as meeting the transaction status recovery conditions, and the transaction recovery result is generated. The transaction recovery result records the transaction session identifier, the transaction control state before recovery, the transaction state after recovery, the processed record identifier, the updated event association state, and the recovery time, and is output to the POS front end. If the transaction event context does not meet the transaction status recovery conditions, the current transaction control state is retained, and the weight event identifier and barcode scanning event identifier that were not fully reviewed are recorded. The transaction status control and handling write-back module returns the updated transaction event context to the candidate event construction module. After a new barcode scanning event to be matched or a new weight step event is written, the candidate event construction module re-executes candidate event construction based on the updated matching state.

Claims

1. A loss prevention method for supermarket self-checkout based on the analysis of incorrect and missed scan behavior, characterized in that, include: S100: Obtain transaction session identifier, barcode decoding data, SKU baseline weight range, and weight sampling data; The barcode decoding data is bound to the product SKU, scanning time, and baseline weight range to generate a barcode scanning event to be matched. Identify weight change segments and calculate the weight difference before and after stabilization to generate weight step events; Write to the transaction event context; S200. Calculate the scanning interval sequence based on the transaction event context, and determine the event association time range by combining the weight stabilization duration of the target weight step event. Filter time-based candidate barcode scanning events from unrelated unmatched barcode scanning events, and generate a weight-compatible candidate barcode scanning event set based on the compatibility relationship between step amplitude and baseline weight range. S300. When the weight-compatible candidate scanning event set includes a unique scanning event, a one-to-one association is established and the associated event is updated to a matched state. When the time candidate scanning event is empty, the weight-compatible candidate scanning event set is empty, or includes multiple scanning events, suspected missed scanning records, suspected wrong scanning records, or uncertain association records are generated respectively, and event association results are generated. S400: Write the transaction control status based on the event association results; receive the review operation and update the event association status; generate the transaction recovery result when the transaction event context meets the transaction status recovery conditions.

2. The method according to claim 1, characterized in that, The barcode scanning event to be matched includes a transaction session identifier, a barcode scanning event identifier, barcode information, product SKU, scanning time, baseline weight range, and matching status; the weight step event includes a transaction session identifier, a weight event identifier, an occurrence time, a stabilization time, a step amplitude, a change direction, a stabilization status, and a matching status; the matching status includes a pending matching status, a matched status, a cancelled status, and a timeout status.

3. The method according to claim 1, characterized in that, The process of identifying weight change segments and calculating the weight difference before and after stabilization includes: performing a moving average on the weight sampling data to calculate the difference between adjacent weight sampling data; extracting weight change segments whose differences continuously exceed a weight noise threshold, and merging adjacent weight change segments with a time interval less than a segment merging threshold; calculating the stable weight difference before and after the merged weight change segment, and generating a positive or negative weight step event based on the sign of the stable weight difference.

4. The method according to claim 1, characterized in that, The step of determining the event-related time range by combining the weight stabilization duration of the target weight step event includes: calculating the mean and standard deviation of the scanning intervals in the scanning interval sequence; taking the occurrence time of the target weight step event as the end point of the time range, determining the time range corresponding to the sum of the mean scanning interval, the standard deviation of the scanning interval, and the weight stabilization duration as the event-related time range; and writing unrelated unmatched scanning events whose scanning times are within the event-related time range into the time candidate scanning events.

5. The method according to claim 1, characterized in that, When the set of weight-compatible candidate barcode scanning events includes multiple barcode scanning events, the time distance and weight deviation corresponding to each barcode scanning event are calculated respectively; the time distance is the difference between the scanning time and the time when the target weight step event occurs; The weight deviation is the deviation of the step amplitude value relative to the corresponding reference weight range; the time distance, the weight deviation, and the queue order of the scanning event in the scanning event to be matched are weighted and calculated to generate candidate association values; when the difference between the smallest candidate association value and the second smallest candidate association value is greater than the candidate distinction threshold, the scanning event corresponding to the smallest candidate association value is determined as the target scanning event.

6. The method according to claim 4, characterized in that, Mark the scanning events corresponding to multiple consecutive scanning intervals that are lower than the average scanning interval minus twice the standard deviation of the scanning interval as continuous high-speed scanning status; increase the duration of the associated time range of the event according to the continuous high-speed scanning status, and write the continuous high-speed scanning status into the corresponding suspected missed scan record, suspected wrong scan record, or associated uncertain record.

7. The method according to claim 1, characterized in that, When the set of weight-compatible candidate scanning events is empty, multiple consecutive scanning events are selected from the time-selected candidate scanning events according to the scanning time order; the lower limit and upper limit of the reference weight range corresponding to the multiple consecutive scanning events are added together respectively; When the step amplitude is between the lower and upper limits after addition, a combined association is established between the target weight step event and the multiple consecutive scanning events, and the target weight step event and the multiple consecutive scanning events are updated to a matched state.

8. The method according to claim 1, characterized in that, Receive product item deletion events or negative weight step events; filter scan events from the matched scan events that have a reference weight range that is compatible with the step amplitude of the negative weight step event; Remove the event association between the selected barcode scanning events and the corresponding positive weight step events; The selected QR code scanning events and the positive weight step event are updated to the undone or removed state, and the remaining unassociated QR code scanning events to be matched are rewritten into the transaction event context.

9. The method according to claim 1, characterized in that, The step of writing the transaction control status based on the event association results includes: writing a pending review status based on the suspected missed scan record; writing a prohibited payment status based on the suspected wrong scan record and sending a request for assistance to the monitoring terminal; writing a pending review status based on the uncertain association record; when receiving a rescan operation, writing the newly added unmatched scan event into the transaction event context, and re-filtering the time-matching candidate scan events and weight-compatible candidate scan events; when receiving a product removal operation, updating the corresponding weight step event to the removed status; when receiving a manual confirmation operation, establishing an event association relationship between the confirmed scan event and the corresponding weight step event; and when there are no unmatched positive weight step events, suspected wrong scan records, or uncertain association records in the transaction event context, determining that the transaction event context meets the transaction status recovery conditions.

10. The method according to claim 1, characterized in that, Receive sensor status data from the weighing sensor in the bagging area; the sensor status data indicates that when weight sampling is interrupted, the generation of weight step events is stopped and a degradation processing record is generated; the sensor status data indicates that when the sensor is unstable, the weight change segment that has not formed a stable state is retained in the context of the transaction event. When a product SKU lacks a baseline weight range, the corresponding barcode scanning event to be matched will be updated to a pending review status.

Images