In-vehicle permission hierarchical control method, device, equipment and storage medium

Abstract

This application discloses a method, device, equipment, and storage medium for hierarchical control of in-vehicle access permissions, relating to the field of vehicle networking technology. The method includes: responding to a user-triggered authentication request, acquiring the user's voiceprint information, determining the user's location based on the voiceprint information, and performing facial recognition on the user to obtain a recognition result; and granting the user operational permissions to in-vehicle facilities when the voiceprint information, the user's location, and the recognition result meet preset conditions. This application can grant differentiated operational permissions to different user seating positions to execute in-vehicle functions, thereby meeting the personalized control needs of different passengers while minimizing unauthorized operations by non-drivers that could interfere with driving safety.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to in-vehicle access control methods, devices, equipment and storage media. Background Technology

[0002] With the development of automotive intelligence, voice interaction has become one of the main ways for drivers to control vehicle functions. However, current technologies treat voice commands from any location within the vehicle as equally valid, failing to meet the personalized control needs of passengers in different seats and making it difficult to adapt to complex scenarios with multiple passengers. Therefore, how to allocate permissions based on seating position to execute commands has become an urgent problem to be solved. Summary of the Invention

[0003] The main objective of this application is to provide a method, device, equipment, and storage medium for hierarchical control of in-vehicle permissions, aiming to solve the technical problem of how to allocate permissions according to seating position to execute instructions.

[0004] To achieve the above objectives, this application proposes an in-vehicle access control method, which includes: In response to a user-triggered authentication request, the system obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain the recognition result; and If the voiceprint information, user location, and recognition results meet the preset conditions, the user is granted permission to operate the in-vehicle facilities.

[0005] This application obtains the user's voiceprint information in response to the user's authentication request to determine the user's location and performs facial recognition to accurately identify the user's location and identity, thereby granting differentiated operation permissions. This satisfies the personalized control needs of different passengers while minimizing unauthorized operations by non-drivers that could interfere with driving safety.

[0006] To achieve the above objectives, the preset conditions may optionally include at least one of the following: The user identity information indicated by the voiceprint information is the registered identity information; the user identity information indicated by the recognition result is the registered identity information; the user identity information indicated by the voiceprint information is consistent with the user identity information indicated by the recognition result; and the user's location is the location where the user has been pre-authorized to operate the in-vehicle facilities.

[0007] This application effectively prevents identity forgery and misuse of permissions by setting multiple preset conditions, including identity registration, consistency of two-factor authentication, and location permission.

[0008] To achieve the above objectives, the user's location may optionally be determined using a liveness detection method.

[0009] This application uses a liveness detection method to determine the user's location, which can accurately identify the seat position of a live person in the vehicle, and is not limited by environmental noise, fake recordings, or the user not speaking.

[0010] To achieve the above objectives, optionally, in response to a user triggering an authentication request, the system obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain a recognition result, followed by: If the voiceprint information, location, or recognition result does not meet the preset conditions, the system will enter a waiting mode after a preset waiting time. If the user triggers an authentication request again within the waiting time, the system returns a response to the user's authentication request, obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain the recognition result; and... If the voiceprint information, location, and recognition results still do not meet the preset conditions, the execution of hierarchical access control will be terminated.

[0011] When the permission verification fails on the first attempt, this application will enter a waiting mode for a preset duration, allowing users to re-trigger the authentication request for a second attempt. This effectively avoids permission misjudgments caused by non-malicious factors such as single identification errors or temporary environmental interference, and enhances the system's fault tolerance.

[0012] To achieve the above objectives, the in-vehicle access control method may optionally further include: Obtain scene mode configuration information for in-vehicle facilities; Determine the permitted functions of in-vehicle facilities in the current scenario mode based on the scenario mode configuration information; and If the voiceprint information, user location, and recognition results meet preset conditions, the user's permission to operate in-vehicle facilities also includes: If the voiceprint information, user location, identification, and permission information results meet the preset conditions, the user is granted permission to operate the in-vehicle facilities.

[0013] This application improves the adaptability and intelligence of the in-vehicle system in multiple scenarios by identifying the current scene of the vehicle and determining the permitted functional scope of each seat in the corresponding scene, thus ensuring driving safety and meeting the functional requirements of different usage scenarios.

[0014] To achieve the above objectives, optionally, the step of determining the permitted function information of in-vehicle facilities in the current scenario mode based on the scenario mode configuration information includes: When the scenario mode configuration information is set to driving mode, the permitted functions are: the driver is permitted to have power chassis operation functions, air conditioning functions, and entertainment functions, and the passenger is permitted to have air conditioning functions and entertainment functions. When the scenario mode configuration information is set to maintenance mode, the permitted functions are: the driver and passenger are permitted to operate the powertrain chassis, use the air conditioning, and access entertainment functions; and When the scene mode configuration information is set to guest mode, the permitted function information is that the driver and passenger are permitted to have entertainment functions.

