Robot account identification processing method and device, computer device, and readable storage medium

Abstract

The application discloses a kind of robot account identification processing method, device, computer equipment and readable storage medium, applied to the internet account system including client and server.Long connection is established with server after client in account registration or login success, and heartbeat packet is sent according to preset interval.The login log of account is recorded by server, including IP address, equipment identification and operation time.The first type robot account is judged by server by detecting whether heartbeat packet is received within preset time, and whether the number of accounts associated in a statistical period based on login log analysis same IP or equipment identification exceeds threshold value, to determine the second type robot account.Disabling operation is performed to the robot account determined, and offline notice is issued through active long connection, to trigger client to clear local login state and return to login interface.The method realizes double-dimensional real-time identification and processing of robot account, improves identification accuracy and system security.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a robot account identification and processing method, apparatus, computer equipment, and readable storage medium. Background Technology

[0002] In internet account systems, the proliferation of bot accounts severely impacts platform security and user experience. Existing identification methods largely rely on single-dimensional static verification, such as verifying identity information only during registration or login, lacking monitoring of the account's continuous activity. Furthermore, traditional methods struggle to effectively identify bot account clusters generated through dynamic IPs or emulated device technology, resulting in low accuracy, delayed response times, and an inability to adapt to constantly evolving bot behavior patterns. Therefore, a bot account identification and processing solution is needed that can monitor account activity in real time and perform aggregated analysis using multi-dimensional logs. Summary of the Invention

[0003] The purpose of this invention is to provide a robot account identification and processing method, apparatus, computer equipment, and readable storage medium.

[0004] In a first aspect, embodiments of the present invention provide a robot account identification and processing method, applied to an internet account system including a client and a server. The server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information. The method includes: When the client successfully registers or logs in to the account, it initiates a long connection establishment request to the server and establishes a long connection with the server. After the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals. If the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection. The server records the IP address, device identifier, and operation time for each account's registration or login operation, and generates login logs for the corresponding account. For all accounts that have completed registration or login, the server checks whether it has received a heartbeat packet for the corresponding account within a preset detection time range. If no heartbeat packet is received, the account is determined to be a first-type robot account. The server aggregates and analyzes the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds the first preset threshold within a preset statistical period, or the number of different accounts registered or logged in corresponding to the same device identifier exceeds the second preset threshold, then all accounts registered or logged in corresponding to the IP address or the device identifier within the preset statistical period are identified as second-type robot accounts. The server will ban the first and second types of robot accounts identified. If a robot account is identified as having a long-lived connection that is currently active, the server will send an offline notification to the corresponding client through the long-lived connection, triggering the client to clear its local login information and return to the login page.

[0005] In one possible implementation, the client retrying to establish a long connection continues until the long connection is successfully established, or the corresponding account actively triggers the logout operation, or the corresponding account is determined to be a bot account.

[0006] In one possible implementation, the preset detection time range used for the first type of robot account recognition is an adjustable parameter configured through the server backend interface. The value of the preset detection time range is negatively correlated with the user interaction frequency of the corresponding application scenario: the higher the user interaction frequency of the application scenario, the shorter the value of the preset detection time range.

[0007] In one possible implementation, the aggregation analysis process in the second type of robot account identification is executed through two triggering mechanisms: the first is real-time triggering, which is triggered at two nodes: when a single account completes registration and when a single account completes login, and aggregate verification is performed on the IP address and device identifier associated with the current operation; the second is periodic triggering, which performs batch backtracking analysis on the full login logs according to a preset fixed backtracking period.

[0008] The first preset threshold and the second preset threshold are parameters that can be dynamically adjusted according to the business time period attributes and the access popularity of the registration or login area.

[0009] In one possible implementation, the first type of robot account recognition and the second type of robot account recognition are independent recognition processes executed in parallel. The first type of robot account is a script-based robot account that simulates the communication protocol of the Internet platform, skips the client interaction process and sends registration or login requests directly to the server, and does not have the logic of establishing a long connection with the client and reporting a heartbeat. The second type of robot account is a tool-type robot account that uses automated tools to simulate real user operations, automatically completes the entire registration or login process on the client page, and exhibits the characteristic of batch aggregation of IP addresses or device identifiers.

[0010] In one possible implementation, the server performs aggregated analysis of login logs for all accounts, including: The server extracts a training sample set from historical login logs. Each sample corresponds to an IP address or device identifier within a historical statistical period. A multidimensional feature vector is constructed for each sample. The multidimensional feature vector includes the number of registered accounts associated with the IP address or device identifier within the historical statistical period, the number of logged-in accounts, the dispersion of account operation time, the distribution of time intervals between registration and login behaviors, the nickname or basic information entropy value of the registered account, and the average active duration of the corresponding account extracted from the heartbeat packet data. Each sample is labeled as a source of bot account aggregation based on historical ban records or manual review tags, and the aggregation pattern dynamic recognition model is trained using the labeled sample set. Within the preset statistical period, the server extracts the same multidimensional feature vector for the IP address or device identifier to be analyzed and inputs it into the aggregation pattern dynamic recognition model to obtain a probability score that the IP address or device identifier is a source of robot account aggregation. The server dynamically adjusts the first preset threshold or the second preset threshold based on the probability score. When the probability score is higher than a set risk threshold, the first preset threshold or the second preset threshold is lowered. When the probability score is lower than a set safety threshold, the first preset threshold or the second preset threshold is raised. Alternatively, the server compares the probability score with a preset probability score threshold. When the probability score exceeds the probability score threshold, all accounts registered or logged in within the preset statistical period corresponding to that IP address or device are directly identified as a high-risk robot account set.

[0011] In one possible implementation, the server detects whether it has received a heartbeat packet for the corresponding account within a preset detection time range, including: The server collects heartbeat packet data continuously sent by each account after the long connection is established, forming a heartbeat behavior time series sequence. The characteristics of the sequence include the time interval sequence between consecutive heartbeat packets, the heartbeat packet data packet size sequence, and the offset sequence between the heartbeat packet sending time and the server system timestamp. Using the historical heartbeat behavior time series sequence of normal user accounts, an unsupervised learning algorithm is used to train a heartbeat behavior benchmark model for calculating the abnormal score of the behavior sequence. For any account, the server extracts the heartbeat behavior time sequence within a detection window with a length greater than or equal to the preset detection time range, and inputs it into the heartbeat behavior benchmark model to obtain an anomaly score; When the server receives a heartbeat packet from the corresponding account within the preset detection time range, and the abnormal score exceeds the set abnormal score threshold, the account is determined to be a third-type robot account. The server performs a ban operation on the third type of robot account and carries abnormal behavior code when sending an offline notification via a long connection.

