System and method for unlocking multi-user lock through mobile phone

Abstract

The invention discloses a system and a method for unlocking a multi-user lock by a mobile phone. A vehicle-mounted control module of the system adopts a BLE double-broadcast mode for dynamic switching, an integrated identity authentication unit realizes double authentication of secret key verification and IRK verification, and unlocking and locking are triggered through RSSI signal strength conversion distance. The mobile phone user module can be automatically reconnected with the vehicle-mounted BLE, and HID function adaptation and personalized parameter configuration are supported. And the cloud auxiliary module realizes user account management, OTA remote upgrade and equipment state real-time synchronization. According to the method, the initial trust relationship between the mobile phone and the vehicle-mounted equipment is established through initialized binding, permission distribution is completed through multi-user identity authentication and pairing, finally non-inductive unlocking and locking are achieved through IRK identity recognition and RSSI distance judgment, and meanwhile the exception handling process is covered. Unlocking and locking operation can be completed without manual intervention, and the safety level is remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle unlocking and control, specifically to a mobile phone unlocking system and method for multi-user locks. Background Technology

[0002] Currently, unlocking and control solutions for electric bicycles mainly fall into three categories. Each type of solution has some issues in terms of system composition, safety performance, and user experience, as detailed below:

[0003] (1) 433MHz RF remote control key solution. The system of this solution consists of two parts: the key end and the vehicle end. The key end is a button battery remote control with a built-in fixed rolling code or fixed code chip. The transmission power is controlled within 10 dBm and the signal transmission is maintained by the button battery. The vehicle end consists of a 433 MHz superheterodyne or superregenerative receiver module, a microcontroller unit (MCU), and a drive relay or field-effect transistor (MOSFET). It adopts a constant power supply mode to ensure that the key signal can still be received after the vehicle is turned off.

[0004] This solution has two major drawbacks: First, it lacks security. The fixed code signal is easily captured and replayed by unauthorized devices. Even if a rolling code is used to raise the threshold for cracking, current technology can still record and replay the signal using dedicated equipment, or crack it by brute-force scanning through possible code values. Second, it has weak anti-interference capabilities. The 433 MHz band is occupied by various civilian devices such as tire pressure monitoring devices, garage door remote controls, and wireless doorbells. In areas with dense devices, co-channel interference is likely to occur, causing the unlocking command to fail or the lock to be accidentally triggered, affecting the reliability of use.

[0005] (2) Pure mechanical key solution. The system of this solution consists of three parts: a metal key, an integrated lock cylinder, and a wiring harness. The key is made of metal with a double-sided milled tooth or internal milled groove structure, and unlocking is achieved by matching the physical tooth shape with the lock cylinder; the lock body is an integrated lock cylinder that combines the functions of a mechanical steering lock and a power contact plate, and integrates a dust cover, a bolt, a pin or a blade mechanism inside, which can realize vehicle steering locking and is responsible for power on and off control; when the key is turned to the ON position, the wiring harness closes the main relay coil circuit with the contact plate, and allows the positive terminal of the battery pack to be transmitted to the vehicle controller through the fuse to complete the power conduction.

[0006] The shortcomings of this solution are mainly in two aspects: security and user experience. In terms of security, the lock cylinders generally meet the Class A standard for resistance to technical picking. Skilled locksmiths can pry them open within 30 seconds using technical means. Furthermore, the power contacts of the lock body are exposed, allowing unauthorized personnel to directly start the vehicle through short contact points, resulting in weak anti-theft capabilities. In terms of user experience, each ride requires completing the entire process of taking out the key, inserting it into the lock cylinder, turning it to turn on the power, and removing the key after riding. Metal keys are inconvenient to carry and are easily forgotten or lost, rendering the vehicle unusable.

[0007] (3) Smartphone APP vehicle control solution. This solution is a multi-terminal collaborative architecture, consisting of three parts: user terminal, vehicle terminal, and cloud terminal. The user terminal is an APP running on iOS or Android systems, which establishes communication with the vehicle telematics terminal (T-Box) via Bluetooth Low Energy (BLE) or 4G Cat.1 network. The vehicle terminal consists of a BLE system-on-a-chip (SoC) or cellular communication module, security chip, MCU, CAN or RS485 bus, and driver-level MOSFET, and is responsible for receiving and executing APP commands. The cloud terminal deploys servers for user account management, vehicle status monitoring, encrypted certificate storage, and over-the-air (OTA) updates. For example, in a 4G scenario, after a user clicks the "remote start" button in the APP while in the office, the cloud will push an encrypted command to the vehicle T-Box. The T-Box will verify the legality of the command and then execute the start operation.

[0008] The core problem with this solution lies in its lack of ease of use: users must open the mobile app each time they unlock the device, complete identity verification or click an action within the app before sending a command, making the process cumbersome. In scenarios requiring rapid response, such as those involving frequent vehicle entry and exit for delivery riders and couriers, the time spent launching and operating the app significantly impacts efficiency, resulting in long response times that fail to meet the need for instant unlocking.

[0009] In summary, current mainstream solutions all have shortcomings in terms of security, ease of use, and scenario adaptability. 433MHz keys are easily cracked and have poor anti-interference capabilities; mechanical keys offer low security and are inconvenient to carry; and app-based solutions are cumbersome to operate and slow to respond. None of these three solutions can simultaneously meet the requirements of multi-user authorization, seamless and fast unlocking, and high-security protection. They are ill-suited for multi-user scenarios such as family-owned shared vehicles and commercial rental vehicles, and also fail to satisfy users' pursuit of a smart unlocking experience. Therefore, a new unlocking system that can solve the above problems is needed to improve the unlocking security and efficiency of electric bicycles and related scenarios. Summary of the Invention

[0010] Addressing the shortcomings of existing solutions—433 MHz radio frequency keys, purely mechanical keys, and smartphone app-based vehicle control—in terms of security, convenience, and adaptability to various scenarios, this invention proposes a smartphone-based multi-user lock unlocking system and method through innovative hardware selection, protocol design, and closed-loop process.

[0011] The first objective of this invention is to provide a mobile phone unlocking multi-user lock system, including an in-vehicle control module, a mobile phone user module, and a cloud-based auxiliary module;

[0012] The vehicle control module includes a BLE communication unit, an identity authentication unit, a status detection and execution unit, and a security encryption unit. The BLE communication unit performs dynamic switching and dynamic sleep mechanisms for dual broadcast modes. The identity authentication unit adopts a dual authentication mechanism of key verification and IRK verification and performs hierarchical access control. The status detection and execution unit calculates distance by signal strength and combines sensors and actuators to trigger operations. The security encryption unit provides security protection for HID services, sensitive data, and control commands.

[0013] The mobile phone user module includes a Bluetooth communication unit, an APP interaction unit, an HID adaptation unit, and a personalized configuration unit. The Bluetooth communication unit performs automatic scanning and stable connection. The APP interaction unit provides device binding, HID function control, sensing distance adjustment, and device status viewing functions. The HID adaptation unit adapts to different mobile phone systems and supports abnormal recovery. The personalized configuration unit supports permission management, unlock reminder settings, reconnection priority configuration, and scene mode presets.

[0014] The cloud-based auxiliary module is built on a cloud server and includes a user account management unit, an OTA upgrade unit, and a status synchronization unit. The user account management unit performs multi-factor authentication, device association, and operation log management. The OTA upgrade unit performs hierarchical upgrade package management, breakpoint resume, and canary release. The status synchronization unit performs bidirectional data synchronization, hierarchical anomaly alarms, and cross-device parameter migration.

[0015] Preferably, the BLE communication unit of the vehicle control module adopts a Bluetooth Low Energy SoC chip; the dual broadcast mode includes connection broadcast and binding broadcast, connection broadcast is started by default, and binding broadcast is triggered by continuous operation of the mechanical key to receive the initial connection key; under the dynamic sleep mechanism, when there is no mobile phone connection, the connection broadcast interval is gradually extended until it enters a deep sleep state, and wakes up and restores the normal broadcast interval when a mobile phone Bluetooth signal or mechanical key operation is detected.

[0016] In the identity authentication unit of the vehicle control module, the connection key for key verification is generated and intercepted by the mobile APP based on the user account information and the device SN code through a hash algorithm. After receiving it, the vehicle unit encrypts and stores it in the on-chip Flash, and the storage address adopts a random offset design. The IRK verification generates an IRK when the mobile phone enables the HID function for pairing and stores it in association with the hash identifier of the mobile phone's Bluetooth device. When reconnecting, the mobile phone's Bluetooth broadcast identity identifier is parsed and matched with the IRK list.

[0017] Preferably, the status detection and execution unit of the vehicle control module includes an RSSI signal detection component, a status sensor component, and an actuator component; in the RSSI signal detection component, the distance is calculated using the formula d=10^((abs(RSSI)-50) / (10×3.325)), which is the proximity unlock threshold and distance lock threshold associated with each IRK group; the status sensor component includes a Hall effect wheel sensor, a piezoelectric vibration sensor, and an ignition switch status detection circuit, and is determined to be in a stationary state if there is no wheel movement and no vibration for a continuous preset time; the actuator component includes a MOSFET, a DC relay, and a Bluetooth alarm control circuit, and triggers an audible and visual alarm when the Bluetooth alarm is armed and detects abnormal vibration or illegal power supply.