[0015] This application grants different permissions for specific scenarios such as driving mode, maintenance mode, and guest mode, achieving precise adaptation of permission allocation to scenario requirements, ensuring the absolute security of core functions in specific scenarios as much as possible, providing operational convenience for different roles, and improving intelligent permission control capabilities.

[0016] To achieve the above objectives, the in-vehicle access control method may optionally further include: In response to a temporary authorization command issued by the primary user, obtain the authorized functions, authorized objects, and effective time of the authorized functions in the temporary authorization command; If the identity information in the control request instruction is the same as that of the authorized object, the user is granted permission to operate on the authorized functions according to the control request instruction; and If the temporary authorization period expires, terminate the user's access to the authorized functions.

[0017] This application enables time-limited authorization of specific users and functions by responding to the temporary authorization command of the driver. While ensuring the driver's absolute control over the core functions of the vehicle as much as possible, it allows the driver to temporarily grant some operating permissions to the front passenger or rear passenger.

[0018] Furthermore, to achieve the above objectives, this application also proposes an in-vehicle access control device, which includes: The acquisition module is used to respond to the user's authentication request, acquire the user's voiceprint information, determine the user's location based on the voiceprint information, and perform facial recognition on the user to obtain the recognition result. The execution module is used to grant users access to in-vehicle facilities when the voiceprint information, user location, and recognition results meet preset conditions.

[0019] In addition, to achieve the above objectives, this application also proposes an in-vehicle access control device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the in-vehicle access control method described above.

[0020] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the in-vehicle access control method described above. Attached Figure Description

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

[0022] To more clearly illustrate the technical solutions in some embodiments of this application or in the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0023] Figure 1 This is a first flowchart illustrating some embodiments of the in-vehicle access control method of this application; Figure 2 This is the overall flowchart of the in-vehicle access control method of this application; Figure 3 This is a flowchart illustrating the implementation of the in-vehicle access control method described in this application. Figure 4 A second flowchart is provided for some embodiments of the in-vehicle access control method of this application; Figure 5 A third flowchart provided for some embodiments of the in-vehicle access control method of this application; Figure 6 A fourth flowchart is provided for some embodiments of the in-vehicle access control method of this application; Figure 7 This is a schematic diagram of the module structure of an in-vehicle access control device according to some embodiments of this application; Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the in-vehicle permission hierarchical control method in some embodiments of this application.

[0024] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0025] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] In some embodiments, for ease of description, the vehicle is used as the subject of the description.

[0028] Because the relevant technology treats voice commands from any location in the vehicle as equally valid, it cannot meet the personalized control needs of passengers in different seats and is difficult to adapt to complex scenarios with multiple passengers.

[0029] In order to implement the allocation of permissions based on seating position to execute instructions, this application provides an in-vehicle permission hierarchical control method in some embodiments. This application obtains the user's voiceprint information to determine the user's location in response to the authentication request triggered by the user, and performs facial recognition to accurately identify the user's location and identity of the user who made the voice, thereby granting operation permissions in a differentiated manner. While meeting the personalized control needs of different passengers, this method avoids unauthorized operations by non-drivers that may interfere with driving safety as much as possible.

[0030] Based on this, some embodiments of this application provide a method for hierarchical control of in-vehicle access permissions, referring to... Figure 1 , Figure 1 This is a first flowchart illustrating some embodiments of the in-vehicle access control method of this application.

[0031] In some embodiments, the in-vehicle access control method includes steps S10 to S20: Step S10: In response to the user triggering an authentication request, obtain the user's voiceprint information, determine the user's location based on the voiceprint information, and perform facial recognition on the user to obtain the recognition result. It is understandable that users have a need to control vehicle functions, but the system cannot distinguish the user's intent or adapt to the personalized control permissions of different passengers. Therefore, responding to the authentication request triggered by the user, which is the initiation signal for obtaining a certain operation permission, can be issued through voice, gesture, or other interactive methods. By responding to the authentication request, the system can accurately capture the user's authentication intent, avoid the system passively waiting as much as possible, and realize an interaction mode driven by user active requests.

[0032] In some examples, voiceprint information of the user's voice is obtained. That is, after receiving an authentication request, voice features can be extracted. This voiceprint information can include timbre, pitch, sound wave characteristics, and spatial location information of the sound source received by the microphone array, facilitating voiceprint recognition and sound source localization to determine the user's location. The user's location is their specific seat, such as driver's seat, front passenger seat, rear left, rear right, etc. Simultaneously, facial recognition is performed on the user to obtain the recognition result. All user-related data involved in this application, such as capturing the user's facial image, is obtained after obtaining the user's permission or consent. It is stated that when this application is applied to specific products or technologies, user permission is required to acquire and process relevant data, and the processing of relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions. For example, facial recognition can capture a user's facial image through an in-vehicle camera and extract facial features (such as contours, facial proportions, textures, etc.), compare them with a pre-registered user facial feature database to confirm whether the user initiating the authentication request is a registered legitimate user, and associate it with the user's preset operation permission range. The recognition result is the conclusion obtained after facial recognition, which facilitates the allocation of differentiated permissions.

