An adaptive risk protection method and system for smart home device control

Abstract

The application discloses a kind of self-adapting risk protection method and system of smart home equipment control, and relates to the technical field of smart home security.The method comprises the following steps: receiving the device control request of control end and extracting context information;Determine the risk analysis module to be called through decision scheduling module;Each risk analysis module carries out risk scoring;Comprehensive scoring engine carries out weighted aggregation and risk amplification to each risk score, and gives comprehensive risk score;According to the comprehensive risk score, the safety policy is executed on the device control request, including release, secondary authentication or interception operation;Finally, the device control request released by terminal is executed.The application realizes multi-dimensional dynamic risk assessment, and improves the security of smart home equipment control.

Description

Technical Field

[0001] This invention relates to the field of smart home security technology, specifically to an adaptive risk protection method and system for controlling smart home devices. Background Technology

[0002] With the increasing prevalence of smart home devices, more and more home appliances such as door locks, cameras, lights, and air conditioners are being centrally managed through a unified platform. Users typically control these devices via mobile apps, automation rules, or third-party platforms, and can also share device permissions with family members or visitors. As the number of devices and control methods increase, security issues related to device control are gradually gaining attention, especially in scenarios involving home security and privacy.

[0003] In existing technologies, security protection for device control mainly relies on static access control or fixed authentication policies, which are insufficient to address dynamic risk scenarios such as complex control sources, improper use of permissions, account theft, and accidental operations. Therefore, a method capable of comprehensively assessing dynamic risks using multi-dimensional information is needed. Summary of the Invention

[0004] The purpose of this invention is to provide an adaptive risk protection method and system for controlling smart home devices. Through a multi-dimensional risk analysis module and a dynamic scheduling mechanism, it can achieve real-time and accurate risk assessment of device control requests, thus making up for the shortcomings of existing static permission control strategies.

[0005] To achieve the objective, the present invention provides the following technical solution: An adaptive risk protection method for controlling smart home devices includes the following steps: Step S1: Receive device control request and extract context information, including user identity, device type, control action, control source, and home security status; Step S2: Based on the above-mentioned device types, as well as preset scenario characteristics and configuration information, the decision scheduling module determines the risk analysis module that needs to be invoked for the above-mentioned device control request. Step S3: Call the risk analysis modules determined in Step S2 to perform risk scoring on the above device control requests; the risk analysis modules include: a context risk analysis module, used to match the extracted context information according to a preset risk configuration table and output a first risk score; a user behavior profile risk analysis module, used to calculate the deviation of the current operation based on the user's historical behavior data and output a second risk score; a sensor consistency risk analysis module, used to output a third risk score based on the consistency between the real-time status of the collaborative sensors and the control actions; and a risk list matching module, used to match risk lists based on one or more dimensions of users, devices, and IPs and output a fourth risk score. Step S4: The comprehensive scoring engine performs weighted aggregation and risk amplification on the various risk scores to generate a comprehensive risk score; Step S5: Execute the corresponding security policy for the device control request based on the above comprehensive risk score, including allowing, secondary authentication, or blocking operations.

[0006] Furthermore, the aforementioned context risk analysis module uses a multi-stage filtering and matching algorithm to perform step-by-step matching and downgrade strategies based on the attributes of the device control request and the context risk configuration table information, until the first risk score is output.

[0007] Furthermore, the aforementioned user behavior profile risk analysis module adopts a multi-level behavior profile structure, including user-level behavior profiles, family-level behavior profiles, and device-type-level behavior profiles. It then backtracks sequentially based on data sparsity to calculate the comprehensive deviation of operation time, operation frequency, login device, login IP, geographical location, and operation type, and maps it to a second risk score.

[0008] Furthermore, the aforementioned sensor consistency risk analysis module obtains real-time sensor data from the cache through a pre-configured device-cooperative sensor relationship table, calls expressions to calculate the consistency score of each sensor, and weights and fuses them to obtain a comprehensive consistency score, which is then converted into a third risk score.

[0009] Furthermore, the aforementioned risk list matching module uses hash tables, Trie trees, and pre-compiled regular expressions for exact matching, IP segment matching, and regular expression matching, respectively. It also calculates a comprehensive deviation value based on the risk value and weight of the matched entries, which is ultimately mapped to a fourth risk score.

[0010] Furthermore, the aforementioned comprehensive scoring engine maps each risk score to a standard deviation and assigns weights, then aggregates positive and negative deviations respectively; it then calculates the total deviation based on the positive and negative aggregated values, and maps the total deviation to a comprehensive risk score.

[0011] A smart home system, comprising: The control terminal is used to initiate device control requests; The request receiving module is used to receive device control requests and extract context information; The decision scheduling module is used to determine the risk analysis module to be invoked for the current device control request based on the device type in the context information, as well as preset scenario features and configuration information. The aforementioned risk analysis modules include: a context risk analysis module, used to match extracted context information according to a preset risk configuration table and output a first risk score; a user behavior profile risk analysis module, used to calculate the deviation of the current operation based on the user's historical behavior data and output a second risk score; a sensor consistency risk analysis module, used to output a third risk score based on the consistency between the real-time status of the collaborative sensors and the control actions; and a risk list matching module, used to match risk lists based on one or more dimensions of users, devices, and IPs and output a fourth risk score. The comprehensive scoring engine is used to weight and aggregate various risk scores and amplify the risk to generate a comprehensive risk score. The strategy execution module is used to perform release, secondary authentication, or interception operations on device control requests based on the comprehensive risk score; The terminal is used to execute device control requests that have been permitted by the policy execution module.

