State synchronization method, apparatus, system, communication device, and storage medium

Abstract

The present disclosure relates to a state synchronization method, device, system, communication device and storage medium. The state synchronization method executed by a terminal comprises: receiving a first version number and a first instruction sent by a server, the first instruction being used to indicate adjusting a state of a digital car key in the terminal, and the first version number being used to identify a state version of the digital car key after adjustment; and determining whether to execute the first instruction according to the first version number and a second version number of the terminal, the second version number being used to identify a current state version of the digital car key in the terminal. In this way, the terminal can determine whether to execute the first instruction according to the second version number of the terminal and the received first version number. This approach helps to identify abnormal instructions, reduces the number of times of executing abnormal instructions, and also helps to ensure consistency of the state of the digital car key among multiple terminals.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and more specifically, to state synchronization methods, apparatus, systems, communication devices, and storage media. Background Technology

[0002] Unlike traditional car keys, digital car keys can be stored in a terminal and can enable functions such as vehicle entry, start, parking, and air conditioning control. For digital car keys to function properly, the status of the digital car key in the vehicle, cloud service, and user's mobile phone must be consistent. Summary of the Invention

[0003] This disclosure provides a state synchronization method, apparatus, system, communication device, and storage medium.

[0004] According to a first aspect of the embodiments of this disclosure, a state synchronization method is proposed, executed by a terminal, the method comprising:

[0005] Receive a first version number and a first instruction sent by the server. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number is used to identify the state version of the digital car key after the adjustment.

[0006] Whether to execute the first instruction is determined based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0007] According to a second aspect of the embodiments of this disclosure, a state synchronization method is proposed, executed by a server, the method comprising:

[0008] Receive a second instruction from the requesting end to indicate the adjustment of the digital car key's status;

[0009] Determine the identifier of the adjusted digital car key's status version to obtain the first version number;

[0010] A first version number and a first instruction are sent to the terminal. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current state version of the digital car key of the terminal.

[0011] According to a third aspect of the present disclosure, a first state synchronization device is provided, applied to a terminal, the device comprising:

[0012] The first receiving module is configured to receive a first version number and a first instruction sent by the server. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal, and the first version number is used to identify the state version of the digital car key after adjustment.

[0013] The first execution module is configured to determine whether to execute the first instruction based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0014] According to a fourth aspect of the embodiments of this disclosure, a second state synchronization device is provided, applied to a server, the device comprising:

[0015] The second receiving module is configured to receive a second instruction from the requesting end to indicate the adjustment of the state of the digital car key;

[0016] The first determining module is configured to determine the identifier of the adjusted state version of the digital car key, and obtain the first version number;

[0017] The first sending module is configured to send a first version number and a first instruction to the terminal. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current state version of the digital car key of the terminal.

[0018] According to a fifth aspect of the embodiments of this disclosure, a state synchronization method is proposed, comprising:

[0019] The server receives a second instruction from the requesting client to adjust the status of the digital car key;

[0020] The server determines the identifier of the adjusted digital car key's status version and obtains the first version number;

[0021] The server sends a first version number and a first instruction to the terminal, the first instruction being used to instruct the adjustment of the status of the digital car key in the terminal.

[0022] The terminal receives the first version number and the first instruction sent by the server.

[0023] The terminal determines whether to execute the first instruction based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0024] According to a sixth aspect of the present disclosure, a communication device is provided, comprising:

[0025] One or more processors;

[0026] The processor is configured to invoke computer instructions to cause the communication device to execute the state synchronization method as described in any one of the first and second aspects above.

[0027] According to a seventh aspect of the present disclosure, a state synchronization system is proposed, comprising a terminal and a server, wherein the terminal is configured to implement the state synchronization method as described in any one of the first aspects above, and the server is configured to implement the state synchronization method as described in any one of the second aspects above.

[0028] According to an eighth aspect of the present disclosure, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions that, when executed on a communication device, cause the communication device to perform a state synchronization method as described in any one of the first and second aspects above. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings required for the description of the embodiments are introduced below. The following drawings are only some embodiments of this disclosure and do not impose specific limitations on the protection scope of this disclosure.

[0030] Figure 1 This is a flowchart illustrating the state synchronization of a digital car key according to an embodiment of the present disclosure.

[0031] Figure 2 This is a flowchart illustrating the state synchronization of a digital car key according to an embodiment of the present disclosure.

[0032] Figure 3 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0033] Figure 4 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0034] Figure 5 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0035] Figure 6 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0036] Figure 7 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0037] Figure 8 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0038] Figure 9This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0039] Figure 10 This is an interactive flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0040] Figure 11 This is an interactive flowchart illustrating a state synchronization method according to an embodiment of the present disclosure.

[0041] Figure 12 This is a schematic diagram of a first-state synchronization device according to an embodiment of the present disclosure.

[0042] Figure 13 This is a schematic diagram of a second-state synchronization device according to an embodiment of the present disclosure.

[0043] Figure 14 This is a schematic diagram of the structure of a communication device 8100 according to an embodiment of the present disclosure. Detailed Implementation

[0044] To ensure that the digital car keys in various devices are in the same state, embodiments of this disclosure propose a state synchronization method, apparatus, system, communication device, and storage medium.

[0045] Firstly, a state synchronization method is proposed, executed by a terminal, the method comprising:

[0046] Receive a first version number and a first instruction sent by the server. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number is used to identify the state version of the digital car key after the adjustment.

[0047] Whether to execute the first instruction is determined based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0048] In the above embodiments, the terminal can determine whether to execute the first instruction based on the terminal's second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0049] In conjunction with some embodiments of the first aspect, in some embodiments, determining whether to execute the first instruction based on the first version number and the second version number of the terminal includes:

[0050] The decision on whether to execute the first instruction is based on the order of the first version number and the second version number.

[0051] In the above embodiments, before executing a server-side instruction, the terminal can determine whether to execute the instruction based on the descending order of its version number. Compared to directly executing server-side instructions, the method in the above embodiments helps to identify abnormal instructions and reduces the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0052] In conjunction with some embodiments of the first aspect, in some embodiments, determining whether to execute the first instruction based on the high-low order between the first version number and the second version number includes:

[0053] If the first version number is higher than the second version number, then the first instruction will be executed; or...

