A method, device, medium, and program product for local de-identification generation of vehicle voice control commands.

Abstract

This application provides a method, device, medium, and program product for locally anonymized generation of in-vehicle voice control commands. The method includes: acquiring user voice control commands and performing local semantic parsing to obtain a semantic parsing result including user intent and semantic parameters, where the semantic parameters include semantic parameter type and semantic parameter value; determining a control action based on the user intent, and determining sensitive semantic parameters associated with the control action based on the semantic parameter type and a sensitive type set, where the sensitive semantic parameters include sensitive semantic parameter type and sensitive semantic parameter value; matching corresponding privacy data objects from a local privacy data set on the vehicle side based on the sensitive semantic parameters to generate a local execution identifier to replace the sensitive semantic parameter value; and generating anonymized vehicle control commands based on the control action, the local execution identifier, and non-sensitive semantic parameters. This application avoids sensitive plaintext from entering vehicle control commands, improving privacy protection capabilities during in-vehicle voice interaction.

Description

Technical Field

[0001] This application relates to the field of voice interaction privacy protection technology, and in particular to a method, device, medium and program product for local de-identification generation of in-vehicle voice control commands. Background Technology

[0002] With the development of intelligent cockpit technology, in-vehicle voice assistants have been widely used in vehicle function control scenarios such as navigation, communication, air conditioning, windows, and entertainment. In order to reduce network dependence and improve response speed, some in-vehicle voice assistants also adopt offline speech recognition, local dialogue systems, lightweight models, and local databases to complete speech recognition, semantic understanding, and vehicle function control on the vehicle side.

[0003] Existing offline in-vehicle voice assistants typically focus on the accuracy of voice recognition, the ability to perform semantic understanding locally, and the timely execution of vehicle control commands. For example, current solutions may incorporate a voice recognition control module and an AI module on the vehicle's infotainment system. These modules collect user voice data via microphone and use a natural language processing module to segment the text, tag it with parts of speech, identify named entities, and process user intent, thereby enabling vehicle function control such as navigation, in-vehicle entertainment, security, and intelligent interaction. However, when user voice commands involve sensitive information such as contacts, phone numbers, home addresses, and company addresses, current solutions typically treat this information merely as ordinary semantic parameters for intent recognition and command matching, lacking local isolation and desensitization mechanisms for sensitive semantic parameters. Even if voice recognition and semantic understanding are performed on the vehicle side, sensitive semantic parameter values ​​obtained from semantic parsing may still enter vehicle control commands, controller call parameters, voice feedback content, or system operation logs. When the in-vehicle system transmits data back based on diagnostic, maintenance, or OTA processes, or when third-party applications can access the in-vehicle's general storage area, these sensitive semantic parameter values ​​can be further exposed through logs or cached data, increasing the risk of privacy leaks.

[0004] Therefore, how to achieve local anonymized generation of in-vehicle voice control commands while ensuring the security of privacy data is a technical problem that urgently needs to be solved in the field of intelligent vehicle cockpit interaction. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method, device, medium, and program product for local desensitization generation of in-vehicle voice control commands, which at least solves the problem of avoiding the exposure of sensitive personal information in the semantic parsing results in the vehicle control execution chain when existing offline in-vehicle voice assistants process voice control commands containing sensitive semantic parameters.

[0006] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0007] In a first aspect, some embodiments of this application provide a method for local de-identification generation of in-vehicle voice control commands, including:

[0008] The system acquires user voice control commands and performs local semantic parsing on the user voice control commands to obtain semantic parsing results. The semantic parsing results include user intent and semantic parameters corresponding to the user intent. The semantic parameters include semantic parameter type and semantic parameter value.

[0009] The corresponding control action is determined based on the user intent, and the sensitive semantic parameters associated with the control action are determined from the semantic parsing results based on the semantic parameter type and the preset set of sensitive types. The sensitive semantic parameters include sensitive semantic parameter type and sensitive semantic parameter value.

[0010] Based on the sensitive semantic parameters, a privacy data object corresponding to the control action is matched from the local privacy data set on the vehicle, and a local execution identifier of the privacy data object is generated;

[0011] Based on the control action, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing result, a desensitized vehicle control command is generated for sending to the vehicle-side execution unit; wherein, the local execution identifier is used to replace the sensitive semantic parameter value in the semantic parsing result.

[0012] Optionally, the step of determining the sensitive semantic parameters associated with the control action from the semantic parsing result based on the semantic parameter type and a preset set of sensitive types includes:

[0013] The semantic parameter types of each semantic parameter in the semantic parsing result are compared with a preset set of sensitive types, and the semantic parameters whose semantic parameter types belong to the set of sensitive types are determined as candidate sensitive parameters.

[0014] Based on the control action, a preset mapping table of control actions and sensitive parameter types is queried to obtain the set of target sensitive parameter types corresponding to the control action;

[0015] If the semantic parameter type of the candidate sensitive parameter belongs to the target sensitive parameter type set, the candidate sensitive parameter is determined as a sensitive semantic parameter associated with the control action;

[0016] If the set of target sensitive parameter types is empty or the semantic parameter type of the candidate sensitive parameter does not belong to the set of target sensitive parameter types, the candidate sensitive parameter is determined as a non-sensitive semantic parameter.

[0017] In this alternative approach, semantic parameters are initially screened using a set of sensitive types, and then a secondary judgment is made by combining the mapping table between control actions and sensitive parameter types. This allows for the dynamic determination of the sensitive semantic parameters that truly need desensitization under the current control action, reducing the false desensitization of ordinary semantic parameters and preventing the omission of privacy parameters related to the current control action.

[0018] Optionally, the privacy data set is encrypted and stored in a secure storage area on the vehicle side. The privacy data set includes multiple privacy data fields, and different privacy data fields are used to store different types of privacy data objects.

[0019] The step of matching the privacy data object corresponding to the control action from the vehicle-side local privacy data set based on the sensitive semantic parameters includes:

[0020] Based on the control action and the sensitive semantic parameter type, a target privacy data domain is determined from the plurality of privacy data domains;

[0021] In the target privacy data domain, the privacy data object corresponding to the control action is matched based on the sensitive semantic parameter value.

[0022] In this alternative solution, by encrypting and storing the privacy data set in the vehicle's secure storage area and classifying and managing it according to privacy data domains, the matching range of privacy data objects can be limited based on control actions and sensitive semantic parameter types, thereby reducing unnecessary access to privacy data and improving local matching efficiency and privacy data access security.

[0023] Optionally, the step of generating the local execution identifier of the privacy data object includes:

[0024] Within the vehicle-side secure storage area, vehicle execution parameters and corresponding execution parameter types that match the control action are determined from the privacy data object;

[0025] Based on the control action and the execution parameter type, the target vehicle-side calling interface is determined from the preset set of vehicle-side calling interfaces, and an interface calling index corresponding to the target vehicle-side calling interface is generated;

[0026] Based on the object identifier of the privacy data object, the action identifier of the control action, the current voice control session identifier, and the session random number, a virtual execution handle bound to the current voice control session is generated;

[0027] Establish a local mapping relationship between the virtual execution handle and the vehicle execution parameters, and determine the virtual execution handle and the interface call index as the local execution identifier.

[0028] In this alternative approach, a virtual execution handle bound to the current voice control session is generated, and a local execution identifier is formed by combining it with the interface call index. This allows the virtual execution handle to replace the plaintext of vehicle execution parameters, and the interface call index to determine the vehicle-side call interface. This approach balances the desensitization of privacy parameters with the execution routing of vehicle control commands.

[0029] Optionally, the step of generating desensitized vehicle control commands for sending to the vehicle-side execution unit based on the control action, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing result includes:

[0030] The corresponding vehicle-side execution unit and instruction type are determined based on the control action;

[0031] The control action, the instruction type, the local execution identifier, and the non-sensitive semantic parameters are encapsulated into a desensitized instruction payload;

[0032] Based on the current voice control session identifier, the action identifier of the control action, and the desensitized instruction payload, an instruction verification tag is generated;

[0033] The desensitized instruction payload and the instruction verification tag are encapsulated into the desensitized vehicle control instruction, and the desensitized vehicle control instruction is sent to the vehicle-side execution unit.