[0012] Furthermore, it also includes a rule configuration management module, which is used to dynamically update the risk configuration table, behavior profile baseline, collaborative sensor configuration table, and risk list table.

[0013] Furthermore, the aforementioned user behavior profiling risk analysis module includes an offline computing unit and a real-time computing unit. Offline data is imported into the offline computing unit, which statistically analyzes various baseline parameters and periodically writes the results to a cache for use by the real-time computing unit.

[0014] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned adaptive risk protection method for controlling smart home devices.

[0015] Compared with the prior art, the present invention has the following advantages: Firstly, this invention receives device control requests and extracts multi-dimensional contextual information. The decision-making and scheduling module dynamically determines the risk analysis module to be invoked based on factors such as device type, enabling adaptive risk assessment for different control scenarios. Compared to traditional single or static protection strategies, this method can flexibly combine various analysis methods such as contextual analysis, user profiling, sensor consistency, and risk lists, significantly improving the ability to identify and protect against complex and dynamic risk scenarios while avoiding unnecessary waste of computational resources.

[0016] Secondly, the contextual risk analysis module in this invention employs a multi-stage filtering and matching algorithm to perform step-by-step matching and degradation strategies based on device type, control action, user identity, control source, and home security status. This design can still output a reasonable risk score even in cases of missing or incomplete configuration, improving the system's fault tolerance and robustness, and ensuring the continuity and availability of risk assessment under various edge scenarios.

[0017] Third, the user behavior profiling risk analysis module in this invention constructs a three-tiered behavior profile structure at the user, family, and device type levels, and automatically backtracks based on data sparsity. This mechanism effectively solves the problem of establishing a behavior baseline for new users or in scenarios with sparse data, ensuring the universality and accuracy of risk assessment. Furthermore, by combining offline pre-computation with real-time caching, it achieves low-latency risk judgment.

[0018] Fourth, the sensor consistency risk analysis module in this invention uses a pre-configured device-cooperative sensor relationship table and real-time sensor data to quickly assess the consistency between the environmental state and the control intent before device control. This module relies solely on cached data for expression calculation, avoiding database access latency and enabling assessment within milliseconds, effectively preventing security risks caused by environmental anomalies or device malfunctions.

[0019] Fifth, the risk list matching module in this invention integrates three data structures: hash tables, Trie trees, and pre-compiled regular expressions, supporting exact matching, IP segment matching, and regular expression matching, respectively. This multi-dimensional and efficient matching mechanism can quickly hit various risk list entries and generate a comprehensive score through positive and negative deviation accumulation and balancing algorithms, significantly improving the speed and accuracy of identifying known risk sources (such as blacklisted IPs and malicious devices).

[0020] Sixth, this invention uses a comprehensive scoring engine to weight and aggregate various risk scores, and introduces a mechanism for separating positive and negative deviations in aggregation and a risk amplification process. This design not only integrates multi-dimensional risk information, but also amplifies the total risk value when multiple high-risk factors occur simultaneously, or reduces the risk value when multiple reliable factors are at work. This makes the final comprehensive risk score more sensitive and accurate, providing a reliable basis for subsequent release, secondary authentication, or interception strategies.

[0021] Seventh, this invention also provides a corresponding smart home system, including a control terminal, a request receiving module, a decision scheduling module, multiple risk analysis modules, a comprehensive scoring engine, a strategy execution module, and a terminal, and supports dynamic updates of various configuration tables through a rule configuration management module. This system has a clear architecture, decoupled modules, and flexible configuration, enabling it to quickly adapt to new device access and new risk scenarios, and possesses good scalability and maintainability. Attached Figure Description

[0022] Figure 1 This is a flowchart of the adaptive risk protection method for controlling smart home devices in this invention.

[0023] Figure 2 This is a structural block diagram of the smart home system in this invention. Detailed Implementation

[0024] Specific embodiments of the present invention will now be described with reference to the accompanying drawings. Many details are described below to provide a comprehensive understanding of the invention; however, those skilled in the art will be able to implement the invention without these details.

[0025] like Figure 1 and Figure 2 As shown, an adaptive risk protection method for controlling smart home devices includes the following steps: Step S1: Receive device control request and extract context information, including user identity, device type, control action, control source, and home security status; Step S2: The decision-making and scheduling module determines the risk analysis module that needs to be invoked for the aforementioned device control request, based on the device type, preset scenario characteristics, and configuration information. This module can reduce unnecessary calls to the scoring sub-modules in advance, improving efficiency.

[0026] Step S3: Call the risk analysis modules determined in step S2 to perform risk scoring on the above-mentioned equipment control requests.