[0012] Secondly, embodiments of the present invention provide a robot account recognition and processing device, applied to an internet account system including a client and a server. The server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information. The device includes: The client initiates a long connection establishment request to the server when the account registration or login is successful, and establishes a long connection with the server. After the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals. If the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection. The server records the IP address, device identifier and operation time of each account's registration or login operation, and generates the corresponding account's login log. The identification module is used to detect whether the server receives a heartbeat packet for any registered or logged-in account within a preset detection time range. If no heartbeat packet is received, the account is identified as a first-type bot account. The server aggregates and analyzes the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds a first preset threshold or the number of different accounts registered or logged in corresponding to the same device identifier exceeds a second preset threshold within a preset statistical period, all accounts registered or logged in corresponding to that IP address or device identifier within the preset statistical period are identified as second-type bot accounts. The server performs blocking operations on the identified first-type and second-type bot accounts. If a bot account has a currently active long connection, the server sends an offline notification to the corresponding client through the long connection, triggering the client to clear its local login information and return to the login interface.

[0013] Thirdly, embodiments of the present invention provide a computer device, the computer device including a processor and a non-volatile memory storing computer instructions, wherein when the computer instructions are executed by the processor, the computer device performs the method described in the first aspect.

[0014] Fourthly, embodiments of the present invention provide a readable storage medium, the readable storage medium including a computer program, wherein the computer program, when running, controls the computer device where the readable storage medium is located to execute the method described in the first aspect.

[0015] Compared to existing technologies, the beneficial effects of this invention include: The robot account identification and processing method, apparatus, computer equipment, and readable storage medium disclosed in this invention are applied to an internet account system comprising a client and a server. After successful account registration or login, the client establishes a long connection with the server and sends heartbeat packets at preset intervals. The server records the account's login logs, including IP address, device identifier, and operation time. The server determines a first type of robot account by detecting whether a heartbeat packet is received within a preset time period, and simultaneously determines a second type of robot account by analyzing the login logs to see if the number of accounts associated with the same IP address or device identifier exceeds a threshold within a statistical period. Robot accounts are blocked, and an offline notification is sent through the active long connection, triggering the client to clear its local login status and return to the login interface. This method achieves real-time identification and processing of robot accounts from two dimensions, improving identification accuracy and system security. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as limiting the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the steps of the robot account recognition and processing method provided in an embodiment of the present invention;

[0018] Figure 2 A schematic block diagram of the structure of the robot account recognition and processing device provided in an embodiment of the present invention;

[0019] Figure 3 A schematic block diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0022] In order to solve the technical problems mentioned in the background art Figure 1This is a flowchart illustrating the robot account recognition processing method provided in this embodiment. The method is applied to an internet account system that includes a client and a server. The server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information. The robot account recognition processing method will be described in detail below.

[0023] In step S201, when the client has successfully registered or logged in to the account, it initiates a long connection establishment request to the server and establishes a long connection with the server. After the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals. If the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection. In this embodiment of the invention, for example, after a user successfully registers or logs in to an account on a client (such as a mobile app or webpage), the client immediately initiates a long-connection establishment request to the server. Upon receiving this request, the server first verifies the validity of the session token or identity credential carried in the request, confirming that it corresponds to a legitimate account that has passed verification and is in a "login" or "registered and activated" state. After successful verification, the server allocates a long-connection session resource to the account and establishes a persistent network connection channel (e.g., based on WebSocket or TCP long connection). The server internally maintains an "active connection session table," recording the unique identifier of each long-connection session, the associated account ID, the connection establishment time, the last communication timestamp, and the connection status.

[0024] After a long connection is successfully established, the server expects the client to send heartbeat packets at preset time intervals (e.g., every 30 seconds). A heartbeat packet is typically a lightweight data packet primarily used to indicate that the client is online and the connection is healthy. Each time the server receives a heartbeat packet from a specific account, it updates the "last communication timestamp" for that account in the "active connection session table." Simultaneously, the server runs a connection health monitoring daemon that periodically checks all active long connections. If the server detects that a long connection has been unexpectedly broken due to network fluctuations, abnormal client exit, or other reasons, it removes the connection from the "active connection session table" and marks the connection status as "disconnected." For the client, when it detects a connection break or initial connection failure, it continuously attempts to re-establish the connection according to the retry logic. The server needs to handle these retry requests and may perform preliminary risk control judgments based on the retry frequency and pattern, but the core retry logic is controlled by the client until the connection is successfully established, the user actively logs out, or the account is deemed abnormal.

[0025] Step S202: The server records the IP address, device identifier, and operation time of each account during the registration or login operation, and generates the login log for the corresponding account. When a critical account registration or login operation occurs, after verifying identity information (such as username, password, SMS verification code, third-party token, etc.), the server not only switches the account's state (e.g., from never registered to registered, or from never logged in to logged in), but also simultaneously generates a detailed login log. The server captures and records key traceability information for this operation, including but not limited to: 1) Operation Account ID: Uniquely identifies the subject of this operation. 2) Client IP Address: The network source address that initiated the request, which may be a public IP address or an IP address after a proxy. 3) Device Identifier: A unique device identifier extracted from the request header or client SDK, such as the mobile device's IDFA / GAID, IMEI (after hashing), or the browser fingerprint on the web. 4) Operation Type: Specifies whether it is "registration" or "login". 5) Operation Timestamp: The time when the server receives the request and completes processing.

[0026] After structuring this information, the server persistently stores it in a dedicated log database or big data platform, forming massive amounts of account login logs. These logs serve as the foundational data source for subsequent aggregation analysis and behavioral pattern mining. For example, in a social media platform scenario, whenever a new user registers using a mobile phone number, or an existing user successfully logs in with a password, the server backend immediately appends a log record containing the aforementioned information.

[0027] Step S203: For all accounts that have completed registration or login, the server checks whether it has received the corresponding account's heartbeat packet within a preset detection time range. If it has not received the heartbeat packet, the account is determined to be a first-type robot account. The server initiates a scheduled scanning task that periodically (e.g., every minute) scans all online accounts. Here, "online" refers to accounts that are "logged in" in the server's records and have not been banned. For each account to be scanned, the server performs the following operations: Check if the account exists in the current "Active Connection Sessions Table", that is, whether there are active long connections.

[0028] If an active long-lived connection exists, the account's "last communication timestamp" is read from the "Active Connection Session Table".

[0029] Calculate the difference between the current system time and the "last communication timestamp".

[0030] Compare this difference to a preset detection time range (e.g., 180 seconds).

[0031] For example, in an online game application, a normal player client maintains a stable connection and sends a heartbeat packet every 20 seconds. The server's detection time range is set to 120 seconds. When the server's detection task runs, it finds that the last heartbeat time for account Player_A was 150 seconds ago, exceeding the 120-second threshold. The server further confirms that the account's long-connection session still exists but there is no heartbeat. At this point, the server determines that account Player_A is a Type I bot account. The characteristics of this type of account are that its registration or login request may be initiated by a direct script of the simulation protocol, successfully obtaining a legitimate session, but because the script does not have or does not fully implement the client's long-connection maintenance and heartbeat packet sending logic, normal heartbeat communication cannot be maintained after the connection is established. The server records this determination result (account ID, determination type, determination time) in the risk account database.

