Risk control method, node and system

Abstract

The present application provides a risk control method, a node and a system. The method is applied to a remote service node, and comprises: obtaining the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group comprises a plurality of nodes, and whether each node is a trusted node is determined on the basis of trusted status information stored by the present node; and on the basis of the number of trusted nodes in each node group and a pre-stored first preset threshold, correspondingly determining each node group to be a risky group or a trusted group. Risky groups can be simply and efficiently identified, providing a safer and more efficient risk control service.

Description

Risk control methods, nodes, and systems Technical Field

[0001] This application relates to the field of risk control, and in particular to a risk control method, node, and system. Background Technology

[0002] With the continuous development of technology in various industries, risk control is an effective means to maintain the stability and security of business operations. Risk control refers to the various measures and methods taken by risk managers to eliminate or reduce the possibility of risk events occurring, or to reduce the losses caused when risks occur.

[0003] For example, in the financial sector, losses can arise from market risk, credit risk, and operational risk, such as loan defaults and group-based risk behaviors. Among these, group-based risk behaviors cause extremely serious losses and have a wide-ranging impact. Therefore, how to easily and efficiently identify these high-risk groups to provide safer and more efficient risk control services has become an urgent problem to be solved.

[0004] Summary of the Invention

[0005] This application provides a risk control method, node, and system that can easily and efficiently identify risky groups to provide safer and more efficient risk control services.

[0006] In a first aspect, this application provides a risk control method applied to a remote service node. The method includes: obtaining the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on the trusted status information stored by the node; and determining each node group as a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

[0007] The risk control method provided in this application can determine whether a node group as a whole is a risky or trustworthy group based on the trustworthiness of each node within the group. Specifically, it identifies risky groups by determining the number of trustworthy nodes in different node groups based on the trustworthiness status information stored by each node. Services are refused to be provided to risky groups, thereby ensuring the security of financial services. The trustworthiness of each node is determined based on whether it is an authenticated trustworthy node, without needing to collect user information from each node, thus avoiding issues such as user data leakage. This enhances privacy and also reduces network transmission pressure and storage pressure on remote service nodes caused by the transmission of large amounts of user information.

[0008] In this application, the determination of whether a node group is a risky group or a trusted group can be performed by either the remote service node or the root node within that node group. For example, the root node can determine, based on its processing capabilities, whether to perform the determination itself or to report the collected trusted node information to the remote service node for determination. The identification of risky groups can be completed either by the remote service node or by the root node within each node group before reporting to the remote service node. This effectively alleviates the network and computational overhead of the remote service node while reducing service latency.

[0009] In one possible implementation, obtaining the number of trusted nodes in at least one node community connected to the remote service node includes: receiving a set of trusted status information reported by each root node, wherein the set of trusted status information reported by each root node includes the trusted status information of each node in its node community, and the root node refers to a node in each node community that is directly connected to the remote service node; and determining the number of trusted nodes in the node community according to each set of trusted status information.

[0010] Optionally, the remote service node can divide each node in the local network into a node group, determine the total number of nodes in each node group based on the number of root nodes and child nodes in each node group, and determine the number of trusted nodes in its node group based on the trusted status information reported by the child nodes level by level and the trusted status information of the root node.

[0011] In one possible implementation, the method further includes: receiving a trusted message reported by the root node, wherein the trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate whether the node community to which the root node belongs is a risky community or a trusted community; and determining whether the node community to which the root node belongs is a risky community or a trusted community based on the trusted message reported by the root node.

[0012] When the root node is capable of judging and processing the business, it can report to the remote service node whether the node group it judges belongs to a risk group or a trusted group, or it can inform the remote service node that the number of trusted nodes is to be judged by the remote service node itself.

[0013] In one possible implementation, determining whether a node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a first preset threshold includes: if the proportion of trusted nodes in a node group is greater than the first preset threshold, then the node group is determined to be a trusted group; if the proportion of trusted nodes in a node group is not greater than the first preset threshold, then the node group is determined to be a risk group.

[0014] Optionally, the remote service node sets a first preset threshold based on the number of nodes in the node group. Alternatively, the remote service node can also set a first preset threshold based on the proportion of trusted nodes in the node group to the total number of nodes. This setting method is not affected by the number of nodes in the node group, making it more flexible and convenient to apply. Calculating the number or proportion of trusted nodes based on the trusted status information of each node does not require relying on complex algorithms to mine risk groups or judge the attributes of their risk events. It only requires determining whether to provide service based on whether the node group is trusted, significantly reducing the computational difficulty and overhead, and improving the overall response speed.

[0015] In one possible implementation, the triggering condition for obtaining the number of trusted nodes in at least one node community connected to the remote service node includes one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0016] Optionally, after each business request, the trusted status of each node may change because the business request is a risk control event. Therefore, the trusted status information is updated and recalculated based on the occurrence of a risk control event. Alternatively, remote service nodes can initiate risk group identification at irregular or regular intervals. This can further improve the real-time protection capabilities of security measures.

[0017] In one possible implementation, the method further includes: if a node is determined to be an untrusted node, then all downstream nodes of the untrusted node are also determined to be untrusted nodes. Setting all downstream nodes of an untrusted node to untrusted status further enhances the probability of identifying risky groups, making protection more precise.

[0018] Secondly, this application provides a risk control method applied to a root node, wherein the root node refers to a node directly connected to the remote service node within a node group connected to the remote service node. The method includes: collecting trusted status information of each node in the node group to which the root node belongs, wherein the trusted status information is stored by each node and reported level by level by each child node; reporting the trusted status information to the remote service node, so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines the node group to which the root node belongs as a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0019] This application can identify risk groups based on the trusted node status already obtained for different nodes in each local network, such as trusted nodes, ordinary nodes, and untrusted nodes. It eliminates the need for techniques such as graph computing, knowledge graphs, and community mining to identify risk groups, such as the primary risk behavior group. Therefore, it greatly simplifies computational complexity, increases the possibility of real-time identification, and does not rely on abundant user data. It can easily and efficiently identify risk groups to provide more secure, real-time, and efficient risk control services.

[0020] In one possible implementation, after collecting the trusted status information of each node in the node community, the method further includes: determining the number of trusted nodes based on the collected trusted status information of each node in the node community; the step of reporting the trusted status information to the remote service node includes: if the total number of nodes in the node community is greater than a pre-stored second preset threshold, then the collected trusted status information of each node is used as a trusted status information set and reported to the remote service node.

[0021] In one possible implementation, the method further includes: determining the number of trusted nodes based on the trusted status information of each node in the node group to which the node belongs; if the total number of nodes in the node group to which the node belongs is not greater than a pre-stored second preset threshold, then determining the node group to which the node belongs as a risk group or a trusted group based on the number of trusted nodes in the node group to which the node belongs and the pre-stored first preset threshold; reporting a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message being used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0022] In one possible implementation, determining whether a node group is a risk group or a trusted group based on the number of trusted nodes in the node group and a pre-stored first preset threshold includes: if the proportion of trusted nodes in the node group is greater than the first preset threshold, then the node group is determined to be a trusted group; if the proportion of trusted nodes in the node group is not greater than the first preset threshold, then the node group is determined to be a risk group.

[0023] In one possible implementation, the triggering conditions for reporting the trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0024] In one possible implementation, the method further includes: if a node is determined to be an untrusted node, then all downstream nodes of the untrusted node are determined to be untrusted nodes.

