Vehicle theft prevention method, device, equipment, vehicle, storage medium and program product

Abstract

The present disclosure provides a vehicle theft prevention method, a vehicle theft prevention device, an electronic device, a vehicle, a storage medium and a computer program product, the technical field of vehicle control, especially the technical field of vehicle theft prevention, and the specific implementation scheme is: in response to detecting that the door of the vehicle is opened, and the current vehicle mode is a factory mode, feedback password input prompt information, wherein the factory mode is the initial mode of the vehicle when leaving the factory; obtain the input verification password and compare the verification password with the set password; and in response to the verification password being the same as the set password, start the vehicle.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control technology, and more particularly to the field of vehicle anti-theft technology, specifically to vehicle anti-theft methods, vehicle anti-theft devices, electronic devices, vehicles, storage media, and computer program products. Background Technology

[0002] With the maturity of mobile phone Bluetooth key technology, more and more vehicles are now equipped with it as standard. Based on Bluetooth key technology, a vehicle can be paired with a mobile phone via a car key. Once paired, the vehicle can be controlled via the phone, such as opening and closing doors, opening and closing the trunk, remotely starting or stopping the vehicle, and controlling the air conditioning. Using a Bluetooth key to turn the vehicle off or on reduces the risk of theft. Summary of the Invention

[0003] This disclosure provides a vehicle anti-theft method, a vehicle anti-theft device, an electronic device, a vehicle, a storage medium, and a computer program product that can reduce the risk of vehicle theft.

[0004] According to one aspect of this disclosure, a vehicle anti-theft method is provided, comprising: responding to detecting that a vehicle door is opened and the current vehicle mode is factory mode, providing a password input prompt, wherein the factory mode is the vehicle's factory initial mode; obtaining an input verification password and comparing the verification password with a preset password; and starting the vehicle in response to the verification password being the same as the preset password.

[0005] According to another aspect of this disclosure, a vehicle anti-theft device is provided, comprising: a feedback module, an acquisition module, and a start module. The feedback module is configured to, in response to detecting that a vehicle door is opened and the current vehicle mode is factory mode, provide a password input prompt, wherein factory mode is the vehicle's initial factory mode. The acquisition module is configured to acquire the input verification password and compare it with a preset password. The start module is configured to, in response to the verification password matching the preset password, start the vehicle.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor and a memory. The memory is communicatively connected to the at least one processor and stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods mentioned above.

[0007] According to another aspect of this disclosure, a vehicle is provided, which is equipped with the electronic devices mentioned above.

[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods mentioned above.

[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods mentioned above.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0012] Figure 1 A schematic block diagram of an exemplary system architecture for a vehicle anti-theft method that can be applied according to this disclosure is shown;

[0013] Figure 2 This is a schematic flowchart of a vehicle anti-theft method according to a first embodiment of the present disclosure;

[0014] Figure 3 This is a schematic diagram of a mechanical key engraved with a set password according to some embodiments of the present disclosure;

[0015] Figure 4 This is a schematic diagram of a key tag engraved with a set password according to some embodiments of the present disclosure;

[0016] Figure 5 This is a schematic diagram of the operation flow of various systems of a vehicle based on some embodiments of the vehicle anti-theft method 200 of this disclosure;

[0017] Figure 6 This is a schematic flowchart of a vehicle anti-theft method according to a second embodiment of the present disclosure;

[0018] Figure 7 This is a schematic flowchart of a vehicle anti-theft device according to a third embodiment of the present disclosure;

[0019] Figure 8 A schematic block diagram of an example electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0020] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0021] Figure 1 This is a schematic block diagram of an exemplary system architecture for a vehicle anti-theft method that can be applied according to this disclosure.

[0022] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0023] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as video applications, live streaming applications, instant messaging tools, email clients, social media platform software, etc.

[0024] The terminal devices 101, 102, and 103 here can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, such as in-vehicle infotainment systems. When terminal devices 101, 102, and 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are made here.

[0025] Server 105 can be a server that provides various services, such as a backend server that supports terminal devices 101, 102, and 103. The backend server can perform processing such as comparing the received verification password and setting password, and feed back the processing result (such as a command to start the vehicle or a judgment result on whether to start the vehicle) to the terminal device.

[0026] It should be noted that the data set construction method or model training method for three-dimensional models provided in this disclosure embodiment can be executed by server 105 or terminal devices 101, 102, 103. Accordingly, the data set construction device or model training device can be set in server 105 or terminal devices 101, 102, 103.

