Monitoring methods and electronic devices for abnormal game top-ups

Abstract

This invention provides a method for monitoring abnormal game top-ups, comprising: synchronous monitoring measures; the synchronous monitoring measures include: setting a preset online time threshold; establishing a device information table on the server to store client data; obtaining the client device information for the current top-up, and querying the device information table: if the client device for the current top-up does not exist, or exists and has been marked with a security identifier, it is determined to be a normal top-up; otherwise, the single online time of the client device for the current top-up is recorded, and if it does not exceed the online time threshold, it is determined to be an abnormal top-up. By evaluating the client behavior of the game based on the online time threshold, top-up orders can be identified in a timely manner at the beginning of the payment process, avoiding the defects of monitoring lag and minimizing the financial losses of game publishers. This invention also provides an electronic device that has corresponding advantages due to its ability to implement the game abnormal top-up monitoring method of this invention.

Description

Technical Field

[0001] This invention belongs to the field of Internet technology, and in particular relates to a method for monitoring abnormal game data storage and a corresponding electronic device. Background Technology

[0002] With the development of the internet, internet companies have launched various services and products, all of which require users to prepay, the most common being in-game purchases. Some of these prepayments are genuine purchases and fall under the category of normal prepayment. However, some prepayments are not genuine purchases but rather attempts to profit through refunds. These abnormal in-game purchases cause significant losses to internet companies. Taking mobile smartphone games as an example, since the rise of mobile games, many gray-market industries have emerged, including malicious prepayment (proxy prepayment). Malicious prepayment refers to certain organizations or individuals offering discounted, non-real-time prepayment services to game players. Once the player receives the in-game item, the prepayment organization or individual will process a refund. Because the order has been refunded, when game marketplaces (such as Google Play and the App Store) settle accounts with game publishers, the market will exclude the refunded order from the settlement process. As a result, game publishers deliver items to players but do not receive payment, leading to financial losses for the publishers. Such abnormal top-ups are common in the gaming industry, especially in games released on app stores, harming the interests of game publishers and seriously hindering the development of internet technology. Losses caused by abnormal top-ups are often difficult to recover afterward, so using technical means for monitoring and prevention is currently the main measure to avoid financial losses. However, preventative measures vary in quality, and top-up agencies also develop countermeasures to circumvent them as the industry evolves, resulting in this problem remaining prominent to this day.

[0003] Existing methods for monitoring abnormal top-ups typically involve collecting relevant information about the game player after the fact, and then combining this information with refund requests to determine whether the top-up was a genuine top-up by the player or an abnormal top-up by the third-party platform. If the top-up is determined to be an abnormal top-up by the third-party platform, subsequent top-ups initiated by the player will be controlled or the player's account will be banned.

[0004] It is known that the existing methods for monitoring abnormal game recharges have at least the following shortcomings: (1) They only focus on processing at the end of the payment process, resulting in a lag in monitoring. The existing processing measures cannot identify abnormal recharges before refunds. Although they can avoid some malicious recharges, the refund is already a fait accompli when the abnormal recharge is identified, inevitably causing losses. Especially for some games with serious abnormal recharges, the solution of monitoring only at the end of the payment process is not very meaningful for game developers who have already suffered huge losses, and the monitoring effect is not ideal. (2) They only evaluate based on refund behavior and do not conduct effective data analysis and processing on the collected information, resulting in a rough judgment logic. Many abnormal recharges cannot be identified and are easily cracked by third parties. (3) There is a high misjudgment rate when judging whether a player's information is abnormal after collection. In the existing practice, once an abnormal recharge is determined, the player's account will be directly banned, and the phenomenon of wrongly banning accounts occurs frequently. However, the existing abnormal recharge monitoring methods lack timely corrective measures when wrongly banning accounts. This flaw also led to a decline in the user experience for players, causing game publishers to lose customers. Instead of effectively preventing abnormal recharges, it amplified the economic losses caused by abnormal recharges. Summary of the Invention

[0005] This invention addresses all or part of the problems described in the prior art. On one hand, it provides a method for monitoring abnormal game top-ups, offering a proactive solution for maintaining a healthy game operation environment. On the other hand, it provides an electronic device capable of implementing the game top-up monitoring method of this invention.

[0006] This invention provides a method for monitoring abnormal game top-ups, comprising: synchronous monitoring measures; the synchronous monitoring measures include: setting a preset online time threshold; establishing a device information table on the server to store client data; obtaining the currently logged-in client device information, accumulating the online time of this login, and updating the device information table; when the accumulated online time of this login exceeds the threshold, adding a security identifier to the client device; obtaining the client device information for the current top-up, and querying the device information table: if the client device for the current top-up does not exist, or exists and has already been marked with a security identifier, it is determined to be a normal top-up; otherwise, recording the single online time of the client device for the current top-up, if it does not exceed the threshold, it is determined to be an abnormal top-up; wherein the client data includes: application ID, account, device ID, IP address, online time information, and the security identifier.

