An encrypted scheduling system and method for smart home devices based on AI dynamic decision-making

Abstract

This invention discloses an intelligent device encrypted scheduling system and method based on AI dynamic decision-making. The method includes: a multi-layered AI intent understanding engine converting user input into structured intents using a cloud-based large language model, a local small language model, and an automatic degradation link based on rule matching; generating a plan through dynamic planning; and then encrypting and encapsulating the plan using a private encryption protocol stack with a device-unique identifier-derived key before execution and feedback optimization. An independent cloud authorization server performs dual authentication for access control operations using asymmetric signatures and an encryption layer, generating a time-sensitive temporary token. The system possesses self-healing capabilities, automatically diagnosing, repairing, and rolling back according to a security classification strategy. This invention integrates three layers of AI semantic understanding, a private encryption protocol, dual signatures, and a universal software control adapter, solving the problems of weak understanding capabilities, poor security, and rigid logic in existing solutions. It is applicable to scenarios such as smart homes, hotel access control, commercial offices, connected vehicles, and smart agriculture.

Description

Technical Field

[0001] This invention relates to the field of smart home control technology, specifically to a smart home device encryption scheduling system and method that combines artificial intelligence dynamic decision-making, private encryption protocols, and cloud authorization verification. Background Technology

[0002] Existing smart home control systems generally adopt a "fixed trigger condition → fixed execution script" working mode. Users manually set scene rules through a mobile app, such as "turn on the entrance light when the door magnetic sensor is opened"; the system stores the rules on a local gateway or in the cloud, and sends control commands to the devices according to the preset script when the trigger condition is met.

[0003] The above-mentioned existing technologies have the following shortcomings: (1) Lack of natural language understanding. Existing systems require users to use fixed command sentences or APP operation interfaces, and cannot understand natural expressions such as "I feel a little dark" or "I want to go to bed early tonight". Although some systems have integrated voice assistants, they are essentially still converting speech into text and then performing keyword matching, and do not have the ability to truly understand complex semantics, ambiguous expressions, and contextual relationships. (2) The openness of communication protocols brings security risks. Smart home devices generally use open protocols such as WiFi, Zigbee, and Bluetooth for communication, and control commands are transmitted in plaintext or standard encryption. Attackers can analyze the protocol format by capturing packets and forge control commands. Once the home network is breached, security-sensitive devices such as door locks and cameras face direct threats. (3) Rigid execution logic and lack of dynamic adaptability. Existing scenario rules are statically configured and cannot be adaptively adjusted according to real-time environment (weather, time, user location) and long-term user behavior habits. For example, if a user sets "turn on the air conditioner at 7 am every day", but the outdoor temperature is suitable on a certain day and the air conditioner is not needed, the system will still mechanically execute the command. (4) The device control architecture is flat and lacks hierarchical security isolation. Most smart home systems adopt a direct "APP→cloud→device" architecture, where the APP directly generates control codes that the device can recognize. Under this architecture, AI capabilities (even if they exist) are tightly coupled with device control, and any security vulnerability in any layer will directly expose the device control capabilities. Therefore, there is an urgent need for a system and method that organically combines AI's dynamic semantic understanding capabilities, the security isolation capabilities of private encryption protocols, and a hierarchical scheduling architecture. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide an encrypted scheduling system and method for smart home devices based on AI dynamic decision-making, in order to solve the technical problems of insufficient natural language understanding ability, poor communication security, rigid execution logic, and lack of hierarchical isolation in the existing technology.