[0054] If the first version number is equal to the second version number, then the execution of the first instruction is refused; or...

[0055] If the second version number is higher than the first version number, it is determined that the first instruction will not be executed.

[0056] In the above embodiments, when the first version number is equal to or lower than the second version number, it can be determined that the first instruction is an abnormal instruction. Therefore, it can be determined that the execution of the first instruction will be refused; when the first version number is higher than the second version number, it is determined that the first instruction will be executed. Compared with the method of directly executing the server-side instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0057] In conjunction with some embodiments of the first aspect, some embodiments include:

[0058] Confirm that the first instruction was executed successfully;

[0059] The first version number is used as the identifier of the current digital car key status version of the terminal.

[0060] Send a message to the server indicating that the first instruction has been successfully executed.

[0061] In the above embodiments, by determining that the first instruction was successfully executed and using the first version number as an identifier of the current digital car key status version of the terminal, the identifier of the current digital car key status version of the terminal can be updated. This achieves synchronization of the digital car key status version numbers between the terminal and the server. Furthermore, the terminal can also send a message to the server indicating successful execution of the first instruction, facilitating subsequent processing by the server.

[0062] In conjunction with some embodiments of the first aspect, some embodiments include:

[0063] It is confirmed that the terminal has restored its network connection;

[0064] The second version number is sent to the server. The second version number is used by the server to determine whether the current digital car key status version of the terminal is consistent with the digital car key status version of the server.

[0065] In the above embodiments, after the terminal restores the network connection, it can actively send a second version number to the server so that the server can determine whether the digital car key status version number of the terminal and the server are consistent and determine whether the status of the digital car key needs to be synchronized.

[0066] Secondly, a state synchronization method is proposed, executed by the server, the method comprising:

[0067] Receive a second instruction from the requesting end to indicate the adjustment of the digital car key's status;

[0068] Determine the identifier of the adjusted digital car key's status version to obtain the first version number;

[0069] A first version number and a first instruction are sent to the terminal. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current state version of the digital car key of the terminal.

[0070] In the above embodiments, the server can receive a second instruction from the requesting terminal indicating an adjustment to the state of the digital car key, and determine the identifier of the adjusted digital car key state version to obtain a first version number. By setting the first version number, the terminal can determine whether to execute the first instruction based on its own second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key state across multiple terminals.

[0071] In conjunction with some embodiments of the second aspect, some embodiments include:

[0072] Receive a second version number sent by the terminal, the second version number being sent by the terminal after the network connection is restored;

[0073] Based on the second version number and the server's third version number, it is determined whether to send a third instruction to the terminal. The third instruction is used to instruct the adjustment of the state of the digital car key in the terminal, and the third version number is used to identify the current state version of the digital car key on the server.

[0074] In the above embodiments, after the terminal restores its network connection, it can proactively send a second version number to the server. The server can determine whether it needs to instruct the adjustment of the digital car key's state in the terminal based on the second and third version numbers. Through the methods described in the above embodiments, even if the server experiences a fault, the version number can be used to identify inconsistencies in the digital car key's state version between the server and the terminal, and then a third instruction can be sent to adjust the state of the terminal's digital car key. In this way, the state of the digital car key across multiple terminals can be automatically synchronized.

[0075] In conjunction with some embodiments of the second aspect, in some embodiments, determining whether to send a third instruction to the terminal based on the second version number and the server's third version number includes:

[0076] Based on the order of the second version number and the third version number, determine whether to send the third instruction to the terminal.

[0077] In the above embodiment, the server can determine whether to send a third instruction based on the version number. This allows the server to identify inconsistencies in the digital car key status versions between the server and the terminal, and then adjust the digital car key status of the terminal by sending a third instruction. This enables automatic synchronization of the digital car key status across multiple devices.

[0078] In conjunction with some embodiments of the second aspect, in some embodiments, determining whether to send the third instruction to the terminal based on the high-low order between the second version number and the third version number includes:

[0079] If the second version number is lower than the third version number, it is determined that the third instruction will be sent to the terminal.

[0080] In the above embodiments, when the second version number is lower than the third version number, it can be determined that the digital car key status versions between the server and the terminal are inconsistent. Therefore, the third instruction can be sent to the terminal to adjust the status of the terminal's digital car key.

[0081] In conjunction with some embodiments of the second aspect, some embodiments include:

[0082] Determine to send the third instruction to the terminal;

[0083] Determine the current state of the digital car key on the server to obtain the first state;

[0084] The third instruction and the third version number are sent to the terminal. The third instruction is used to instruct the state of the digital car key in the terminal to be adjusted to the first state. The third version number is used to identify the state version of the digital car key in the terminal after the state is adjusted to the first state.

[0085] In the above embodiments, by sending a third instruction and a third version number, the status and status version of the digital car key on the terminal and the server can be synchronized.

[0086] In conjunction with some embodiments of the second aspect, some embodiments include:

[0087] Receive a message sent by the terminal indicating successful execution of the first instruction;

[0088] Send a message to the requesting end indicating that the digital car key status adjustment was successful.

[0089] In the above embodiment, the server can receive a message from the terminal indicating successful execution of the first instruction, and send a message to the requesting terminal indicating successful adjustment of the digital car key status, thereby completing the synchronization of the digital car key.

[0090] Thirdly, a first-state synchronization device is proposed for use in a terminal, the device comprising:

[0091] The first receiving module is configured to receive a first version number and a first instruction sent by the server. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal, and the first version number is used to identify the state version of the digital car key after adjustment.

[0092] The first execution module is configured to determine whether to execute the first instruction based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0093] In the above embodiments, the decision to execute the first instruction can be determined based on the terminal's second version number and the received first version number. Compared to directly executing server-side instructions, the method described in the above embodiments helps to identify abnormal instructions and reduces the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0094] Fourthly, a second-state synchronization device is proposed for use on a server side, the device comprising:

[0095] The second receiving module is configured to receive a second instruction from the requesting end to indicate the adjustment of the state of the digital car key;

[0096] The first determining module is configured to determine the identifier of the adjusted state version of the digital car key, and obtain the first version number;

[0097] The first sending module is configured to send a first version number and a first instruction to the terminal. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current state version of the digital car key of the terminal.

