A method and device for monitoring lottery sales based on edge AI

Abstract

This application relates to the field of lottery sales technology, and in particular to a lottery sales supervision method and device based on edge AI. The method includes each sales terminal detecting the environment of its corresponding site to determine the current operating mode. When the operating mode is a standard sales mode, the terminal locally determines whether there are any user-related risk events. If so, a risk event report is generated and transmitted to a central cloud platform. The central cloud platform performs cross-site analysis based on the received risk event report to generate a regional dynamic watchlist, which is then distributed to the sales terminals. When a sales terminal identifies a user matching the regional dynamic watchlist, it performs a collaborative intervention operation. This application improves the effectiveness of lottery supervision.

Description

Technical Field

[0001] This application relates to the field of lottery sales technology, and in particular to a lottery sales supervision method and device based on edge AI. Background Technology

[0002] As an important public welfare undertaking, the lottery industry enjoys broad public participation globally. To ensure the fairness, impartiality, and transparency of lottery sales and maintain social stability, effective regulation of the sales process is crucial. In particular, preventing minors from purchasing lottery tickets, identifying and intervening in irrational large-stakes betting, and combating potential fraudulent activities are core issues in current lottery sales regulation.

[0003] Existing lottery sales monitoring technologies largely rely on centralized cloud platforms for post-event analysis of data uploaded from various sales terminals. When suspicious behavior is detected, risk events such as irrational large-scale betting often have already occurred, making it impossible for the central platform to intervene effectively at the moment of occurrence, resulting in a significant lag in regulatory measures. Furthermore, cross-site collaborative prevention and control capabilities are weak. If risky individuals, such as irrational bettors identified by one site, are found, they can easily move to other sales sites to continue their activities, making the identification and management of risky behavior extremely difficult. This reveals significant vulnerabilities in the monitoring network, thus requiring improvement. Summary of the Invention

[0004] To improve the effectiveness of lottery supervision, this application provides a lottery sales supervision method and device based on edge AI.

[0005] The above-mentioned objective of this application is achieved through the following technical solution:

[0006] A lottery sales supervision method based on edge AI, the method comprising:

[0007] Each sales terminal detects the environment of its corresponding site to determine the current working mode. When the working mode is the standard sales mode, it determines locally whether there are any risk events related to users. If there are, it generates a risk event report for the risk event and transmits the risk event report to the central cloud platform.

[0008] The central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic attention list, and then distributes the regional dynamic attention list to the sales terminal.

[0009] When the sales terminal identifies a user that matches the regional dynamic watchlist, it performs a collaborative intervention operation.

[0010] By adopting the above technical solution, localized environmental detection and initial risk event assessment at the sales terminal level enable immediate response at the scene of a risk event. High-value risk information, after initial screening, is uploaded, significantly reducing the computational and bandwidth pressure on the central cloud platform and protecting the privacy of ordinary users' data from being uploaded. Next, by aggregating and cross-site analyzing risk reports from different sites through the central cloud platform, high-risk individuals engaging in cross-regional activities that cannot be detected by a single site can be identified, thus generating a more comprehensive and dynamic watchlist. Finally, the sales terminal performs local matching and collaborative intervention based on the distributed list, achieving precise closed-loop handling of identified high-risk individuals. This ensures both privacy and system efficiency while constructing a complete and efficient regulatory system from initial screening at a single point to overall assessment and targeted intervention.

[0011] In a preferred embodiment, this application can be further configured such that: each sales terminal detects the environment of its corresponding site to determine the current operating mode, specifically including:

[0012] The current environment image is captured by the camera of the sales terminal, and the image sharpness parameter and scene dynamics parameter are calculated by using the frequency domain transformation algorithm and the background feature point tracking algorithm, respectively.

[0013] While comparing the image sharpness parameter with a preset sharpness threshold, the scene dynamics parameter is also compared with a preset dynamics threshold.

[0014] When the image clarity parameter is lower than the clarity threshold or the scene dynamics parameter is higher than the dynamics threshold, the working mode is determined to be the security alert mode and a local alarm mechanism is triggered; otherwise, the working mode is determined to be the standard sales mode.

[0015] By adopting the above technical solutions and introducing a dynamic switching mechanism for working modes, the robustness and reliability of the system are greatly enhanced. By using the joint detection of two parameters—image clarity and scene dynamism—the system can accurately identify abnormal environmental situations such as obstructed or damaged cameras or fights and disturbances occurring on-site. In these scenarios where the AI ​​analysis foundation is no longer reliable, the system automatically switches to a security alert mode and suspends AI risk analysis, avoiding erroneous risk judgments due to low-quality input data. This ensures the effectiveness and accuracy of subsequent risk analysis processes and improves the stability of the entire monitoring system.

[0016] In a preferred embodiment, this application can be further configured such that, when the working mode is a standard sales mode, the local determination of whether a user-related risk event exists specifically includes:

[0017] By using a preset model to analyze the user's biometric information, it is possible to determine whether the user is at risk of age non-compliance.

