Vehicle key creation method and apparatus, storage medium, and program product

Abstract

The present disclosure relates to a vehicle key creation method, device, storage medium and program product, belonging to the technical field of vehicle keys. The method comprises: in response to a user's request to create a vehicle key, determining whether the user equipment supports the creation of the vehicle key; in response to the user equipment not supporting the creation of the vehicle key, sending first prompt information to the user, the first prompt information being configured to prompt the user equipment to need version upgrade. In this way, the user can be assisted and prompted when it is determined that the user equipment does not support the creation of the vehicle key. In this way, it helps to improve the success rate of vehicle key creation and guarantee the user's vehicle key use experience.

Description

Technical Field

[0001] This disclosure relates to the field of car key technology, and in particular to car key creation methods, devices, storage media, and program products. Background Technology

[0002] In relevant scenarios, digital car keys have been widely used in various vehicle models. Before using a digital car key, users can create one. However, sometimes users may find that they cannot create a digital car key successfully. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this disclosure provides a car key creation method, device, storage medium, and program product.

[0004] According to a first aspect of the present disclosure, a method for creating a car key is provided, comprising:

[0005] In response to a user's request to create a vehicle key, determine whether the user's device supports creating the vehicle key; In response to the user device not supporting the creation of the car key, a first prompt message is sent to the user, the first prompt message being configured to prompt the user device to perform a version upgrade.

[0006] Using the above solution, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, suggesting that the user's device needs to be upgraded. The user can then upgrade their device and try creating the car key again. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0007] In some possible implementations, including: In response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

[0008] In this way, when the user's device supports the creation of the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0009] In some possible implementations, including: In response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

[0010] In this way, once the user device version is upgraded, if the user device supports creating the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0011] In some possible implementations, including: In response to the user's choice to upgrade the car key application version, the creation of the car key is interrupted; In response to the completion of the car key application version upgrade, the car key is created.

[0012] This allows you to upgrade the car key application version first, and then create the car key. This enables car key creation based on a higher version of the application, which helps improve the success rate of key creation.

[0013] In some possible implementations, including: In response to the user's choice not to upgrade the car key application version, the car key is created.

[0014] This allows users to create car keys based on the current version of the car key application even if they choose not to upgrade. This improves the flexibility of the car key creation process.

[0015] In some possible implementations, determining whether the user equipment supports creating the car key includes: Determine the version of the car key application in the vehicle to obtain the first version; Based on the first version and the first association, determine whether the user device supports creating the car key.

[0016] In this way, by incorporating information about the car key application version, it is possible to more accurately determine whether a device supports the creation of a car key during the digital car key creation process.

[0017] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0018] In this way, by configuring the association between the car key protocol and the car key application version in the vehicle, the association can be used to help determine whether the device supports creating a car key.

[0019] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

[0020] In this way, the accuracy of the decision can be improved by combining the type of digital car key protocol supported by the user equipment.

[0021] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

[0022] This allows the system to determine whether a user's device supports creating the car key based on the vehicle model and the version of the car key application installed in the vehicle. By incorporating the car key application version information, the system can more accurately determine whether the device supports key creation during the digital car key creation process.

[0023] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0024] In this way, by configuring the association between the car key protocol, vehicle model, and the version of the car key application in the vehicle, the association can be used to help determine whether the device supports the creation of car keys.

[0025] According to a second aspect of the present disclosure, a method for creating a car key is provided, comprising: Send a request to the server for the user to create a car key for the vehicle; The server receives a first prompt message sent by the user device. The server sends the first prompt message when it determines that the user device does not support the creation of the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0026] Using the above solution, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, suggesting that the user's device needs to be upgraded. The user can then upgrade their device and try creating the car key again. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0027] In some possible implementations, including: The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0028] In this way, when the user's device supports the creation of the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0029] In some possible implementations, including: In response to the first prompt message, upgrade the user device version; The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0030] In this way, once the user device version is upgraded, if the user device supports creating the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0031] In some possible implementations, including: In response to the second prompt message, if the user selects to upgrade the car key application version, the creation of the car key is interrupted; In response to the completion of the car key application version upgrade, the car key is created.

[0032] This allows you to upgrade the car key application version first, and then create the car key. This enables car key creation based on a higher version of the application, which helps improve the success rate of key creation.

[0033] In some possible implementations, including: In response to the second prompt, the car key is created if the user chooses not to upgrade the car key application version.

[0034] This allows users to create car keys based on the current version of the car key application even if they choose not to upgrade. This improves the flexibility of the car key creation process.

[0035] In some possible implementations, the server determines whether the user equipment supports creating the car key by: determining the car key application version in the vehicle to obtain a first version; and determining whether the user equipment supports creating the car key based on the first version and a first association relationship.

[0036] In this way, by incorporating information about the car key application version, it is possible to more accurately determine whether a device supports the creation of a car key during the digital car key creation process.

[0037] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0038] In this way, by configuring the association between the car key protocol and the car key application version in the vehicle, the association can be used to help determine whether the device supports creating a car key.

[0039] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

[0040] In this way, the accuracy of the decision can be improved by combining the type of digital car key protocol supported by the user equipment.

[0041] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining the vehicle model to obtain a first model; and determining whether the user equipment supports creating the car key based on the first version, the first model, and the first association.

[0042] This allows the system to determine whether a user's device supports creating the car key based on the vehicle model and the version of the car key application installed in the vehicle. By incorporating the car key application version information, the system can more accurately determine whether the device supports creating a car key during the digital car key creation process.

[0043] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0044] In this way, by configuring the association between the car key protocol, vehicle model, and the version of the car key application in the vehicle, the association can be used to help determine whether the device supports the creation of car keys.

[0045] According to a third aspect of the present disclosure, a car key creation apparatus is provided, comprising: The determination module is configured to determine whether the user device supports creating the car key in response to a user's request to create a vehicle key; The first prompt message sending module is configured to send a first prompt message to the user in response to the user device not supporting the creation of the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0046] In some possible implementations, including: The second prompt message sending module is configured to send a second prompt message to the user in response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0047] In some possible implementations, including: The information sending module is configured to send a second prompt message to the user in response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0048] In some possible implementations, including: The interrupt module is configured to interrupt the creation of the car key in response to the user's choice to upgrade the car key application version; The first car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

[0049] In some possible implementations, including: The processing module is configured to create the car key in response to the user's choice not to upgrade the car key application version.

[0050] In some possible implementations, the determining module is configured to: Determine the version of the car key application in the vehicle to obtain the first version; Based on the first version and the first association, determine whether the user device supports creating the car key.

[0051] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0052] In some possible implementations, the determining module is configured to: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

[0053] In some possible implementations, the determining module is configured to: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

[0054] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0055] According to a fourth aspect of the present disclosure, a car key creation apparatus is provided, comprising: The request sending module is configured to send a request to the server for the user to create a car key for the vehicle. The first prompt information receiving module is configured to receive a first prompt information sent by the server. The server sends the first prompt information when it determines that the user device does not support the creation of the car key. The first prompt information is configured to prompt the user device to perform a version upgrade.

[0056] In some possible implementations, including: The second prompt information receiving module is configured to receive a second prompt information sent by the server. The server sends the second prompt information when the user device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt information is configured to prompt the user to upgrade the car key application version.