[0033] In some examples, step S10 may include step A11: Step A11: The user's location is determined using a liveness detection method.

[0034] Understandably, in the in-vehicle environment, common sound source localization methods cannot determine whether the sound comes from a real, living user. For example, an attacker might use pre-recorded voice, synthesized audio, or sound played through a speaker to impersonate a legitimate user. If only this traditional localization result is relied upon, the system will mistakenly take the location of the fake sound source as the location of the real user, thus granting them access. Therefore, a liveness detection method can be used. By utilizing the radar bio-echo characteristics of UWB, physiological features such as human breathing and micro-movements can be detected to achieve passive liveness detection without a key or other electronic device. This can accurately locate a living person in the vehicle who is not carrying electronic devices, providing comprehensive coverage of the driver's seat, front passenger seat, rear left seat, and rear right seat area. This effectively prevents non-liveness attacks such as recording playback and voice synthesis, thus improving the security of access authorization.

[0035] Step S20: If the voiceprint information, the user's location, and the recognition result meet the preset conditions, grant the user permission to operate the in-vehicle facilities.

[0036] Understandably, in multi-user scenarios within a vehicle, users in different seats typically have differentiated operating permissions. These operating permissions refer to the actual control over vehicle functions. For example, the driver can control driving-related functions, while rear-seat passengers can only control the entertainment system. Relying solely on a single authentication factor could lead to incorrectly granted permissions, such as an unregistered user impersonating another user through voice commands, or a registered user being granted inappropriate permissions in the wrong seat. Therefore, if at least two of the following conditions are met—voiceprint information, user location, and recognition results—users are granted operating permissions for in-vehicle facilities. This enables authorization control that meets the differentiated needs of multiple users in a complex in-vehicle environment.

[0037] In some examples, step S20 may include step B11: Step B11: The user identity information indicated by the voiceprint information is the registered identity information; the user identity information indicated by the recognition result is the registered identity information; the user identity information indicated by the voiceprint information is consistent with the user identity information indicated by the recognition result; and the user's location is the location where the user has been pre-authorized to operate the in-vehicle facilities.

[0038] In some examples, the system can employ triple-parallel redundant verification logic for hierarchical permission recognition. For instance, by capturing the user's voice commands through a full-vehicle microphone array, it simultaneously completes voiceprint feature identity verification and preliminary location of the sound direction, while filtering out invalid commands that interfere with recording forgery, background noise, and other interference. Through the ultra-wideband (UWB) sensing network deployed in the vehicle, it can accurately detect the seat position of a living person in the vehicle, and confirm whether the user has registered a personal account and the corresponding preset function operation permission scope through face recognition (Face ID).

[0039] Ultra-wideband (UWB) typically employs a one-to-four or one-to-three configuration, with the central control unit controlling the UWB module and UWB anchor points deployed at the A-pillar, B-pillar, left rear, and right rear. The verification process utilizes a dual-mode complementary positioning system, combining active and passive methods, covering all usage scenarios. In active mode, the system uses the user's UWB digital key or the UWB chip built into their mobile phone to establish a connection and location. A Time-of-Flight (ToF) and Angle of Arrival (AoA) fusion algorithm is used to calculate the user's precise location, with a positioning response time of less than 50 milliseconds. In passive mode, the system leverages the radar bio-echo characteristics of UWB to detect physiological features such as breathing and subtle movements, enabling passive liveness detection even without a key or electronic device. This allows for accurate location of silent individuals without electronic devices inside the vehicle, providing comprehensive coverage of the driver's seat, front passenger seat, and the left and right rear seats. Therefore, UWB can achieve seat-level positioning within a vehicle at a 10-centimeter level using a ToF algorithm based on nanosecond-level ultra-wideband pulse signals, with a sampling frequency of 10 Hz. This is completely unaffected by in-vehicle air conditioning noise, music playback, road bumps, or cabin echo reflections. Its positioning accuracy is also far superior to the 30-centimeter positioning detection of microphone arrays. Microphone arrays can only locate the direction of the sound source; they cannot distinguish between real users and recorded voices, nor can they identify users who are not speaking. In contrast, UWB can achieve all-time liveness detection, complementing voiceprint and facial recognition capabilities, and physically preventing security risks such as unauthorized access and voice hijacking.

[0040] In some examples, voiceprint information, user location, and recognition results can be used for redundant judgments. For example, if the voiceprint information, user location, and recognition results all pass, the command can be executed directly. The permission level is divided according to the location where the command was issued, and all functions under that permission can be controlled. If there is a discrepancy of less than or equal to one of the three checks, a 300-millisecond wait window is triggered to wait for the user to repeat the command and trigger a second check. If the command is received again within 300 milliseconds, the judgment is re-evaluated. If the discrepancy is still not met, the relevant prompt that the command cannot be executed is returned immediately, and the abnormal check log is recorded for security traceability. If a hardware failure occurs in one of the checks, it is automatically downgraded to the remaining two checks. As long as the results of the two checks are completely consistent, the command can still be executed, and a system fault alarm is reported, which does not affect normal use.