[0025] Thirdly, this application provides a risk control method applied to a child node, wherein the child node refers to a node in each node group connected to the remote service node that indirectly accesses the remote service node. The method includes: reporting stored trusted status information level by level, wherein the trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node determines the node group to which the child node belongs as a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to a node in each node group connected to the remote service node that directly accesses the remote service node.

[0026] In one possible implementation, the triggering conditions for reporting the trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0027] Fourthly, this application provides a remote service node, comprising: a transceiver module, configured to acquire the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on trusted status information stored in the node; and a risk group identification module, configured to determine each node group as a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

[0028] In one possible implementation, the transceiver module is specifically used to receive a set of trusted state information reported by each root node. The set of trusted state information reported by each root node includes the trusted state information of each node in its node community. The root node refers to a node in each node community that directly accesses the remote service node. The risk community identification module is specifically used to determine the number of trusted nodes in the node community based on each set of trusted state information.

[0029] In one possible implementation, the transceiver module is further configured to receive a trusted message reported by the root node, wherein the trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate that the node community to which the root node belongs is a risky community or a trusted community; the risky community identification module is further configured to determine, based on the trusted message reported by the root node, that the node community to which the root node belongs is a risky community or a trusted community.

[0030] In one possible implementation, the risk group identification module is specifically used to determine that a node group is a trusted group if the proportion of trusted nodes in a node group is greater than the first preset threshold; and to determine that a node group is a risk group if the proportion of trusted nodes in a node group is not greater than the first preset threshold.

[0031] In one possible implementation, the triggering condition for the transceiver module to obtain the number of trusted nodes in at least one node community connected to the remote service node includes one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0032] In one possible implementation, the risk group identification module is further configured to, if a node is determined to be an untrusted node, identify all downstream nodes of the untrusted node as untrusted nodes.

[0033] Fifthly, this application provides a root node, which refers to a node directly connected to the remote service node in each node group connected to the remote service node. The root node includes: a risk group identification module, used to collect the trusted status information of each node in the node group to which it belongs, wherein the trusted status information is stored by each node and reported by each child node level by level; and a transceiver module, used to report the trusted status information to the remote service node, so that the remote service node can determine the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determine whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0034] In one possible implementation, the risk group identification module is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of each node in the node group to which it belongs is greater than a pre-stored second preset threshold, then the trusted status information of each node collected is used as a trusted status information set. The transceiver module is also used to report the trusted status information set to the remote service node.

[0035] In one possible implementation, the risk group identification module is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of nodes in the node group to which it belongs is not greater than a pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the pre-stored first preset threshold. The transceiver module is further used to report a trusted message to the remote service node. The trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0036] In one possible implementation, the risk group identification module is specifically used to determine the node group as a trusted group if the proportion of trusted nodes in the node group to which it belongs is greater than the first preset threshold; and to determine the node group as a risk group if the proportion of trusted nodes in the node group to which it belongs is not greater than the first preset threshold.

[0037] In one possible implementation, the triggering conditions for the transceiver module to report the trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0038] In one possible implementation, the risk group identification module is further configured to, if a node is determined to be an untrusted node, identify all downstream nodes of the untrusted node as untrusted nodes.

[0039] Sixthly, this application provides a child node, wherein the child node refers to a node in each node group connected to the remote service node that indirectly accesses the remote service node. The child node includes a transceiver module, used to report stored trusted status information level by level. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node determines the node group to which the child node belongs as a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to a node in each node group connected to the remote service node that directly accesses the remote service node.

[0040] In one possible implementation, the triggering conditions for the transceiver module to report the trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0041] In a seventh aspect, this application provides an electronic device including at least one processor and a communication port, such as a transceiver, wherein the at least one processor and the transceiver are coupled, and when the at least one transceiver executes a program or instructions, the electronic device implements some or all of the operations described in the first aspect and any possible implementation thereof. This electronic device may be a terminal device or a chip within a terminal device.

[0042] Eighthly, this application provides an electronic device including at least one processor and a communication port, such as a transceiver, wherein the at least one processor and the transceiver are coupled, and when the at least one transceiver executes a program or instructions, the electronic device performs some or all of the operations described in the second aspect and any possible implementation thereof. This electronic device may be an edge device or a chip within an edge device.

[0043] Ninthly, this application provides an electronic device including at least one processor and a communication port, such as a transceiver, wherein the at least one processor and the transceiver are coupled, and when the at least one transceiver executes a program or instructions, the electronic device performs some or all of the operations described in the third aspect and any possible implementation thereof. The electronic device may be a server or a chip within a server.

[0044] In a tenth aspect, this application provides a risk control system, comprising: a remote service node, at least one root node, and at least one child node, wherein the remote service node is used to implement some or all of the operations as in any possible implementation of the first aspect; the root node is used to implement some or all of the operations as in any possible implementation of the second aspect, and the child node is used to implement some or all of the operations as in any possible implementation of the third aspect.

[0045] Eleventhly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements some or all of the operations included in any of the methods described in any of the foregoing aspects and any possible implementations of any of the foregoing aspects.

[0046] In a twelfth aspect, this application provides a computer program product comprising a computer program that, when executed by a processor, implements some or all of the operations included in any of the methods described in any of the foregoing aspects and any possible implementations of any of the foregoing aspects.

[0047] In a thirteenth aspect, this application provides a chip, including: an interface circuit and a processor. The interface circuit is connected to the processor, and the processor is configured to cause the chip to perform some or all of the operations included in any of the preceding aspects of the method and any possible implementation thereof.

[0048] It should be understood that the second to thirteenth aspects of this application are consistent with or correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0049] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 is an architecture diagram of a risk control system provided in an embodiment of this application;

[0051] Figure 2 is a flowchart illustrating one of the risk control methods provided in this application embodiment;

[0052] Figure 3 is a second schematic flowchart of a risk control method provided in an embodiment of this application;

[0053] Figure 4 is a second flowchart illustrating a risk control method provided in an embodiment of this application;

[0054] Figure 5 is an example diagram of the trusted state of each node in node community A provided in the embodiments of this application;

[0055] Figure 6 is an architecture diagram of another risk control system provided in an embodiment of this application;

[0056] Figure 7 is a fourth flowchart illustrating a risk control method provided in an embodiment of this application;

[0057] Figure 8 is a fifth flowchart illustrating a risk control method provided in an embodiment of this application;

[0058] Figure 9 is a schematic diagram of the structure of a remote service node provided in an embodiment of this application;

[0059] Figure 10 is a schematic diagram of the structure of a root node provided in an embodiment of this application;

[0060] Figure 11 is a schematic diagram of the structure of a child node provided in an embodiment of this application;

[0061] Figure 12 is a schematic diagram of the structure of the first device 40 according to an embodiment of this application;

[0062] Figure 13 is a schematic diagram of the structure of the second device 50 according to an embodiment of this application;

[0063] Figure 14 is a structural schematic diagram of the third device 60 according to an embodiment of this application;

[0064] Figure 15 is a structural schematic diagram of a device 70 provided in an embodiment of this application;

[0065] Figure 16 is a schematic diagram of another risk control system provided in an embodiment of this application. Detailed Implementation

[0066] To enable those skilled in the art to better understand the solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0067] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0068] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0069] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0070] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0071] To facilitate understanding, the relevant terms and concepts used in the embodiments of this application will be explained below:

[0072] 1. Terminal Node

[0073] Also known as a terminal or terminal device, it refers to the outermost device in a computer network, mainly used for user information input and output, and is an important device for interaction with users, including computers, mobile phones, etc.

[0074] 2. Edge device nodes

[0075] A device that communicates with a remote service node (i.e., a server) at the boundary of a local network.

[0076] 3. Nodes

[0077] The term "node" refers to various devices in a network, including terminal devices, servers, edge devices, etc. In this embodiment, "node" refers to devices in the network other than remote service nodes.

[0078] 4. Trusted Nodes

[0079] It refers to various types of nodes that have been certified or licensed and can be trusted, including terminal trusted nodes (or terminal trusted devices, trusted terminal devices) and edge trusted nodes (or trusted edge devices, purely trusted nodes), etc.

[0080] 5. Local network

[0081] Local networks can be divided according to geographical scope, Internet Protocol (IP) network segments, etc., and are not limited to the examples in the embodiments.

[0082] 6. Intelligent risk control

[0083] It is an important means of comprehensively utilizing technologies such as big data, information systems, and artificial intelligence (AI) to intelligently manage financial risks that exist during the operation of financial businesses, thereby ensuring the business security of financial institutions (such as banks, telecom operators, and internet finance companies). Among these financial risks are primary risk behaviors such as defaulting on loans and group primary risk behaviors.

[0084] 7. Group's First Risk Behavior

[0085] The first risk behavior refers to the act of obtaining user assets through improper means such as fabricating facts and concealing the truth. There are many forms of group first risk behavior. The embodiments of this application mainly target the identification of groups that initiate first risk behavior within the same network scope (i.e., a local network) (referred to as first risk behavior groups).

[0086] 8. Risk Groups

[0087] This application defines a risk group as a local network or a group of nodes containing multiple nodes that may potentially cause financial risks. A common risk group includes a group that performs the first risky action. A risk group can also include multiple nodes in a local network that trigger different types of financial risk events; for example, some nodes may perform the first risky action while others may steal bank card deposits. This application uses the first risky action group as an example for illustration, but it is not intended to be limiting.

[0088] The risk control method provided in this application can identify risk groups and can be applied to systems that provide intelligent risk control services (such as financial risk control). As shown in Figure 1, this system includes multiple local networks, each containing multiple nodes, which can be terminal nodes or edge device nodes. This application example uses multiple nodes in each local network as a node group, but this is not a limitation; the node group can be divided according to the actual deployment. Figure 1 is an architecture diagram of a risk control system provided in this application. The system 100 includes a remote service node 10 and other nodes. The remote service node 10 is the device corresponding to the remote risk control service center. Referring to Figure 1, the service node not in any local network is the remote service node. Other nodes include a root node 20 and child nodes 30. In each node group, the root node 20 directly connects to the remote service node, while the child nodes 30 connect to the remote service node 10 through the root node 20 or other nodes. Both the root node 20 and child nodes 30 can be trusted nodes, ordinary nodes, or untrusted nodes. Trusted nodes are nodes that have been authenticated by remote service nodes or other trusted nodes; ordinary nodes are new terminal nodes that have just joined the system and have not yet been authenticated; untrusted nodes are nodes that have become untrusted due to a risk event. System 100 includes multiple local networks, each containing several interconnected nodes. Each dashed box in Figure 1 is considered a local network.

[0089] Figure 2 is a flowchart illustrating one of the risk control methods provided in this application embodiment. This application embodiment uses the application of this method in the system provided in Figure 1 as an example for illustration, but it is not limited thereto. The method is applied to the remote service node 10, including but not limited to steps S101 and S102.

[0090] S101. The remote service node obtains the number of trusted nodes in at least one node community connected to the remote service node, wherein the node community includes multiple nodes, and whether each node is a trusted node is determined based on its stored trusted state information.

[0091] A node community includes multiple nodes, such as terminal nodes or edge device nodes. A node community that is directly connected to a remote service node is defined as the root node. A node that is indirectly connected to a remote service node is defined as a child node. Indirect access refers to accessing the remote service node through the root node or through other child nodes. A node community that has at least one node connected to a remote service node is a node community where the root node is directly connected to the remote service node.

[0092] The process of a remote service node obtaining the number of trusted nodes in at least one node group connected to it involves two parts: first, the remote service node obtains information about the node groups it is connected to, including the number of nodes in each group; second, the remote service node obtains the number of trusted nodes in each node group. Regarding the remote service node obtaining information about the node groups it is connected to, it can divide these nodes into several groups based on their network relationships. Referring to Figure 1, the remote service node can divide each node in its local network into a node group, and determine the total number of nodes in each group based on the number of root nodes and child nodes within each group.

[0093] To obtain the number of trusted nodes in each node community, the remote service node can obtain the trusted state information set of each node community through the root node to determine the number of trusted nodes in each node community. Alternatively, it can obtain the number of trusted nodes in its corresponding node community based on the indication information received from the root node, such as trusted messages.

[0094] For example, each node (including the root node and child nodes) stores its own trusted state information. In one possible implementation, each node's trusted state information is continuously updated based on whether the node is currently authenticated by a remote service node or other already authenticated trusted nodes. If a node A (node ​​A can be the root node or a child node) has been authenticated, its trusted state information can be trusted; if node A has just come online and has not yet been authenticated, its trusted state information can be normal; if node A is identified as having experienced a risk event in the risk control service, its trusted state information can be untrusted, and so on for other nodes. Assuming that in system 100, the remote service node is referred to as the upstream device, each node can report its trusted state information level by level, so that the root node can collect the trusted state information of its node group. The root node can determine, based on its processing capacity, whether to judge whether the node group is a risk group itself or report it to the remote service node for judgment. If the root node is capable of processing, it will process the collected trusted state information to obtain the number of trusted nodes, and send a trusted message to the remote service node to inform whether the node's community is a risky community, or to inform it of the number of trusted nodes. If the root node is not capable of processing, it will send the collected trusted state information as a trusted state information set to the remote service node, which will then process it to obtain the number of trusted nodes.

[0095] Optionally, trusted status information can use pre-defined identifiers or characters to indicate trusted, normal, or untrusted status. Trusted status information can also include both trusted and untrusted status, where untrusted status includes both normal and untrusted status.

[0096] S102. The remote service node determines each node group as a risk group or a trusted group based on the number of trusted nodes in each node group and the pre-stored first preset threshold.

[0097] Optionally, the remote service node determines whether a node group is a risk group or a trusted group based on the number of trusted nodes in each node group, the total number of nodes in the node group, and a pre-stored first preset threshold. It continues to provide risk control services to trusted groups and refuses to provide risk control services to risk groups.

[0098] For example, remote service nodes can preset and save a first threshold. This first threshold can be set based on experience such as the number of risk groups identified in the past, or it can be set according to the actual situation of each local network during risk control. Remote service nodes can set the first threshold for each node group to be the same or different.

[0099] Optionally, the remote service node sets a first preset threshold based on the number of nodes in a node group. For example, if node group A has 10 nodes, the first preset threshold can be set to 5; if node group B has 4 nodes, the first preset threshold can be set to 2, and so on. The remote service node determines whether a node group is trustworthy based on the number of nodes and the number of trusted nodes in the group. For example, if the number of trusted nodes in node group A is less than or equal to 5, the group is determined to be a risky group; if the number of trusted nodes is greater than 5, the group is determined to be a trustworthy group (or a normal group, non-risk group, etc.).