[0057] In some possible implementations, including: The user equipment version upgrade module is configured to upgrade the user equipment version in response to the first prompt information; The execution module is configured to receive a second prompt message sent by the server. The server sends the second prompt message when the user device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0058] In some possible implementations, including: The car key creation interruption module is configured to interrupt the creation of the car key in response to the second prompt message if the user selects to upgrade the car key application version; The second car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

[0059] In some possible implementations, including: The third car key creation module is configured to create the car key in response to the second prompt message if the user chooses not to upgrade the car key application version.

[0060] In some possible implementations, the server determines whether the user equipment supports creating the car key by: determining the car key application version in the vehicle to obtain a first version; and determining whether the user equipment supports creating the car key based on the first version and a first association relationship.

[0061] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0062] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

[0063] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining the vehicle model to obtain a first model; and determining whether the user equipment supports creating the car key based on the first version, the first model, and the first association.

[0064] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0065] According to a fifth aspect of the present disclosure, a car key creation apparatus is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to perform the steps of the method described in any one of the first to second aspects.

[0066] According to a sixth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first to second aspects.

[0067] According to a seventh aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first to second aspects.

[0068] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0069] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0070] Figure 1 This is a schematic diagram illustrating the distribution of a car key software module according to an exemplary embodiment.

[0071] Figure 2 This is a flowchart illustrating the creation process of a digital key according to an exemplary embodiment.

[0072] Figure 3 This is a flowchart illustrating a method for creating a car key according to an exemplary embodiment.

[0073] Figure 4 This is a flowchart illustrating an implementation of step S31 according to an exemplary embodiment.

[0074] Figure 5 This is a flowchart illustrating a vehicle update according to an exemplary embodiment.

[0075] Figure 6 This is a flowchart illustrating the creation of a car key according to an exemplary embodiment.

[0076] Figure 7 This is a flowchart illustrating a digital key protocol selection according to an exemplary embodiment.

[0077] Figure 8 This is a flowchart illustrating a method for creating a car key according to an exemplary embodiment.

[0078] Figure 9 This is a block diagram illustrating a car key creation device according to an exemplary embodiment.

[0079] Figure 10 This is a block diagram illustrating a car key creation device according to an exemplary embodiment.

[0080] Figure 11 This is a block diagram illustrating a device 1000 according to an exemplary embodiment.

[0081] Figure 12 This is a block diagram illustrating a server 1900 according to an exemplary embodiment. Detailed Implementation

[0082] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0083] Before introducing the car key creation method, apparatus, storage medium and program product of this disclosure, relevant scenarios of the embodiments of this disclosure will be described by way of example.

[0084] Digital car keys are now widely used in various models from major automakers. In this context, to ensure that digital car keys function well on more devices and that these devices can support vehicles from more automakers, different device manufacturers can negotiate relevant digital car key protocols with different automakers.

[0085] Therefore, multiple digital car key protocols currently exist. These protocols are often spearheaded by different equipment manufacturers or automakers. In some scenarios, automakers can also modify or upgrade the digital car key protocol to optimize the digital car key experience for their vehicles.

[0086] Figure 1 This is a schematic diagram illustrating the distribution of a car key software module as shown in an exemplary embodiment of this disclosure. (Refer to...) Figure 1A car manufacturer can have a model A, which uses digital key protocol X. The manufacturer can also subsequently develop a model B, using digital key protocol Y. Therefore, to enable its car manufacturer's app (i.e., application) to simultaneously support the digital key functionality of both model A and model B, software modules for both digital key protocols X and Y can be integrated within the app. Furthermore, software modules for both digital key protocols X and Y can also be integrated into the car manufacturer's cloud service.

[0087] In addition, to ensure that the car manufacturer's app can select the correct digital key protocol type during the digital car key creation process, a mapping relationship between the car model and the digital key protocol can be configured in the car manufacturer's cloud service. This mapping relationship can be shown in Table 1:

[0088] Table 1 As shown in Table 1, this includes the association between vehicle models and digital key protocols on the OEM's cloud service. For example, vehicle model A is associated with digital key protocol X, and vehicle model B is associated with digital key protocol Y. In some scenarios, Table 1 is manually maintained by R&D personnel.

[0089] also, Figure 2 This is a flowchart illustrating the creation process of a digital key according to an exemplary embodiment of this disclosure. (Refer to...) Figure 2 When a user holds a user device and creates a digital key for a vehicle based on the car manufacturer's app, the car manufacturer's app can obtain the vehicle model and send the model to the car manufacturer's cloud service.

[0090] The vehicle manufacturer's cloud service can use the vehicle model sent by the user, combined with Table 1, to confirm the types of digital key protocols supported by that model, and return the digital key protocol type information. The vehicle manufacturer's app can then create a digital key of the corresponding protocol type based on the received information. After the digital key creation process is executed normally, the corresponding vehicle's digital key will be generated within the vehicle manufacturer's app on the user's device.

[0091] It's important to note that this digital key protocol selection process defaults to vehicles of the same model supporting the same digital key protocol. However, as vehicles are upgraded and digital key protocols are updated, it's possible that a vehicle might replace its digital key protocol or upgrade its digital key protocol version during an upgrade. In such cases, different vehicles of the same model may support different digital key protocols. For example, an upgraded vehicle might have its digital key protocol updated to the first protocol, while vehicles that haven't been upgraded might still use the previous second protocol.

[0092] in this case, Figure 2The illustrated process may not be able to determine the appropriate car key protocol solely based on the vehicle model. For example, when the cloud service provides the first protocol, the vehicle may not yet be updated and therefore cannot support the first protocol. In this case, the device cannot create a car key based on the first protocol.

[0093] Therefore, this disclosure provides a method for creating car keys. Figure 3 This is a flowchart illustrating a method for creating a car key according to an exemplary embodiment of this disclosure. The method can, for example, be executed by a vehicle's cloud service. (See also...) Figure 3 The method includes: In step S31, in response to the user's request to create a vehicle key, it is determined whether the user device supports creating a vehicle key.

[0094] In step S32, in response to the user device not supporting the creation of a car key, a first prompt message is sent to the user. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0095] Using the above solution, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, suggesting that the user's device needs to be upgraded. The user can then upgrade their device and try creating the car key again. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0096] The following provides an exemplary description of the implementation of the above steps. In step S31, in response to the user's request to create a vehicle key, it can be determined whether the user device supports creating a vehicle key.

[0097] Figure 4 This is a flowchart illustrating an implementation of step S31 as shown in an exemplary embodiment of this disclosure, with reference to... Figure 4 The step of determining whether the user equipment supports creating the car key includes: In step S41, the version of the car key application in the vehicle is determined to obtain the first version.

[0098] For example, in one possible implementation, the vehicle identifier in the user's request to create a car key for the vehicle can be obtained, and the version of the car key application in the vehicle can be determined based on the vehicle identifier to obtain the first version.

[0099] For example, the first version can be obtained by querying the vehicle upgrade record in the vehicle cloud service based on the vehicle identifier.