[0007] By setting a preset online time threshold and recording and updating client data on the server, online behavior can be synchronously monitored from the moment a user logs in for the first time. Based on the threshold, the game's client device can be evaluated. The client device that makes the deposit can be evaluated at the beginning of the payment process, and the abnormal deposit behavior after the order is blocked can be identified in time. This avoids the defects of monitoring lag and minimizes the property losses caused by abnormal deposits when the game is released in the app store.

[0008] Once a prepaid value is identified as abnormal, the corresponding prepaid value order will be marked as an abnormal prepaid value order.

[0009] The method for setting the online duration threshold includes: conducting tests to obtain the total number of orders, the number of orders marked as abnormal value storage, the total number of reported abnormal orders, and the total number of refunded orders within several test periods; obtaining an increasing time length sequence with a randomly increasing step size; performing sampling screening; and statistical analysis to obtain the optimal value of online duration as the online duration threshold. By conducting tests, based on the specific operational situation of the game, order data for virtual goods and online duration can be collected within a limited test period for correlation analysis. Through statistical calculations, the correlation between the online duration of client devices and abnormal value storage behavior obtained during actual operation can be objectively evaluated, setting effective monitoring indicators for the entire lifecycle of game operation.

[0010] The sampling and screening process employs a normal distribution algorithm, including: defining the test period duration; recording the total number of orders within the current test period as Total_Num, the number of orders marked as abnormal stored value as Proxy_Num, the total number of reported abnormal orders as Error_Num, the total number of refunded orders as Refund_Num, and the current online duration as N. i , where i is a natural number; calculate the reported anomaly percentage: E(N) i ) = Error_Num / Proxy_Num; Calculate the refund percentage: R(N) i ) = Refund_Num / Total_Num; Calculate the proportion of funds held in reserve: P(N) i ) = Proxy_Num / Total_Num; using the formula F(N) i )=(E(N i )+R(N i )) / P(N i The comprehensive value for each test cycle is calculated; these comprehensive values ​​are then grouped into a series, and a curve is plotted using the normal distribution curve formula; the maximum value of the curve corresponds to N. iThis refers to the optimal value for the online duration. The normal distribution algorithm is used for computation, consuming minimal resources and not impacting server performance. It also allows for rapid sampling and selection to determine the optimal value. Furthermore, the calculation of the online duration threshold does not affect server operation during testing, and the results more closely reflect actual operating conditions.

[0011] Define the test cycle duration to cover two world time zone cycles; complete multiple test cycles within one month.

[0012] The process of updating the device information table includes: after a user successfully logs in, determining whether the currently logged-in client device information already exists in the device information table; if not, saving the currently logged-in client device information in the device information table; the client reports its online status according to a preset reporting period; the server receives the online status, queries the device information table, and obtains the online duration information of the current client device; if the online duration of the current client device is greater than the online duration threshold, a security identifier is added to the current client device; otherwise, the online duration is continuously accumulated and the online duration information of the current client device is updated.

[0013] The method for setting the preset reporting period includes: performing stress tests on the server to obtain the minimum reporting period under stress conditions; setting a redundancy amount based on the server's performance; and determining the preset reporting period based on the minimum value and the redundancy amount. By presetting the reporting period according to the server's stress tolerance, the minimum reporting period is found while ensuring normal use by a certain number of users. This allows for faster reporting of results, reduces latency and errors, and does not affect server performance.

[0014] The minimum value of the reporting period is calculated using an extreme approximation algorithm and denoted as M(min); the current number of users under load testing is denoted as online_usr, the maximum allowed number of users on the server is denoted as max_allow_sur, the maximum allowed performance loss on the server is denoted as max_allow_loss, and the current reporting period is denoted as M. j j is a natural number; M(min) = F(online_usr, M j (max_allow_sur, max_allow_loss). The algorithm is selected based on the server's load capacity, ensuring that the computational resources used by the algorithm do not increase server load or affect normal operation. Given the current technology and server specifications, using the limit approximation algorithm will not impact performance and allows for setting a reasonable reporting cycle.

[0015] The game abnormal recharge monitoring method of the present invention also includes asynchronous monitoring measures performed only on the server side as a background task; the asynchronous monitoring measures are performed after the payment process is completed, including: continuously scanning the order table and marking suspicious objects; setting abnormal indicators, and judging whether the suspicious objects have abnormal recharges based on the abnormal indicators; wherein, the method of marking the suspicious objects includes: if multiple accounts are found to be recharged by the same client device, the client device is marked as suspicious; if multiple accounts are found to be recharged by the same IP address, the IP address is marked as suspicious; if there are refund orders, the accounts, client devices, and IP addresses associated with the refund orders are marked as suspicious; the abnormal indicators include: the maximum number of accounts recharged by a client device and / or an IP address within a preset time period, and the maximum frequency of refund orders initiated by the suspicious device. By using asynchronous monitoring measures, orders are continuously scanned in the background process of the server. The analysis and identification of abnormal stored value are carried out by associating client devices, accounts, and IP addresses (all or part of the three items) with refund orders. The analysis is comprehensive and only the marked suspicious objects are evaluated after the analysis is completed. On the one hand, the evaluation of suspicious objects can reduce false judgments by setting abnormal indicators. On the other hand, it only works on the server side, which is easy to implement and does not affect the performance of the client.

[0016] The method for setting the maximum number of accounts that can store value for a single IP address includes: establishing a user table, obtaining the distribution of accounts to IP addresses, establishing a distribution curve with IP address as the X-axis and the number of accounts corresponding to the IP address as the Y-axis; and setting the maximum number of accounts that can store value for a single IP address based on the Y-axis value corresponding to 80% of the maximum value on the X-axis.

[0017] The game abnormal recharge monitoring method of the present invention further includes: defining an evaluation threshold based on the operation strategy to evaluate the abnormal recharge situation; if the evaluation result reaches the evaluation threshold, the synchronous monitoring measures and the asynchronous monitoring measures are implemented together; if not, only the asynchronous monitoring measures are implemented; the evaluation process includes: obtaining the game's current ranking in the application market, predicting the abnormal recharge situation based on the current ranking; and / or conducting tests using synchronous and asynchronous monitoring measures together, and judging the current actual abnormal recharge situation based on the test results; the evaluation threshold includes the ranking value and the number of abnormal recharge orders. By evaluating the abnormal recharge situation and implementing appropriate monitoring measures, it is beneficial to balance the effectiveness of monitoring and the efficient use of system resources. When the abnormal recharge situation is not serious, from the perspective of efficient use of system resources, it is not necessary to enable synchronous monitoring, only asynchronous monitoring is retained to save system resources and achieve the monitoring purpose. When the evaluation determines that the abnormal recharge situation is serious, synchronous and asynchronous monitoring measures are fully implemented to maximize the accuracy of identifying abnormal recharge and the rigor of monitoring, to deal with serious abnormal recharge situations, and to avoid operational losses.

[0018] The monitoring method for abnormal game top-ups of the present invention further includes: measures to correct wrongly banned accounts, including: providing an order resending function; providing a customer complaint feedback interface in the game interface, the feedback interface including an option control for wrongly judging abnormal top-ups; triggering the option control for wrongly judging abnormal top-ups to submit a wrongly judged work order; identifying whether there is a wrongly banned account based on the wrongly judged work order, and if so, unbanning the corresponding account and reshipping the goods.

[0019] Another aspect of the present invention provides an electronic device, including a memory; the memory stores a plurality of instructions, the instructions being adapted for loading by a processor and executing the game abnormal storage monitoring method of the present invention.

[0020] Compared with the prior art, the main beneficial effects of the present invention are:

[0021] 1. This invention provides a method for monitoring abnormal game top-ups. Through synchronous monitoring starting from game login, it proactively identifies abnormal top-ups, preventing them at the beginning of the payment process, avoiding delays, and reducing losses for game developers. Through asynchronous monitoring on the server side, it flexibly selects monitoring strategies based on the abnormal top-up situation, improving the accuracy of monitoring while considering the impact of monitoring measures on client performance, effectively achieving the monitoring objective in a way that optimizes system resources. Through the fusion and analysis of diverse data and backend data, data processing is more rigorous, increasing the difficulty for third-party cracking and making the monitoring measures more stable and reliable. By providing measures to correct mistakenly banned accounts, it can promptly correct mistakenly banned accounts in a way that facilitates player operation, improving customer experience. It comprehensively and reasonably monitors abnormal top-ups while minimizing the impact on normal players, providing a positive solution for maintaining a healthy game operating environment.

[0022] 2. An electronic device of the present invention has corresponding advantages because it can implement the abnormal stored value monitoring method of the present invention. Attached Figure Description

[0023] Figure 1 This is a schematic representation of device information in Embodiment 1 of the present invention.

[0024] Figure 2 This is a schematic diagram of the synchronous monitoring measures in Embodiment 1 of the present invention.

[0025] Figure 3 This is a schematic diagram illustrating the distribution of the number of accounts to IP addresses in Embodiment 2 of the present invention.

[0026] Figure 4 This is a schematic diagram of the abnormal stored value monitoring method according to Embodiment 2 of the present invention. Detailed Implementation

[0027] The technical solutions in specific embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] The operations of the embodiments are described in a specific order in the following embodiments. These operations can be performed substantially in parallel, or sometimes interspersed, depending on the purpose to be achieved by the operations involved. This description of the order is intended to provide a better understanding of the details in the embodiments and to fully comprehend the invention; however, this description of the order does not limit the scope of the invention.

[0029] The following embodiments of the present invention use proxy pre-paid behavior as a typical example of abnormal game pre-paid behavior, but do not limit the abnormal pre-paid monitoring method of the present invention to only the abnormal game pre-paid monitoring of proxy pre-paid institutions.

[0030] The term "proxy top-up" refers to a specific type of abnormal top-up behavior. It involves proxying top-ups for real players and then maliciously refunding them, causing players to receive virtual game items at a lower price than they should be. The proxy agency profits from this abnormal top-up behavior. For ease of understanding, this invention uses the phenomenon of proxy top-up as an example rather than a limiting description. When proxy top-up occurs, it generally manifests as follows: 1) The client device ID used for account login changes from the player's own client device to the proxy top-up's client device; 2) After logging into the player's account, the proxy top-up agent stays online briefly, generally only for the duration of the top-up operation (longer online times are not economically viable for the proxy top-up agent, therefore shorter online times are more advantageous); 3) After the top-up is completed, the proxy top-up agent immediately logs out, after which the player logs back into their own client device to continue playing the game.

