Methods, apparatus, media and equipment for generating identification features of abnormal registration events

Abstract

This disclosure provides a method, apparatus, medium, and device for generating identification features for abnormal registration events. The method involves acquiring attributes of registration events occurring within a set time period, extracting several event features of the registration events based on extraction rules that match the network service identifier and registration source identifier corresponding to the registration events, and generating corresponding key-value pairs based on these rules. In each key-value pair, the key includes the network service identifier, the registration source identifier, and the feature type identifier to which each event feature belongs under the extraction rule; the value includes the value of each event feature under the extraction rule. The obtained key-value pairs are then clustered, meaning key-value pairs belonging to the same category are grouped into the same key-value pair set. Furthermore, identification features for identifying abnormal registration events are generated based on the key-value pair set with the highest number of included key-value pairs.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of information technology, and more specifically, the embodiments of this disclosure relate to a method, apparatus, medium, and device for generating identification features of abnormal registration events. Background Technology

[0002] In the internet age, individuals or organizations can register as users of internet providers and obtain corresponding internet services. For internet providers, however, effectively identifying abnormal registration events (such as individuals from the black market registering on online platforms) is a crucial issue.

[0003] Generally speaking, registration events can be judged based on some identification features used to identify abnormal registration events. If a registration event meets the identification features of abnormal registration events, then the registration event is identified as an abnormal registration event.

[0004] Therefore, a more effective scheme for generating identification features of abnormal registration events is needed. Summary of the Invention

[0005] In this context, embodiments of the present disclosure aim to provide a method, apparatus, medium, and device for generating identification features of abnormal registration events, so as to generate more effective identification features.

[0006] In a first aspect of this disclosure, a method for generating identification features of abnormal registration events is provided for providing registration risk control functions for several network services. Each network service accepts registration events through several registration sources, including: registration device sources and / or registration channel sources. The method includes:

[0007] Obtain the attribute information of the monitored registration event, which includes: the network service identifier corresponding to the network service that accepted the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event;

[0008] Based on several extraction rules that match the network service identifier and the registration source identifier, extract several event features corresponding to each extraction rule from the event feature set;

[0009] For each extraction rule, a key-value pair corresponding to that extraction rule is generated; wherein, the key in the key-value pair contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature corresponding to the extraction rule belongs, and the value in the key-value pair contains the value of each event feature corresponding to the extraction rule;

[0010] Based on the similarity between key-value pairs obtained within a set time period, key-value pairs with a similarity greater than a set similarity are grouped into the same key-value pair set. Furthermore, based on the key-value pair set containing more than a first number of key-value pairs, identification features for identifying abnormal registration events are generated.

[0011] In a second aspect of this disclosure, an apparatus for generating identification features of abnormal registration events is provided, used to provide registration risk control functions for several network services, each network service accepting registration events through several registration sources, including: registration device sources and / or registration channel sources, the apparatus comprising:

[0012] The acquisition module acquires the attribute information of the monitored registration event. The attribute information includes: the network service identifier corresponding to the network service that accepted the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event.

[0013] The extraction module extracts several event features corresponding to each extraction rule from the event feature set based on several extraction rules that match the network service identifier and the registration source identifier.

[0014] The first generation module generates a key-value pair corresponding to each extraction rule; wherein, the key in the key-value pair contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature corresponding to the extraction rule belongs, and the value in the key-value pair contains the value of each event feature corresponding to the extraction rule;

[0015] The second generation module, based on the similarity between each key-value pair obtained within a set time period, groups key-value pairs with a similarity greater than a set similarity into the same key-value pair set, and generates identification features for identifying abnormal registration events based on the number of key-value pairs included in the key-value pair set exceeding a first number.

[0016] In a third aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0017] In a fourth aspect of the present disclosure, a computing device is provided, including a memory and a processor; the memory is used to store computer instructions executable on the processor, and the processor is used to implement the method of the first aspect when executing the computer instructions.

[0018] The above technical solution addresses the issue that different key-value pairs belonging to the same category are often obtained by applying the same extraction rules to different registration events. Therefore, a large number of key-value pairs belonging to the same category indicates a large number of registration events with common characteristics. In the field of registration risk control, a large number of common registration events occurring within a limited time period are often considered abnormal registration events. Thus, based on a sufficient number of key-value pairs belonging to the same category, identification features for identifying abnormal registration events can be generated. These generated features are relatively accurate and can effectively identify abnormal registration events.

[0019] Furthermore, the above technical solution eliminates the need for designing complex risk control models to extract identifying features of abnormal registration events from individual registration events. Instead, it utilizes relatively simple pre-defined extraction rules to extract key-value pairs from registration events, performs clustering statistics on these pairs, and thus identifies the common features corresponding to a large number of registration events with common characteristics occurring within a limited time period, which serve as the identification features. Therefore, the implementation of the above technical solution is relatively simple, determining relatively effective identifying features of abnormal registration events at a relatively low technical cost. Attached Figure Description

[0020] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0021] Figure 1 An exemplary flow is provided for a method of generating identification features for abnormal registration events;

[0022] Figure 2 An example is provided of a process for generating identification features;

[0023] Figure 3 An example is provided of a process for a registration risk control system to process registration event flows;

[0024] Figure 4 An exemplary structure for generating identification features of abnormal registration events is provided;

[0025] Figure 5 An exemplary computer-readable storage medium is provided;

[0026] Figure 6 An exemplary structural diagram of a computing device is provided.

[0027] In the accompanying drawings, identical or corresponding reference numerals denote identical or corresponding parts. Any number of elements in the drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning. Detailed Implementation

[0028] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0029] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0030] According to embodiments of this disclosure, a method, apparatus, medium, and device for generating identification features of abnormal registration events are proposed.

[0031] In the field of registration risk control, a large number of common registration events occurring within a limited time period are often considered abnormal registration events. Registration risk control is a branch of risk control that primarily targets risk management for registration events related to online services. Specifically, registration risk control aims to identify whether a registration event is abnormal, in order to trigger interception mechanisms for abnormal registration events that are currently occurring (accounts that have not yet been created for online services), or to trigger freezing mechanisms for abnormal registration events that have already occurred (accounts that have already been created for online services).

[0032] In the field of registration risk control, there are generally two aspects to focus on. One aspect is to determine the identification features used to identify abnormal registration events, and the other aspect is to identify abnormal registration events based on the identification features used to identify abnormal registration events. The former aspect can be understood as risk control preparation work, and the latter aspect can be understood as risk control execution work.

[0033] The abnormal registration events defined in this disclosure are in contrast to normal registration events. Normal registration events are often isolated, meaning that different normal registration events are usually initiated independently by different ordinary users who are not related to or contact each other. Abnormal registration events, on the other hand, are often batch-based, meaning that a batch of abnormal registration events is often initiated multiple times by the same user or organization within a limited time period. Since the same batch of abnormal registration events is initiated by the same user or organization (such as a black market group), these abnormal registration events often share commonalities.

[0034] However, in practice, the difficulty in identifying abnormal registration events lies in the fact that users or organizations initiating a batch of abnormal registrations often deliberately employ methods to create the anomalies (such as registering using significantly different IP addresses or phone numbers), making these different abnormal registration events, which actually belong to the same batch, appear as isolated, ordinary registration events in order to evade identification by registration risk control agencies. For registration risk control agencies, it is difficult to design an identification feature that can distinguish between actual ordinary registration events and abnormal registration events that appear to be ordinary.

[0035] Therefore, the technical solution provided in this disclosure is as follows: First, obtain some attributes of registration events occurring within a set time period (including the network service identifier corresponding to the network service accepting the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event). Then, based on extraction rules matching the network service identifier and registration source identifier corresponding to the registration event, extract several event features of the registration event according to the matching extraction rules, so as to generate a corresponding key-value pair based on the matching extraction rules. In this key-value pair, the key contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature belongs according to the extraction rule; the value contains the value of each event feature according to the extraction rule. Then, perform cluster statistics on the obtained key-value pairs, that is, group key-value pairs belonging to the same category into the same key-value pair set. Finally, generate identification features for identifying abnormal registration events based on the key-value pair set containing a larger number of key-value pairs.

[0036] The above technical solution addresses the issue that different key-value pairs belonging to the same category are often obtained by applying the same extraction rules to different registration events. Therefore, a large number of key-value pairs belonging to the same category indicates a large number of registration events with common characteristics. In the field of registration risk control, a large number of common registration events occurring within a limited time period are often considered abnormal registration events. Thus, based on a sufficient number of key-value pairs belonging to the same category, identification features for identifying abnormal registration events can be generated. These generated features are relatively accurate and can effectively identify abnormal registration events.

[0037] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments.

[0038] Figure 1 An exemplary process for generating identification features of abnormal registration events is provided, including the following steps:

[0039] S100: Obtain attribute information of registered events detected within a set time period.

[0040] Figure 1The illustrated method flow is used to provide registration risk control functions for several network services. The network services defined in this disclosure can refer to any service that can be obtained through a network. For example, an application (APP) installed on a mobile operating system (such as iOS) can be a form of network service; a website accessible by a browser can be a form of network service; a desktop client installed on a personal computer operating system (such as Windows) can be a form of network service. Users can obtain any of the above-mentioned network services through the network, and typically need to register on the network service to obtain an account before obtaining it.

[0041] Figure 1 The method shown can be applied to registration risk control systems that are independent of each network service. The registration risk control system interfaces with different network services, receives registration events from different network services, performs risk control, and returns the risk control results to the corresponding network service.

[0042] also, Figure 1 The method shown can be applied to a server corresponding to a certain network service. This server can not only provide registration risk control functions for its own network service, but also provide registration risk control functions for other network services.

[0043] For ease of description, the registration risk control system will be referred to as [the system] below. Figure 1 The execution entity of the method flow shown.

[0044] In some embodiments, a monitoring component of the registration risk control system can be installed on the server corresponding to different network services, so that the registration risk control system can directly monitor the attribute information of the registration events accepted by each network service.

[0045] In other embodiments, the network service can monitor the registration events it receives and send the attribute information of the registration events to the registration risk control system.