[0032] Step S204: The server performs aggregated analysis on the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds the first preset threshold within the preset statistical period, or the number of different accounts registered or logged in corresponding to the same device identifier exceeds the second preset threshold, then all accounts registered or logged in corresponding to the IP address or the device identifier within the preset statistical period are identified as second-type robot accounts.

[0033] The server performs aggregated analysis on all stored login logs to identify clustered patterns of registrations or logins. The analysis process can be triggered according to preset statistical periods (e.g., the past hour, 24 hours). The server executes the following analysis workflow: Aggregation by IP Address: The server writes a query analysis task to aggregate data by "client IP address" within a specified statistical period (e.g., the past 24 hours). For each IP address, it counts the number of different account IDs associated with it. This number is then compared to a preset first threshold (e.g., 50).

[0034] Aggregation by Device Identifier: Simultaneously, aggregation is performed by grouping according to "Device Identifier". For each device identifier, the number of different account IDs associated with it is counted. This number is compared to a preset second threshold (e.g., 10).

[0035] In an e-commerce platform, the risk control system is set to a statistical period of 1 hour, a threshold of 20 for the same IP address registering different accounts, and a threshold of 5 for the same device identifier logging into different accounts. The server performs a batch analysis task once per hour.

[0036] Scenario A (IP Aggregation): Analysis revealed that IP address 203.0.113.25 successfully registered 35 new accounts (User_1 to User_35) within the past hour. 35 > 20 (the first threshold), triggering the IP aggregation rule. The server determined that these 35 accounts registered by IP address 203.0.113.25 within this statistical period were Category II bot accounts. This typically corresponds to scripts that use the same proxy IP or server room IP for batch registration.

[0037] Scenario B (Device Aggregation): Analysis revealed that within the past hour, device identifier Device_Fingerprint_XYZ successfully logged into 8 different existing accounts: Account_A, Account_B, ..., Account_H. 8 > 5 (the second threshold), triggering the device aggregation rule. The server determined that the 8 accounts logged into by Device_Fingerprint_XYZ within this statistical period were Category II bot accounts. This typically corresponds to automated tools switching accounts on the same physical device or emulator to engage in activities such as boosting traffic, reviews, or web scraping.

[0038] The server records the above judgment results (list of account IDs involved, aggregation source IP / device, judgment type, and judgment time) in the risk account database. The first and second preset thresholds can be static values ​​set based on business experience, or they can be dynamically adjusted through the backend management system. For example, the threshold can be increased during promotional periods to tolerate multiple account operations by normal users, or the threshold can be decreased during peak periods of malicious registration at night.

[0039] In step S205, the server performs a ban operation on the first type of robot account and the second type of robot account determined by the judgment; if the robot account is determined to have a long connection that is currently active, the server sends an offline notification to the corresponding client through the long connection, triggering the client to clear the local login information and return to the login interface.

[0040] For robot accounts classified as Category 1 or Category 2, the server will perform a uniform ban. The banning operation includes, but is not limited to: 1) marking the account status as "banned"; 2) adding the account ID to the real-time blacklist, so that all subsequent business requests (except for unbanning appeals) will be blocked; 3) optionally, clearing the account's related sessions and tokens, making them immediately invalid.

[0041] The key offline notification process: When performing a ban, the server checks whether the account being banned currently exists in the "active connection session table," i.e., whether it still has active long-lived connections. If it does, the server immediately sends a system-level "offline notification" command to the corresponding client through the existing long-lived connection channel. This command is a push initiated by the server, not a response to a client request.

[0042] Regarding Scenario B on the aforementioned e-commerce platform, when the server determines that the eight accounts logged into the Device_Fingerprint_XYZ device are bot accounts and bans them, it discovers that Account_C and Account_F still have active long-lived connections (the user may be using automation tools to browse products using these two accounts). The server will send a "disconnect notification" command to the automation tool program disguised as a client through the long-lived connection sessions corresponding to these two accounts. Upon receiving this command, a legitimate client application will execute predefined processing logic: immediately clear locally saved login state (such as tokens, cookies), disconnect the network connection, and redirect the application interface back to the login page, prompting the user "Account status is abnormal, please log in again." However, for bot scripts or tools, they may not be able to correctly parse or respond to this command, but the connection will be forcibly closed by the server, thus terminating their current automation operation.

[0043] The detailed description above demonstrates how the server, as the core executor, effectively identifies and handles two typical types of bot accounts by maintaining persistent connections and heartbeat states, recording detailed login logs, implementing rule-based scheduled detection and batch analysis, and ultimately executing bans and proactive notifications. This ensures the security and fairness of the internet account system. The entire process is automated on the server side, possessing real-time and batch processing capabilities, and can handle the challenges of bot attacks on large-scale account systems.

[0044] It is important to note that in this embodiment of the invention, "all accounts that have completed registration or login" and "all accounts" have different technical meanings and applicable scopes, as follows: "All accounts that have completed registration or login" refers to the set of accounts that have successfully completed registration or login at the current time and may still be online (i.e., may have established a long connection). This set is mainly used for real-time heartbeat packet detection of the first type of robot accounts. "All accounts" refers to all accounts that have historically registered or logged in to the system, and their corresponding login logs constitute the data basis for analysis. This set is mainly used for aggregate analysis of the second type of robot accounts to discover clustering characteristics of IP addresses or device identifiers. While there is an inclusion relationship in their data scope (the former is a subset of the latter), they serve different detection mechanisms and inventive points.

[0045] In this embodiment of the invention, the client retrying to establish a long connection continues until the long connection is successfully established, or the corresponding account actively triggers the logout operation, or the corresponding account is determined to be a robot account.

[0046] In this embodiment of the invention, for example, in the method, the client's retry to establish a long connection is initiated autonomously by the client, but the server, as the receiving and processing end, directly determines the final result of the retry through its logic and state. The server continuously senses and responds to the client's connection attempts until any of the following conditions are met: Scenario 1: Retry successful, long connection established: The server continuously receives periodic connection requests from clients using the same account. For example, if the long-lived connection for account User_Alpha is lost due to a network switch, its client will initiate a reconnection request every 5 seconds. The first few requests may fail because the network is not yet stable, and the server will return a connection error. Once the network recovers, the server receives a valid reconnection request, verifies that the session token is still valid and the account status is normal, then reallocates resources, successfully establishes a new long-lived connection, and updates the active connection session table. At this point, the client's retry behavior naturally terminates because the goal has been achieved.

[0047] Scenario 2: The account voluntarily logs out, and there is no basis for retrying:

[0048] The server receives a "logout" request from account User_Beta via the normal client process. The server processes this request, immediately invalidating all session tokens for that account and clearing its corresponding active persistent connection record. Afterwards, the client may still send reconnection requests due to a failure to synchronize its state in a timely manner. When the server receives the client's connection request again, it will verify that the token has expired or the account has no active session state, therefore refusing to establish a connection and possibly returning a "Please log in again" response. Upon receiving such an explicit rejection, the client will stop retries for that login state.