[0031] Example 1

[0032] In Embodiment 1 of this invention, the method for monitoring abnormal game top-ups includes: synchronous monitoring measures. In this embodiment, taking an Android or iOS client as an example, the synchronous monitoring measures are implemented through cooperation between the client and server, via HTTP communication. After the client successfully logs into the server, both parties establish HTTP communication via API. A device information table is created on the server to store client data. In the example, the device information table records the online duration of player accounts. Synchronous monitoring measures are implemented based on the online duration of the client device corresponding to the account, as well as switching behavior (changes in client device and active IP address). In this embodiment, as... Figure 1 As shown, the client data in the device information table includes: application ID (app_id), account (account), device ID (device_id), active IP address (active_ip), security identifier (is_safe), online time (online_timeline), and the time marked as safe (safed_at), etc.

[0033] In this embodiment, the preset period for clients to report online status is M minutes, and the value of M is determined based on the actual business operation. The example uses stress testing combined with an "extreme approximation algorithm" to determine this: under the pressure conditions, the minimum value M(min) is taken, and a certain amount of redundancy is added to M(min) to set the reporting period. In the example scenario, the server needs to serve 2000 users simultaneously. Without considering a certain amount of redundancy, the server may not function properly during peak periods. A better approach is to add 20% redundancy. The algorithm selection based on the server's stress tolerance is not limited to the extreme approximation algorithm. When selecting an algorithm, it is considered that the computational resources used by the algorithm will not increase the server's pressure and affect normal use. Setting redundancy is to ensure the server's normal operation. Based on the current technology and the server used, the extreme approximation algorithm is preferred as it will not affect performance and allows for a reasonable reporting period. The algorithm in the example is as follows: M(min) = F(online_usr, M j (max_allow_sur, max_allow_loss). Where online_usr represents the current number of users in the load test; M j `j` represents the current reporting period, where `j` is a natural number; `max_allow_sur` represents the maximum number of users allowed on the current server; and `max_allow_loss` represents the maximum allowable performance loss on the current server. The example uses a limit approximation algorithm to better match the server's load capacity. For instance, if a server is required to serve at least 2000 users simultaneously, then, while ensuring normal operation for 2000 users, find the minimum value of `M`. j The value is set to M(min). M(min) plus the redundancy is used to obtain the preset M minutes as the reporting period. This can report results faster, reduce latency and errors, and will not affect server performance.