[0046] It should be noted that each network service typically accepts registration events through several registration sources, which may include registration device sources and / or registration channel sources.

[0047] The source of the registration device can be understood as the type of device on which the user initiates the registration event. Device types generally include mobile devices, PCs, browsers, etc. For example, a network service can be a game that supports mobile game (i.e., the user plays on a mobile device), PC game (i.e., the user plays on a PC), and web game (i.e., the user plays in a web browser). Therefore, the network server can process registration events from the source of the registration device, such as mobile devices, PCs, or browsers.

[0048] Registration channels can be understood as the marketing methods used to drive registrations for an event. Common registration channels include offline advertising, online advertising, friend referrals, competitor apps, etc.

[0049] In the embodiments of this disclosure, the attribute information is defined as including the network service identifier corresponding to the network service that accepts the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event.

[0050] Among them, the event characteristics of a registration event can be understood as some information that the server corresponding to the network service or the registration risk control system can obtain through the network when the network service accepts the registration event. This information can reflect the characteristics of the registration event.

[0051] The event characteristics of some registration events are given exemplarily herein, which does not constitute a limitation on the scope of event characteristics in this disclosure. Event characteristics may include at least one of the following:

[0052] The time of the registration event;

[0053] The account name corresponding to this registration event;

[0054] The password corresponding to this registration event;

[0055] The mobile phone number corresponding to this registration event;

[0056] The IP address that initiated the registration event;

[0057] The region to which the IP address that initiated the registration event belongs;

[0058] One or more operating environment parameters of the operating environment that initiated the registration event.

[0059] It should be noted here that the operating environment corresponding to the registration event can include both software and hardware operating environments. The software operating environment can be, for example, the browser that initiated the registration event; browser operating environment parameters can include cookies, UserAgent, IP address, etc. The hardware operating environment can be, for example, the host device, keyboard device, mouse device, or display device; hardware operating environment parameters can include device information (such as device type, device unique identifier, etc.), mouse operation trajectory information, keyboard operation trajectory information, etc.

[0060] It should also be noted that, generally speaking, different registration events correspond to different account names. Even for a batch of abnormal registration events occurring within a set time period, the account names corresponding to these abnormal registration events are often different. However, the account names corresponding to a batch of abnormal registration events may follow the same naming template. Therefore, in order for the key-value pairs generated by different registration events to contain similarity representations between account names, the event features of the registration events can be extended to determine the account name corresponding to the registration event and the naming template to which the account name belongs; the naming template is then added as an event feature to the event feature set corresponding to the registration event; wherein, the account name and the naming template follow a preset fuzzy matching rule.

[0061] For example, the fuzzy matching rules can be preset as follows:

[0062] For the pinyin contained in the account name, the pinyin is mapped to PN1, where P represents the pinyin contained in the account name and N1 is the number of consecutive syllables in the pinyin.

[0063] For the numeric string contained in the account name, map the numeric string to DN2, where D represents the numeric string contained in the account name and N2 is the number of consecutive digits in the numeric string;

[0064] For non-pinyin English letter strings contained in the account name, the English letter string is mapped to EN3, where E represents the English letter string contained in the account name, and N3 is the number of consecutive English letters in the English letter string.

[0065] For special strings contained in the username, the special strings are mapped to ON4, where O represents the special strings contained in the username and N4 is the number of consecutive special characters in the special strings.

[0066] Suppose an account name is liuzhujie-33sZs, where liuzhujie is the pinyin, containing 3 syllables, so it is mapped to P3; - is a special string containing 1 special character, mapped to O1; 33 is a numeric string containing 2 digits, mapped to D2; and sZs is an English letter string containing 3 English letters, mapped to E3. Therefore, the naming template that account name 1 can be mapped to is P3O1D2E3.

[0067] If another account is named shenyahui*56syh, it can also be mapped to the naming template P3O1D2E3.

[0068] Although the account names corresponding to different abnormal registration events belonging to the same batch are different, these abnormal registration events often have some commonalities. This commonality can be abstracted as the same naming template to which the account names belong. Therefore, taking the naming template to which the account names belong to the registration event also as the event feature of the registration event, and using extraction rules to extract the naming template as the event feature into the key-value pairs generated by the registration event, can help to cluster the key-value pairs generated by registration events with common account names, and thus help to obtain the identification features of the same batch of abnormal registration events that can identify the commonalities of the corresponding account names.

[0069] S102: Based on several extraction rules that match the network service identifier and the registration source identifier, extract several event features corresponding to each extraction rule from the event feature set.

[0070] S104: For each extraction rule, generate a key-value pair corresponding to that extraction rule.

[0071] In embodiments of this disclosure, several extraction rules can be pre-defined. These extraction rules may include several fields, some of which are used to match registered events, and others are used to extract values ​​of event features from the event feature set of the registered events.

[0072] The fields used to match registration events in the extraction rules typically specify the following attribute information of the registration event to be matched: the network service identifier corresponding to the network service that accepts the registration event, and the registration source identifier corresponding to the source of the registration event.

[0073] The field in the extraction rule used to extract event features specifies the feature type identifier to which all or part of the event features to be extracted from the event features of the registered event matching the extraction rule belong.

[0074] Applying extraction rules to registration events generates a key-value pair corresponding to the extraction rule. The key in the key-value pair contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature belongs under the extraction rule. The value in the key-value pair contains the value of each event feature corresponding to the extraction rule.

[0075] In addition, multiple extraction rules can be pre-set. For each registered event, these multiple extraction rules can be applied to that registered event to obtain multiple key-value pairs (one extraction rule corresponds to one key-value pair). In other words, the registered event can generate multiple key-value pairs.

[0076] Table 1 below provides an example extraction rule.

[0077] Network service identifier Registered Source Identifier Feature type identifier pro1 source1 phone pro1 source1 phone, IP pro1 source1 phone number, IP address region

[0078] Table 1

[0079] Assuming that in the attribute information of the registration event, the network service identifier corresponding to the network service that accepted the registration event is pro1, the registration source identifier of the registration event is source1, and in the registration event characteristics of the registration event, the mobile phone number is 136****690, the IP is 115.236.191.0, and the IP region is Beijing, China.

[0080] By applying the three extraction rules in Table 1 above to the registration event, three key-value pairs are obtained, as follows:

[0081] The first key-value pair is: key: pro1-source1-phone; value: 136****690.

[0082] The second key-value pair is: key: pro1-source1-phone-IP; value: 136****690-115.236.191.0.

[0083] The third key-value pair is: key: pro1-source1-phone-IP region; value: 136****690-Beijing, China.

[0084] In some embodiments, an extraction rule may also be set, which may be any of the registration source identifiers corresponding to the same network service.

[0085] See Table 2 below:

[0086] Network service identifier Registered Source Identifier Feature type identifier pro1 source1 phone pro1 source1 phone, IP pro1 source1 phone number, IP address region pro1 ALL time

[0087] Table 2

[0088] As can be seen, Table 2 has an additional fourth extraction rule compared to Table 1. The registration source identifier in the fourth extraction rule is ALL, which means that for the registration event provided by the same network service pro1, the registration source of the registration event can be matched to this extraction rule, which extracts the occurrence time of the registration event from the event feature set of the registration event as the value of the key-value pair.

[0089] In addition, it should be noted that the operating environment parameters for initiating a registration event often include many parameters, some of which are listed below:

[0090] Language, time zone, operating system, plugins, Java support, cookie support, console access, storage path, resolution, canvas, number of fonts, font MD5 hash, CPU model, number of CPU cores, number of mouse and keyboard presses, etc.

[0091] If each operating environment parameter is treated as an independent event feature, the proportion of the same event features in the event feature set of normal registration events and the event feature set of abnormal registration events will be too large. This may lead to the key-value pairs generated by normal registration events and those generated by abnormal registration events being classified into the same category, failing to effectively distinguish between key-value pairs generated by normal registration events and those generated by abnormal registration events, thus reducing the accuracy of the generated identification features.

[0092] Therefore, in some embodiments, instead of treating each operating environment parameter as an event feature, a few operating environment fingerprints can be formed from numerous operating environment parameters, with each operating environment fingerprint serving as an event feature. For example, one or more environment parameters in the operating environment that initiated the registration event can be combined into two operating environment fingerprints, as follows:

[0093] Operating environment fingerprint 1: Based on language, time zone, operating system, plugins, whether Java is supported, whether cookies are supported, whether the console is open, and storage path, the operating environment fingerprint 1 is calculated (such as by hash calculation).

[0094] Operating environment fingerprint 2: The operating environment fingerprint 2 is calculated based on resolution, canvas, number of fonts, font MD5, CPU model, number of CPU cores, and number of mouse and keyboard presses.

[0095] The above only describes how applying one or more extraction rules to a registered event yields one or more key-value pairs. It's easy to understand that this process can be repeated for each registered event to obtain one or more key-value pairs corresponding to that event.

[0096] S106: Based on the similarity between the obtained key-value pairs, key-value pairs with a similarity greater than a set similarity are grouped into the same key-value pair set.

[0097] In the field of registration risk control, a large number of common registration events occurring within a limited time period are more likely to be abnormal registration events. Therefore, in step S100, it is necessary to obtain the registration events that occur within a set time period (i.e., within a limited time period) and cluster the key-value pairs generated by these registration events. If the key-value pairs are not clustered from the registration events that occur in a concentrated period within a limited time period, but are accumulated from registration events that occur over a long period of time without limiting the time period, then even if the number of accumulated key-value pairs is large, they will not meet the criteria for identifying abnormal registration events (i.e., a large number of common registration events that occur in a concentrated period within a limited time period). Doing so is meaningless.

[0098] Furthermore, it should be noted that if clustering is performed over a relatively long, finite time period (such as 1 day or 1 month), even if there are many key-value pairs in the same cluster, the probability that these key-value pairs are generated based on the same batch of anomalous registration events is not very high. Therefore, it is generally advisable to set the duration of the set time period to be relatively short, for example, a duration within the range of 10 to 30 minutes (such as 10 minutes, 20 minutes, or 30 minutes). A large number of common registration events occurring within a short, finite time period are more likely to be anomalous registration events.