[0018] According to a preset time period, the cumulative betting amount of the user at the sales terminal is calculated. If the cumulative betting amount exceeds the preset cumulative warning limit, it is determined that the user has a risk of abnormal user status.

[0019] When it is determined that there is a risk that the user's age is not compliant and / or the user's status is abnormal, a risk event related to the user is generated.

[0020] By adopting the above technical solution and combining two typical risk scenarios—age non-compliance and exceeding the cumulative betting limit—comprehensive coverage of risk dimensions is achieved. On the one hand, by using a lightweight model deployed locally on the terminal to analyze user biometric information, it is possible to effectively identify and prevent minors from purchasing lottery tickets without infringing on user privacy. On the other hand, by monitoring the cumulative betting amount over a period of time rather than the amount of a single bet, it is possible to effectively identify addictive or irrational lottery purchasing behavior that uses multiple small bets to evade supervision, significantly improving the ability to detect potential problem gamblers.

[0021] In a preferred embodiment, this application can be further configured such that: the central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic watchlist, specifically including:

[0022] The anonymous biometric information of the user is obtained from the risk event report, and the anonymous biometric information is obtained by processing the biometric information.

[0023] Based on the anonymous biometric information, determine the number of risk event reports containing the user's anonymous biometric information within a preset time window, and determine whether the number meets the identification criteria;

[0024] If the quantity meets the identification criteria, the user's anonymous biometric information is written into the regional dynamic watchlist.

[0025] By employing the aforementioned technical solution, and aggregating anonymized biometric information reported from various terminals in the cloud, and performing statistical analysis based on this data, it is possible to accurately identify the same individual who repeatedly triggers risks at different times and sales sites. This identification method, based on cross-site correlation analysis, effectively filters out single and accidental risk events, focusing on users with persistent and high-probability risk behaviors. This results in a more accurate watchlist and more effective utilization of regulatory resources. Furthermore, because the entire process uses irreversibly anonymized biometric information, it ensures that user privacy is strictly protected while achieving effective regulation.

[0026] In a preferred embodiment, this application can be further configured such that the method also includes:

[0027] Based on the event type of the risk event, obtain the basic risk score corresponding to the event type;

[0028] Based on the anonymous biometric information, analyze the distribution patterns of the number of sales terminal reports and event types associated with the anonymous biometric information;

[0029] Based on the basic risk score, the number of reports from the sales terminal, and the event type distribution pattern, the user's total risk score is calculated using a preset weighted algorithm.

[0030] The calculated total risk score is compared with a preset risk level mapping table to obtain the user's risk level, and the user's risk level is written into the regional dynamic watchlist.

[0031] By adopting the above technical solution and introducing a multi-dimensional and weighted total risk score model, a refined and quantitative assessment of user risk levels is achieved. It not only considers the type and severity of risk events (basic risk score) and the frequency of occurrence (number of reports), but also introduces the dimension of event type distribution pattern, which can provide a deeper understanding of users' behavioral intentions. The resulting watchlist with risk levels provides clear action instructions for downstream collaborative intervention, making differentiated and graded precise intervention possible and avoiding a one-size-fits-all approach to extensive management.

[0032] In a preferred embodiment, this application can be further configured such that: when the sales terminal identifies a user matching the regional dynamic watchlist, it performs a collaborative intervention operation, specifically including:

[0033] When a new user appears within the camera's field of view at the sales terminal, the anonymous biometric information of the new user is obtained.

[0034] The anonymous biometric information of the new user is compared with the anonymous biometric information in the regional dynamic watchlist to determine a similarity score;

[0035] If the similarity is higher than the preset matching threshold, it is determined that a user matching the regional dynamic watchlist has been identified, and the collaborative intervention operation is triggered according to the risk level.

[0036] By adopting the above technical solution, real-time and efficient feature comparison is performed locally at the sales terminal, enabling the immediate identification of high-risk users on the watchlist. The entire identification process does not require real-time communication with the cloud, resulting in a fast response time and ensuring that intervention measures are triggered the instant a user makes a purchase. Simultaneously, triggering corresponding intervention operations based on the user's risk level achieves precise matching of regulatory intensity, ensuring the effectiveness of regulation, optimizing the experience for normal users, and achieving a good balance between regulatory strength and business operations.

[0037] In a preferred embodiment, this application can be further configured such that: triggering the collaborative intervention operation based on the risk level specifically includes:

[0038] If the risk level is high, the betting function of the sales terminal will be locked, and the highest level alarm notification will be sent to the preset supervisor.

[0039] If the risk level is medium risk, the large-amount betting function of the sales terminal will be restricted, and the regulatory personnel at the site where the sales terminal is located will be notified.

[0040] By adopting the aforementioned technical solution and providing clear and specific intervention strategies directly linked to risk levels, differentiated handling can be effectively implemented. For high-risk users, strong measures such as locking betting and alerting higher-level regulatory personnel can decisively cut off major risks; for medium-risk users, gentler measures such as restricting large bets and alerting site staff serve as warnings and oversight. This specific operational guidance ensures that regulatory strategies can be executed automatically and accurately by the system, improving the efficiency and standardization of interventions.