[0034] In this embodiment, a test is conducted with a preset online duration threshold of N minutes. The example setting method is as follows: Define the duration of a test cycle. Due to the uncertainty of world time zones, ideally, the duration of a test cycle should be longer than one world time zone cycle, i.e., greater than 24 × 60 minutes. Generally, the test period should not be too long or too short. Ideally, each test cycle should be completed within one month. A preferred test cycle is two world time zone cycles, i.e., 48 × 60 minutes. For a test cycle, the total number of orders within the current test cycle is recorded as Total_Num, the number of orders marked as abnormal stored value is recorded as Proxy_Num, the total number of reported abnormal orders is recorded as Error_Num, the total number of refunded orders is recorded as Refund_Num, and the current online duration is recorded as N. iLet i be a natural number. First, the game operator defines the minimum acceptable online time as N1 minutes and the maximum acceptable online time as N(L) minutes. Then, with an incrementing step of s minutes, an increasing sequence of time lengths is obtained, {N1, N2, N3, ..., N(L)}. The sequence length should not be too long, preferably within L (i.e., s ≥ 1 minute); define s as the time step. In the example, s is randomly selected, such as 2 minutes, 3 minutes, 4 minutes, or 5 minutes, depending on the required calculation precision. Generally, it should not be too long, as a large step size will affect the precision. Define L as the sequence length, i.e., the number of sequence units, which can be set randomly, but 10 units are generally preferred.