[0041] In some embodiments, an in-vehicle permission hierarchical control method is proposed. In response to a user-triggered authentication request, the method acquires the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain the recognition result. If the voiceprint information, the user's location, and the recognition result meet preset conditions, the user is granted permission to operate in-vehicle facilities. This solves the technical problem of how to allocate permissions based on seating position to execute instructions. Compared to existing technologies, this application, by acquiring the user's voiceprint information to determine the user's location in response to a user-triggered authentication request and performing facial recognition, accurately identifies the user's location and identity based on the voice emitted, thereby granting differentiated operating permissions. This satisfies the personalized control needs of different passengers while minimizing unauthorized operations by non-drivers that could interfere with driving safety.

[0042] like Figure 2 As shown, Figure 2 The flowchart of the in-vehicle permission hierarchical control method in this application is as follows: It can capture voice commands through a microphone, determine the identity and location of the person issuing the command, and accurately determine whether the command comes from the driver, passenger, or rear seat. Based on different scenario triggering conditions (such as maintenance mode, visitor mode, etc.), the driver-triggered command is assigned the highest permission level L0, the passenger-triggered command is assigned the intermediate permission level L1, and the rear seat-triggered command is assigned the lowest permission level L2. In this way, while ensuring that the identity and location are uniquely bound, differentiated operation permissions are dynamically assigned to different seat roles to meet the personalized control needs of multiple users and ensure driving safety and scenario adaptability as much as possible.

[0043] like Figure 3 As shown, Figure 3 This is a flowchart illustrating the implementation of the in-vehicle access control method in this application. It involves performing voiceprint verification and initial location of the voice using a microphone array. The system checks if the user has an ID account. If no ID account is available, UWB liveness detection is performed directly. If an ID account is available, UWB liveness detection is performed for redundancy checks. If a single verification fails, a double verification is performed using either voice and ID or UWB and ID. After the redundancy check passes, the vehicle space is divided into four areas: front left, front right, rear left, and rear right. Functional decisions are made based on the preset access levels for each area on the large screen. Further, it determines whether to enable scene modes (such as maintenance mode or visitor mode). If a scene mode exists, its access level is higher than the area-specific access level; otherwise, relevant functions are enabled according to the area permissions set on the large screen. This ensures accurate access control based on seat identity, flexibly adapts to different usage scenarios, and minimizes unauthorized operations by non-drivers, thus improving driving safety.

[0044] In some embodiments, refer to Figure 4 , Figure 4The second flowchart provided for some embodiments of the in-vehicle access control method of this application further includes steps S30-S50: Step S30: If the voiceprint information, location, or recognition result does not meet the preset conditions, enter the waiting mode according to the preset waiting time. It is understandable that if the voiceprint information, location, and recognition results do not meet the preset conditions, it does not mean that all user operations will be rejected. Considering the actual vehicle use scenario, permission verification failure may be caused by non-malicious factors such as temporary environmental interference. Therefore, user operations cannot be directly and completely blocked.

[0045] In some examples, if the voiceprint information, location, or recognition result does not meet the preset conditions, a waiting window of a preset duration will be entered. Within this window, the user can still proactively initiate a permission reassignment request by issuing a clear target control request command. This target control request command is a security command with a clear target seat identifier issued by the user to actively request specific seat permissions after verification failure. It can be a voice command or a touch interaction command, such as saying "I am the car owner, I want to control the driver's seat" or "Please authorize the passenger seat," or clicking the "Manual Authorization" button on the in-vehicle central control screen and entering a preset security password. This allows the user to re-trigger the permission reassignment process. The preset duration refers to the waiting time threshold set by the system. The time interval can be 30 to 60 seconds. After receiving a target control request command, the system will parse the user's target seat location and identity, and re-verify. For example, it will match the voiceprint with the pre-recorded registered voiceprint database, or verify whether the user's entered security password is correct. If the verification is successful, it will query the preset permission level (L0 / L1 / L2) corresponding to the target seat location declared by the user, generate a new permission verification result, and directly grant it to the current user. However, if the downgrade verification also fails, or if the user does not issue any valid target control request command within the preset time, it will be judged as a final failure, completely rejecting all control requests, and generating a security exception log for uploading. This ensures security while minimizing the risk of system lock-up due to a single verification failure.

[0046] Step S40: If the user triggers the authentication request again within the waiting time, return the response to the user triggering the authentication request, obtain the user's voiceprint information, determine the user's location based on the voiceprint information, and perform facial recognition on the user to obtain the recognition result. In some examples, if the user triggers the authentication request again during the waiting period, the system will return to the steps that triggered the authentication request, re-acquire voiceprint information, determine location, and perform facial recognition.