[0098] In the above embodiments, the server can receive a second instruction from the requesting terminal indicating an adjustment to the state of the digital car key, and determine the identifier of the adjusted digital car key state version to obtain a first version number. By setting the first version number, the terminal can determine whether to execute the first instruction based on its own second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key state across multiple terminals.

[0099] Fifthly, a state synchronization method is proposed, including:

[0100] The server receives a second instruction from the requesting client to adjust the status of the digital car key;

[0101] The server determines the identifier of the adjusted digital car key's status version and obtains the first version number;

[0102] The server sends a first version number and a first instruction to the terminal, the first instruction being used to instruct the adjustment of the status of the digital car key in the terminal.

[0103] The terminal receives the first version number and the first instruction sent by the server.

[0104] The terminal determines whether to execute the first instruction based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0105] Sixthly, a communication device is proposed, comprising:

[0106] One or more processors;

[0107] The processor is configured to invoke computer instructions to cause the communication device to execute the state synchronization method as described in either the first or second aspect.

[0108] In a seventh aspect, a state synchronization system is proposed, comprising a terminal and a server, wherein the terminal is configured to implement the state synchronization method as described in any one of the first aspects above, and the server is configured to implement the state synchronization method as described in any one of the second aspects above.

[0109] Eighthly, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions that, when executed on a communication device, cause the communication device to perform a state synchronization method as described in any one of the first and second aspects.

[0110] Ninthly, embodiments of this disclosure provide a computer program product that, when executed by a communication device, causes the communication device to perform a state synchronization method as described in any one of the first and second aspects.

[0111] Understandably, the aforementioned first state synchronization device, second state synchronization device, communication equipment, state synchronization system, computer-readable storage medium, and computer program product are all used to execute the state synchronization method provided in the embodiments of this disclosure. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding state synchronization method, and will not be repeated here.

[0112] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0113] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The singular expressions "a," "an," "the," "the," "the," "the," "the foregoing," "this," etc., in the embodiments of this disclosure also include the plural expressions, unless the context clearly indicates otherwise. The predefined in the embodiments of this disclosure can be understood as defined, pre-defined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned, etc.

[0114] Prefixes such as "first" and "second" in this disclosure are merely for distinguishing different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal numbers before "field" in "first field" and "second field" do not restrict the position or order of the "fields," nor do "first" and "second" restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the described object is a "level," the ordinal numbers before "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the quantity of described objects is not limited by ordinal numbers and can be one or more; for example, in "first device," the quantity of "device" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device," then "first device" and "second device" can be devices of the same type or different types. Similarly, if the object being described is "information," then "first information" and "second information" can be information with the same content or information with different content. In summary, the use of ordinal numbers and other prefixes used to distinguish the objects described in this disclosure does not constitute a limitation on the objects being described. The description of the objects being described is based on the claims or the context of the embodiments, and should not constitute an unnecessary limitation due to the use of such prefixes.

[0115] In this embodiment of the disclosure, "multiple" refers to two or more. In this embodiment of the disclosure, "and / or" is used to describe the relationship between related objects, representing three relationships that can exist independently. For example, A and / or B can represent: A existing alone, B existing alone, or A and B existing simultaneously. Descriptions such as "at least one of A1, A2, ..., An (or at least one of them)" in this embodiment of the disclosure include the case where any one of A1, A2, ..., An exists alone, as well as the case where any combination of any multiple of A1, A2, ..., An exists, and each case can exist independently; for example, the description "at least one of A, B, C" includes the cases of A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, and a combination of A, B, and C.

[0116] In some embodiments, the notation "in one case A, in another case B" or "in response to one case A, in response to another case B" may include the following technical solutions depending on the situation: A is executed regardless of B, i.e., A is executed in some embodiments; B is executed regardless of A, i.e., B is executed in some embodiments; A and B are selectively executed, i.e., A and B are selected for execution in some embodiments; A and B are both executed, i.e., A and B are executed in some embodiments. The same applies when there are more branches such as A, B, C, etc.

[0117] In some embodiments, the terms “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “if…”, “if…”, etc., can be used interchangeably.

[0118] In some embodiments, “including A,” “containing A,” “for indicating A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0119] In some embodiments, terms such as “greater than,” “greater than or equal to,” “above,” “higher than,” and “not less than” can be used interchangeably, as can terms such as “less than,” “less than or equal to,” “below,” “lower than,” and “not greater than”.

[0120] In some embodiments, the terms “function”, “device”, “equipment”, “system”, “chip”, “chip system”, etc., may be used interchangeably.

[0121] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile terminal (MT)", "mobile unit", "wireless unit", "remote unit", "mobile device", "wireless device", "wireless communication device", "remote device", "mobile subscriberstation", "access terminal", "mobile terminal", "wireless terminal", "remote terminal", "handset", "mobile client", and "client" can be used interchangeably.

[0122] In some embodiments, the names of information, etc., are not limited to the names described in the embodiments. Terms such as "information", "message", "signal", "signaling", "report", "configuration", "indication", "instruction", "command", "channel", "parameter", "domain", "field", "symbol", "symbol", "codebook", "codeword", "codepoint", "bit", "data", "program", and "chip" can be used interchangeably.

[0123] In some embodiments, “get,” “obtain,” “get,” “receive,” “transmit,” “bidirectional transmission,” and “send and / or receive” can be used interchangeably and can be interpreted as receiving from other entities, obtaining from protocols, processing and obtaining on their own, or autonomously implementing, among other meanings.

[0124] In some embodiments, terms such as “send,” “transmit,” “report,” “distribute,” “transfer,” “bidirectional transmission,” “send and / or receive” can be used interchangeably.

[0125] In some embodiments, "predetermined" or "preset" can be interpreted as pre-defined in a protocol or the like, or as a device or the like performing a pre-set action. In some embodiments, "determining" can be interpreted as judging, deciding, judging, calculating, computing, processing, deriving, investigating, searching, looking up, searching, querying, ascertaining, receiving, transmitting, input, output, accessing, resolving, selecting, choosing, establishing, comparing, assuming, expecting, considering, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, assigning, etc., but is not limited to these.

[0126] Unlike traditional car keys, digital car keys can be stored in a terminal and can enable functions such as vehicle entry, start, parking, and air conditioning control. For digital car keys to function properly, the status of the digital car key in the vehicle, cloud service, and user's mobile phone must be consistent.

