Access control method and apparatus, electronic device, and storage medium

CN123020085APending Publication Date: 2026-10-30BEIJING XIAOMI MOBILE SOFTWARE CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510551677.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-28
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

当前在智能座舱中,车内的网络摄像头(Internet Protocol Camera,IPC)用于监控驾驶员状态、乘客行为及舱内环境,相关技术中,IPC产品的远程访问通常依赖于简单的身份验证机制,但这种方式无法动态适应不同用车场景的需求,未能充分考虑车辆内部的实际状态,导致监控数据的反馈缺乏灵活性和针对性

Benefits of technology

[0040]本申请提出的访问控制方法、装置、电子设备、芯片和存储介质,通过请求方的身份数据和车辆内部状态,实现了针对访问请求进行监控数据反馈,可以动态适应不同用车场景下访问控制的需求,充分考虑车辆内部的实际状态,提高了监控数据的反馈的灵活性和针对性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123020085A_ABST
    Figure CN123020085A_ABST
Patent Text Reader

Abstract

The application provides an access control method and device, electronic equipment and a storage medium. The method comprises the following steps: receiving an access request of a request party, and determining identity data of the request party; wherein the access request is used for requesting to obtain monitoring data of a camera in a vehicle; and determining whether to send the monitoring data to the request party according to the identity data of the request party and a vehicle internal state, wherein the vehicle internal state comprises a running scene in which the vehicle is located. Through the identity data of the request party and the vehicle internal state, the monitoring data feedback for the access request is realized, the demand of access control in different vehicle use scenes can be dynamically adapted, the actual state in the vehicle is fully considered, and the flexibility and pertinence of the monitoring data feedback are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of smart cockpit technology, and more particularly to an access control method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of intelligent vehicle technology, remote vehicle monitoring has gradually become a key focus for users. Currently, in intelligent cockpits, in-vehicle network cameras (Internet Protocol Cameras, IPCs) are used to monitor driver status, passenger behavior, and the cabin environment. In related technologies, remote access to IPC products typically relies on simple authentication mechanisms. However, this approach cannot dynamically adapt to the needs of different usage scenarios and fails to fully consider the actual state inside the vehicle, resulting in a lack of flexibility and specificity in the feedback of monitoring data. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in the related art.

[0004] Therefore, this application proposes a method, apparatus, electronic device, and storage medium.

[0005] One embodiment of this application proposes an access control method, including:

[0006] Receive an access request from the requester and determine the identity data of the requester; wherein, the access request is used to request the acquisition of monitoring data from the camera in the vehicle;

[0007] Based on the identity data of the requester and the internal status of the vehicle, determine whether to send the monitoring data to the requester. The internal status of the vehicle includes the operating scenario in which the vehicle is located.

[0008] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's interior status includes:

[0009] If there are people inside the vehicle, determine whether to send the monitoring data to the requesting party based on the instructions of the people inside the vehicle.

[0010] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's interior status includes:

[0011] If there are no people inside the vehicle, determine whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's scenario mode.

[0012] Optionally, determining whether to send the monitoring data to the requesting party based on the instructions of the occupants of the vehicle includes any of the following:

[0013] When the indication is to accept access, a feedback strategy is determined for the requester based on the requester's permissions, and the feedback strategy is related to the monitoring data;

[0014] If the indication is "access denied", a denial message is sent to the requesting party.

[0015] Optionally, the identity data of the requester can be any of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining the feedback strategy for the requester based on their permissions includes any of the following:

[0016] If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester.

[0017] If the requester's identity data indicates that the user is authorized, the monitoring data is processed according to a preset procedure and then sent to the requester.

[0018] If the requester's identity data indicates that the user is a temporary user or an unauthorized user, a rejection message will be sent to the requester.

[0019] Optionally, the method further includes at least one of the following:

[0020] Generate and play the voice prompt based on the access request.

[0021] Generate a text prompt message based on the access request, and display the text prompt message on the display.