[0100] Optionally, the remote service node can also set a first preset threshold based on the proportion of trusted nodes in the node group to the total number of nodes. This setting method is not affected by the number of nodes in the node group, making it more flexible and convenient to apply. This embodiment uses the proportion of trusted nodes as the first preset threshold, and assumes that all first preset thresholds are equal, as an example. Assuming the first preset threshold is set to 50%, if the proportion of trusted nodes in the total number of nodes is less than or equal to 50%, the node group is determined to be a risk group; if the proportion of trusted nodes in the total number of nodes is greater than 50%, the node group is determined to be a trusted group. Referring to Figure 1, node group A has 10 nodes, of which 4 are trusted nodes, accounting for 40%, therefore node group A is a risky group; node group B has 4 nodes, of which 4 are trusted nodes, accounting for 100%, therefore node group B is a trusted group; node group C has 4 nodes, of which 1 is trusted node, accounting for 25%, therefore node group C is a risky group; node group D has 4 nodes, of which 0 are trusted nodes, accounting for 0%, therefore node group D is a risky group; node group E has 5 nodes, of which 3 are trusted nodes, accounting for 60%, therefore node group E is a trusted group.

[0101] In some instances, nodes within a node community can obtain risk control services by accessing remote service nodes or other trusted nodes. For example, referring to Figure 3, a terminal node (typically providing ordinary business services) initiates a business request to a node in the local network (this node processes business requests and is usually an edge node that does not provide ordinary business services; for distinction, this node is referred to as the business system node). This business request may include login, transaction, loan, or consumption. The business system node sends a verification request to the remote service node or a local trusted node (including itself). Since both the remote service node and the trusted node store risk control service content, which may include risk control models and risk prevention strategies, this content can identify risks in different business requests and determine whether the request is risky. Therefore, the node receiving the verification request can return a verification result (e.g., risky or not risky) to the business system node based on the risk control service content. The business system node then confirms or rejects the business request based on the returned result.

[0102] Optional, the risk control service content is intelligent risk control service content, including risk control models and risk prevention strategies obtained through big data calculation, machine learning or training, which can achieve more intelligent risk control results.

[0103] Based on this example and the risk control method provided in this application embodiment, if node group A and node group C are identified as risky groups, it is considered that the nodes in node group A and node group C are highly likely to engage in the first risky behavior, and therefore all business requests initiated by node group A and node group C are rejected. Node group B, node group D, and node group E are trusted groups, and when they receive business requests, other risk control measures can be applied to their business applications using the method shown in Figure 3.

[0104] Optionally, the trusted status of each node may change after each business request, and the trusted status information is updated accordingly. Remote service nodes can initiate risk group identification at irregular or scheduled intervals to further improve the real-time protection capabilities of security. For example, risk group identification can be triggered by the occurrence of a risk control event (i.e., the result returned as risky in the example above), or it can be triggered at preset time intervals, such as every hour.

[0105] The risk control method provided in this application can identify risky groups, remote service nodes, and other service-providing nodes by the number of trusted nodes in different node groups, and then stop providing services to risky groups, thereby ensuring the security of financial services. In this application embodiment, the identification of the first risky behavior of a group can be completed by the remote service node or by the root node in each node group and then reported to the remote service node, effectively alleviating the network and computational overhead of the remote service node and reducing service latency. This application embodiment uses certified trusted nodes to determine risky groups, without collecting user information from each node, avoiding problems such as user data leakage, enhancing privacy, and reducing the network transmission pressure and storage pressure on remote service nodes caused by the transmission of large amounts of user information. The number or proportion of trusted nodes is calculated based on the trusted status information of each node, without relying on complex algorithms for risky groups, such as the mining of groups with the first risky behavior and the judgment of the attributes of the first risky behavior, which greatly reduces the difficulty and overhead of computation, improves the overall response speed, and makes it possible to determine the first risky behavior of a group in real time.

[0106] Figure 4 is a flowchart of a risk control method provided in an embodiment of this application. As shown in Figure 4, the method is executed by a remote service node, a root node, and a child node respectively. Taking the risk group as the first risk behavior group as an example, the method includes: S201 to S209.

[0107] S201. The remote service node initiates the identification process for the first risky behavior group.

[0108] Initiating the identification process for the first risk behavior group is equivalent to the remote service node starting to acquire the number of trusted nodes in at least one node group within its system, as shown in Figure 1, which includes node groups A, B, C, D, and E. The triggering condition can be one or both of the following: a risk control event occurs, or a preset time interval is established.

[0109] For example, a risk control event can be triggered by one of the terminal nodes in node groups A, B, C, D, and E sending a business request. This request, such as a request for the first risky behavior, is identified as a risk event by other trusted nodes or a remote service node. This triggers the remote service node to initiate the identification process for the first risky behavior group. For instance, it might inform each node that it needs to obtain their current trusted status information to identify the first risky behavior group, and each node would then report its current trusted status information. Typically, edge device nodes do not provide ordinary business services; therefore, under normal circumstances, it is the terminal node that sends the risk control event to trigger the identification of the first risky behavior group.

[0110] Triggering at preset time intervals can involve simultaneously starting timers on both the remote service node and nodes within each node group. Each timer is set to a preset time interval, and upon timeout, each node within a node group reports its trusted status information level by level. The preset time interval is determined based on factors such as the need to identify the first risky behavior group during actual deployment. Optionally, the timer can be started at the time of the last reported trusted status information.

[0111] When the identification process of the first risky behavior group is initiated by the remote service node, each node updates and obtains the current trusted status information. For example, after S201, S202 and S203 are executed.

[0112] S202, The root node updates the trusted state information.

[0113] The root node in each node community updates its trusted state information. The root node in Figure 4 can refer to any root node in Figure 1. The root node of each node community in the system shown in Figure 1 can perform operations with reference to the root node in Figure 4, without being limited to the number of root nodes in the example in Figure 4.

[0114] S203. The child node updates the trusted status information and reports it level by level.

[0115] Each child node in a node community updates its trusted state information. The child nodes in Figure 4 can refer to any one of the child nodes in Figure 1. The child nodes of each node community in the system shown in Figure 1 can perform operations with reference to the child nodes in Figure 4, without being limited to the number of child nodes in the example in Figure 4.