[0034] In this alternative approach, by encapsulating control actions, command types, local execution identifiers, and non-sensitive semantic parameters into desensitized command payloads and generating command verification tags, desensitized vehicle control commands can be bound to the current voice control session and control actions, reducing the risk of desensitized commands being tampered with, reused across sessions, or misused across actions.

[0035] Optionally, after sending the desensitized vehicle control command to the vehicle-side execution unit, the method further includes:

[0036] The vehicle-side execution unit parses the desensitized vehicle control command to obtain the desensitized command payload and command verification tag, and verifies the command verification tag based on the current voice control session identifier, the action identifier of the control action, and the desensitized command payload;

[0037] If the instruction verification tag passes the verification, the vehicle-side execution unit extracts the interface call index and virtual execution handle from the de-identified instruction payload;

[0038] The vehicle-side execution unit determines the vehicle-side calling interface based on the interface calling index, and sends the virtual execution handle to the vehicle-side calling interface;

[0039] The target vehicle-side calling interface accesses the vehicle-side secure storage area based on interface permission verification, and queries the local mapping relationship according to the virtual execution handle to obtain the corresponding vehicle execution parameters;

[0040] The vehicle-side execution unit performs vehicle control operations corresponding to the control actions based on the vehicle execution parameters.

[0041] If the instruction verification tag fails to pass verification, the desensitized vehicle control instruction will be refused to be executed.

[0042] In this alternative solution, the vehicle-side execution unit performs instruction verification before executing the desensitized vehicle control instructions. After the verification is successful, it performs interface routing based on the interface call index and queries the vehicle execution parameters in the vehicle-side secure storage area based on the virtual execution handle, so that it can complete the vehicle control operation without exposing sensitive plaintext.

[0043] Optionally, the method further includes:

[0044] Maintain a desensitized context record in the current voice control session; wherein, when the user voice control command in any round generates the virtual execution handle and the interface call index, the virtual execution handle, the interface call index and the handle inheritance conditions determined according to the control action corresponding to the round are written to or updated to the desensitized context record, and the desensitized context record does not include the sensitive semantic parameter value and the vehicle execution parameter;

[0045] When a user voice control instruction for a subsequent round is received in the current voice control session, and the user voice control instruction for the subsequent round needs to use the privacy data object of the previous round, the virtual execution handle and interface call index to be inherited are determined from the desensitized context record based on the handle inheritance condition.

[0046] The virtual execution handle to be inherited and the interface call index are determined as the local execution identifier of the user voice control command in the subsequent rounds. Based on the subsequent control action, local execution identifier and non-sensitive semantic parameters corresponding to the user voice control command in the subsequent rounds, the desensitized vehicle control command corresponding to the user voice control command in the subsequent rounds is generated.

[0047] In this alternative approach, by maintaining desensitized context records that do not contain sensitive semantic parameter values ​​and vehicle execution parameters in multi-round voice control sessions, subsequent rounds can inherit the virtual execution handles and interface call indexes of previous rounds to reuse privacy data objects, thereby supporting multi-round continuous control while preventing sensitive plaintext from entering the multi-round dialogue context.

[0048] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0049] One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform a local de-identification generation method for in-vehicle voice control instructions as described above.

[0050] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the local desensitization generation method for vehicle voice control instructions as described above.

[0051] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the local desensitization generation method for vehicle voice control instructions as described above.

[0052] Compared with existing technologies, the solution provided in this application performs semantic parsing of user voice control commands locally on the vehicle side and combines it with the control actions corresponding to the user's intent. Sensitive semantic parameters associated with the control actions are identified from the semantic parsing results. This avoids sensitive information such as contacts, frequently visited destinations, addresses, and phone numbers being directly used as ordinary semantic parameters in the generation of vehicle control commands. Based on the sensitive semantic parameters, corresponding privacy data objects are matched in the vehicle's local privacy data set, and a local execution identifier is generated to replace the sensitive semantic parameter values. This allows subsequent de-identified vehicle control commands to be generated and sent to the vehicle execution unit normally based on the control actions, the local execution identifier, and non-sensitive semantic parameters. Therefore, this application ensures the normal execution of in-vehicle voice control functions such as navigation and communication while preventing sensitive semantic parameter values ​​and corresponding plaintext privacy content from directly entering the generation and transmission link of vehicle control commands, thus improving privacy protection capabilities during in-vehicle voice interaction. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating a method for local desensitization generation of vehicle voice control commands provided in an embodiment of this application.

[0055] Figure 2This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0057] Some embodiments of this application relate to a local anonymized generation method for in-vehicle voice control commands. This method can be applied to application environments such as vehicle smart cockpits, in-vehicle infotainment systems, in-vehicle voice assistants, or vehicle-side voice control systems. It can also be deployed in vehicle systems, cockpit domain controllers, in-vehicle voice assistant modules, or other in-vehicle computing devices with local speech recognition and local semantic parsing capabilities. The aforementioned in-vehicle computing devices can communicate with navigation services, communication services, in-vehicle application services, window controllers, air conditioning controllers, or other in-vehicle execution units, suitable for scenarios where users control navigation, communication, in-vehicle applications, or vehicle functional components via voice. Especially when user voice control commands involve sensitive semantic parameters such as contacts, phone numbers, home addresses, company addresses, and frequently used destinations, this method can complete semantic parsing, privacy data matching, and anonymized vehicle control command generation locally on the vehicle side, enabling the in-vehicle execution unit to perform corresponding vehicle control operations without receiving sensitive plaintext information. (Refer to...) Figure 1 As shown, the method may include the following steps:

[0058] Step S1: Obtain the user's voice control command and perform local semantic parsing on the user's voice control command to obtain the semantic parsing result. The semantic parsing result includes the user's intent and the semantic parameters corresponding to the user's intent. The semantic parameters include the semantic parameter type and the semantic parameter value.

[0059] In one specific embodiment, the vehicle-mounted computing device can acquire user voice signals via a microphone array installed in the vehicle cabin to obtain user voice control commands. After acquiring the user voice signal, the vehicle-mounted computing device performs preprocessing on the user voice signal locally. Preprocessing may include at least one of echo cancellation, environmental noise suppression, voice enhancement, endpoint detection, and feature extraction. Endpoint detection is used to determine the start and end positions of the user's voice control commands, and feature extraction can be used to extract Mel-frequency cepstral coefficients, Mel-spectral features, or other acoustic features from the user voice signal. It should be noted that the original audio data corresponding to the user voice signal can be processed locally on the vehicle-mounted device without being uploaded to a cloud server, and the acoustic features obtained after preprocessing can be directly input into the semantic understanding model deployed locally on the vehicle-mounted device.

[0060] Optionally, the edge semantic understanding model can be a lightweight semantic model that has undergone model quantization, structured pruning, and / or knowledge distillation to adapt to the vehicle's computing resources and real-time interaction requirements. For example, the model can be compressed using INT8 quantization, the model parameter size can not exceed a preset size, and the model file size can be compressed to a range that can be loaded on the vehicle, thereby completing local inference on the vehicle's infotainment chip, NPU processor, GPU processor, or other vehicle processors.

[0061] A local semantic parsing of preprocessed acoustic features is performed using an edge-side semantic understanding model. Specifically, the acoustic features are first converted into text recognition results by an automatic speech recognition module, and then the text recognition results are processed by a natural language understanding module to perform intent recognition and semantic parameter extraction, thereby obtaining the semantic parsing result. The semantic parsing result can include the user intent and at least one semantic parameter corresponding to the user intent. The semantic parameter includes the semantic parameter type and the semantic parameter value. The user intent represents the vehicle-side function that the user wishes to perform, such as navigation, dialing, sending messages, turning on the air conditioning, adjusting the windows, or playing media; the semantic parameter is used to limit the execution object, execution conditions, or execution parameters of the user intent.

[0062] For example, for a user's voice control command "navigate to a frequently used location", the user intent obtained from local semantic parsing can be navigation control, the semantic parameter type can include frequently used location type, and the semantic parameter value can be home address, company address or other preset frequently used location identifier; for a user's voice control command "send a message to a contact", the user intent obtained from local semantic parsing can be message sending control, the semantic parameter type can include communication object type, and the semantic parameter value can be contact name, contact alias or contact relationship identifier.