[0022] An image prompt message is generated based on the access request, and the image prompt message is displayed on the monitor.

[0023] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's internal status includes any one of the following:

[0024] When the scenario mode is a preset target mode, it is determined whether to send the monitoring data to the requester based on the requester's identity data, wherein the preset target mode is a scenario mode that allows remote viewing;

[0025] When the scenario mode is not the preset target mode, a rejection message is sent to the requester.

[0026] Optionally, the identity data of the requester can be any one of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining whether to send the monitoring data to the requester based on the identity data of the requester includes any one of the following:

[0027] If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester.

[0028] If the identity data of the requester is not that of the vehicle owner, an authorization request is sent to the vehicle owner. Based on the feedback of the authorization request, a feedback strategy is determined for the requester, and the feedback strategy is related to the monitoring data.

[0029] Optionally, determining the feedback strategy for the requester based on the feedback of the authorization request includes any of the following:

[0030] If the identity data of the requester is that of a temporary user or an unauthorized user, a rejection message is sent to the requester.

[0031] If the requester's identity data indicates that the user is authorized, and the authorization request response indicates agreement to authorization, the monitoring data is processed according to a preset procedure and then sent to the requester.

[0032] If the requester's identity data indicates that the user is authorized, and the response to the authorization request is that the user does not agree to the authorization, a rejection message will be sent to the requester.

[0033] Another embodiment of this application proposes an access control device, including:

[0034] Receive an access request from the requester and determine the identity data of the requester; wherein, the access request is used to request the acquisition of monitoring data from the camera in the vehicle;

[0035] Based on the identity data of the requester and the internal status of the vehicle, determine whether to send the monitoring data to the requester. The internal status of the vehicle includes the operating scenario in which the vehicle is located.

[0036] Another embodiment of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in the foregoing aspect.

[0037] Another embodiment of this application proposes a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the foregoing aspect.

[0038] Another embodiment of this application proposes a chip including processing circuitry configured to perform the method described in one aspect above.

[0039] Another embodiment of this application proposes a computer program product having a computer program stored thereon, which, when executed by a processor, implements the method described in the foregoing aspect.

[0040] The access control method, device, electronic device, chip, and storage medium proposed in this application realize the monitoring data feedback for access requests by using the identity data of the requester and the internal state of the vehicle. It can dynamically adapt to the access control needs under different vehicle use scenarios, fully consider the actual state of the vehicle, and improve the flexibility and pertinence of the monitoring data feedback.

[0041] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0042] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0043] Figure 1 A flowchart illustrating an access control method provided in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram of the structure of a rendering apparatus provided in an embodiment of this application;

[0045] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0046] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0047] In related technologies, in smart cockpits, in-vehicle cameras (IPCs) are used to monitor driver status, passenger behavior, and the cabin environment. However, most IPC products can only be used for local viewing within the cabin and do not support remote viewing, resulting in limited functionality. Alternatively, some IPC products and the cockpit system are two independent systems with low integration, allowing users to freely view cabin videos, bypassing authorized operations and infringing on the privacy of cabin occupants. Furthermore, traditional solutions typically employ fixed priority or first-come-first-served strategies, failing to dynamically adapt to different scenario needs, such as prioritizing responses to driver requests in emergency situations.

[0048] The access control method, apparatus, electronic device, chip, and storage medium of this application are described below with reference to the accompanying drawings.

[0049] Figure 1 This is a schematic diagram of an access control process provided in an embodiment of this application.

[0050] As one implementation, the access control method of this application embodiment can be configured in an access control device, which can be applied to any electronic device so that the electronic device can perform access control functions.

[0051] Among them, electronic devices can be any device with computing capabilities, such as mobile terminals, which can be hardware devices with various operating systems, touch screens and / or displays, such as mobile phones, tablets, personal digital assistants, wearable devices, etc.

[0052] As another implementation, the access control method of this application embodiment can also be executed by a chip with processing capabilities. The chip includes an image signal processing chip (ISP), a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a system on a chip (SOC), a reduced instruction set computer (RISC), etc., which will not be listed here.