[0049] Scenario 3: The account is identified as a bot, and the server may proactively terminate the connection. This is the core linkage scenario. Through the aforementioned detection process, the server determines that the account User_Gamma is a type-one robot account (e.g., no heartbeat is received for 180 consecutive seconds). The server then performs a ban operation, marking the account status as "banned". Almost simultaneously, the client of this account may still be executing the retry logic and sending a new connection request to the server. When processing this or any subsequent retry requests, the server will first check the account status, find that it has been banned, and thus directly reject the connection establishment and may close the connection or ignore the request. For the client, its retry behavior will either continuously fail due to the connection being rejected or stop after receiving the ban notice. The ban action on the server side fundamentally eliminates the possibility of the account successfully reconstructing a long connection, thus forcibly ending the client's retry loop.

[0050] In the embodiment of the present invention, the preset detection time range used for identifying the type-one robot account is an adjustable parameter through the server background configuration interface, and the value of the preset detection time range is negatively correlated with the user interaction frequency of the corresponding application scenario: for application scenarios with higher user interaction frequencies, the value of the preset detection time range is shorter.

[0051] In the embodiment of the present invention, for example, in the robot account identification processing method, the identification of type-one robot accounts mainly depends on the key parameter of "preset detection time range". As the executor and manager of the policy, the server designs this parameter as a variable that can be dynamically adjusted through the background configuration interface rather than a fixed code constant. Its adjustment logic closely follows the characteristics of the business scenario and adheres to the negative correlation principle of "the higher the user interaction frequency of the application scenario, the shorter the value", so as to achieve the best balance between risk control accuracy and user experience.

[0052] Server background configuration and management: Server operation and maintenance or risk control administrators access the configuration interface for the "heartbeat detection module" through a dedicated internal management platform. This interface provides a visual form or API, allowing administrators to set independent "heartbeat timeout determination thresholds" (i.e., preset detection time ranges) for different "application scenario identifiers" or "business lines". After all configuration modifications are submitted, the server configuration center will push the new parameters to all service instances running the detection tasks in real-time or near real-time, making them take effect immediately. For example, an administrator adjusts the value from 120 seconds to 90 seconds for the "Instant Messaging" business line and from 300 seconds to 600 seconds for the "Online Reading" business line in the configuration interface. After the server receives the update, it immediately loads the new configuration, and all subsequent detection tasks will use the new threshold for calculation.

[0053] In high-interaction-frequency scenarios, such as instant messaging applications, the sending and receiving of messages and the awareness of online status between users require extremely high real-time performance. Normal user clients maintain very active long connections and frequently send heartbeat packets (e.g., every 15 seconds) to maintain their online status. Based on this high-interaction-frequency characteristic, the server sets a short preset detection time range, such as 60 seconds. The server's heartbeat detection daemon runs once per minute, checking the last heartbeat time of each online account. When the last heartbeat record of account ChatUser_123 is detected to be 70 seconds ago, the server calculates that 70 seconds > 60 seconds (the preset threshold) and immediately classifies the account as a first-type bot account. This short threshold setting allows the server to quickly detect and handle scripts that simulate successful logins but cannot maintain real-time heartbeats, ensuring the accuracy of the online user list and preventing "zombie accounts" from displaying as online for extended periods.

[0054] In high-frequency interaction scenarios, such as multiplayer online game platforms, player location synchronization and skill release require millisecond-level responses, leading to extremely frequent data exchange between the client and server. For this scenario, the server is configured with a shorter detection timeframe, such as 45 seconds. Game clients typically communicate with the server multiple times per second, with heartbeat intervals potentially as short as 10 seconds. When the server's detection task runs, it detects that the last valid heartbeat for player account GamePlayer_XYZ occurred 50 seconds ago. Although the connection hasn't been terminated by the system, the 45-second threshold has been exceeded. Based on this, the server determines that the account is abnormal and may be using cheats or automated scripts that lack normal game client heartbeat logic, thus triggering a ban. This extremely short detection window effectively identifies non-human players attempting to maintain a connection but exhibiting abnormal behavior patterns.

[0055] In low-interaction-frequency scenarios, such as news or e-book reading applications, users primarily engage in reading and may remain on the same page for extended periods without generating network requests. User interaction frequency is low. The server is configured with a relatively long preset detection time range for such scenarios, such as 300 seconds (5 minutes). A normal user might spend several minutes reading an article, during which time the client's heartbeat packets are sent normally. The server's detection task finds that the last heartbeat record for account Reader_456 was 280 seconds ago. Since 280 seconds < 300 seconds (the preset threshold), the server determines that the account's heartbeat behavior is normal and does not consider it a bot. This longer tolerance time avoids misjudging genuine users focused on reading as bots, reducing false positives and improving the user experience.

[0056] Dynamic Adjustment and Intelligent Linkage: Furthermore, server adjustment strategies can be more refined. For example, during "flash sales" on e-commerce platforms, the server can temporarily and dynamically lower the heartbeat detection threshold of the relevant activity page from the usual 120 seconds to 80 seconds to address potential bots using scripts to snatch purchases but unable to simulate full client-side behavior. The adjustment can be based on signal notifications from the business system or real-time decisions from the risk control system. The server continuously monitors the judgment rate and false alarm rate under different thresholds, providing data analysis feedback to administrators to inform parameter optimization. Through this configurable, scenario-based time range setting, the server enables the first type of bot account identification mechanism to possess high adaptability and operational flexibility, accurately targeting bots while effectively protecting the experience of legitimate users.

[0057] In this embodiment of the invention, the aggregation analysis process in the second type of robot account identification is executed through two triggering mechanisms: the first is real-time triggering, which is triggered at two nodes: when a single account completes registration and when a single account completes login, and aggregate verification is performed on the IP address and device identifier associated with the current operation; the second is periodic triggering, which performs batch backtracking analysis on the full login logs according to a preset fixed backtracking period.

[0058] The first preset threshold and the second preset threshold are parameters that can be dynamically adjusted according to the business time period attributes and the access popularity of the registration or login area.

[0059] In this embodiment of the invention, exemplarily, the real-time triggering mechanism executes as follows: after successfully processing any account registration or login request, the server, while returning a success response to the client, immediately triggers a real-time aggregated verification task. This task uses the IP address and device identifier recorded in the current operation as the query key to query the number of all different accounts associated with that IP address and the number of all different accounts associated with that device identifier within a statistical period (e.g., the past hour). For example, when account New_User_99 successfully registers from IP address 192.168.1.100, the server, after writing to the login log, immediately queries and learns that this IP address has successfully registered 98 accounts, from New_User_01 to New_User_98, within the past hour. The server compares the real-time calculated number 98 with the "first preset threshold" currently in effect for this business scenario (e.g., dynamically set to 50 based on the current time period). Since 98 > 50, the server immediately identifies IP address 192.168.1.100 and all 99 accounts associated with it during this period as a Class II bot account set and triggers the blocking process. This real-time triggering can immediately intercept malicious registration behavior as it occurs, curbing its spread.