[0063] Step S2: Determine the corresponding control action based on the user's intent, and determine the sensitive semantic parameters associated with the control action from the semantic parsing results based on the semantic parameter type and the preset set of sensitive types. The sensitive semantic parameters include the sensitive semantic parameter type and the sensitive semantic parameter value.

[0064] In some embodiments, after obtaining the semantic parsing results, the vehicle-side computing device can determine the corresponding control action based on the user's intent. The user intent represents the vehicle-side function the user wishes to achieve, and the control action represents the specific operation that the vehicle-side execution unit can perform. For example, the user intent could be a navigation intent, a communication intent, an air conditioning adjustment intent, a window control intent, or a media playback intent; the corresponding control action could be starting navigation, initiating communication, adjusting the air conditioning temperature, controlling the opening and closing of windows, or playing media content.

[0065] The vehicle-side computing device can determine whether there are parameters related to user privacy among the semantic parameters based on the semantic parameter types in the semantic parsing results and a preset set of sensitive types. The set of sensitive types can include contact types, communication object types, address types, frequently used location types, and travel location types. If a semantic parameter type belongs to the set of sensitive types, and the semantic parameter is related to the execution object or execution parameter of the current control action, then the semantic parameter can be identified as a sensitive semantic parameter associated with the control action. Sensitive semantic parameters can include both a sensitive semantic parameter type and a sensitive semantic parameter value.

[0066] Step S3: Based on the sensitive semantic parameters, match the privacy data object corresponding to the control action from the local privacy data set on the vehicle, and generate a local execution identifier for the privacy data object.

[0067] In some embodiments, the vehicle may locally store a privacy data set, which may include data related to the user's personal information, such as contact data, phone number data, frequently used location data, address data, and travel location data. After determining the sensitive semantic parameters, the vehicle-side computing device can match the privacy data object corresponding to the current control action in the vehicle's local privacy data set according to the sensitive semantic parameter type and value.

[0068] For example, when the control action is to initiate navigation, the corresponding location object can be matched in the local privacy data set based on sensitive semantic parameters of common location types or address types. When the control action is to initiate communication or send a message, the vehicle-side computing device can match the corresponding contact object in the local privacy data set based on sensitive semantic parameters of contact type or communication object type. After matching the privacy data object, a local execution identifier corresponding to the privacy data object is generated, enabling this local execution identifier to replace the sensitive semantic parameter value in subsequent vehicle control commands.

[0069] Step S4: Based on the control action, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing result, generate a desensitized vehicle control command to be sent to the vehicle-side execution unit; wherein, the local execution identifier is used to replace the sensitive semantic parameter values ​​in the semantic parsing implementation result.

[0070] In some embodiments, after generating a local execution identifier, the vehicle-side computing device can generate desensitized vehicle control instructions based on the control action, the local execution identifier, and non-sensitive semantic parameters from the semantic parsing results. Non-sensitive semantic parameters can be parameters used to define the execution method of the control action but do not involve sensitive personal information of the user, such as target air conditioning temperature, window position, volume level, route preference, and playback mode. When generating desensitized vehicle control instructions, the vehicle-side computing device does not directly write the values ​​of sensitive semantic parameters into the vehicle control instructions; instead, it writes the local execution identifier as the desensitized execution object into the desensitized vehicle control instructions. For example, for navigation control instructions, the desensitized vehicle control instructions may include a navigation initiation action, a local execution identifier, and non-sensitive semantic parameters such as route preferences, but not the specific address plaintext; for communication control instructions, the desensitized vehicle control instructions may include a communication control action and a local execution identifier, but not the contact name or communication number plaintext.

[0071] Compared with existing technologies, the solution provided in this application performs semantic parsing of user voice control commands locally on the vehicle side and combines it with the control actions corresponding to the user's intent. Sensitive semantic parameters associated with the control actions are identified from the semantic parsing results. This avoids sensitive information such as contacts, frequently visited destinations, addresses, and phone numbers being directly used as ordinary semantic parameters in the generation of vehicle control commands. Based on the sensitive semantic parameters, corresponding privacy data objects are matched in the vehicle's local privacy data set, and a local execution identifier is generated to replace the sensitive semantic parameter values. This allows subsequent de-identified vehicle control commands to be generated and sent to the vehicle execution unit normally based on the control actions, the local execution identifier, and non-sensitive semantic parameters. Therefore, this application ensures the normal execution of in-vehicle voice control functions such as navigation and communication while preventing sensitive semantic parameter values ​​and corresponding plaintext privacy content from directly entering the generation and transmission link of vehicle control commands, thus improving privacy protection capabilities during in-vehicle voice interaction.

[0072] Optionally, in some embodiments, step S2, which involves determining the sensitive semantic parameters associated with the control action from the semantic parsing results based on the semantic parameter type and a preset set of sensitive types, includes:

[0073] Step S201: Compare the semantic parameter types of each semantic parameter in the semantic parsing result with the preset sensitive type set, and determine the semantic parameters whose semantic parameter types belong to the sensitive type set as candidate sensitive parameters.

[0074] In some embodiments, the vehicle-side computing device may pre-configure a set of sensitive types. This set of sensitive types characterizes semantic parameter types that may involve user privacy in in-vehicle voice control scenarios. The set of sensitive types may include at least one of the following: contact type, communication number type, communication object type, home address type, company address type, frequently visited location type, travel location type, and device identifier type. The set of sensitive types may be stored in a local configuration file on the vehicle, a secure storage area on the vehicle, or a parameter configuration table corresponding to the semantic parsing model, and may be updated according to vehicle function configuration, user privacy settings, or vehicle application permissions.

[0075] After obtaining the semantic parsing results, the semantic parameters in the results are traversed, and the semantic parameter type corresponding to each semantic parameter is read. For any semantic parameter, it is determined whether its semantic parameter type belongs to the sensitive type set. If the semantic parameter type belongs to the sensitive type set, it means that the semantic parameter may involve user privacy information such as contacts, addresses, frequently visited locations, and communication numbers in the vehicle voice control scenario, and the semantic parameter can be identified as a candidate sensitive parameter. Candidate sensitive parameters can include candidate sensitive parameter types and candidate sensitive parameter values, where the candidate sensitive parameter type can correspond to the semantic parameter type, and the candidate sensitive parameter value can correspond to the semantic parameter value.

[0076] Step S202: Query the preset mapping table of control actions and sensitive parameter types according to the control action to obtain the set of target sensitive parameter types corresponding to the control action.

[0077] In some embodiments, the vehicle-side computing device may pre-configure a mapping table between control actions and sensitive parameter types. This mapping table records the correspondence between different control actions and the types of sensitive parameters involved in their execution. This mapping table is not used to determine whether a certain semantic parameter type is generally considered a privacy type, but rather to determine which sensitive semantic parameters will participate in subsequent vehicle control processing as the execution object, execution condition, or execution parameter of the current control action.

[0078] The control action-sensitive parameter type mapping table can include multiple mapping entries. Each mapping entry includes a control action identifier and a set of target sensitive parameter types corresponding to that control action identifier. The control action identifier represents a control action that the vehicle-side execution unit can perform, such as starting navigation, initiating communication, sending a message, calling an in-vehicle application, or connecting to an in-vehicle device. The target sensitive parameter type set represents the sensitive parameter types that may need to be matched with the vehicle's local privacy data set when executing the control action.

[0079] For example, when the control action is to start navigation, the corresponding set of target sensitive parameter types may include frequently used location type, address type, destination type, or trip location type; when the control action is to initiate communication or send a message, the corresponding set of target sensitive parameter types may include contact type, communication object type, or communication number type; when the control action is to connect to an in-vehicle device, the corresponding set of target sensitive parameter types may include device identifier type. However, when the control action is to adjust the air conditioning temperature, adjust the volume, or control the opening and closing of the windows, if the control action typically does not require access to private data such as contacts, addresses, or communication numbers, the corresponding set of target sensitive parameter types can be empty.

[0080] After determining the control action based on the user's intent, the vehicle-side computing device can query the above-mentioned control action and sensitive parameter type mapping table based on the control action identifier corresponding to the control action, thereby obtaining the set of target sensitive parameter types corresponding to the current control action.

[0081] Step S203: If the semantic parameter type of the candidate sensitive parameter belongs to the target sensitive parameter type set, the candidate sensitive parameter is determined as a sensitive semantic parameter associated with the control action.