[0027] The risk analysis module includes a context risk analysis module, a user behavior profiling risk analysis module, a sensor consistency risk analysis module, and a risk list matching module. The context risk analysis module matches extracted context information against a pre-defined context risk configuration table and outputs a first risk score. The user behavior profiling risk analysis module calculates the deviation of the current operation based on historical user behavior data and outputs a second risk score. The sensor consistency risk analysis module outputs a third risk score based on the consistency between the real-time status of the coordinating sensors and the control actions. The risk list matching module matches a risk list based on one or more dimensions of user, device, and IP, and outputs a fourth risk score.

[0028] In one specific embodiment, the risk factor configuration table is as follows:

[0029] Step S4: Use a comprehensive scoring engine to weight and aggregate the various risk scores and amplify the risk to generate a comprehensive risk score.

[0030] Step S5: Execute the corresponding security policy for the device control request based on the above comprehensive risk score, including allowing, secondary authentication, or blocking operations.

[0031] In one specific embodiment, the context risk analysis module uses a multi-stage filtering and matching algorithm to perform step-by-step matching and degradation strategies based on the attributes of the device control request and the context risk configuration table information, and outputs a first risk score.

[0032] More specifically, the contextual risk analysis module uses contextual factors that integrate information from the following dimensions: Equipment types: door locks, cameras, etc.

[0033] Control actions: unlocking, air conditioning cooling, etc.

[0034] User identities include: owner, member, child, visitor, etc.

[0035] Sources of control: local, remote, third-party API, automation, etc.

[0036] Home security status: Armed at home, Armed when away, Disarmed, Custom, etc.

[0037] To achieve low latency and high scalability, the adaptive risk protection system pre-builds a multi-dimensional context risk configuration table, whose core configuration items are as follows:

[0038] The context risk configuration table is stored on the data platform, loaded into the cache, and dynamically updated.

[0039] The specific process by which the contextual risk analysis module calculates and outputs the first risk score using the aforementioned contextual factors is as follows: (1.1) Preliminary matching of equipment type and control action action identifier The context risk analysis module performs a preliminary screening of the context risk configuration table based on the device type (device_type) and action identifier (action_id) in the device control request, and obtains a set of candidate records.

[0040] This step ensures that subsequent calculations are performed only on the set of device operations relevant to the request, improving efficiency.

[0041] (1.2) Filtering of motion parameters for controlling actions The candidate records are further verified by matching against the action parameters (action_param_name). If parameter matching rules (such as regular expressions) are configured, the context risk analysis module verifies the action parameters in the device control request; if no parameter rules are configured, this step is passed by default.

[0042] (1.3) Precise matching of context attributes Among the candidate records filtered by action parameters, the context risk analysis module performs precise matching based on the following configuration table fields: User identity (user_role): the identity type of the request initiator, such as owner, family member, visitor, etc.; Control source (control_source): the request initiation method, such as local APP, remote API, smart linkage, scheduled task, etc.; Home security status (security_mode): the current armed status of the home, such as disarmed, home armed, away armed, custom armed.

[0043] If a record is found to be a perfect match, the basic risk score of that record will be used as the first risk score output.

[0044] (1.4) Multi-level degradation matching strategy If no exact match is found, the contextual risk analysis module performs a downgraded matching for the dimension. The downgraded matching rules include, but are not limited to: Degradation layer 1: Security status is empty, only user identity and control source are matched; Degradation layer two: The control source is empty, and only user identity and security status are matched; Degradation level 3: User identity is empty, only control source and security status are matched; Degradation layer four: Security status and control source are empty; only user identity is matched. This downgrade matching rule ensures that a reasonable first risk score can still be output even when some configurations are missing or not configured, thus improving the fault tolerance rate.

[0045] (1.5) Device-level downgrade matching If the above step (1.4) still fails to find a record or does not fully match, the context risk analysis module relaxes the requirements for the device dimension, ignoring device type and action identifier, and only matching based on user identity, control source, and home security status. If there is still no matching record, the default is no risk.

[0046] (1.6) Output the first risk score After completing multi-stage matching and downgrade processing, the context risk analysis module outputs the final first risk score of the context factors.

[0047] In one specific embodiment, in order to quickly generate the configuration table and improve efficiency when a new device is connected to the system, the context risk analysis module also uses an AI model to assist in generating the aforementioned context risk configuration table, as detailed below: (a) Input items The rule generation process is based on the following inputs: the type of new device, the set of supported action identifiers, and the range of action parameters; historical device control logs and user behavior data of the system; and the historical distribution of home security status and control source dimensions.

[0048] (b) Feature construction Based on the type and actions of the new device, construct a multi-dimensional combined feature set: <Device type, action identifier, action parameters, action parameter values, whether it is a regular expression, user identity, control source, home security status>, i.e. <device_type,action_id,action_param_name,action_param_value,is_regex,user_role,control_source,security_mode> Simultaneously, the system generates default weights and initial scoring values, and calculates the initial risk probability distribution by combining historical data of similar devices.