[0041] In a preferred embodiment, this application can be further configured such that the method also includes:

[0042] A collaborative intervention report is generated by the sales terminal that performs the aforementioned collaborative intervention operation;

[0043] The collaborative intervention report is uploaded to the central cloud platform and stored in association with the risk event report to build a complete risk event tracing chain.

[0044] By adopting the above technical solutions and introducing a mechanism for generating and uploading intervention reports, and linking them with the original risk reports, a complete closed-loop management process from risk discovery to risk management and feedback on management is constructed. This complete risk event tracking log not only provides tamper-proof data evidence for the effectiveness of regulatory work, but also provides a valuable data foundation for subsequent compliance audits, strategy optimization, and model iteration, thereby enabling the entire regulatory system to have the ability to self-improve and continuously evolve.

[0045] The above-mentioned objective 2 of this application is achieved through the following technical solution:

[0046] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described edge AI-based lottery sales supervision method.

[0047] In summary, this application includes at least one of the following beneficial technical effects:

[0048] 1. By conducting localized environmental monitoring and initial risk event assessment at the sales terminal, a real-time response can be made at the scene of a risk event. High-value risk information after initial screening is uploaded, greatly reducing the computing and bandwidth pressure on the central cloud platform and protecting the privacy of ordinary users' data from being uploaded. Next, by aggregating and cross-site analyzing risk reports from different sites through the central cloud platform, high-risk individuals with cross-regional activities that cannot be detected by a single site can be identified, thereby generating a more global dynamic watchlist. Finally, the sales terminal performs local matching and collaborative intervention based on the distributed list, realizing precise closed-loop handling of identified high-risk individuals. Thus, while ensuring privacy and system efficiency, a complete and efficient regulatory system is built, from single-point initial screening to global assessment and targeted intervention.

[0049] 2. By introducing a multi-dimensional and weighted total risk score model, a refined and quantitative assessment of user risk levels is achieved. It not only considers the type and severity of risk events (i.e., the basic risk score) and the frequency of occurrence (i.e., the number of reports), but also introduces the dimension of event type distribution pattern. This allows for a deeper understanding of users' behavioral intentions. The resulting watchlist with risk levels provides clear action instructions for downstream collaborative intervention, making differentiated and graded precise intervention possible and avoiding a one-size-fits-all approach to extensive management.

[0050] 3. By introducing a mechanism for generating and uploading intervention reports and linking them to original risk reports, a complete closed-loop management process was constructed, from risk discovery to risk management and then to management feedback. This complete risk event tracking log not only provides tamper-proof data evidence for the effectiveness of regulatory work, but also provides a valuable data foundation for subsequent compliance audits, strategy optimization, and model iteration, thereby enabling the entire regulatory system to have the ability to self-improve and continuously evolve. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating the implementation of a lottery sales supervision method based on edge AI in one embodiment of this application.

[0052] Figure 2 This is a flowchart illustrating the implementation of step S10 in a lottery sales supervision method based on edge AI in one embodiment of this application.

[0053] Figure 3 This is a flowchart illustrating the implementation of step S13 and beyond in a lottery sales supervision method based on edge AI in one embodiment of this application.

[0054] Figure 4 This is a flowchart illustrating the implementation of step S20 in an embodiment of the lottery sales supervision method based on edge AI in this application.

[0055] Figure 5 This is another implementation flowchart of the lottery sales supervision method based on edge AI in one embodiment of this application;

[0056] Figure 6 This is a flowchart illustrating the implementation of step S30 in a lottery sales supervision method based on edge AI in one embodiment of this application.

[0057] Figure 7 This is a flowchart illustrating the implementation of step S33 in a lottery sales supervision method based on edge AI in one embodiment of this application.

[0058] Figure 8 This is another implementation flowchart of the lottery sales supervision method based on edge AI in one embodiment of this application;

[0059] Figure 9 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0060] The following embodiments will help those skilled in the art to further understand the function of this application, but do not limit this application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application. These all fall within the protection scope of this application.

[0061] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0062] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0063] The present application will be further described in detail below with reference to the accompanying drawings.

[0064] In one embodiment, such as Figure 1 As shown, this application discloses a lottery sales supervision method based on edge AI, which specifically includes the following steps:

[0065] S10: Each sales terminal detects the environment of the corresponding site to determine the current working mode. When the working mode is the standard sales mode, it judges locally whether there are risk events related to users. If there are, it generates a risk event report and transmits the risk event report to the central cloud platform.

[0066] Specifically, such as Figure 2 As shown, step S10 specifically includes:

[0067] S11: The current environment image is captured by the camera of the sales terminal, and the image sharpness parameter and scene dynamics parameter are calculated by using the frequency domain transformation algorithm and the background feature point tracking algorithm, respectively.