[0082] In some embodiments, the semantic parameter type of a candidate sensitive parameter is matched with each sensitive parameter type in the target sensitive parameter type set. If the semantic parameter type of a candidate sensitive parameter belongs to the target sensitive parameter type set, it indicates that the candidate sensitive parameter may not only involve user privacy in terms of type, but also participate in subsequent vehicle control processing as an execution object, execution condition, or execution parameter during the execution of the current control action. Therefore, the vehicle-side computing device can determine the candidate sensitive parameter as a sensitive semantic parameter associated with the current control action. The sensitive semantic parameter associated with the control action may include a sensitive semantic parameter type and a sensitive semantic parameter value. The sensitive semantic parameter type can be used to represent the privacy category corresponding to the sensitive semantic parameter, and the sensitive semantic parameter value can be a specific parameter value or referential information extracted from the semantic parsing result. For example, if the control action is to start navigation, and the semantic parameter type of the candidate sensitive parameter is a common location type, and the target sensitive parameter type set includes the common location type, then the candidate sensitive parameter can be determined as a sensitive semantic parameter associated with the start navigation action; if the control action is to send a message, and the semantic parameter type of the candidate sensitive parameter is a communication object type, and the target sensitive parameter type set includes the communication object type, then the candidate sensitive parameter can be determined as a sensitive semantic parameter associated with the send message action.

[0083] In the presence of multiple candidate sensitive parameters, the vehicle-side computing device can perform the above matching process on each candidate sensitive parameter separately, and determine all candidate sensitive parameters whose semantic parameter type belongs to the target sensitive parameter type set as sensitive semantic parameters associated with the current control action.

[0084] Step S204: If the target sensitive parameter type set is empty or the semantic parameter type of the candidate sensitive parameter does not belong to the target sensitive parameter type set, the candidate sensitive parameter is determined as a non-sensitive semantic parameter.

[0085] In some embodiments, if the target sensitive parameter type set is empty, or the semantic parameter type of a candidate sensitive parameter does not belong to the target sensitive parameter type set, it indicates that although the candidate sensitive parameter belongs to the preset sensitive type set, it is unrelated to the execution object or execution parameter of the current control action. Therefore, the vehicle-side computing device does not determine the candidate sensitive parameter as a sensitive semantic parameter associated with the current control action and excludes it from the local privacy data matching and desensitization replacement process corresponding to the current control action. This avoids performing desensitization processing under all control actions simply because a certain semantic parameter type belongs to the global sensitive type set, thereby improving the accuracy of sensitive semantic parameter identification.

[0086] In the solution provided in this embodiment, through steps S201 to S204, semantic parameters are first initially screened based on a preset set of sensitive types, and then verified in conjunction with the set of target sensitive parameter types corresponding to the current control action. This ensures that only candidate sensitive parameters actually related to the current control action are identified as sensitive semantic parameters. Therefore, this avoids false desensitization caused by static judgment based solely on the global set of sensitive types, reduces the number of candidate sensitive parameters unrelated to the current control action entering the local privacy data matching and desensitization replacement process, and also avoids the risk of missing privacy parameters required for the current control action, thus improving the accuracy of subsequent privacy data matching and desensitized vehicle control command generation.

[0087] Optionally, in some embodiments, the privacy data set is encrypted and stored in a secure vehicle-side storage area. The secure vehicle-side storage area can be a trusted execution environment, a security domain, an encrypted storage partition, or other vehicle-side storage area with access control capabilities. The privacy data set includes multiple privacy data domains, each used to store different types of privacy data objects. For example, privacy data domains may include contact data domains, communication number data domains, frequently visited location data domains, address data domains, travel location data domains, and in-vehicle device data domains; correspondingly, privacy data objects may include contact objects, communication number objects, frequently visited location objects, address objects, travel location objects, and in-vehicle device objects.

[0088] In step S3, the step of matching the privacy data object corresponding to the control action from the vehicle's local privacy data set based on the sensitive semantic parameters specifically includes:

[0089] Step S301: Determine the target privacy data domain from multiple privacy data domains based on the control action and sensitive semantic parameter type.

[0090] In some embodiments, after determining the sensitive semantic parameters, the vehicle-side computing device can jointly determine the target privacy data domain to be accessed based on the current control action and the sensitive semantic parameter type. The control action limits the vehicle-side function to be executed, and the sensitive semantic parameter type limits the data category to which the privacy data object to be matched belongs. For example, if the control action is to start navigation and the sensitive semantic parameter type is a common location type or an address type, the common location data domain or the address data domain can be determined as the target privacy data domain; if the control action is to initiate communication or send a message and the sensitive semantic parameter type is a contact type, a communication object type, or a communication number type, the contact data domain or the communication number data domain can be determined as the target privacy data domain.

[0091] Step S302: In the target privacy data domain, match the privacy data object corresponding to the control action based on the sensitive semantic parameter value.

[0092] In some embodiments, after determining the target privacy data domain, a privacy data object corresponding to the current control action can be matched within that target privacy data domain based on sensitive semantic parameter values. Sensitive semantic parameter values ​​can be the specific referent obtained after local semantic parsing of the user's voice control command, such as a preset contact name, contact alias, communication object identifier, frequently used location name, address alias, trip location name, or in-vehicle device name. For example, if the control action is to start navigation, and the sensitive semantic parameter value is a preset frequently used location identifier, then a frequently used location object matching the preset frequently used location identifier is searched in the frequently used location data domain; if the control action is to send a message, and the sensitive semantic parameter value is a preset contact identifier, then a contact object matching the preset contact identifier is searched in the contact data domain. The matched privacy data object serves as the privacy execution object actually needed for the current control action, such as a navigation destination object, contact object, communication number object, or in-vehicle device object.

[0093] In the solution provided in this embodiment, through steps S301 to S302, a target privacy data domain is determined from multiple privacy data domains based on the control action and the type of sensitive semantic parameters. Within the target privacy data domain, the corresponding privacy data object is matched based on the value of the sensitive semantic parameters, thus limiting the privacy data matching process to the data range related to the current control action. This avoids indiscriminate searching across the entire privacy data set, reduces access to irrelevant privacy data domains, and improves local privacy data matching efficiency. Simultaneously, by encrypting and storing the privacy data set in a secure vehicle-side storage area and managing it according to privacy data domains, the risk of privacy data exposure during the matching process is reduced.

[0094] Optionally, in some embodiments, after the vehicle-side computing device obtains the privacy data object, it does not directly write the plaintext privacy content in the privacy data object into the vehicle control command. Instead, it generates a local execution identifier on the vehicle side that can replace the plaintext privacy content. This local execution identifier can be used to enable the vehicle-side execution unit to locate the vehicle execution parameters actually needed for the current control action without receiving sensitive plaintext information. Step S3, the step of generating the local execution identifier of the privacy data object, includes:

[0095] Step S303: In the vehicle-side secure storage area, determine the vehicle execution parameters and corresponding execution parameter types that match the control action from the privacy data object.

[0096] In some embodiments, the privacy data object may include one or more data fields related to user privacy, and the data fields actually used for different control actions may be different. Therefore, within the vehicle-side secure storage area, the vehicle execution parameters matching the current control action are determined from the privacy data object, and the execution parameter type corresponding to the vehicle execution parameters is determined. Here, the vehicle execution parameters refer to the parameters actually called by the vehicle-side execution unit when performing the corresponding vehicle control operation, and the execution parameter type is used to indicate the calling category of the vehicle execution parameters.

[0097] For example, when the control action is to initiate navigation, and the privacy data object is a frequently used location object or an address object, the vehicle execution parameters can be destination coordinates, address index, POI identifier, or navigation destination identifier, and the corresponding execution parameter type can be navigation destination type. When the control action is to initiate communication or send a message, and the privacy data object is a contact object, the vehicle execution parameters can be communication number, contact communication identifier, or message recipient identifier, and the corresponding execution parameter type can be communication object type. The process of determining the above vehicle execution parameters can be completed in the vehicle-side secure storage area to avoid the plaintext exposure of vehicle execution parameters to the vehicle-side control command generation link.

[0098] Step S304: Based on the control action and execution parameter type, determine the target vehicle terminal calling interface from the preset vehicle terminal calling interface set, and generate the interface calling index corresponding to the target vehicle terminal calling interface.