[0035] Calculate the reported anomaly percentage: E(N) i ) = Error_Num / Proxy_Num; Calculate the refund percentage: R(N) i ) = Refund_Num / Total_Num; Calculate the proportion of funds held in reserve: P(N) i ) = Proxy_Num / Total_Num; using the formula F(N) i )=(E(N i )+R(N i )) / P(N i Regarding the test results, E(N) i ) and R(N i P(N) should be as small as possible. i The larger the value, the better. The comprehensive value F(N) for each test cycle is calculated. i The resulting composite values ​​are arranged into a sequence. The normal distribution curve formula is used: Plot the sequence as a curve. The current online duration corresponding to the maximum value of the curve is the optimal value N(o). Set N(o) as the online duration threshold, i.e., N minutes.

[0036] In this embodiment, after the client successfully logs into the server, the client and server establish HTTP communication via API. The process of synchronous monitoring measures is as follows: Figure 2As shown, users log in to the game via Android and iOS client devices. After successful login, the game's internal logic reports the user's login information, including the application ID, account, device ID, and active IP address. Upon receiving the login information from the client, the server first queries the "Device Information Table" for the currently logged-in client device information. If the client device information exists, it determines whether the currently logged-in client device is a secure device by checking the security identifier field in the Device Information Table. If it is a secure device with a security identifier, it means the currently logged-in player is a legitimate player, not a third party, and subsequent operations are ignored; otherwise, the online time of the last login on that client device is reset to zero. If the currently logged-in client device information does not exist, the player's currently logged-in client data is recorded in the Device Information Table. After the user starts the game, a background thread is started within the game, reporting the game's online status every M minutes according to the preset period for client online status reporting. The online status information also includes the current application ID, account, device ID, and active IP address. After the server receives the game's online status report, it first queries the "Device Information Table" to determine whether the current client device is a secure device. If the online time recorded in the Device Information Table exceeds a preset online time threshold of N minutes, a security flag is added to the client device, and the security flag in the table is changed to true. Otherwise, the online time of the client device is accumulated: online_timeline = online_timeline + (M × 60). To ensure the accuracy of the online time recording, the online time is accumulated in seconds, and the online time information in the Device Information Table is updated. The above operation is repeated throughout the client's online time until the logged-in client device meets the conditions for adding a security flag, and it is then marked as a secure device.

[0037] When a user tops up their account via a client device, the client device information needs to be reported after successful top-up. Upon receiving this report, the server queries the "Device Information Table" and determines the order based on the current top-up data. If the client device being topped up was not previously in the "Device Information Table," or if the client device being topped up matches a previously found device in the table and already has a security tag, the order is fulfilled directly; otherwise, the next step is performed. The server records the single online duration of the client device being topped up. If the online duration exceeds N minutes, a security tag is added to the device, and the order is fulfilled; otherwise, the order is not fulfilled, and the order is marked as a top-up order.

[0038] In this embodiment, the probability of mistakenly banning accounts is low when using synchronous monitoring measures. Even if mistakenly banning accounts occurs, the monitoring method for abnormal game recharges in this embodiment may also include corrective measures for mistakenly banning accounts.

[0039] The example corrective measures for mistakenly banned accounts include providing an unbanning option on the server-side order list interface and supporting reshipment. First, the order reshipment function needs to be provided. Then, a customer feedback interface needs to be provided on the client-side game interface. Players can submit feedback on the corresponding order's anomalies through this interface, which includes a "misjudged recharge" option control. After a player triggers the "misjudged recharge" option control and submits a recharge misjudgment work order, it can be submitted to customer service for verification. If a mistakenly banned account exists, the legitimate player can still operate through the customer feedback interface, allowing for quick unbanning and reshipment, improving the user experience for legitimate players.

[0040] This embodiment also provides an electronic device, an example of which is a server, including a memory. The example server is capable of establishing HTTP communication with a mobile terminal. The memory stores multiple instructions adapted for loading and execution by a processor using the game anomaly monitoring method of this embodiment. In some embodiments, the electronic device is a smartphone; in others, it is a system comprising a server and a terminal; this is not limited.

[0041] Example 2

[0042] In this embodiment, the monitoring method for abnormal game top-ups also includes asynchronous monitoring measures performed on the server side as background tasks. In the example asynchronous monitoring measures, the background process continuously scans the order table, marking suspicious objects; it sets anomaly indicators and determines whether suspicious objects have abnormal top-ups based on these indicators. Marking suspicious objects includes: if multiple accounts are found to be topped up on the same client device, the device is marked as suspicious; if multiple accounts are found to be topped up on the same IP address, the IP address is marked as suspicious; if a refund order exists, the account, client device, and IP address associated with the refund order are marked as suspicious. Example anomaly indicators include: the maximum number of accounts topped up on a single client device within a preset time period; the maximum number of accounts topped up on a single IP address; and the maximum frequency of refund orders initiated by a suspicious device (which can be represented by the number of refund orders initiated and the interval between each order). The maximum number of accounts topped up on a single client device within a preset time period depends on how many accounts the game operator can tolerate a single client device using. The setting of abnormal indicators can be based on a comprehensive consideration of actual application and system resource allocation. Only one indicator or several indicators can be set. The evaluation can be based on the maximum number of accounts stored on a client device within a preset time period, or only on the maximum frequency of refund orders initiated by suspicious devices, or a combination of indicators can be used for evaluation. There are no restrictions.

[0043] like Figure 3 As shown, the method for setting a maximum number of accounts that can be stored for a single IP address includes: creating a user table, obtaining the distribution of the number of accounts per IP address, and constructing a distribution curve with IP address as the X-axis and the number of accounts corresponding to the IP address as the Y-axis; setting a maximum number of accounts that can be stored for a single IP address based on the Y-axis value corresponding to 80% of the maximum value on the X-axis. The number of accounts corresponding to a single IP address in the user table is used for evaluation. If the number of accounts corresponding to a single IP address is too high, it is identified as a proxy IP address. In the example, the maximum number of accounts that can be stored for a single IP address is obtained by adding redundancy to the Y-axis value corresponding to the 4 / 5 position on the X-axis. If the number of accounts corresponding to an IP address at the 4 / 5 position on the X-axis is less than the maximum tolerable value, then IP addresses after the 4 / 5 position on the X-axis are proxy IPs; otherwise, all IP addresses starting from the 4 / 5 position on the X-axis are proxy IPs.

[0044] In the example scenario, if the same client device is found to be making top-ups for multiple accounts, it is initially marked as a suspicious device. If this suspicious device makes more than 5 top-ups within a single day, it is determined to be a third-party top-up device and will be banned. If the same IP address is found to be making top-ups for multiple accounts, it is marked as a suspicious IP. If this suspicious IP makes more than 10 top-ups within a single day, it is determined to be a third-party top-up IP and will be banned. If refund orders are found, the accounts, client devices, and IP addresses involved in the refund orders are marked as suspicious entities. If a suspicious account makes more than 10 refunds in total, and the average interval between refunds is less than 1 hour, the account is banned; if a suspicious device makes more than 10 refunds in total, and the average interval between refunds is less than 1 hour, the client device is banned; if a suspicious IP makes more than 10 refunds in total, and the average interval between refunds is less than 1 hour, the IP address is banned. The maximum number of refund orders initiated by suspicious entities will be confirmed by operations personnel based on the actual situation. Refunds are not always indicative of abnormal deposits, but there is usually a maximum tolerance limit, defined in this example as 10 refunds. Furthermore, refunds are generally not consecutive; consecutive refunds (such as many refunds within an hour) usually indicate a third-party deposit. By evaluating client devices, IP addresses, accounts, and refund orders from multiple perspectives, monitoring accuracy is high, the probability of wrongly banning accounts is greatly reduced, and the system is difficult to crack, enabling stable and reliable monitoring.

[0045] In this embodiment, the monitoring method for abnormal game top-ups further includes: assessing the abnormal top-up situation and determining monitoring measures based on the assessment results: defining an assessment threshold based on the operational strategy; if the assessment result reaches the assessment threshold, then synchronous and asynchronous monitoring measures are implemented together; if it does not reach the threshold, then only asynchronous monitoring measures are implemented; the assessment process includes: obtaining the game's current ranking in the app store, predicting the abnormal top-up situation based on the current ranking; and / or conducting tests using both synchronous and asynchronous monitoring measures, and determining the actual current abnormal top-up situation based on the test results. The example assessment threshold includes the ranking value and the number of abnormal top-up orders. Depending on the actual operational situation, the assessment can be based solely on the current ranking or on the results of tests conducted through joint implementation, and is not limited to this. In the example scenario, if the game's current ranking in the app store is below 10th, then only asynchronous monitoring measures are implemented on the server side; if the ranking is within the top 10, then both synchronous and asynchronous monitoring measures are implemented together. Games with higher rankings generally have more serious top-up issues and require both synchronous and asynchronous monitoring. In the example scenario, using the game's ranking value in the app store as an assessment threshold aligns with the characteristics of top-up behavior in game operations. Generally, third-party payment service providers cannot accurately ascertain the current popularity of a game. They often rely on app store rankings to assess the profitability of targeting a game for third-party payment services. Targeting top-ranked games in the app store is likely to maximize profits for these providers. Additionally, players may use third-party payment services for discounts (which are typically cheaper than the game's original top-up price). Top-ranked games usually have high daily active users, generally exceeding 50,000. With such a large player base, the probability of players using third-party payment services is relatively high. Therefore, ranking can reasonably assess the likelihood of serious third-party payment activity.