[0047] In some examples, the waiting time is used to avoid invalid retries caused by network latency or a user briefly leaving their seat. For instance, if a user's facial recognition fails due to insufficient lighting when they first trigger authentication, but voiceprint localization is successful, the system enters a waiting period. If the user adjusts their posture and triggers the request again during the waiting period, the system will re-execute the entire authentication process, allowing the user to complete facial recognition using the new environmental conditions (such as better lighting). If the user temporarily changes seats (such as moving from the front passenger seat to the back seat) and triggers authentication again during the waiting period, the system can relocate the new seat and match the new voiceprint and facial information to ensure that permissions accurately correspond to the current seat. This prevents permanent locking of operation permissions due to a single failure as much as possible and avoids frequent and meaningless retries interfering with system resources.

[0048] Step S50: If the voiceprint information, location, and recognition result still do not meet the preset conditions, terminate the execution of hierarchical access control.

[0049] In some examples, if the secondary verification still fails, it is judged as a failure, all control requests are completely rejected, and a security exception log is generated and uploaded, thereby ensuring security while minimizing the risk of system lock-up due to a single verification failure.

[0050] In some embodiments, an in-vehicle access control method is proposed, which, when voiceprint information, location, and recognition results do not meet preset conditions, enters a waiting mode for a preset waiting time; if the user triggers an authentication request again within the waiting time, the method returns a response to the user's authentication request, obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain the recognition result; and if the voiceprint information, location, and recognition result still do not meet the preset conditions, the access control is terminated. This solves the technical problem of how to allocate permissions to execute instructions based on seating position. Compared with the prior art, this application enters a waiting mode for a preset time when the access verification fails on the first attempt, allowing the user to re-trigger the authentication request for a second attempt. This effectively avoids access misjudgment caused by non-malicious factors such as single recognition errors or temporary environmental interference, and enhances the system's fault tolerance.

[0051] In some embodiments, refer to Figure 5 , Figure 5 The third flowchart provided for some embodiments of the in-vehicle access control method of this application further includes steps S60-S80: Step S60: Obtain the scene mode configuration information of the in-vehicle facilities; In some examples, to address the need for dynamic adaptation of user permissions under different vehicle usage scenarios, scenario mode permissions can be configured to obtain scenario mode configuration information. This scenario mode configuration information is a dataset of control strategies used to dynamically match different vehicle usage scenarios. For example, the scenario mode configuration information defines multiple scenario modes: driving mode, maintenance mode, and visitor mode. Driving mode is the system configuration under normal vehicle driving conditions. In driving mode, powertrain and chassis operations can only be performed by the driver, and are prohibited in other areas. For air conditioning system functions, all functions are allowed in the driver's area, while other seats can only operate functions corresponding to their respective areas. Similarly, for the infotainment system, all functions are allowed in the driver's area, while other seats can only operate functions corresponding to their respective areas. Function adjustment: Maintenance mode is configured when the vehicle enters inspection or diagnostic state. In maintenance mode, all permissions are granted, allowing operation of all areas and all categories of functions, facilitating inspection and repair. Guest mode is a restricted permission configuration for non-owners temporarily using the vehicle. In guest mode, permissions are granted, allowing adjustment of corresponding areas of the entertainment information domain, such as adjusting playlists, single-zone air conditioning, and single-door windows, minimizing privacy exposure. Privacy data and settings functions are only operable by the driver. This allows for automatic switching based on the current scenario before receiving user interaction commands, or manual selection of the corresponding control strategy by the user, ensuring driving safety and owner privacy, minimizing accidental operation, and enhancing the intelligence and adaptability of vehicle interaction.

[0052] Step S70: Determine the permitted function information of the in-vehicle facilities in the current scene mode based on the scene mode configuration information; In some examples, it is necessary to determine the permitted functions of in-vehicle facilities in the current scenario mode based on the scenario mode configuration information. The function permission information is the permission data of the in-vehicle sub-functions, which can automatically switch to the most appropriate permission level according to different scenarios. Among them, the in-vehicle sub-function is the smallest executable operation unit, such as driver's seat temperature adjustment and rear window lifting. The function permission information is the execution permission generated after authorizing the in-vehicle sub-functions one by one. The target control request command is the voice or touch command issued by the user to actively request the reassignment of permission level. It is used to trigger secondary authentication and obtain the operation permission of the corresponding seat, thereby avoiding the incompatibility of permissions due to scenario changes as much as possible and improving the intelligence level of vehicle control.

[0053] In some examples, step S70 may include steps C11 to C13: Step C11: When the scenario mode configuration information is set to driving mode, the permitted function information is that the driver is permitted to have power chassis operation function, air conditioning function and entertainment function, and the passenger is permitted to have air conditioning function and entertainment function. Understandably, in driving mode, for the core requirement of safe driving, the driver needs to have full control over the vehicle, including power chassis operation (such as accelerator, brake, steering, etc.) as well as air conditioning and entertainment functions. The front passenger, as a passenger, usually does not need to intervene in driving operations, so only the air conditioning and entertainment functions are turned on to avoid accidental operation affecting driving safety, while ensuring the comfort of the front passenger.