[0053] like Figure 1 As shown, the method may include the following steps:

[0054] Step 101: Receive the access request from the requester and determine the identity data of the requester; wherein, the access request is used to request the acquisition of monitoring data from the camera in the vehicle;

[0055] Step 102: Based on the identity data of the requester and the internal status of the vehicle, determine whether to send the monitoring data to the requester. The internal status of the vehicle includes the operating scenario in which the vehicle is located.

[0056] In this embodiment, multiple network camera IPCs are installed in the vehicle to collect images and audio, receive remote viewing requests from the mobile application, and return the results of remote viewing to the mobile application based on the working status of the vehicle system and the corresponding operations of the user in the cabin.

[0057] The requesting party initiates a remote viewing request or preemption request to the vehicle's infotainment system via a mobile application. If the vehicle's infotainment system allows viewing, it will send the monitoring data captured by the IPC to the mobile application, displaying the real-time footage inside the cabin. At the same time, the video intercom function can be enabled.

[0058] The requester's access permissions can be determined based on the requester's identity data, and the vehicle's operating scenario can be determined based on the vehicle's internal status. Different judgment logics can be set for different operating scenarios to determine whether to send the monitoring data to the requester, thereby avoiding unnecessary monitoring and protecting the privacy of the people in the vehicle.

[0059] By authenticating received access requests, the system ensures that only legitimate requesters can access vehicle camera monitoring data, preventing unauthorized access and misuse. The system determines whether to send monitoring data based on the vehicle's operating environment, enabling remote access to adapt to different scenarios, such as when the vehicle is in motion or parked, thus enhancing the system's flexibility and practicality.

[0060] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's interior status includes:

[0061] If there are people inside the vehicle, determine whether to send the monitoring data to the requesting party based on the instructions of the people inside the vehicle.

[0062] In this embodiment, the vehicle system collects in-vehicle image data through the vehicle's internal camera, performs human body recognition on the image data to determine whether there are people inside the vehicle. If there are people inside the vehicle, in order to protect the privacy of the people inside the vehicle, it is necessary to increase the priority of the people inside the vehicle in the decision-making process of deciding whether to send monitoring data, so that the people inside the vehicle can decide whether to send monitoring data to the requester.

[0063] In one possible embodiment, when there are people in the vehicle, the vehicle system will emit a specific prompt tone through the vehicle's audio system, or generate a voice prompt to remind the person requesting monitoring data in the vehicle. The person in the vehicle can indicate whether to agree to send the monitoring data through voice commands, touch screen, or physical buttons.

[0064] When there are people inside the vehicle, granting them the authority to send monitoring data fully respects their wishes and privacy needs, avoiding potential privacy issues that might arise from sending monitoring data without their consent. By deciding whether to send monitoring data based on the instructions of the people inside the vehicle, the system can more flexibly respond to different situations, improving the applicability and practicality of the vehicle remote access function.

[0065] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's interior status includes:

[0066] If there are no people inside the vehicle, determine whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's scenario mode.

[0067] In this embodiment, the vehicle's infotainment system collects in-vehicle image data through cameras inside the vehicle. It then performs human recognition on the image data to determine if anyone is inside the vehicle. If no one is inside, the system needs to consider both the vehicle's scenario mode and the requester's identity to determine whether to send monitoring data to the requester. The vehicle's scenario mode is a function that provides users with a convenient, comfortable, and personalized driving and riding experience through the collaborative work of vehicle hardware and software, based on user usage scenarios and needs.

[0068] When no one is inside the vehicle, the system can automatically decide whether to send monitoring data based on the requester's identity data and the vehicle's scenario mode, without human intervention, thus improving the system's automation level and processing efficiency. In unmanned situations, the system ensures that only legitimate requesters meeting the scenario requirements can obtain monitoring data through dual verification of the requester's identity and scenario mode, further guaranteeing vehicle security and the confidentiality of monitoring data.