[0060] In addition to the periodic triggering mechanism, the server also sets up an offline batch analysis task, which starts according to a preset fixed backtracking cycle (e.g., every 24 hours). This task fully scans all login logs from the past complete cycle, performing more complex cross-dimensional aggregation analysis and pattern mining. For example, at 3:00 AM every day, the server starts a batch task to analyze logs from the past 24 hours. Through batch calculation, the system may find that although a device identifier Device_Simulator_ABC does not exceed the limit in a single real-time trigger (e.g., logging in with 3 different accounts per hour), it has logged in with a total of 42 different accounts within 24 hours. The "second preset threshold," dynamically adjusted by the system based on the "access popularity of the registration / login area," is 30 during normal periods. Since 42 > 30, the server successfully discovered this low-frequency but persistent batch login behavior through this periodic analysis and classified the device and its 42 associated accounts as second-type bot accounts. This batch backtracking compensates for the scattered aggregation behaviors that may be missed by real-time triggering.

[0061] The dynamic adjustment of thresholds, configured by the policy engine in the server management backend, makes the first preset threshold (IP-related) and the second preset threshold (device-related) dynamic parameters. For example, when the "business period attribute" is "shopping festival flash sale period," the server automatically and temporarily raises the IP registration threshold for the relevant interface from 50 to 80 to tolerate some real users using shared family IPs to participate in multi-account flash sales, reducing false positives. Conversely, when the system detects an abnormal surge in access activity from a specific geographical area with a high historical risk, the policy engine can automatically and dynamically lower the device login threshold for that region's IP range from 10 to 5 for stricter control. These adjustments are either automatically executed by the server based on preset risk control rule models or manually intervened by administrators to ensure that the prevention and control strategy always matches the real-time risk situation.

[0062] In this embodiment of the invention, the first type of robot account recognition and the second type of robot account recognition are independent recognition processes executed in parallel. The first type of robot account is a script-based robot account that simulates the communication protocol of the Internet platform, skips the client interaction process and sends registration or login requests directly to the server, and does not have the logic of establishing a long connection with the client and reporting a heartbeat.

[0063] The second type of robot account is a tool-type robot account that uses automated tools to simulate real user operations, automatically completes the entire registration or login process on the client page, and exhibits the characteristic of batch aggregation of IP addresses or device identifiers.

[0064] In this embodiment of the invention, for example, the robot account identification and processing method deploys two independently running risk identification processes on the server, targeting two types of robot accounts with drastically different technical principles and behavioral characteristics. These two processes execute in parallel on the server side, independent of each other, and together constitute a comprehensive defense system.

[0065] The identification process and typical scenarios for the first type of bot accounts involve a server running a real-time detection module focused on monitoring long connections and heartbeat status. This module continuously tracks all accounts with established long connections and determines whether their heartbeat behavior is normal based on a preset detection time range. The first type of bot accounts targeted by this process are essentially scripts that directly simulate internet platform communication protocols. They typically analyze server API interfaces, construct legitimate HTTP / HTTPS request packets, and directly invoke the server's registration or login endpoints, thereby bypassing the real client application interaction process (such as page loading, button clicks, and CAPTCHA rendering). Although such scripts can successfully pass identity verification and obtain valid session tokens, their internal logic often lacks or cannot fully simulate the core capabilities of real client applications in maintaining long connections and periodically sending heartbeat packets.

[0066] For example, on a social media platform, an attacker wrote a Python script that, through packet sniffing and analysis, directly sent a POST request carrying the stolen username and password to the server's ` / api / login` interface. After successful server verification, the script successfully obtained a token representing the login status of the account `SocialBot_A`. Subsequently, the script might attempt to establish a persistent connection, but because it is not a genuine client application, it cannot stably maintain a WebSocket connection and does not implement the logic of sending a specific formatted heartbeat packet every 30 seconds. The server-side heartbeat detection module did not receive any heartbeat packets from account `SocialBot_A` for 120 consecutive seconds (a preset detection time range). Although the login request itself appears "successful," the server, based on the conclusive evidence of the missing heartbeat, independently classifies it as a Type I bot account and bans it. This type of identification does not rely on clustered analysis of IPs or devices, but only on the connection behavior itself.

[0067] The identification process and typical scenarios for the second type of bot accounts involve the server simultaneously running another task focused on login log aggregation and analysis. This task uses both real-time and periodic triggering mechanisms to check for the clustering of IP addresses and device identifiers. This type of bot account, targeted by this process, operates in a more "advanced" manner. Attackers use automated tools (such as Selenium and Appium) or customized emulators to completely control a real or virtual device environment. They use automated scripts to simulate all actions of a real user on the client-side page: loading the registration page, entering information, clicking to obtain an SMS verification code, entering the verification code, and clicking submit. From the outside, the registration or login process appears identical to that of a real user, completing the entire interaction, including graphical verification codes, thus successfully registering or logging in. However, its essence is a batch, automated tool behavior, inevitably leaving traces at the underlying level: the same IP address (such as a proxy server) or the same device identifier (such as an emulator instance) is associated with a large number of different accounts within a short period.

[0068] For example, on an e-commerce platform, someone maliciously used a computer with automation tools installed to control multiple Android emulator instances (each instance with a unique device identifier, Emulator_ID_X) via a fixed residential proxy IP address (203.0.113.88) to register accounts in bulk for subsequent order manipulation. Each emulator automatically completed the entire process from opening the app, clicking register, entering a mobile phone number, receiving and entering an SMS verification code, to setting a password. The server successfully processed these registration requests each time and generated login logs. Subsequently, the server's aggregation analysis module (whether triggered in real-time or as a periodic task) analyzed the logs from the past hour and found that IP address 203.0.113.88 was associated with 85 newly registered accounts, and device identifier Emulator_ID_1 was also associated with 12 newly registered accounts. These numbers all exceeded the dynamically adjusted thresholds (e.g., IP threshold 50, device threshold 8). Based on this clear bulk aggregation characteristic, the server independently classified these accounts as Category II bot accounts and banned them. This type of identification does not care whether the account has a heartbeat, but only focuses on the aggregation of its source.

[0069] Parallel execution and complementarity: In the server background, the heartbeat detection module and the log aggregation and analysis module run simultaneously, sharing a risk account database as the exit point for handling, but their data sources, analysis algorithms, and decision-making criteria are completely independent. An account may be banned by the first type of process due to missing heartbeats, or by the second type of process due to IP aggregation, or be hit by both processes simultaneously. This parallel architecture ensures that the server can cover various bot attack methods, from "low-simulation" protocol scripts to "high-simulation" automated tools, greatly improving the overall defense robustness of the system.

[0070] In this embodiment of the invention, the server performs aggregated analysis on the login logs of all accounts, which can be implemented through the following example.

[0071] The server extracts a training sample set from historical login logs. Each sample corresponds to an IP address or device identifier within a historical statistical period. A multidimensional feature vector is constructed for each sample. The multidimensional feature vector includes the number of registered accounts associated with the IP address or device identifier within the historical statistical period, the number of logged-in accounts, the dispersion of account operation time, the distribution of time intervals between registration and login behaviors, the nickname or basic information entropy value of the registered account, and the average active duration of the corresponding account extracted from the heartbeat packet data.