[0049] (c) AI model generation rules A decision tree model is used to train and map historical data and multi-dimensional combined feature sets to generate a contextual risk configuration table record. Each record includes: <device type, action identifier, action parameters, action parameter value, whether it is a regular expression, user identity, control source, home security status, score>, i.e. <device_type,action_id,action_param_name,action_param_value,is_regex,user_role,control_source,security_mode,Score> The score reflects the basic risk rating of the new device under different user identities, control sources, and home security conditions.

[0050] (d) Post-expert review The AI-generated context risk configuration table is submitted to experts for manual review. The manual review includes: checking the reasonableness of the basic risk score to ensure that high-risk operations score highest in high-risk scenarios; verifying the correctness of the action parameter matching rules to avoid missing abnormal actions; reviewing whether there are any omissions or logical conflicts in the combined features to ensure the completeness of the rules; and fine-tuning the scoring weights based on expert experience to optimize the accuracy of the risk score.

[0051] Once the review is completed, the context risk configuration table confirmed by the experts becomes the final deployable configuration, and the system hot-updates it to the data platform cache.

[0052] (e) Rule optimization and iteration During the operation of new equipment, the system continuously collects equipment control requests and security alarm feedback, and periodically optimizes the context risk configuration table, including: adjusting the basic risk score to more accurately reflect the actual risk; adding or updating combined feature entries to cover missed scenarios; and updating action parameter matching rules to adapt to new equipment functions or firmware upgrades.

[0053] The optimized context risk configuration table is synchronized to the data platform through a cache hot update mechanism.

[0054] In one specific embodiment, the user behavior profile risk analysis module adopts a multi-level behavior profile structure, including user-level behavior profile, family-level behavior profile and device type-level behavior profile, and backtracks sequentially according to the data sparsity to calculate the comprehensive deviation of operation time, operation frequency, login device, login IP, geographical location and operation type and map it into a second risk score.

[0055] The key configuration items of the multi-level behavioral profile structure configuration table are as follows:

[0056] The process prioritizes user-level behavioral profiles. If a user's historical operation records are sufficient (e.g., the number of historical operation records exceeds the first threshold), the second risk score is calculated directly. If the user-level behavioral profile is insufficient (e.g., the number of historical operation records does not exceed the first threshold), the family-level behavioral profile is used to calculate the second risk score. Similarly, if the family profile is insufficient (e.g., the number of historical operation records for all family members does not exceed the second threshold), the device type-level general behavioral profile is used to calculate the second risk score, ensuring that a reasonable second risk score can still be output even when user or family-level behavioral profile data is sparse.

[0057] Following a step-back rule from user-level behavioral profiles to family-level behavioral profiles to device-type-level general behavioral profiles, the comprehensive deviation of operation time, operation frequency, login device, login IP, geographical location, and operation type is calculated and mapped to a second risk score. The specific process is as follows: (2.1) Calculation of deviation of operation time distribution The user behavior profiling risk analysis module maintains a 24-hour operation time distribution model for each user, using a sliding window to statistically analyze the average number of operations performed by the user within each time period, forming a stable time feature vector. When a user initiates a device control request, the module calculates the deviation in hours Δh between the current time and the user's commonly used time period center, and normalizes the result to the maximum deviation time Hmax, obtaining the deviation degree: Dt = Δh / Hmax; the larger the deviation value, the more abnormal the operation time. The module uses a memory-level histogram structure to maintain statistical information and updates it in real time using a moving average.

[0058] (2.2) Calculation of operating frequency deviation The user behavior profiling risk analysis module maintains a baseline for the operation frequency of each user and uses an exponentially weighted average (EMA) algorithm to dynamically smooth the number of operations per unit time. Let the number of operations in the current period (e.g., 5 minutes) be fc, the historical average operation frequency be fh, and the historical maximum and minimum operation frequencies be fmax and fmin, respectively. Then, the deviation calculation formula is: Df = min(1, |fc|h) fh∣ / (fmax This algorithm can reflect abnormal fluctuations in user operation frequency in real time, such as abnormally high-frequency operations, batch triggering, or long periods of inactivity. The user behavior profiling risk analysis module uses a fixed-length sliding window to maintain frequency information, with a computational complexity of O(1).

[0059] (2.3) Calculation of deviation of login device The system maintains a set of frequently used devices for each user, including device ID and device type. When a device control request arrives, the user behavior profile risk analysis module uses a hash matching mechanism to determine whether the current device belongs to the set of frequently used devices and calculates the deviation: if it is a complete match, the deviation Dd = 0; if it is a partial match (e.g., device type matches, but device ID does not match), the deviation Dd = 0.3; if it is a complete mismatch, the deviation Dd = 1. The device set is stored using a Bloom filter, which can complete the matching judgment in O(1) time complexity, and the false positive rate is controlled below 0.1%.

[0060] (2.4) Calculation of login IP deviation During long-term operation, the system statistically analyzes frequently used user login IPs to establish a baseline range of IP network segments and geographical regions. In device control requests, the user behavior profiling and risk analysis module quickly matches the current IP with the baseline range and calculates the deviation using an IP segment distance function. The system preloads an IP segment and geographical location mapping table and achieves rapid judgment through hash indexing and interval comparison, with a time complexity of O(1).

[0061] (2.5) Calculation of geographical location deviation When a control request carries geographic coordinate information, the user behavior profile risk analysis module calculates the deviation of the current location L_cur based on the user's historical persistent location L_mean. It then uses the Haversine formula (simplified to Earth's radius) to calculate the geographic distance and performs normalization: Dg=min(1,dist(L_cur,L_mean) / Lmax); where L_max is the system's preset maximum allowable offset distance. The system caches the persistent location coordinates of each user and performs real-time calculations using fast trigonometric functions.