[0116] For example, Figure 5 is an example diagram of the trusted state of each node in node group A provided in an embodiment of this application. In node group A, the root node can access the remote service node via 4G or 5G, and each child node in node group A can access other local nodes (including the root node and other child nodes) via Bluetooth, Wireless Fidelity (WIFI), 4G or 5G, etc. If child node 2 in node group A is currently an authenticated trusted node, taking child nodes 1, 2, 3, and 4 as examples, child node 2 has not experienced a risk event, so after the update, it remains a trusted node, and its trusted state information still indicates trustworthiness. Since child node 1 accesses child node 2, child node 1 initiates an authentication request to child node 2. As a trusted node, child node 2 stores risk control service content and can perform risk identification. If child node 2 determines there is no risk based on the authentication request sent by child node 1 and the saved risk control service content, then child node 1's authentication is successful. If child node 2 determines there is risk based on the authentication request sent by child node 1 and the saved risk control service content, then child node 1's authentication fails. If child node 2 cannot determine whether there is risk based on the authentication request sent by child node 1 and the saved risk control service content, then child node 1's authentication is invalid. Child node 2 sends the authentication result back to child node 1. If authentication is successful, child node 1 becomes a trusted node; if authentication fails, child node 1 becomes an untrusted node; if authentication is invalid, child node 1 remains in its current state. The connection between child node 3 and child node 4 follows the example above. Assuming that after authentication, the trusted states of each node in the current node community A are as shown in Figure 5, child node 1 failed authentication and is an untrusted node, child node 3 remains a normal node despite invalid authentication, and child nodes 2 and 4 remain trusted nodes, etc. After updating the trusted state, child node 1 can report its own trusted state information (i.e., untrusted) to child node 2; child node 2 reports its own trusted state information and child node 1's trusted state information to the root node; child node 3 can report its own trusted state information (i.e., normal) to child node 4; child node 4 reports its own trusted state information and child node 3's trusted state information to the root node, and so on; the root node obtains the current trusted state information of each child node in node community A.

[0117] Optionally, after a node (including the root node and child nodes) updates its trusted state information to untrusted, it is necessary to determine whether the node includes downstream child nodes. If so, all downstream child nodes of that node are set as untrusted nodes. For example, if the root node of node community A is an untrusted node, the remote service node or the root node can set all child nodes in node community A as untrusted nodes. If child node 2 is an untrusted node, the remote service node or the root node can set its downstream child node 1 as an untrusted node. If child node 1 is an untrusted node but has no downstream nodes, then other nodes do not need to be set as untrusted nodes. For example, referring to Figure 6, if the root node in node community D is an untrusted node, then all its downstream nodes are set as untrusted nodes. The root node in node community D receives the node state information of each child node that is gradually reported. Since the root node is an untrusted node, it reports all downstream nodes as untrusted nodes. Alternatively, if the remote service node receives a report that the root node in node community D is an untrusted node, then regardless of the actual trusted node information of each reported child node, all nodes in node community D are considered untrusted nodes.

[0118] After S202 and S203, execute S204.

[0119] S204. If the root node collects the trusted status information of N child nodes, then determine the number of trusted nodes and the value of N.

[0120] The process checks if N is greater than a second preset threshold. N is the total number of nodes in the node community to which the root node belongs, and N is a positive integer greater than 2. Each root node can set a second preset threshold based on its processing capacity. If N > the second preset threshold, then execute S205; if N ≤ the second preset threshold, then execute S208. For example, if a root node can process the trusted status of 6 child nodes (including calculating the number of trusted nodes by their trusted status information, updating downstream nodes of untrusted nodes to untrusted nodes, etc.), then the second preset threshold can be set to 6. Referring to the root node of node community A in Figure 1, it receives trusted status information reported layer by layer from 10 child nodes. That is, N = 10, which is greater than the second preset threshold, so execute S205. Referring to the root node of node community D in Figure 1, it receives trusted status information reported layer by layer from 4 child nodes. That is, N = 4, which is less than the second preset threshold, so execute S208.

[0121] S205. The root node reports a set of trusted state information to the remote service node. Each set of trusted state information includes the trusted state information of each node in the node community to which the corresponding root node belongs.

[0122] S206. The remote service node obtains the number of trusted nodes in each node community based on the trusted state information set.

[0123] S207. The remote service node determines the node group as the first risk behavior group or a trusted group based on the number of trusted nodes in each node group and the pre-stored first preset threshold.

[0124] Determining whether a node group is a primary risk behavior group or a trusted group can be done by referring to the method in S102, which will not be repeated here.

[0125] S208. The root node obtains the number of trusted nodes in its node community based on the trusted state information set.

[0126] S209. The root node determines whether its node group is a first risk behavior group or a trusted group based on the number of trusted nodes in its node group and a first preset threshold. Optionally, if the proportion of trusted nodes in the node group to which the root node belongs is greater than the first preset threshold, then the node group is determined to be a trusted group; if the proportion of trusted nodes in the node group to which the root node belongs is not greater than the first preset threshold, then...

[0127] Referring to Figure 1, in node groups B, C, D, and E, after the root node's judgment, N is less than the second preset threshold. The root node in each node group obtains the number of trusted nodes in its respective node group. The root node determines whether a node group is a first risk behavior group or a trusted group based on the number of trusted nodes in its node group and the first preset threshold. Taking a first preset threshold of 50% trusted nodes as an example, the example in S102 can be referred to for the first preset threshold of quantity, which will not be elaborated further. Node group B has 4 nodes, including 1 root node and 3 child nodes, all of which are trusted nodes, thus accounting for 100%, which is greater than the first preset threshold. Node group B is a trusted group. Node group C has 4 nodes, including 1 root node and 3 child nodes, with 1 trusted node, thus accounting for 25%, which is less than the first preset threshold. Node group C is a first-risk behavior group. Node group D has 4 nodes, including 1 root node and 3 child nodes, with 4 untrusted nodes, thus accounting for 0%, which is less than the first preset threshold. Node group D is a first-risk behavior group. Node group E has 4 nodes, including 1 root node and 3 child nodes, with 3 trusted nodes, thus accounting for 60%, which is greater than the first preset threshold. Node group E is a trusted group.

[0128] Optionally, after the root node determines that its node group is the first risk behavior group or a trusted group, it can also report a trusted message to the remote service node to inform the root node that its node group is the first risk behavior group or a trusted group. For example, the root node of node group B reports a trusted message to the remote service node to inform node group B that node group B is a trusted group; the root node of node group C reports a trusted message to the remote service node to inform node group C that node group C is the first risk behavior group; the root node of node group D reports a trusted message to the remote service node to inform node group D that node group D is the first risk behavior group; and the root node of node group E reports a trusted message to the remote service node to inform node group E that node group E is a trusted group.

[0129] Optionally, the root node may also report a trusted message to inform it of the number of trusted nodes in its node community. Alternatively, the root node may report a trusted message that, in addition to informing it that its node community is a trusted community, also informs it of the number of trusted nodes in its node community.

[0130] S209 is executed after S207 and S208.

[0131] S209, The remote service node obtains the group's first risk behavior identification results.

[0132] For example, a remote service node can determine, through its own node and the root node, whether each node group is identified as the first risky behavior group through steps S207 and S208. Then, based on the trusted messages reported by each root node after steps S208 and S209, it can determine that node group B is a trusted group, node group C is the first risky behavior group, node group D is the first risky behavior group, and node group E is a trusted group. After obtaining the identification results, the first risky behavior group identification process ends.

[0133] Optionally, remote service nodes and root nodes can take further action based on whether each node group is a first-risk behavior group, such as ceasing to send data to the first-risk behavior group or rejecting business requests from the first-risk behavior group.

[0134] In this embodiment, risk control is achieved by initiating the identification of a first-risk behavior group. This identification is based on the identities already obtained by different nodes in the local network, such as trusted nodes, ordinary nodes, and untrusted nodes, to identify the group's first-risk behavior. This differs from industry-standard techniques like graph computing, knowledge graphs, and community mining. Therefore, it significantly simplifies computational complexity, increases the possibility of real-time identification, and eliminates the need for abundant user data. This allows for simple and efficient identification of first-risk behavior groups, providing a more secure, real-time, and efficient risk control service.