[0099] In some embodiments, the vehicle-side can be pre-configured with a set of vehicle-side API calls. This set of API calls may include navigation service interfaces, communication service interfaces, message service interfaces, in-vehicle device connection interfaces, and in-vehicle application API calls. Different vehicle-side API calls are used to receive different types of vehicle execution parameters and trigger corresponding vehicle-side functions.

[0100] The vehicle-side computing device can determine the target vehicle-side calling interface from the set of vehicle-side calling interfaces based on the current control action and execution parameter type. For example, if the control action is to start navigation and the execution parameter type is navigation destination, the navigation service interface can be determined as the target vehicle-side calling interface; if the control action is to send a message and the execution parameter type is communication object, the message service interface can be determined as the target vehicle-side calling interface; and if the control action is to initiate communication and the execution parameter type is communication number, the communication service interface can be determined as the target vehicle-side calling interface. After determining the target vehicle-side calling interface, an interface calling index corresponding to that target vehicle-side calling interface can be generated. This interface calling index is used to instruct the vehicle-side execution unit to route the local execution request to the corresponding vehicle-side calling interface when subsequent de-identified vehicle control commands are executed, without exposing the specific calling parameters or privacy data content of the target interface in the de-identified vehicle control commands.

[0101] Step S305: Based on the object identifier of the privacy data object, the action identifier of the control action, the current voice control session identifier, and the session random number, generate a virtual execution handle bound to the current voice control session.

[0102] In some embodiments, the vehicle-side computing device can generate a virtual execution handle for the matched privacy data object. This virtual execution handle is neither the plaintext content of the privacy data object nor the vehicle execution parameters themselves, but rather a de-identified index used to temporarily represent the privacy data object or its corresponding vehicle execution parameters in the current voice control session.

[0103] Specifically, when a user wakes up the in-vehicle voice assistant or initiates a voice interaction, the vehicle-side computing device can generate a current voice control session identifier and a session random number for that session. After matching a privacy data object, the vehicle-side computing device can obtain the object identifier of that privacy data object and the action identifier of the current control action. It then combines the object identifier, action identifier, current voice control session identifier, and session random number according to a preset field order to obtain handle generation input data. Subsequently, it can perform hash operations, message authentication code operations, digest operations based on the vehicle-side local key, or random token mapping on the handle generation input data to obtain a virtual execution handle. This virtual execution handle does not directly contain sensitive semantic parameter values, the plaintext content of the privacy data object, or the plaintext of vehicle execution parameters. Furthermore, because its generation process incorporates the current voice control session identifier and session random number, it can be limited to use within the current voice control session. Once the current voice control session ends, the control action is completed, or the virtual execution handle exceeds the preset valid duration, the vehicle-side computing device can delete or invalidate the virtual execution handle and its corresponding local mapping relationship, thereby reducing the risk of the virtual execution handle being reused or misused across sessions.

[0104] Step S306: Establish a local mapping relationship between the virtual execution handle and the vehicle execution parameters, and determine the virtual execution handle and the interface call index as the local execution identifier.

[0105] In some embodiments, after generating a virtual execution handle, the vehicle-side computing device can establish a local mapping relationship between the virtual execution handle and vehicle execution parameters on the vehicle side. This local mapping relationship can be stored in a secure storage area on the vehicle side, a protected session cache, or other local storage area with access control capabilities. This local mapping relationship is used to query the corresponding vehicle execution parameters based on the virtual execution handle when subsequently executing de-identified vehicle control commands, without needing to directly carry the plaintext of the vehicle execution parameters in the de-identified vehicle control commands. The local mapping relationship can include at least the virtual execution handle and the vehicle execution parameters corresponding to it. Optionally, the local mapping relationship can also include at least one of the following: current voice control session identifier, action identifier of the control action, execution parameter type, valid time information, or execution status information, to limit the scope of use of the virtual execution handle. For example, when the control action is to start navigation, the local mapping relationship can be used to record the correspondence between the virtual execution handle and destination coordinates, address index, or navigation destination identifier; when the control action is to send a message or initiate communication, the local mapping relationship can be used to record the correspondence between the virtual execution handle and contact communication identifier, communication number, or message recipient identifier.

[0106] The vehicle-side computing device can use a virtual execution handle and an interface call index to jointly determine the local execution identifier. The virtual execution handle replaces the values ​​of sensitive semantic parameters and the corresponding plaintext vehicle execution parameters, while the interface call index indicates the target vehicle-side interface to be invoked during subsequent execution. In other words, the virtual execution handle primarily addresses the question of "which local privacy data object corresponds to which vehicle execution parameters to use," while the interface call index primarily addresses the question of "which vehicle-side interface to send the virtual execution handle to for execution." Once these two elements constitute the local execution identifier, de-identified vehicle control commands can carry this identifier without requiring sensitive plaintext information such as contact numbers, home addresses, or destination coordinates.

[0107] For example, for initiating navigation, the vehicle-side computing device can establish a local mapping between a virtual execution handle and the destination coordinates or address index, and use the virtual execution handle and the interface call index corresponding to the navigation service interface as the local execution identifier. Subsequently generated desensitized vehicle control commands can carry non-sensitive semantic parameters such as the navigation initiation action, the local execution identifier, and route preferences, without directly carrying the specific address or destination coordinates in plaintext. As another example, for sending a message, the vehicle-side computing device can establish a local mapping between a virtual execution handle and a contact communication identifier, and use the virtual execution handle and the interface call index corresponding to the message service interface as the local execution identifier. This allows desensitized vehicle control commands to complete the corresponding message sending control locally on the vehicle without carrying the contact name or communication number in plaintext.

[0108] In some embodiments, the local mapping relationship can have session-level validity. When the current voice control session ends, the control action is completed, the preset validity period expires, or the user cancels the current voice control task, the vehicle-side computing device can delete or invalidate the virtual execution handle and its corresponding local mapping relationship. This avoids the virtual execution handle from being effectively invoked after it becomes invalid, reducing the risk of the virtual execution handle being reused, repeatedly invoked, or misused across sessions.

[0109] In the solution provided in this embodiment, through steps S303 to S306, the vehicle execution parameters that actually match the control action are first determined in the vehicle-side secure storage area. Then, a session-bound virtual execution handle is generated for the vehicle execution parameters, and a local execution identifier is formed by combining it with the interface call index. This allows subsequent de-identified vehicle control commands to query the corresponding execution parameters locally on the vehicle side without directly carrying plaintext vehicle execution parameters such as contact numbers, destination coordinates, and address indexes. The corresponding execution parameters can also be accurately routed to the target vehicle-side call interface through the virtual execution handle, and the interface call index can be used to accurately route the commands to the target vehicle-side call interface. Thus, while ensuring that vehicle control operations can be executed normally, sensitive semantic parameter values ​​and plaintext vehicle execution parameters are isolated in the vehicle-side secure storage area, reducing the risk of sensitive information being exposed in the control command generation, transmission, and execution chain.

[0110] Optionally, in some embodiments, step S4 specifically includes:

[0111] Step S401: Determine the corresponding vehicle-side execution unit and instruction type based on the control action.

[0112] In some embodiments, the vehicle-side computing device can determine the corresponding vehicle-side execution unit based on the control action. The vehicle-side execution unit can be a functional module, service module, or controller for performing specific vehicle control operations. For example, when the control action is to start navigation, the corresponding vehicle-side execution unit can be a navigation service module; when the control action is to initiate communication or send a message, the corresponding vehicle-side execution unit can be a communication service module or a message service module; when the control action is to adjust the air conditioning temperature, the corresponding vehicle-side execution unit can be an air conditioning controller; and when the control action is to control the opening and closing of the windows, the corresponding vehicle-side execution unit can be a window controller.

[0113] Furthermore, the vehicle-side computing device can determine the corresponding instruction type based on the control action. The instruction type characterizes the control or execution category to which the anonymized vehicle control instruction belongs, such as navigation instruction type, communication instruction type, message sending instruction type, air conditioning control instruction type, window control instruction type, media playback instruction type, etc. By determining the vehicle-side execution unit and instruction type, the subsequently generated anonymized vehicle control instructions can be correctly distributed to the corresponding execution module, and parsed by the execution module according to the corresponding control category.