[0062] (2.6) Calculation of Operation Type Deviation The system statistically analyzes the operation types of each user to form an operation distribution model. Let the current control request type be a_cur, and its probability of occurrence in historical operations be P_hist(a_cur). Then the deviation is defined as: Da = (1 Phist(acur)); when the user performs rare or high-risk actions (such as remotely unlocking or disabling security), the deviation of this item increases significantly. The system uses a hash table to store the probability distribution of operation types, and both query and update are O(1) operations.

[0063] (2.7) Calculation of overall deviation The deviation of each dimension is normalized to the [0,1] interval to represent the degree of anomaly of the corresponding dimension.

[0064] The overall deviation D is calculated using the following formula: D = w_t*Dt + w_f*Df + w_d*Dd + w_ip*D_ip + wg*D_g + w_a*Da; where w_i (i = t, f, d, ip, g, a) are the weights of each dimension, which are dynamically configured according to the device type and home security policy.

[0065] (2.8) Calculate the second risk score The overall deviation D (range 0-1) is converted into a second risk score F2 (range 0-100, where 0 indicates confidence, 50 indicates neutral, and 100 indicates high risk). The system comprehensively calculates the second risk score F2 using the following formula: If D≥D m Then F2 = 50 + (DD) m ) / (1-D m )×50; If D <D m Then F2 = 50 - (D m -D) / (1-D m )×50; where, take the neutral value D m =0.3, which is a configurable empirical value; (2.9) Offline computing support The system's database provides offline data support for real-time deviation calculation. Offline data includes, but is not limited to, historical user operation data (including operation time, operation type, device information, IP address, geographical location, and environmental status). The user behavior profiling risk analysis module includes an offline calculation unit and a real-time calculation unit. Offline data is imported into the offline calculation unit, which statistically analyzes various baseline parameters and periodically writes the results to a high-speed cache for use by the real-time calculation unit. The real-time calculation unit only references the parameters generated offline and does not need to directly access the original historical data, ensuring low computational latency.

[0066] In one specific embodiment, the sensor consistency risk analysis module retrieves real-time sensor data from the cache through a pre-configured device-cooperative sensor relationship table, calls an expression to calculate the consistency score of each cooperative sensor, and weights and fuses them to obtain a comprehensive consistency score, which is then converted into a third risk score, as follows: (3.1) Relationship table between equipment control and collaborative sensors For example, the core configuration items for the relational table are as follows:

[0067] Based on the above relationship table, pre-maintain the cache for the device and its cooperating sensors. Only sensors belonging to the same area, room, or household, and whose sensor types match, are considered cooperating sensors.

[0068] (3.2) Calculation of Cooperative Sensor Consistency Score When a device control request C={device,action,t0} is received, the following steps are performed: (3.2.1) Device-corresponding collaborative sensor query, that is, based on the device ID, retrieve the collaborative sensor set from the cache: S = {s1,s2,…,sn} (3.2.2) Single sensor consistency calculation: For each sensor sj (j=1, 2, 3, ..., n) in set S, the sensor consistency risk analysis module retrieves its real-time data from the cache and calls the expression defined in the configuration table to perform the calculation. The calculation formula is defined as follows: score = expected_state_score(sensor_value, t0); where expected_state_score() is a configurable expression function; sensor_value is the real-time value of the sensor, including the timestamp; t0 is the request time; the function returns a value in the range [0, 100], representing the consistency score between the collaborative sensor and the device control action at the current moment. The higher the value, the higher the consistency between the state of the collaborative sensor and the expectation.

[0069] (3.2.3) Multi-sensor integrated score calculation, i.e., SconS=(score1*weight1+score2*weight2+...+scoren*weightn) / (weight1+weight2+...+weightn); where SconS∈[0, 100], score is the score of each collaborative sensor, and weight is the importance weight of each sensor, defined by the configuration table.

[0070] (3.2.4) Default Policy When the cache cannot obtain the collaborative sensor, a default score value is given based on the device type and specific action. For example, the default score for door lock unlocking is 80 (high uncertainty), and the default score for lighting control is 50 (neutral).

[0071] (3.2.5) Sensor consistency risk factor output The sensor consistency risk analysis module calculates a third risk score based on the sensor consistency score: F3=100 SconS. F3 is the third risk score; a higher value indicates a greater discrepancy between the environmental condition and the control intent.

[0072] The above steps employ a combination of configuration mapping, expression computation, and real-time weighted fusion to achieve the goal of rapidly and consistently assessing the environmental state before executing device control requests.