[0072] Each sample is labeled as a source of bot account aggregation based on historical ban records or manual review tags, and the aggregation pattern dynamic recognition model is trained using the labeled sample set.

[0073] Within the preset statistical period, the server extracts the same multidimensional feature vector for the IP address or device identifier to be analyzed and inputs it into the aggregation pattern dynamic recognition model to obtain a probability score that the IP address or device identifier is a source of robot account aggregation.

[0074] The server dynamically adjusts the first preset threshold or the second preset threshold based on the probability score. When the probability score is higher than a set risk threshold, the first preset threshold or the second preset threshold is lowered. When the probability score is lower than a set safety threshold, the first preset threshold or the second preset threshold is raised.

[0075] Alternatively, the server compares the probability score with a preset probability score threshold. When the probability score exceeds the probability score threshold, all accounts registered or logged in within the preset statistical period corresponding to that IP address or device are directly identified as a high-risk robot account set.

[0076] In this embodiment of the invention, for example, in the robot account identification processing method, the server's aggregated analysis of all login logs can be upgraded from rule detection based on fixed thresholds to intelligent dynamic identification that integrates machine learning models. This process uses the server as the computing core, trains the model using historical data, and applies it to real-time risk decision-making.

[0077] The server performs sliding window sampling from stored historical login logs (e.g., data from the past three months) according to a preset historical statistical period (e.g., 24 hours). Each sample is a snapshot of the behavior of an IP address or device identifier within a statistical period. The server automatically constructs a multi-dimensional feature vector for each sample. For example, for the behavior of historical IP address 198.51.100.25 within a certain historical period, the server extracts and calculates the following features: 1) Number of registered accounts: This IP successfully registered 8 new accounts within this period. 2) Number of logged-in accounts: This IP logged in to 15 existing accounts. 3) Dispersion of account operation time: Calculating the standard deviation of the timestamps of these 23 (8+15) registration / login operations reveals that the operation intervals are very uniform with low dispersion, exhibiting automation characteristics. 4) Distribution of time intervals between registration and login behaviors: Analysis shows that registration behavior is concentrated in the first 10 minutes, while login behavior is scattered over the last 23 hours, presenting a "batch registration first, then scattered login" pattern. 5) Entropy value of registered account nicknames or basic information: Calculating the randomness of the nicknames of the 8 accounts registered by this IP (e.g., user_af12x, user_98hjq), it was found that their entropy values ​​were very high, consistent with machine generation patterns. 6) Average active duration of the corresponding accounts: Server-linked heartbeat data revealed that these accounts had an average active (heartbeat-enabled) duration of only about 2 minutes after logging in, far lower than that of normal users.

[0078] The server associates the massive amount of historical samples extracted above with a historical ban record database. For example, IP198.51.100.25 was banned by the risk control system based on rules after the end of its current period, so the server automatically labels this sample as "a source of bot account aggregation." Samples that were not banned are labeled "non-aggregation source." Some samples that are difficult to determine are manually reviewed and labeled by operations personnel through the review platform. Subsequently, the server uses these labeled sample sets to train a binary classification model (such as Gradient Boosting Decision Tree (GBDT), i.e., a "dynamic aggregation pattern recognition model." This model learns the complex nonlinear relationship between the aforementioned multidimensional features and "whether it is an aggregation source," rather than just a single quantitative threshold.

[0079] During the online operation phase, the server performs the same feature extraction process on the IPs or devices to be analyzed within a preset statistical period (such as the past hour). For example, the server monitors in real time that IP address 203.0.113.200 has been associated with login operations of 10 different accounts within the current period. The server immediately constructs its feature vector: 0 registrations, 10 logins, moderate operation time dispersion, uniform time interval distribution, entropy of no registrations, and average active duration (approximately 5 minutes). The server inputs this feature vector into a "dynamic clustering pattern recognition model" already loaded into memory. For example, after calculation, the model outputs a probability score of 0.87 (range 0-1), indicating that the probability that this IP is a source of bot account clustering is 87%.

[0080] The server compares the model's output probability score of 0.87 with the preset policy threshold. Assuming the system sets a risk threshold of 0.75 and a security threshold of 0.3, since 0.87 > 0.75, the server determines the IP to be extremely high-risk. In this case, the server does not directly block the IP, but instead triggers a dynamic threshold adjustment strategy: for the IP address 203.0.113.200, the applicable first preset threshold (IP dimension) is temporarily and significantly reduced from the usual 50 to 8. This means that in the following statistical period, once the number of different accounts associated with this IP exceeds 8, the real-time trigger mechanism will immediately determine it as a set of bot accounts. This dynamic adjustment makes the defense strategy more targeted, tightening the defense in advance when the risk signal is clear.

[0081] Alternatively, the server can employ a more direct strategy. A higher probability score threshold of 0.9 is set for direct judgment. When the model's score for an analyzed object exceeds this threshold, the server skips the traditional quantitative threshold comparison. For example, for the device identifier Device_Emulator_Pro_7, the model assigns a probability score of 0.93 based on its highly patterned behavioral characteristics (such as extremely low operational dispersion and abnormal account information entropy values). Since 0.93 > 0.9, the server directly classifies all accounts registered or logged in with this device identifier within the current statistical period (e.g., 15 accounts) as a "high-risk bot account set" and immediately executes a ban. This approach is suitable for identifying clustered attacks with extremely obvious characteristics, resulting in a faster and more decisive response.

[0082] Through the above process, the server will upgrade from rule-based static defense to data-driven dynamic intelligent identification, which can discover more hidden and complex aggregation patterns and achieve refined risk adaptive management.

[0083] In this embodiment of the invention, the server detects whether it has received a heartbeat packet from the corresponding account within a preset detection time range, which can be implemented through the following example.

[0084] The server collects heartbeat packet data continuously sent by each account after the long connection is established, forming a heartbeat behavior time series sequence. The characteristics of the sequence include the time interval sequence between consecutive heartbeat packets, the heartbeat packet data packet size sequence, and the offset sequence between the heartbeat packet sending time and the server system timestamp. Using the historical heartbeat behavior time series sequence of normal user accounts, an unsupervised learning algorithm is used to train a heartbeat behavior benchmark model for calculating the abnormal score of the behavior sequence. For any account, the server extracts the heartbeat behavior time sequence within a detection window with a length greater than or equal to the preset detection time range, and inputs it into the heartbeat behavior benchmark model to obtain an anomaly score; When the server receives a heartbeat packet from the corresponding account within the preset detection time range, and the abnormal score exceeds the set abnormal score threshold, the account is determined to be a third-type robot account.

[0085] The server performs a ban operation on the third type of robot account and carries abnormal behavior code when sending an offline notification via a long connection.

[0086] In this embodiment of the invention, for example, while maintaining long-lived connections for each account, the server continuously collects the data of each heartbeat packet it sends and constructs a dynamically updated temporal behavior sequence for it. This sequence contains sub-sequences in multiple dimensions: 1) Heartbeat interval sequence: recording the time difference (Δt) between two consecutive heartbeat packets arriving at the server. 2) Packet size sequence: recording the number of bytes of network payload for each heartbeat packet. 3) Timestamp offset sequence: recording the difference (ΔT) between the client's sending timestamp carried in the heartbeat packet and the server's actual receiving timestamp. These sequences are updated in real time and continuously retain data of the most recent sufficient duration (e.g., 1 hour).