[0099] Among the preset extraction rules, some rules are used to extract partial (rather than all) event features from the event feature set of registered events that match the rule. Such extraction rules may produce identical key-value pairs when applied to different registered events, indicating a clear commonality among the different registered events that generate these key-value pairs. The clustering criterion for key-value pairs can be set so that only identical key-value pairs are grouped into the same category; that is, based on the obtained key-value pairs, identical key-value pairs can be grouped into the same key-value pair set.

[0100] Furthermore, the same extraction rule applied to different registration events may yield similar key-value pairs. If the key-value pairs are sufficiently similar, it indicates that the different registration events that generated these key-value pairs share significant commonalities. Therefore, sufficiently similar key-value pairs can be grouped into the same category; that is, key-value pairs grouped into the same category do not necessarily need to be identical. In some embodiments, the similarity between key-value pairs specifically refers to the similarity between the values ​​of different key-value pairs with the same key. In other words, key-value pairs with different keys can be considered dissimilar.

[0101] In some embodiments, in a key-value pair, the order of the feature type identifiers contained in the key can be the same as the order of the event features contained in the value corresponding to each feature type identifier. This makes it easier for the registration risk control system to clearly identify the one-to-one correspondence between the feature type identifiers in the key and the event feature values ​​in the value when reading the key-value pair.

[0102] In some embodiments, key-value pairs with a similarity greater than a set similarity and a quantity exceeding a certain threshold can be grouped into the same key-value pair set. That is, if some key-value pairs are sufficiently similar to each other, but the number of these key-value pairs is too small, there is no need to cluster these key-value pairs into a single key-value pair set.

[0103] S108: Generate identification features for identifying abnormal registration events based on a set of key-value pairs containing more than a first number of key-value pairs.

[0104] The key-value pairs generated by registration events occurring within a set time period are clustered. If the number of key-value pairs belonging to the same category is large enough, it indicates that the registration events that generated these key-value pairs are a sufficiently large group of registration events with sufficient commonalities, and these registration events are likely to be anomalous registration events. Therefore, identification features for identifying anomalous registration events can be generated based on these key-value pairs.

[0105] In some embodiments, for a sufficient number of key-value pairs belonging to the same category, the network service identifier, registration source identifier, and event characteristics (the event characteristic type identifier and the value of the event characteristic) contained in these key-value pairs can be combined to form an identification feature for identifying abnormal registration events. The registration risk control system can identify the attribute information of subsequently acquired registration events based on this identification feature. If the attribute information of a registration event contains the identification feature, it is determined that the registration event matches the identification feature, and the registration event belongs to the category of abnormal registration events.

[0106] In some embodiments, a set of key-value pairs containing more than a first number of key-value pairs can be provided to the administrator for review, so that the administrator can decide whether to generate identification features for identifying abnormal registration events based on the set of key-value pairs. Identification features for identifying abnormal registration events can be automatically generated based on a set of key-value pairs containing more than a second number of key-value pairs; wherein the second number is greater than the first number.

[0107] In other words, if the number of key-value pairs belonging to the same category is greater than the first threshold but less than the second threshold (where the second threshold is greater than the first threshold), it indicates that the number of key-value pairs belonging to the same category is relatively large. Therefore, the corresponding set of key-value pairs can be identified as potentially abnormal and provided to the administrator for manual judgment. If the administrator believes that the multiple registration events corresponding to this set of key-value pairs meet the criteria of "a large number of registration events occurring within a limited time period and sharing common characteristics," then identification features for identifying abnormal registration events can be manually generated based on this set of key-value pairs. If the number of key-value pairs belonging to the same category is greater than the second threshold, it indicates that the number of key-value pairs belonging to the same category is very large. Therefore, manual judgment is not required; the corresponding set of key-value pairs can be directly identified as confirmed abnormal, and identification features for identifying abnormal registration events can be automatically generated based on the confirmed abnormal set of key-value pairs. See also... Figure 2 , Figure 2 An exemplary process for generating recognition features is provided, including the following steps:

[0108] S201: Filter registration events that are confirmed as normal or abnormal from the registration event stream that occurs within a set time period, and retain registration events identified as unknown or suspected.

[0109] S202: Determine one or more extraction rules that match each registered event to be retained.

[0110] S203: Apply each matching extraction rule to the registered event to obtain the key-value pair corresponding to each extraction rule.

[0111] S204: Group key-value pairs with a similarity greater than a set similarity into the same key-value pair set, and accumulate the number of key-value pairs in each key-value pair set.

[0112] S205: Output the set of key-value pairs with a number greater than the first number and less than the second number to the administrator, who will then determine whether to generate a recognition feature.

[0113] S206: Output the set of key-value pairs with a number greater than the second number, and directly generate recognition features.

[0114] S207: Apply the generated identification features to the registration risk control.

[0115] It should be noted that the registration events mentioned above may refer to the first type of registration events, which are registration events that are in progress and not yet completed. For ease of description, the set time period in which the first type of registration events occur is referred to as the first type set time period. Since the first type of registration events occur in real time, execution is performed within the first type set time period. Figure 1 The method described involves acquiring multiple first-type registration events occurring in real time within a set time period, generating key-value pairs, and clustering them. If a set of key-value pairs contains a large number of key-value pairs, it indicates that the set of first-type registration events that generated each key-value pair in that set represents a large number of first-type registration events occurring within the set time period and sharing common characteristics. This likely belongs to a batch of abnormal registration events occurring in real time within the set time period. Therefore, the identification features obtained based on this set of key-value pairs can be promptly configured for the registration risk control system. This allows the registration risk control system to respond to the end of the first-type set time period and perform risk control based on these identification features, thereby promptly identifying other abnormal registration events that belong to the same batch as the aforementioned abnormal registration events and occur subsequently.

[0116] Correspondingly, identification features generated based on several Type I registration events occurring within a set time period can be used to monitor more Type I registration events occurring after the end of the set time period, thereby identifying abnormal registration events. An interception mechanism for the abnormal registration event can then be triggered, causing the registration of the abnormal event to fail. For example, the interception mechanism for the abnormal registration event can be triggered by notifying the network service provider handling the abnormal registration event to intercept the registration.

[0117] Furthermore, in some embodiments, event attribute information of a second type of registration event occurring within a set time period can be obtained; the second type of registration event is a registration event that has already been registered. For ease of description, the set time period in which the second type of registration event occurs is referred to as the second type set time period. Since the second type of registration event is a registration event that has already been registered, this means that the second type time period in which the second type of registration event occurs is related to the execution... Figure 1 The time periods in the illustrated method flow are not the same time period, which is a significant difference between the embodiment that generates identification features based on the second type of registration event and the embodiment that generates identification features based on the first type of registration event.

[0118] In other words, in execution Figure 1 The method shown is meaningful for clustering multiple first-type registration events occurring within the current finite time period, allowing for real-time generation of identification features; however, during the execution of... Figure 1 The method shown is meaningful for clustering key-value pairs generated by multiple second-type registration events within a historical finite time period that occurred before the current finite event period. This allows for delayed generation of identification features, and remedial risk control can be performed on some second-type registration events that have historically passed the first risk control (but actually have risks) and generated accounts based on the generated identification features.

[0119] Correspondingly, identification features (i.e., identification features generated based on several Type II registration events that have occurred within the second-defined time period) can be used to monitor Type II registration events that have occurred outside the second-defined time period to identify abnormal registration events. This triggers an account freezing mechanism for the abnormal registration event, making the account successfully registered by that abnormal registration event temporarily unusable. For example, triggering the account freezing mechanism for the abnormal registration event could involve notifying the network service provider handling the abnormal registration event to freeze the account.

[0120] Alternatively, in response to the detected registration event being classified as a second type of registration event, a risk label for the second type of registration event can be determined based on the current identification features used to identify anomalous registration events. The determined risk label is then added as an event feature to the event feature set corresponding to the second type of registration event. The risk label characterizes the risk that the second type of registration event belongs to an anomalous registration event. The risk label may include several risk levels, such as good, unknown, suspected, and dangerous.

[0121] It should be noted here that, considering that the event feature set of a registered event may contain a risk label assigned to the registered event by the registration risk control system, which can be regarded as a special event feature, when setting the extraction rules in advance, the field used to extract event features in some extraction rules can be set to contain a special feature type identifier, which means that the risk label assigned to the registered event by the registration risk control system needs to be extracted from the event feature set.

[0122] Here is a specific example. See Table 3 below:

[0123] Network service identifier Registered Source Identifier Feature type identifier pro1 source1 phone, X pro1 source1 phone, IP pro1 source1 phone number, IP address region

[0124] Table 3

[0125] The preset extraction rules can include an extraction rule that can extract risk tags from the event feature set of the registered event, such as the first rule in Table 3. The feature type identifier field of this extraction rule contains a special feature type identifier, namely X, which means that risk tags need to be extracted from the event feature set of the registered event and written into the value of the key-value pair generated by the extraction rule.

[0126] Assuming the registration event's attribute information includes the network service identifier "pro1" corresponding to the network service accepting the registration event, the registration source identifier "source1," and the registration event characteristics such as the phone number "136****690," the IP address "115.236.191.0," and the IP region "Beijing, China," the registration risk control system can, based on existing identification features used to identify abnormal registration events, provide an identification result (one of "good," "unknown," "suspected," or "dangerous") for the registration event, serving as a risk label (e.g., "suspected").

[0127] Applying the first extraction rule in Table 3 to this registration event yields the following key-value pair: Key: pro1-source1-phone-X; Value: 136****690-Suspected.

[0128] Figure 3This document provides an exemplary flow for a registration risk control system to process registration event streams. A registration event stream can be understood as a batch of registration events occurring consecutively within a defined time period. In some embodiments, the defined time period can be a specific time period during which the registration risk control system is currently operating (referred to as a first-type defined time period), and the registration event stream can be a batch of registration events occurring within the first-type defined time period, i.e., a real-time first-type registration event stream. In other embodiments, the defined time period can be a specific time period in the history of the registration risk control system (referred to as a second-type defined time period), and the registration event stream can be a batch of registration events that have historically occurred within the second-type defined time period, i.e., a previously occurring second-type registration time stream.