[0027] It should be understood that, Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0028] In some technologies, the use of mobile phone Bluetooth keys requires registration based on the customer's mobile phone number and identity information before activation. This causes significant inconvenience in production, debugging, and logistics, requiring developers to design solutions for such scenarios. Typically, vehicles equipped with mobile phone Bluetooth keys also come with remote keys or Near Field Communication (NFC) card keys. During vehicle production, debugging, and logistics, personnel use remote keys or NFC card keys to lock, unlock, and start the vehicle. After delivery to the customer, the customer registers and uses the mobile phone Bluetooth key to start the vehicle. However, after vehicles roll off the factory assembly line, they undergo multiple stages including quality inspection, debugging, repair, transportation, and loading / unloading, resulting in frequent vehicle handovers. Activating mobile phone Bluetooth keys for vehicles would require frequent registration and deregistration for different personnel, and would necessitate adding a key management system to the factory, significantly increasing time and management costs. Adding remote keys or NFC cards and reader systems to vehicles would incur high material costs.

[0029] Continue to refer to Figure 2 , Figure 2 This is a schematic flowchart of a vehicle anti-theft method according to a first embodiment of the present disclosure. Figure 2 As shown, vehicle anti-theft method 200 may include the following steps:

[0030] Step 201: In response to the detection that the vehicle door has been opened and the current vehicle mode is factory mode, a password input prompt is sent.

[0031] In this embodiment, the executing entity may be, for example, Figure 1The terminal device or server illustrated can be, for example, an in-vehicle host. After detecting that a door has been opened, the executing entity can put the vehicle in the ON position, powering it on and determining the current vehicle mode. If the current vehicle mode is determined to be factory mode, the executing entity can proactively provide a password input prompt, or it can provide the prompt after the user turns on the screen. The timing of the password input prompt can be configured as needed, for example, by referring to the feedback methods for password input prompts.

[0032] In this embodiment, the user can open the car door with a mechanical key. After confirming that the car door has been opened by the mechanical key, the executing entity determines the current vehicle mode.

[0033] In this embodiment, the factory mode is the vehicle's initial factory mode. In other words, in this embodiment, the executing entity presets a factory mode for the vehicle. In factory mode, the vehicle is started using a mechanical key and a set password. By adding a factory mode, personnel involved in vehicle debugging, logistics transportation, and other processes can start the vehicle using a set password, eliminating the need to add NFC devices or remote keys to the vehicle, thus reducing material and development costs. Because the vehicle needs to be started with a set password, even if other personnel illegally open the door, the vehicle cannot be started, meaning it cannot enter the "ready" state (successfully started and ready to start), preventing the vehicle from being driven away and improving its anti-theft performance, thereby achieving the purpose of theft prevention.

[0034] As an example, the executing entity can display a pop-up window on the central control display screen to provide password input prompts. It should be understood that, without departing from the teachings of this disclosure, the executing entity may also provide password input prompts in other ways, such as playing a password input reminder through the vehicle's voice control system so that the user can enter the password by voice. This disclosure does not limit the manner in which the executing entity provides password input prompts.

[0035] Step 202: Obtain the input verification password and compare it with the set password.

[0036] In this embodiment, the executing entity can detect whether any information has been input after receiving the password input prompt. If information is detected, the executing entity obtains the input information as a verification password and compares it with the set password to determine whether to start the vehicle.

[0037] In some embodiments of this disclosure, the password is set to the password used to start the vehicle in factory mode. Alternatively, the password can be set before the vehicle is delivered to the user. For example, the executing entity can write the password into the vehicle's memory and set the vehicle to factory mode after the vehicle's off-line electrical inspection process is completed. In this example, the password is entered during the off-line electrical inspection process, eliminating the need for additional procedures and reducing development costs.