[0127] Figure 1 This is a flowchart illustrating the state synchronization of a digital car key according to an embodiment of this disclosure, referred to... Figure 1 The status of a digital car key can be synchronized in the following ways:

[0128] In step 1, the requesting end sends a digital car key status change command to the server. The requesting end can be an external trigger source, such as a vehicle manufacturer's application, a web (World Wide Web) terminal, the vehicle's central control system, customer service telephone, or offline store equipment. The server can be the vehicle manufacturer's cloud service or the terminal device's cloud service; these terminal device cloud services can establish mutual trust and connection with the vehicle manufacturer's cloud service.

[0129] In step 2, the server sends a status change command to the terminal via the network link. The terminal can be a user's mobile phone, wearable device, or even a user's vehicle.

[0130] In step 3, the terminal executes the state change instruction. If the execution is successful, the terminal completes the state change of the local digital car key.

[0131] In step 4, the terminal returns a notification to the server that the status change was successful.

[0132] In step 5, after receiving the notification that the terminal's state change was successful, the server records the execution result of the state change instruction.

[0133] In step 6, the server sends the status change result back to the requesting client.

[0134] In step 7, in some cases (e.g., the terminal is located in the basement), the terminal connection fails or there is no response. After the waiting time expires, the server determines that the execution of this instruction has no result.

[0135] When the command execution has no result, it may cause inconsistencies in the status of the digital car key between the server, the user's mobile phone, and the vehicle. Figure 2 This is a flowchart illustrating the state synchronization of a digital car key according to an embodiment of this disclosure, referred to... Figure 2 When the command execution yields no result, the digital car key status can be synchronized in the following way:

[0136] After the terminal connects to the network, it reports the network status to the server.

[0137] Based on the reported network status, the server checks whether there is a non-response command in the cloud that was not successfully executed and corresponds to the terminal;

[0138] If there is a non-response command that was not executed successfully, the server will send the incomplete status change command to the terminal again.

[0139] This method can compensate for unsuccessfully executed commands by the terminal at the next network connection time, thereby achieving synchronization of the digital car key status among multiple terminals after the terminal regains network connection.

[0140] exist Figure 2In the synchronization scheme, the server records unresponsive "state change commands." Therefore, when an anomaly occurs in the recording, it can lead to a desynchronization of the digital car key states across multiple devices, which cannot be automatically corrected. For example, the server sends a key deletion command to a mobile device, which executes it successfully. The server then sends a key deletion command to the vehicle, but the vehicle is offline. If the server experiences an anomaly (such as a power outage), causing the execution status data of the vehicle's key deletion command stored in the cache to be lost, the server may lose information about unexecuted commands on the vehicle. Therefore, even if the vehicle reconnects to the network and reports its network status, the server will not send a replacement key deletion command, resulting in inconsistencies in the digital car key states of the mobile device, server, and vehicle, which cannot be automatically corrected.

[0141] Furthermore, in the above embodiments, the terminal unconditionally executes the received instructions. However, in some scenarios, an incorrect buffering or retrying transmission by a relay node (e.g., a gateway, a middleware forwarding service) in the network link may cause the terminal to receive some duplicate instructions. As an example, if the terminal first receives and processes instruction A; then receives and processes instruction B; and then, due to an error, repeatedly receives and processes instruction A, the state of the digital car key between the terminal and the server will be inconsistent, and the server will not be able to recognize this inconsistency.

[0142] Figure 3 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a terminal and includes:

[0143] In step S31, a first version number and a first instruction sent by the server are received. The first instruction is used to indicate the adjustment of the status of the digital car key in the terminal, and the first version number is used to identify the status version of the digital car key after adjustment.

[0144] In some implementations, the first instruction can be used to report a lost key, restore a key, or delete a key; that is, it can instruct the digital car key in the terminal to be in a lost, restored, or deleted state. Depending on application requirements, the first instruction can also be used to instruct the digital car key in the terminal to be in a state defined in the requirements.

[0145] The first version number can be presented as various characters or combinations of characters. In some implementations, the first version number can be presented as a number. When presented as a number, the order of version numbers can be determined based on the magnitude of the number and a rule for accumulating the numbers. For example, version numbers can be accumulated by adding 1, such that the next version after 000001 is 000002. In this way, the size relationship of the version numbers corresponds to the hierarchical relationship of the versions.

[0146] In step S32, it is determined whether to execute the first instruction based on the first version number and the second version number of the terminal. The second version number is used to identify the current state version of the digital car key of the terminal.

[0147] For example, in one possible implementation, step S32 may refer to: determining that the first version number and the second version number are different, and executing the first instruction.

[0148] When the first version number and the second version number are the same, it indicates that the digital car key status versions between the server and the terminal are consistent. Therefore, the first instruction may be an abnormal instruction, and it is unnecessary to execute the first instruction in this case.

[0149] In one possible implementation, step S32 may refer to:

[0150] The decision on whether to execute the first instruction is based on the order of the first version number and the second version number.

[0151] In some implementations, if the first version number is equal to the second version number, the execution of the first instruction is rejected. The fact that the first and second version numbers are the same indicates that the digital car key status versions between the server and the terminal are consistent. Therefore, the first instruction may be an abnormal instruction, and in this case, it is unnecessary to execute the first instruction.

[0152] In some implementations, if the second version number is higher than the first version number, it is determined that the first instruction will not be executed. A second version number higher than the first version number indicates that the digital car key of the terminal has a higher state version. Therefore, the first instruction may be an abnormal instruction, such as a repeatedly sent instruction, and thus does not need to be executed.

[0153] In some implementations, if the first version number is higher than the second version number, the execution of the first instruction is determined. A higher first version number indicates that the state version of the terminal's digital car key is lower than the state version of the server's digital car key. Therefore, the first instruction can be executed.

[0154] In the above embodiments, the terminal can determine whether to execute the first instruction based on the terminal's second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0155] Figure 4 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a terminal and includes:

[0156] In step S41, a first version number and a first instruction sent by the server are received. The first instruction is used to indicate the adjustment of the status of the digital car key in the terminal, and the first version number is used to identify the status version of the adjusted digital car key.

[0157] In step S42, it is determined whether to execute the first instruction based on the first version number and the second version number of the terminal. The second version number is used to identify the current state version of the digital car key of the terminal.