[0100] For example, vehicle cloud services can integrate vehicle upgrade modules, such as OTA (Over-the-Air Technology) cloud service modules. (See reference...) Figure 5 The diagram illustrates a vehicle update flowchart, where the vehicle OTA cloud service module provides OTA functionality for the vehicle. After an OTA update, the vehicle OTA cloud service module can update the vehicle's body software version information, such as the car key application version information.

[0101] The vehicle OTA cloud service module can also maintain a vehicle software version data management table, as shown in Table 2:

[0102] Table 2 As shown in Table 2, in vehicle A, the current software version of the digital key module is 1.0, and the current software version of the communication module is 1.0. In vehicle B, the current software version of the digital key module is 2.0. In vehicle N, the current software version of software module N is xx.

[0103] Furthermore, the vehicle cloud service may also include other sub-services, such as a digital key cloud service module. Upon receiving the request, the digital key cloud service module can obtain the vehicle identifier from the request and, based on the vehicle identifier (e.g., ID), query the vehicle OTA cloud service module for the vehicle's body software version information. For example, the car key application version information. In this way, the first version can be obtained.

[0104] In some implementations, the vehicle OTA cloud service module and the digital key cloud service module can communicate with each other. For example, after a vehicle update, the vehicle OTA cloud service module can synchronize the latest software version information of the vehicle to the digital key cloud service module.

[0105] In one possible implementation, the server can also send a query request for software version information to the vehicle to obtain the first version.

[0106] In step S42, based on the first version and the first association, it is determined whether the user device supports creating a car key.

[0107] In one possible implementation, the first association relationship includes the association relationship between the car key protocol and the car key application version in the vehicle. Thus, by configuring the association relationship between the car key protocol and the car key application version in the vehicle, the association relationship can be used to help determine whether the device supports creating car keys.

[0108] As an example, in the first association, the first car key application version is associated with the first car key protocol, the second car key application version is associated with the second car key protocol, the third car key application version is associated with the third car key protocol, and so on... Thus, after determining the first version, the system can search the association relationships to see if a car key protocol corresponding to the first version exists. In a possible implementation, if a car key protocol corresponding to the first version exists, it can be determined that the user equipment supports creating car keys. If no car key protocol corresponding to the first version exists, it can be determined that the user equipment does not support creating car keys.

[0109] The above solution, by incorporating information about the car key application version, can more accurately determine whether a device supports car key creation during the digital car key creation process. For example, after different vehicles of the same model undergo digital car key protocol changes, the supported car key protocols may differ. Existing solutions determine support based on the car model, assuming that the same model supports the same protocol, but they cannot distinguish whether the supported protocol has changed, potentially leading to car key creation failure. The above solution, however, accurately determines support based on the digital car key application version, significantly improving the success rate of car key creation.

[0110] In one possible implementation, determining whether the user equipment supports creating the car key based on the first version and the first association (step S42) includes: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

[0111] For example, in one implementation, the user's request to create a vehicle key includes protocol parameters configured to describe the car key protocols supported by the car key application in the user's device (or simply the device). This allows the protocol parameters in the first request to be retrieved, and the car key protocols supported by the car key application in the device to be determined based on these parameters.

[0112] For example, the protocol parameters may include an "appDigitalKeyType" field. This field can represent a list of digital key protocol types supported by the car manufacturer's app on the device currently expected to create the digital key. As an example, the list may include a first protocol, a second protocol, and a third protocol. Thus, the server can determine, based on the protocol parameters, that the car key application on the user's device supports the first, second, and third protocols.

[0113] After determining the car key protocol supported by the car key application in the device, it can be determined whether the user device supports creating the car key based on the digital car key protocol type supported by the device, the first version, and the first association relationship.

[0114] For example, based on the first version, the first association relationship can be queried to determine whether a car key protocol associated with the first version exists in the first association relationship. As an example, assuming a first car key protocol associated with the first version exists in the first association relationship, it can be determined whether the car key protocols supported by the car key application in the device include the first car key protocol. If the car key protocols supported by the car key application in the device include the first car key protocol, it can be determined that the user device supports the first car key protocol.

[0115] Using the above example, it can be determined whether the first car key protocol is included in the first protocol, the second protocol, and the third protocol. If it is included, it can be determined that the device supports creating the car key; otherwise, it can be determined that the device does not support creating the car key.

[0116] Therefore, by combining the types of car key protocols supported by the device to determine whether there is a car key protocol supported by the user device, the accuracy of the decision can be improved.

[0117] Reference Figure 4 In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association (step S42) includes: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

[0118] For example, in one implementation, a user's request to create a vehicle key may include vehicle model information. For instance, when a user creates a vehicle key through a car manufacturer's app on their device, the app can obtain the vehicle model information, thus identifying the first vehicle model. In this way, a request including the first vehicle model can be sent. Upon receiving the request, the server can retrieve the first vehicle model from the request.

[0119] In one implementation, the server can also send a query request to the device that sent the request to query the car model corresponding to the car key and obtain the first car model.

[0120] In one implementation, the request may also include other information, such as the car key protocol supported by the car key application in the device, the vehicle's identifier, etc.

[0121] Thus, based on the first version, the first vehicle model, and the first association, it can be determined whether the user device supports creating the car key.

[0122] For example, in some possible implementations, the first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle. Thus, by configuring the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle, the device can be used to help determine whether it supports creating car keys.

[0123] As an example, the server can maintain a first association. This first association includes the relationship between the car key protocol, vehicle model, and the version of the car key application within the vehicle. Continuing with the above example, this first association can be presented in tabular form, and the digital key cloud service module can maintain this first association as shown in Table 3.

[0124]

[0125] Table 3 Referring to Table 3, the digital key cloud service module can maintain the association between vehicle model, version number, and digital key protocol (car key protocol). For example, the data in the table describes that on vehicle model A, when the version number (such as the version number of the car key application in the vehicle) is 1.0, digital key protocol X is supported. When the version number is 2.0, digital key protocol Y is supported. On vehicle model B, when the version number is 1.0, digital key protocol Y is supported. On vehicle model N, when the version number is xx, digital key protocol N is supported.

[0126] Therefore, when determining whether the user equipment supports creating the car key based on the first version, the first vehicle model, and the first association relationship, the association relationship can be queried based on the first version and the first vehicle model to determine whether a car key protocol associated with the first version and the first vehicle model exists. If such a protocol exists, it can be determined that the user equipment supports car key creation; otherwise, it can be determined that the user equipment does not support car key creation.

[0127] If the device supports creating car keys, relevant information can be sent to the device to facilitate the car key creation process. For example, in one embodiment, the car key protocol corresponding to the first version and the first vehicle model in the first association relationship is the target protocol. Information about the target protocol can then be sent to the device, and this information may include, for example, key parameters. This information is used by the device to create a car key corresponding to the target protocol.

[0128] The key parameters may include relevant parameters required to create a car key under the target protocol, such as a key seed. After receiving the target protocol information, the device can determine that the protocol of the car key to be created is the target protocol. Thus, the device can send a request to the server to create a car key under the target car key protocol; this request may also include the key parameters. The server can then respond to the request, thereby executing the car key creation process.

[0129] In the above solution, the system can determine whether a user device supports creating the car key based on the vehicle model and the version of the car key application in the vehicle. By incorporating the car key application version information, the system can more accurately determine whether the device supports creating a car key during the digital car key creation process, thus improving the accuracy of the decision-making.