[0129] The registration risk control system may include a clustering module 301, an automatic identification feature generation module 302, a manual identification feature generation module 303, and a risk control execution module 304. After the registration event stream enters the registration risk control system, it enters the clustering module to generate identification features, and the risk control execution module to identify abnormal registration events. As can be easily understood, at this time, the risk control execution module identifies abnormal registration events from the registration event stream based on the existing set of identification features.

[0130] The clustering module applies several preset extraction rules to each registered event in the registered event stream, resulting in several key-value pairs. Then, the clustering module performs clustering statistics on the key-value pairs generated by each registered event occurring within a set time period. Key-value pairs with a similarity greater than a set similarity are grouped into the same key-value pair set. Furthermore, key-value pair sets containing more than a first set of key-value pairs are pushed to the manually generated recognition feature module, while key-value pair sets containing more than a second set of key-value pairs (greater than the first set) are pushed to the automatically generated recognition feature module.

[0131] The manual feature generation module displays the received set of key-value pairs to the administrator for manual judgment. The administrator can choose whether to generate a feature based on this set of key-value pairs. If the administrator generates a feature based on this set of key-value pairs, the manual feature generation module pushes the feature to the risk control execution module, which is equivalent to configuring the feature to the risk control execution module. The automatic feature generation module directly generates a feature based on the received set of key-value pairs and pushes it to the risk control execution module, which is equivalent to configuring the feature to the risk control execution module.

[0132] The risk control execution module can identify abnormal registration events in the registration event stream received after the configured identification feature time point (after the identification feature set is updated).

[0133] In addition, see also Figure 2In some embodiments, the risk control execution module's identification results for registration events can include four levels: good, unknown, suspected, and dangerous. Before the registration event stream enters the clustering module, the risk control execution module of the registration risk control system can first identify the registration event stream, filter registration events with identification results of good or dangerous, and retain only registration events with identification results of unknown or suspected. The filtered registration event stream is then input into the clustering module for processing.

[0134] In this way, for registration events that have been identified as abnormal (i.e., dangerous) or normal (i.e., good), key-value pair extraction and key-value pair clustering statistics are not required; that is, they are not used as the basis for generating identification features. The reason is that since the risk control execution module can identify some registration events as normal or abnormal based on the existing set of identification features, it means that the existing set of identification features is already capable of accurately identifying these registration events. However, since the risk control execution module identifies other registration events as unknown or suspected based on the existing set of identification features, it means that the existing set of identification features lacks the ability to accurately identify other registration events. Therefore, new identification features need to be generated to supplement the identification feature set of the risk control execution module to improve its identification capabilities.

[0135] In some embodiments, the generated identification features for identifying anomalous registration events may have an expiration period. The expiration period may be extended if, within this period, the number of anomalous registration events identified based on the identification features exceeds a third number. That is, for anomalous registration events occurring within a certain time period, if one or more identification features perform well (i.e., accurately identify a large number of anomalous registration events within that time period), it indicates that the corresponding identification features correspond well to that batch of anomalous registration events. Considering that this batch of anomalous registration events may continue to emerge for some time afterward, the expiration period of the identification features can be extended to continue addressing other anomalous registration events similar to this batch. This allows for dynamic configuration of the expiration period of the identification features based on their identification performance, maximizing their effectiveness.

[0136] Furthermore, this disclosure provides a specific implementation method for grouping key-value pairs with a similarity greater than a set similarity into the same key-value pair set.

[0137] First, identical key-value pairs (those with infinite similarity) can be grouped into the same key-value pair set. Then, key-value pairs that satisfy similarity criteria are identified. These criteria include: the keys are identical, and the event features belonging to at least one feature type identifier in their values ​​are different. Next, the similarity of each pair of key-value pairs is calculated. This involves identifying the different event features belonging to the same feature type identifier in the values ​​of the two key-value pairs, calculating the similarity for these different event features, calculating the average similarity based on the similarity values ​​corresponding to several feature type identifiers, and using this average similarity as the similarity between the two key-value pairs. Finally, key-value pairs with similarity scores greater than the set similarity score are grouped into the same key-value pair set.

[0138] When the same user or organization initiates a batch of abnormal registration events, the event characteristics such as the phone number, password, UserAgent, and cookies used in different registration events often differ significantly (this is a deliberate tactic employed by the user or organization to circumvent registration risk controls). However, the account names used in different registration events often exhibit certain similarities. Furthermore, the geographical location of the user or organization is often limited to a specific area; therefore, the IP addresses used in different registration events tend to be quite similar.

[0139] In some embodiments, the step of calculating the similarity between different event features belonging to the same feature type identifier contained in the values ​​of these two key-value pairs may include: if the same feature type identifier is an account name type identifier, then calculating the similarity between different account names contained in the two key-value pairs. For example, the similarity between different account names can be calculated by comparing the edit distance of different account names.

[0140] Furthermore, a regular expression can be determined to match similar account names based on the similar account names contained in different key-value pairs within the same set of key-value pairs. For example, the regular expression matching the similar account names syh1, syh2, and syh3 is syh\d.

[0141] If the number of key-value pairs in the same key-value pair set is greater than the first quantity, then the common event characteristics contained in each key-value pair in the key-value pair set, together with the regular expression, form an identification feature for identifying abnormal registration events. In other words, when identifying registration events based on this identification feature, it is necessary to determine whether the account name corresponding to the registration event matches the regular expression. If they do not match, it can be determined that the registration event has not matched the identification feature.

[0142] In some embodiments, the step of calculating the similarity of different event features belonging to the same feature type identifier may include: if the same feature type identifier is an IP address type identifier, then calculating the similarity between the different IP addresses contained in the two key-value pairs. For example, the similarity between different IP addresses can be determined by comparing the Geohash encodings of different IP addresses.

[0143] Furthermore, a common Geohash encoding prefix for these similar IP addresses can be determined based on the similar IP addresses contained in different key-value pairs within the same key-value pair set. If the number of key-value pairs in the same key-value pair set is greater than a first number, then the common event features contained in each key-value pair in the key-value pair set, together with the common Geohash encoding prefix, form an identification feature for identifying abnormal registration events.

[0144] In addition, the registration risk control system can also obtain abnormal tags from an auxiliary risk control system that is independent of the registration risk control system, to assist the registration risk control system in identifying abnormal registration events, or to assist the registration risk control system in generating identification features for identifying abnormal registration events.

[0145] The aforementioned anomaly labels are used to mark the event characteristics of abnormal registration events identified by the auxiliary risk control system. Since the auxiliary risk control system is independent of the registration risk control system, it may possess some risk control capabilities that the registration risk control system does not have. This means that some event characteristics that the registration risk control system considers normal registration events may be considered abnormal registration events by the auxiliary risk control system.

[0146] If the event feature set of the registration event detected by the registration risk control system includes the event feature marked by the abnormal label, the abnormal label can be added to the event feature set as an event feature; or, identification features for identifying abnormal registration events can be generated based on the abnormal label.

[0147] After adding the abnormal tag as an event feature to the event feature set, the registration risk control system can review the attribute information of events that have been identified as normal registration events by the registration risk control system based on the updated event feature set.

[0148] Furthermore, if the registration event corresponding to the updated event feature set was previously identified as a normal registration event by the registration risk control system, then the extraction rules are reapplied to that registration event, and the key-value pairs corresponding to that registration event are regenerated. Afterwards, the key-value pairs are re-clustered to regenerate the identification features.

[0149] It should be noted here that, considering that the event feature set of the registered event may contain abnormal tags sent by the auxiliary risk control system to the registered risk control system, the abnormal tag can be used to mark whether a specific event feature belongs to the event feature of an abnormal event. The abnormal tag itself can also be regarded as a special event feature. Therefore, when setting the extraction rules in advance, some extraction rules can be set to include a special feature type identifier in the field used to extract event features, which means that abnormal tags need to be extracted from the event feature set.

[0150] Here is a specific example. See Table 4 below:

[0151] Network service identifier Registered Source Identifier Feature type identifier pro1 source1 phone, Y pro1 source1 phone, IP, Y pro1 source1 phone number, IP address region

[0152] Table 4

[0153] The preset extraction rules can include an extraction rule that can extract anomaly tags from the event feature set of the registered event, such as the first and second rules in Table 4. The feature type identifier field of this extraction rule contains a special feature type identifier, namely Y, which means that anomaly tags need to be extracted from the event feature set of the registered event and written into the value of the key-value pair generated by the extraction rule.

[0154] Assuming the registration event's attribute information includes the network service identifier "pro1" corresponding to the network service accepting the registration event, the registration source identifier "source1," and the registration event characteristics such as the phone number "136****690," the IP address "115.236.191.0," and the IP region "Beijing, China," the auxiliary risk control system identifies the phone number "136****690" as belonging to a black market user. Therefore, the auxiliary risk control system can generate an anomaly tag indicating that the phone number is abnormal, which can be denoted as "Abnormal Phone Number." This anomaly tag is sent to the registration risk control system, which then adds it to the registration event characteristic set of registration events containing this phone number (such as the registration event described above).

[0155] Applying the first extraction rule in Table 4 to this registration event yields the following key-value pair: Key: pro1-source1-phone-Y; Value: 136****690-phone number abnormal. Applying the second extraction rule in Table 4 to this registration event yields the following key-value pair: Key: pro1-source1-phone-IP-Y; Value: 136****690-115.236.191.0-phone number abnormal.

[0156] This section introduces several ways to obtain anomaly tags for auxiliary risk control systems.

[0157] In some embodiments, the registration risk control system can send the attribute information of the monitored registration events to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps:

[0158] The event characteristics of one or more of the registered events are displayed to the risk control personnel, so that the risk control personnel can customize several abnormal labels and input them into the auxiliary risk control system.

[0159] In some embodiments, the registration risk control system can send the attribute information of the monitored registration events to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps:

[0160] Send one or more event features of the registered event to the black market information marking platform; receive the marking results from the black market information marking platform regarding whether the one or more event features belong to black market information; send the marking results indicating that they belong to black market information as an anomaly label to the registration risk control system.