[0068] Specifically, the preferred frequency domain transformation algorithm is the Fast Fourier Transform (FFT), which transforms the image from the spatial domain to the frequency domain. Edges, textures, and other details in the image correspond to high-frequency components, while smooth background areas correspond to low-frequency components. A quantized sharpness parameter is obtained by calculating the proportion of high-frequency component energy in the total energy. The preferred background feature point tracking algorithm is the Kanade-Lucas-Tomasi (KLT) optical flow method. This algorithm first selects several stable and easily trackable feature points in non-foreground areas of the image, such as corners or fixed posters. Then, it tracks the pixel displacements of these feature points in consecutive video frames. By calculating the average displacement of all background feature points, the scene dynamics parameter is obtained.

[0069] Furthermore, the advantage of using dual-parameter joint detection lies in its coverage of two typical environmental anomalies. The sharpness parameter is primarily used to detect problems with the camera itself, such as malicious lens obstruction, dust accumulation, or focusing failure. The scene dynamics parameter is used to detect abnormal events in the environment, such as arguments, fights, or rapid gathering and movement of crowds. These two parameters are independent of each other, but together they form the fundamental guarantee for the physical security of the terminal and the stability of the operating environment.

[0070] S12: While comparing the image sharpness parameter with the preset sharpness threshold, the scene dynamics parameter is also compared with the preset dynamics threshold.

[0071] Specifically, a preset clarity threshold, such as Threshold_Clarity=0.3, represents the minimum acceptable standard for image quality. If the calculated clarity parameter is lower than this threshold, it means that image details are severely lost, and subsequent AI analysis, such as facial recognition, will be unreliable. A preset dynamism threshold, such as Threshold_Motion=20 pixels / frame, represents the general upper limit of scene stability. If the calculated scene dynamism parameter is higher than this threshold, it may mean that a sudden event has occurred, and the system's priority should shift to safety alerts rather than normal sales. These two thresholds are not fixed; they can be set as configurable parameters. During system initialization or when instructions are remotely issued by the central cloud platform, adjustments can be made according to the specific environment of different sites. For example, for a sales site located in a transportation hub with high foot traffic, the dynamism threshold can be appropriately increased to avoid frequent false alarms caused by normal foot traffic.

[0072] S13: When the image sharpness parameter is lower than the sharpness threshold or the scene dynamics parameter is higher than the dynamics threshold, the working mode is determined to be the security alert mode and the local alarm mechanism is triggered; otherwise, the working mode is determined to be the standard sales mode.

[0073] Specifically, once any of the above comparison conditions is met, such as the resolution parameter dropping to 0.4, it means that the camera may be covered by fog or dust. At this time, it will immediately switch to the safety alert mode. In this mode, all AI functions involving user biometric information analysis will be suspended to prevent incorrect judgments. At the same time, a semi-transparent red layer will be overlaid on the terminal's software interface and a message will be displayed indicating that the device environment is abnormal. Please check the text on the camera and record a detailed system log. Conversely, if all parameters are within the normal range, the working mode will be set to the standard sales mode. At this time, the terminal's AI engine will be fully activated and running silently in the background, continuously analyzing the users within the field of view.

[0074] Specifically, such as Figure 3 As shown, step S10 specifically includes:

[0075] S14: By using a preset model to analyze the user's biometric information, it is possible to determine whether the user is at risk of age non-compliance.

[0076] Specifically, the biometric information here refers to the real-time capture of a user's face, either frontal or near-frontal, via a camera. When the camera detects a face, it captures an image of the face region and inputs it into a preset model. This preset model is a lightweight convolutional neural network model, such as one built on the MobileNetV3 architecture, that is locally deployed on the terminal and trained for age classification tasks. The model receives a pre-processed face image (e.g., cropped and scaled to 112x112 pixels), performs forward computation, and outputs a probability distribution vector. This vector corresponds to the confidence scores for multiple predefined age groups, such as 0-17 years, 18-30 years, and 31-50 years. When the confidence score for the 0-17 age group is the highest and exceeds a preset threshold, such as 0.85, the system determines that there is a risk of age non-compliance.

[0077] Furthermore, the entire age estimation process is completed locally on the edge device, without uploading the user's original facial image; de-identified evidence is only uploaded when a risk is triggered. The model itself is designed as an age classifier rather than an identity recognizer; it doesn't know who the user is, only which age group they might belong to, which greatly reduces the risk of personal privacy leaks.

[0078] S15: Calculate the user's cumulative betting amount at the sales terminal according to the preset time period. If the cumulative betting amount exceeds the preset cumulative warning limit, it is determined that the user has a risk of abnormal user status.

[0079] Specifically, this step aims to identify potentially irrational or addictive betting behavior. To this end, the system uses the anonymous facial feature vector extracted in the preceding steps—such as a high-dimensional floating-point array that cannot be reversed to an image—as a temporary user identifier. When a user places a bet, the system records their anonymous feature vector and the bet amount. A preset time period, such as 30 minutes, defines a monitoring window. Within this window, the system accumulates the betting amounts of all records with the same anonymous feature vector. If the accumulated amount exceeds a preset cumulative warning threshold, such as 500 yuan, the user's status is deemed abnormal.