[0018] Preferably, in the security encryption unit of the vehicle control module, HID service encryption triggers mobile phone Bluetooth pairing by generating a service change report, and pairing uses an encryption algorithm to generate a temporary session key; sensitive data uses a block encryption algorithm, the encryption key is generated based on the chip's unique ID and real-time clock, and the data is stored in on-chip secure Flash; control command verification generates a check code through a hash algorithm, the check code is calculated from the command content and the random challenge code of the vehicle unit, and the command is executed after the comparison is consistent.

[0019] Preferably, the Bluetooth communication unit of the mobile phone user module scans for BLE broadcast signals and adopts adaptive frequency hopping technology after the connection is established; the HID adaptation unit sets the sampling frequency and connection interval for the iOS system or Android system.

[0020] In the OTA upgrade unit of the cloud-assisted module, the upgrade package is divided into firmware and configuration packages for the vehicle control module, and full installation package and incremental resource package for the mobile APP. The upgrade package uses RSA signature verification. The upgrade process supports breakpoint resume. In the status synchronization unit, the cloud synchronizes the status data uploaded by the vehicle control module to the mobile APP at fixed intervals. When the user modifies the parameters, the data is first synchronized to the cloud and then forwarded to the vehicle unit.

[0021] The second objective of this invention is to provide a method for unlocking a multi-user lock on a mobile phone, based on the aforementioned system implementation, comprising the following steps:

[0022] S1: System initialization and binding: Establish the initial trust relationship between the mobile user module and the vehicle control module. The vehicle BLE communication unit starts the connection broadcast, triggers the vehicle binding broadcast, and the mobile APP sends and stores the binding key.

[0023] S2: Multi-user authentication and pairing, completes secondary verification of user identity and HID service adaptation, mobile APP connects to vehicle connection broadcast, APP sends key and completes verification, enables HID function and completes pairing, stores IRK and configures personalized RSSI;

[0024] S3: Seamless unlocking and locking, relying on automatic reconnection, IRK verification and RSSI judgment to achieve automatic operation. The mobile phone automatically reconnects to the vehicle's BLE communication unit via Bluetooth. The vehicle control module verifies the mobile phone's IRK, determines the distance based on RSSI and triggers the operation, and sends the operation result back to the mobile phone.

[0025] S4: Abnormal handling and closed-loop control, including real-time monitoring of status, shutting off the power switch after a timeout while stationary, and triggering arming after the power switch is shut off.

[0026] Preferably, step S1 includes the following steps:

[0027] S11: After the vehicle control module is powered on, it completes a hardware self-test. After the self-test is passed, the BLE communication unit starts connection broadcasting. If there is no connection, the BLE communication unit enters a deep sleep state. In the deep sleep state, it can be woken up by a mechanical key or by detecting the Bluetooth signal of a bound mobile phone. After waking up, connection broadcasting is resumed.

[0028] S12: After the mechanical key detection circuit recognizes that the mechanical key has continuously executed multiple operation sequences, the BLE communication unit stops the connection broadcast and switches to the binding broadcast. The binding broadcast includes the device SN code and the binding request identifier.

[0029] S13: After logging into the account on the mobile APP, click "Add Device" to start Bluetooth scanning and identify the binding broadcast. After the user selects the target device, the APP establishes a temporary connection with the vehicle BLE communication unit. The APP calculates the connection key based on the user account ID, device SN code, and current timestamp, encrypts it, and sends it to the vehicle control module. The vehicle identity authentication unit decrypts the key, re-encrypts it, and stores it in a secure address. The vehicle BLE communication unit disconnects and switches back to connection broadcast. After the APP detects the disconnection, it pops up a binding success prompt and adds the device to the "My Devices" list.

[0030] Preferably, step S2 includes the following steps:

[0031] S21: After a new user logs into the APP and is authorized by the administrator to access the target vehicle control module, the APP starts Bluetooth scanning for connection broadcasts of the target device; after the APP initiates a connection request, the vehicle BLE communication unit triggers the identity authentication unit to send a key request instruction.

[0032] S22: After receiving the key request instruction, the APP retrieves the locally stored connection key, and the ordinary user or temporary user manually enters the connection key; the APP encrypts the key and sends it to the vehicle control module, the vehicle identity authentication unit decrypts it and compares it with the stored key; if the comparison is consistent, a communication connection is established.

[0033] S23: After successful verification, the user clicks the HID enable button, and the APP sends the HID enable command to the vehicle control module; the vehicle security encryption unit sets the HID service channel to encrypted mode, generates a service change report containing the HID service UUID and encryption status identifier, and sends it to the APP; the APP triggers the mobile phone Bluetooth pairing process, the vehicle unit generates a random pairing code, and the user clicks to pair after verifying that the pairing code matches.

[0034] S24: After successful HID pairing, the vehicle identification unit generates an IRK and associates the IRK with the mobile phone's Bluetooth identifier, storing it in a secure address. The user adjusts the unlocking and locking distances on the APP by sliding the progress bar. The APP calculates the corresponding Hid_on_rssi and Hid_off_rssi values ​​in real time and sends them to the vehicle control module. The vehicle status detection and execution unit encrypts and stores the parameters, then reports successful saving, and the APP prompts that the settings have taken effect.

[0035] Preferably, step S3 includes the following steps:

[0036] S31: When the user carries a paired mobile phone with Bluetooth enabled, the mobile phone's Bluetooth communication unit scans the BLE channel; after scanning and broadcasting the connection of an authenticated vehicle control module, it extracts the SN code and matches it with the local authentication list. If the match is consistent, it initiates a reconnection request; and establishes a communication link based on the BLE fast connection feature.

[0037] S32: The vehicle-mounted authentication unit extracts the Bluetooth hash identifier from the reconnection request, retrieves the stored IRK list for matching; after matching, it verifies the user's permission status; if the permission is valid, it sends an identity verification pass command;

[0038] S33: After receiving the verification pass command, the vehicle status detection and execution unit collects the mobile phone Bluetooth RSSI signal and performs a sliding average filter; it calculates the actual distance based on the formula d=10^((abs(RSSI mean)-A) / (10×n)), where A is the absolute value of RSSI at a distance of 1 meter and n is the dynamic environment attenuation factor; when the actual distance is ≤ the unlocking distance, it controls the Bluetooth alarm to disarm and the MOSFET to turn on the ACC circuit; when the actual distance is ≥ the locking distance, it controls the alarm to arm and disconnects the ACC circuit when the detection switch is closed.

[0039] S34: The vehicle-mounted BLE communication unit sends a result command containing the operation type, time, and vehicle status to the mobile phone; the mobile phone's Bluetooth communication unit synchronizes the operation result to the APP background, and the device log page is updated the next time the APP is launched.

[0040] Preferably, step S4 includes the following steps:

[0041] S41: The on-board status detection and execution unit monitors multi-dimensional status, including: ignition switch and actuator status, vehicle motion and environmental status, and BLE connection status.

[0042] S42: Based on wheel movement and vibration sensor data, determine the vehicle's stationary state; after the ignition is turned on and the stationary state has been inactive for a timeout, control the MOSFET to disconnect the ACC circuit, detect whether the ignition is closed, and if it is not closed, send an ignition closing failure alarm to the cloud, push the alarm to the administrator, and the vehicle unit records the fault details.

[0043] S43: After the ignition is turned off, the vehicle control module uses the mobile phone's GPS to determine whether the vehicle is in the safe zone preset by the APP; if it is in the safe zone, the arming is delayed; if it is in the unsafe zone, the arming is not delayed; when the vehicle is armed, the Bluetooth alarm is activated and the ACC circuit is disconnected, and the arming result is synchronized to the cloud and the mobile phone.

[0044] The present invention has the following beneficial effects:

[0045] (1) This invention does not require the user to manually open the APP or operate the physical key. The user only needs to carry an authenticated mobile phone and turn on the system Bluetooth. When the mobile phone is close to the vehicle, it can automatically reconnect to the vehicle's BLE through the HID service and complete the unlocking by combining the RSSI signal. When the user moves away from the vehicle, the system will automatically trigger the lock based on the preset RSSI threshold, without the need for manual intervention.

[0046] (2) This invention constructs a multi-layered security system with dual authentication, encrypted transmission, and hardware-level identity recognition: First, the mobile APP must pass key verification during its initial binding and subsequent connections. If the connection times out or the key is incorrect, it will automatically disconnect to prevent unauthorized APP access. Second, when the mobile phone and the vehicle terminal are paired via HID service, the vehicle BLE generates and stores the mobile phone's IRK as a unique identifier. Subsequent reconnections require verification of IRK consistency, and illegal devices such as those with fake MAC addresses cannot pass identity verification. Third, the HID service channel and sensitive data are encrypted to prevent signals from being recorded and replayed or data from being stolen. The security level of this invention is significantly improved.

[0047] (3) The in-vehicle BLE of the present invention can store multiple sets of mobile phone IRKs. Each IRK corresponds to an independent user identity and personalized parameters. Administrators can set permission levels for different IRKs. This design is suitable for multi-user scenarios such as family members sharing a vehicle and commercial rental vehicles. It does not require additional physical keys or repeated APP binding. New users only need to complete pairing through administrator authorization to use the vehicle, which greatly improves the flexibility of scenario adaptation and solves the problem that existing solutions cannot support multi-user collaboration.