[0130] Reference Figure 3 In step S32, in response to the user device not supporting the creation of a car key, a first prompt message is sent to the user. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0131] Following the example above of determining whether a user device supports creating a car key based on the first version, the first vehicle model, and the first association, in a possible implementation, the server may determine that no car key protocol is supported by the user device if a first car key protocol associated with the first version and the first vehicle model exists in the first association, and the car key protocol supported by the car key application in the user device does not include the first car key protocol.

[0132] In other words, even if a first car key protocol exists in the first association relationship, associated with the first version and the first vehicle model, the car key application in the user device cannot support the first car key protocol because it does not support such a protocol. Therefore, it can be determined that no car key protocol is supported by the user device.

[0133] In one implementation, the server can determine that no car key protocol is supported by the user device if no car key protocol associated with the first version and the first vehicle model exists in the first association relationship.

[0134] Therefore, by combining the types of car key protocols supported by the device to determine whether there is a car key protocol supported by the user device, the accuracy of the decision can be improved.

[0135] In addition, if the server determines that the user device does not support the creation of the car key, it can also send a first prompt message to the user device, which is configured to prompt the user device to upgrade its version.

[0136] For example, users can be prompted to update the car key app on their device, thereby helping them resolve issues where their device does not support the car key protocol, and thus assisting them in creating car keys.

[0137] In some possible implementations, the method includes: In response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

[0138] Following the example above of determining whether a user device supports creating a car key based on the first version, the first vehicle model, and the first association, in a possible implementation, it can be determined that the user device supports the first car key protocol (i.e., it can create a car key based on the first car key protocol) based on the first version, the first vehicle model, and the first association.

[0139] Thus, if it is determined that in the first association relationship, the first vehicle model has a newer (or higher) version of the car key application than the first version, a second prompt message can be sent to the user. For example, the second prompt message can be sent directly to the user or to the user's device (such as a mobile phone, wearable device, etc.). The second prompt message is configured to prompt the user to upgrade the car key application version.

[0140] Referring to Table 3, taking vehicle model A as an example, the server can determine that a newer version of the car key application exists for vehicle model A, namely version 2.0. This means that an upgradable version of the car key application exists for vehicle A. Therefore, the server can send a second notification to the device to indicate that a new version of the car key application exists for the vehicle. This second notification can be presented via app notifications, SMS messages, or other means.

[0141] In this way, users can learn from the second prompt that the car key application in their vehicle can be upgraded. In one possible implementation, the user can first upgrade the car key application and then trigger the car key creation process via the device. In another possible implementation, the user can also first trigger the car key creation process via the device and then upgrade the car key application.

[0142] In this way, when the user's device supports the creation of the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0143] It should be noted that in some possible implementations, the user may choose to upgrade the car key application version. In this case, the method may include: interrupting the creation of the car key in response to the user's choice to upgrade the car key application version; and creating the car key in response to the completion of the car key application version upgrade.

[0144] In this way, when a user chooses to upgrade the car key application version, the creation of the car key can be interrupted, and the creation process can resume after the user completes the upgrade. Specifically, depending on application requirements, the car key creation process can be paused when the user upgrades the car key application version and resumed after the upgrade is complete. Alternatively, the car key creation process can be ended when the user upgrades the car key application version and restarted after the upgrade is complete.

[0145] This allows you to upgrade the car key application version first, and then create the car key. This enables car key creation based on a higher version of the application, which helps improve the success rate of key creation.

[0146] In some possible implementations, the user may choose not to upgrade the car key application version. In this case, the car key can be created in response to the user's choice not to upgrade the car key application version. For example, the car key can be created based on the current car key application version. This improves the flexibility of the car key creation process.

[0147] In some possible implementations, the method includes: In response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

[0148] For example, after upgrading their user device, a user can re-enter the car key creation process. If a higher version of the digital car key application exists for the vehicle, a second prompt message can be sent to the user, configured to prompt them to upgrade the car key application version.

[0149] In this way, once the user device version is upgraded, if the user device supports creating the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0150] Figure 6 This is a flowchart illustrating the creation of a car key according to an exemplary embodiment of this disclosure. (Refer to...) Figure 6 The process includes: When a user wishes to use the digital key function, they send a digital key creation compatibility request to the vehicle manufacturer's cloud service via the vehicle manufacturer's app. This digital key creation compatibility request can be the union of key creation request parameters from various protocols, with the following parameters added: “vehicleId” is configured to identify the ID of the vehicle for which a digital key needs to be created; “vehicleType” is configured to characterize the vehicle model for which a digital key needs to be created; "appDigitalKeyType" is configured to represent a list of digital key protocol types that the car manufacturer's app on the device currently expected to create a digital key can support.

[0151] For example, if a key creation request for creating a digital key protocol X needs to carry parameters A, B, and C, suppose its code segment is as follows: { “A”: “xxx”; “B”: “xxx”; “C”: “xxx” } If the key creation request for creating digital key protocol Y needs to carry parameters A, D, and E, assume its code segment is as follows: { “A”: “xxx”; “D”: “xxx”; “E”: “xxx” } In this way, the digital key creation compatibility request can take the union of the two and add the parameters "vehicleId", "vehicleType", and "appDigitalKeyType". Its code snippet can be represented as: { “A”: “xxx”; “B”: “xxx”; “C”: “xxx”, “D”: “xxx”, “E”: “xxx”, “vehicleId”: “xxx”, “vehicleType”: “xxx”, “appDigitalKeyType”: [ “digitalKeyTypeX”, “digitalKeyTypeY”, … ] } The code segment indicates that the car manufacturer's APP on the device supports digital key functions of digital key protocol X and digital key protocol Y.

[0152] In addition, refer to Figure 6 The cloud service can combine information from multiple internal modules to perform a digital key protocol selection operation. Based on the execution result, it can return the digital key protocol type and the necessary parameters for subsequent key creation under that protocol type to the device. In some scenarios, it may also return creation failure information and corresponding prompts to the user.

[0153] Figure 7 This is a flowchart illustrating a digital key protocol selection process as shown in an exemplary embodiment of this disclosure. (Refer to...) Figure 7 The process includes: The vehicle manufacturer's cloud service receives a digital key creation compatibility request uploaded by the vehicle manufacturer's app. Based on the vehicleId, it queries Table 2 of the vehicle OTA cloud service module to find the corresponding vehicle software version for the digital key module. Then, based on the corresponding vehicle software version and the vehicleType parameter in the digital key creation compatibility request, it queries Table 3 of the digital key cloud service module to find the supported digital key protocol types for the vehicle.

[0154] Based on the types of digital key protocols that the vehicle supports, and combined with the appDigitalKeyType parameter in the digital key creation compatibility request, it is determined whether the vehicle manufacturer's app on the current requesting device supports the digital key protocol.

[0155] If the vehicle manufacturer's app on the requesting device does not support the digital key protocol, a key creation failure message will be returned, prompting the user that "the current vehicle's digital key function requires an upgrade to the vehicle key app on the device." If the vehicle manufacturer's app on the requesting device supports the digital key protocol, then Table 3 of the digital key cloud service module will be checked to see if a higher version of the digital key module's body software exists for the vehicle model.