[0087] To establish a baseline for normal behavior, the server filters historical data for accounts confirmed as genuine users (e.g., consistently active, with no violations, and exhibiting rich interactive behavior). It then extracts a large number of heartbeat behavior time-series sequences from these accounts during normal sessions to form a training sample set. The server trains these normal sequences using unsupervised learning algorithms (such as autoencoders based on recurrent neural networks or isolated forest algorithms). The model's learning objective is to capture and memorize the latent patterns and statistical regularities of normal user heartbeat behavior, such as the random fluctuations in heartbeat intervals within a certain range, the stability of data packet size, and the normal distribution of timestamp offsets affected by network latency. After training, the model is deployed as a heartbeat behavior baseline model. Its core function is to calculate the degree of deviation of any given heartbeat behavior sequence from the "normal pattern" and output an anomaly score.

[0088] During the online operation phase, the server's heartbeat detection module maintains a real-time updated detection window (e.g., a sliding window with a length of 180 seconds) for each online account. For the account GamePlayer_Shadow, the server continuously inputs the time sequence of heartbeat behavior within its window into the heartbeat behavior benchmark model for evaluation.

[0089] For example, in a massively multiplayer online role-playing game (MMORPG), an attacker used an advanced automated script. This script could not only simulate login but also establish a persistent connection after login and attempt to send heartbeats to the server at fixed intervals (e.g., precisely every 30.00 seconds) to circumvent Type I detection based on "missing heartbeats." However, its behavior pattern has flaws: 1) Its heartbeat interval sequence is almost a straight line with a standard deviation close to zero, lacking the slight fluctuations caused by system scheduling and foreground / background switching during real user interaction. 2) Its packet size sequence is completely consistent, while a real game client's heartbeat packet might fluctuate normally by a few bytes due to carrying a small amount of dynamic information (such as background resource loading status). 3) Its timestamp offset sequence is also unusually stable, while this value would reasonably change due to fluctuations in mobile network speeds for real users.

[0090] After analyzing GamePlayer_Shadow's heartbeat sequence over the past 180 seconds, the server's heartbeat behavior baseline model calculated an anomaly score as high as 0.92 (assuming a score range of 0-1, with higher scores indicating greater anomalies). The system's preset anomaly score threshold is 0.85. At this point, the server confirms that it did receive heartbeat packets from this account within the preset detection time range (180 seconds). However, because the anomaly score of its behavior sequence (0.92) > 0.85, the server comprehensively determines that the account GamePlayer_Shadow is a third-type bot account. The essence of this type of account is that it possesses basic heartbeat maintenance capabilities, but it cannot simulate the subtle differences in heartbeat behavior that are human-like or consistent with the characteristics of real client operation.

[0091] The server bans accounts identified as Category III bots. When sending an "offline notification" command through the remaining persistent connection, the server includes a specific "behavioral anomaly code" (e.g., LOGOUT_REASON: HEARTBEAT_ANOMALY). Upon receiving this code, legitimate game clients not only perform standard actions like clearing local information and returning to the login screen, but can also display more specific prompts on the interface, such as "An abnormal game environment detected; please close unofficial auxiliary programs and try again." For bot scripts, this code can be used as a background log to help operations personnel analyze attack characteristics. By introducing Category III detection based on sequence pattern recognition, the server can expand its defense scope from "no heartbeat" to "fake heartbeat," significantly improving the depth and accuracy of combating advanced automation tools.

[0092] Please refer to the following: Figure 2 This invention provides a robot account recognition and processing device 110, applied to an internet account system including a client and a server. The server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information. The device includes: The establishment module 1101 is used by the client to initiate a long connection establishment request to the server when the account registration or login is successful, and establish a long connection with the server; after the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals; if the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection; the server records the IP address, device identifier and operation time of the registration or login operation for each account, and generates the login log for the corresponding account; The identification module 1102 is used to detect whether the server receives a heartbeat packet for all registered or logged-in accounts within a preset detection time range. If no heartbeat packet is received, the account is determined to be a first-type robot account. The server performs aggregated analysis on the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds a first preset threshold or the number of different accounts registered or logged in corresponding to the same device identifier exceeds a second preset threshold within a preset statistical period, then all accounts registered or logged in corresponding to the IP address or device identifier within the preset statistical period are determined to be second-type robot accounts. The server performs blocking operations on the determined first-type robot accounts and second-type robot accounts. If a robot account is determined to have a currently active long connection, the server sends an offline notification to the corresponding client through the long connection, triggering the client to clear its local login information and return to the login interface.

[0093] It should be noted that the implementation principle of the aforementioned robot account recognition processing device 110 can refer to the implementation principle of the aforementioned robot account recognition processing method, and will not be repeated here. It should be understood that the division of the various modules in the above device is merely a logical functional division; in actual implementation, they can be fully or partially integrated into a single physical entity, or physically separated. Furthermore, these modules can all be implemented in software through processing element calls; they can all be implemented in hardware; or some modules can be implemented by processing element calls to software, and some modules can be implemented in hardware. For example, the robot account recognition processing device 110 can be a separately established processing element, or it can be integrated into a chip in the aforementioned device. Alternatively, it can be stored as program code in the memory of the aforementioned device, and called and executed by a processing element of the aforementioned device. The implementation of other modules is similar. Furthermore, these modules can be fully or partially integrated together, or implemented independently. The processing element described here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuit in the hardware of the processor element or through software instructions.

[0094] For example, these modules can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs). As another example, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together to implement a system-on-a-chip (SOC).

[0095] This invention provides a computer device 100, which includes a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device 100 executes the aforementioned robot account recognition processing device 110. Figure 3 As shown, Figure 3This is a structural block diagram of a computer device 100 provided in an embodiment of the present invention. The computer device 100 includes a robot account recognition processing device 110, a memory 111, a processor 112, and a communication unit 113.

[0096] To enable data transmission or interaction, the memory 111, processor 112, and communication unit 113 are electrically connected to each other directly or indirectly. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The robot account recognition processing device 110 includes at least one software function module that can be stored in the memory 111 or embedded in the operating system (OS) of the computer device 100 in the form of software or firmware. The processor 112 is used to execute the robot account recognition processing device 110 stored in the memory 111, such as the software function modules and computer programs included in the robot account recognition processing device 110.

[0097] This invention provides a readable storage medium, which includes a computer program. When the computer program runs, it controls the computer device where the readable storage medium is located to execute the aforementioned robot account recognition processing device 110.

[0098] For illustrative purposes, the foregoing description has been made with reference to specific embodiments. However, the foregoing illustrative discussions are not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Numerous modifications and variations are possible in accordance with the foregoing teachings. These embodiments were chosen and described in order to best illustrate the principles of the present disclosure and its practical application, thereby enabling those skilled in the art to best utilize the disclosure and to employ various embodiments with different modifications to suit a particular intended application.