[0054] Step C12: When the scenario mode configuration information is set to maintenance mode, the permitted function information is that the driver and passenger seats are permitted to have power chassis operation functions, air conditioning functions, and entertainment functions. Understandably, in maintenance mode, the vehicle is stationary or under inspection, and both the driver and passenger need to have the authority to operate the vehicle's power chassis in order to perform adjustments, tests, or emergency relocation. At the same time, the air conditioning and entertainment functions remain on to maintain a comfortable interior environment, taking into account both the flexibility and safety of maintenance work.

[0055] Step C13: When the scene mode configuration information is set to guest mode, the permitted function information is that the driver and passenger are permitted to have entertainment functions.

[0056] Understandably, in visitor mode, the vehicle is usually used temporarily by non-owners. To ensure that the vehicle's main functions (such as power, chassis, air conditioning, etc.) are not operated by unauthorized personnel, only the entertainment functions are enabled for the driver and passenger to meet the visitor's basic audio-visual entertainment needs and to minimize the risk of vehicle damage or safety risks due to misoperation.

[0057] Step S80, if the voiceprint information, the user's location, and the recognition result meet preset conditions, grants the user permission to operate the in-vehicle facilities, and also includes: If the voiceprint information, user location, identification, and permission information results meet the preset conditions, the user is granted permission to operate the in-vehicle facilities.

[0058] In some examples, the system needs to check whether the user's current requested operation falls within the scope of functions allowed in the scenario mode. For example, in guest mode, because the permitted function information only includes entertainment functions, even if the user passes voiceprint and facial recognition, they cannot obtain power chassis operation permissions. Similarly, in driving mode, the passenger cannot obtain power chassis permissions, so as to ensure that permissions are granted securely, in line with the reasonable expectations of different use scenarios, and to avoid security or management risks caused by unauthorized operations due to legitimate identity as much as possible.

[0059] An in-vehicle permission hierarchical control method proposed in some embodiments obtains scene mode configuration information of in-vehicle facilities; determines the permitted function information of in-vehicle facilities in the current scene mode based on the scene mode configuration information; and, when voiceprint information, user location, and recognition results meet preset conditions, grants the user operation permissions to the in-vehicle facilities. The method further includes: granting the user operation permissions to the in-vehicle facilities when the voiceprint information, user location, recognition, and permitted function information results meet preset conditions. This solves the technical problem of how to allocate permissions to execute instructions based on seating position. Compared with existing technologies, this application improves the adaptability and intelligence of the in-vehicle system in multiple scenarios by identifying the current scene of the vehicle and determining the permitted function range of each seat in the corresponding scene, ensuring driving safety and meeting the functional requirements of different usage scenarios.

[0060] In some embodiments, refer to Figure 6 , Figure 6 The fourth flowchart provided for some embodiments of the in-vehicle access control method of this application further includes steps S90~S110: Step S90: In response to the temporary authorization instruction issued by the driver user, obtain the authorized function, authorized object and effective time of the authorized function in the temporary authorization instruction; In some examples, a temporary authorization command is an authorization control signal initiated by the driver through the in-vehicle interactive terminal. Its purpose is to temporarily grant other passengers access to certain functions of the system or the driver's own vehicle. For example, a front passenger might temporarily need to operate the navigation, or a rear passenger might need to adjust the air conditioning temperature. Therefore, it is a high-priority dynamic permission change request. Responding to the temporary authorization command issued by the driver, the authorized function, the authorized recipient, and the effective time of the authorized function can be obtained. The authorized function is the list of specific authorized functions and their corresponding operation levels. For example, the driver can specify that the front passenger temporarily has the right to adjust the air conditioning temperature, or the rear passenger temporarily has the right to raise and lower the windows. The authorized recipient is the specific passenger receiving the permission, such as the front passenger or the left rear passenger. The effective time is a time constraint parameter attached to the authorization request, used to define the start and end times or duration of the temporary permission. For example, it can be set to "authorization takes effect from the current time and lasts for 30 minutes" or "authorization is valid until the vehicle is turned off," thus ensuring that the permission is automatically revoked after the authorization ends, restoring the default permission level of the original scenario.

[0061] Step S100: If the identity information of the control request instruction is the same as that of the authorized object, grant the user the permission to operate the authorized function according to the control request instruction. In some examples, when other users in the authorized group issue specific control request commands through the in-vehicle interactive terminal, the system verifies whether the identity information in the control request command matches the authorized group specified in the previous temporary authorization command from the driver. Only if the identities match will the system authorize the user to perform the corresponding operation on the authorized function based on the specific content of the control request command. For example, the front passenger can successfully raise the air conditioning temperature, or the rear passenger can successfully lower the window. This ensures the accurate issuance and execution of temporary permissions as much as possible, and quickly responds to the special needs of non-drivers. For example, during long-distance driving, the driver can temporarily authorize the rear children to adjust the entertainment screen volume to improve passenger comfort. The system provides a flexible shared operating space for visitors without requiring them to stop and modify system settings. Control request commands can be configured with temporary dedicated permissions for visitors. If the specific function corresponding to the control request command falls within the scope of the user's permissions, the system can control the vehicle's central controller or the corresponding domain controller to execute the vehicle function. If the control request command exceeds the allowed scope, the system will refuse to execute it and return a prompt message. The vehicle function refers to all hardware and software functional units inside the vehicle that can be controlled by the electronic system, including the air conditioning system, window system, seat adjustment, vehicle door locks, navigation system, multimedia playback, driver assistance functions, etc.