[0156] If a higher version of the digital key module body software is not available, the system will return the digital key protocol type and the necessary parameters for key creation for that protocol type to proceed with the subsequent key creation process. If a higher version of the digital key module body software is available for the corresponding vehicle model, the system will return the digital key protocol type and the necessary parameters for key creation for that protocol type, and will prompt the user that "the current vehicle supports a higher version of the digital key function. You can improve your driving experience by completing the vehicle OTA and APP upgrades."

[0157] In this situation, users can either continue with the subsequent key creation process or interrupt the current process and initiate a new digital key creation process after completing the vehicle OTA and APP upgrades.

[0158] Therefore, when different vehicles of the same model switch digital key protocols or upgrade their digital key protocol versions, the above method can be used to select the correct digital key protocol. In some cases, prompts can also be provided to guide users through the digital key creation process.

[0159] In the above solution, by integrating the digital key cloud service module and the vehicle OTA cloud service module, the vehicle OTA cloud service module can provide more information for the car manufacturer's app to select the digital key protocol. Simultaneously, it designs a compatible key creation request, simplifies the protocol selection process, and provides users with a concise and comprehensive guide to digital key protocol operation. Thus, when a car manufacturer wants to replace or upgrade the digital key protocol during a specific OTA upgrade for different vehicles of the same model, this solution can provide the user with the ability to select the digital key protocol during the digital key creation process.

[0160] Based on the same inventive concept, this disclosure also provides a method for creating a car key. Figure 8 This is a flowchart illustrating a car key processing method according to an exemplary embodiment of this disclosure. The method can be executed by a device, which can be any of the devices involved in the above embodiments, including mobile phones, tablets, wearable devices, etc. (Refer to...) Figure 8 The car key processing method includes: In step S81, a request for the user to create a car key for the vehicle is sent to the server.

[0161] In step S82, a first prompt message is received from the server. The server sends the first prompt message when it determines that the user device does not support creating the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0162] Here, an exemplary embodiment of the implementation method for the server to determine whether the user device supports the creation of the car key is provided.

[0163] Reference Figure 4 The server can determine the version of the car key application in the vehicle, obtaining a first version. Based on the first version and the first association relationship, it can determine whether the user device supports creating a car key.

[0164] For example, in one possible implementation, the vehicle identifier in the user's request to create a car key for the vehicle can be obtained, and the version of the car key application in the vehicle can be determined based on the vehicle identifier to obtain the first version.

[0165] As an example, the first version can be obtained by querying the vehicle upgrade record in the vehicle cloud service based on the vehicle identifier.

[0166] For example, vehicle cloud services can integrate vehicle upgrade modules, such as OTA cloud service modules. (See reference...) Figure 5 The vehicle OTA cloud service module can provide OTA functionality for vehicles. After an OTA update, the vehicle OTA cloud service module can update the vehicle's body software version information, such as the car key application version information.

[0167] The vehicle OTA cloud service module can also maintain a vehicle software version data management table, as shown in Table 2. Referring to Table 2, in vehicle A, the current software version of the digital key module is 1.0, and the current software version of the communication module is 1.0. In vehicle B, the current software version of the digital key module is 2.0. In vehicle N, the current software version of software module N is xx.

[0168] Furthermore, the vehicle cloud service may also include other sub-services, such as a digital key cloud service module. Upon receiving the request, the digital key cloud service module can obtain the vehicle identifier from the request and, based on the vehicle identifier, query the vehicle OTA cloud service module for the vehicle's body software version information. For example, the car key application version information. In this way, the first version can be obtained.

[0169] In some implementations, the vehicle OTA cloud service module and the digital key cloud service module can communicate with each other. For example, after a vehicle update, the vehicle OTA cloud service module can synchronize the latest software version information of the vehicle to the digital key cloud service module.

[0170] In one possible implementation, the server can also send a query request for software version information to the vehicle to obtain the first version.

[0171] In this way, it can be determined whether the user device supports creating a car key based on the first version and the first association.

[0172] In one possible implementation, the first association relationship includes the association relationship between the car key protocol and the car key application version in the vehicle. Thus, by configuring the association relationship between the car key protocol and the car key application version in the vehicle, the association relationship can be used to help determine whether the device supports creating car keys.

[0173] For example, in the first association relationship, the first car key application version is associated with the first car key protocol, the second car key application version is associated with the second car key protocol, the third car key application version is associated with the third car key protocol, and so on. Thus, after determining the first version, the association can be searched to see if a car key protocol corresponding to the first version exists. In a possible implementation, if a car key protocol corresponding to the first version exists, it can be determined whether the user equipment supports creating a car key. If no car key protocol corresponding to the first version exists, it can be determined that the user equipment does not support creating a car key.

[0174] In the above solution, by introducing information about the car key application version, it is possible to more accurately determine whether the device supports the creation of car keys during the creation process of digital car keys.

[0175] In one possible implementation, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

[0176] For example, in one implementation, the user's request to create a vehicle key includes protocol parameters configured to describe the car key protocols supported by the car key application in the user's device. This allows the protocol parameters in the first request to be retrieved, and the car key protocols supported by the car key application in the device to be determined based on these parameters.

[0177] For example, the protocol parameters may include an "appDigitalKeyType" field. This field can represent a list of digital key protocol types supported by the car manufacturer's app on the device currently expected to create the digital key. As an example, the list may include a first protocol, a second protocol, and a third protocol. Thus, the server can determine, based on the protocol parameters, that the car key application on the user's device supports the first, second, and third protocols.

[0178] After determining the car key protocol supported by the car key application in the user equipment, it can be determined whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association relationship.

[0179] For example, based on the first version, the first association relationship can be queried to determine whether a car key protocol associated with the first version exists in the first association relationship. As an example, assuming a first car key protocol associated with the first version exists in the first association relationship, it can be determined whether the car key protocols supported by the car key application in the device include the first car key protocol. If the car key protocols supported by the car key application in the device include the first car key protocol, it can be determined that the user device supports the first car key protocol.

[0180] Using the above example, it can be determined whether the first car key protocol is included in the first protocol, the second protocol, and the third protocol. If it is included, it can be determined that the device supports creating the car key; otherwise, it can be determined that the device does not support creating the car key.

[0181] Therefore, by combining the types of car key protocols supported by the device to determine whether there is a car key protocol supported by the user device, the accuracy of the decision can be improved.

[0182] Reference Figure 4 In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

[0183] For example, in one implementation, a user's request to create a vehicle key may include vehicle model information. For instance, when a user creates a vehicle key through a car manufacturer's app on their device, the app can obtain the vehicle model information, thus identifying the first vehicle model. In this way, a first request including the first vehicle model can be sent. Upon receiving the first request, the server can retrieve the first vehicle model from the first request.

[0184] In one implementation, the server can also send a query request to the device that sent the first request to query the car model corresponding to the car key and obtain the first car model.

[0185] In one implementation, the first request may also include other information, such as the car key protocol supported by the car key application in the device, the vehicle's identifier, etc.

[0186] Thus, based on the first version, the first vehicle model, and the first association, it can be determined whether the user device supports creating the car key.

[0187] For example, in some possible implementations, the first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle. Thus, by configuring the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle, the device can be used to help determine whether it supports creating car keys.