[0038] For example, a vehicle may include systems such as a Vehicle Control Unit (VCU), a mechanical key, a Tester, a Body Domain Control Unit (BDCU), a Cockpit Domain Controller (CDC), and a Passive Keyless Enter Controller (PKC). The VCU is used to set the vehicle's mode. Within the factory and during vehicle logistics transportation, the VCU sets the vehicle to factory mode. Once the vehicle completes Bluetooth key registration, the VCU sets the vehicle out of factory mode. The mechanical key is used to unlock the doors. The Tester is used to write a setting password into the Body Domain Controller during vehicle electrical testing. The Body Domain Controller stores the written setting password in the vehicle's EEPROM. During the final assembly line electrical testing, electrical personnel or other personnel input the setting password into the Tester. The Tester then writes the setting password into the BDCU via diagnostic commands. For example, in the password writing process during the End of Line (EOL) process, the Tester can set the BDCU to enter extended session mode by setting the DID instruction (e.g., 0x10 03) corresponding to the Extended Session Mode service (e.g., 0x10); access the BDCU by using the DID instruction (e.g., 0x27 01 or 0x27 02) corresponding to the Secure Access service (e.g., 0x27); and write the password by using the DID instruction (0x2E F150) corresponding to the Password Information Writing service (e.g., 0x2E). For instance, during the EOL process, after detecting the corresponding instruction, the Tester can pop up a password input interface where the electrical inspector can enter the set password. After detecting that the password input is complete (e.g., the confirmation completion control in the password input interface is triggered), the Tester will pop up a confirmation box to prompt the electrical inspector to verify the password's correctness, and will display two options: "Re-enter" and "Correct". The text in the confirmation box can be set as needed; for example, the text could be "Please check if the set password XXX is correct". After confirming that the "Re-enter" option has been triggered, the Tester can bring up the password input interface again. After confirming that the "Correct" option has been triggered, the Tester can write the setting password entered by the electrical inspector into the BDCU. The BDCU then writes the setting password written by the Tester into the EEPROM for storage.

[0039] Optionally, the password can be overwritten or cleared by the Tester. For example, the Tester can configure the BDCU to enter extended session mode by using the DID instruction (e.g., 0x1003) corresponding to the Extended Session Mode service (e.g., 0x10). The Tester accesses the BDCU using the DID instruction (e.g., 0x27 01 or 0x27 02) corresponding to the Secure Access service (e.g., 0x27). The Tester reads the written password using the DID instruction (e.g., 0x22 F150) corresponding to the Read Data service (0x22). For example, if the Tester reads the password information of the BDCU using 0x22 F150, and the BDCU does not store the password, it can return 00 or other specified information; if the password is stored, it can return the actual password. If the Tester receives 00 or other specified information, it can prompt that no password has been written (e.g., display a text box "No password written to BDCU"). If other numbers are received, for example, if the password is set to 4 digits and the received information is 4 numerical values, the received information will be displayed (e.g., a text box "XXXX" will pop up). The Tester can assist in clearing the password by writing the DID instruction (0x2E F150) corresponding to the password information service (e.g., 0x2E). For example, if the password is set to be 00 when no password is set, the password can be cleared by issuing the instruction 0x2E F150 00. After clearing the password, the Tester can write the password back by writing the DID instruction (0x2E F150) corresponding to the password information service (e.g., 0x2E). The password writing process can be referred to the relevant description above, and will not be repeated here.

[0040] It should be understood that, without departing from the teachings of this publication, the implementing entity may also perform operations such as writing, clearing, and rewriting passwords through other means, and no restrictions are imposed here.

[0041] It should be understood that, without departing from the teachings of this disclosure, the implementing entity may also write the setting password in other processes. For example, after the vehicle is delivered to the user, the user may set / modify the setting password through a pre-set password setting / modification command. This disclosure does not restrict this.

[0042] In some embodiments of this disclosure, the password is determined based on at least one of the vehicle mechanical key tooth traceability information, vehicle identification code, and vehicle powertrain number.

[0043] As an example, the password setting can be determined based on the traceability information of the mechanical key's teeth; for instance, the traceability information of the key teeth can be used as the password setting. To facilitate the reconfiguration of the vehicle's mechanical key after it is lost, users are usually informed of the vehicle's mechanical key's traceability information. In this example, the key tooth traceability information can be used to trace the vehicle's mechanical key teeth for key configuration and also to start the vehicle. Since the key tooth traceability information can be obtained early in the vehicle production process, the relevant manufacturers can determine the vehicle's password in advance and engrave it on items such as the mechanical key or a key tag so that users can easily access it. This has minimal impact on the vehicle production / shipping process, requires minimal changes to existing processes, and minimal adjustments to the production line, making it more conducive to the implementation of vehicle anti-theft methods.