[0048] The core technical solution of this invention is not only applicable to two-wheeled electric vehicles, but can also be directly extended to scenarios that require unlocking and control, such as automobiles and smart home door locks, thereby improving the reusability of the technology and reducing the R&D costs in different scenarios. Attached Figure Description

[0049] Figure 1 This is a diagram illustrating the method steps of an embodiment of the present invention;

[0050] Figure 2 This is the vehicle-mounted BLE dual-broadcast switching process according to an embodiment of the present invention;

[0051] Figure 3 This is a flowchart illustrating the logic of triggering a mobile phone pairing pop-up window using in-vehicle BLE in an embodiment of the present invention.

[0052] Figure 4 This is a design diagram of the sensor-activated unlocking interface according to an embodiment of the present invention;

[0053] Figure 5 Flowchart of the unlocking and locking closed-loop design for an embodiment of the present invention

[0054] Figure 6 This is a circuit diagram of the vehicle control module according to an embodiment of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Example 1

[0057] This embodiment of the mobile phone unlocking multi-user lock system is mainly applied to electric bicycles, but can be extended to electric tricycles, cars, smart home door locks, and other scenarios. Through collaborative interaction between the vehicle-mounted terminal, the user terminal, and the cloud, the system achieves seamless multi-user unlocking, layered security authentication, real-time device status monitoring, and intelligent anomaly handling. The system consists of several parts, including an on-board control module, a mobile phone user module, and a cloud-based auxiliary module. Each module has clearly defined internal functions and a closed-loop data interaction mechanism. The specific structure and functions are described below:

[0058] I. Vehicle Control Module. This is the system's execution unit, integrating communication, authentication, detection, and execution functions. Based on ultra-low power hardware and security protocols, it achieves precise control of multi-user locks, such as... Figure 6 As shown, it includes the following units:

[0059] 1. BLE Communication Unit. This is the core carrier for low-power communication between the vehicle and mobile devices, and can utilize the Onsemi OM6626 BLE 5.3 SoC chip. This chip integrates an ARM Cortex-M0+ core with a maximum clock speed of 48MHz, supports BLE 5.3's LE Audio and long-distance transmission features, and can meet the requirements of multi-user concurrent connections and low power consumption.

[0060] The BLE communication unit supports dynamic switching between dual broadcast modes, such as... Figure 2 As shown, the working logic is as follows: After the vehicle control module is powered on, the BLE communication unit starts connection broadcasting by default. The broadcast content includes the unique identifier of the vehicle device, i.e., the device SN code, the BLE protocol version, the supported encryption algorithm types, and the current status of the device. The transmission power of the connection broadcast is controlled at 10dBm, and the communication coverage distance can reach 50 meters in open environments. Due to the influence of metal parts of the vehicle body, it is optimized to 30 meters in actual applications to ensure stable identification when a user brings their mobile phone close to the vehicle.

[0061] When adding a user or resetting device authentication information, a binding broadcast must be triggered via the mechanical key: the user must turn the mechanical key to the ON position and then back to the OFF position within 5 seconds, performing this operation 6 times consecutively. Once the on-board unit's mechanical key detection circuit detects this specific operation sequence, it immediately stops sending connection broadcasts and switches to binding broadcast mode. The binding broadcast is only used to receive the initial connection key sent by the mobile app, does not respond to any control commands, and lasts for 30 seconds. If no mobile phone successfully connects within 30 seconds, the BLE communication unit automatically switches back to connection broadcast mode, requiring the mechanical key operation to be performed again to trigger binding.

[0062] To reduce power consumption, the unit adopts a dynamic sleep mechanism: when there is no mobile phone connection, the connection broadcast interval is gradually extended from 100ms to 1 second; if there is still no connection after 1 second, it enters a deep sleep state with a sleep current ≤5µA; when a mobile phone Bluetooth signal or mechanical key operation is detected, it is immediately woken up and the normal broadcast interval is restored, balancing power consumption and response speed.

[0063] 2. Identity Authentication Unit. Responsible for unique identification and authorization verification of multiple users, with the goal of preventing unauthorized devices from accessing the system and ensuring vehicle control security. It can employ a dual authentication mechanism of key verification and IRK (Identity Resolving Key) verification.

[0064] The first layer of authentication is key verification: When the mobile app connects for the first time via a binding broadcast, it must send a 16-bit connection key within 30 seconds according to a preset custom protocol. This key is generated by the app using a hash algorithm based on the user account information and the device serial number, and is unique. After receiving the key, the vehicle unit encrypts it using the AES-128 algorithm of the security encryption unit and stores it in the on-chip Flash memory. The storage address uses a random offset design to prevent physical attacks from reading it. Subsequent times the mobile app connects via a connection broadcast, it must resend the connection key within 30 seconds. The vehicle authentication unit retrieves and decrypts the stored encrypted key. If it matches the received key, a communication connection is established. If the match is inconsistent or the key is not sent within the timeout period, the connection is immediately disconnected and an error log is recorded.

[0065] The second layer of authentication is IRK verification: When the mobile phone enables HID (Human Interface Device) and completes pairing, the vehicle unit automatically generates a 16-bit identity resolution key, i.e., IRK, for the mobile phone. The IRK is associated with and stored in conjunction with the hash identifier of the mobile phone's Bluetooth device. The unit supports storing up to 16 sets of IRK information to meet the needs of multi-user scenarios such as multi-member families and car sharing. When the mobile phone approaches the vehicle and initiates automatic reconnection, the vehicle unit first reads the identity identifier in the mobile phone's Bluetooth broadcast, and then verifies the identifier through the IRK. If the parsing result matches the stored IRK list, the user is determined to be legitimate and subsequent operations are allowed; if they do not match, the connection is directly rejected and illegal connection attempts are continuously recorded. After accumulating 10 illegal attempts, the connection broadcast is temporarily shut down for 5 minutes to prevent brute-force attacks.

[0066] To enhance authentication flexibility, the unit supports hierarchical permissions: the IRK corresponding to the administrator user has the function of modifying other users' permissions and resetting the device, while the IRK corresponding to the ordinary user only has the permissions to unlock and lock; permission configuration information is stored in association with the IRK, and modification of permissions requires secondary verification through the administrator key.

[0067] 3. Status Detection and Execution Unit. This unit is responsible for real-time monitoring of the environment and equipment status, and executing operations such as unlocking, locking, and power control according to preset conditions. It is a crucial component for achieving seamless control and safety protection, and includes RSSI signal detection components, status sensor components, and actuator components.

[0068] The core function of the RSSI signal detection component is to calculate the distance between the phone and the vehicle by receiving the RSSI signal strength from the phone's Bluetooth, providing a distance judgment basis for unlocking and locking. The distance conversion formula used is d=10^((abs(RSSI)-50) / (10×3.325)), where the parameters are defined as follows: abs(RSSI) is the absolute value of the phone's Bluetooth signal strength, 50 is the absolute value of the RSSI when the phone and the vehicle device are 1 meter apart, at which point the actual RSSI value is approximately -50dB, and 3.325 is the environmental attenuation factor, adapting to the wireless signal attenuation characteristics of common scenarios such as urban roads and residential areas. The component associates two sets of RSSI thresholds with each stored IRK: Hid_on_rssi (close-to-unlock threshold) and Hid_off_rssi (far-from-lock threshold). The thresholds are configured by the user through a mobile APP, with a configuration range of 0 meters to 20 meters. After configuration, the data is synchronized to the vehicle unit in real time and stored encrypted, and is not lost after power failure.

[0069] The status sensor assembly integrates wheel movement sensors, vibration sensors, and ignition switch status detection circuits to achieve comprehensive vehicle status monitoring. The wheel movement sensors, employing the Hall effect, are mounted at the wheel hubs and determine vehicle movement by detecting the number of wheel rotations. The vibration sensors are piezoelectric, with adjustable sensitivity, and can detect abnormal vibrations such as illegal prying and collisions. The ignition switch status detection circuit determines the ignition switch's current open or closed state by acquiring the voltage signal at the ACC terminal. The assembly monitors at a frequency of 1Hz; if the vehicle is continuously inactive and without vibration for 5 minutes, it is considered stationary. Status data is transmitted in real-time to the onboard MCU, providing a basis for anomaly handling.

[0070] The actuator assembly is responsible for translating control commands into physical actions, and includes a driver-stage MOSFET, a double-pole double-throw relay, and a Bluetooth alarm control circuit. The MOSFET is an N-channel enhancement-type MOSFET with a withstand voltage ≥60V, suitable for 12V to 48V power supply systems for two-wheeled electric vehicles, used to control the on / off state of the ACC circuit. The relay uses a DC 12V coil with a contact current ≥10A, serving as redundant protection for the MOSFET. When the MOSFET fails, the relay can replace it to cut off the ACC circuit, ensuring reliable ignition control. After receiving the execution command, the Bluetooth alarm control circuit can disarm (stop the alarm function when unlocked) and arm (activate the alarm function when locked). In the armed state, if abnormal vibration or unauthorized power is detected, an audible and visual alarm is immediately triggered, lasting for 30 seconds or until the user unlocks the device.