[0114] Step S402: Encapsulate the control action, instruction type, local execution identifier, and non-sensitive semantic parameters into a desensitized instruction payload.

[0115] In some embodiments, the vehicle-side computing device can encapsulate control actions, instruction types, local execution identifiers, and non-sensitive semantic parameters into a desensitized instruction payload according to a preset instruction encapsulation format. For example, in a navigation control scenario, the desensitized instruction payload may include a navigation initiation action, a navigation instruction type, a local execution identifier, and non-sensitive semantic parameters such as route preferences and obstacle avoidance conditions, but exclude sensitive plaintext information such as home address, company address, and destination coordinates; in a communication control scenario, the desensitized instruction payload may include a communication initiation action, a communication instruction type, and a local execution identifier, but exclude sensitive plaintext information such as contact person name and contact number; in an air conditioning control scenario, the desensitized instruction payload may include an air conditioning adjustment action, an air conditioning control instruction type, and non-sensitive semantic parameters such as target temperature and fan speed mode. Thus, the desensitized instruction payload can retain the control information required for vehicle-side execution while preventing sensitive semantic parameter values ​​from directly entering the instruction payload.

[0116] Step S403: Generate a command verification tag based on the current voice control session identifier, the action identifier of the control action, and the desensitized command payload.

[0117] Specifically, the vehicle-side computing device can combine the current voice control session identifier, the action identifier of the control action, and the de-identified command payload in a preset order to obtain verification input data. It then performs digest operations, hash operations, message authentication code operations, or signature operations based on the vehicle-side local key on this verification input data to generate a command verification tag. This command verification tag is used to verify the consistency between the de-identified command payload and the current voice control session and control action after the vehicle-side execution unit receives the de-identified vehicle control command. By introducing the command verification tag, the risk of the de-identified command payload being tampered with, reused across sessions, or incorrectly bound to other control actions can be reduced.

[0118] Step S404: Encapsulate the desensitized instruction payload and instruction verification tag into a desensitized vehicle control instruction, and send the desensitized vehicle control instruction to the vehicle-side execution unit.

[0119] In some embodiments, the vehicle-side computing device can encapsulate a de-identified instruction payload and an instruction verification tag into a de-identified vehicle control instruction. This de-identified vehicle control instruction may include an instruction header, a de-identified instruction payload, and an instruction verification tag. The instruction header may include information such as instruction type, target vehicle-side execution unit identifier, session identifier, or timestamp; the de-identified instruction payload carries control actions, a local execution identifier, and non-sensitive semantic parameters; the instruction verification tag is used by the vehicle-side execution unit to perform instruction validity or consistency verification. After generating the de-identified vehicle control instruction, the vehicle-side computing device can send the de-identified vehicle control instruction to the vehicle-side execution unit.

[0120] In the solution provided in this embodiment, through steps S401 to S404, the corresponding vehicle-side execution unit and instruction type are first determined based on the control action. Then, the control action, local execution identifier, and non-sensitive semantic parameters are encapsulated into a desensitized instruction payload. An instruction verification tag is generated by combining the current voice control session identifier and the action identifier of the control action, ultimately forming and sending the desensitized vehicle control instruction. Therefore, the desensitized vehicle control instruction can be accurately distributed to the corresponding vehicle-side execution unit and parsed and executed according to the corresponding instruction type even without carrying sensitive semantic parameter values ​​and plaintext vehicle execution parameters. Simultaneously, the binding relationship between the desensitized instruction payload and the current voice control session and control action is verified through the instruction verification tag, improving the accuracy and security of the desensitized vehicle control instruction generation and execution process.

[0121] Optionally, in some embodiments, after sending the desensitized vehicle control command to the vehicle-side execution unit, the command is not executed directly. Instead, the command verification tag in the desensitized vehicle control command is first verified, and the corresponding vehicle execution parameters are obtained based on the local execution identifier after the verification passes. This ensures that the desensitized vehicle control command can still be executed correctly without carrying sensitive plaintext information, and reduces the risk of the desensitized command being tampered with, reused across sessions, or misused across actions. The method further includes:

[0122] Step A1: The vehicle-side execution unit parses the desensitized vehicle control command to obtain the desensitized command payload and command verification tag, and verifies the command verification tag based on the current voice control session identifier, the action identifier of the control action, and the desensitized command payload.

[0123] In some embodiments, after receiving a de-identified vehicle control command, the vehicle-side execution unit can parse the command according to a preset command encapsulation format to obtain a de-identified command payload and a command verification tag. The vehicle-side execution unit can obtain the current voice control session identifier, the action identifier of the control action, and the parsed de-identified command payload, and generate a verification tag to be compared according to the same rules used when generating the command verification tag. For example, the vehicle-side execution unit can combine the current voice control session identifier, the action identifier of the control action, and the de-identified command payload in a preset field order, and generate a verification tag to be compared based on a preset digest algorithm, hash algorithm, message authentication code algorithm, or local key verification algorithm. Subsequently, the vehicle-side execution unit can compare the verification tag to be compared with the command verification tag carried in the de-identified vehicle control command; if they match, the command verification tag verification is successful; if they do not match, the command verification tag verification is unsuccessful. Through this verification process, it can be confirmed that the de-identified command payload has not been tampered with during transmission and that the de-identified command payload still belongs to the current voice control session and the current control action.

[0124] Step A2: If the instruction verification tag passes the verification, the vehicle-side execution unit extracts the interface call index and virtual execution handle from the de-identified instruction payload.

[0125] In some embodiments, after the instruction verification tag passes verification, the vehicle-side execution unit can further parse the de-identified instruction payload and extract the local execution identifier from it. Since the local execution identifier may include a virtual execution handle and an interface call index, the vehicle-side execution unit can extract the interface call index and the virtual execution handle respectively. The interface call index indicates the target vehicle-side call interface to be called subsequently, and the virtual execution handle is used to query the vehicle execution parameters corresponding to the privacy data object locally on the vehicle side. For example, in a navigation control scenario, the interface call index may point to a navigation service interface, and the virtual execution handle may be used to query the corresponding destination coordinates or address index; in a communication control scenario, the interface call index may point to a communication service interface or a message service interface, and the virtual execution handle may be used to query the corresponding contact communication identifier or communication number.

[0126] Step A3: The vehicle-side execution unit determines the vehicle-side calling interface based on the interface calling index and sends the virtual execution handle to the vehicle-side calling interface.

[0127] In some embodiments, the vehicle-side execution unit can query the set of vehicle-side call interfaces based on the interface call index to determine the target vehicle-side call interface corresponding to the interface call index. Different vehicle-side call interfaces correspond to different types of vehicle control operations. After determining the target vehicle-side call interface, the vehicle-side execution unit can send a virtual execution handle to the target vehicle-side call interface. Optionally, the vehicle-side execution unit can also send the action identifier of the control action, the current voice control session identifier, the instruction type, or non-sensitive semantic parameters to the target vehicle-side call interface so that the target vehicle-side call interface can verify the validity, applicable actions, and call scope of the virtual execution handle.

[0128] Step A4: The target vehicle calls the interface to access the vehicle's secure storage area based on the interface permission verification, and queries the local mapping relationship according to the virtual execution handle to obtain the corresponding vehicle execution parameters.

[0129] In some embodiments, after receiving the virtual execution handle, the target vehicle-side API may first perform an API permission check. This permission check can be used to determine whether the target vehicle-side API has permission to access the corresponding local mapping relationships in the vehicle-side secure storage area, and whether the current control action matches the service scope of the target vehicle-side API. For example, a navigation service API can access local mapping relationships for navigation destination types, and a communication service API can access local mapping relationships for communication object types.

[0130] If the interface permission verification passes, the target vehicle can access the vehicle's secure storage area and query the local mapping relationship between the virtual execution handle and vehicle execution parameters to obtain the vehicle execution parameters corresponding to that virtual execution handle. Vehicle execution parameters can include destination coordinates, address index, navigation destination identifier, contact communication identifier, communication number, message recipient identifier, device connection identifier, etc. Optionally, when querying the local mapping relationship, it can also verify whether the virtual execution handle belongs to the current voice control session, whether it matches the current control action, whether it is within its valid duration, and whether it has expired. If the above verifications fail, the return of vehicle execution parameters can be refused.

[0131] Step A5: The vehicle-side execution unit executes the vehicle control operation corresponding to the control action based on the vehicle execution parameters.