[0069] Optionally, determining whether to send the monitoring data to the requesting party based on the instructions of the occupants of the vehicle includes any of the following:

[0070] When the indication is to accept access, a feedback strategy is determined for the requester based on the requester's permissions, and the feedback strategy is related to the monitoring data;

[0071] If the indication is "access denied", a denial message is sent to the requesting party.

[0072] In this embodiment, when there are people inside the vehicle, to protect their privacy, the priority of these occupants in the decision-making process regarding whether to send monitoring data needs to be increased. The occupants should then determine whether to send monitoring data to the requester. They can choose to reject or accept the request. If they choose to reject, no monitoring data needs to be sent; a rejection message is sent directly to the requester to inform them that the access request has been denied. If they choose to accept the access request, the system will further determine the requester's permissions based on their identity. The vehicle's infotainment system has multiple pre-set identity information and corresponding permissions. Based on the requester's permissions, a feedback strategy can be determined. This strategy includes whether to allow a specific identity to access monitoring data and whether the monitoring data needs to be processed before being sent back to the specific identity.

[0073] In one possible embodiment, when there are people in the vehicle, the vehicle system will emit a specific prompt tone through the vehicle's audio system, or generate a voice message to remind the person requesting monitoring data in the vehicle. The person in the vehicle can indicate whether they agree to send the monitoring data via voice command, touch screen, or physical button. If the person in the vehicle expresses their intention not to send the data via voice or presses the disagree button, the vehicle system will understand that the person in the vehicle is refusing to send the monitoring data and will send a rejection message to the requester. The requester will receive the rejection message on their mobile app.

[0074] In one possible implementation, when someone is inside the vehicle, the vehicle system will emit a specific prompt tone through the in-vehicle audio system, or generate a voice message to remind the person requesting in-vehicle monitoring data. The person inside the vehicle can indicate whether they agree to send the monitoring data via voice command, touchscreen, or physical button. If the person inside the vehicle expresses their agreement via voice or presses the "agree" button, the vehicle system understands that the person agrees to send the monitoring data and will send an agreement message to the requester. The requester will receive the agreement message on their mobile app. The mobile app retrieves the monitoring video stream, and then the IPC returns the monitoring video stream to the mobile app.

[0075] The system clarifies the specific procedures for granting or denying access to personnel inside the vehicle, enabling it to respond quickly and accurately to their instructions, thus improving system reliability and user experience. Clear instructions and procedures reduce the likelihood of erroneous data transmission or rejection due to user error, enhancing system stability and security.

[0076] Optionally, the identity data of the requester can be any of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining the feedback strategy for the requester based on their permissions includes any of the following:

[0077] If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester.

[0078] If the requester's identity data indicates that the user is authorized, the monitoring data is processed according to a preset procedure and then sent to the requester.

[0079] If the requester's identity data indicates that the user is a temporary user or an unauthorized user, a rejection message will be sent to the requester.

[0080] In this embodiment, if someone is inside the vehicle and agrees to send monitoring data to the requester, the requester's permissions are determined based on the requester's identity data. The requester's permissions are formulated according to security specifications and managed in detail based on their role. The requester's identity data includes: vehicle owner, authorized user, temporary user, and unauthorized user. The vehicle owner, as the owner of the vehicle, has the highest permissions and can view the complete monitoring data. Authorized users are users authorized and trusted by the vehicle owner and can view partial monitoring data, such as monitoring data collected by specific cameras inside the vehicle, rather than all cameras, or specific images within the monitoring data, such as images that do not contain faces, requiring blurring of a portion of the monitoring data to obtain the desired image. Temporary users are people temporarily using the vehicle, such as vehicle renters; unauthorized users are users without authorization and have no connection to the vehicle. To protect vehicle privacy, temporary users and unauthorized users are not allowed to view the vehicle's monitoring data.

[0081] In one possible embodiment, the permissions of requesters with various identities are shown in Table 1:

[0082] User Role Remotely view camera Remote monitoring Remote operation Car owner Full permissions Listenable Adjustable camera Authorized users Restricted permissions prohibit prohibit Temporary users prohibit prohibit prohibit Unauthorized users prohibit prohibit prohibit

[0083] Table 1

[0084] The vehicle owner has full operational privileges, such as viewing surveillance data captured by the cameras, listening to sounds inside the vehicle via the in-vehicle microphone, communicating with occupants, and remotely operating the in-vehicle cameras to adjust their angles to capture specific locations. Other users are not allowed to remotely monitor or operate the cameras; only authorized users authorized by the vehicle owner can view the surveillance data within a limited scope.

[0085] In one possible implementation, if there are people inside the vehicle, the user inside the vehicle agrees to send monitoring data to the requester. If the requester is the vehicle owner, the complete monitoring data will be sent to the vehicle owner's mobile app.

[0086] In one possible implementation, if there are people inside the vehicle, the user inside the vehicle agrees to send monitoring data to the requester. If the requester is an authorized user, the face in the complete monitoring data will be blurred and then sent to the authorized user's mobile APP.

[0087] In one possible embodiment, if there are people in the vehicle, the user in the vehicle agrees to send monitoring data to the requester. If the requester is a temporary user, the faces in some of the camera monitoring data will be blurred before being sent to the temporary user's mobile APP.

[0088] In one possible implementation, if there are people in the vehicle, the user in the vehicle agrees to send monitoring data to the requester. If the requester is an unauthorized user, a rejection message is sent to the unauthorized user's mobile app.

[0089] Fine-grained access control is implemented for requesters with different identities. Whether to send monitoring data and how to process it are determined based on whether the requester is a vehicle owner and their permission level, enhancing system security and data protection capabilities. More personalized services are provided to users with different identities; for example, vehicle owners can directly access monitoring data, while authorized users who are not vehicle owners have their data processed according to their permissions before being sent. This meets the needs of different user groups, improving system applicability and user satisfaction.

[0090] Optionally, the method further includes at least one of the following:

[0091] Generate and play the voice prompt based on the access request.

[0092] Generate a text prompt message based on the access request, and display the text prompt message on the display.

[0093] An image prompt message is generated based on the access request, and the image prompt message is displayed on the monitor.

[0094] In this embodiment, the prompts generated inside the vehicle can be voice messages, text messages, image messages, or light messages, to remind the occupants to make a selection to determine whether to allow the sending of monitoring data to the requesting party.

[0095] In one possible embodiment, the vehicle's infotainment system generates a "beep" sound to alert occupants that someone has requested access to in-vehicle monitoring data.

[0096] In one possible embodiment, the vehicle's infotainment system generates a voice message indicating a request to view surveillance data to alert occupants of the vehicle.

[0097] In one possible embodiment, the vehicle's infotainment system generates the message "Request to view monitoring data" and displays it on a display device within the vehicle to alert occupants that a requester is seeking access to in-vehicle monitoring data. Optionally, the display device may include a screen in the vehicle, an electronic instrument panel, or a head-up display (HUD).

[0098] In one possible embodiment, the vehicle's infotainment system controls the vehicle's interior lighting system to flash at a specific frequency and display a specific color to alert occupants that a requester is seeking access to in-vehicle monitoring data.

[0099] The system generates prompts to remind vehicle occupants whether they should allow the requester to access monitoring data. This allows occupants to be aware of remote access requests in a timely manner, avoiding the risk of privacy leaks or accidental data acquisition due to lack of awareness. It enhances occupants' participation in and control over the vehicle's remote access function, improving the system's user experience and friendliness.

[0100] Optionally, determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's scenario mode includes any one of the following:

[0101] When the scenario mode is a preset target mode, it is determined whether to send the monitoring data to the requester based on the requester's identity data, wherein the preset target mode is a scenario mode that allows remote viewing;

[0102] When the scenario mode is not the preset target mode, a rejection message is sent to the requester.