[0135] In addition to the remote service nodes being able to identify the group's first risk behavior, the root node in each node group also has the ability to identify the group's first risk behavior. Once the remote service node fails, the root node can also be used to identify the group's first risk behavior, which greatly enhances the fault tolerance of the risk control service.

[0136] Figure 7 is a fourth flowchart illustrating a risk control method provided in an embodiment of this application. As shown in Figure 7, the method is applied to the root node and includes:

[0137] S301. The root node collects the trusted state information of each node in its node community.

[0138] S302. The root node reports trusted status information to the remote service node so that the remote service node can determine the corresponding node group as a risk group or a trusted group based on the number of trusted nodes and a first preset threshold. The trusted status information is stored by each node and reported by each child node level by level.

[0139] The trusted state information of the root node is stored by the root node itself, and the trusted state information of other child nodes in the node community to which the root node belongs is reported by each child node level by level.

[0140] Optionally, after the root node collects the trusted status information of each node in its node community, it further includes: determining the number of trusted nodes based on the collected trusted status information of each node in its node community; reporting the trusted status information to the remote service node includes: if the total number of nodes in its node community is greater than a pre-stored second preset threshold, then the collected trusted status information of each node is used as a trusted status information set and reported to the remote service node.

[0141] Optionally, the root node determines the number of trusted nodes based on the trusted status information of each node in its node group; if the total number of nodes in its node group is not greater than a pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in its node group and the pre-stored first preset threshold; and reports a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message used to indicate whether the node group to which the root node belongs is a risk group or a trusted group.

[0142] The root node can report the collected trusted status information to the remote service node, the number of trusted nodes to the remote service node, and whether the node group it belongs to is a risky group to the remote service node.

[0143] Optionally, determining whether a node group is a risk group or a trusted group based on the number of trusted nodes in the node group and a pre-stored first preset threshold includes: if the proportion of trusted nodes in the node group is greater than the first preset threshold, then the node group is determined to be a trusted group; if the proportion of trusted nodes in the node group is not greater than the first preset threshold, then the node group is determined to be a risk group.

[0144] Optionally, the triggering conditions for reporting trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0145] Optionally, the method further includes: if the root node determines a node as an untrusted node, then all downstream nodes of the untrusted node are determined as untrusted nodes.

[0146] The risk control method executed by the root node in this application embodiment can be implemented with reference to the example in Figure 4 and the above embodiment, and will not be described in detail here.

[0147] Figure 8 is a fifth flowchart illustrating a risk control method provided in an embodiment of this application. As shown in Figure 8, the method is applied to a sub-node and includes:

[0148] S401. Sub-nodes report the stored trusted status information level by level. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node can determine whether the node group to which the sub-node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to the node that is directly connected to the remote service node in each node group connected to the remote service node.

[0149] The risk control method for child nodes in this application embodiment can be implemented with reference to the example in Figure 4 and the above embodiment, and will not be described in detail here.

[0150] Figure 9 is a schematic diagram of the structure of a remote service node provided in an embodiment of this application. As shown in Figure 9, the remote service node 10 includes a transceiver module 101 and a risk group identification module 102.

[0151] The transceiver module 101 is used to obtain the number of trusted nodes in at least one node community connected to the remote service node, wherein the node community includes multiple nodes, and whether each node is a trusted node is determined according to the trusted state information stored by the node.

[0152] The risk group identification module 102 is used to determine whether each node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

[0153] In one possible implementation, the transceiver module 101 is specifically used to receive the trusted state information set reported by each root node. The trusted state information set reported by each root node includes the trusted state information of each node in its node community. The root node refers to the node in each node community that directly accesses the remote service node. The risk community identification module 102 is specifically used to determine the number of trusted nodes in the node community according to each trusted state information set.

[0154] In one possible implementation, the transceiver module 101 is further configured to receive a trusted message reported by the root node, wherein the trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate whether the node community to which the root node belongs is a risky community or a trusted community; the risky community identification module 102 is further configured to determine whether the node community to which the root node belongs is a risky community or a trusted community based on the trusted message reported by the root node.

[0155] In one possible implementation, the risk group identification module 102 is specifically used to determine a node group as a trusted group if the proportion of trusted nodes in a node group is greater than a first preset threshold; and to determine a node group as a risk group if the proportion of trusted nodes in a node group is not greater than the first preset threshold.

[0156] In one possible implementation, the triggering condition for the transceiver module 101 to obtain the number of trusted nodes in at least one node community connected to the remote service node includes one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0157] In one possible implementation, the risk group identification module 102 is further configured to identify all downstream nodes of the untrusted node as untrusted nodes if a node is determined to be an untrusted node.

[0158] It should be understood that the modules shown in Figure 9 are merely examples. The transceiver module 101 and the risk group identification module 102 can perform their operations with reference to the method section of the embodiments of this application, or perform variations thereof. The remote service node 10 may also include other modules, such as a risk control module for storing risk control service content, a network module that supports network connectivity, etc., and is not limited to the examples in this embodiment.

[0159] Figure 10 is a schematic diagram of the structure of a root node provided in an embodiment of this application. As shown in Figure 10, the root node 20 includes a transceiver module 201 and a risk group identification module 202.

[0160] Root node 20 refers to the node in each node group connected to the remote service node that is directly connected to the remote service node, as shown in Figure 1, Figure 5 or Figure 6, which is the node directly connected to the remote service node 10.

[0161] The risk group identification module 202 is used to collect the trust status information of each node in the node group to which it belongs. The trust status information is stored by each node and reported by each child node level by level.

[0162] The transceiver module 101 is used to report trusted status information to the remote service node, so that the remote service node can determine the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determine whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0163] In one possible implementation, the risk group identification module 202 is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of nodes in the node group to which it belongs is greater than a pre-stored second preset threshold, the trusted status information of each node collected is used as a trusted status information set. The transceiver module 201 is also used to report the trusted status information set to the remote service node.

[0164] In one possible implementation, the risk group identification module 202 is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of nodes in the node group to which it belongs is not greater than a pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the pre-stored first preset threshold. The transceiver module 201 is also used to report trusted messages to remote service nodes. The trusted messages include the number of trusted nodes in the node group, or the trusted messages are used to indicate whether the node group to which the root node belongs is a risk group or a trusted group.

[0165] In one possible implementation, the risk group identification module 202 is specifically used to determine a node group as a trusted group if the proportion of trusted nodes in the node group is greater than a first preset threshold; and to determine a node group as a risk group if the proportion of trusted nodes in the node group is not greater than the first preset threshold.

[0166] In one possible implementation, the triggering conditions for the transceiver module 201 to report trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0167] In one possible implementation, the risk group identification module 202 is further configured to identify all downstream nodes of the untrusted node as untrusted nodes if a node is determined to be an untrusted node.

[0168] It should be understood that the modules shown in Figure 10 are merely examples. The transceiver module 201 and the risk group identification module 202 can perform their operations with reference to the method section of the embodiments of this application, or perform variations thereof. The root node 20 may also include other modules, such as a risk control management module for storing risk control service content, a network module that supports network connectivity, a trusted state management module, a risk control module update module, etc. Alternatively, the risk control management module of the root node 20 may include a risk group identification module, etc., without limiting the scope to the examples in this embodiment.