Claims

1. A robot account recognition and processing method, applied to an internet account system comprising a client and a server, wherein the server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information, characterized in that, The method includes: When the client successfully registers or logs in to the account, it initiates a long connection establishment request to the server and establishes a long connection with the server. After the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals. If the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection. The server records the IP address, device identifier, and operation time for each account during registration or login, and generates login logs for the corresponding account. For all accounts that have completed registration or login, the server checks whether it has received a heartbeat packet for the corresponding account within a preset detection time range. If no heartbeat packet is received, the account is determined to be a first-type robot account. The server aggregates and analyzes the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds the first preset threshold within a preset statistical period, or the number of different accounts registered or logged in corresponding to the same device identifier exceeds the second preset threshold, then all accounts registered or logged in corresponding to the IP address or the device identifier within the preset statistical period are identified as second-type robot accounts. The server will ban the first and second types of robot accounts identified. If a robot account is identified as having a long-lived connection that is currently active, the server will send an offline notification to the corresponding client through the long-lived connection, triggering the client to clear its local login information and return to the login page.

2. The robot account identification and processing method according to claim 1, characterized in that, The client's retry operation to establish a long connection continues until the long connection is successfully established, or the corresponding account actively triggers the logout operation, or the corresponding account is determined to be a bot account.

3. The robot account identification and processing method according to claim 1, characterized in that, The preset detection time range used for the first type of robot account recognition is an adjustable parameter configured through the server backend interface. The value of the preset detection time range is negatively correlated with the user interaction frequency of the corresponding application scenario: the higher the user interaction frequency of the application scenario, the shorter the value of the preset detection time range.

4. The robot account identification and processing method according to claim 1, characterized in that, The aggregation analysis process in the second type of robot account identification is executed through two triggering mechanisms: the first is real-time triggering, which is triggered at two nodes: when a single account completes registration and when a single account completes login, and aggregate verification is performed on the IP address and device identifier associated with the current operation; the second is periodic triggering, which performs batch backtracking analysis on the full login logs according to a preset fixed backtracking period. The first preset threshold and the second preset threshold are parameters that can be dynamically adjusted according to the business time period attributes and the access popularity of the registration or login area.

5. The robot account identification and processing method according to claim 1, characterized in that, The first type of robot account recognition and the second type of robot account recognition are independent recognition processes executed in parallel; The first type of robot account is a script-based robot account that simulates the communication protocol of the Internet platform, skips the client interaction process and sends registration or login requests directly to the server, and does not have the logic of establishing a long connection with the client and reporting a heartbeat. The second type of robot account is a tool-type robot account that uses automated tools to simulate real user operations, automatically completes the entire registration or login process on the client page, and exhibits the characteristic of batch aggregation of IP addresses or device identifiers.

6. The robot account identification and processing method according to claim 1, characterized in that, The server performs aggregated analysis on the login logs of all accounts, including: The server extracts a training sample set from historical login logs. Each sample corresponds to an IP address or device identifier within a historical statistical period. A multidimensional feature vector is constructed for each sample. The multidimensional feature vector includes the number of registered accounts associated with the IP address or device identifier within the historical statistical period, the number of logged-in accounts, the dispersion of account operation time, the distribution of time intervals between registration and login behaviors, the nickname or basic information entropy value of the registered account, and the average active duration of the corresponding account extracted from the heartbeat packet data. Each sample is labeled as a source of bot account aggregation based on historical ban records or manual review tags, and the aggregation pattern dynamic recognition model is trained using the labeled sample set. Within the preset statistical period, the server extracts the same multidimensional feature vector for the IP address or device identifier to be analyzed and inputs it into the aggregation pattern dynamic recognition model to obtain a probability score that the IP address or device identifier is a source of robot account aggregation. The server dynamically adjusts the first preset threshold or the second preset threshold based on the probability score. When the probability score is higher than a set risk threshold, the first preset threshold or the second preset threshold is lowered. When the probability score is lower than a set safety threshold, the first preset threshold or the second preset threshold is raised. Alternatively, the server compares the probability score with a preset probability score threshold. When the probability score exceeds the probability score threshold, all accounts registered or logged in within the preset statistical period corresponding to the IP address or device are directly identified as a high-risk robot account set.

7. The robot account identification and processing method according to claim 1, characterized in that, The server detects whether it receives a heartbeat packet for the corresponding account within a preset detection time range, including: The server collects heartbeat packet data sent continuously by each account after the long connection is established, forming a heartbeat behavior time sequence. The characteristics of the sequence include the time interval sequence between consecutive heartbeat packets, the heartbeat packet data packet size sequence, and the offset sequence between the heartbeat packet sending time and the server system timestamp. Using the historical heartbeat behavior time series of normal user accounts, an unsupervised learning algorithm is used to train a heartbeat behavior benchmark model for calculating the abnormal score of the behavior sequence. For any account, the server extracts the heartbeat behavior time sequence within a detection window with a length greater than or equal to the preset detection time range, and inputs it into the heartbeat behavior benchmark model to obtain an anomaly score; When the server receives a heartbeat packet from the corresponding account within the preset detection time range, and the abnormal score exceeds the set abnormal score threshold, the account is determined to be a third-type robot account. The server performs a ban operation on the third type of robot account and carries abnormal behavior code when sending an offline notification via a long connection.

8. A robot account recognition and processing device, applied to an internet account system comprising a client and a server, wherein the server receives an account registration request or account login request initiated by the client, and completes the registration or login operation of the corresponding account after verifying the account identity information, characterized in that, The device includes: The client initiates a long connection establishment request to the server when the account registration or login is successful, and establishes a long connection with the server. After the long connection is successfully established, the client sends heartbeat packets to the server at preset time intervals. If the long connection establishment fails or the established long connection is unexpectedly disconnected, the client continues to retry to establish the long connection. The server records the IP address, device identifier and operation time of each account's registration or login operation, and generates the corresponding account's login log. The identification module is used to detect whether the server receives a heartbeat packet for any registered or logged-in account within a preset detection time range. If no heartbeat packet is received, the account is identified as a first-type bot account. The server aggregates and analyzes the login logs of all accounts. If it detects that the number of different accounts registered or logged in corresponding to the same IP address exceeds a first preset threshold or the number of different accounts registered or logged in corresponding to the same device identifier exceeds a second preset threshold within a preset statistical period, all accounts registered or logged in corresponding to that IP address or device identifier within the preset statistical period are identified as second-type bot accounts. The server performs blocking operations on the identified first-type and second-type bot accounts. If a bot account has a currently active long connection, the server sends an offline notification to the corresponding client through the long connection, triggering the client to clear its local login information and return to the login interface.

9. A computer device, characterized in that, The computer device includes a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device performs the method according to any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium includes a computer program, which, when executed, controls the computer device on which the readable storage medium is located to perform the method described in any one of claims 1-7.

Images