[0132] In some embodiments, after the target vehicle-side calling interface retrieves the vehicle execution parameters based on the virtual execution handle, the vehicle-side execution unit can execute the corresponding vehicle control operation based on the vehicle execution parameters and the non-sensitive semantic parameters in the desensitized instruction payload. For example, when the control action is to start navigation, the vehicle-side execution unit can start navigation based on the retrieved destination coordinates or address index, combined with non-sensitive semantic parameters such as route preferences; when the control action is to send a message, the vehicle-side execution unit can execute the message sending operation based on the retrieved contact communication identifier or message recipient identifier, combined with non-sensitive semantic parameters such as message content and sending confirmation information; when the control action is to initiate communication, the vehicle-side execution unit can execute the dialing operation based on the retrieved communication number or contact communication identifier. Thus, the vehicle-side execution unit can complete the corresponding vehicle control operation through the virtual execution handle and local mapping relationship without directly receiving sensitive semantic parameter values ​​and plaintext vehicle execution parameters.

[0133] Step A6: If the instruction verification tag fails, refuse to execute the de-identified vehicle control instruction.

[0134] In some embodiments, if the vehicle-side execution unit determines that the instruction verification tag verification has failed, it indicates that the de-identified instruction payload may not match the current voice control session or the current control action, or that there is a risk of tampering, replaying, or incorrect binding during transmission. In this case, the vehicle-side execution unit may refuse to execute the de-identified vehicle control instruction and stop the subsequent processing flow of extracting the interface call index, sending the virtual execution handle, and querying the local mapping relationship.

[0135] Optionally, the vehicle-side execution unit can also generate a verification failure message, record an exception log, or return the execution failure result to the vehicle-side voice interaction module. For example, it can record the verification failure time, command type, control action identifier, and failure reason, but not record sensitive semantic parameter values ​​or plaintext vehicle execution parameters. This improves the security of command execution while avoiding the risk of introducing new sensitive information exposure during exception handling.

[0136] In the solution provided in this embodiment, through steps A1 to A6, after receiving the de-identified vehicle control command, the vehicle-side execution unit first parses and verifies the de-identified command payload and command verification tag. After the verification passes, it extracts the interface call index and virtual execution handle, determines the target vehicle-side call interface through the interface call index, and queries the corresponding vehicle execution parameters in the vehicle-side secure storage area through the virtual execution handle, thereby executing the corresponding vehicle control operation. Thus, the de-identified vehicle control command can still be accurately parsed, routed, and executed by the vehicle-side execution unit without directly carrying sensitive semantic parameter values ​​and plaintext vehicle execution parameters. Through command verification tags, interface permission verification, and local mapping relationship queries, the risks of de-identified commands being tampered with, reused across sessions, misused across actions, or unauthorized access to privacy data can be reduced. Furthermore, abnormal commands are promptly rejected when verification fails, improving the security, accuracy, and privacy protection capabilities of the in-vehicle voice control execution link.

[0137] Optionally, in some embodiments, the vehicle-side computing device can support multi-round voice control sessions. Within the same voice control session, subsequent voice control commands from the user may omit privacy objects mentioned in previous rounds. For example, the user might first issue a voice control command to "navigate to a preset frequently used location," and then issue a voice control command to "change to highway priority" or "start navigation." In this case, although subsequent voice control commands do not directly contain sensitive semantic parameter values ​​of the frequently used location type again, they still need to use the privacy data objects matched in previous rounds. To maintain de-identification processing throughout multi-round voice control, the vehicle-side computing device can maintain a de-identification context record. The method further includes:

[0138] Step B1: Maintain a desensitized context record in the current voice control session; wherein, when a user voice control command in any round generates a virtual execution handle and an interface call index, the virtual execution handle, interface call index, and handle inheritance conditions determined according to the control action in that round are written to or updated to the desensitized context record, and the desensitized context record does not include sensitive semantic parameter values ​​and vehicle execution parameters.

[0139] In some embodiments, the current voice control session can be a continuous voice interaction process that begins when the user wakes up the in-vehicle voice assistant and ends when the voice interaction ends, the session times out, or the user actively exits. The vehicle-side computing device can establish a de-identified context record for the current voice control session. This de-identified context record is used to store de-identified identification information within the current session that can be inherited and used in subsequent rounds.

[0140] Once the user voice control command in any round has completed the identification of sensitive semantic parameters, matching of privacy data objects, and generation of local execution identifiers, the virtual execution handle and interface call index generated in that round can be written to or updated to the desensitization context record. Simultaneously, the handle inheritance conditions are determined based on the control action corresponding to that round, and these conditions are also written to the desensitization context record. Handle inheritance conditions can be used to limit the scope of the virtual execution handle and interface call index that can be inherited and used in subsequent rounds, such as the inheritable subsequent control action types, inheritable semantic context types, validity period, number of valid rounds, and whether user confirmation is required.

[0141] For example, if the control action in the previous round was to start navigation, the handle inheritance condition can indicate that the virtual execution handle generated in this round can be inherited by subsequent control actions related to the same navigation object, such as navigation confirmation, route preference adjustment, navigation start, and navigation cancellation. If the control action in the previous round was to send a message, the handle inheritance condition can indicate that the virtual execution handle generated in this round can be inherited by subsequent control actions related to the same communication object, such as message content supplementation, message confirmation, and message cancellation.

[0142] It should be noted that the anonymized context record stores anonymized context information such as virtual execution handles, interface call indexes, and handle inheritance conditions, but does not store sensitive semantic parameter values ​​or vehicle execution parameters. For example, the anonymized context record can store a virtual execution handle representing a frequently used location object, but not the plaintext address or destination coordinates of that frequently used location; it can store a virtual execution handle representing a contact object, but not the contact's name, contact number, or communication number in plaintext. This avoids the direct accumulation of sensitive plaintext information within multi-turn voice context.

[0143] Step B2: When receiving subsequent rounds of user voice control commands in the current voice control session, and the subsequent rounds of user voice control commands need to use the privacy data objects of the previous rounds, determine the virtual execution handle and interface call index to be inherited from the desensitized context record based on the handle inheritance condition.

[0144] In some embodiments, after receiving subsequent user voice control commands in the current voice control session, the vehicle-side computing device can perform local semantic parsing on the subsequent user voice control commands to obtain the subsequent user intent, subsequent control actions, and subsequent semantic parameters. If the subsequent user voice control commands do not provide new sensitive semantic parameter values, but their semantic content indicates that the privacy data objects from the previous rounds need to be used, then it can be determined that the subsequent user voice control commands need to use the privacy data objects from the previous rounds.

[0145] For example, in the previous round, the user issued a voice control command to "navigate to a preset frequently used location," and the vehicle's computing device generated a virtual execution handle and interface call index corresponding to that frequently used location object. In the next round, the user issued a voice control command to "change to avoid congestion" or "start navigation." This next round's voice control command did not again contain the name or address information of the frequently used location, but its control action was still related to the navigation object of the previous round. Therefore, it can be determined that this next round needs to reuse the privacy data object from the previous round.

[0146] After determining that privacy data objects from previous rounds need to be reused, inheritable virtual execution handles and interface call indices can be determined based on subsequent control actions, subsequent semantic context, and handle inheritance conditions in the de-identification context record. If multiple candidate virtual execution handles exist in the de-identification context record, the virtual execution handle and interface call index that best matches the current subsequent round can be selected as the virtual execution handle and interface call index to be inherited, based on round distance, control action matching degree, effective duration, or user confirmation result. If the handle inheritance conditions are not met, inheritance can be skipped, and sensitive semantic parameter identification, privacy data object matching, or user confirmation can be re-performed.

[0147] Step B3: Determine the virtual execution handle and interface call index to be inherited as the local execution identifier for subsequent rounds of user voice control commands, and generate desensitized vehicle control commands corresponding to subsequent rounds of user voice control commands based on the subsequent control actions, local execution identifiers and non-sensitive semantic parameters.

[0148] In some embodiments, after determining the virtual execution handle and interface call index to be inherited from the de-identification context record, the virtual execution handle and interface call index to be inherited can be used as the local execution identifier for subsequent rounds of user voice control commands. Since this local execution identifier originates from the result of the de-identification process already completed in the previous round, subsequent rounds do not need to re-carry sensitive semantic parameter values ​​in the vehicle control commands, nor do they need to write the plaintext content of privacy data objects into subsequent de-identified vehicle control commands.