[0071] 4. Security Encryption Unit. This unit ensures the security of system communication and data storage, preventing security risks such as key leakage, instruction tampering, and data theft. Its core functions include HID service encryption, sensitive data encryption, and control instruction verification.

[0072] The implementation logic of HID service encryption is as follows: When the mobile app sends a command to enable the HID function, the security encryption unit immediately sets the access permission of the HID service channel to encrypted mode, and generates a service change report and sends it to the mobile phone. After receiving the report, the mobile phone triggers the system Bluetooth to pop up a pairing interface. Only the paired mobile phone can access the HID service channel. The pairing process uses the ECC-256 elliptic curve cryptography algorithm to generate a session key. Subsequent HID service data interactions are all encrypted using this session key.

[0073] Sensitive data encryption uses the AES-128 block encryption algorithm for stored connection keys, IRKs, user permission configurations, and other data. The encryption key is generated by the vehicle unit based on the chip's unique ID and real-time clock when it is powered on, and is therefore uncopyable. The data storage area uses on-chip secure Flash, which can only be accessed by the secure encryption unit. Other units cannot read or modify it, preventing data theft through the debug interface.

[0074] A control command verification mechanism ensures that received control commands, such as unlock commands and ignition off commands, have not been tampered with or forged. Each control command carries a checksum generated based on the SHA-256 algorithm. The checksum is calculated by combining the command content with a random challenge code generated by the onboard unit. After receiving the command, the onboard unit extracts the command content and the checksum, recalculates the checksum using the locally stored random challenge code, and executes the command only if the checksum matches the received checksum. If they do not match, the command is discarded and an anomaly is logged.

[0075] II. Mobile User Module. Serving as the user interaction platform and identity credential, this module enables seamless control without requiring continuous app operation. It is compatible with both iOS and Android systems and includes the following functional units:

[0076] 1. Bluetooth Communication Unit. Utilizing the Bluetooth module of the mobile phone system, it enables automatic reconnection and data exchange with the vehicle's BLE communication unit. Key features include automatic scanning, stable connection, and signal feedback.

[0077] The implementation logic of the automatic scanning function is as follows: After the mobile phone's Bluetooth is turned on, the Bluetooth communication unit scans the surrounding BLE broadcast signals at 1-second intervals. The scanning range is limited to the broadcast channels commonly used by vehicle devices (channels 37, 38, and 39) to reduce power consumption and interference. When an authenticated vehicle device broadcast is detected, the device's SN code is automatically extracted and compared with the locally stored list of authenticated devices. If the comparison matches, a reconnection request is initiated without requiring manual operation by the user.

[0078] The stable connection mechanism is optimized for weak signal scenarios: In environments with signal obstruction, such as underground parking garages and dense building complexes, if the first reconnection fails, the Bluetooth communication unit automatically adjusts the scanning interval to 500ms, increases the scanning frequency, and reduces the connection timeout to 3 seconds, thereby improving the connection success rate. After the connection is established, adaptive frequency hopping technology is used to avoid interference sources such as WiFi and microwave ovens in the 2.4GHz band, ensuring stable data transmission with a packet loss rate of ≤0.1%.

[0079] The signal feedback function collects the RSSI signal strength between the mobile phone's Bluetooth and the vehicle unit in real time and sends it to the vehicle's RSSI signal detection component at 500ms intervals to provide continuous data support for distance conversion. When the RSSI signal strength fluctuates by more than 10dB, the transmission frequency is automatically increased to 200ms interval to ensure the accuracy of distance judgment.

[0080] 2. APP Interaction Unit. Provides users with a visual entry point for system configuration and device management. Core functions include device binding, HID function control, sensing distance adjustment, and device status viewing. The interface design follows a minimalist principle to reduce the user's operating threshold.

[0081] The device binding function offers a guided operation: the APP homepage displays an "Add Device" button, which leads to a binding guide page with illustrations explaining the steps to trigger the binding broadcast with the mechanical key; simultaneously, Bluetooth scanning is initiated, and after scanning for the binding broadcast, nearby in-vehicle devices are automatically listed. The user selects the target device and clicks "Connect," and the APP generates and sends a connection key; after successful binding, the APP pops up a prompt box displaying the device name and binding time, and adds the device to the "My Devices" list, supporting the management of multiple in-vehicle devices.

[0082] HID function control adopts one-click operation: On the device details page, there are two buttons, "Enable HID" and "Disable HID". After clicking "Enable HID", the APP sends an enabling command to the vehicle unit and displays a pairing guide to prompt the user to complete the Bluetooth pairing of the mobile phone; after clicking "Disable HID", the APP sends a disabling command and triggers the device unpairing process of the mobile phone system to ensure that the mobile phone will not automatically reconnect to the vehicle device after being disabled.

[0083] The sensing distance can be adjusted by sliding the progress bar: for example Figure 4 As shown, the left side of the progress bar indicates "near" (0 meters) and the right side indicates "far" (20 meters). When the user slides the progress bar, the APP calculates the corresponding Hid_on_rssi and Hid_off_rssi values ​​in real time and displays the currently set unlock and lock distances simultaneously. After clicking "Save", the parameters are immediately sent to the vehicle unit, backed up locally, and synchronized to the cloud to avoid parameter loss after changing the phone or reinstalling the APP.

[0084] The device status viewing page displays real-time vehicle information, including the ignition switch status (on / off), arming / disarming status, remaining battery percentage, and the last unlock time. The status data is updated synchronously from the cloud with a refresh interval of 5 seconds. When a vehicle malfunctions, an alarm notification pops up on the page, displaying the alarm type and occurrence time. Users can click "View Details" to obtain more information.

[0085] 3. HID Adaptation Unit. This unit adapts to in-vehicle HID services, enabling automatic reconnection between the mobile phone and the in-vehicle unit. Core optimizations address compatibility differences between different mobile phone systems, ensuring a seamless and consistent experience.

[0086] For iOS systems, the HID adapter unit optimizes the RSSI sampling frequency and connection parameters: the sampling frequency is set to 1Hz to balance data accuracy and power consumption; the connection interval is set to 100ms, the slave latency is set to 0, and the timeout interval is set to 3 seconds to ensure a fast reconnection response; at the same time, it adapts to iOS's Bluetooth permission mechanism, providing permission request guidance when the APP requests Bluetooth permission for the first time, avoiding the inability to reconnect due to permission being closed.

[0087] For Android systems, adaptive parameter adjustments are used to address the differences in Bluetooth drivers across different brands: the connection interval can be adjusted to 120-150ms. At the same time, the background Bluetooth scanning limitation issue on some Android phones is resolved by requesting background services through the APP to ensure that Bluetooth can still scan and reconnect normally after the APP is closed.

[0088] The unit also supports HID service failure recovery: if the reconnection fails or the HID service is disconnected, a retry mechanism is automatically triggered, retrying 3 times with a 1-second interval between each attempt; if the retry fails, the APP will pop up a push notification to prompt the user to check the Bluetooth status or vehicle power, ensuring that the user is aware of the problem in a timely manner.

[0089] 4. Personalized Configuration Unit. This unit allows users to customize their system usage habits to meet the needs of different scenarios and users. Core functions include permission management, unlock reminder settings, reconnection priority configuration, and scene mode presets.

[0090] The permission management function distinguishes between administrators and ordinary users: Administrators can add other users on the "Permission Settings" page by entering the authorized user's mobile phone number or APP account and selecting the permission type; ordinary users only have unlock and lock permissions and cannot modify parameters such as sensing distance; temporary users can set the authorization period from 1 hour to 30 days, and the permissions will automatically expire after the expiration, without the need for manual deletion.

[0091] The unlock reminder settings offer multiple options: users can choose between three reminder methods: "vibration," "ringtone," and "vibration and ringtone." The vibration intensity is divided into three levels: weak, medium, and strong. The ringtone can be selected from the phone's system ringtone. After setting, when the phone successfully reconnects to the vehicle unit and unlocks, the corresponding reminder method will be triggered to inform the user that the unlock was successful.

[0092] The reconnection priority configuration is designed for multi-device scenarios: When there are multiple certified in-vehicle devices near a user's mobile phone, the device order can be adjusted on the "Device Priority" page, with higher-priority devices being scanned and reconnected first; for example, if a user has both a home electric vehicle and a commuter electric vehicle, the commuter electric vehicle can be set as the high priority to ensure that the correct device is automatically connected during daily commutes.

[0093] The scene mode presets offer quick configuration: three preset modes are built-in, namely "Commuter Mode", "Leisure Mode" and "Sharing Mode". The commuter mode has a default unlock distance of 1 meter and a lock distance of 4 meters, which is suitable for quick getting on and off the vehicle; the leisure mode has a default unlock distance of 2 meters and a lock distance of 5 meters, which is suitable for short stops after parking; and the sharing mode has a default unlock distance of 3 meters and a lock distance of 6 meters, which is suitable for multiple people to share the vehicle. Users can directly select the mode to apply, or modify the preset parameters and save it as a custom mode.