[0080] Furthermore, this cumulative amount-based monitoring method is more effective than monitoring single large bets. This is because it can identify an avoidance behavior known as "structured betting," where users use multiple small bets to avoid triggering single-bet limits. By accumulating over time, this solution can more accurately detect this continuous, high-frequency potential risk behavior. Once the monitoring window ends (e.g., if the user is away for more than 30 minutes), the anonymous feature vector and its associated betting records are cleared to protect user privacy.

[0081] S16: When it is determined that there is a risk of user age non-compliance and / or user status abnormality, generate a risk event related to the user.

[0082] Specifically, the generation of risk events is the final output of local risk identification. When either condition in step S14 or S15 is met, the system immediately instantiates a risk event object. This object is serialized into a structured risk event report, such as a JSON data packet, ready to be uploaded to the central cloud platform. This JSON packet contains a set of key-value pairs that clearly describe the entire event. For example, a JSON string with the content {"event_id":"EVT-20231027-1A4B8C","terminal_id":"T008-BJ-CY","timestamp":"2023-10-27T14:30:15Z","risk_type":["AGE_UNDER_SPEC"],"evidence":{"blurred_face_hash":"a1b2c3d4...","age_prediction":{"0-17":0.91,"18-30":0.08}},"anonymous_feature_vector":[0.12,-0.45,...,0.89]} is generated. This string is then added to an upload queue, waiting to be sent to the central cloud platform via an encrypted channel.

[0083] S20: The central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic watchlist, and then distributes the regional dynamic watchlist to the sales terminals.

[0084] Specifically, such as Figure 4 As shown, step S20 specifically includes:

[0085] S21: Obtain anonymous biometric information of users from risk event reports. The anonymous biometric information is obtained through biometric processing.

[0086] Specifically, the central cloud platform listens for and receives risk event reports uploaded from all edge sales terminals within its jurisdiction. For each received report, such as the JSON data packet generated in step S110, the cloud platform parses its content and extracts the value of the "anonymous_feature_vector" field. This value is a high-dimensional floating-point vector, representing the user's anonymous biometric information. This vector is an embedded representation obtained by using deep learning models such as FaceNet or ArcFace to perform forward propagation calculations on the user's facial image at the edge. It does not contain any image information itself, but preserves the uniqueness or distinguishability between individuals.

[0087] S22: Based on the anonymous biometric information, determine the number of risk event reports containing the user's anonymous biometric information within a preset time window, and determine whether the number meets the identification conditions.

[0088] Specifically, the cloud platform sets a preset time window, such as the past 30 days, to define the analysis timeframe. For newly received anonymous biometric information, the cloud platform performs a similarity search in the vector database, finding all stored vectors within the past 30 days with a similarity higher than a specific threshold, such as a cosine similarity greater than 0.9. These found similar vectors are considered to belong to the same user. Subsequently, the system counts these risk event reports belonging to the same user, obtaining a quantity value. Determining whether the quantity meets the identification criteria is a key decision point in deciding whether to add the user to the watchlist. This identification criterion can be a simple quantity threshold, such as "if the cumulative number of risk event reports from different sales terminals is greater than or equal to 3, then the identification criterion is met." This design aims to filter out accidental and single-point risk events, while accurately capturing individuals who repeatedly exhibit similar risk behaviors in different locations and at different times; these individuals have higher regulatory value.

[0089] S23: If the quantity meets the identification criteria, write the user's anonymous biometric information into the regional dynamic watchlist.

[0090] Specifically, when the judgment result of the aforementioned steps is yes, the system will perform a write operation. The regional dynamic watchlist can be implemented as a database table or a specific dataset in a distributed caching system such as Redis. The write operation does not simply store anonymous biometric information, but rather creates a record containing richer information. This record includes at least the anonymous biometric information as the primary key, the first discovery time, the most recent discovery time, the cumulative number of triggers, a list of risk types involved, and all associated event IDs.

[0091] Furthermore, the dynamism of this list is reflected in two aspects. First, the list is continuously updated; once a new user meets the conditions of step S22, they will be added. Second, the list is time-sensitive. The system can set a cooling-off or observation period, such as 90 days. If a user already on the list does not trigger any new risk events within 90 days, the system can automatically remove them from the list or lower their attention level. This dynamic update mechanism ensures the effectiveness of monitoring resources, keeping them focused on recently active high-risk individuals. After the update is completed, the latest version of this regional dynamic attention list will be securely distributed to all sales terminals within the region.

[0092] In one embodiment, such as Figure 5 As shown, the method also includes:

[0093] S221: Based on the event type of the risk event, obtain the basic risk score corresponding to the event type.

[0094] Specifically, the central cloud platform maintains an internal table mapping event types to basic risk scores. This table assigns an initial score to each risk event based on its severity and regulatory attention. For example, age non-compliance (AGE_UNDER_SPEC) might be considered a high-risk event with a basic risk score of 85; while abnormal user status – exceeding betting limits (AMOUNT_EXCEEDED) might be considered medium risk with a basic risk score of 50. When the cloud platform processes a new risk event report, it first parses the "risk_type" field in the report and retrieves the corresponding basic score from this table.