[0062] Step S110: If the temporary authorization period reaches its effective time, terminate the user's access to the authorized functions.

[0063] In some examples, the temporary authorization duration is a time constraint parameter set by the primary user in the authorization command, defining the effective duration or expiration time of the temporary permission. Terminating the user's operation permission for the authorized function means that when the temporary authorization duration reaches the effective time, the authorized object's control over the relevant function is revoked, and it will no longer respond to subsequent operation requests, restoring the primary user's exclusive control over the relevant function, that is, restoring it to the original default permission level.

[0064] In some embodiments, an in-vehicle permission hierarchical control method is proposed. In response to a temporary authorization command issued by the driver, the method obtains the authorized function, authorized object, and effective time of the authorized function from the temporary authorization command. If the identity information of the control request command is the same as the authorized object, the method grants the user the operation permission for the authorized function according to the control request command. And if the temporary authorization duration reaches its effective time, the method terminates the user's operation permission for the authorized function. This solves the technical problem of how to allocate permissions to execute commands based on seating position. Compared with existing technologies, this application, by responding to the driver's temporary authorization command, achieves time-limited authorization for specific users and specific functions. While ensuring the driver's absolute control over the core functions of the vehicle as much as possible, it allows the driver to temporarily grant some operation permissions to the front passenger or rear passengers.

[0065] This application also provides an in-vehicle access control device, please refer to... Figure 7 The in-vehicle access control system includes: The acquisition module 10 is used to respond to the user's triggered authentication request, acquire the user's voiceprint information, determine the user's location based on the voiceprint information, and perform facial recognition on the user to obtain the recognition result. The execution module 20 is used to grant the user permission to operate the in-vehicle facilities when the voiceprint information, the user's location, and the recognition result meet preset conditions.

[0066] The execution module 20 is also used to determine whether the user identity information indicated by the voiceprint information is registered identity information, whether the user identity information indicated by the recognition result is registered identity information, whether the user identity information indicated by the voiceprint information is consistent with the user identity information indicated by the recognition result, and whether the user's location is a location that has been pre-authorized to operate the in-vehicle facilities.

[0067] The execution module 20 is also used to determine the user's location using a liveness detection method.

[0068] The execution module 20 is also used to enter a waiting mode according to a preset waiting time when the voiceprint information, location, or recognition result does not meet the preset conditions. If the user triggers the authentication request again within the waiting time, the system returns a response to the user's authentication request, obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain the recognition result. If the voiceprint information, location, and recognition results still do not meet the preset conditions, the execution of hierarchical access control will be terminated.

[0069] The execution module 20 is also used to obtain scene mode configuration information of in-vehicle facilities; Determine the permitted functions of in-vehicle facilities in the current scenario mode based on the scenario mode configuration information; If the voiceprint information, user location, and recognition results meet preset conditions, the user's permission to operate in-vehicle facilities also includes: If the voiceprint information, user location, identification, and permission information results meet the preset conditions, the user is granted permission to operate the in-vehicle facilities.

[0070] The execution module 20 is also used to, when the scenario mode configuration information is driving mode, permit the driver to have power chassis operation function, air conditioning function and entertainment function, and permit the passenger to have air conditioning function and entertainment function. When the scenario mode configuration information is set to maintenance mode, the permitted function information is that the driver and passenger seats are permitted to have power chassis operation functions, air conditioning functions, and entertainment functions; When the scene mode configuration information is set to guest mode, the permitted function information is that the driver and passenger are permitted to have entertainment functions.

[0071] The execution module 20 is also used to respond to the temporary authorization command issued by the driver user, and to obtain the authorized function, authorized object and effective time of the authorized function in the temporary authorization command; If the identity information of the control request instruction is the same as that of the authorized object, the user is granted the right to operate the authorized function according to the control request instruction; If the temporary authorization period expires, terminate the user's access to the authorized functions.

[0072] The in-vehicle permission hierarchical control device provided in this application, employing the in-vehicle permission hierarchical control method in the above embodiments, can solve the technical problem of how to allocate permissions to execute instructions based on seating position. Compared with the prior art, the beneficial effects of the in-vehicle permission hierarchical control device provided in this application are the same as those of the in-vehicle permission hierarchical control method provided in the above embodiments, and other technical features in the in-vehicle permission hierarchical control device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0073] This application provides an in-vehicle access control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the in-vehicle access control method in Embodiment 1 above.

[0074] The following is for reference. Figure 8 This document illustrates a structural schematic diagram of an in-vehicle access control device suitable for implementing some embodiments of this application. The in-vehicle access control device in some embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The in-vehicle access control device shown is merely an example and should not impose any limitations on the functionality and scope of use of some embodiments of this application.