[0094] III. Cloud-based Auxiliary Module. The cloud-based auxiliary module is built on a cloud server and provides services such as user management, remote upgrades, and status synchronization, supporting the system's scalability and reliability. It includes the following units:

[0095] 1. User Account Management Unit. This unit establishes a unique account for each user, linking the user's mobile device and in-vehicle device to achieve unified management of user identity and permissions.

[0096] User registration and login employ multi-factor authentication: users register accounts using their mobile phone numbers and complete verification by receiving SMS verification codes; login supports "password login," "SMS verification code login," and "biometric login." Biometric login is only available when the mobile phone supports it and the user enables it, thus improving login security.

[0097] The account is associated with a unique device: when a user adds a vehicle device, the APP sends the mobile device ID and the vehicle device SN code to the cloud, and the cloud records the association relationship.

[0098] Operation log management supports traceability and export: Every user operation is recorded in the cloud, including unlocking, locking, permission modification, and parameter adjustment. The log content includes operation time, operation type, operation result, and device information. Logs are stored for 180 days by default and are automatically archived after the storage period. Users can view historical logs in the "Log Center" of the APP, which supports filtering by time range. Clicking "Export" can save the logs as CSV format for easy viewing later.

[0099] 2. OTA Upgrade Unit. This unit provides remote upgrade services for the vehicle control module and mobile APP, supporting incremental and full upgrades to ensure continuous system function optimization and security vulnerability patching.

[0100] The upgrade package management adopts a layered design: For the vehicle control module, the upgrade package is divided into firmware packages and configuration packages. The firmware package includes BLE chip firmware, MCU firmware, etc., while the configuration package contains encryption algorithm parameters, default thresholds, etc. For the mobile app, the upgrade package is divided into a full upgrade installation package and an incremental upgrade resource package. All upgrade packages are verified using RSA signatures to ensure the legitimate source of the upgrade packages and prevent malicious tampering.

[0101] The upgrade process supports breakpoint resumption and rollback: When the vehicle unit or APP receives the upgrade package, if the network is interrupted, it will continue to receive the package from the point of interruption when it reconnects, without having to download it again; if an abnormality such as power failure or upgrade failure occurs during the upgrade process, the system will automatically trigger the rollback mechanism to restore the version before the upgrade, so as to avoid the device becoming unusable.

[0102] The upgrade strategy supports phased rollout: The cloud adopts a canary release strategy, first pushing the upgrade package to 10% of users and monitoring the upgrade success rate and anomaly feedback within 24 hours; if the anomaly rate is ≤0.5%, then pushing it to 30% of users; if there are still no anomalies, finally pushing it to the remaining 60% of users, reducing the risk of large-scale upgrades.

[0103] 3. Status Synchronization Unit. This unit enables real-time synchronization of status between the mobile phone, in-vehicle equipment, and the cloud, ensuring that users can always monitor the vehicle's status and handle any abnormal situations promptly.

[0104] Status data synchronization adopts bidirectional transmission: the vehicle control module uploads the ignition status, arming status, RSSI data, and sensor data to the cloud at 5-second intervals; the cloud updates the data immediately upon receiving it and synchronizes it to the mobile APP at 10-second intervals to ensure that the status displayed in the APP is consistent with the actual status of the vehicle; when the user modifies parameters such as sensing distance through the APP, the parameters are first sent to the cloud for backup, and then forwarded by the cloud to the vehicle unit to achieve bidirectional synchronization.

[0105] Anomaly alarms are pushed in a tiered manner: the cloud classifies vehicle anomalies into two levels. Level 1 alarms include unauthorized tampering, ignition left on for more than 5 minutes, and battery malfunctions. Upon triggering, an alarm notification is immediately pushed to the administrator's mobile phone, via the app, and via SMS. Level 2 alarms include Bluetooth connection failures and weak RSSI signals. Upon triggering, an app notification is pushed after a 1-minute delay to avoid false alarms. Alarm notifications include the anomaly type, time of occurrence, and vehicle location. Clicking the notification will take the user to the anomaly handling page in the app to view solutions.

[0106] Cross-device synchronization supports parameter migration: When a user changes their phone, after logging into the same cloud account, the APP automatically synchronizes the previous device list, sensing distance settings, permission configurations and other parameters from the cloud without the need for reconfiguration; if the user deletes the APP on their phone and reinstalls it, all parameters can still be synchronized after logging in, ensuring a consistent user experience.

[0107] Example 2

[0108] This embodiment of the mobile phone unlocking multi-user lock method is based on the system implementation of Embodiment 1. Through the process of initialization binding, identity authentication, seamless control, and abnormal closed-loop, it realizes secure and convenient unlocking and locking for multiple users, while also covering intelligent handling of abnormal scenarios. Figure 1 As shown, it includes the following steps:

[0109] S1: System Initialization and Binding. This step involves basic configuration during the first use of the system. The goal is to establish an initial trust relationship between the mobile phone and the in-vehicle device, generate and store the connection key, and ensure secure subsequent communication. For example... Figure 1 As shown, the specific process is as follows:

[0110] S11: Vehicle BLE Startup Connection Broadcast. After the vehicle control module is powered on, it first completes hardware initialization, including self-tests of the MCU, BLE chip, and sensors; after the self-tests pass, the BLE communication unit automatically starts the connection broadcast mode.