[0158] Optional implementations of steps S41 and S42 can be found in [reference]. Figure 3 The optional implementation methods of steps S31 and S32 will not be elaborated here.

[0159] In step S43, it is determined that the first instruction was successfully executed.

[0160] In step S44, the first version number is used as the identifier of the current digital car key status version of the terminal.

[0161] For example, in some implementations, the second version number can be a parameter field that identifies the current state version of the digital car key on the terminal. Therefore, the second version number can be updated by assigning a value to the first version number.

[0162] In some scenarios, the terminal can also accumulate and record version numbers on its own. For example, a rule for recording version numbers can be agreed upon, and after successfully adjusting the state of the digital car key, the current second version number can be updated according to the recording rule. As an example, the recording rule could be to increment the version number by one after successfully adjusting the state of the digital car key. In this way, after confirming that the first instruction has been successfully executed, the terminal can increment the current second version number by one to obtain a new second version number.

[0163] In step S45, a message indicating successful execution of the first instruction is sent to the server.

[0164] In the above embodiments, by determining that the first instruction was successfully executed and using the first version number as an identifier of the current digital car key status version of the terminal, the identifier of the current digital car key status version of the terminal can be updated. This achieves synchronization of the digital car key status version numbers between the terminal and the server. Furthermore, the terminal can also send a message to the server indicating successful execution of the first instruction, facilitating subsequent processing by the server.

[0165] In some embodiments, the first instruction may also fail to execute. In this case, the terminal may send a message to the server indicating that the first instruction has failed to execute.

[0166] Figure 5This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a terminal and includes:

[0167] In step S51, a first version number and a first instruction sent by the server are received. The first instruction is used to indicate the adjustment of the status of the digital car key in the terminal, and the first version number is used to identify the status version of the adjusted digital car key.

[0168] In step S52, it is determined whether to execute the first instruction based on the first version number and the second version number of the terminal. The second version number is used to identify the current digital car key status version of the terminal.

[0169] Optional implementations of steps S51 and S52 can be found in [reference]. Figure 3 The optional implementation methods of steps S31 and S32 will not be elaborated here.

[0170] In step S53, it is determined that the terminal has restored its network connection.

[0171] In step S54, a second version number is sent to the server. The second version number is used by the server to determine whether the current digital car key status version of the terminal is consistent with the digital car key status version of the server.

[0172] For example, after a terminal changes from a network-free environment to a network-enabled environment, it can restore its network connection. In this way, the terminal can send a second version number to the server, allowing the server to determine whether the terminal's current digital car key status version matches the server's digital car key status version, and whether the terminal's digital car key status needs adjustment.

[0173] In the above embodiments, after the terminal restores the network connection, it can actively send a second version number to the server so that the server can determine whether the digital car key status version number of the terminal and the server are consistent and determine whether the status of the digital car key needs to be synchronized.

[0174] Figure 6 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a server and includes:

[0175] In step S61, a second instruction from the requesting end is received, indicating that the state of the digital car key should be adjusted.

[0176] In some implementations, a second instruction can be received from devices such as vehicle manufacturer applications, web terminals, vehicle central control systems, customer service telephones, and offline store equipment to instruct the adjustment of the digital car key's status. This second instruction can be used to report a lost key, restore a key, or delete a key; that is, it can instruct the digital car key to be adjusted to a lost, restored, or deleted state.

[0177] In step S62, the identifier of the adjusted digital car key's status version is determined to obtain the first version number.

[0178] Version numbers can be presented as various characters or combinations of characters. In some implementations, version numbers can be presented as numbers. When presented as numbers, the order of version numbers can be determined based on the magnitude of the numbers and a rule for accumulating them. As an example, the rule for recording version numbers can be: after the state of the digital car key is adjusted, the version number is incremented by 1 (in other implementations, this can be any value). In this example, step S62 can refer to the server determining the current version number of the digital car key and incrementing it by 1 to obtain the first version number.

[0179] In some implementations, the rules for accumulating version numbers can be set based on application requirements.

[0180] In some implementations, the first version number may also be obtained by the server from the requesting client.

[0181] In some implementations, the first version number can also be obtained by the server from the requesting server. The requesting server can determine the first version number based on the version number accumulation rules and the current version number.

[0182] In step S63, the first version number and the first instruction are sent to the terminal.

[0183] The first instruction is used to instruct the adjustment of the status of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current status version of the digital car key in the terminal.

[0184] In some implementations, the first instruction and the second instruction can be the same, that is, in step S63, the server forwards the second instruction to the terminal, along with the first version number.

[0185] In the above embodiments, the server can receive a second instruction from the requesting terminal indicating an adjustment to the state of the digital car key, and determine the identifier of the adjusted digital car key state version to obtain a first version number. By setting the first version number, the terminal can determine whether to execute the first instruction based on its own second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key state across multiple terminals.

[0186] Figure 7This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a server and includes:

[0187] In step S71, a second instruction from the requesting end is received, indicating that the state of the digital car key should be adjusted.

[0188] In step S72, the identifier of the adjusted digital car key's status version is determined to obtain the first version number.

[0189] In step S73, the first version number and the first instruction are sent to the terminal.

[0190] For optional implementations of steps S71 to S73, please refer to [link / reference]. Figure 6 The optional implementation methods of steps S61 to S63 will not be elaborated here.

[0191] In step S74, the receiving terminal sends a second version number, which is sent by the terminal after the network connection is restored.

[0192] In step S75, based on the second version number and the server's third version number, it is determined whether to send a third instruction to the terminal. The third instruction is used to instruct the adjustment of the state of the digital car key in the terminal, and the third version number is used to identify the current state version of the digital car key on the server.

[0193] In some implementations, determining whether to send a third instruction to the terminal based on the second version number and the server's third version number includes: determining whether to send the third instruction to the terminal based on the high-low order between the second version number and the third version number.

[0194] For example, in one embodiment, if the second version number is lower than the third version number, it is determined that the third instruction will be sent to the terminal. The fact that the second version number is lower than the third version number indicates that the digital car key status versions of the terminal and the server are inconsistent, and that the terminal's digital car key status version is lower than the server's digital car key status version. Therefore, the terminal may have failed to execute digital car key adjustment instructions, in which case the third instruction can be sent to the terminal.