[0005] Technical Solution – Method: This invention provides an encrypted scheduling method for smart home devices based on AI dynamic decision-making, comprising the following steps: S1. Receiving user input, the user input including at least one of natural language text input, natural language voice input, or environmental event-triggered input; S2. Sending the user input to a multi-layer AI intent understanding engine, the multi-layer AI intent understanding engine including at least one cloud-based large language model layer, at least one local small language model layer, and at least one rule matching layer, calling each layer sequentially from high to low according to a preset degradation strategy until a certain layer outputs a valid structured intent representation, the structured intent representation including at least a target device identifier, operation type, and operation parameters; S3. Based on the structured intent representation, a dynamic programming module generates an execution plan containing at least one execution step, each step in the execution plan corresponding to a device control instruction; S4. Encapsulating the device control instruction through a private encryption protocol stack to generate an encrypted protocol frame, the private encryption protocol stack adopting a key derivation mechanism based on a unique device identifier, enabling different devices to use different session keys; S5. Sending the encrypted protocol frame to the target device through a message middleware, the target device decrypts and executes the corresponding operation; S6. The system receives the execution result returned by the target device and feeds the execution result back to the multi-layer AI intent understanding engine to optimize subsequent intent understanding and dynamic planning.

[0006] Technical Solution – System: Accordingly, this invention provides an AI-based dynamic decision-making-based encrypted scheduling system for smart home devices, comprising: an AI intent understanding module deployed on a network-connected computing device, used to receive user input and convert it into a structured intent representation; the AI ​​intent understanding module includes a cloud-based large language model submodule, a local small language model submodule, and a rule matching submodule, and the three submodules are connected in series according to priority to form an automatic degradation link; a dynamic planning and scheduling module, used to generate an execution plan containing at least one execution step based on the structured intent representation, and distribute each execution step to the corresponding device connector; and a private encryption protocol stack module, used for... The device control commands generated by the device connector are encrypted and encapsulated to generate an encrypted protocol frame with a unified frame format. The encryption key of the encrypted protocol frame is generated by a key derivation function using a master key and the unique identifier of the target device. A message middleware module is used to establish an asynchronous bidirectional communication channel between the scheduling system and each target device. The encrypted protocol frame is sent to the target device via the message middleware module, and the execution result is returned via the message middleware module. A device execution agent module is deployed on each controlled device or device gateway to receive and decrypt the encrypted protocol frame, forward the decrypted operation command to the device hardware interface for execution, and encrypt and return the execution result.

[0007] Compared with existing technologies, the present invention has the following beneficial effects: (1) True natural language understanding. The three-layer AI architecture enables the system to understand the user's intentions expressed in any way, including fuzzy expressions, implicit intentions and complex instructions with contextual associations, without requiring the user to memorize fixed command formats. The intent caching mechanism enables high-frequency instructions to achieve millisecond-level response. (2) End-to-end security isolation. The AI ​​decision layer does not directly contact the device control protocol, and the device execution layer does not contact the AI ​​inference logic. The two are securely isolated through a private encryption protocol stack, and any breach of any layer will prevent a separate attack. The device-level key isolation mechanism ensures that the leakage of a single device key does not affect the security of other devices. (3) Dynamic adaptive execution. Dynamic planning is performed by combining environmental context (time, weather, sensor status) and user behavior habits, rather than mechanically executing fixed scripts. Automatic replanning is performed when execution fails, ensuring that the task is eventually completed. (4) High availability. The multi-layer automatic degradation mechanism ensures that the system can continue to run through the local model or rule engine in abnormal situations such as network interruption and cloud service unavailability, and the core device control function is never interrupted. (5) Forward compatibility and scalability. The unified private frame format is decoupled from specific hardware communication methods (WiFi, Zigbee, Bluetooth). Adding a new device type only requires registering the device identifier and installing the corresponding device execution agent; no modification to the AI ​​decision layer and encryption protocol stack is required. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the overall architecture of the system of the present invention. Figure 2 This is a flowchart of the main steps of the method of the present invention. Figure 3 This is a schematic diagram of the structure of a private encryption protocol frame. Figure 4 A flowchart for the automatic degradation process of the AI ​​dynamic decision-making layer. Figure 5 This is a flowchart of the query process for the intent caching mechanism. Detailed Implementation