[0111] The connection broadcast contains four key pieces of information: the unique identifier of the vehicle-mounted device (i.e., the device's 16-character serial number), the BLE protocol version, the supported encryption algorithm types AES-128 and ECC-256, and the device's current unbound status. The broadcast interval is initially set to 100ms; if no mobile phone connects for 30 seconds, the interval is extended to 500ms. If there is no connection for 5 minutes, the BLE communication unit enters a deep sleep state.

[0112] In sleep mode, the vehicle unit supports two wake-up methods: one is by the user operating the mechanical key and turning it to the ON position; the other is by detecting the Bluetooth signal of the paired mobile phone. After being woken up, the BLE communication unit immediately resumes connection broadcasting, the interval is reset to 100ms, and it re-enters the connection waiting state.

[0113] S12: Trigger vehicle binding broadcast. The user needs to trigger the binding broadcast through a specific operation of the mechanical key. The operation steps must strictly follow the timing requirements: The user holds the mechanical key, inserts it into the lock cylinder, and turns it to the ON position. The ignition is not turned on, only the detection circuit is triggered. After holding it for 1 second, turn it back to the OFF position. This operation must be performed 6 times consecutively within 5 seconds.

[0114] The mechanical key detection circuit of the vehicle unit collects the lock cylinder's position signal in real time. When it detects that the "ON-OFF" operation occurs 6 times in a row and the total duration is ≤5 seconds, it immediately sends a control signal to the BLE communication unit to stop the current connection broadcast and switch to the binding broadcast mode.

[0115] The binding broadcast contains only two pieces of information: the device serial number and the binding request identifier. It does not respond to any control commands. The binding broadcast lasts for 30 seconds. If no mobile phone successfully connects within 30 seconds, the BLE communication unit automatically switches back to the connection broadcast mode. The user needs to perform the mechanical key operation again to trigger the binding.

[0116] S13: The mobile app sends and stores the binding key. After logging in to their account, the user opens the corresponding app on their phone and clicks the "Add Device" button on the homepage. The app then enters the device binding page and activates the Bluetooth scanning function, scanning only broadcast signals of BLE 5.0 and above.

[0117] When the app scans for a linked broadcast, it automatically lists nearby in-vehicle devices on the page, displaying the last 6 characters of the device's serial number (SN) while hiding the first 10 characters to protect privacy. After the user confirms the target device, they click the "Connect" button, and the app establishes a temporary connection with the in-vehicle BLE communication unit.

[0118] Once the connection is established, the APP immediately generates a 16-bit connection key: the key is calculated based on the user account ID, device SN code, and current timestamp, and the first 16 bits are extracted after calculation using the SHA-256 algorithm; after generation, the APP sends the key to the vehicle unit according to a custom protocol, and the sending process is encrypted using the ECC-256 algorithm to prevent it from being stolen during transmission.

[0119] After receiving the key, the vehicle-mounted security encryption unit first decrypts it using the ECC-256 algorithm, and then uses the AES-128 algorithm to encrypt and store the key in the on-chip secure Flash. The storage address is generated based on the hash value of the device's serial number and is unique. After storage, the vehicle-mounted BLE communication unit actively disconnects from the APP and switches back to the connection broadcast mode.

[0120] After the APP detects that the connection has been lost, a "Binding Successful" prompt box will pop up, displaying the device name and binding time. The device name defaults to "Vehicle Lock Device + Last 4 Digits of SN". At the same time, the device will be added to the "My Devices" list, completing the system initialization and binding steps.

[0121] S2: Multi-user authentication and pairing. This step is the configuration process for adding new users or using the HID function for the first time. Its core is to complete secondary authentication of user identities and adapt to the HID service, ensuring secure multi-user access. The specific process is as follows:

[0122] S21: Mobile App Connects to Vehicle Connectivity Broadcast. New users open the app on their mobile phones and log in to their accounts. Administrators must grant the account prior authorization to access the target vehicle device. Users then access the "My Devices" list, select the target vehicle device, and click the "Connect" button. The app will then initiate a Bluetooth scan to search for the device's connectivity broadcast.

[0123] When the APP scans the connection broadcast of the target device, it automatically initiates a connection request. After receiving the request, the vehicle BLE communication unit does not directly establish a connection, but triggers the key verification process of the identity authentication unit and sends a "key request" instruction to the APP, requesting the APP to provide the connection key.

[0124] If the app does not receive the "key request" instruction within 10 seconds, it will automatically retry the connection, up to 3 times. If all 3 retries fail, the app will display a message "The current device is not responding. Please check the vehicle's power supply" to guide the user in troubleshooting.

[0125] S22: The APP sends the key and completes verification. After receiving the "Key Request" instruction, the APP displays an "Enter Connection Key" dialog box. If the account is an administrator account, the APP automatically retrieves the locally stored connection key, eliminating the need for manual input. If the user is a regular or temporary user, they must manually enter the 16-character connection key provided by the administrator, which is case-sensitive.

[0126] After the user confirms the input, the APP sends the key to the vehicle unit according to the preset protocol. The sending process is encrypted using the AES-128 algorithm. After receiving the key, the vehicle identity authentication unit extracts and decrypts it, and compares it with the connection key stored in the secure Flash.

[0127] The comparison results fall into three categories: First, if the comparison matches, the vehicle unit sends a "verification successful" command to the APP and establishes a stable communication connection. Second, if the comparison does not match, the vehicle unit sends a "key error" command, the APP displays a prompt and allows the user to re-enter the key, with a maximum of 3 attempts allowed. After 3 incorrect attempts, the vehicle unit temporarily disables the connection broadcast for 5 minutes to prevent brute-force attacks. Third, if the key is not sent within 30 seconds, the vehicle unit automatically disconnects, and the APP prompts "key input timed out, please reconnect."

[0128] S23: Enable HID function and complete pairing. For example... Figure 3 As shown, after successful verification, the APP redirects to the device details page. The user clicks the "Enable HID" button, and the APP sends the "HID Enable" command to the vehicle unit. After receiving the command, the vehicle security encryption unit immediately switches the access permission of the HID service channel to encryption mode and generates a service change report, which includes the UUID of the HID service and the encryption status identifier, and sends it to the mobile APP.

[0129] After receiving the service change report, the APP triggers the Bluetooth pairing process of the mobile phone system. The "Bluetooth Pairing Request" dialog box pops up on the mobile phone interface, and at the same time displays a 4-digit random pairing code generated by the vehicle device. This code is generated by the vehicle security encryption unit based on the device's serial number and the current time. The user needs to verify whether the pairing code displayed on the APP is consistent with the pairing code in the mobile phone's Bluetooth dialog box. After confirming that they are consistent, click the "Pair" button.

[0130] During pairing, the mobile phone and the vehicle unit generate a temporary session key using the ECC-256 algorithm. All subsequent data interactions for the HID service are encrypted using this session key. After successful pairing, the APP will display a "HID function is enabled" message and the device details page will show "HID status: enabled", informing the user that automatic reconnection is possible in the future.

[0131] If pairing fails, such as when the user clicks "Cancel" or enters an incorrect pairing code, the app will display "Pairing failed, please try again." The user can then click the "Enable HID" button again to re-initiate pairing, with no limit on the number of retries.

[0132] S24: Store IRK and configure personalized RSSI. After successful HID pairing, the vehicle identification unit automatically generates a 16-bit IRK for the mobile phone. The IRK is calculated based on the hash identifier of the mobile phone's Bluetooth device and the security key of the vehicle device, and is unique. After generation, the IRK is associated with the mobile phone's Bluetooth device identifier and stored in the on-chip secure Flash. At the same time, an independent parameter storage area is allocated for the user to store the RSSI threshold.

[0133] On the device details page of the app, users can click "Sensing Distance Settings" to enter the adjustment interface. The interface displays a progress bar from 0 meters to 20 meters, along with the currently set unlock and lock distances. The default unlock distance is 1 meter, and the default lock distance is 4 meters. As the user slides the progress bar, the app calculates the corresponding Hid_on_rssi and Hid_off_rssi values ​​in real time. For example, when the unlock distance is set to 1.5 meters, Hid_on_rssi is approximately -55dB, and when the lock distance is set to 4.5 meters, Hid_off_rssi is approximately -71dB. The calculation results are displayed on the interface in real time.

[0134] After the user confirms the settings and clicks the "Save" button, the APP sends the Hid_on_rssi and Hid_off_rssi values ​​to the vehicle unit. After receiving the parameters, the vehicle status detection and execution unit encrypts and stores them in the corresponding user parameter area, and sends a "Parameter saved successfully" command to the APP. After receiving the command, the APP pops up a "Settings have taken effect" prompt, completing the multi-user authentication and pairing steps.

[0135] S3 Seamless Unlocking and Locking. This is the core process for daily user interaction. No manual app operation is required; simply bring your authenticated phone near or away from the vehicle, and automatic unlocking and locking will be achieved through the collaborative interaction between the vehicle unit and the phone. The core process involves IRK identity verification, precise RSSI distance judgment, and actuator linkage. The specific process is as follows:

[0136] The S31 mobile phone automatically reconnects to the vehicle's BLE via Bluetooth. When a user approaches the vehicle with their HID-paired phone, ensuring Bluetooth is enabled, there's no need to manually launch the corresponding system app. The phone's Bluetooth communication unit initiates a scan according to a preset strategy: it prioritizes scanning channel 39, a commonly used broadcast channel for BLE devices with minimal interference, with a scan interval of 500ms. If no target vehicle device broadcast is detected within 1 second, it then scans channels 38 and 37 sequentially, shortening the scan interval to 300ms to improve scanning efficiency in weak signal environments.

[0137] When a certified in-vehicle device is detected connecting to the broadcast, the mobile phone HID adapter automatically extracts the device's serial number (SN) from the broadcast and matches it against the locally stored list of certified devices. Upon a match, a reconnection request is immediately initiated, carrying the hash identifier of the mobile phone's Bluetooth device for subsequent IRK verification. After receiving the reconnection request, the in-vehicle BLE communication unit establishes a communication link directly based on the fast connection characteristics of the BLE protocol without waiting for app intervention. The connection establishment time is short, ensuring a seamless experience.

[0138] If the initial reconnection fails, such as due to signal obstruction causing link interruption, the mobile phone's Bluetooth communication unit automatically triggers a retry mechanism: the first retry interval is 500ms, the second retry interval is 1000ms, and the third retry interval is 2000ms. If all three retries fail, the mobile phone system will silently prompt the user through the notification bar of iOS or the status bar icon of Android, informing the user that "the connection to the vehicle device has not been successfully completed. Please check the Bluetooth status or move closer to the vehicle," to avoid the user missing status information.

[0139] The S32 vehicle unit verifies the mobile phone IRK. After the communication link is established, the vehicle authentication unit immediately extracts the Bluetooth device hash identifier from the mobile phone's reconnection request, and at the same time retrieves the list of all user IRKs stored in the independent partition of the on-chip secure Flash.

[0140] The identity authentication unit performs verification according to the following logic: First, it matches the mobile phone's Bluetooth device hash identifier with the "device identifier-IRK mapping relationship" corresponding to each IRK in the IRK list. If no matching mapping relationship is found, the device is determined to be unauthorized, the communication link is immediately disconnected, and this unauthorized connection attempt is recorded in the local log. If a matching mapping relationship is found, the user permission status associated with that IRK is further verified. Administrator users and ordinary users need to confirm whether their permissions are in a "valid" state, and temporary users need to additionally confirm whether their authorization period has expired.

[0141] If the permission status is valid, the vehicle-mounted identity authentication unit sends an "identity verification passed" command to the status detection and execution unit, allowing the subsequent distance judgment process to proceed. If the permission status is invalid, such as when a temporary user's authorization expires or an administrator manually freezes a regular user's permissions, the communication link is also disconnected, and an invalid permission log is recorded. When a total of 10 illegal connection attempts are detected, the vehicle-mounted BLE communication unit temporarily disables the connection broadcast for 5 minutes. During the shutdown period, it only responds to the binding broadcast triggered by the mechanical key to prevent brute-force attacks.

[0142] S33 determines the distance and triggers the operation based on RSSI. After receiving the "identity verification passed" command, the status detection and execution unit starts the RSSI signal detection component, collects the RSSI signal strength of the mobile phone Bluetooth at 200ms intervals, and simultaneously starts 5 moving average filtering processes to remove errors caused by instantaneous signal fluctuations and obtain a stable RSSI average value.

[0143] The execution unit calculates the actual distance between the mobile phone and the vehicle based on a preset formula: d=10^((abs(RSSI mean)-A) / (10×n)), where the parameters are defined as follows: abs(RSSI mean) is the absolute value of the filtered RSSI signal strength; A is the absolute value of RSSI when the mobile phone and the vehicle device are 1 meter apart, with a default value of 50, which can be adjusted through OTA upgrades to adapt to the differences in Bluetooth transmission power of different mobile phone models; n is a dynamic environmental attenuation factor. The vehicle unit collects environmental data once per hour. If the deviation between the RSSI mean value collected for 3 consecutive times and the theoretical calculated value exceeds 15%, n will be automatically adjusted from the default 3.325 to the optimal value in the range of 3.0-3.6 to ensure the accuracy of distance calculation in scenarios such as rainy days and dense building clusters.

[0144] The execution unit compares the calculated actual distance with the RSSI threshold associated with the user's IRK. Hid_on_rssi corresponds to the unlock distance, and Hid_off_rssi corresponds to the lock distance. The operation is triggered according to the following logic:

[0145] (1) When the actual distance is less than or equal to the unlocking distance: The execution unit sends a "disarm, allow ignition start" command to the actuator component. The Bluetooth alarm stops the arming state, the MOSFET turns on the ACC ignition circuit, and the relay is simultaneously in the standby conduction state. If the MOSFET fails, the relay can immediately take over the conduction to ensure the ignition power supply. At the same time, a "unlocking preparation complete" command is sent to the mobile phone, and the user can use it normally by pressing the vehicle start button.

[0146] (2) When the user is far away from the vehicle and the actual distance is greater than or equal to the locking distance: The actuator first determines the ignition status through the ignition detection circuit. If the ignition is closed, it directly sends an "arming" command to the actuator component, the Bluetooth alarm starts the arming state, and both the MOSFET and the relay disconnect the ACC circuit to complete the locking. If the ignition is not closed, the locking is not triggered temporarily, and the S4 abnormal handling process is entered instead.

[0147] S34 sends the operation result to the mobile phone. After the unlocking or locking operation is completed, the vehicle BLE communication unit immediately sends the operation result command to the mobile phone. The command includes the unlocking / locking operation type, operation time, and current vehicle status. For example, after unlocking, the command will send the message "Electric ignition is allowed to start"; after locking, the command will send the message "Armed, ACC circuit disconnected".

[0148] After receiving the command, the mobile phone HID adapter unit triggers feedback according to the system type: For iOS systems, a silent notification is sent via the notification bar, without a pop-up window, only displayed in the pull-down notification bar with the content "[Last 4 digits of the vehicle device SN] Unlocked, ignition can be started"; for Android systems, a status bar icon and a pop-up notification are displayed with the content "Vehicle device is locked, currently armed". Simultaneously, the mobile phone Bluetooth communication unit synchronizes the operation result to the APP background. The next time the APP is launched, the operation record is automatically updated to the "Device Log" page, allowing users to easily trace historical operations.

[0149] S4 Anomaly Handling and Closed-Loop Control. This step addresses anomalies such as ignition switch not being turned off, vehicle stationary time exceeding the specified period, and actuator malfunction. Through real-time monitoring, tiered processing, and closed-loop feedback, it achieves automatic control, preventing safety risks and equipment damage. The specific process is as follows:

[0150] The S41 monitors multi-dimensional status in real time. The onboard status detection and execution unit initiates a multi-dimensional monitoring mechanism, with a monitoring frequency of 1Hz. Monitoring data is uploaded to the cloud-based status synchronization unit in real time, synchronizing every 5 seconds. Simultaneously, the monitoring data for the most recent 10 minutes is cached locally to prevent data loss due to network interruptions. Specific monitoring dimensions include:

[0151] (1) Status of the switch and actuator: The switch is determined to be open by the voltage signal of the ACC terminal of the switch. If the voltage is ≥12V, it is considered open; if it is <5V, it is considered closed. The feedback pin signals of the MOSFET and the relay are used to determine whether they are in normal on / off state. A high level feedback signal indicates normal operation, and a low level indicates a fault. When there is a fault, the fault code is recorded: E01 for MOSFET fault and E02 for relay fault.

[0152] (2) Vehicle movement and environmental status: The wheel motion sensor detects the number of wheel rotations. If the number of rotations is 0 for 5 consecutive minutes, it is determined that there is no wheel motion. The vibration sensor detects the vibration intensity of the vehicle. If it exceeds the preset threshold of 200mg, it is determined to be abnormal vibration. The threshold can be configured through the APP. The battery voltage detection circuit collects the battery pack voltage. If it is lower than 30V, it is determined to be low battery and a charging reminder is required.

[0153] (3) BLE connection status: The BLE communication unit monitors the stability of the link with the mobile phone. If the link is interrupted three times in a row and the retry fails, it is determined to be a connection abnormality. At the same time, the broadcast signal strength is monitored. If it is lower than -80dB, it is determined to be a weak signal and the user needs to be reminded to move closer.

[0154] When any monitoring dimension shows an anomaly, the execution unit immediately marks the anomaly type and the time of occurrence, and triggers subsequent hierarchical processing procedures to ensure that the anomaly does not escalate.

[0155] S42 Automatic power shut-off after a timeout period while stationary. For example... Figure 5As shown, the state detection and execution unit uses data from wheel movement and vibration sensors to determine whether the vehicle is stationary and whether there has been no wheel movement or vibration for 5 consecutive minutes. The stationary duration can be customized within the range of 1-10 minutes via the app. If the ignition is detected to be on and the vehicle has been stationary for more than the specified time, the execution unit initiates the ignition-off process.

[0156] First, a "power off" command is sent to the actuator component to control the MOSFET to disconnect the ACC circuit. After 10 seconds, the power detection circuit determines whether the power is off. If it is off, a "power off automatically closed successfully" log is recorded. If it is not off, such as a MOSFET failure preventing disconnection, the actuator triggers a retry mechanism: the first retry interval is 10 seconds, controlling the relay to disconnect the ACC circuit; the second retry interval is 20 seconds, simultaneously controlling the MOSFET and relay to disconnect; the third retry interval is 30 seconds, repeating the linkage disconnection operation.

[0157] If all three retries fail, the execution unit sends an "Electric switch off failed" alarm command to the cloud. The cloud immediately pushes a tiered alarm to the administrator's mobile phone and records the fault details locally on the vehicle unit to facilitate subsequent troubleshooting by maintenance personnel.

[0158] Automatic arming is triggered when the S43 ignition is turned off. After the ignition is successfully turned off, the execution unit switches back to the normal locking judgment process and optimizes the arming strategy by combining vehicle location information: the vehicle unit determines whether the vehicle is in a security zone preset by the administrator through linkage with the mobile phone GPS, such as a home garage or company parking lot. Security zones can be added on the "Scene Settings" page of the APP.

[0159] If the vehicle is in a safe area, the execution unit sets the arming delay time to 2 minutes, allowing the user to temporarily retrieve or place items after turning off the ignition without having to unlock the device again. During the delay, the unit continuously monitors changes in the phone's distance. If the phone's distance remains less than or equal to the unlocking distance within 2 minutes, the arming delay is extended every minute, up to a maximum of 5 minutes. If the phone's distance is greater than or equal to the locking distance within 2 minutes, arming is triggered immediately.

[0160] If the vehicle is in an unsafe area, the actuator triggers arming without delay: it controls the Bluetooth alarm to activate the arming state, and simultaneously disconnects the ACC circuit between the MOSFET and the relay to complete locking. After arming is completed, the actuator sends an "arming successful" command to the cloud and the mobile phone. The cloud updates the vehicle status to "armed," and the mobile phone provides feedback on the arming result through system notification, ensuring vehicle safety in different scenarios.

[0161] The embodiments of the present invention achieve contactless unlocking through the above steps, and can be extended to scenarios such as automobiles and smart home door locks that require multi-user authorization for unlocking.

[0162] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A multi-user lock system for unlocking mobile phones, characterized in that, This includes an in-vehicle control module, a mobile user module, and a cloud-based auxiliary module; The vehicle control module includes a BLE communication unit, an identity authentication unit, a status detection and execution unit, and a security encryption unit. The BLE communication unit performs dynamic switching and dynamic sleep mechanisms for dual broadcast modes. The identity authentication unit adopts a dual authentication mechanism of key verification and IRK verification and performs hierarchical access control. The status detection and execution unit calculates distance by signal strength and combines sensors and actuators to trigger operations. The security encryption unit provides security protection for HID services, sensitive data, and control commands. The mobile phone user module includes a Bluetooth communication unit, an APP interaction unit, an HID adaptation unit, and a personalized configuration unit. The Bluetooth communication unit performs automatic scanning and stable connection. The APP interaction unit provides device binding, HID function control, sensing distance adjustment, and device status viewing functions. The HID adaptation unit adapts to different mobile phone systems and supports abnormal recovery. The personalized configuration unit supports permission management, unlock reminder settings, reconnection priority configuration, and scene mode presets. The cloud-based auxiliary module is built on a cloud server and includes a user account management unit, an OTA upgrade unit, and a status synchronization unit. The user account management unit performs multi-factor authentication, device association, and operation log management. The OTA upgrade unit performs hierarchical upgrade package management, breakpoint resume, and canary release. The status synchronization unit performs bidirectional data synchronization, hierarchical anomaly alarms, and cross-device parameter migration.

2. The mobile phone unlocking multi-user lock system according to claim 1, characterized in that, The vehicle control module's BLE communication unit uses a Bluetooth Low Energy SoC chip; the dual broadcast mode includes connection broadcast and binding broadcast. Connection broadcast is enabled by default, while binding broadcast is triggered by continuous operation of the mechanical key to receive the initial connection key; under the dynamic sleep mechanism, the connection broadcast interval gradually increases when there is no mobile phone connection until it enters a deep sleep state. When a mobile phone Bluetooth signal or mechanical key operation is detected, it is woken up and the normal broadcast interval is restored. In the identity authentication unit of the vehicle control module, the connection key for key verification is generated and intercepted by the mobile APP based on the user account information and the device SN code through a hash algorithm. After receiving it, the vehicle unit encrypts and stores it in the on-chip Flash, and the storage address adopts a random offset design. The IRK verification generates an IRK when the mobile phone enables the HID function for pairing and stores it in association with the hash identifier of the mobile phone's Bluetooth device. When reconnecting, the mobile phone's Bluetooth broadcast identity identifier is parsed and matched with the IRK list.

3. The mobile phone unlocking multi-user lock system according to claim 1, characterized in that, The vehicle control module's status detection and execution unit includes an RSSI signal detection component, a status sensor component, and an actuator component. The RSSI signal detection component calculates distance using the formula d=10^((abs(RSSI)-50) / (10×3.325)), which is used to associate the proximity unlock threshold and distance lock threshold for each IRK group. The status sensor component includes a Hall effect wheel sensor, a piezoelectric vibration sensor, and an ignition switch status detection circuit; no wheel movement and no vibration within a preset time period indicate a stationary state. The actuator component includes a MOSFET, a DC relay, and a Bluetooth alarm control circuit; when the Bluetooth alarm is armed, abnormal vibration or unauthorized power-on triggers an audible and visual alarm.

4. The mobile phone unlocking multi-user lock system according to claim 1, characterized in that, In the security encryption unit of the vehicle control module, HID service encryption triggers mobile phone Bluetooth pairing by generating a service change report. Pairing uses an encryption algorithm to generate a temporary session key. Sensitive data uses a block encryption algorithm. The encryption key is generated based on the chip's unique ID and real-time clock. The data is stored in on-chip secure Flash. Control command verification generates a checksum through a hash algorithm. The checksum is calculated from the command content and the random challenge code of the vehicle unit. The command is executed after the comparison is consistent.

5. The mobile phone unlocking multi-user lock system according to claim 1, characterized in that, The Bluetooth communication unit of the mobile phone user module scans the BLE broadcast signal and adopts adaptive frequency hopping technology after the connection is established; the HID adaptation unit sets the sampling frequency and connection interval for iOS or Android systems. In the OTA upgrade unit of the cloud-assisted module, the upgrade package is divided into firmware and configuration packages for the vehicle control module, and full installation package and incremental resource package for the mobile APP. The upgrade package uses RSA signature verification. The upgrade process supports breakpoint resume. In the status synchronization unit, the cloud synchronizes the status data uploaded by the vehicle control module to the mobile APP at fixed intervals. When the user modifies the parameters, the data is first synchronized to the cloud and then forwarded to the vehicle unit.

6. A method for unlocking a multi-user lock on a mobile phone, characterized in that, The system implementation based on any one of claims 1-5 includes the following steps: S1: System initialization and binding: Establish the initial trust relationship between the mobile user module and the vehicle control module. The vehicle BLE communication unit starts the connection broadcast, triggers the vehicle binding broadcast, and the mobile APP sends and stores the binding key. S2: Multi-user authentication and pairing, completes secondary verification of user identity and HID service adaptation, mobile APP connects to vehicle connection broadcast, APP sends key and completes verification, enables HID function and completes pairing, stores IRK and configures personalized RSSI; S3: Seamless unlocking and locking, relying on automatic reconnection, IRK verification and RSSI judgment to achieve automatic operation. The mobile phone automatically reconnects to the vehicle's BLE communication unit via Bluetooth. The vehicle control module verifies the mobile phone's IRK, determines the distance based on RSSI and triggers the operation, and sends the operation result back to the mobile phone. S4: Abnormal handling and closed-loop control, including real-time monitoring of status, shutting off the power switch after a timeout while stationary, and triggering arming after the power switch is shut off.

7. The method for unlocking a multi-user lock on a mobile phone according to claim 6, characterized in that, S1 includes the following steps: S11: After the vehicle control module is powered on, it completes a hardware self-test. After the self-test is passed, the BLE communication unit starts connection broadcasting. If there is no connection, the BLE communication unit enters a deep sleep state. In the deep sleep state, it can be woken up by a mechanical key or by detecting the Bluetooth signal of a bound mobile phone. After waking up, connection broadcasting is resumed. S12: After the mechanical key detection circuit recognizes that the mechanical key has continuously executed multiple operation sequences, the BLE communication unit stops the connection broadcast and switches to the binding broadcast. The binding broadcast includes the device SN code and the binding request identifier. S13: After logging into the account on the mobile APP, click "Add Device" to start Bluetooth scanning and identify the binding broadcast. After the user selects the target device, the APP establishes a temporary connection with the vehicle BLE communication unit. The APP calculates the connection key based on the user account ID, device SN code, and current timestamp, encrypts it, and sends it to the vehicle control module. The vehicle identity authentication unit decrypts the key, re-encrypts it, and stores it in a secure address. The vehicle BLE communication unit disconnects and switches back to connection broadcast. After the APP detects the disconnection, it pops up a binding success prompt and adds the device to the "My Devices" list.

8. The method for unlocking a multi-user lock on a mobile phone according to claim 6, characterized in that, S2 includes the following steps: S21: After a new user logs into the APP and is authorized by the administrator to access the target vehicle control module, the APP starts Bluetooth scanning for connection broadcasts of the target device; after the APP initiates a connection request, the vehicle BLE communication unit triggers the identity authentication unit to send a key request instruction. S22: After receiving the key request instruction, the APP retrieves the locally stored connection key, and the ordinary user or temporary user manually enters the connection key; the APP encrypts the key and sends it to the vehicle control module, the vehicle identity authentication unit decrypts it and compares it with the stored key; if the comparison is consistent, a communication connection is established. S23: After successful verification, the user clicks the HID enable button, and the APP sends the HID enable command to the vehicle control module; the vehicle security encryption unit sets the HID service channel to encrypted mode, generates a service change report containing the HID service UUID and encryption status identifier, and sends it to the APP; the APP triggers the mobile phone Bluetooth pairing process, the vehicle unit generates a random pairing code, and the user clicks to pair after verifying that the pairing code matches. S24: After successful HID pairing, the vehicle identification unit generates an IRK and associates the IRK with the mobile phone's Bluetooth identifier, storing it in a secure address. The user adjusts the unlocking and locking distances on the APP by sliding the progress bar. The APP calculates the corresponding Hid_on_rssi and Hid_off_rssi values ​​in real time and sends them to the vehicle control module. The vehicle status detection and execution unit encrypts and stores the parameters, then reports successful saving, and the APP prompts that the settings have taken effect.

9. The method for unlocking a multi-user lock on a mobile phone according to claim 6, characterized in that, S3 includes the following steps: S31: When the user carries a paired mobile phone with Bluetooth enabled, the mobile phone's Bluetooth communication unit scans the BLE channel; after scanning and broadcasting the connection of an authenticated vehicle control module, it extracts the SN code and matches it with the local authentication list. If the match is consistent, it initiates a reconnection request; and establishes a communication link based on the BLE fast connection feature. S32: The vehicle-mounted authentication unit extracts the Bluetooth hash identifier from the reconnection request, retrieves the stored IRK list for matching; after matching, it verifies the user's permission status; if the permission is valid, it sends an identity verification pass command; S33: After receiving the verification pass command, the vehicle status detection and execution unit collects the mobile phone Bluetooth RSSI signal and performs a sliding average filter; it calculates the actual distance based on the formula d=10^((abs(RSSI mean)-A) / (10×n)), where A is the absolute value of RSSI at a distance of 1 meter and n is the dynamic environment attenuation factor; when the actual distance is ≤ the unlocking distance, it controls the Bluetooth alarm to disarm and the MOSFET to turn on the ACC circuit; when the actual distance is ≥ the locking distance, it controls the alarm to arm and disconnects the ACC circuit when the detection switch is closed. S34: The vehicle-mounted BLE communication unit sends a result command containing the operation type, time, and vehicle status to the mobile phone; the mobile phone's Bluetooth communication unit synchronizes the operation result to the APP background, and the device log page is updated the next time the APP is launched.

10. The method for unlocking a multi-user lock on a mobile phone according to claim 6, characterized in that, S4 includes the following steps: S41: The on-board status detection and execution unit monitors multi-dimensional status, including: ignition switch and actuator status, vehicle motion and environmental status, and BLE connection status. S42: Based on wheel movement and vibration sensor data, determine the vehicle's stationary state; after the ignition is turned on and the stationary state has been inactive for a timeout, control the MOSFET to disconnect the ACC circuit, detect whether the ignition is closed, and if it is not closed, send an ignition closing failure alarm to the cloud, push the alarm to the administrator, and the vehicle unit records the fault details. S43: After the ignition is turned off, the vehicle control module uses the mobile phone's GPS to determine whether the vehicle is in the safe zone preset by the APP; if it is in the safe zone, the arming is delayed; if it is in the unsafe zone, the arming is not delayed; when the vehicle is armed, the Bluetooth alarm is activated and the ACC circuit is disconnected, and the arming result is synchronized to the cloud and the mobile phone.

Images