[0195] In some embodiments, the second version number may also be equal to the third version number, in which case there is no need to send a third instruction.

[0196] In some embodiments, the server may also send a third instruction when the second version number and the third version number are inconsistent.

[0197] In some embodiments, when it is determined that the third instruction will be sent to the terminal, the method further includes:

[0198] Determine the current state of the digital car key on the server to obtain the first state;

[0199] The third instruction and the third version number are sent to the terminal. The third instruction is used to instruct the state of the digital car key in the terminal to be adjusted to the first state. The third version number is used to identify the state version of the digital car key in the terminal after the state is adjusted to the first state.

[0200] In one implementation, the current state of the digital car key on the server is logged out. The server can then use this logged-out state as the first state and send the third instruction and the third version number to the terminal. The third instruction instructs the digital car key in the terminal to be changed to a logged-out state, and the third version number identifies the state version of the digital car key in the terminal after the state is changed to logged-out.

[0201] In one implementation, the server's current digital car key is in a lost / reported state. The server can then use this lost / reported state as the first state and send the third instruction and the third version number to the terminal. The third instruction instructs the server to change the state of the digital car key in the terminal to a lost / reported state, and the third version number identifies the state version of the digital car key in the terminal after the state is changed to lost / reported.

[0202] Of course, the status of a digital car key is not limited to the canceled or lost status, and this disclosure does not impose any restrictions on this.

[0203] In the above embodiments, by sending a third instruction and a third version number, the status and status version of the digital car key on the terminal and the server can be automatically synchronized.

[0204] Figure 8 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure. The method is executed by a server and includes:

[0205] In step S81, a second instruction from the requesting end is received, indicating that the state of the digital car key should be adjusted.

[0206] In step S82, the identifier of the adjusted digital car key's status version is determined to obtain the first version number.

[0207] In step S83, the first version number and the first instruction are sent to the terminal.

[0208] Optional implementations of steps S81 to S83 can be found in [reference]. Figure 6 The optional implementation methods of steps S61 to S63 will not be elaborated here.

[0209] In step S84, a message sent by the receiving terminal indicating successful execution of the first instruction is received.

[0210] In step S85, a message indicating that the digital car key status adjustment was successful is sent to the requesting end.

[0211] In the above embodiment, the server can receive a message from the terminal indicating successful execution of the first instruction, and send a message to the requesting terminal indicating successful adjustment of the digital car key status, thereby completing the synchronization of the digital car key.

[0212] Figure 9 This is a flowchart illustrating a state synchronization method according to an embodiment of the present disclosure, the method comprising:

[0213] In step S91, the server receives a second instruction from the requesting end to indicate the adjustment of the state of the digital car key.

[0214] In step S92, the server determines the identifier of the adjusted digital car key's status version and obtains the first version number.

[0215] In step S93, the server sends a first version number and a first instruction to the terminal. The first instruction is used to instruct the adjustment of the status of the digital car key in the terminal.

[0216] Optional implementations of steps S91 to S93 can be found in [reference]. Figure 6 The optional implementation methods of steps S61 to S63 will not be elaborated here.

[0217] In step S94, the terminal receives the first version number and the first instruction sent by the server.

[0218] In step S95, the terminal determines whether to execute the first instruction based on the first version number and the terminal's second version number. The second version number is used to identify the current state version of the digital car key of the terminal.

[0219] Optional implementations of steps S94 to S95 can be found in [reference]. Figure 3 The optional implementation methods of steps S31 to S32 will not be elaborated here.

[0220] In the above embodiments, the terminal can determine whether to execute the first instruction based on the terminal's second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0221] Figure 10 This is an interactive flowchart illustrating a state synchronization method according to an embodiment of the present disclosure, the method comprising:

[0222] In step 101, the external action trigger source sends a digital car key status change command to the vehicle manufacturer's cloud service.

[0223] In step 102, the vehicle manufacturer's cloud service designs and records a status version number field for each digital car key. After receiving a status change instruction from an external action trigger source, it records the target change status and increments the status version number by 1.

[0224] In step 103, the vehicle manufacturer's cloud service sends a status change instruction and the status version number corresponding to the status change to the terminal.

[0225] In step 104, after receiving the status change instruction issued by the vehicle manufacturer's cloud service, the terminal executes the instruction and records the latest status version number.

[0226] In step 105, the terminal sends the successful status change result back to the vehicle manufacturer's cloud service.

[0227] In step 106, the vehicle manufacturer's cloud service records the execution results of the instructions on the terminal.

[0228] In step 107, the vehicle manufacturer's cloud service sends a notification of successful status change to the external action triggering source.

[0229] By setting a status version number field, it is helpful to identify abnormal instructions and reduce the number of times abnormal instructions are executed.

[0230] exist Figure 10 During the process, when external network conditions or engineering code errors cause the digital car key status to become out of sync between multiple devices, it can be resolved through... Figure 11 The diagram shows an interactive flowchart for a state synchronization method. (Refer to...) Figure 11 The interaction process includes:

[0231] When the vehicle or mobile device regains network connectivity, read all digital car key information from the local device, including key status and status version number, and send it to the vehicle manufacturer's cloud service.

[0232] After receiving all the digital car key information from the terminal, the car manufacturer's cloud service compares the information with the key status and status version number stored in the car manufacturer's cloud service.

[0233] For keys with out-of-sync states, the vehicle manufacturer's cloud service sends a state change command and a state version number to the terminal to prompt state synchronization.

[0234] In this way, even if the server malfunctions, the need to synchronize the digital car key can be determined by the key status and status version number reported by the terminal.

[0235] This disclosure also provides an apparatus for implementing any of the above-described state synchronization methods. For example, a state synchronization apparatus is provided, which includes units for implementing the steps performed by the terminal in any of the above-described state synchronization methods.

[0236] It should be understood that the division of the units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software: for example, the device includes a processor connected to a memory containing computer instructions. The processor calls the computer instructions stored in the memory to implement any of the above state synchronization methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the units. All units of the above device can be implemented entirely through processor-invoked software, entirely through hardware circuits, or partially through processor-invoked software with the remaining parts implemented through hardware circuits.

[0237] In this embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a Neural Network Processing Unit (NPU), a Tensor Processing Unit (TPU), a Deep Learning Processing Unit (DPU), etc.