[0149] Furthermore, desensitized vehicle control commands for subsequent rounds can be generated based on the subsequent control actions corresponding to the user's voice control commands in subsequent rounds, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing results of subsequent rounds. For example, in the aforementioned navigation scenario, the desensitized vehicle control commands for subsequent rounds may include route preference adjustment actions, inherited local execution identifiers, and non-sensitive semantic parameters such as "avoid congestion" and "highway priority," but will not include the specific address or destination coordinates in plaintext.

[0150] In the solution provided in this embodiment, through steps B1 to B3, a desensitized context record that does not contain sensitive semantic parameter values ​​and vehicle execution parameters is maintained in the current voice control session. When subsequent rounds need to reuse the privacy data object of the previous round, the virtual execution handle and interface call index generated in the previous round are inherited based on the handle inheritance condition, thereby generating the desensitized vehicle control command corresponding to the subsequent round. Therefore, users do not need to repeatedly input sensitive information such as contacts, addresses, and frequently used locations, and subsequent control operations can be completed continuously, ensuring the consistency of the control object in multi-round voice interaction scenarios. Moreover, since only the desensitized virtual execution handle and interface call index are recorded in the multi-round context, and not the plaintext of sensitive semantic parameter values ​​and vehicle execution parameters, the risk of sensitive information accumulating and being exposed in the multi-round voice context can be reduced, improving the continuity and privacy security of the multi-round vehicle voice control process.

[0151] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0152] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0153] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a local de-identification generation method for in-vehicle voice control instructions as provided in any one or more of the above embodiments. Figure 2An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0154] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.

[0155] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0156] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0157] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a local de-identification generation method for vehicle voice control instructions provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not be assembled into the device. The computer-readable medium carries one or more computer-readable instructions.

[0158] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0159] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0161] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0162] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0163] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0164] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0165] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0166] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used only to distinguish descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0167] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for local de-identification generation of vehicle voice control commands, characterized in that, include: The system acquires user voice control commands and performs local semantic parsing on the user voice control commands to obtain semantic parsing results. The semantic parsing results include user intent and semantic parameters corresponding to the user intent. The semantic parameters include semantic parameter type and semantic parameter value. The corresponding control action is determined based on the user intent, and the sensitive semantic parameters associated with the control action are determined from the semantic parsing results based on the semantic parameter type and the preset set of sensitive types. The sensitive semantic parameters include sensitive semantic parameter type and sensitive semantic parameter value. Based on the sensitive semantic parameters, a privacy data object corresponding to the control action is matched from the local privacy data set on the vehicle, and a local execution identifier of the privacy data object is generated; Based on the control action, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing result, a desensitized vehicle control command is generated for sending to the vehicle-side execution unit; wherein, the local execution identifier is used to replace the sensitive semantic parameter value in the semantic parsing result.

2. The method for local desensitization generation of vehicle voice control commands according to claim 1, characterized in that, The step of determining the sensitive semantic parameters associated with the control action from the semantic parsing results based on the semantic parameter type and a preset set of sensitive types includes: The semantic parameter types of each semantic parameter in the semantic parsing result are compared with a preset set of sensitive types, and the semantic parameters whose semantic parameter types belong to the set of sensitive types are determined as candidate sensitive parameters. Based on the control action, a preset mapping table of control actions and sensitive parameter types is queried to obtain the set of target sensitive parameter types corresponding to the control action; If the semantic parameter type of the candidate sensitive parameter belongs to the target sensitive parameter type set, the candidate sensitive parameter is determined as a sensitive semantic parameter associated with the control action; If the set of target sensitive parameter types is empty or the semantic parameter type of the candidate sensitive parameter does not belong to the set of target sensitive parameter types, the candidate sensitive parameter is determined as a non-sensitive semantic parameter.

3. The method for local de-identification generation of vehicle voice control commands according to claim 1, characterized in that, The privacy data set is encrypted and stored in the vehicle-side secure storage area. The privacy data set includes multiple privacy data fields, and different privacy data fields are used to store different types of privacy data objects. The step of matching the privacy data object corresponding to the control action from the vehicle-side local privacy data set based on the sensitive semantic parameters includes: Based on the control action and the sensitive semantic parameter type, a target privacy data domain is determined from the plurality of privacy data domains; In the target privacy data domain, the privacy data object corresponding to the control action is matched based on the sensitive semantic parameter value.

4. The method for local desensitization generation of vehicle voice control commands according to claim 3, characterized in that, The step of generating the local execution identifier of the privacy data object includes: Within the vehicle-side secure storage area, vehicle execution parameters and corresponding execution parameter types that match the control action are determined from the privacy data object; Based on the control action and the execution parameter type, the target vehicle-side calling interface is determined from the preset set of vehicle-side calling interfaces, and an interface calling index corresponding to the target vehicle-side calling interface is generated; Based on the object identifier of the privacy data object, the action identifier of the control action, the current voice control session identifier, and the session random number, a virtual execution handle bound to the current voice control session is generated; Establish a local mapping relationship between the virtual execution handle and the vehicle execution parameters, and determine the virtual execution handle and the interface call index as the local execution identifier.

5. The method for local desensitization generation of vehicle voice control commands according to claim 4, characterized in that, The step of generating desensitized vehicle control commands for sending to the vehicle-side execution unit based on the control action, the local execution identifier, and the non-sensitive semantic parameters in the semantic parsing result includes: The corresponding vehicle-side execution unit and instruction type are determined based on the control action; The control action, the instruction type, the local execution identifier, and the non-sensitive semantic parameters are encapsulated into a desensitized instruction payload; Based on the current voice control session identifier, the action identifier of the control action, and the desensitized instruction payload, an instruction verification tag is generated; The desensitized instruction payload and the instruction verification tag are encapsulated into the desensitized vehicle control instruction, and the desensitized vehicle control instruction is sent to the vehicle-side execution unit.

6. The method for local de-identification generation of vehicle voice control commands according to claim 5, characterized in that, After sending the desensitized vehicle control command to the vehicle-side execution unit, the method further includes: The vehicle-side execution unit parses the desensitized vehicle control command to obtain the desensitized command payload and command verification tag, and verifies the command verification tag based on the current voice control session identifier, the action identifier of the control action, and the desensitized command payload; If the instruction verification tag passes the verification, the vehicle-side execution unit extracts the interface call index and virtual execution handle from the de-identified instruction payload; The vehicle-side execution unit determines the vehicle-side calling interface based on the interface calling index, and sends the virtual execution handle to the vehicle-side calling interface; The target vehicle-side calling interface accesses the vehicle-side secure storage area based on interface permission verification, and queries the local mapping relationship according to the virtual execution handle to obtain the corresponding vehicle execution parameters; The vehicle-side execution unit performs vehicle control operations corresponding to the control actions based on the vehicle execution parameters. If the instruction verification tag fails to pass verification, the desensitized vehicle control instruction will be refused to be executed.

7. The method for local desensitization generation of vehicle voice control commands according to claim 4, characterized in that, The method further includes: Maintain a desensitized context record in the current voice control session; wherein, when the user voice control command in any round generates the virtual execution handle and the interface call index, the virtual execution handle, the interface call index and the handle inheritance conditions determined according to the control action corresponding to the round are written to or updated to the desensitized context record, and the desensitized context record does not include the sensitive semantic parameter value and the vehicle execution parameter; When a user voice control instruction for a subsequent round is received in the current voice control session, and the user voice control instruction for the subsequent round needs to use the privacy data object of the previous round, the virtual execution handle and interface call index to be inherited are determined from the desensitized context record based on the handle inheritance condition. The virtual execution handle to be inherited and the interface call index are determined as the local execution identifier of the user voice control command in the subsequent rounds. Based on the subsequent control action, local execution identifier and non-sensitive semantic parameters corresponding to the user voice control command in the subsequent rounds, the desensitized vehicle control command corresponding to the user voice control command in the subsequent rounds is generated.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the local de-identification generation method for in-vehicle voice control instructions as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the local desensitization generation method for vehicle voice control instructions as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the local desensitization generation method for vehicle voice control instructions as described in any one of claims 1-7.

Images