[0103] In this embodiment, the vehicle's scenario mode is a function that provides users with a convenient, comfortable, and personalized driving and riding experience through the coordinated work of vehicle hardware and software, based on user usage scenarios and needs. The vehicle is equipped with multiple scenario modes, with the target mode being an unoccupied scenario mode that allows remote viewing. Target modes include Sentry Mode, Camping Mode, and Parking Mode, among others.

[0104] In one possible embodiment, the target mode includes a sentry mode, in which the vehicle is unattended and the environment around the vehicle and the vehicle status are monitored in real time through visual algorithms and vibration detection. Once any abnormality is detected, such as a broken window or an impact, the vehicle will sound its horn and play music to warn unauthorized intruders.

[0105] In one possible embodiment, the target mode includes a camping mode, which maintains vehicle power supply and disables features such as door locking upon leaving the vehicle, thus providing convenience for camping.

[0106] In one possible embodiment, the target mode includes a parking mode, which is a state in which the vehicle is stopped and the engine is off, and the user can activate the parking mode when temporarily leaving the vehicle.

[0107] The system determines whether to send monitoring data based on the vehicle's current scenario, enabling it to adapt more intelligently to different usage scenarios and improving its intelligence and applicability. When the scenario is a preset target mode, the system directly determines whether to send monitoring data based on the requester's identity data, simplifying the decision-making process and improving processing efficiency and response speed.

[0108] Optionally, the identity data of the requester can be any one of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining whether to send the monitoring data to the requester based on the identity data of the requester includes any one of the following:

[0109] If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester.

[0110] If the identity data of the requester is not that of the vehicle owner, an authorization request is sent to the vehicle owner. Based on the feedback of the authorization request, a feedback strategy is determined for the requester, and the feedback strategy is related to the monitoring data.

[0111] In this embodiment, when there are no people inside the vehicle and the scenario mode is the preset target mode, the requester's permissions are determined based on the requester's identity data. The requester's permissions are formulated according to security specifications and managed in detail according to their role. The requester's identity data includes: vehicle owner, authorized user, temporary user, and unauthorized user. Among them, the vehicle owner is the owner of the vehicle and has the highest permissions, and can view complete monitoring data. If the requester is the vehicle owner, the monitoring data can be sent directly to the requester.

[0112] If the requester is not the vehicle owner, the vehicle owner needs to decide whether to send monitoring data to the requester. The vehicle system sends a notification to the vehicle owner to inform them of the authorization request from another requester. The vehicle owner needs to make a decision and determine the feedback strategy for the requester based on the vehicle owner's feedback. The feedback strategy specifically includes whether to send the monitoring data to the requester and whether to process the monitoring data before sending it.

[0113] In one possible embodiment, when the vehicle is unoccupied and in the target scenario mode, the vehicle owner initiates a remote access request to the vehicle via the APP, and the vehicle will send the complete monitoring data collected by the in-vehicle monitoring camera to the vehicle owner's mobile APP.

[0114] In one possible embodiment, when the vehicle is unoccupied and in a target scenario mode, a non-owner initiates a remote access request to the vehicle via an app. The vehicle's system then sends an authorization request to the owner and receives feedback. Based on the feedback, it sends monitoring data collected by the in-vehicle surveillance camera to the requester's mobile app. Optionally, the authorization request may be a prompt message in the owner's mobile app or an SMS message sent to the owner's mobile phone. The owner can perform actions within the mobile app to send feedback.

[0115] Based on the scenario mode, the permission management for requesters with different identities has been further refined, and the processing of monitoring data under different identity conditions has been clarified, thereby enhancing the system's security and data protection capabilities.

[0116] Optionally, determining the feedback strategy for the requester based on the feedback of the authorization request includes any of the following:

[0117] If the identity data of the requester is that of a temporary user or an unauthorized user, a rejection message is sent to the requester.

[0118] If the requester's identity data indicates that the user is authorized, and the authorization request response indicates agreement to authorization, the monitoring data is processed according to a preset procedure and then sent to the requester.