[0169] Figure 11 is a schematic diagram of the structure of a sub-node provided in an embodiment of this application. As shown in Figure 11, the sub-node 30 includes a transceiver module 301 and a processing module 302.

[0170] The transceiver module 301 is used to report the stored trusted status information level by level. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node can determine whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to the node that is directly connected to the remote service node in each node group connected to the remote service node.

[0171] Storage module 302 is used to perform operations other than sending and receiving, such as storing trusted state information.

[0172] In one possible implementation, the triggering conditions for the transceiver module 301 to report trusted status information include one or two of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0173] It should be understood that the modules shown in Figure 11 are merely examples. The transceiver module 301 can perform its operations with reference to the method section of the embodiments of this application, or perform variations thereof. The sub-node 30 may also include other modules to implement other functions. Taking the example of Figure 11, the sub-node 30 may also include a risk control management module for storing risk control service content, a network module that supports network connectivity, a trusted status management module, a risk control module update module, etc., without limiting the scope to the examples in this embodiment.

[0174] Furthermore, this application embodiment also provides a first device 40, as shown in FIG12, which is a structural schematic diagram of the first device 40 according to an embodiment of this application. The first device 40 includes a communication interface 401 and a processor 402 connected to the communication interface 401. The communication interface 401 may be a transceiver or similar device. The communication interface 401 may be used to perform the operations of the transmission and reception portion in the above embodiments, and the processor 402 may be used for operations other than transmission and reception. For example, the communication interface 401 may be used to obtain the number of trusted nodes in at least one node group connected to a remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined according to the trusted status information stored by the node; the processor 402 may be used to determine whether the node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

[0175] This application embodiment also provides a second device 50, as shown in FIG13, which is a structural schematic diagram of the second device 50 according to an embodiment of this application. The second device 50 includes a communication interface 501 and a processor 502 connected to the communication interface 501. The communication interface 501 can be a transceiver or similar device. The communication interface 501 can be used to perform the transmission and reception operations in the methods of the above embodiments, and the processor 502 can be used for operations other than transmission and reception. For example, the processor 502 can be used to collect the trusted status information of each node in its node community, wherein the trusted status information is stored by each node and reported by each child node level by level. The communication interface 501 reports the trusted status information to the remote service node, so that the remote service node can determine the number of trusted nodes in the node community to which the root node belongs based on the trusted status information, and determine whether the node community to which the root node belongs is a risky community or a trusted community based on the number of trusted nodes and a pre-stored first preset threshold.

[0176] This application embodiment also provides a third device 60, as shown in FIG14, which is a structural schematic diagram of the third device 60 according to an embodiment of this application. The third device 60 includes a communication interface 601 and a processor 602 connected to the communication interface 601. The communication interface 601 can be a transceiver or similar device. The communication interface 601 can be used to perform the transmission and reception operations in the methods of the above embodiments. The processor 602 can be used for operations other than transmission and reception. For example, the communication interface 601 can be used to report stored trusted status information level by level. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node can determine the node group to which the child node belongs as a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to the node in each node group connected to the remote service node that is directly connected to the remote service node.

[0177] Furthermore, this application embodiment also provides a device 70, as shown in Figure 15, which is a structural schematic diagram of a device 70 provided in this application embodiment. As shown in Figure 12, device 70 may include a processor 701, a memory 702 coupled to the processor 701, and a transceiver 703. The transceiver 703 may be a communication interface, an optical module, etc., used for sending and receiving data, etc. The processor 701 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP, used to execute the forwarding processing related steps in the device exemplified in the above embodiments. The processor may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. Processor 701 may refer to a single processor or may include multiple processors. Memory 702 may include volatile memory, such as random-access memory (RAM); it may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); Memory 702 may also include combinations of the above types of memory. Memory 702 may refer to a single memory or may include multiple memories for storing program instructions. In one embodiment, memory 702 stores computer-readable instructions, which include multiple software modules, such as a sending module, a processing module, and a receiving module. After executing each software module, processor 701 can perform corresponding operations according to the instructions of each software module. In this embodiment, the operation performed by a software module actually refers to the operation performed by processor 701 according to the instructions of the software module. Optionally, the processor 701 may also store program code or instructions for executing the scheme of the embodiments of this application. In this case, the processor 701 does not need to read program code or instructions from the memory 702.

[0178] The device 70 can be used to perform the methods described in the above embodiments. Specifically, the device 70 can be used as...

[0179] The terminal node executes the operations performed by the remote service node in methods S101 to S102 and S201 to S209, or executes the operations performed by the root node in methods S201 to S209 and S301 to S302 as the root node, or the remote service node executes the operations performed by the child node in methods S201 to S209 and S401.

[0180] This application also provides a computer-readable storage medium storing instructions that, when executed on a processor, implement some or all of the operations in any of the methods in any of the foregoing embodiments.

[0181] This application also provides a computer program product, including a computer program that, when run on a processor, implements some or all of the operations in any method of any of the foregoing embodiments.

[0182] This application also provides a risk control system. Referring to Figure 16, which is a schematic diagram of another risk control system provided in this application, the risk control system 200 may include a remote service node, at least one root node, and at least one child node. Figure 16 uses system 3 as an example, including a remote service node 10, a root node 20, and a child node 30. The structure of the remote service node 10 is shown in Figures 9, 12, and 15; the structure of the root node 20 is shown in Figures 10, 13, and 15; and the structure of the child node 30 is shown in Figures 11, 14, and 15. System 200 can perform its operations, or variations thereof, with reference to the method portions of the embodiments of this application. For example, it can be applied to the methods provided in Figures 2, 3, 4, and 7-8, performing their operations, or variations thereof.

[0183] In some instances, a risk control system is an information system that can be composed of any combination of hardware and software.

[0184] This application also provides another risk control system, including at least one memory and at least one processor. The at least one memory stores instructions, and the at least one processor executes the instructions, causing the communication system to perform some or all of the operations in any of the methods in any of the foregoing embodiments.

[0185] This application also provides a chip, including an interface circuit and a processor. The interface circuit and the processor are connected, and the processor is used to cause the chip to perform some or all of the operations in any of the methods in any of the foregoing embodiments.

[0186] This application also provides a chip system, including: a processor coupled to a memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, the chip system enables the chip system to perform some or all of the operations in any one of the methods in any of the foregoing embodiments.

[0187] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0188] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0189] For example, the chip system can be an FPGA, an ASIC, a system-on-chip (SoC), a CPU, an NP, a digital signal processing circuit (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0190] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0191] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0192] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical business division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0193] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0194] Furthermore, the various business units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software business unit.

[0195] If the integrated unit is implemented as a software business unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, Random Access Memory, magnetic disks, or optical disks.

[0196] Those skilled in the art will recognize that, in one or more of the examples above, the services described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0197] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of this application.

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

Claims

1. A risk control method, characterized in that, Applied to remote service nodes, the method includes: Obtain the number of trusted nodes in at least one node community connected to the remote service node, wherein the node community includes multiple nodes, and whether each node is a trusted node is determined based on the trusted status information stored by the node. Based on the number of trusted nodes in each node group and a pre-stored first preset threshold, each node group is determined to be either a risk group or a trusted group.

2. The method according to claim 1, characterized in that, The step of obtaining the number of trusted nodes in at least one node community connected to the remote service node includes: Receive a set of trusted status information reported by each root node. The set of trusted status information reported by each root node includes the trusted status information of each node in its node community. The root node refers to the node in each node community that is directly connected to the remote service node. The number of trusted nodes in the node community is determined according to each set of trusted state information.