[0238] Figure 12 This is a schematic diagram of a first state synchronization device provided in an embodiment of this disclosure. The first state synchronization device can be applied to a terminal. Figure 12 As shown, the first state synchronization device 1200 includes:

[0239] The first receiving module 1201 is configured to receive a first version number and a first instruction sent by the server. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number is used to identify the state version of the digital car key after the adjustment.

[0240] The first execution module 1202 is configured to determine whether to execute the first instruction based on the first version number and the second version number of the terminal, wherein the second version number is used to identify the current digital car key status version of the terminal.

[0241] In the above embodiments, the decision to execute the first instruction can be determined based on the terminal's second version number and the received first version number. Compared to directly executing server-side instructions, the method described in the above embodiments helps to identify abnormal instructions and reduces the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key status across multiple terminals.

[0242] Optionally, the first execution module includes:

[0243] The first determining submodule is configured to determine whether to execute the first instruction based on the high-low order between the first version number and the second version number.

[0244] Optionally, the first determining submodule is configured as follows:

[0245] If the first version number is higher than the second version number, then the first instruction will be executed; or...

[0246] If the first version number is equal to the second version number, then the execution of the first instruction is refused; or...

[0247] If the second version number is higher than the first version number, it is determined that the first instruction will not be executed.

[0248] Optionally, it includes:

[0249] The second determining module is configured to determine that the first instruction was successfully executed.

[0250] The second execution module is configured to use the first version number as an identifier of the current digital car key status version of the terminal.

[0251] The second sending module is configured to send a message to the server indicating that the first instruction has been successfully executed.

[0252] Optionally, it includes:

[0253] The third determining module is configured to determine that the terminal has restored its network connection;

[0254] The third sending module is configured to send the second version number to the server. The second version number is used by the server to determine whether the current digital car key status version of the terminal is consistent with the digital car key status version of the server.

[0255] Figure 13 This is a schematic diagram of a second-state synchronization device provided in an embodiment of this disclosure. The second-state synchronization device can be applied to a server. Figure 13 As shown, the second state synchronization device 1300 includes:

[0256] The second receiving module 1301 is configured to receive a second instruction from the requesting end for indicating the adjustment of the state of the digital car key;

[0257] The first determining module 1302 is configured to determine the identifier of the adjusted state version of the digital car key and obtain a first version number;

[0258] The first sending module 1303 is configured to send a first version number and a first instruction to the terminal. The first instruction is used to instruct the adjustment of the state of the digital car key in the terminal. The first version number and the second version number of the terminal are used by the terminal to determine whether to execute the first instruction. The second version number is used to identify the current state version of the digital car key of the terminal.

[0259] In the above embodiments, the server can receive a second instruction from the requesting terminal indicating an adjustment to the state of the digital car key, and determine the identifier of the adjusted digital car key state version to obtain a first version number. By setting the first version number, the terminal can determine whether to execute the first instruction based on its own second version number and the received first version number. Compared to directly executing the server's instructions, the method in the above embodiments helps to identify abnormal instructions and reduce the number of times abnormal instructions are executed. This also helps to ensure the consistency of the digital car key state across multiple terminals.

[0260] Optionally, it includes:

[0261] The third receiving module is configured to receive a second version number sent by the terminal after the network connection is restored.

[0262] The fourth determining module is configured to determine whether to send a third instruction to the terminal based on the second version number and the third version number of the server. The third instruction is used to instruct the adjustment of the state of the digital car key in the terminal, and the third version number is used to identify the current state version of the digital car key on the server.

[0263] Optionally, the fourth determining module includes:

[0264] The second determining submodule is configured to determine whether to send the third instruction to the terminal based on the high-low order between the second version number and the third version number.

[0265] Optionally, the second determining submodule is configured as follows:

[0266] If the second version number is lower than the third version number, it is determined that the third instruction will be sent to the terminal.

[0267] Optionally, the fourth determining module determines to send the third instruction to the terminal, and the second state synchronization device includes:

[0268] The status determination module is configured to determine the current status of the digital car key on the server and obtain a first status.

[0269] The fourth sending module is configured to send the third instruction and the third version number to the terminal. The third instruction is used to instruct the state of the digital car key in the terminal to be adjusted to the first state, and the third version number is used to identify the state version of the digital car key of the terminal after the state is adjusted to the first state.

[0270] Optionally, it includes:

[0271] The fourth receiving module is configured to receive a message sent by the terminal indicating successful execution of the first instruction;

[0272] The fifth sending module is configured to send a message to the requesting end indicating that the digital car key status adjustment has been successful.

[0273] Figure 14 This is a schematic diagram of the structure of the communication device 8100 provided in this embodiment. The communication device 8100 can be a network device configured as a server, a terminal (e.g., a user equipment), a chip, chip system, or processor that supports the network device in implementing any of the above-described state synchronization methods, or a chip, chip system, or processor that supports the terminal in implementing any of the above-described state synchronization methods. The communication device 8100 can be used to implement the state synchronization methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0274] like Figure 14 As shown, the communication device 8100 includes one or more processors 8101, which are used to invoke computer instructions to cause the communication device 8100 to execute any of the above-mentioned state synchronization methods.

[0275] Optionally, the communication device 8100 also includes one or more memories 8102 for storing computer instructions. In optional embodiments, all or part of the memories 8102 may also be located outside the communication device 8100.

[0276] Optionally, the communication device 8100 further includes one or more transceivers 8103. When the communication device 8100 includes one or more transceivers 8103, the communication steps such as sending and receiving in the above-described state synchronization method are performed by the transceivers 8103, and other steps are performed by the processor 8101.

[0277] The communication device 8100 described in the above embodiments may be a network device or a terminal, but the scope of the communication device 8100 described in this disclosure is not limited thereto, and the structure of the communication device 8100 may vary. Figure 14 The limitations. Communication equipment can be a standalone device or part of a larger device. For example, the communication equipment can be: (1) a standalone integrated circuit IC, or chip, or chip system or subsystem; (2) a collection of one or more ICs, optionally including storage components for storing data and computer programs; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, terminal device, smart terminal device, cellular phone, wireless device, handheld device, mobile unit, vehicle-mounted device, network device, cloud device, artificial intelligence device, etc.; (6) others, etc.