[0044] As another example, the password can be determined based on the vehicle identification number (VIN). For instance, the VIN can be input into a specified algorithm to obtain the password, so that the user can request the vehicle service provider to assist in determining the VIN based on the password, or request the vehicle service provider to assist in determining the password based on the VIN.

[0045] As another example, the password can be determined based on the vehicle powertrain number. For instance, the vehicle powertrain number can be input into a specified algorithm to obtain the password, so that the user can request the vehicle service provider to assist in determining the vehicle powertrain number based on the password, or request the vehicle service provider to assist in determining the password based on the vehicle powertrain number.

[0046] It should be understood that, without departing from the teachings of this disclosure, the password can also be a randomly set value, which can be randomly generated, for example, between 0000 and 9999, or determined based on other vehicle identification information. This disclosure does not restrict the setting of the password.

[0047] In some embodiments of this disclosure, Figure 3 This is a schematic diagram of a mechanical key engraved with a set password, according to some embodiments of this disclosure. Figure 3 As shown, the password can be engraved on the mechanical key 300. The mechanical key supplier can laser-engrave the password on each key when shipping it from the factory.

[0048] It should be understood that, without departing from the teachings of this disclosure, a password can also be engraved on the keyplate 400 of the mechanical key (e.g., Figure 4 (as shown) or other locations of the vehicle, without limitation here.

[0049] Step 203: In response to the verification password matching the set password, start the vehicle.

[0050] In this embodiment, authorized users can legally obtain the vehicle's default password and enter it in a pop-up window. Unauthorized users cannot obtain the default password, thus preventing them from using the vehicle. After obtaining the verification password, if the verification password matches the default password, the vehicle is started. Once started, the user is allowed to drive. If the verification password does not match the default password, the vehicle is not started, and the user cannot drive.

[0051] It should be understood that, without departing from the teachings of this disclosure, if it is determined that the verification password is different from the set password, the executing entity may perform other operations, such as performing specified alarm operations, such as issuing an alarm sound, etc. This disclosure does not restrict such operations.

[0052] In some embodiments of this disclosure, as described above, the vehicle may include systems such as VCU, mechanical key, Tester, BDCU, CDC, and PKC. The setting password is written to the BDCU by the Tester. After receiving the verification password, the BDCU compares the received verification password with the stored setting password. If the results match, the VCU is allowed to start the vehicle; if the results do not match, an error message is displayed indicating that the password was entered incorrectly, and the start-up fails.

[0053] According to some embodiments of this disclosure, the vehicle is set to factory mode after leaving the factory. In factory mode, the executing entity verifies the verification password entered by the user. If the verification password matches the set password, the vehicle can be started. In this embodiment, the user can start the vehicle by setting a password, which satisfies the convenience of key handover and also realizes anti-theft verification during the starting process, increasing security. In addition, this process does not require Bluetooth key registration or NFC device installation, solving the practical problem that users in the factory and vehicle transportation stages cannot register a mobile phone Bluetooth key but need to start the vehicle, thus reducing management costs, equipment costs, and development costs.

[0054] In some scenarios, Figure 5 This is a schematic diagram illustrating the operation flow of various systems of a vehicle based on some embodiments of the vehicle anti-theft method 200 of this disclosure.

[0055] As described above, the vehicle may include VCU, Tester, BDCU, CDC, and PKC systems. Based on the vehicle anti-theft method 200 of this disclosure, in EOL mode, i.e., during the offline electrical inspection process, the operations performed by each system may include:

[0056] Step 501: The Tester obtains the input password. The password can be, for example, a 4-digit password.

[0057] Step 502: The Tester writes the password to the BDCU. The password writing process can be found in the relevant description above, and will not be repeated here.

[0058] After completing the off-line electrical inspection process, the vehicle enters factory mode. In factory mode, the operations performed by various systems may include:

[0059] Step 503: The CDC detects that the user has opened the vehicle door, and a pop-up window appears asking for a password. Specifically, the user opens the door with the mechanical key, the vehicle is put into the "on" position, and the CDC displays a pop-up window asking for a password.

[0060] Step 504: The CDC obtains the verification password entered by the user and forwards it to the BDCU.

[0061] Step 505: The BDCU receives the verification password. The BDCU and CDC are connected.

[0062] Step 506: BDCU determines whether the verification password matches the set password. If they match, proceed to step 507; if they do not match, proceed to step 509.

[0063] Step 507: BDCU starts the vehicle.

[0064] Step 508: CDC exits the password input interface. Afterwards, the vehicle startup process ends. Steps 507 and 508 can be executed simultaneously or sequentially; there is no restriction on this.

[0065] In step 509, the CDC indicates that the password input failed and reminds the user to re-enter the password. Then, the system returns to step 504.

[0066] In addition to the operations described above, other systems in the vehicle can also simultaneously perform a smart key registration check, or perform a smart key registration check after step 508 is completed. This check may include the following steps:

[0067] Step 510: PKC checks if the smart key is registered. If yes, proceed to step 510; otherwise, continue checking if the user has used the mechanical key to open the door and started the vehicle using the set password.

[0068] Step 511: The VCU confirms that the Bluetooth key has been registered and switches the vehicle's mode to normal mode.

[0069] During the process of entering normal mode, the vehicle's system may perform the following operations:

[0070] Step 512, CDC exits the password input interface.

[0071] Step 513: The BDCU determines whether to start the vehicle based on the smart key.

[0072] As described above, in some embodiments of this disclosure, the vehicle is set to factory mode after leaving the factory. In factory mode, the executing entity verifies the verification password entered by the user. If the verification password matches the set password, the vehicle can be started. In this embodiment, the user can start the vehicle by setting a password, satisfying the convenience of key handover and also realizing anti-theft verification during the starting process, thus increasing security. Furthermore, this process eliminates the need for Bluetooth key registration or NFC device installation, solving the practical problem that users in the factory and during vehicle transportation cannot register their mobile phone Bluetooth keys but still need to start the vehicle, reducing management costs, equipment costs, and development costs.

[0073] See also Figure 6 , Figure 6 This is a flowchart illustrating a vehicle anti-theft method according to a second embodiment of this disclosure. This embodiment is largely the same as the first embodiment, with the main difference being that after successful smart key registration, the vehicle can be switched to normal mode. Figure 6 As shown, Figure 6 As shown, vehicle anti-theft method 600 may include the following steps:

[0074] Step 601: In response to detecting that a vehicle door has been opened and that the current vehicle mode is factory mode, a password input prompt is displayed. Factory mode refers to the vehicle's initial factory mode.

[0075] Step 602: Obtain the input verification password and compare it with the set password.

[0076] Step 603: In response to the verification password matching the set password, start the vehicle.

[0077] In this embodiment, steps 601 to 603 are roughly the same as steps 201 to 203, and will not be described again here.

[0078] Step 604: In response to the detection that the smart key registration was successful, switch the vehicle from factory mode to normal mode.

[0079] In this embodiment, when the vehicle is delivered to the user, the user can register a smart key (such as the aforementioned mobile phone Bluetooth key). After confirming successful smart key registration, the executing entity can switch the vehicle to normal mode. In normal mode, the vehicle can be started using the smart key. In this embodiment, after the vehicle is delivered, the user can start the vehicle using the smart key, improving the convenience of starting the vehicle and the vehicle's security, thus enhancing the user experience.

[0080] As an example, as described in the first embodiment, a vehicle may include systems such as VCU, mechanical key, Tester, BDCU, CDC, and PKC. The functions of each system are described above and will not be repeated here. The following mainly illustrates the method of switching vehicle modes under this example. For example, after recognizing that the smart key has been registered, the PKC can issue a key registration flag. Upon receiving this flag, the VCU can switch the vehicle to normal mode. Once the vehicle enters normal mode, the CDC will no longer display a password input box, and the VCU will start the vehicle based on the smart key information (e.g., real-time location information).

[0081] As an option, after vehicle delivery, the implementing entity may allow the user to switch the vehicle back to factory mode for use by other personnel.

[0082] For example, in some scenarios, the executing entity can switch the vehicle from normal mode to factory mode in response to the detection of a diagnostic signal. For instance, upon receiving a diagnostic signal from a local diagnostic tool or a remote diagnostic signal, the executing entity can control the vehicle to switch to factory mode so that when a component of the vehicle malfunctions and triggers a diagnostic signal, the vehicle mode can be automatically switched, thus facilitating the use of the vehicle by maintenance personnel or other personnel during the maintenance phase.

[0083] For example, in some scenarios, the executing entity can switch the vehicle from normal mode to factory mode in response to the detection of a third-party takeover signal. For instance, if the vehicle is a special vehicle such as a driver's license test vehicle or a shared vehicle, and there are many users, registering a smart key for each user would be inconvenient. In this example, after receiving a third-party takeover signal, the executing entity can switch back to factory mode, allowing users to start the vehicle using a pre-set password. This eliminates the need for users to register a smart key, improving convenience and user experience.

[0084] Optionally, a third-party takeover signal can be triggered based on a takeover request command. This takeover request command can be triggered by controls on the vehicle or by other electronic devices besides the vehicle. Upon receiving a takeover request command from another device, the executing entity can send a takeover permission request to the vehicle's management terminal. In response to receiving a takeover permission grant command, the third-party takeover signal is triggered. In this case, the executing entity triggers a vehicle mode switch upon receiving the takeover permission grant command from the management terminal, improving vehicle security.

[0085] It should be understood that, without departing from the teachings of this publication, a third-party takeover signal can also be triggered in other ways, such as by the management terminal directly issuing the third-party takeover signal, which is not restricted here.

[0086] It should be understood that, without departing from the teachings of this disclosure, the implementing entity may switch between factory mode and normal mode in other scenarios, and this disclosure does not impose any restrictions on this.

[0087] According to some embodiments of this disclosure, the vehicle is set to factory mode after leaving the factory. In factory mode, the executing entity verifies the verification password entered by the user. If the verification password matches the set password, the vehicle can be started. In this embodiment, the user can start the vehicle by setting a password, which satisfies the convenience of key handover and also realizes anti-theft verification during the starting process, increasing security. In addition, this process does not require Bluetooth key registration or NFC device installation, solving the practical problem that users in the factory and during vehicle transportation cannot register their mobile phone Bluetooth keys but still need to start the vehicle, reducing management costs, equipment costs, and development costs. Furthermore, after the vehicle is delivered, the user can start the vehicle with a smart key, improving the convenience of vehicle starting and vehicle security, and enhancing the user experience.

[0088] See also Figure 7 , Figure 7 This is a schematic block diagram of a vehicle anti-theft device according to a third embodiment of the present disclosure. Figure 7 As shown, the vehicle anti-theft device 700 includes a feedback module 701, an acquisition module 702, and a start module 703. The feedback module 701 is configured to provide a password input prompt in response to detecting that a vehicle door is opened and the current vehicle mode is factory mode. Factory mode refers to the vehicle's initial factory setting. The acquisition module 702 is configured to acquire the input verification password and compare it with a preset password. The start module 703 is configured to start the vehicle in response to the verification password matching the preset password.

[0089] In some embodiments of this disclosure, the password is determined based on at least one of the vehicle key tooth tracing information, vehicle identification number, and vehicle powertrain number.

[0090] In some embodiments of this disclosure, the vehicle anti-theft device 700 may further include a writing module and a first switching module. The writing module is configured to write a preset password into the vehicle's memory. The first switching module is configured to switch the vehicle's mode to factory mode in response to the completion of the vehicle's off-line electrical inspection process.

[0091] In some embodiments of this disclosure, the vehicle anti-theft device 700 may further include a second switching module. The second switching module is configured to switch the vehicle from factory mode to normal mode in response to detecting successful smart key registration, wherein the vehicle is started in normal mode using a smart key.

[0092] In some embodiments of this disclosure, the vehicle anti-theft device 700 may further include a third switching module. The third switching module is configured to switch the vehicle from normal mode to factory mode in response to the detection of a diagnostic signal.

[0093] In some embodiments of this disclosure, the vehicle anti-theft device 700 may further include a fourth switching module. The fourth switching module is configured to switch the vehicle from normal mode to factory mode in response to the detection of a third-party takeover signal.

[0094] In some embodiments of this disclosure, the vehicle anti-theft device 700 may further include a request module and a trigger module. The request module is configured to send a takeover permission request to the vehicle's management terminal in response to receiving a takeover request instruction. The trigger module is configured to trigger a third-party takeover signal in response to receiving a takeover permission grant instruction.

[0095] It is not difficult to see that this embodiment is a device embodiment corresponding to the above method embodiments, and this embodiment can be implemented in conjunction with the above method embodiments. The relevant technical details mentioned in the above method embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above method embodiments.

[0096] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by this invention; however, this does not mean that other units are absent from this embodiment.

[0097] According to a fourth embodiment of this disclosure, an electronic device is provided, including at least one processor and a memory. The memory is communicatively connected to the at least one processor and stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the methods mentioned in the above embodiments.

[0098] According to a fifth embodiment of this disclosure, a vehicle is provided, which is equipped with the electronic equipment mentioned in the fifth embodiment. The electronic equipment may be implemented as an on-board unit. The on-board unit may include systems such as VCU, BDCU, CDC, and PKC mentioned above.

[0099] In some embodiments of this disclosure, the vehicle may also include a mechanical key. As described above, a password may be engraved on the mechanical key.

[0100] According to a sixth embodiment of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform the methods mentioned in the above embodiments.

[0101] According to a seventh embodiment of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods mentioned in the above embodiments.

[0102] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0103] like Figure 8 As shown, device 800 includes a processor 801, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 802 or a computer program loaded from memory 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The processor 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0104] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; memory 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0105] Processor 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 801 performs the various methods and processes described above, such as vehicle anti-theft methods 200 / 600. For example, in some embodiments, vehicle anti-theft method 200 / 600 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as memory 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by processor 801, one or more steps of vehicle anti-theft method 200 / 600 described above may be performed. Alternatively, in other embodiments, the processor 801 may be configured to perform vehicle anti-theft method 200 / 600 by any other suitable means (e.g., by means of firmware).