[0046] In some implementations, the process of monitoring abnormal game recharges is as follows: Figure 4As shown, besides considering app store rankings, simultaneous synchronous and asynchronous monitoring measures can be implemented for continuous testing in the early stages. The test results can then be used to determine the current abnormal recharge situation. In the example scenario, if the test results show that the number of abnormal recharge orders has exceeded the maximum tolerance limit of the operational strategy, it is determined that the current recharge situation is serious, and simultaneous implementation continues. The results of simultaneous implementation can reflect the true recharge situation to the greatest extent. Once the monitoring results show that the recharge is not serious (in the example scenario, the number of abnormal recharge orders is not high, less than the maximum tolerance limit of the operational strategy), synchronous monitoring measures are turned off for efficient use of system resources, and only the server-side asynchronous monitoring measures continue to monitor, saving system resources and achieving the monitoring objective. In some implementation scenarios, test tasks are set according to the operational strategy and game operation situation. Simultaneous and asynchronous monitoring measures are implemented periodically to test the current abnormal recharge situation. After the test task is completed, the test results determine whether simultaneous implementation on both sides or only asynchronous monitoring on one side is needed in the following period. Specific situations are not limited here.

[0047] The common English terms or letters used in this invention for clarity of description are for illustrative purposes only and are not limiting interpretations or specific uses. They should not be used to limit the scope of protection of this invention based on their possible Chinese translations or specific letters.