[0119] If the requester's identity data indicates that the user is authorized, and the response to the authorization request is that the user does not agree to the authorization, a rejection message will be sent to the requester.

[0120] In this embodiment, the requester's identity data includes: vehicle owner, authorized user, temporary user, and unauthorized user. When the vehicle is unoccupied and in the target scenario mode, if the requester's identity data indicates a temporary user or unauthorized user, no authorization request needs to be sent to the vehicle owner; the requester's access request is directly rejected. When the requester is an authorized user, an authorization request needs to be sent to the vehicle owner, who then decides whether to authorize the requester to view the monitoring data. After the vehicle owner authorizes the sending of monitoring data, the monitoring data can be processed before being sent to the requester. The preset processing is used to partially obscure the monitoring data inside the vehicle, retaining only the content that the requester is allowed to view.

[0121] In one possible implementation, the car owner can pre-authorize different permissions for different users. For example, user A can be granted permission to view in-vehicle monitoring data, while user B can be granted permission to view external monitoring data. Then, if the car owner grants permission after user A initiates an access request, the monitoring data captured by the in-vehicle camera will be sent to user A; similarly, if the car owner grants permission after user B initiates an access request, the monitoring data captured by the external camera will be sent to user B.

[0122] In one possible embodiment, when the vehicle is unoccupied and in the target scenario mode, the authorized user initiates a remote access request to the vehicle via the APP. The vehicle will send an authorization request to the vehicle owner and receive feedback. If the feedback is that the authorization is granted, the monitoring data collected by the in-vehicle monitoring camera will be sent to the requester's mobile APP.

[0123] In one possible embodiment, when the vehicle is unoccupied and in the target scenario mode, the authorized user initiates a remote access request to the vehicle via the APP. The vehicle will send an authorization request to the vehicle owner and receive feedback. If the feedback is that the authorization is agreed and the vehicle owner selects several network cameras in the vehicle for authorization, the monitoring data collected by the authorized in-vehicle monitoring cameras will be sent to the requester's mobile APP.

[0124] Comprehensive access control was implemented for requesters with different identities, including authorized and unauthorized users. Clear procedures were established for handling monitoring data in various situations, ensuring system security and data confidentiality. For requesters who are neither vehicle owners nor authorized users, a direct rejection message was sent, effectively preventing unauthorized access to monitoring data and improving system security. For authorized users, monitoring data was processed based on the authorization request response and their permissions before transmission, enabling personalized processing and transmission of monitoring data, meeting the needs of different users, and improving system applicability and user experience.

[0125] To implement the above embodiments, this application also proposes an access control device.

[0126] Figure 2 This is a schematic diagram of an access control device provided in an embodiment of this application.

[0127] like Figure 2 As shown, the device may include:

[0128] The receiving module 210 is used to receive the access request from the requester and determine the identity data of the requester; wherein, the access request is used to request to obtain the monitoring data of the camera in the vehicle;

[0129] The control module 220 is used to determine whether to send the monitoring data to the requester based on the identity data of the requester and the internal state of the vehicle, wherein the internal state of the vehicle includes the operating scenario in which the vehicle is located.

[0130] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of this embodiment, and will not be repeated here.

[0131] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing method embodiments.

[0132] To implement the above embodiments, this application also proposes a computer program product having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described in the foregoing method embodiments.

[0133] To implement the above embodiments, this application also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described in the foregoing method embodiments.

[0134] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example, the electronic device 800 may be a remote camera, a vehicle, an in-vehicle system, a smart cockpit, etc.

[0135] Reference Figure 3 The electronic device 800 may include one or more of the following components: processing component 802, memory 804, power component 806, multimedia component 808, audio component 810, input / output (I / O) interface 812, sensor component 814, and communication component 816.

[0136] Processing component 802 typically controls the overall operation of electronic device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

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

[0138] Power component 806 provides power to various components of electronic device 800. Power component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 800.

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

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

[0141] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

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

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

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