[0161] In some embodiments, the registration risk control system can send the attribute information of the monitored registration events to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps:

[0162] Based on the attribute information of different registration events, the number of different registration events matching the same abnormal tag is counted. Among them, the registration events matching the abnormal tag have event characteristics corresponding to the abnormal tag. Abnormal tags with a corresponding statistical number greater than the fourth number are sent to the registration risk control system.

[0163] In other words, in this embodiment, the auxiliary risk control system can directly count the number of registration events matching the same abnormal label across different registration events. In contrast, registration risk control systems typically do not have the function of directly counting across different registration events. Instead, they usually extract several key-value pairs for each registration event, then cluster these key-value pairs, generating identification features based on a sufficiently large number of similar key-value pairs.

[0164] In some embodiments, the registration risk control system can send the attribute information of the monitored registration events to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps:

[0165] One or more event features of the registration event are selected and sent to several network service providers so that each network service provider can mark whether the event feature belongs to an abnormal event feature based on the operation of the network service; the marking results returned by each network service provider are obtained, and the marking results that indicate that they belong to an abnormal event feature are sent as anomaly labels to the registration risk control system.

[0166] In other words, in this embodiment, the network service provider can use the characteristics of abnormal accounts discovered during its operation as abnormal event characteristics, and provide the marking of the abnormal event characteristics as an abnormal label to the auxiliary risk control system, which in turn provides the abnormal label to the registration risk control system.

[0167] Furthermore, each network service provider can inspect the behavioral data of accounts corresponding to normal registration events identified by the registration risk control system. These normal registration events are those processed by the network service. If abnormal account behavior is detected, the normal registration event is determined to be an abnormal registration event (i.e., a missed detection occurred), and the attribute information of the abnormal registration event is fed back to the auxiliary risk control system. Thus, the steps executed by the auxiliary risk control system also include:

[0168] For each network service, the attribute information of the abnormal registration event reported by the provider of that network service is further fed back to the providers of other network services for reference;

[0169] and / or

[0170] For each network service, the attribute information of the abnormal registration event reported by the network service provider is fed back to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

[0171] It should be noted that network service providers only monitor account behavior data after obtaining authorization from the user associated with the account.

[0172] Furthermore, each network service provider can detect the behavioral data of the account corresponding to the abnormal registration event identified by the registration risk control system. The abnormal registration event is handled by the corresponding network service provider. If it is determined that the detected account behavior is normal, then the abnormal registration event is actually a normal registration event (in which case a misjudgment has occurred), and the attribute information of the normal registration event is fed back to the auxiliary risk control system.

[0173] The steps performed by the auxiliary risk control system also include:

[0174] For each network service, the attribute information of the normal registration event reported by the provider of that network service is forwarded to the providers of other network services;

[0175] and / or

[0176] For each network service, the attribute information of normal registration events reported by the provider of that network service is forwarded to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

[0177] Here is a specific example.

[0178] Suppose that in the attribute information of a certain registration event, the network service identifier corresponding to the network service that accepts the registration event is pro1, the registration source identifier of the registration event is source1, and the registration event feature set of the registration event includes the following registration event features:

[0179] The mobile phone number is 136****690;

[0180] The IP address is 115.236.191.0;

[0181] The IP address is located in Beijing, China.

[0182] The account name is shenyahui*56syh;

[0183] Several operating environment parameters are as follows: language (Chinese), time zone (UTC+8), cookie, resolution (1080P), CPU model (i5-4800u), and number of CPU cores (8 cores).

[0184] Some event characteristics of this registration event can be further transformed. For example, the username shenyahui*56syh can be transformed into its corresponding naming template P3O1D2E3 (see the previous explanation for the transformation method). Meanwhile, the original username is still retained as an event characteristic. Similarly, several operating environment operations can be transformed into two operating environment fingerprints: calculating the hash values ​​of language (Chinese), time zone (UTC+8), and cookie to obtain operating environment fingerprint 1 (assuming the hash value of operating environment fingerprint 1 is abcf); and calculating the hash values ​​of resolution (1080P), CPU model (i5-4800u), and number of CPU cores (8 cores) to obtain operating environment fingerprint 2 (assuming the hash value of operating environment fingerprint 2 is cdee). At the same time, the original operating environment parameters are no longer retained as event characteristics.

[0185] Therefore, the event feature set of the registered event is updated to include the following event features:

[0186] The mobile phone number is 136****690;

[0187] The IP address is 115.236.191.0;

[0188] The IP address is located in Beijing, China.

[0189] The account name is shenyahui*56syh;

[0190] The naming template is P3O1D2E3;

[0191] Operating environment fingerprint 1;

[0192] Operating environment fingerprint 2.

[0193] Furthermore, event features can be added to the event feature set to update the set. The identification result of the registration event by the registration risk control system based on existing identification features can be used as a risk label and added to the event feature set. For example, the risk label could be "suspected."

[0194] You can also add the anomaly tags provided by the auxiliary risk control system to the registration risk control system to the event feature set. For example, the anomaly tag could be "abnormal mobile phone number".

[0195] Assume the preset extraction rules are as shown in Table 5 below:

[0196]

[0197] Table 5

[0198] X represents a risk label, and Y represents an anomaly label.

[0199] Since the three extraction rules shown in Table 5 all contain pro1-source1, they match the registration event mentioned above. Therefore, these three extraction rules can be applied to the registration event to obtain the following three key-value pairs:

[0200] Key-value pair 1, key: pro1-source1-phone-operating environment fingerprint1-account name-X; value: 136****690-abcf-shenyahui*56syh-suspected;

[0201] Key-value pair 2, key: pro1-source1-phone-IP-naming template-Y; value: 136****690-115.236.191.0-P3O1D2E3-phone number error;

[0202] Key-value pair 3, Key: pro1-source1-phone-operating environment fingerprint2-account name-IP-IP region; Value: 136****690-cdee-shenyahui*56syh-115.236.191.0-Beijing, China.

[0203] Based on the example above, the following details how to compare the similarity between two key-value pairs.

[0204] Assuming there are 4 key-value pairs, the key is: pro1-source1-phone-operating environment fingerprint1-account name-X; the value is: 136****690-abcf-shenyahui*66syh-suspected.

[0205] It can be observed that the main difference between key-value pair 1 and key-value pair 4 lies in the usernames. The edit distance between these two usernames can be calculated as their similarity. Assuming that the usernames contained in key-value pair 1 and key-value pair 4 are sufficiently similar, then key-value pair 1 and key-value pair 4 can be grouped into the same key-value pair set. Furthermore, the commonalities between these two different usernames can be abstracted into a regular expression. If subsequent identification features need to be generated based on key-value pair 1 and key-value pair 4, this regular expression can be used to replace the specific usernames in key-value pair 1 and key-value pair 4.

[0206] Assuming there are 5 key-value pairs, the key is: pro1-source1-phone-IP-naming template-Y; the value is: 136****690-115.236.191.1-P3O1D2E3-phone number error.

[0207] It can be observed that the main difference between key-value pair 2 and key-value pair 5 lies in their IP addresses. Therefore, both IP addresses can be converted into Geohash codes, and then the two Geohash codes can be compared. The more common encoding prefixes, the higher the similarity between the two Geohash codes. This allows us to obtain the similarity between the two IP addresses, which can then be used as the similarity score for key-value pair 2 and key-value pair 5. Assuming the two IP addresses are sufficiently similar, key-value pair 2 and key-value pair 5 can be grouped into the same key-value pair set. Furthermore, the common encoding prefixes of these two IP addresses can be extracted. If subsequent identification features need to be generated based on key-value pair 2 and key-value pair 5, these common encoding prefixes can be used instead of the specific IP addresses.

[0208] Assuming there are 6 key-value pairs, the key is: pro1-source1-phone-operating environment fingerprint2-account name-IP-IP region; the value is: 136****690-cdee-shenyahui*66syh-115.236.191.1-Beijing, China.

[0209] It can be observed that the main differences between key-value pair 3 and key-value pair 6 are the usernames and IP addresses. Therefore, we can calculate the similarity for the two IP addresses and the two usernames separately, and then calculate the average of the IP address similarity and username similarity as the similarity between the two key-value pairs. Assuming that the two key-value pairs are sufficiently similar, then key-value pair 3 and key-value pair 6 can be grouped into the same key-value pair set.

[0210] This section provides a detailed explanation of how to generate identification features based on key-value pairs from a set of key-value pairs.

[0211] Assuming the limit is set to 3, meaning the key-value pair set contains more than 3 key-value pairs, this set can be output to generate recognition features. A key-value pair might contain 4 key-value pairs, as shown below:

[0212] Key: pro1-source1-phone-operating environment fingerprint1-account name-IP-X; Value: 136****690-abcf-syh1-115.236.191.1-suspected;

[0213] Key: pro1-source1-phone-operating environment fingerprint1-account name-IP-X; Value: 136****690-abcf-syh2-115.236.191.1-suspected;

[0214] Key: pro1-source1-phone-operating environment fingerprint1-account name-IP-X; Value: 136****690-abcf-syh3-115.236.191.1-suspected;

[0215] Key: pro1-source1-phone-operating environment fingerprint1-account name-IP-X; Value: 136****690-abcf-syh4-115.236.191.1-suspected;

[0216] Therefore, when generating identification features based on this set of key-value pairs, these key-value pairs are merged, that is, identical keys are retained, identical values ​​are retained, and different but similar values ​​are replaced with common representations (such as common encoding prefixes of IP addresses, regular expressions for account names). The resulting identification feature can still be a key-value pair, including:

[0217] Key: pro1-source1-phone-operating environment fingerprint1-account name-IP-X; Value: 136****690-abcf-syh\d-common encoding prefix-suspected.

[0218] When the registration risk control system uses the aforementioned identification features to identify registration events, it first determines whether the registration event to be identified corresponds to pro1 and source1. If they correspond, it further extracts event features of types such as phone, operating environment fingerprint 1, account name, IP, and X from the event feature set of the registration event. Then, it determines whether these features match the values ​​contained in the identification features. If they match completely, the registration event is identified as an abnormal registration event. If they do not match completely, the registration event is identified as unknown, suspected, or good based on the degree of overlap between the event features corresponding to the registration event and the event features contained in the identification features. The higher the degree of overlap, the more likely the registration event is to be an abnormal registration event.