[0095] Furthermore, this comparison table can be dynamically configured and adjusted by the administrator. As regulatory policies change or awareness of new risks deepens, the scores in the table can be updated at any time. For example, if a new type of group fraud is discovered, a new event type can be added and assigned a very high base risk score, such as 80 points, enabling the system to respond quickly to new threats.

[0096] S222: Based on anonymous biometric information, analyze the distribution patterns of the number of sales terminal reports and event types of risk event reports associated with anonymous biometric information.

[0097] Specifically, after obtaining the base score for a single event, the system begins to aggregate the user's historical behavioral data. By performing a similarity search on the anonymized biometric information of the current event in the vector database, the system can find all historical risk event reports associated with the user. Next, the system counts the total number of these reports, i.e., the number of reports submitted by the sales terminal. Simultaneously, the system analyzes the distribution of all "risk_type" fields in these reports. For example, in the five events associated with user A, four were for exceeding betting limits and one was for age non-compliance; this is his event type distribution pattern. The analysis of event type distribution patterns goes far beyond simple counting. The system can identify more complex behavioral patterns, such as whether a user triggers multiple types of risks simultaneously, or whether they trigger a specific type of risk in a concentrated period of time. These patterns themselves are also important dimensions of risk assessment. For example, a user involved in both age non-compliance and betting anomalies clearly poses a higher potential risk than a user involved in only a single betting anomaly.

[0098] S223: Based on the basic risk score, the number of reports from sales terminals, and the event type distribution pattern, the user's total risk score is calculated using a preset weighted algorithm.

[0099] Specifically, risk indicators from multiple dimensions are integrated into a single total score. The preset weighting algorithm can be a non-linear formula: Total Risk Score = Σ(Base Risk Score_i) × W_freq × log(Number of Reports from Sales Terminals + 1) × W_pattern × (Pattern Complexity Factor), where Σ(Base Risk Score_i) is the sum of the base scores of all related events for the user; W_freq and W_pattern are the weight coefficients corresponding to the number of reports and the distribution pattern, respectively; the log() function is used to smooth the impact of the number of reports, preventing it from growing too linearly; and the pattern complexity factor is a multiplier calculated based on the distribution pattern analyzed in step S222. For example, for users involved in multiple risk types, the factor is 1.5, and for a single type, it is 1.0. The more times a sales terminal reports, the higher the risk, but its diminishing marginal impact is reflected by the log function. At the same time, users who exhibit behaviors that trigger multiple types of risks or trigger a specific type of risk behavior pattern in a short period of time will be given a higher risk weight, as this often indicates a stronger risk tendency or subjective intention.

[0100] S224: Compare the calculated total risk score with a preset risk level mapping table to obtain the user's risk level, and write the user's risk level into the regional dynamic watchlist.

[0101] Specifically, the cloud platform maintains a mapping table between total risk score and risk level, defining clear boundaries for action instructions. For example, a total risk score in the range [0, 50) corresponds to no risk, [50, 100) to a low risk level, [100, 200) to a medium risk level, and scores above 200 to a high risk level. The system compares the calculated total risk score with this table to determine its level. Then, when generating or updating a regional dynamic watchlist, in addition to writing the user's anonymous biometric information, this calculated risk level is also written as a key field.

[0102] Furthermore, once this list, including risk levels, is distributed to sales terminals, the terminals can take differentiated measures based on the different levels. For example, low-risk users can simply have their information recorded in the background; medium-risk users can have some betting functions restricted on their next purchase and an internal notification will pop up for the salesperson; and high-risk users can have all betting functions restricted and be required to undergo manual verification by the salesperson. This tiered response mechanism ensures that regulatory resources are precisely allocated to where they are most needed, achieving a balance between efficiency and accuracy.

[0103] S30: When a sales terminal identifies a user that matches the regional dynamic watchlist, it performs a collaborative intervention.

[0104] Specifically, such as Figure 6 As shown, step S30 specifically includes:

[0105] S31: When a new user appears within the camera's field of view at the sales terminal, obtain the new user's anonymous biometric information.

[0106] Specifically, the camera at the point of sale continuously monitors a designated area, such as the counter. Once a stable and clear facial image is detected within this area, the system triggers a feature extraction process. This process preprocesses the captured facial image, such as cropping, alignment, and normalization, to convert the facial image into an anonymous feature vector, which is the anonymous biometric information of the new user. To ensure efficiency and real-time performance, not every frame of the video stream is processed. Instead, a trigger-based mechanism is used, where feature extraction is only performed when the face remains in the frame for more than a preset time, such as 5 seconds, and the image quality meets requirements such as clarity and illumination exceeding thresholds. The extracted anonymous biometric information is temporarily stored in memory for immediate comparison in step S32. If no match is found after comparison, the information is immediately destroyed, and no biometric information of users not of interest is persistently stored locally.

[0107] S32: Compare the anonymous biometric information of new users with the anonymous biometric information in the regional dynamic watchlist to determine a similarity score.