[0188] As an example, the server can maintain a first association. This first association includes the relationship between the car key protocol, vehicle model, and the version of the car key application within the vehicle. Continuing with the above example, this first association can be presented in tabular form, and the digital key cloud service module can maintain this first association as shown in Table 3.

[0189] Referring to Table 3, the digital key cloud service module can maintain the association between vehicle model, version number, and digital key protocol (car key protocol). For example, the data in the table describes that on vehicle model A, when the version number (such as the version number of the car key application in the vehicle) is 1.0, digital key protocol X is supported. When the version number is 2.0, digital key protocol Y is supported. On vehicle model B, when the version number is 1.0, digital key protocol Y is supported. On vehicle model N, when the version number is xx, digital key protocol N is supported.

[0190] Therefore, when determining whether the user equipment supports creating the car key based on the first version, the first vehicle model, and the first association relationship, the association relationship can be queried based on the first version and the first vehicle model to determine whether a car key protocol associated with the first version and the first vehicle model exists. If such a protocol exists, it can be determined that the user equipment supports car key creation; otherwise, it can be determined that the user equipment does not support car key creation.

[0191] If the device supports creating car keys, relevant information can be sent to the device to facilitate the car key creation process. For example, in one embodiment, the car key protocol corresponding to the first version and the first vehicle model in the first association relationship is the target protocol. Information about the target protocol can then be sent to the device, and this information may include, for example, key parameters. This information is used by the device to create a car key corresponding to the target protocol.

[0192] The key parameters may include relevant parameters required to create a car key under the target protocol, such as a key seed. After receiving the target protocol information, the device can determine that the protocol of the car key to be created is the target protocol. Thus, the device can send a request to the server to create a car key under the target car key protocol; this request may also include the key parameters. The server can then respond to the request, thereby executing the car key creation process.

[0193] In the above solution, the system can determine whether a user device supports creating the car key based on the vehicle model and the version of the car key application in the vehicle. By incorporating the car key application version information, the system can more accurately determine whether the device supports creating a car key during the digital car key creation process, thus improving the accuracy of the decision-making.

[0194] Using the above solution, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, suggesting that the user's device needs to be upgraded. The user can then upgrade their device and try creating the car key again. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0195] In some implementations, the server may determine that the user's device does not support creating a car key and send a first prompt message to the user, which is configured to prompt the user's device to upgrade.

[0196] Following the example above of determining whether a user device supports creating a car key based on the first version, the first vehicle model, and the first association, in a possible implementation, the server may determine that no car key protocol is supported by the user device if a first car key protocol associated with the first version and the first vehicle model exists in the first association, and the car key protocol supported by the car key application in the user device does not include the first car key protocol.

[0197] In other words, even if a first car key protocol exists in the first association relationship, associated with the first version and the first vehicle model, the car key application in the user device cannot support the first car key protocol because it does not support such a protocol. Therefore, it can be determined that no car key protocol is supported by the user device.

[0198] In one implementation, the server can determine that no car key protocol is supported by the user device if no car key protocol associated with the first version and the first vehicle model exists in the first association relationship.

[0199] Therefore, by combining the types of car key protocols supported by the device to determine whether there is a car key protocol supported by the user device, the accuracy of the decision can be improved.

[0200] In addition, if the server determines that the user device does not support the creation of the car key, it can also send a first prompt message to the user device, which is configured to prompt the user device to upgrade its version.

[0201] After receiving the first prompt, the user can upgrade their device to facilitate car key creation. For example, in some implementations, the user device can provide an upgrade control for the car manufacturer's app, which the user can trigger to upgrade the app. After the upgrade is complete, the car key can be created again.

[0202] The above solution can prompt users to update their devices when their devices do not support creating car keys, thereby helping users solve the problem of their devices not supporting the car key protocol and assisting them in creating car keys.

[0203] In some possible implementations, the method is in Figure 8 In addition to: The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0204] Following the example above of determining whether a user device supports creating a car key based on the first version, the first vehicle model, and the first association, in a possible implementation, the server can determine whether the user device supports the first car key protocol (i.e., can create a car key based on the first car key protocol) based on the first version, the first vehicle model, and the first association.

[0205] Thus, if it is determined that in the first association relationship, the first vehicle model has a newer (or higher) version of the car key application than the first version, a second prompt message can be sent to the user. For example, the second prompt message can be sent directly to the user or to the user's device (such as a mobile phone, wearable device, etc.). The second prompt message is configured to prompt the user to upgrade the car key application version.

[0206] Referring to Table 3, taking vehicle model A as an example, the server can determine that a newer version of the car key application exists for vehicle model A, namely version 2.0. This means that an upgradable version of the car key application exists for vehicle A. Therefore, the server can send a second notification to the device to indicate that a new version of the car key application exists for the vehicle. This second notification can be presented via app notifications, SMS messages, or other means.

[0207] In this way, users can learn from the second prompt that the car key application in their vehicle can be upgraded. In one possible implementation, the user can first upgrade the car key application and then trigger the car key creation process via the device. In another possible implementation, the user can also first trigger the car key creation process via the device and then upgrade the car key application.

[0208] In this way, when the user's device supports the creation of the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0209] It should be noted that in some possible implementations, the user may choose to upgrade the car key application version. In this case, the method may include: interrupting the creation of the car key in response to the user's choice to upgrade the car key application version; and creating the car key in response to the completion of the car key application version upgrade.

[0210] In this way, when a user chooses to upgrade the car key application version, the creation of the car key can be interrupted, and the creation process can resume after the user completes the upgrade. Specifically, depending on application requirements, the car key creation process can be paused when the user upgrades the car key application version and resumed after the upgrade is complete. Alternatively, the car key creation process can be ended when the user upgrades the car key application version and restarted after the upgrade is complete.

[0211] This allows you to upgrade the car key application version first, and then create the car key. This enables car key creation based on a higher version of the application, which helps improve the success rate of key creation.

[0212] In some possible implementations, the user may choose not to upgrade the car key application version. In this case, the car key can be created in response to the user's choice not to upgrade the car key application version. For example, the car key can be created based on the current car key application version. This improves the flexibility of the car key creation process.

[0213] In this way, when the user's device supports the creation of the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0214] In some possible implementations, the method is in Figure 8 In addition to: In response to the first prompt message, upgrade the user device version; The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0215] For example, after upgrading their user device, a user can re-enter the car key creation process. At this point, if the server determines that a higher version of the digital car key application exists, it can send a second prompt message to the user, configured to prompt the user to upgrade the car key application version.

[0216] In this way, once the user device version is upgraded, if the user device supports creating the car key and the vehicle has a higher version of the digital car key application, the user can be prompted to upgrade the car key application version through the second prompt message, thereby improving the car key creation and usage experience.

[0217] Regarding the implementation methods of the above steps, they have already been discussed in [the document / document / etc.]. Figures 1 to 7 The embodiments described in detail are presented below. For the sake of brevity, the embodiments disclosed herein will not be repeated.

[0218] Based on the same inventive concept, this disclosure provides a car key creation device. Figure 9 This is a block diagram of a car key creation device shown in an exemplary embodiment of the present disclosure, with reference to... Figure 9 The car key creation device includes: The determination module 801 is configured to determine whether the user device supports creating the car key in response to a user's request to create a car key for the vehicle. The first prompt message sending module 802 is configured to send a first prompt message to the user in response to the user device not supporting the creation of the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