[0009] Example 1: Complete Process of User Issuing the Command "Turn on the Living Room Light". This example uses the natural language command "Turn on the living room light" as an example to explain in detail the complete process of the system from receiving user input to executing device control. Step 1: Receiving User Input. The user records the voice command "Turn on the living room light" through the microphone of the mobile application. The mobile application uploads the audio data to the HAL server deployed in the local area network via an HTTP interface. The HAL server calls the speech recognition interface to transcribe the audio into the text "Turn on the living room light". Step 2: AI Intent Understanding. The text "Turn on the living room light" is sent to the intent understanding engine of the AI ​​dynamic decision layer. First, the intent cache is queried: the hash value of the text is calculated, and a matching record is searched in the cache database. Assuming that the user issues this command for the first time, the cache is not hit. Entering Model Inference: The engine constructs a prompt word template containing contextual information such as the current time, date, and weather status, and first calls the cloud-based large language model for inference. The cloud model analyzes the semantics of the text, identifies the user's true intent as "control the main living room light to turn on", and outputs a structured intent representation containing intent category, target device identifier, operation type, operation parameters, and confidence score. The intent understanding engine stores the successful parsing result in the cache database. Step 3: Dynamic Programming. After receiving the structured intent, the dynamic programming module generates an execution plan containing a single step based on the intent category and device type, namely, calling the lighting control connector with the target device identifier and the start command as parameters. Step 4: Encryption and Encapsulation. The lighting control connector generates a plaintext payload based on the device identifier and operation parameters, and passes it to the private encryption protocol stack. The encryption protocol stack first derives the device-specific AES key from the master key using the HMAC key derivation function based on the device identifier (including device type, model, region, and serial number). The derived key is used to encrypt the plaintext payload with AES-128-GCM to generate an encrypted payload containing ciphertext and a GCM authentication tag. A complete private protocol frame is constructed, including the frame header magic number, device identifier field, timestamp, command type, serial number, payload length, encrypted payload, and CRC-32 integrity check field. Step 5: MQTT Distribution. The encrypted protocol frame is published to the command topic corresponding to the device through the MQTT client. After receiving the message, the MQTT message broker forwards it to the device execution broker that subscribes to the topic. Step 6: Device Decryption and Execution. The device execution agent extracts the encrypted frame byte array from the MQTT message, verifies the magic number and CRC-32 checksum in the frame header, and confirms that it matches its own device identifier. Then, it uses its stored derived key to perform AES-128-GCM decryption and authentication tag verification on the encrypted payload. After obtaining the plaintext payload, it calls the hardware driver interface to execute the corresponding operation, turning on the living room light. Step 7: Result Feedback. The device execution agent encapsulates the execution result into a response frame, encrypts it, and sends it back to the HAL server via an MQTT status topic. After decryption and verification, the HAL server records the execution result in the log and updates the device status cache.The feedback evaluation module determines that the process was successful and sends a push notification to the user via the app, indicating that "the living room light is on."

[0010] Example 2: Away Mode – Autonomous Triggering of Multi-Device Linkage. This example illustrates how the system can autonomously coordinate and schedule multiple devices through environmental event triggering without user input. Prerequisites: The user has registered four smart devices in the system: front door lock, living room light, living room curtains, and living room air conditioner. Step 1: Event Triggering. The front door lock detects that the user has performed a "leaving home and locking the door" operation outside the door. The door lock device publishes an event message to the HAL server via its device execution agent through an MQTT event topic, with the event type being "leaving home and locking the door". Step 2: No Input Intent Generation. After the HAL server's AI dynamic decision layer listens to the event, it autonomously initiates the intent understanding process without direct user input. The engine constructs prompts containing the following context: current time (weekday 08:15), current weather (sunny, outdoor 28°C), triggering event (front door locking the door), and user's historical behavior (typically performing the operation sequence of turning off all lights, turning off the air conditioner, and closing the curtains during the weekday 8:00-8:30 leaving home period). The cloud-based large language model performs comprehensive reasoning on the above information and outputs a structured intent. The intent category is scenario mode, the scenario type is "away mode," and it includes three sub-intents: close the living room curtains, turn off the living room lights, and turn off the living room air conditioner. Step 3: Multi-step dynamic programming. The dynamic programming module generates an execution plan containing three steps based on the intent, ordered by dependency: first close the living room curtains (heat insulation), then turn off the living room lights (lighting), and finally turn off the living room air conditioner (temperature maintenance). Steps 4 to 6: Encrypted delivery and execution. Each step is encapsulated in sequence through a private encryption protocol stack and then delivered to the execution agent of the corresponding device via MQTT. The curtain motor, lights, and air conditioner turn off in sequence. The execution result of each step is sent back to the HAL server, and the feedback module confirms that each step was executed successfully. Step 7: User notification. After all steps are completed, the HAL server pushes a notification to the user via the APP: "Away mode has been activated: lights are off, curtains are closed, and air conditioner is off."