[0073] The computational complexity of the entire algorithm is O(n) (where n is the number of associated sensors, typically not exceeding 5), and risk assessment can be completed within milliseconds. The system relies solely on cached data, avoiding latency caused by database access and ensuring the real-time performance of the device control link.

[0074] In one specific embodiment, the risk list matching module uses hash tables, Trie trees, and pre-compiled regular expressions to perform exact matching, IP segment matching, and regular expression matching, respectively, and calculates a comprehensive deviation value based on the risk value and weight of the matched entries, which is finally mapped to a fourth risk score.

[0075] The system maintains a unified risk list, and its core configuration items are as follows:

[0076] The above configuration is mapped to the following three data structures in the system: (1) Hash mapping table, used to quickly find exact matching items (such as user_id, device_id, client_id, etc.), where the key is the risk dimension + matching value and the value is the risk item object.

[0077] (2) A prefix tree structure is used to store IP segments or CIDR matching items, which are constructed into a Trie tree to achieve fast interval matching. Overlapping network segments are automatically merged during insertion, and the query complexity is O(log N).

[0078] (3) Regular expression pattern table, used to store pre-compiled regular expression rules, with a separate pattern array maintained for each dimension. At the same time, a pre-compiled state machine (Trie / Aho-Corasick) for multi-pattern matching is generated based on the rule content during the construction phase.

[0079] The specific process by which the risk list matching module calculates the fourth risk score is as follows: (4.1) Risk list record retrieval Exact match: Quickly and accurately match fields such as user_id, device_id, and client_id in the device control request with the hash mapping table. If a match is found, add it to the candidate record set.

[0080] Segment matching: Compares the IP address or other information from the device control request with the segment set; if a match is found, it is added to the candidate record set.

[0081] Regular expression matching: Records that successfully match the corresponding field in the device control request are added to the candidate set.

[0082] (4.2) Calculation of standardized deviation For each record in the hit record set, the following classification is applied: if the risk score (risk_score) > 50, it is considered a risk deviation; if the risk score (risk_score) < 50, it is considered a protection deviation; if the risk score (risk_score) = 50, it is considered neutral and does not participate in the accumulation. The deviation value is multiplied by the recording weight to obtain the standardized deviation.

[0083] (4.3) Deviation from Accumulation and Balance The total risk deviation is obtained by weighting and summing the deviations of all risk scores greater than 50; as the number of hit records of risk deviation increases, the overall risk bias amplifies. The total protection deviation is obtained by weighting and summing all risk scores less than 50 and accumulating the deviation values; as the number of protection deviation hit records increases, the overall protection bias increases. Calculate the deviation difference ΔT = total risk deviation – total protection deviation, to achieve positive and negative offsetting.

[0084] (4.4) Generation of comprehensive score The deviation difference ΔT is mapped to the range of 0 to 100 to obtain the final risk list factor comprehensive score, namely the fourth risk score. Boundary clipping ensures [0, 100].

[0085] (4.5) Performance and Optimization Description Exact matching uses a hash map, segment matching uses a Trie tree, and regular expression matching uses a pre-compiled state machine; the computational complexity is O(n), and it can be executed in real time before device control, with latency controllable to the millisecond level; the caching mechanism can accelerate repeated request matching and maintain high performance; it supports weight configuration and non-linear amplification parameters to flexibly adjust the scoring sensitivity; the system records the hit entries and deviations for easy auditing and backtracking.

[0086] In addition, the risk list generation mechanism is as follows: (a) Automatic generation mechanism (based on behavioral risk accumulation) (a.1) Input and monitoring objects The system continuously monitors the following main behaviors: user operations (such as login, device control requests, and unauthorized permission attempts); IP and client anomalies (such as login from different locations, high-frequency requests, etc.); each event includes a risk level E_i and a weight w_i, and also records the event occurrence time t_i.

[0087] (a.2) Risk accumulation calculation The system accumulates events by subject (user / device / IP / client) to generate a real-time risk value R(t): the risk value of a single event is multiplied by the weight: w_i*E_i; it is accumulated by time decay: recent events have higher weights and historical events have lower weights; the accumulation method is weighted summation to obtain the current risk value R(t); it should be noted that simple weighting or exponential decay can be used here to ensure efficient calculation and low latency.

[0088] (a.3) Generation of risk list entries For entities that meet the threshold conditions, generate risk list entries and populate the following fields: risk_type: Matching dimension (USER_ID, DEVICE_ID, IP, CLIENT_ID, etc.) match_str: Main identifier match_type: Exact match or segment match risk_score: Mapped to 0~100 based on cumulative risk score. weight: Automatically generated entries can be set with a default weight (e.g., 0.6~0.8). source="auto_generated" effective_time / expire_time: Effective period and expiration period (b) Manual allocation mechanism Administrators or security operations personnel can manually create risk list entries through the backend interface or API. High-risk entries are directly generated for special security incidents or external threat intelligence. Configure whitelist exemptions for important users and critical equipment; Manually generated entries can override automatically generated entries (those with higher weight and higher priority). In one specific embodiment, the comprehensive scoring engine maps each risk score to a standard deviation and assigns weights, then aggregates positive and negative deviations respectively; next, it calculates the total deviation based on the positive and negative aggregated values, and maps the total deviation to a comprehensive risk score. The specific process is as follows: (5.1) Risk factor mapping Since a risk factor's risk score of 0 indicates credibility, 50 indicates neutrality, and 100 indicates high risk, the risk score of each risk factor is uniformly mapped to a standard deviation range to obtain the corresponding mapped score. Based on the mapped score, the deviation of each risk factor is calculated: Deviation = (Mapped Score - 50) / 50. The deviation ranges from -1 to 1, with negative values ​​indicating a credibility tendency, positive values ​​indicating a risk tendency, and 0 indicating neutrality.