[0106] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0107] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0108] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0111] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0112] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0113] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A vehicle anti-theft method, comprising: In response to the detection that a vehicle door has been opened and the current vehicle mode is factory mode, a password input prompt is provided, wherein the factory mode is the vehicle's initial factory mode. Obtain the input verification password and compare it with the set password; and The vehicle is started in response to the verification password being the same as the set password; In response to the detection of successful smart key registration, the vehicle is switched from the factory mode to the normal mode, wherein the vehicle in the normal mode is started using the smart key.

2. The method according to claim 1, further comprising: Write the set password into the vehicle's memory; In response to the completion of the vehicle's off-line electrical inspection process, the vehicle is set to the factory mode.

3. The method according to claim 1, further comprising: In response to the detection of a diagnostic signal, the vehicle is switched from the normal mode to the factory mode.

4. The method according to claim 1, further comprising: In response to the detection of a third-party takeover signal, the vehicle is switched from the normal mode to the factory mode.

5. The method according to claim 4, further comprising: In response to receiving a takeover request instruction, a takeover authorization request is sent to the vehicle's management terminal; as well as In response to receiving a takeover authorization instruction, the third-party takeover signal is triggered.

6. The method according to any one of claims 1 to 5, wherein, The password is determined based on at least one of the vehicle's mechanical key tooth traceability information, vehicle identification number, and vehicle powertrain number.