[0011] Example 3: Smart Door Lock – Independent Encrypted Channel for High-Security Devices. This example uses a smart door lock as an independent implementation scenario to illustrate the advantages of the proprietary encryption protocol stack of this invention in security-sensitive devices. Background: Smart door locks are the first physical line of defense for home security. Unlike non-security-sensitive devices such as lights and curtains, the forgery or tampering of door lock control commands directly leads to the risk of burglary. Existing smart door locks generally have the following security vulnerabilities: the door lock firmware and the APP communicate using a fixed key or the device's factory default key. Once this key is obtained through network packet capture or firmware reverse engineering, attackers can forge unlocking commands; AI voice assistants can directly control the door lock, but the security boundary of the voice assistant itself is weak. Anyone standing outside the door and shouting "open the door" can trigger unlocking without any authorization or verification. This invention fundamentally solves the above security problems through a multi-layered isolation architecture of "AI understanding → encrypted command → authorization gateway → door lock execution". System Deployment: A smart lock is deployed in the entrance area, integrating an embedded chip supporting WiFi and BLE. The firmware pre-loads a device-specific AES-128 key (generated from the master key via a key derivation function, not stored in plaintext in the firmware). The HAL lock execution agent runs as a coprocessor on the lock's mainboard, communicating with the lock's motor drive circuit, fingerprint module, and Bluetooth module via onboard communication interfaces, and with the MQTT message broker via WiFi. The cloud authorization server is independent of the AI ​​decision-making layer; lock control commands must undergo explicit signature verification by the cloud authorization server before reaching the lock execution agent. Unlocking Process: After the user issues the "unlock" command, the AI ​​dynamic decision-making layer performs intent parsing. Before the encrypted protocol frame is sent, the system performs the following additional steps: (A) Access Control Authorization Verification. The AI ​​decision-making layer sends the unlocking request (including user identity token, device identifier, and timestamp) to the cloud authorization server. The cloud authorization server performs the following: verifying the validity and permission level of the user identity token (unlocking requires the user's permission level to be a family member and the token to be valid); verifying whether the request source IP is consistent with the user's home network to prevent remote attacks; and verifying whether the current time is within the user's configured automatic unlocking time window. After all the above verifications are successful, the cloud authorization server uses its private key to sign the authorization credential allowing unlocking and returns the signed authorization token. (B) Double Signature Encapsulation. The HAL server appends the authorization token issued by the cloud authorization server to the payload of the encrypted protocol frame. This frame simultaneously contains the AI ​​decision-making layer's AES-128-GCM instruction encryption and the cloud authorization server's asymmetric signature authentication, forming double security protection. (C) Door Lock Executes Proxy Dual Verification. After receiving the encrypted frame, the door lock execution agent decrypts the instruction payload using the device's dedicated AES key, verifies the GCM authentication tag, and confirms that the instruction has not been tampered with and comes from a legitimate HAL server holding the correct AES key; it extracts the cloud authorization token from the payload, verifies the signature using the public key of the cloud authorization server, and confirms that the unlocking operation has been explicitly authorized by the cloud. After both layers of verification are passed, the agent outputs an unlocking signal to the door lock motor drive circuit, and the door lock opens. (D) Extended application in hotel and commercial access control scenarios. The above solution is also applicable to any access control scenario that requires authorization verification, such as hotel door locks, office access control, rental housing management, and shared office spaces. Taking the hotel scenario as an example: After a guest completes a room reservation through a mobile terminal, the platform pushes the guest's identity token and check-in time period to the cloud authorization server. The cloud authorization server derives a temporary session key based on the unique identifier of the device corresponding to the room's door lock. When the guest arrives at the room door, the door lock execution agent detects the guest's identity credentials (including but not limited to mobile device Bluetooth broadcast signals, biometrics, digital passwords, or dynamic QR codes), triggering the AI ​​decision layer to generate an unlocking intent. After verifying the validity period of the guest token and its binding relationship with the room, the cloud-based authorization server issues a time-limited authorization credential, unlocking the door. Upon check-out time or early check-out, the cloud-based authorization server automatically revokes the temporary token, and the door lock no longer responds to any identification credentials for that guest. Throughout the process, guests do not need to queue at the front desk to collect physical room cards, hotels do not need to manage the issuance and collection of room cards, landlords can remotely set precise hourly check-in and check-out authorization time windows for tenants, and office access control can automatically generate one-time or time-limited access credentials based on visitor appointments. By introducing a time-limited temporary authorization token mechanism, this invention extends secure access control from smart home scenarios to any commercial access control scenario requiring authorization verification.