[0278] This disclosure also provides a readable storage medium storing computer instructions that, when executed on a communication device 8100, cause the communication device 8100 to perform any of the above-described state synchronization methods. Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium or a temporary computer-readable storage medium.

[0279] This disclosure also provides a computer program product, which, when executed by a communication device 8100, causes the communication device 8100 to perform any of the above-mentioned state synchronization methods.

Claims

1. A state synchronization method, characterized by, The method is executed by a terminal and comprises: receiving a first version number and a first instruction sent by a server, the first instruction being used to indicate adjustment of a state of a digital vehicle key in the terminal, the state comprising any one of a loss state, a deletion state and a recovery state, and the first version number being used to identify a state version of the digital vehicle key after adjustment; determining whether to execute the first instruction according to the first version number and a second version number of the terminal, the second version number being used to identify a current state version of the digital vehicle key in the terminal.

2. The method of claim 1, wherein, The determination whether to execute the first instruction according to the first version number and the second version number of the terminal comprises: determining whether to execute the first instruction according to a high-low order between the first version number and the second version number.

3. The method of claim 2, wherein, The determination whether to execute the first instruction according to the high-low order between the first version number and the second version number comprises: when the first version number is higher than the second version number, determining to execute the first instruction; or when the first version number is equal to the second version number, determining to refuse to execute the first instruction; or when the second version number is higher than the first version number, determining to refuse to execute the first instruction.

4. The method according to any one of claims 1 to 3, characterized in that, The method comprises: determining that the first instruction is successfully executed; taking the first version number as an identifier of the current state version of the digital vehicle key in the terminal; and sending, to the server, a message indicating that the first instruction is successfully executed.

5. The method according to any one of claims 1 to 3, characterized in that, The method comprises: determining that the terminal restores network connection; and sending, to the server, the second version number, the second version number being used by the server to determine whether the state version of the digital vehicle key in the terminal is consistent with a state version of a digital vehicle key in the server.

6. A state synchronization method characterized by, The method is executed by a server and comprises: receiving a second instruction of a request end, the second instruction being used to indicate adjustment of a state of a digital vehicle key; determining an identifier of a state version of the digital vehicle key after adjustment, to obtain a first version number; and sending, to a terminal, the first version number and a first instruction, the first instruction being used to indicate adjustment of the state of the digital vehicle key in the terminal, the state comprising any one of a loss state, a deletion state and a recovery state, and the first version number and a second version number of the terminal being used by the terminal to determine whether to execute the first instruction, the second version number being used to identify a current state version of the digital vehicle key in the terminal.

7. The method of claim 6, wherein, The method comprises: receiving a second version number sent by the terminal, the second version number being sent by the terminal after the terminal restores network connection; and determining whether to send a third instruction to the terminal according to the second version number and a third version number of the server, the third instruction being used to indicate adjustment of the state of the digital vehicle key in the terminal, and the third version number being used to identify a current state version of the digital vehicle key in the server.

8. The method of claim 7, wherein, The determination whether to send the third instruction to the terminal according to the second version number and the third version number of the server comprises: determining whether to send the third instruction to the terminal according to a high-low order between the second version number and the third version number.

9. The method of claim 8, wherein, The determining whether to send the third instruction to the terminal according to the high-low order between the second version number and the third version number comprises: The second version number is lower than the third version number, and it is determined to send the third instruction to the terminal.

10. The method according to any one of claims 7 to 9, characterized in that, Comprise: Determine to send the third instruction to the terminal; Determine the current state of the digital car key of the server, and obtain a first state; Send the third instruction and the third version number to the terminal, the third instruction being used to instruct to adjust the state of the digital car key in the terminal to the first state, and the third version number being used to identify the state version of the digital car key of the terminal after the state is adjusted to the first state.

11. The method according to any one of claims 6 to 9, characterized in that, Comprise: Receive the message sent by the terminal for indicating the successful execution of the first instruction; Send the message for indicating the successful adjustment of the state of the digital car key to the request end.

12. A first state synchronization apparatus, characterized by comprising: Applied to a terminal, the apparatus comprises: A first receiving module configured to receive a first version number and a first instruction sent by a server, the first instruction being used to instruct to adjust the state of a digital car key in the terminal, the state comprising any one of a loss state, a deletion state and a recovery state, and the first version number being used to identify the state version of the digital car key after the adjustment. A first execution module configured to determine whether to execute the first instruction according to the first version number and a second version number of the terminal, the second version number being used to identify the state version of the digital car key of the terminal at present.

13. A second state synchronizing apparatus characterized by comprising: Applied to a server, the apparatus comprises: A second receiving module configured to receive a second instruction for instructing to adjust the state of a digital car key sent by a request end; A first determining module configured to determine the identification of the state version of the digital car key after the adjustment, and obtain a first version number; A first sending module configured to send the first version number and the first instruction to a terminal, the first instruction being used to instruct to adjust the state of a digital car key in the terminal, the state comprising any one of a loss state, a deletion state and a recovery state, and the first version number and a second version number of the terminal being used by the terminal to determine whether to execute the first instruction, the second version number being used to identify the state version of the digital car key of the terminal at present.

14. A state synchronization method, characterized by, Comprise: The server receives a second instruction for instructing to adjust the state of a digital car key sent by a request end; The server determines the identification of the state version of the digital car key after the adjustment, and obtains a first version number; The server sends the first version number and the first instruction to a terminal, the first instruction being used to instruct to adjust the state of a digital car key in the terminal, the state comprising any one of a loss state, a deletion state and a recovery state; The terminal receives the first version number and the first instruction sent by the server; The terminal determines whether to execute the first instruction according to the first version number and a second version number of the terminal, the second version number being used to identify the state version of the digital car key of the terminal at present.

15. A communication device, characterized by Comprise: One or more processors; The processor is configured to call computer instructions to enable the communication device to execute the state synchronization method in any one of claims 1-11.

16. A state synchronization system, characterized by A terminal and a server are included, wherein the terminal is configured to implement the state synchronization method of any one of claims 1 to 5, and the server is configured to implement the state synchronization method of any one of claims 6 to 11.

17. A computer-readable storage medium having stored computer instructions, wherein, The computer instructions, when executed on a communications device, cause the communications device to perform the state synchronization method of any one of claims 1-11.

Images