7. A vehicle anti-theft device, comprising: The feedback module is configured to respond to the detection that a vehicle door is opened and the current vehicle mode is factory mode, and to provide a password input prompt, wherein the factory mode is the vehicle's factory initial mode. The acquisition module is configured to acquire the input verification password and compare the verification password with the set password; The startup module is configured to start the vehicle in response to the verification password being the same as the set password; and The second switching module is configured to switch the vehicle from the factory mode to the normal mode in response to detecting successful smart key registration, wherein the vehicle starting method in the normal mode includes smart key starting.

8. The apparatus according to claim 7, further comprising: The writing module is configured to write the set password into the vehicle's memory; The first switching module is configured to switch the vehicle's mode to the factory mode in response to the completion of the vehicle's off-line electrical inspection process.

9. The apparatus according to claim 7, further comprising: The third switching module is configured to switch the vehicle from the normal mode to the factory mode in response to the detection of a diagnostic signal.

10. The apparatus according to claim 7, further comprising: The fourth switching module is configured to switch the vehicle from the normal mode to the factory mode in response to the detection of a third-party takeover signal.

11. The apparatus of claim 10, further comprising: The request module is configured to send a takeover permission request to the vehicle's management terminal in response to receiving a takeover request instruction. as well as The triggering module is configured to trigger the third-party takeover signal in response to receiving a takeover permission granting instruction.

12. The apparatus according to any one of claims 7 to 11, wherein, The password is determined based on at least one of the vehicle key tooth traceability information, vehicle identification number, and vehicle powertrain number.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 6.

14. A vehicle equipped with the electronic device of claim 13.

15. The vehicle according to claim 14, further comprising a mechanical key, wherein the setting password is engraved on the mechanical key.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 6.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images