[0012] Security Features Summary: Transmission encryption uses AES-128-GCM authentication to prevent network eavesdropping and command tampering; key isolation uses independently derived keys for each device, so a leak of a key on one device will not affect other devices; authorization verification uses explicit signatures on the cloud server to prevent the AI ​​layer from being deceived and directly controlling the door lock; temporary tokens have an expiration time and are automatically revoked upon expiration, suitable for time-limited authorization scenarios such as hotels and rental properties; network isolation uses authorization verification source IP binding to prevent remote attackers from forging commands; local priority uses the highest priority of Bluetooth physical buttons, allowing local unlocking even when the network is offline. Through the above multi-layered security mechanisms, even if the AI ​​dynamic decision-making layer is deceived by malicious input (e.g., someone says "unlock the door" to the smart speaker), the cloud authorization verification layer will still refuse to issue authorization credentials due to the lack of a valid family member identity token, thus blocking the attack chain from voice spoofing attack to physical unlocking at the architectural level.

[0013] The above description is merely a preferred embodiment of the present invention and does not limit the scope of patent protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of patent protection of the present invention.

Claims

1. An intelligent home device encryption scheduling method based on AI dynamic decision, characterized in that, Includes the following steps: S1. Receive user input, wherein the user input includes at least one of natural language text input, natural language speech input, or environmental event-triggered input; S2. The user input is sent to a multi-layer AI intent understanding engine. The multi-layer AI intent understanding engine includes at least one cloud-based large language model layer, at least one local small language model layer, and at least one rule matching layer. The multi-layer AI intent understanding engine calls each layer sequentially from high to low according to a preset degradation strategy until a certain layer outputs a valid structured intent representation. The structured intent representation includes at least the target device identifier, operation type, and operation parameters. S3. Based on the structured intent representation, the dynamic programming module generates an execution plan containing at least one execution step, wherein each step in the execution plan corresponds to a device control instruction; S4. The device control command is encapsulated through a private encryption protocol stack to generate an encrypted protocol frame. The private encryption protocol stack adopts a key derivation mechanism based on the unique identifier of the device, so that different devices use different session keys. S5. The encrypted protocol frame is sent to the target device via a message middleware, and the target device decrypts it and performs the corresponding operation. S6. Receive the execution result returned by the target device, and feed the execution result back to the multi-layer AI intent understanding engine to optimize subsequent intent understanding and dynamic planning.