[0219] Figure 4 An exemplary embodiment provides the structure of a device for generating identification features of abnormal registration events, comprising:

[0220] The acquisition module 401 acquires the attribute information of the monitored registration event. The attribute information includes: the network service identifier corresponding to the network service that accepts the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event.

[0221] The extraction module 402 extracts several event features corresponding to each extraction rule from the event feature set based on several extraction rules that match the network service identifier and the registration source identifier.

[0222] The first generation module 403 generates a key-value pair corresponding to each extraction rule; wherein, the key in the key-value pair includes the network service identifier, the registration source identifier, and the feature type identifier to which each event feature corresponding to the extraction rule belongs, and the value in the key-value pair includes the value of each event feature corresponding to the extraction rule;

[0223] The second generation module 404, based on the similarity between each key-value pair obtained within a set time period, groups key-value pairs with a similarity greater than a set similarity into the same key-value pair set, and generates identification features for identifying abnormal registration events based on the number of key-value pairs included in the key-value pair set exceeding a first number.

[0224] In some embodiments, the acquisition module 401 acquires event attribute information of a first type of registration event monitored within a first set time period; the first type of registration event is a registration event that is in the process of registration and has not yet been completed.

[0225] In some embodiments, it also includes:

[0226] The identification module 405 monitors the first type of registration events that occur after a set time period based on the generated identification features for identifying abnormal registration events, so as to identify the abnormal registration events; and triggers an interception mechanism for the abnormal registration events.

[0227] In some embodiments, the acquisition module 401 acquires event attribute information of a second type of registration event that occurs within a second set time period; the second type of registration event is a registration event that has been registered.

[0228] In some embodiments, it also includes:

[0229] The identification module 405 monitors second-type registration events that occur outside the second-type set time period based on the generated identification features used to identify abnormal registration events, so as to identify abnormal registration events among them; and triggers an account freezing mechanism for the abnormal registration event.

[0230] In some embodiments, the apparatus further includes:

[0231] In response to the detected registration event being the second type of registration event, the feature addition module 406 determines the risk label of the second type of registration event based on the current identification features used to identify abnormal registration events, and adds the determined risk label as an event feature to the event feature set corresponding to the second type of registration event; wherein, the risk label is used to characterize the risk that the second type of registration event belongs to the abnormal registration event.

[0232] In some embodiments, the event feature set of the registration event includes at least one of the following event features:

[0233] The time of the registration event;

[0234] The account name corresponding to this registration event;

[0235] The password corresponding to this registration event;

[0236] The mobile phone number corresponding to this registration event;

[0237] The IP address that initiated the registration event;

[0238] The region to which the IP address that initiated the registration event belongs;

[0239] One or more operating environment parameters of the browser that initiated the registration event.

[0240] In some embodiments, the feature addition module 406 determines the account name corresponding to the registration event and the naming template to which the account name belongs; adds the naming template as an event feature to the event feature set corresponding to the registration event; wherein the account name and the naming template follow a preset fuzzy matching rule.

[0241] In some embodiments, the feature addition module 406 determines at least one browser fingerprint based on one or more operating environment parameters of the browser that initiated the registration event, and adds each browser fingerprint as an event feature to the event feature set of the registration event.

[0242] In some embodiments, in a key-value pair, the order of the feature type identifiers contained in the key is the same as the order of the event features contained in the value corresponding to the respective feature type identifiers.

[0243] In some embodiments, the second generation module 404 groups identical key-value pairs into the same key-value pair set based on the obtained key-value pairs.

[0244] In some embodiments, the second generation module 404 groups identical key-value pairs among the obtained key-value pairs into the same key-value pair set; determines key-value pairs that satisfy similarity conditions; wherein, two key-value pairs satisfying similarity conditions include: the two key-value pairs have the same key, and the event features belonging to at least one feature type identifier contained in the values ​​are different; for key-value pairs that satisfy similarity conditions, calculate the similarity between each pair, including: determining the different event features belonging to the same feature type identifier contained in the values ​​of the two key-value pairs, calculating the similarity between the different event features belonging to the same feature type identifier, calculating the average similarity based on the similarity corresponding to several feature type identifiers respectively, and using the average similarity as the similarity between the two key-value pairs; and grouping key-value pairs with similarity greater than a set similarity into the same key-value pair set.

[0245] In some embodiments, if the same feature type identifier is an account name type identifier, the second generation module 404 calculates the similarity between the different account names contained in the two key-value pairs.

[0246] In some embodiments, the second generation module 404 determines a regular expression for matching similar account names based on the similar account names contained in different key-value pairs in the same key-value pair set; if the number of key-value pairs in the same key-value pair set is greater than a first number, then the same event features contained in each key-value pair in the key-value pair set and the regular expression are combined to form an identification feature for identifying abnormal registration events.

[0247] In some embodiments, if the same feature type identifier is an IP address type identifier, the second generation module 404 calculates the similarity between the different IP addresses contained in the two key-value pairs.

[0248] In some embodiments, the second generation module 404 determines the common Geohash encoding prefix of similar IP addresses based on the similar IP addresses contained in different key-value pairs in the same key-value pair set; if the number of key-value pairs in the same key-value pair set is greater than a first number, then the common event features contained in each key-value pair in the key-value pair set and the common Geohash encoding prefix are combined to form identification features for identifying abnormal registration events.

[0249] In some embodiments, the second generation module 404 provides a set of key-value pairs containing more than a first number of key-value pairs to the administrator for review, so that the administrator can decide whether to generate identification features for identifying abnormal registration events based on the set of key-value pairs; and automatically generates identification features for identifying abnormal registration events based on a set of key-value pairs containing more than a second number of key-value pairs; wherein the second number is greater than the first number.

[0250] In some embodiments, the generated identification features for identifying abnormal registration events have an expiration period, and the apparatus further includes:

[0251] The validity period extension module 407 extends the validity period if, within the validity period, the number of abnormal registration events identified based on the identification features is greater than a third number.

[0252] In some embodiments, the apparatus, used in a registration risk control system, further includes:

[0253] The interaction module 408 obtains anomaly tags provided by the auxiliary risk control system, wherein the auxiliary risk control system is independent of the registration risk control system, and the anomaly tags are used to mark the event features of abnormal registration events identified by the auxiliary risk control system; if the event feature set of the monitored registration events includes the event feature marked by the anomaly tag, then the anomaly tag is added to the event feature set as an event feature; or, identification features for identifying abnormal registration events are generated based on the anomaly tag.

[0254] In some embodiments, the interaction module 408 sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps:

[0255] The event characteristics of one or more of the registered events are displayed to the risk control personnel, so that the risk control personnel can customize several abnormal labels and input them into the auxiliary risk control system.

[0256] In some embodiments, the interaction module 408 sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps:

[0257] Send one or more event characteristics of the registered event to the black market information tagging platform;

[0258] Receive the black market information labeling platform's labeling results regarding whether one or more event characteristics belong to black market information;

[0259] The labeling results representing black market information are sent as anomaly tags to the registration risk control system.

[0260] In some embodiments, the interaction module 408 sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps:

[0261] Based on the attribute information of different registered events, the number of different registered events matching the same anomaly label is counted. Among them, the registered events matching the anomaly label have event characteristics corresponding to the anomaly label.

[0262] The abnormal tags whose corresponding statistical count is greater than the fourth number are sent to the registration risk control system.

[0263] In some embodiments, the interaction module 408 sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps:

[0264] Select one or more event features of the registered event and send them to several network service providers so that each network service provider can mark whether the event feature is an abnormal event feature based on the operation of the network service;

[0265] Obtain the labeling results returned by the provider of each network service, and send the labeling results that represent the characteristics of abnormal events as abnormal tags to the registration risk control system.

[0266] In some embodiments, each network service provider detects the behavioral data of the account corresponding to the normal registration event identified by the registration risk control system. The normal registration event is the registration event accepted by the network service. If it is determined that the detected account behavior is abnormal, the normal registration event is actually an abnormal registration event, and the attribute information of the abnormal registration event is fed back to the auxiliary risk control system.

[0267] The steps performed by the auxiliary risk control system also include:

[0268] For each network service, the attribute information of the abnormal registration event reported by the provider of that network service is further fed back to the providers of other network services for reference;

[0269] and / or

[0270] For each network service, the attribute information of the abnormal registration event reported by the network service provider is fed back to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

[0271] In some embodiments, each network service provider detects the behavioral data of the account corresponding to the abnormal registration event identified by the registration risk control system. The abnormal registration event is handled by the corresponding network service provider. If it is determined that the detected account behavior is normal, the abnormal registration event is actually a normal registration event, and the attribute information of the normal registration event is fed back to the auxiliary risk control system.

[0272] The steps performed by the auxiliary risk control system also include:

[0273] For each network service, the attribute information of the normal registration event reported by the provider of that network service is forwarded to the providers of other network services;

[0274] and / or

[0275] For each network service, the attribute information of normal registration events reported by the provider of that network service is forwarded to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

[0276] In some embodiments, it also includes:

[0277] The review module 409, after adding the abnormal label as an event feature to the event feature set, reviews the attribute information of the registration risk control system as a normal registration event based on the updated event feature set.

[0278] Figure 5 This is a schematic diagram of a computer-readable storage medium 140 provided in this disclosure, on which a computer program is stored, which, when executed by a processor, implements the method of any embodiment of this disclosure.

[0279] This disclosure also provides a computing device, including a memory and a processor; the memory is used to store computer instructions that can be executed on the processor, and the processor is used to implement the methods of any embodiment of this disclosure when executing the computer instructions.

[0280] Figure 6This is a schematic diagram of the structure of a computing device provided in this disclosure. The computing device 15 may include, but is not limited to, a processor 151, a memory 152, and a bus 153 connecting different system components (including the memory 152 and the processor 151).