[0089] (5.2) Risk factor weight allocation Weights are assigned to the risk scores of each risk factor to reflect their contribution to the total risk. In one specific embodiment, the weights of each risk score are configured as follows: First risk score F1 (request context): weight 0.35; Second risk score F2 (user behavior profile): weight 0.25; Third risk score F3 (sensor consistency): weight 0.20; Fourth risk score F4 (risk list): weight 0.20.

[0090] The aforementioned weights can be obtained through machine learning algorithms, or they can be set according to business importance and security policies, and can be flexibly and dynamically configured by experts based on the actual business situation.

[0091] (5.3) Positive and negative deviation processing For deviations greater than zero (positive deviations), the risk is increased; multiplying by the corresponding weight yields a positive weighted value. For deviations less than zero (negative deviations), the risk is reduced; multiplying by the corresponding weight yields a negative weighted value.

[0092] (5.4) Positive and negative deviations from aggregation All positively weighted values ​​are non-linearly aggregated to obtain a positive aggregated value, ensuring that the total risk value can be amplified when multiple high-risk factors appear simultaneously. All negatively weighted values ​​are non-linearly aggregated to obtain a negative aggregated value, ensuring that the total risk value can be reduced when multiple reliable factors appear simultaneously. Non-linear aggregation includes, but is not limited to, the use of exponential weighting.

[0093] (5.5) Calculate the total deviation. Total deviation = Positive aggregate value - Negative aggregate value. The total deviation ranges from -1 to 1, with positive values ​​indicating an increase in overall risk and negative values ​​indicating an overall credibility bias.

[0094] (5.6) is mapped to the final comprehensive risk score. Map the total deviation back to the risk score range of 0 to 100: Overall risk score = 50 * (1 + total deviation).

[0095] As a preferred approach, if the deviation of a single factor exceeds the high-risk threshold, the overall risk score is amplified. If multiple factors simultaneously deviate beyond the threshold, the risk scores are further compounded. This high-risk amplification mechanism ensures that in critical operational scenarios, any anomaly in a single or multiple risk factors can significantly improve the overall risk score, thereby enhancing safety protection capabilities.

[0096] like Figure 1 and Figure 2 As shown, a smart home system is used to implement the aforementioned adaptive risk protection method. This smart home system specifically includes a control terminal, a request receiving module, a decision scheduling module, multiple risk analysis modules, a comprehensive scoring engine, and a terminal. The adaptive risk protection method of this smart home system relies on a smart home infrastructure platform, such as the aforementioned control terminal for initiating device control requests, the aforementioned terminal for executing device control requests, gateways providing communication connections and data processing support, communication networks, and application service platforms. Its workflow is roughly as follows: When the control terminal (such as a mobile APP, smart screen, etc.) initiates a device control request, the request receiving module receives the request and hands it over to the risk analysis module and the comprehensive scoring engine for processing, resulting in a comprehensive risk score. Subsequently, the policy execution module performs allow, secondary authentication, or interception operations on the device control request based on the comprehensive risk score. If the policy execution module decides to allow, the device control request is ultimately executed by the corresponding terminal (such as a smart light, electronic lock, electric curtain, etc.).

[0097] like Figure 1 and Figure 2 As shown, specifically, the control end initiates device control requests to the terminal. The request receiving module receives the device control request and extracts context information. The decision scheduling module determines the risk analysis module to be invoked for the current device control request based on the device type in the context information, as well as preset scenario characteristics and configuration information. The comprehensive scoring engine performs weighted aggregation and risk amplification on various risk scores to generate a comprehensive risk score. The terminal executes the device control request allowed by the policy execution module.

[0098] like Figure 1 and Figure 2 As shown, more specifically, the multiple risk analysis modules include a context risk analysis module, a user behavior profiling risk analysis module, a sensor consistency risk analysis module, and a risk list matching module. Specifically, the context risk analysis module matches extracted context information against a preset risk configuration table and outputs a first risk score; the user behavior profiling risk analysis module calculates the deviation of the current operation based on historical user behavior data and outputs a second risk score; the sensor consistency risk analysis module outputs a third risk score based on the consistency between the real-time status of the collaborative sensors and the control actions; and the risk list matching module matches risk lists based on one or more dimensions of users, devices, and IPs and outputs a fourth risk score. A comprehensive scoring engine weights and aggregates the various risk scores and amplifies the risk to generate a comprehensive risk score. Preferably, the user behavior profiling risk analysis module includes an offline computing unit and a real-time computing unit. Offline data is imported into the offline computing unit, which calculates various baseline parameters and periodically writes the results to a high-speed cache for use by the real-time computing unit.