[0219] Based on the aforementioned device, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, indicating that the user's device needs to be upgraded. The user can then upgrade their device before creating the car key. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0220] In some possible implementations, including: The second prompt message sending module is configured to send a second prompt message to the user in response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0221] In some possible implementations, including: The information sending module is configured to send a second prompt message to the user in response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0222] In some possible implementations, including: The interrupt module is configured to interrupt the creation of the car key in response to the user's choice to upgrade the car key application version; The first car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

[0223] In some possible implementations, including: The processing module is configured to create the car key in response to the user's choice not to upgrade the car key application version.

[0224] In some possible implementations, the determining module is configured to: Determine the version of the car key application in the vehicle to obtain the first version; Based on the first version and the first association, determine whether the user device supports creating the car key.

[0225] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0226] In some possible implementations, the determining module is configured to: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

[0227] In some possible implementations, the determining module is configured to: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

[0228] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0229] Based on the same inventive concept, this disclosure provides a car key creation device. Figure 10 This is a block diagram of a car key creation device shown in an exemplary embodiment of the present disclosure, with reference to... Figure 10 The car key creation device includes: The request sending module 901 is configured to send a request to the server for the user to create a car key for the vehicle. The first prompt information receiving module 902 is configured to receive a first prompt information sent by the server. The server sends the first prompt information when it determines that the user device does not support the creation of the car key. The first prompt information is configured to prompt the user device to perform a version upgrade.

[0230] Using the aforementioned device, when a user creates a car key, it can be determined whether the user's device supports car key creation. If the user's device does not support car key creation, a first prompt message can be sent to the user, indicating that the user's device needs to be upgraded. The user can then upgrade their device and try creating the car key again. This method provides assistance and prompts to the user when it is determined that the user's device does not support car key creation. This helps improve the success rate of car key creation and ensures a better user experience.

[0231] In some possible implementations, including: The second prompt information receiving module is configured to receive a second prompt information sent by the server. The server sends the second prompt information when the user device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt information is configured to prompt the user to upgrade the car key application version.

[0232] In some possible implementations, including: The user equipment version upgrade module is configured to upgrade the user equipment version in response to the first prompt information; The execution module is configured to receive a second prompt message sent by the server. The server sends the second prompt message when the user device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

[0233] In some possible implementations, including: The car key creation interruption module is configured to interrupt the creation of the car key in response to the second prompt message if the user selects to upgrade the car key application version; The second car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

[0234] In some possible implementations, including: The third car key creation module is configured to create the car key in response to the second prompt message if the user chooses not to upgrade the car key application version.

[0235] In some possible implementations, the server determines whether the user equipment supports creating the car key by: determining the car key application version in the vehicle to obtain a first version; and determining whether the user equipment supports creating the car key based on the first version and a first association relationship.

[0236] In some possible implementations, the first association includes an association between the car key protocol and the version of the car key application in the vehicle.

[0237] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

[0238] In some possible implementations, determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining the vehicle model to obtain a first model; and determining whether the user equipment supports creating the car key based on the first version, the first model, and the first association.

[0239] In some possible implementations, the first association includes the association between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

[0240] This disclosure provides a car key creation device, including: processor; Memory used to store processor-executable instructions; The processor is configured to perform the steps of the car key creation method provided in at least one embodiment of this disclosure.

[0241] This disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the car key creation method provided in at least one embodiment of this disclosure.

[0242] This disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the car key creation method provided in at least one embodiment of this disclosure.

[0243] Regarding the car key creation device in the above embodiments, the specific methods by which each module performs its operations have been described in detail in the embodiments related to the car key creation method, and will not be elaborated here.

[0244] Figure 11 This is a block diagram illustrating a device 1000 according to an exemplary embodiment. For example, device 1000 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness device, personal digital assistant, etc.

[0245] Reference Figure 11 The device 1000 may include one or more of the following components: a first processing component 1002, a first memory 1004, a first power supply component 1006, a multimedia component 1008, an audio component 1010, a first input / output interface 1012, a sensor component 1014, and a communication component 1016.

[0246] The first processing component 1002 typically controls the overall operation of the device 1000, such as operations associated with display, telephone calls, data communication, camera operation, and recording. The first processing component 1002 may include one or more first processors 1020 to execute instructions to complete all or part of the steps of the aforementioned car key creation method. Furthermore, the first processing component 1002 may include one or more modules to facilitate interaction between the first processing component 1002 and other components. For example, the first processing component 1002 may include a multimedia module to facilitate interaction between the multimedia component 1008 and the first processing component 1002.

[0247] The first memory 1004 is configured to store various types of data to support the operation of the device 1000. Examples of this data include instructions for any application or method operating on the device 1000, contact data, phonebook data, messages, pictures, videos, etc. The first memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0248] The first power supply component 1006 provides power to various components of the device 1000. The first power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device 1000.

[0249] Multimedia component 1008 includes a screen that provides an output interface between the device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1008 includes a front-facing camera and / or a rear-facing camera. When the device 1000 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0250] Audio component 1010 is configured to output and / or input audio signals. For example, audio component 1010 includes a microphone (MIC) configured to receive external audio signals when device 1000 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in first memory 1004 or transmitted via communication component 1016. In some embodiments, audio component 1010 also includes a speaker for outputting audio signals.

[0251] The first input / output interface 1012 provides an interface between the first processing component 1002 and the peripheral interface module. The peripheral interface module may be a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to, a home button, volume buttons, a start button, and a lock button.

[0252] Sensor assembly 1014 includes one or more sensors for providing state assessments of various aspects of device 1000. For example, sensor assembly 1014 may detect the on / off state of device 1000, the relative positioning of components such as the display and keypad of device 1000, changes in the position of device 1000 or a component of device 1000, the presence or absence of user contact with device 1000, the orientation or acceleration / deceleration of device 1000, and temperature changes of device 1000. Sensor assembly 1014 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1014 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1014 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0253] Communication component 1016 is configured to facilitate wired or wireless communication between device 1000 and other devices. Device 1000 can access wireless networks based on communication standards, such as WiFi, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 1016 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1016 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0254] In an exemplary embodiment, the device 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described car key creation method.

[0255] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a first memory 1004 including instructions, which can be executed by a first processor 1020 of device 1000 to complete the aforementioned car key creation method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0256] Figure 12 This is a block diagram illustrating a server 1900 according to an exemplary embodiment. For example, server 1900 may be provided as a vehicle cloud server. (Refer to...) Figure 12 Server 1900 includes a second processing component 1922, which further includes one or more processors, and memory resources represented by a second memory 1932 for storing instructions, such as applications, that can be executed by the second processing component 1922. The applications stored in the second memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the second processing component 1922 is configured to execute instructions to perform the aforementioned car key creation method.

[0257] Server 1900 may also include a second power supply component 1926 configured to perform power management of server 1900, a wired or wireless network interface 1950 configured to connect server 1900 to a network, and a second input / output interface 1958. Server 1900 can operate on an operating system, such as Windows Server, stored in a second memory 1932. TM Mac OS X TM Unix TM Linux TM FreeBSD TM Or similar.