2. The method of claim 1, wherein, The degradation strategy in step S2 is as follows: the cloud-based large language model layer is called first. If no valid output is obtained within the preset timeout period, it is automatically downgraded to the local small language model layer. If the local small language model layer also fails to obtain a valid output within the preset timeout period, it is automatically downgraded to the rule matching layer. The rule matching layer performs deterministic matching based on a pre-configured keyword-intent mapping table as a final backup.

3. The method of claim 1, wherein, Step S2 further includes: matching the hash value input by the user with the historical structured intent representation in a cache; if the cache hits, the corresponding structured intent representation is returned directly, bypassing all model layer calls.

4. The method of claim 1, wherein, The private encryption protocol frame in step S4 includes the following fields: frame header magic number, device identifier field, timestamp field, instruction type field, serial number field, payload length field, ciphertext payload field, and integrity verification field; wherein the ciphertext payload field uses an authentication encryption algorithm to encrypt the plaintext instruction payload and embeds an authentication tag in the ciphertext.

5. The method of claim 1, wherein, The key derivation mechanism in step S4 is as follows: using a preset master key as the root key, and using a combination of the target device's device type identifier, device model identifier, region identifier, and device serial number as the derivation factor, the target device's device-specific encryption key is generated through an HMAC-based key derivation function.

6. The method of claim 1, wherein, The message middleware in step S5 is the MQTT message broker. The encrypted protocol frames are published and subscribed through a preset topic namespace, which is organized hierarchically according to device type and device identifier.

7. The method of claim 1, wherein, The environmental event trigger input in step S1 comes from at least one of time scheduling events, sensor state change events, weather data update events, or third-party service callback events; when the environmental event trigger input is received, the method autonomously generates an intent and executes device scheduling without user input.

8. An AI-based dynamic decision intelligent home device encryption scheduling system, characterized in that, include: An AI intent understanding module is deployed on a computing device with network connectivity to receive user input and convert it into a structured intent representation. The AI ​​intent understanding module includes a cloud-based large language model submodule, a local small language model submodule, and a rule matching submodule. The three submodules are connected in series according to priority to form an automatic degradation link. A dynamic planning and scheduling module is used to generate an execution plan containing at least one execution step based on the structured intent representation, and to distribute each execution step to the corresponding device connector; A private encryption protocol stack module is used to encrypt and encapsulate the device control commands generated by the device connector to generate an encryption protocol frame with a unified frame format, wherein the encryption key of the encryption protocol frame is generated by the master key and the unique identifier of the target device through a key derivation function. A message middleware module is used to establish an asynchronous bidirectional communication channel between the scheduling system and each target device. The encrypted protocol frame is sent to the target device via the message middleware module, and the execution result is returned via the message middleware module. A device execution agent module is deployed on each controlled device or device gateway to receive and decrypt the encrypted protocol frame, forward the decrypted operation instructions to the device hardware interface for execution, and encrypt and send back the execution result.

9. The system according to claim 8, characterized in that, The dynamic planning and scheduling module also includes an execution feedback evaluation submodule, which is used to determine whether the current step is successful based on the execution result returned by the device. If it fails, a replanning process is triggered, and the AI ​​intent understanding module regenerates the execution plan based on the failure information and the current context.

10. The system according to claim 8, characterized in that, The device execution agent module runs as a resident process on devices running Windows, Linux, or embedded real-time operating systems, and performs device control operations by calling the operating system's native APIs.

11. The system according to claim 8, characterized in that, The AI ​​intent understanding module also includes an intent cache database, which stores structured intent representations that have been successfully matched in the past, using the hash value of the user input text as the primary key. Before entering the model layer for inference, the intent cache database is queried first.

12. The system according to claim 8, characterized in that, The system also includes a cloud-based authorization verification module, which verifies the user's authorization level through a periodic heartbeat mechanism and dynamically enables or disables the cloud-based large language model submodule and specific advanced functions based on the authorization level.

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

14. A smart home device gateway, comprising a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the method of any one of claims 1 to 7.

Images