3. The method according to claim 1 or 2, characterized in that, Also includes: Receive trusted messages reported by the root node, wherein the trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate whether the node community to which the root node belongs is a risky community or a trusted community. Based on the trusted messages reported by the root node, the node community to which the root node belongs is determined to be either a risky community or a trusted community.

4. The method according to any one of claims 1 to 3, characterized in that, The step of determining whether a node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a first preset threshold includes: If the proportion of trusted nodes in a node group is greater than the first preset threshold, then the node group is determined to be a trusted group. If the proportion of trusted nodes in a node group is not greater than the first preset threshold, then the node group is determined to be a risk group.

5. The method according to any one of claims 1 to 4, characterized in that, The triggering conditions for obtaining the number of trusted nodes in at least one node community connected to the remote service node include one or both of the following: Triggered by a risk control event, or triggered at a preset time interval.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: If a node is determined to be an untrusted node, then all downstream nodes of the untrusted node are determined to be untrusted nodes.

7. A risk control method, characterized in that, Applied to root nodes, where a root node refers to a node in a node community directly connected to the remote service node, the method includes: Collect trusted status information of each node in the node community, wherein the trusted status information is stored by each node and reported by each child node level by level; The trusted status information is reported to the remote service node so that the remote service node can determine the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determine whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

8. The method according to claim 7, characterized in that, After collecting the trusted state information of each node in the node community, the method further includes: Based on the trusted status information of each node in the node community, the number of trusted nodes is determined. The reporting of the trusted status information to the remote service node includes: If the total number of nodes in the node group is greater than the second preset threshold, the collected trusted state information of each node will be used as a trusted state information set and reported to the remote service node.

9. The method according to claim 7, characterized in that, Also includes: Based on the trusted status information of each node in the node community, the number of trusted nodes is determined. If the total number of nodes in the node group to which it belongs is not greater than the pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the pre-stored first preset threshold. The trusted message is reported to the remote service node. The trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate whether the node community to which the root node belongs is a risky community or a trusted community.

10. The method according to claim 9, characterized in that, The step of determining whether a node group is a risk group or a trusted group based on the number of trusted nodes in the node group and a pre-stored first preset threshold includes: If the proportion of trusted nodes in the node group is greater than the first preset threshold, then the node group is determined to be a trusted group. If the proportion of trusted nodes in the node group to which the node belongs is not greater than the first preset threshold, then the node group is determined to be a risk group.

11. The method according to any one of claims 7 to 10, characterized in that, The triggering conditions for reporting the trusted status information include one or both of the following: Triggered by a risk control event, or triggered at a preset time interval.

12. The method according to any one of claims 7 to 11, characterized in that, Also includes: If a node is determined to be an untrusted node, then all downstream nodes of the untrusted node are determined to be untrusted nodes.

13. A risk control method, characterized in that, Applied to child nodes, where a child node refers to a node in a node community connected to the remote service node that is indirectly connected to the remote service node, the method includes: The trusted status information is reported level by level. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node can determine whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to the node that is directly connected to the remote service node in each node group connected to the remote service node.

14. The method according to claim 13, characterized in that, The triggering conditions for reporting the trusted status information include one or both of the following: Triggered by a risk control event, or triggered at a preset time interval.

15. A remote service node, characterized in that, include: The transceiver module is used to obtain the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on the trusted status information stored by the node. The risk group identification module is used to determine whether each node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

16. The node according to claim 15, characterized in that, The transceiver module is specifically used to receive a set of trusted status information reported by each root node. The set of trusted status information reported by each root node includes the trusted status information of each node in its node community. The root node refers to the node in each node community that is directly connected to the remote service node. The risk group identification module is specifically used to determine the number of trusted nodes in the node group according to each trusted state information set.

17. The node according to claim 15 or 16, characterized in that, The transceiver module is also used to receive trusted messages reported by the root node, wherein the trusted message includes the number of trusted nodes in the node community, or the trusted message is used to indicate whether the node community to which the root node belongs is a risky community or a trusted community. The risk group identification module is also used to determine whether the node group to which the root node belongs is a risk group or a trusted group based on the trusted messages reported by the root node.

18. The node according to any one of claims 15 to 17, characterized in that, The risk group identification module is specifically used to determine a node group as a trusted group if the proportion of trusted nodes in a node group is greater than the first preset threshold; and to determine a node group as a risk group if the proportion of trusted nodes in a node group is not greater than the first preset threshold.

19. The node according to any one of claims 15 to 18, characterized in that, The triggering conditions for the transceiver module to obtain the number of trusted nodes in at least one node community connected to the remote service node include one or both of the following: Triggered by a risk control event, or triggered at a preset time interval.

20. The node according to any one of claims 15 to 19, characterized in that, The risk group identification module is further configured to, if a node is determined to be an untrusted node, identify all downstream nodes of the untrusted node as untrusted nodes.

21. A root node, characterized in that, The root node refers to the node directly connected to the remote service node within each node group connected to the remote service node. The root node includes: The risk group identification module is used to collect the trust status information of each node in the node group to which it belongs. The trust status information is stored by each node and reported by each child node level by level. The transceiver module is used to report the trusted status information to the remote service node, so that the remote service node can determine the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determine whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

22. The node according to claim 21, characterized in that, The risk group identification module is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of each node in the node group to which it belongs is greater than a pre-stored second preset threshold, then the trusted status information of each node collected is used as a trusted status information set. The transceiver module is also used to report the trusted status information set to the remote service node.

23. The node according to claim 21, characterized in that, The risk group identification module is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of each node in the node group to which it belongs is not greater than the second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the first preset threshold. The transceiver module is also used to report trusted messages to the remote service node. The trusted messages include the number of trusted nodes in the node community, or the trusted messages are used to indicate whether the node community to which the root node belongs is a risky community or a trusted community.

24. The node according to claim 23, characterized in that, The risk group identification module is specifically used to determine a node group as a trusted group if the proportion of trusted nodes in the node group is greater than the first preset threshold; and to determine a node group as a risk group if the proportion of trusted nodes in the node group is not greater than the first preset threshold.

25. The node according to any one of claims 21 to 24, characterized in that, The triggering conditions for the transceiver module to report the trusted status information include one or two of the following: Triggered by a risk control event, or triggered at a preset time interval.

26. The node according to any one of claims 21 to 25, characterized in that, The risk group identification module is further configured to, if a node is determined to be an untrusted node, identify all downstream nodes of the untrusted node as untrusted nodes.

27. A child node, characterized in that, The child node refers to a node in each node group connected to the remote service node that is indirectly connected to the remote service node. The child node includes: The transceiver module is used to report the stored trusted status information level by level. The trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node can determine whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to the node that is directly connected to the remote service node in each node group connected to the remote service node.

28. The node according to claim 27, characterized in that, The triggering conditions for the transceiver module to report the trusted status information include one or two of the following: Triggered by a risk control event, or triggered at a preset time interval.

29. A risk control system, characterized in that, include: A remote service node, used to implement the method described in any one of claims 1 to 6 above; At least one root node is used to implement the method described in any one of claims 7 to 12 above; At least one child node is used to implement the method described in claim 13 or 14 above.

Images