[0281] The memory 152 stores computer instructions that can be executed by the processor 151, enabling the processor 151 to perform the methods of any embodiment of this disclosure. The memory 152 may include a random access memory (RAM) 1521, a cache memory 1522, and / or a read-only memory (ROM) 1523. The memory 152 may also include a program tool 1525 having a set of program modules 1524, including but not limited to: an operating system, one or more application programs, other program modules, and program data. One or more combinations of these program modules may include an implementation of a network environment.

[0282] Bus 153 may include, for example, a data bus, an address bus, and a control bus. The computing device 15 can also communicate with external devices 155 via I / O interface 154, such as a keyboard or a Bluetooth device. The computing device 150 can also communicate with one or more networks via network adapter 156, such as a local area network (LAN), a wide area network (WAN), or a public network. As shown, network adapter 156 can also communicate with other modules of the computing device 15 via bus 153.

[0283] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0284] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method for generating identification features for abnormal registration events, used to provide registration risk control functions for several network services, each network service accepting registration events through several registration sources, including: The method for registering the source of the device and / or the source of the registration channel includes: Obtain attribute information of registration events that occur within a set time period. The attribute information includes: the network service identifier corresponding to the network service that accepts the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event. Based on several extraction rules that match the network service identifier and the registration source identifier, extract several event features corresponding to each extraction rule from the event feature set; For each extraction rule, a key-value pair corresponding to that extraction rule is generated; wherein, the key in the key-value pair contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature corresponding to the extraction rule belongs, and the value in the key-value pair contains the value of each event feature corresponding to the extraction rule; Based on the similarity between the obtained key-value pairs, key-value pairs with a similarity greater than a set similarity are grouped into the same key-value pair set. Furthermore, based on the key-value pair set containing more than a first number of key-value pairs, identification features for identifying abnormal registration events are generated.

2. The method as described in claim 1, obtaining event attribute information of a registered event occurring within a set time period, includes: Obtain the event attribute information of the first type of registered events detected within the first set time period; The first type of registration event is a registration event that is currently being registered and has not yet been completed.

3. The method of claim 2, further comprising: Based on the generated identification features used to identify abnormal registration events, the first type of registration events that occur after the first set time period are monitored to identify abnormal registration events among them. Trigger the interception mechanism for this abnormal registration event.

4. The method as described in claim 1, obtaining event attribute information of a registered event occurring within a set time period, includes: Obtain event attribute information for second-type registered events that occur within the second-type defined time period; The second type of registration event is a registration event that has already been registered.

5. The method of claim 4, further comprising: Based on the generated identification features used to identify abnormal registration events, the second type of registration events that occur outside the second set time period are monitored to identify abnormal registration events among them. This triggers the account freezing mechanism for the abnormal registration event.

6. The method of claim 4, further comprising: In response to the detected registration event being a second type of registration event, a risk label for the second type of registration event is determined based on the current identification features used to identify abnormal registration events, and the determined risk label is added as an event feature to the event feature set corresponding to the second type of registration event; wherein, the risk label is used to characterize the risk that the second type of registration event belongs to an abnormal registration event.

7. The method of claim 1, wherein the event feature set of the registration event includes at least one of the following event features: The time of the registration event; The account name corresponding to this registration event; The password corresponding to this registration event; The mobile phone number corresponding to this registration event; The IP address that initiated the registration event; The region to which the IP address that initiated the registration event belongs; One or more operating environment parameters of the operating environment that initiated the registration event.

8. The method of claim 7, further comprising: Determine the account name corresponding to the registration event and the naming template to which the account name belongs; The naming template is added as an event feature to the event feature set corresponding to the registration event; wherein the account name and the naming template follow a preset fuzzy matching rule.

9. The method of claim 7, further comprising: Based on one or more operating environment parameters of the operating environment that initiated the registration event, at least one operating environment fingerprint is determined, and each operating environment fingerprint is added as an event feature to the event feature set of the registration event. The operating environment fingerprint is a hash value calculated based on one or more operating environment parameters; the operating environment parameters include language, time zone, operating system, plugins, whether Java is supported, whether cookies are supported, whether the console is open, storage path, resolution, Canvas, number of fonts, font MD5 value, CPU model, number of CPU cores, and number of mouse and keyboard key presses.

10. The method of claim 1, wherein in a key-value pair, the order of the feature type identifiers contained in the key is the same as the order of the event features contained in the value corresponding to the respective feature type identifiers.

11. The method of claim 1, wherein key-value pairs with a similarity greater than a predetermined degree are grouped into the same key-value pair set based on the similarity between each key-value pair, comprising: Based on the obtained key-value pairs, pairs with the same key-value pair are grouped into the same key-value pair set.

12. The method of claim 1, wherein key-value pairs with a similarity greater than a predetermined degree are grouped into the same key-value pair set based on the similarity between the obtained key-value pairs, comprising: Group identical key-value pairs among the obtained key-value pairs into the same key-value pair set; Identify key-value pairs that satisfy similarity conditions among all key-value pairs; wherein, two key-value pairs satisfying similarity conditions include: the two key-value pairs have the same key, and the event features belonging to at least one feature type identifier contained in the values ​​are different; For key-value pairs that meet the similarity conditions, the similarity is calculated pairwise, including: determining the different event features belonging to the same feature type identifier contained in the values ​​of the two key-value pairs; calculating the similarity of the different event features belonging to the same feature type identifier; calculating the average similarity based on the similarity corresponding to several feature type identifiers; and using the average similarity as the similarity between the two key-value pairs. Key-value pairs with a similarity greater than a set similarity will be grouped into the same key-value pair set.

13. The method of claim 12, wherein the step of calculating the similarity between different event features belonging to the same feature type identifier contained in the values ​​of the two key-value pairs includes: If the same feature type identifier is an account name type identifier, then calculate the similarity between the different account names contained in these two key-value pairs.

14. The method of claim 13, further comprising: Based on the similar account names contained in different key-value pairs in the same set of key-value pairs, determine the regular expression used to match these similar account names; Based on a set of key-value pairs containing more than a first number of key-value pairs, generate identification features for identifying anomalous registration events, including: If the number of key-value pairs in the same key-value pair set is greater than the first number, then the common event features contained in each key-value pair in the key-value pair set are combined with the regular expression to form an identification feature for identifying abnormal registration events.

15. The method of claim 12, wherein the step of calculating the similarity of different event features belonging to the same feature type identifier includes: If the same feature type identifier is an IP address type identifier, then calculate the similarity between the different IP addresses contained in these two key-value pairs.

16. The method of claim 15, further comprising: Based on the similar IP addresses contained in different key-value pairs within the same set of key-value pairs, determine the common Geohash encoding prefix of these similar IP addresses; Based on a set of key-value pairs containing more than a first number of key-value pairs, generate identification features for identifying anomalous registration events, including: If the number of key-value pairs in the same key-value pair set is greater than the first number, then the common event features contained in each key-value pair in the key-value pair set, together with the common Geohash encoding prefix, form the identification features used to identify abnormal registration events.

17. The method of claim 1, wherein generating identification features for identifying anomalous registration events based on a set of key-value pairs containing a number exceeding a first number, comprises: A set of key-value pairs containing more than a first number of key-value pairs is provided to the administrator for review, so that the administrator can decide whether to generate identification features for identifying abnormal registration events based on the set of key-value pairs. Based on the set of key-value pairs containing a number of key-value pairs that exceeds a second number, identification features for identifying abnormal registration events are automatically generated; wherein the second number is greater than the first number.

18. The method of claim 1, wherein the generated identification features for identifying abnormal registration events have an expiration period, and the method further comprises: If, within the validity period, the number of abnormal registration events identified based on the identification features exceeds a third number, the validity period is extended.

19. The method as described in claim 1, applied to a registration risk control system, the method further comprising: Obtain anomaly tags provided by the auxiliary risk control system, wherein the auxiliary risk control system is independent of the registration risk control system, and the anomaly tags are used to mark the event characteristics of abnormal registration events identified by the auxiliary risk control system; If the event feature set of the detected registered event includes the event feature marked by the anomaly label, then the anomaly label is added to the event feature set as an event feature; or, identification features for identifying abnormal registered events are generated based on the anomaly label.

20. The method of claim 19, further comprising: The attribute information of the monitored registration events is sent to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps: The event characteristics of one or more of the registered events are displayed to the risk control personnel, so that the risk control personnel can customize several abnormal labels and input them into the auxiliary risk control system.

21. The method of claim 19, further comprising: The attribute information of the monitored registration events is sent to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps: Send one or more event characteristics of the registered event to the black market information tagging platform; Receive the black market information labeling platform's labeling results regarding whether one or more event characteristics belong to black market information; The labeling results representing black market information are sent as anomaly tags to the registration risk control system.

22. The method of claim 19, further comprising: The attribute information of the monitored registration events is sent to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps: Based on the attribute information of different registered events, the number of different registered events matching the same anomaly label is counted. Among them, the registered events matching the anomaly label have event characteristics corresponding to the anomaly label. The abnormal tags whose corresponding statistical count is greater than the fourth number are sent to the registration risk control system.

23. The method of claim 19, further comprising: The attribute information of the monitored registration events is sent to the auxiliary risk control system, so that the auxiliary risk control system can perform the following steps: Select one or more event features of the registered event and send them to several network service providers so that each network service provider can mark whether the event feature is an abnormal event feature based on the operation of the network service; Obtain the labeling results returned by the provider of each network service, and send the labeling results that represent the characteristics of abnormal events as abnormal tags to the registration risk control system.

24. The method of claim 23, wherein, Each network service provider detects the behavioral data of the account corresponding to the normal registration event identified by the registration risk control system. The normal registration event is the registration event accepted by the network service. If it is determined that the detected account behavior is abnormal, the normal registration event is actually an abnormal registration event, and the attribute information of the abnormal registration event is fed back to the auxiliary risk control system. The steps performed by the auxiliary risk control system also include: For each network service, the attribute information of the abnormal registration event reported by the provider of that network service is further fed back to the providers of other network services for reference; and / or For each network service, the attribute information of the abnormal registration event reported by the network service provider is fed back to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