[0108] Specifically, after obtaining the anonymous biometric information of a new user, the system immediately performs a 1:N vector comparison on a locally loaded regional dynamic watchlist. This watchlist is distributed from the central cloud platform in step S120. The comparison process is accomplished by calculating the cosine similarity between the new user's feature vector and each feature vector in the watchlist. Cosine similarity effectively measures the directional consistency between two high-dimensional vectors, and its value range is typically between 0 and 1. The higher the score, the greater the probability that the two feature vectors correspond to the same person. The system ultimately obtains a highest similarity score and the corresponding watchlist entry. For example, the comparison result shows that the new user has the highest match with the entry in watchlist ID W-XYZ-007, with a similarity score of 0.96. This score will serve as the direct basis for the decision in the next step.

[0109] S33: If the similarity is higher than the preset matching threshold, it is determined that a user matching the regional dynamic watchlist has been identified, and a collaborative intervention operation is triggered according to the risk level.

[0110] Specifically, the system compares the highest similarity score calculated in the previous step with a preset matching threshold, such as 0.92. This threshold was determined through extensive testing to ensure extremely high recognition accuracy. If the score exceeds the threshold, the system confirms successful identification of a user on the watchlist. At this point, the system immediately reads the user's risk level field from the matched list entries. Subsequently, based on this specific risk level, the system selects and executes the corresponding collaborative intervention operation from a preset level-action strategy library.

[0111] Specifically, such as Figure 7 As shown, step S33 specifically includes:

[0112] S331: If the risk level is high, lock the betting function of the sales terminal and send the highest level alarm notification to the preset supervisor.

[0113] Specifically, when a matched user's risk level is identified as high-risk, the sales terminal will immediately implement the strongest intervention measures. Locking the betting function means the terminal's application software interface will become inoperable; all betting-related buttons, such as number selection and payment confirmation, will be grayed out or covered by a mask, fundamentally preventing the user from making any betting actions. Simultaneously, the system immediately sends a high-priority alarm message to the central cloud platform via a built-in communication module such as MQTT or an HTTPS client. This alarm message contains key information such as time, site ID, user anonymous ID, and risk level. Upon receiving it, the cloud platform will trigger a preset alarm escalation process. For example, it might send a notification with the highest-level alarm prefix to the mobile device of the key regulatory officer in the region via an SMS gateway or enterprise instant messaging API, ensuring that the risk event is detected immediately and offline emergency plans are activated.

[0114] S332: If the risk level is medium risk, the large-amount betting function of the sales terminal will be restricted, and the regulatory personnel at the site where the sales terminal is located will be notified.

[0115] Specifically, when a user's risk level is identified as medium risk, the system will implement more targeted restrictions. This restriction on large bets means that while the user can still place regular small bets, the betting button will become unavailable if the amount of a single bet or the total daily bet exceeds a preset medium-risk threshold, such as 500 yuan per bet. Simultaneously, a notification will be sent to the supervisors at the sales terminal's location, indicating that the user is a medium-risk individual and requesting close monitoring of their betting behavior. This notification to the site supervisor, typically the store manager or shift supervisor, can be an internal system message or integrated into their daily management app, ensuring immediate awareness at the site level and enabling manual intervention.

[0116] Furthermore, if the risk level is low, the system will perform a silent logging operation. This operation will not affect the terminal functions or interface; it will only silently record the user's visit time and site information in the background log.

[0117] In one embodiment, such as Figure 8 As shown, the method also includes:

[0118] S40: A collaborative intervention report is generated by the sales terminal that performs the collaborative intervention operation.

[0119] Specifically, after any collaborative intervention operation is performed in step S33—whether it's locking, restricting, or silently recording—the sales terminal's system will automatically generate a structured collaborative intervention report. This report is a data package that includes at least the intervention timestamp, the sales terminal's ID, the anonymized biometric information of the intervened user, the matched risk level, a description of the specific intervention measures performed (e.g., locking betting functionality or restricting large bets), and the intervention result (e.g., successful execution). In some configurations, the report may also include a remarks field for the salesperson to fill in. For example, the salesperson can briefly record the user's on-site reaction (e.g., the user leaves without objection) or any special circumstances, providing richer contextual information for subsequent manual review and auditing.

[0120] S50: Upload the collaborative intervention report to the central cloud platform and store it in conjunction with the risk event report to build a complete risk event tracing chain.

[0121] Specifically, after generating a collaborative intervention report, the sales terminal uploads it to the central cloud platform via a secure network channel such as HTTPS. Upon receiving the report, the cloud platform uses the anonymous biometric information contained within to retrieve all historical risk event reports related to that user from its database. Then, it logically links this new collaborative intervention report with these original risk event reports. For example, in the database, the record for this collaborative intervention report will contain a foreign key or identifier pointing to the original set of risk event reports. This associated storage constructs a complete and tamper-proof risk event tracing chain. When regulators query any high-risk user in the background, they can clearly see a complete event timeline, from the user's initial triggering of a risk event at site A, to the cloud platform analyzing their cross-site behavior and raising their risk level, to the user being successfully identified and subjected to intervention at site B, and finally to the intervention result reported by site B. This complete tracing chain provides a solid data foundation for regulatory effectiveness assessment, compliance auditing, and system strategy optimization, achieving closed-loop management of the entire process from risk discovery to risk management and review of management results.