[0099] like Figure 1 and Figure 2 As shown, the system also includes a rule configuration management module, used to dynamically update the risk factor configuration table, multi-level behavioral profile structure configuration table, collaborative sensor configuration table, and risk list table. The system also includes a data platform for buffering various system data.

[0100] The above are merely specific embodiments of the present invention, but the design concept of the present invention is not limited thereto. Any non-substantial modifications made to the present invention using this concept shall be considered as infringing upon the protection scope of the present invention.

Claims

1. An adaptive risk protection method for controlling smart home devices, characterized in that, Includes the following steps: Step S1: Receive device control request and extract context information, including user identity, device type, control action, control source, and home security status; Step S2: The decision scheduling module determines the risk analysis module to be invoked for the device control request based on the device type, preset scenario characteristics, and configuration information. Step S3: Call the risk analysis modules determined in step S2 to perform risk scoring on the device control request; The risk analysis module includes: a context risk analysis module, used to match extracted context information according to a preset risk configuration table and output a first risk score; a user behavior profile risk analysis module, used to calculate the deviation of the current operation based on the user's historical behavior data and output a second risk score; a sensor consistency risk analysis module, used to output a third risk score based on the consistency between the real-time status of the collaborative sensors and the control actions; and a risk list matching module, used to match risk lists based on one or more dimensions of users, devices, and IPs and output a fourth risk score. Step S4: The comprehensive scoring engine performs weighted aggregation and risk amplification on the various risk scores to generate a comprehensive risk score; Step S5: Execute corresponding security policies on the device control request based on the comprehensive risk score, including allowing, secondary authentication, or blocking operations.

2. The adaptive risk protection method for controlling smart home devices according to claim 1, characterized in that, The context risk analysis module uses a multi-stage filtering and matching algorithm to perform step-by-step matching and downgrade strategies based on the attributes of the device control request and the context risk configuration table information, until the first risk score is output.

3. The adaptive risk protection method for controlling smart home devices according to claim 1, characterized in that, The user behavior profile risk analysis module adopts a multi-level behavior profile structure, including user-level behavior profile, family-level behavior profile and device type-level behavior profile. It backtracks sequentially according to the data sparsity, calculates the comprehensive deviation of operation time, operation frequency, login device, login IP, geographical location and operation type, and maps it to a second risk score.

4. The adaptive risk protection method for controlling smart home devices according to claim 1, characterized in that, The sensor consistency risk analysis module obtains real-time sensor data from the cache through a pre-configured device-cooperative sensor relationship table, calls expressions to calculate the consistency score of each sensor, and weights and fuses them to obtain a comprehensive consistency score, which is then converted into a third risk score.

5. The adaptive risk protection method for controlling smart home devices according to claim 1, characterized in that, The risk list matching module uses hash tables, Trie trees, and pre-compiled regular expressions for precise matching, IP segment matching, and regular expression matching, respectively. It calculates a comprehensive deviation value based on the risk value and weight of the matched entries, and finally maps it to a fourth risk score.

6. The adaptive risk protection method for controlling smart home devices according to claim 1, characterized in that, The comprehensive scoring engine maps each risk score to a standard deviation and assigns weights, then aggregates positive and negative deviations respectively; it then calculates the total deviation based on the positive and negative aggregated values, and maps the total deviation to a comprehensive risk score.

7. A smart home system, characterized in that, include: The control terminal is used to initiate device control requests; The request receiving module is used to receive device control requests from the control terminal and extract context information. The decision scheduling module is used to determine the risk analysis module to be invoked for the current device control request based on the device type in the context information, as well as preset scenario features and configuration information. The risk analysis module includes: a context risk analysis module, used to match extracted context information according to a preset risk configuration table and output a first risk score; a user behavior profile risk analysis module, used to calculate the deviation of the current operation based on the user's historical behavior data and output a second risk score; a sensor consistency risk analysis module, used to output a third risk score based on the consistency between the real-time status of the collaborative sensors and the control actions; and a risk list matching module, used to match risk lists based on one or more dimensions of users, devices, and IPs and output a fourth risk score. The comprehensive scoring engine is used to weight and aggregate various risk scores and amplify the risk to generate a comprehensive risk score. The strategy execution module is used to perform release, secondary authentication, or interception operations on device control requests based on the comprehensive risk score; The terminal is used to execute device control requests that have been permitted by the policy execution module.

8. A smart home system according to claim 7, characterized in that, It also includes a rule configuration management module, which is used to dynamically update the risk configuration table, behavior profile baseline, collaborative sensor configuration table, and risk list table.

9. A smart home system according to claim 7, characterized in that, The user behavior profiling risk analysis module includes an offline computing unit and a real-time computing unit. Offline data is imported into the offline computing unit, which statistically analyzes various baseline parameters and periodically writes the results into a cache for use by the real-time computing unit.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements an adaptive risk protection method for controlling smart home devices as described in any one of claims 1 to 6.

Images