[0048] The present invention has been described in detail above. Specific examples have been used to illustrate the structure and working principle of the invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core idea of ​​the present invention. It should be noted that those skilled in the art can make several improvements and modifications to the present invention without departing from the principle of the invention, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A method for monitoring abnormal game top-ups, characterized by: include: Synchronous monitoring measures; The synchronous monitoring measures include: setting a preset online duration threshold; A device information table is created on the server to store client data; Obtain the information of the currently logged-in client device, accumulate the online time of this login, and update the device information table; when the accumulated online time of this login exceeds the threshold, add a security identifier to the client device; Obtain the client device information for the current stored value and query the device information table: if the client device for the current stored value does not exist, or exists and has been marked with a security identifier, it is determined to be a normal stored value; otherwise, record the single online duration of the client device for the current stored value, and if it does not exceed the threshold, it is determined to be an abnormal stored value. The client data includes: application ID, account, device ID, IP address, online duration information, and the security identifier; The method for setting the preset online duration threshold includes: Conduct tests to obtain the total number of orders, the number of orders marked as abnormal stored value, the total number of reported abnormal orders, and the total number of refunded orders within several test periods; An increasing time length sequence is obtained by using a random incrementing step size; sampling and screening are performed, and statistical analysis is conducted to obtain the optimal value of the online duration as the online duration threshold. The sampling and screening process employs a normal distribution algorithm, including: Define the test cycle duration; The total number of orders in the current test period is denoted as Total_Num, the number of orders marked as abnormal stored value is denoted as Proxy_Num, the total number of reported abnormal orders is denoted as Error_Num, the total number of refunded orders is denoted as Refund_Num, and the current value of online time is denoted as Ni, where i is a natural number; Calculate the reported anomaly percentage: E(Ni) = Error_Num / Proxy_Num; Calculate the refund percentage: R(Ni) = Refund_Num / Total_Num; Calculate the escrow percentage: P(Ni) = Proxy_Num / Total_Num; The comprehensive value for each test cycle is calculated using the formula F(Ni)=(E(Ni)+R(Ni)) / P(Ni); The combined values ​​are arranged into a series, and the series is plotted as a curve using the normal distribution curve formula; the Ni corresponding to the maximum value of the curve is the optimal value of the online duration.