[0122] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0123] In one embodiment, an electronic device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores data such as risk event reports, regional dynamic watch lists, and total risk scores. The network interface communicates with external terminals via a network. When executed by the processor, the computer program implements an edge AI-based lottery sales supervision method.

[0124] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0125] Each sales terminal detects the environment of its corresponding site to determine the current working mode. When the working mode is the standard sales mode, it determines locally whether there are any risk events related to users. If so, it generates a risk event report and transmits the risk event report to the central cloud platform.

[0126] The central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic watch list, and then distributes the regional dynamic watch list to the sales terminals.

[0127] When a sales terminal identifies a user that matches the regional dynamic watchlist, it performs a collaborative intervention.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0129] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0130] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A lottery sales supervision method based on edge AI, characterized in that, The lottery sales supervision method based on edge AI includes setting up multiple sales terminals in various geographical areas and establishing a central cloud platform for each geographical area. Each sales terminal detects the environment of its corresponding site to determine the current working mode. When the working mode is the standard sales mode, it determines locally whether there are any risk events related to users. If there are, it generates a risk event report for the risk event and transmits the risk event report to the central cloud platform. The central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic attention list, and then distributes the regional dynamic attention list to the sales terminal. When the sales terminal identifies a user that matches the regional dynamic watchlist, it performs a collaborative intervention operation. Each sales terminal detects the environment of its corresponding site to determine its current operating mode, specifically including: The current environment image is captured by the camera of the sales terminal, and the image sharpness parameter and scene dynamics parameter are calculated by using the frequency domain transformation algorithm and the background feature point tracking algorithm, respectively. While comparing the image sharpness parameter with a preset sharpness threshold, the scene dynamics parameter is also compared with a preset dynamics threshold. When the image clarity parameter is lower than the clarity threshold or the scene dynamics parameter is higher than the dynamics threshold, the working mode is determined to be the security alert mode and a local alarm mechanism is triggered; otherwise, the working mode is determined to be the standard sales mode.

2. The lottery sales supervision method based on edge AI according to claim 1, characterized in that, When the working mode is the standard sales mode, the local determination of whether there are user-related risk events specifically includes: By using a preset model to analyze the user's biometric information, it is possible to determine whether the user is at risk of age non-compliance. According to a preset time period, the cumulative betting amount of the user at the sales terminal is calculated. If the cumulative betting amount exceeds the preset cumulative warning limit, it is determined that the user has a risk of abnormal user status. When it is determined that there is a risk that the user's age is not compliant and / or the user's status is abnormal, a risk event related to the user is generated.

3. The lottery sales supervision method based on edge AI according to claim 2, characterized in that, The central cloud platform performs cross-site analysis based on the received risk event reports to generate a regional dynamic watchlist, specifically including: The anonymous biometric information of the user is obtained from the risk event report, and the anonymous biometric information is obtained by processing the biometric information. Based on the anonymous biometric information, determine the number of risk event reports containing the user's anonymous biometric information within a preset time window, and determine whether the number meets the identification criteria; If the quantity meets the identification criteria, the user's anonymous biometric information is written into the regional dynamic watchlist.

4. The lottery sales supervision method based on edge AI according to claim 3, characterized in that, The method further includes: Based on the event type of the risk event, obtain the basic risk score corresponding to the event type; Based on the anonymous biometric information, analyze the distribution patterns of the number of sales terminal reports and event types associated with the anonymous biometric information; Based on the basic risk score, the number of reports from the sales terminal, and the event type distribution pattern, the user's total risk score is calculated using a preset weighted algorithm. The calculated total risk score is compared with a preset risk level mapping table to obtain the user's risk level, and the user's risk level is written into the regional dynamic watchlist.

5. The lottery sales supervision method based on edge AI according to claim 4, characterized in that, When the sales terminal identifies a user matching the regional dynamic watchlist, it performs a collaborative intervention operation, specifically including: When a new user appears within the camera's field of view at the sales terminal, the anonymous biometric information of the new user is obtained. The anonymous biometric information of the new user is compared with the anonymous biometric information in the regional dynamic watchlist to determine a similarity score; If the similarity is higher than the preset matching threshold, it is determined that a user matching the regional dynamic watchlist has been identified, and the collaborative intervention operation is triggered according to the risk level.

6. The lottery sales supervision method based on edge AI according to claim 5, characterized in that, The triggering of the collaborative intervention operation based on the risk level specifically includes: If the risk level is high, the betting function of the sales terminal will be locked, and the highest level alarm notification will be sent to the preset supervisor. If the risk level is medium risk, the large-amount betting function of the sales terminal will be restricted, and the regulatory personnel at the site where the sales terminal is located will be notified.

7. The lottery sales supervision method based on edge AI according to claim 6, characterized in that, The method further includes: A collaborative intervention report is generated by the sales terminal that performs the aforementioned collaborative intervention operation; The collaborative intervention report is uploaded to the central cloud platform and stored in association with the risk event report to build a complete risk event tracing chain.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the edge AI-based lottery sales supervision method as described in any one of claims 1 to 7.

Images