25. The method of claim 23, wherein, Each network service provider detects the behavioral data of the account corresponding to the abnormal registration event identified by the registration risk control system. The abnormal registration event is handled by the corresponding network service provider. If it is determined that the detected account behavior is normal, the abnormal registration event is actually a normal registration event, and the attribute information of the normal registration event is fed back to the auxiliary risk control system. The steps performed by the auxiliary risk control system also include: For each network service, the attribute information of the normal registration event reported by the provider of that network service is forwarded to the providers of other network services; and / or For each network service, the attribute information of normal registration events reported by the provider of that network service is forwarded to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

26. The method of claim 19, further comprising: After adding the abnormal label as an event feature to the event feature set, the attribute information of the registration risk control system that has been identified as a normal registration event is reviewed based on the updated event feature set.

27. An apparatus for generating identification features for abnormal registration events, used to provide registration risk control functions for several network services, each network service accepting registration events through several registration sources, including: The device is registered from the source of the equipment and / or the source of the registration channel, and the device includes: The acquisition module acquires the attribute information of the monitored registration event. The attribute information includes: the network service identifier corresponding to the network service that accepted the registration event, the registration source identifier corresponding to the source of the registration event, and the event feature set of the registration event. The extraction module extracts several event features corresponding to each extraction rule from the event feature set based on several extraction rules that match the network service identifier and the registration source identifier. The first generation module generates a key-value pair corresponding to each extraction rule; wherein, the key in the key-value pair contains the network service identifier, the registration source identifier, and the feature type identifier to which each event feature corresponding to the extraction rule belongs, and the value in the key-value pair contains the value of each event feature corresponding to the extraction rule; The second generation module, based on the similarity between each key-value pair obtained within a set time period, groups key-value pairs with a similarity greater than a set similarity into the same key-value pair set, and generates identification features for identifying abnormal registration events based on the number of key-value pairs included in the key-value pair set exceeding a first number.

28. The apparatus of claim 27, wherein the acquisition module acquires event attribute information of a first type of registration event monitored within a first set time period; the first type of registration event is a registration event that is in the process of registration and has not yet been completed.

29. The apparatus of claim 28, further comprising: The identification module monitors the first type of registration events that occur after a set time period, based on the generated identification features used to identify abnormal registration events, in order to identify the abnormal registration events among them. Trigger the interception mechanism for this abnormal registration event.

30. The apparatus of claim 27, wherein the acquisition module acquires event attribute information of a second type of registration event occurring within a second type of set time period; the second type of registration event is a registration event that has been registered.

31. The apparatus of claim 30, further comprising: The identification module monitors second-category registration events that occur outside the second-category set time period based on the generated identification features used to identify abnormal registration events, so as to identify abnormal registration events and trigger the account freezing mechanism for the abnormal registration event.

32. The apparatus of claim 30, further comprising: In response to the detected registration event being the second type of registration event, the feature addition module determines the risk label of the second type of registration event based on the current identification features used to identify abnormal registration events, and adds the determined risk label as an event feature to the event feature set corresponding to the second type of registration event; wherein, the risk label is used to characterize the risk that the second type of registration event belongs to the abnormal registration event.

33. The apparatus of claim 27, wherein the event feature set of the registration event includes at least one of the following event features: The time of the registration event; The account name corresponding to this registration event; The password corresponding to this registration event; The mobile phone number corresponding to this registration event; The IP address that initiated the registration event; The region to which the IP address that initiated the registration event belongs; One or more operating environment parameters of the browser that initiated the registration event.

34. The apparatus of claim 33, wherein the feature addition module determines the account name corresponding to the registration event and the naming template to which the account name belongs; and adds the naming template as an event feature to the event feature set corresponding to the registration event; wherein, The account name and the naming template follow a preset fuzzy matching rule.

35. The apparatus of claim 33, wherein the feature addition module determines at least one browser fingerprint based on one or more operating environment parameters of the browser that initiated the registration event, and adds each browser fingerprint as an event feature to the event feature set of the registration event.

36. The apparatus of claim 27, wherein in a key-value pair, the order of the feature type identifiers contained in the key is the same as the order of the event features contained in the value corresponding to the respective feature type identifiers.

37. The apparatus of claim 27, wherein the second generating module, based on the obtained key-value pairs, groups identical key-value pairs into the same key-value pair set.

38. The apparatus of claim 27, wherein the second generating module groups identical key-value pairs among the obtained key-value pairs into the same key-value pair set; Identify key-value pairs that satisfy the similarity condition among all key-value pairs; where, Two key-value pairs satisfy similarity conditions, including: the keys of the two key-value pairs are the same, and the event features belonging to at least one feature type identifier contained in the values ​​are different; for key-value pairs that satisfy similarity conditions, calculate the similarity between each pair, including: determining the different event features belonging to the same feature type identifier contained in the values ​​of the two key-value pairs, calculating the similarity between the different event features belonging to the same feature type identifier, calculating the average similarity based on the similarity corresponding to several feature type identifiers respectively, and using the average similarity as the similarity between the two key-value pairs; and grouping key-value pairs with similarity greater than a set similarity into the same key-value pair set.

39. The apparatus of claim 38, wherein the second generation module, if the same feature type identifier is an account name type identifier, calculates the similarity between the different account names contained in the two key-value pairs.

40. The apparatus of claim 39, wherein the second generation module determines a regular expression for matching similar account names based on the similar account names contained in different key-value pairs in the same key-value pair set; if the number of key-value pairs in the same key-value pair set is greater than a first number, then the common event features contained in each key-value pair in the key-value pair set and the regular expression are combined to form an identification feature for identifying abnormal registration events.

41. The apparatus of claim 38, wherein the second generating module, if the same feature type identifier is an IP address type identifier, calculates the similarity between the different IP addresses contained in the two key-value pairs.

42. The apparatus of claim 41, wherein the second generating module determines a common Geohash encoding prefix for similar IP addresses based on similar IP addresses contained in different key-value pairs in the same key-value pair set; if the number of key-value pairs in the same key-value pair set is greater than a first number, then the common event features contained in each key-value pair in the key-value pair set and the common Geohash encoding prefix are combined to form an identification feature for identifying abnormal registration events.

43. The apparatus of claim 27, wherein the second generation module provides a set of key-value pairs containing more than a first number of key-value pairs to an administrator for review, so that the administrator can decide whether to generate identification features for identifying abnormal registration events based on the set of key-value pairs; and automatically generates identification features for identifying abnormal registration events based on a set of key-value pairs containing more than a second number of key-value pairs; wherein, The second quantity is greater than the first quantity.

44. The apparatus of claim 27, wherein the generated identification feature for identifying abnormal registration events has an expiration date, the apparatus further comprising: The validity period extension module extends the validity period if, within the validity period, the number of abnormal registration events identified based on the identification features exceeds a third number.

45. The apparatus of claim 27, applied to a registration risk control system, the apparatus further comprising: The interaction module obtains anomaly tags provided by the auxiliary risk control system, wherein the auxiliary risk control system is independent of the registration risk control system, and the anomaly tags are used to mark the event features of abnormal registration events identified by the auxiliary risk control system; if the event feature set of the monitored registration events includes the event feature marked by the anomaly tag, then the anomaly tag is added to the event feature set as an event feature; or, identification features for identifying abnormal registration events are generated based on the anomaly tag.

46. ​​The apparatus of claim 45, wherein the interaction module sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps: The event characteristics of one or more of the registered events are displayed to the risk control personnel, so that the risk control personnel can customize several abnormal labels and input them into the auxiliary risk control system.

47. The apparatus of claim 45, wherein the interaction module sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps: Send one or more event characteristics of the registered event to the black market information tagging platform; Receive the black market information labeling platform's labeling results regarding whether one or more event characteristics belong to black market information; The labeling results representing black market information are sent as anomaly tags to the registration risk control system.

48. The apparatus of claim 45, wherein the interaction module sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps: Based on the attribute information of different registered events, the number of different registered events matching the same anomaly tag is counted. The registered events that match the anomaly label have the event characteristics corresponding to that anomaly label; The abnormal tags whose corresponding statistical count is greater than the fourth number are sent to the registration risk control system.

49. The apparatus of claim 45, wherein the interaction module sends the attribute information of the detected registration event to the auxiliary risk control system, so that the auxiliary risk control system performs the following steps: Select one or more event features of the registered event and send them to several network service providers so that each network service provider can mark whether the event feature is an abnormal event feature based on the operation of the network service; Obtain the labeling results returned by the provider of each network service, and send the labeling results that represent the characteristics of abnormal events as abnormal tags to the registration risk control system.

50. The apparatus of claim 49, wherein, Each network service provider detects the behavioral data of the account corresponding to the normal registration event identified by the registration risk control system. The normal registration event is the registration event accepted by the network service. If it is determined that the detected account behavior is abnormal, the normal registration event is actually an abnormal registration event, and the attribute information of the abnormal registration event is fed back to the auxiliary risk control system. The steps performed by the auxiliary risk control system also include: For each network service, the attribute information of the abnormal registration event reported by the provider of that network service is further fed back to the providers of other network services for reference; and / or For each network service, the attribute information of the abnormal registration event reported by the network service provider is fed back to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

51. The apparatus of claim 49, wherein, Each network service provider detects the behavioral data of the account corresponding to the abnormal registration event identified by the registration risk control system. The abnormal registration event is handled by the corresponding network service provider. If it is determined that the detected account behavior is normal, the abnormal registration event is actually a normal registration event, and the attribute information of the normal registration event is fed back to the auxiliary risk control system. The steps performed by the auxiliary risk control system also include: For each network service, the attribute information of the normal registration event reported by the provider of that network service is forwarded to the providers of other network services; and / or For each network service, the attribute information of normal registration events reported by the provider of that network service is forwarded to the registration risk control system so that the registration risk control system can adjust the identification features used to identify abnormal registration events.

52. The apparatus of claim 45, further comprising: The verification module, after adding the abnormal label as an event feature to the event feature set, verifies the attribute information of the registration risk control system as a normal registration event based on the updated event feature set.

53. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1-26.

54. A computing device, comprising a memory and a processor; the memory being configured to store computer instructions executable on the processor, the processor being configured to implement the method of any one of claims 1-26 when executing the computer instructions.

Images