[0258] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A; X applies B; or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0259] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding this specification and the accompanying drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0260] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0261] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for creating a car key, characterized in that, include: In response to a user's request to create a vehicle key, determine whether the user's device supports creating the vehicle key; In response to the user device not supporting the creation of the car key, a first prompt message is sent to the user, the first prompt message being configured to prompt the user device to perform a version upgrade.

2. The method according to claim 1, characterized in that, include: In response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

3. The method according to claim 1, characterized in that, include: In response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle, a second prompt message is sent to the user, the second prompt message being configured to prompt the user to upgrade the car key application version.

4. The method according to claim 2 or 3, characterized in that, include: In response to the user's choice to upgrade the car key application version, the creation of the car key is interrupted; In response to the completion of the car key application version upgrade, the car key is created.

5. The method according to claim 2 or 3, characterized in that, include: In response to the user's choice not to upgrade the car key application version, the car key is created.

6. The method according to any one of claims 1 to 3, characterized in that, Determining whether the user equipment supports creating the car key includes: Determine the version of the car key application in the vehicle to obtain the first version; Based on the first version and the first association, determine whether the user device supports creating the car key.

7. The method according to claim 6, characterized in that, The first association includes the association between the car key protocol and the version of the car key application in the vehicle.

8. The method according to claim 6, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association includes: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

9. The method according to claim 6, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association includes: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

10. The method according to claim 9, characterized in that, The first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

11. A method for creating a car key, characterized in that, include: Send a request to the server for the user to create a car key for the vehicle; The server receives a first prompt message sent by the user device. The server sends the first prompt message when it determines that the user device does not support the creation of the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

12. The method according to claim 11, characterized in that, include: The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

13. The method according to claim 11, characterized in that, include: In response to the first prompt message, upgrade the user device version; The server receives a second prompt message sent by the user's device. The server sends the second prompt message when the user's device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

14. The method according to claim 12 or 13, characterized in that, include: In response to the second prompt message, if the user selects to upgrade the car key application version, the creation of the car key is interrupted; In response to the completion of the car key application version upgrade, the car key is created.

15. The method according to claim 12 or 13, characterized in that, include: In response to the second prompt, the car key is created if the user chooses not to upgrade the car key application version.

16. The method according to any one of claims 11 to 13, characterized in that, The server determines whether the user device supports creating the car key by: determining the car key application version in the vehicle to obtain a first version; and determining whether the user device supports creating the car key based on the first version and a first association relationship.

17. The method according to claim 16, characterized in that, The first association includes the association between the car key protocol and the version of the car key application in the vehicle.

18. The method according to claim 16, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

19. The method according to claim 16, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association relationship includes: determining the vehicle model to obtain a first model; and determining whether the user equipment supports creating the car key based on the first version, the first model, and the first association relationship.

20. The method according to claim 19, characterized in that, The first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

21. A car key creation device, characterized in that, include: The determination module is configured to determine whether the user device supports creating the car key in response to a user's request to create a car key for the vehicle. The first prompt message sending module is configured to send a first prompt message to the user in response to the user device not supporting the creation of the car key. The first prompt message is configured to prompt the user device to perform a version upgrade.

22. The apparatus according to claim 21, characterized in that, include: The second prompt message sending module is configured to send a second prompt message to the user in response to the user device supporting the creation of the car key and the vehicle having a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

23. The apparatus according to claim 21, characterized in that, include: The information sending module is configured to send a second prompt message to the user in response to the completion of the user device version upgrade and the existence of a higher digital car key application version in the vehicle. The second prompt message is configured to prompt the user to upgrade the car key application version.

24. The apparatus according to claim 22 or 23, characterized in that, include: The interrupt module is configured to interrupt the creation of the car key in response to the user's choice to upgrade the car key application version; The first car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

25. The apparatus according to claim 22 or 23, characterized in that, include: The processing module is configured to create the car key in response to the user's choice not to upgrade the car key application version.

26. The apparatus according to any one of claims 21 to 23, characterized in that, The determining module is configured as follows: Determine the version of the car key application in the vehicle to obtain the first version; Based on the first version and the first association, determine whether the user device supports creating the car key.

27. The apparatus according to claim 26, characterized in that, The first association includes the association between the car key protocol and the version of the car key application in the vehicle.

28. The apparatus according to claim 26, characterized in that, The determining module is configured as follows: Based on the type of digital car key protocol supported by the user equipment, the first version, and the first association, determine whether the user equipment supports creating the car key.

29. The apparatus according to claim 26, characterized in that, The determining module is configured as follows: Determine the vehicle model to obtain the first vehicle model; Based on the first version, the first vehicle model, and the first association, determine whether the user device supports creating the car key.

30. The apparatus according to claim 29, characterized in that, The first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

31. A car key creation device, characterized in that, include: The request sending module is configured to send a request to the server for the user to create a car key for the vehicle. The first prompt information receiving module is configured to receive a first prompt information sent by the server. The server sends the first prompt information when it determines that the user device does not support the creation of the car key. The first prompt information is configured to prompt the user device to perform a version upgrade.

32. The apparatus according to claim 31, characterized in that, include: The second prompt information receiving module is configured to receive a second prompt information sent by the server. The server sends the second prompt information when the user device supports creating the car key and the vehicle has a higher version of the digital car key application. The second prompt information is configured to prompt the user to upgrade the car key application version.

33. The apparatus according to claim 31, characterized in that, include: The user equipment version upgrade module is configured to upgrade the user equipment version in response to the first prompt information; The execution module is configured to receive a second prompt message sent by the server. The server sends the second prompt message when the user device version upgrade is completed and the vehicle has a higher version of the digital car key application. The second prompt message is configured to prompt the user to upgrade the car key application version.

34. The apparatus according to claim 32 or 33, characterized in that, include: The car key creation interruption module is configured to interrupt the creation of the car key in response to the second prompt message if the user selects to upgrade the car key application version; The second car key creation module is configured to create the car key in response to the completion of the car key application version upgrade.

35. The apparatus according to claim 32 or 33, characterized in that, include: The third car key creation module is configured to create the car key in response to the second prompt message if the user chooses not to upgrade the car key application version.

36. The apparatus according to any one of claims 31 to 33, characterized in that, The server determines whether the user device supports creating the car key by: determining the car key application version in the vehicle to obtain a first version; and determining whether the user device supports creating the car key based on the first version and a first association relationship.

37. The apparatus according to claim 36, characterized in that, The first association includes the association between the car key protocol and the version of the car key application in the vehicle.

38. The apparatus according to claim 36, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association includes: determining whether the user equipment supports creating the car key based on the digital car key protocol type supported by the user equipment, the first version, and the first association.

39. The apparatus according to claim 36, characterized in that, The step of determining whether the user equipment supports creating the car key based on the first version and the first association relationship includes: determining the vehicle model to obtain a first model; and determining whether the user equipment supports creating the car key based on the first version, the first model, and the first association relationship.

40. The apparatus according to claim 39, characterized in that, The first association relationship includes the association relationship between the car key protocol, the vehicle model, and the version of the car key application in the vehicle.

41. A car key creation device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to perform the steps of the method according to any one of claims 1 to 20.

42. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 20.

43. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 20.

Images