[0145] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of an electronic device 800 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0146] To implement the above embodiments, this application also proposes a chip, including: the chip includes a processing circuit configured to perform the methods provided in the foregoing embodiments.

[0147] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0148] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0149] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0150] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0151] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0152] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0153] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0154] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. An access control method, characterized in that, include: Receive an access request from the requester and determine the identity data of the requester; wherein, the access request is used to request the acquisition of monitoring data from the camera in the vehicle; Based on the identity data of the requester and the internal status of the vehicle, determine whether to send the monitoring data to the requester. The internal status of the vehicle includes the operating scenario in which the vehicle is located.

2. The method according to claim 1, characterized in that, The step of determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's internal status includes: If there are people inside the vehicle, determine whether to send the monitoring data to the requesting party based on the instructions of the people inside the vehicle.

3. The method according to claim 1, characterized in that, The step of determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's internal status includes: If there are no people inside the vehicle, determine whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's scenario mode.

4. The method according to claim 2, characterized in that, The step of determining whether to send the monitoring data to the requesting party based on the instructions of the occupants of the vehicle includes any one of the following: When the indication is to accept access, a feedback strategy is determined for the requester based on the requester's permissions, and the feedback strategy is related to the monitoring data; If the indication is "access denied", a denial message is sent to the requesting party.

5. The method according to claim 4, characterized in that, The identity data of the requester is any one of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining the feedback strategy for the requester based on the requester's permissions includes any one of the following: If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester. If the requester's identity data indicates that the user is authorized, the monitoring data is processed according to a preset procedure and then sent to the requester. If the requester's identity data indicates that the user is a temporary user or an unauthorized user, a rejection message will be sent to the requester.

6. The method according to claim 2, characterized in that, The method further includes at least one of the following: Generate and play the voice prompt based on the access request. Generate a text prompt message based on the access request, and display the text prompt message on the display. An image prompt message is generated based on the access request, and the image prompt message is displayed on the monitor.

7. The method according to claim 3, characterized in that, The step of determining whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's scenario mode includes any one of the following: When the scenario mode is a preset target mode, it is determined whether to send the monitoring data to the requester based on the requester's identity data, wherein the preset target mode is a scenario mode that allows remote viewing; When the scenario mode is not the preset target mode, a rejection message is sent to the requester.

8. The method according to claim 7, characterized in that, The identity data of the requester is any one of the following: vehicle owner, authorized user, temporary user, or unauthorized user. The step of determining whether to send the monitoring data to the requester based on the identity data of the requester includes any one of the following: If the identity data of the requester is that of the vehicle owner, the monitoring data is sent to the requester. If the identity data of the requester is not that of the vehicle owner, an authorization request is sent to the vehicle owner. Based on the feedback of the authorization request, a feedback strategy is determined for the requester, and the feedback strategy is related to the monitoring data.

9. The method according to claim 8, characterized in that, The step of determining the feedback strategy for the requester based on the feedback of the authorization request includes any one of the following: If the identity data of the requester is that of a temporary user or an unauthorized user, a rejection message is sent to the requester. If the requester's identity data indicates that the user is authorized, and the authorization request response indicates agreement to authorization, the monitoring data is processed according to a preset procedure and then sent to the requester. If the requester's identity data indicates that the user is authorized, and the response to the authorization request is that the user does not agree to the authorization, a rejection message will be sent to the requester.

10. An access control device, characterized in that, include: The receiving module is used to receive the access request from the requester and determine the identity data of the requester; wherein, the access request is used to request the acquisition of monitoring data from the camera in the vehicle; The control module is used to determine whether to send the monitoring data to the requester based on the requester's identity data and the vehicle's internal status, wherein the vehicle's internal status includes the vehicle's operating scenario.

11. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method as described in any one of claims 1-9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-9.

13. A chip, characterized in that, The chip includes processing circuitry configured to perform the method as described in any one of claims 1-9.

14. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method of any one of claims 1-9.