[0075] like Figure 8As shown, the in-vehicle access control system may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the in-vehicle access control system. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the in-vehicle access control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show in-vehicle access control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0076] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0077] The in-vehicle permission hierarchical control device provided in this application, employing the in-vehicle permission hierarchical control method in the above embodiments, can solve the technical problem of how to allocate permissions according to seating position to execute instructions. Compared with the prior art, the beneficial effects of the in-vehicle permission hierarchical control device provided in this application are the same as the beneficial effects of the in-vehicle permission hierarchical control method provided in the above embodiments, and other technical features in this in-vehicle permission hierarchical control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0078] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0079] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived 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.

[0080] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the in-vehicle access control method in the above embodiments.

[0081] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, 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 (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In some embodiments, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0082] The aforementioned computer-readable storage medium may be included in the in-vehicle access control system; or it may exist independently and not be installed in the in-vehicle access control system.

[0083] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the in-vehicle access control device, the in-vehicle access control device: in response to a user triggering an authentication request, obtains the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain a recognition result; and, if the voiceprint information, the user's location, and the recognition result meet preset conditions, grants the user access to operate the in-vehicle facilities.

[0084] 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 the "C" language or similar programming 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 a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0085] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, 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, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0086] The modules described in some embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0087] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described in-vehicle access control method, thereby solving the technical problem of how to allocate permissions based on seating position to execute instructions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the in-vehicle access control method provided in the above embodiments, and will not be repeated here.

[0088] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for hierarchical control of in-vehicle access permissions, characterized in that, The method includes: In response to a user triggering an authentication request, the system acquires the user's voiceprint information, determines the user's location based on the voiceprint information, and performs facial recognition on the user to obtain a recognition result; and If the voiceprint information, the user's location, and the recognition result meet preset conditions, the user is granted permission to operate the in-vehicle facilities.

2. The method as described in claim 1, characterized in that, The preset conditions include at least one of the following: The user identity information indicated by the voiceprint information is registered identity information; the user identity information indicated by the recognition result is registered identity information; the user identity information indicated by the voiceprint information is consistent with the user identity information indicated by the recognition result; and the user's location is a location where the user has been pre-authorized to operate the in-vehicle facilities.

3. The method as described in claim 1, characterized in that, The user's location is determined using a liveness detection method.

4. The method as described in claim 1, characterized in that, In response to a user-triggered authentication request, the system acquires the user's voiceprint information, determines the user's location based on the voiceprint information, performs facial recognition on the user, obtains the recognition result, and then includes: If the voiceprint information, the location, or the recognition result does not meet the preset conditions, the system will enter a waiting mode after a preset waiting time. If the user triggers an authentication request again within the waiting time, the steps of responding to the user's authentication request, obtaining the user's voiceprint information, determining the user's location based on the voiceprint information, and performing facial recognition on the user to obtain the recognition result are returned; and If the voiceprint information, the location, and the recognition result still do not meet the preset conditions, the execution of hierarchical access control will be terminated.

5. The method as described in claim 1, characterized in that, The in-vehicle access control method further includes: Obtain scene mode configuration information for in-vehicle facilities; The permitted function information of the in-vehicle facilities in the current scene mode is determined based on the scene mode configuration information; and The provision of granting the user access to in-vehicle facilities when the voiceprint information, the user's location, and the recognition result meet preset conditions further includes: If the voiceprint information, the user's location, the identification, and the permission function information result meet preset conditions, the user is granted permission to operate the in-vehicle facilities.

6. The method as described in claim 5, characterized in that, The step of determining the permitted function information of the in-vehicle facilities in the current scene mode based on the scene mode configuration information includes: When the scenario mode configuration information is set to driving mode, the permitted function information is that the driver's seat is permitted to have power chassis operation function, air conditioning function and entertainment function, and the passenger seat is permitted to have air conditioning function and entertainment function. When the scenario mode configuration information is set to maintenance mode, the permitted functions are: the driver and passenger are permitted to have powertrain chassis operation functions, air conditioning functions, and entertainment functions; and When the scenario mode configuration information is set to guest mode, the permitted function information is that the driver and passenger are permitted to have entertainment functions.

7. The method as described in claim 5, characterized in that, The in-vehicle access control method further includes: In response to a temporary authorization command issued by the primary driver, obtain the authorized function, the authorized object, and the effective time of the authorized function in the temporary authorization command; If the identity information of the control request instruction is the same as that of the authorized object, the user is granted permission to operate the authorized functions according to the control request instruction; and If the temporary authorization period reaches the effective time, the user's access to the authorized functions will be terminated.

8. A vehicle-mounted access control system, characterized in that, The device includes: The acquisition module is used to respond to a user-triggered authentication request, acquire the user's voiceprint information, determine the user's location based on the voiceprint information, and perform facial recognition on the user to obtain the recognition result. The execution module is used to grant the user permission to operate the in-vehicle facilities when the voiceprint information, the user's location, and the recognition result meet preset conditions.

9. A vehicle-mounted access control system, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the in-vehicle access control method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the in-vehicle access control method as described in any one of claims 1 to 7.

Images