2. The method for monitoring abnormal game data storage according to claim 1, characterized in that: Once a prepaid value is identified as abnormal, the corresponding prepaid value order will be marked as an abnormal prepaid value order.

3. The method for monitoring abnormal game top-ups according to claim 1, characterized in that: The test cycle duration is defined to cover two world time zone cycles, i.e., 48 x 60 minutes; multiple test cycles are completed within one month.

4. The method for monitoring abnormal game data storage according to claim 1, characterized in that: The steps for updating the device information table include: After a user successfully logs in, it is determined whether the information of the currently logged-in client device already exists in the device information table. If not, the information of the currently logged-in client device is saved in the device information table. The client reports its online status according to a preset reporting period. Upon receiving the online status, the server queries the device information table to obtain the online duration information of the current client device. If the online duration of the current client device is greater than the online duration threshold, a security identifier is added to the current client device; otherwise, the online duration is continuously accumulated and the online duration information of the current client device is updated.

5. The method for monitoring abnormal game data storage according to claim 4, characterized in that: The method for setting the preset reporting period includes: Perform stress tests on the server to obtain the minimum reporting period under stress conditions; The redundancy is set based on the server performance of the server; the preset reporting period is determined based on the minimum value and the redundancy.

6. The method for monitoring abnormal game data storage according to claim 5, characterized in that: The minimum value of the reporting period is calculated using the limit approximation algorithm and denoted as M(min); the current number of users under load testing is denoted as online_usr, the current maximum allowed number of users on the server is denoted as max_allow_sur, the current maximum allowed performance loss on the server is denoted as max_allow_loss, and the current reporting period is denoted as Mj, where j is a natural number; M(min)=F(online_usr,Mj,max_allow_sur,max_allow_loss).

7. The method for monitoring abnormal game data storage according to claim 1, characterized in that: It also includes asynchronous monitoring measures performed only on the server side as background tasks; The asynchronous monitoring measures are performed after the payment process is completed, including: continuously scanning the order table and marking suspicious objects; Set anomaly indicators, and determine whether the suspicious object has abnormal stored value based on the anomaly indicators; The method for marking the suspicious objects includes: if the same client device is found to have stored value for multiple accounts, the client device is marked as suspicious; if the same IP address is found to have stored value for multiple accounts, the IP address is marked as suspicious; if there is a refund order, the account, client device, and IP address associated with the refund order are marked as suspicious. The abnormal indicators include: the maximum number of accounts with stored value on a single client device and / or a single IP address within a preset time period, and the maximum frequency of refund orders initiated by suspicious devices.

8. The method for monitoring abnormal game data storage according to claim 7, characterized in that: The method for setting the maximum number of accounts that can store value for a single IP address includes: establishing a user table, obtaining the distribution of accounts to IP addresses, establishing a distribution curve with IP address as the X-axis and the number of accounts corresponding to the IP address as the Y-axis; and setting the maximum number of accounts that can store value for a single IP address based on the Y-axis value corresponding to 80% of the maximum value on the X-axis.

9. The method for monitoring abnormal game data storage according to claim 8, characterized in that: Also includes: Based on operational strategies, assessment thresholds are defined to evaluate abnormal stored value situations. If the evaluation result reaches the evaluation threshold, the synchronous monitoring measures and the asynchronous monitoring measures will be implemented together; If the target is not met, then only the aforementioned asynchronous monitoring measures will be implemented; The assessment process includes: obtaining the game's current ranking in the app store, and predicting abnormal recharge situations based on the current ranking; The test may be conducted using a combination of synchronous and asynchronous monitoring measures, and the current actual situation of abnormal stored value will be determined based on the test results; the evaluation thresholds include the ranking value and the number of abnormal stored value orders.

10. The method for monitoring abnormal game top-ups according to any one of claims 1 to 9, characterized in that: Also includes: Corrective measures for mistakenly banned accounts include: providing an order resending function; providing a customer complaint feedback interface in the game interface, the feedback interface including an option control for incorrect abnormal recharge; triggering the option control for incorrect abnormal recharge to submit a work order for incorrect recharge; and based on the work order for incorrect recharge, identifying whether there is a mistakenly banned account, and if so, unbanning the corresponding account and reshipping the goods.

11. An electronic device, characterized in that: Includes a memory; the memory stores multiple instructions adapted for loading and execution by a processor of the game abnormal storage monitoring method according to any one of claims 1 to 10.

Images