Screen control method and device

Abstract

The embodiment of the invention discloses a screen control method and device, and the method comprises the steps: obtaining a target signal which is a signal generated based on user focus transfer; based on the target signal, determining a first seat after the focus of the user is transferred and a first screen corresponding to the first seat; determining a second screen before the focus of the user is transferred and a screen circulation strategy matched with an application program displayed by the second screen; and according to the screen circulation strategy, the display content of the application program displayed by the second screen is circulated to the first screen.

Description

TECHNICAL FIELD

[0001] The present application relates to, but is not limited to, the technical field of vehicle software design, and in particular to a screen control method and device. BACKGROUND

[0002] With the rapid development of intelligent cockpit technology, the richness of vehicle screen hardware and mobile device access has been significantly improved, and multi-screen interaction technology solutions have become increasingly mature. Currently, cross-screen gesture interaction, TOF (Time of Flight) interaction, and multi-screen sharing functions have landed in mass-produced vehicles and are gradually accepted by users.

[0003] However, existing vehicle entertainment systems mainly rely on active interaction methods such as voice control, touch operation, and air gestures. In the context of continuous progress in multi-modal interaction and artificial intelligence active recommendation technology, the current vehicle system lacks intelligent in-cabin multi-screen automatic interaction mode and cannot meet the user's demand for automatic following of task windows and focus windows when moving in multiple locations in the vehicle. SUMMARY

[0004] Therefore, the embodiments of the present application provide at least a screen control method and device.

[0005] The technical solutions of the embodiments of the present application are implemented as follows: On the one hand, the embodiments of the present application provide a screen control method, which comprises: obtaining a target signal, the target signal being a signal generated based on user focus shift; determining a first seat after user focus shift and a first screen corresponding to the first seat based on the target signal; determining a second screen before user focus shift and a screen flow strategy matched with an application program displayed by the second screen; flowing display content of the application program displayed by the second screen to the first screen according to the screen flow strategy.

[0006] On the other hand, the embodiments of the present application provide a screen control device, which comprises: an obtaining module configured to obtain a target signal, the target signal being a signal generated based on user focus shift; a determining module configured to determine a first seat after user focus shift and a first screen corresponding to the first seat based on the target signal, and determine a second screen before user focus shift and a screen flow strategy matched with an application program displayed by the second screen; a flowing module configured to flow display content of the application program displayed by the second screen to the first screen according to the screen flow strategy.

[0007] In another aspect, an embodiment of the present application provides a vehicle comprising a memory and a processor, the memory storing a computer program capable of running on the processor, and the processor implements part or all steps of the above-mentioned screen control method when executing the program.

[0008] In another aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program implements part or all steps of the above-mentioned screen control method when executed by a processor.

[0009] In another aspect, an embodiment of the present application provides a computer program, which comprises computer readable code, and the processor in a vehicle executes part or all steps of the above-mentioned screen control method when the computer readable code runs in the vehicle.

[0010] In another aspect, an embodiment of the present application provides a computer program product, which comprises a non-transitory computer readable storage medium storing a computer program, and the computer program is read and executed by a computer to implement part or all steps of the above-mentioned screen control method.

[0011] The embodiments of the present application realize intelligent flow of application content according to user position and vehicle state by automatic signal collection, focus determination, application type identification and strategy execution, improve multi-screen cooperation efficiency, reduce manual operation, enhance compatibility and energy efficiency optimization, and ensure safety and user experience continuity.

[0012] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, but not limiting the technical solutions of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the technical solutions of the present application.

[0014] Figure 1 An implementation flowchart of a screen control method provided by an embodiment of the present application; Figure 2 A vehicle system architecture diagram of a screen control vehicle system provided by an embodiment of the present application; Figure 3 A screen arrangement example and focus arbitration schematic diagram provided by an embodiment of the present application; Figure 4 A cockpit multi-screen multi-person multi-position focus schematic diagram provided by an embodiment of the present application; Figure 5A schematic diagram of the composition structure of a screen control device provided for an embodiment of the present application is shown in the figure. Figure 6 A schematic diagram of a hardware entity of a vehicle provided for an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0015] In order to make the purposes, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further described in detail below in combination with the drawings and embodiments, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without making creative efforts fall within the scope of protection of the present application.

[0016] In the following description, “some embodiments” are referred to, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0017] The terms “first / second / third” referred to are only to distinguish similar objects, and do not represent a specific order for the objects, and it can be understood that “first / second / third” can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the present application and are not intended to limit the present application.

[0019] With the gradual development of intelligent cockpit, the mounting of vehicle-mounted screen hardware and the access of mobile devices are becoming more and more rich, and the technical development and scheme of multi-screen interaction are also becoming more and more mature. In the current intelligent cockpit, cross-screen gesture interaction, TOF interaction, multi-screen sharing and other methods have been mass-produced and landed, and are gradually accepted by users. However, the current vehicle-mounted entertainment system usually adopts active interaction methods such as voice, touch, and air gesture. In the context of multi-modal development and AI active recommendation, there is a lack of more intelligent in-cabin multi-screen automatic interaction mode to meet the user's demand for simultaneous movement of task windows and focus windows when moving in the cabin: Insufficient multi-screen collaboration capability: When passengers move in the vehicle (such as front passengers moving to the back row), the video application cannot automatically follow the user's location and flow, and needs to be manually re-screened or the user needs to actively operate to specify the layout position, and cannot realize intelligent flow.

[0020] Compatibility of multiple applications is limited: Exclusive applications such as mobile screen mirroring and wireless / wired streaming (which require a single screen resource) are prone to interruption when switching, making seamless migration impossible; online video applications or multi-screen mini-program applications require explicit... Lack of hardware awareness: Existing technologies mainly focus on GUI / VGUI, TOF and other forms, without deeply integrating the vehicle's own hardware status and the unique space utilization mode in the cabin, such as scene mode (such as rest mode, power-on mode when away from the vehicle) and passenger status (such as seat occupancy, DMS detection) and other conditions to dynamically adjust content allocation.

[0021] This application addresses the problem of not being able to identify which scenarios allow application windows to flow within the cabin. It provides a method for multi-screen application flow based on in-vehicle screen devices. To enable entertainment application content to flow according to the needs of multiple passengers in the smart cabin, a connected in-vehicle system needs to be built, which includes vehicle hardware signal input source determination, application process management, multi-screen front-end rendering and display interface. This system includes real-time hardware signal acquisition links, passenger status judgment signal weights, and algorithm rules for front-end process management and display.

[0022] The core solution is to dynamically allocate screen resources and application foreground processes by integrating vehicle mode signals (such as rest mode and power-on mode when the vehicle is not turned off), passenger status detection (DMS / OMS sensors, seat occupancy signals) and application type recognition.

[0023] This application provides a screen control method, which can be executed by a vehicle's processor. The vehicle can refer to devices with screen control capabilities, such as servers, laptops, tablets, desktop computers, smart TVs, set-top boxes, and mobile devices (e.g., mobile phones, portable video players, personal digital assistants, dedicated messaging devices, portable gaming devices). Figure 1 This is a schematic diagram illustrating the implementation flow of a screen control method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: Obtain the target signal, which is a signal generated based on the user focus shift.

[0024] In this embodiment, the target signal refers to electronic data collected by the in-vehicle system through sensors and controllers that indicates a change in the user's focus. User focus shift refers to a change in position or state detected by the in-vehicle system when the user moves or changes their attention within the cabin, such as a change in passenger gaze direction or seat occupancy signal obtained through DMS (Driver Monitoring System) or OMS (Occupant Monitoring System).

[0025] The in-vehicle system monitors various signal sources from the vehicle's internal bus in real time through the signal acquisition layer, including the DMS, OMS, seat pressure sensors, door opening / closing modules, and CDC cockpit controller. These signals are categorized into three types: sensor layer signals, system status signals, and interaction trigger signals, and processed in parallel to identify user focus shift events. For example, when a passenger raises their hand or a change in seat occupancy is detected, the in-vehicle system generates a target signal and transmits it to the decision weight layer for further analysis, ensuring that the signal accurately reflects changes in user behavior.

[0026] Step 102: Based on the target signal, determine the first seat after the user's focus shifts and the first screen corresponding to the first seat.

[0027] In this embodiment, the first seat refers to the priority seat identified by the vehicle system after the user's focus shifts, such as the passenger position currently requiring service determined by the comprehensive arbitration module. The first screen is a display device associated with the first seat, such as the central control screen or the rear screen, and the vehicle system dynamically allocates screen resources according to the seat position.

[0028] Based on the target signal, the in-vehicle system runs a focus seat determination module at the decision weight layer. This module arbitrates data from DMS / OMS, seat occupancy signals, and door signals to identify the first seat and its corresponding first screen. For example, if a rear passenger is detected raising their hand and looking at the screen, the in-vehicle system will shift the focus to the rear seat and determine the screen corresponding to that seat as the first screen. Decision parameters include the passenger's hand-raising status, seat occupancy changes, and driving restrictions to ensure that focus allocation complies with safety rules and user needs.

[0029] Step 103: Determine the second screen before the user focus shifts, and the screen transition strategy that matches the application displayed on the second screen.

[0030] In this embodiment, the second screen refers to the display device being used before the user's focus shifts, such as the driver's screen or the passenger's screen. The screen transition strategy is a rule defined by the in-vehicle system based on the application type, used to determine how to migrate the displayed content from the second screen to other screens, including mirror synchronization, process migration, or multi-instance operation.

[0031] After identifying the second screen, the in-vehicle system analyzes the characteristics of the applications running on that screen using an application type recognition module, distinguishing between reproducible applications (such as online videos) and exclusive applications (such as screen mirroring from a mobile phone). Then, the in-vehicle system matches an appropriate screen transition strategy; for example, a mirroring strategy is used for reproducible applications, and a process remapping strategy is used for exclusive applications. The decision-making process considers the application process state, screen illumination status, and user interaction history to ensure accurate strategy selection.

[0032] Step 104: According to the screen transition strategy, the display content of the application displayed on the second screen is transitioned to the first screen.

[0033] In this embodiment, the displayed content refers to the visual data rendered on the screen by the application, such as video streams or interactive interfaces. The transfer process involves transmitting the displayed content from the second screen to the first screen, and the in-vehicle system completes the migration by controlling the screen hardware and application processes through the application execution layer.

[0034] The in-vehicle system executes specific operations at the application execution layer according to the screen transition strategy: for replicable applications, it activates the multi-screen mirroring function to synchronously project the displayed content onto the first screen; for exclusive applications, it pauses the original process and remaps the hardware interface to the first screen, such as re-initiating the screen projection protocol. The screen control module is responsible for waking up the target screen and adjusting the resolution, while the application enables the module to manage process persistence and window redirection, ensuring seamless migration of displayed content and a continuous user experience.

[0035] This application embodiment achieves intelligent flow of application content based on user location and vehicle status through automated signal acquisition, focus determination, application type identification, and policy execution. This improves multi-screen collaboration efficiency, reduces manual operation, enhances compatibility and energy efficiency optimization, and ensures security and user experience continuity.

[0036] Optionally, the target signal includes at least: sensor layer signal, system status signal, and interaction trigger signal.

[0037] Step 102 includes: Step 1021: Calculate the focus weight of each seat based on sensor layer signals, system status signals, and interactive trigger signals.

[0038] In this embodiment, sensor layer signals refer to data acquired from sensors inside the vehicle, including occupant posture, eye movement direction, and getting in and out of the vehicle; system status signals refer to status information provided by the vehicle's onboard system, including seat pressure, seat switch signals, CDC control mode, and rest / power-off mode; interaction trigger signals refer to signals triggered by user behavior, including raising a hand in the rear seat, changing the focus seat, and changing the application opening priority.

[0039] The in-vehicle system collects sensor signals, system status signals, and interactive trigger signals from the vehicle's internal bus and inputs these signals into the decision weighting module. Using pre-defined algorithmic rules, such as a gradient weighting model, the system processes the signal data for each seat in parallel to calculate a numerical focus weight. The calculation process comprehensively considers signal type and priority, such as safety level and trigger time, to ensure that the weight accurately reflects the focus state of the seat.

[0040] Step 1022: Select the seat with the highest focus weight as the first seat after the user's focus shifts.

[0041] In this embodiment, the focus weight is a numerical index that represents the priority of each seat in the focus decision; the first seat refers to the seat position with the highest priority after the focus shift.

[0042] The in-vehicle system compares the focus weight values ​​of all seats and identifies the seat with the highest weight. Based on preset arbitration rules, such as default focus transfer logic, the system determines the highest-weighted seat as the first seat. If there are seats with the same weight, the system uses a priority queue, such as based on security level and trigger time order, to ensure that the selection of the first seat is unambiguous.

[0043] Step 1023: Match the corresponding first screen according to the first seat.

[0044] In this embodiment, the in-vehicle system accesses a predefined seat-screen mapping database and retrieves the corresponding screen identifier based on the position information of the first seat. The in-vehicle system executes screen control commands, such as waking up the target screen or adjusting the display mode, to ensure that the first screen is correctly associated with the first seat. The matching process considers screen status, such as on / off status and availability, to optimize the display effect.

[0045] This application embodiment achieves automatic shift of entertainment content focus based on user location and vehicle status by automatically calculating focus weight, determining the highest priority seat, and matching the corresponding screen. This improves multi-screen collaboration efficiency, reduces manual operation, and ensures a continuous user experience.

[0046] Optionally, the sensor layer signals include at least: seat occupancy status data and door status change data. The system status signals include at least: vehicle scene mode data. The interaction trigger signals include at least: driver's gaze direction and posture data, and the position and behavior data of the occupants.

[0047] Step 1021 includes: inputting the driver's line of sight, the occupant's position and behavior data, the seat occupancy status data, the vehicle scene mode data, and the door status change data into a weighted prediction model to obtain the focus weight of each seat becoming the first seat.

[0048] In this embodiment, the sensor layer signal refers to the raw data stream acquired from physical sensors within the cabin, used to monitor changes in the vehicle's internal environment. Seat occupancy status data represents binary or pressure value information indicating whether a seat is occupied by a passenger, while door status change data represents a time-series record of door opening and closing events, such as signals output by door open / close sensors.

[0049] The in-vehicle system collects real-time data on seat occupancy status and door status changes using seat pressure sensors and door open / close sensors. Seat pressure sensors detect pressure changes on the seat, generating occupancy status data; door open / close sensors monitor door opening and closing actions, generating status change data. The in-vehicle system integrates this data into sensor-layer signals for subsequent focus weight calculations, ensuring the data accurately reflects passenger distribution and entry / exit behavior within the cabin.

[0050] System status signals refer to the operating status information obtained from the vehicle control in-vehicle system, reflecting the current configuration or mode of the cockpit. Vehicle scene mode data represents specific operating modes defined by the cockpit controller, such as rest mode, movie viewing mode, or power-on mode when away from the vehicle. These modes affect screen resource allocation and focus shifting strategies.

[0051] The in-vehicle system obtains vehicle scene mode data from the CDC cockpit controller interface, which identifies the currently active scene mode in the cockpit. The in-vehicle system analyzes this data to determine whether to allow the flow of entertainment content, such as enabling multi-screen interaction in rest mode. System status signals serve as decision inputs to ensure that focus shifts are synchronized with the vehicle's operating mode, avoiding conflicts or unauthorized operations.

[0052] Interactive trigger signals refer to passenger-initiated behaviors or status information acquired from the monitoring in-vehicle system, used to trigger focus shift events. Driver gaze direction and posture data represent the coordinate information of the driver's eye gaze direction and body posture, while in-vehicle occupant position and behavior data represent the position coordinates and action events of other passengers, such as raising a hand or moving.

[0053] The in-vehicle system uses DMS and OMS sensors to collect data on the driver's gaze direction and posture, as well as the position and behavior data of occupants. The DMS sensor tracks the driver's eye movements and posture to generate gaze direction data; the OMS sensor monitors the position and behavior of other passengers, generating position and behavior data. The in-vehicle system categorizes this data into interaction trigger signals to identify focus shift needs, such as triggering weighted calculations when a passenger raises their hand.

[0054] A weighted prediction model is a computational module based on machine learning or a rule engine, used to analyze multi-source input data and output numerical weights. Focus weight represents the priority score of each seat as a user's focus target; a higher value indicates that the seat is more likely to become the focus target.

[0055] The in-vehicle system takes driver's line-of-sight direction, passenger position and behavior data, seat occupancy status data, vehicle scene mode data, and door status change data as inputs and transmits them to the weight prediction model. The weight prediction model applies predefined algorithms, such as gradient boosting decision trees or rule sets, to calculate the focus weight for each seat. Based on the output weights, the in-vehicle system determines the focus transfer target, for example, prioritizing screen resources for high-weight seats, thus achieving automated focus arbitration.

[0056] This application's embodiments implement dynamic cockpit focus determination based on multi-source signals, automatically handling changes in user position and vehicle status to ensure seamless transitions of entertainment content. This improves multi-screen collaboration efficiency, reduces manual operation, enhances the continuity and security of the user experience, and optimizes energy efficiency and compatibility.

[0057] Optionally, the weight prediction model is trained through the following steps: Step 201: Normalize the obtained sample driver's line of sight direction, sample passenger position and behavior data, sample seat occupancy status data, sample vehicle scene mode data and sample door status change data to obtain a sample dataset.

[0058] In this embodiment, the sample driver's gaze direction refers to data collected by the driver monitoring vehicle system regarding the driver's eye gaze direction, used to determine the driver's focus of attention. Sample occupant position and behavior data refers to passenger position and movement information collected by the occupant monitoring vehicle system, such as raising hands or moving. Sample seat occupancy status data refers to information on whether a seat is occupied, detected by seat pressure sensors. Sample vehicle scene mode data refers to the current vehicle operating mode provided by the cockpit controller, such as rest mode or "power on while off" mode. Sample door status change data refers to door opening and closing event information detected by door sensors. Normalization is a data standardization method that converts data from different sources and with different dimensions into a unified numerical range to eliminate data bias and improve model training efficiency.

[0059] First, sample driver gaze direction, occupant position and behavior data, seat occupancy status data, vehicle scene mode data, and door status change data are acquired from onboard sensors and controllers. This data may originate from DMS, OMS, seat pressure sensors, CDC cockpit controller, and door modules. Then, the onboard system normalizes this data, for example using min-max scaling or Z-score normalization, mapping all data values ​​to between 0 and 1 or within a standard normal distribution. After processing, the onboard system generates a standardized sample dataset containing a uniform format for all input features, ensuring data consistency and comparability, and providing high-quality input for subsequent model training.

[0060] Step 202: Input the sample dataset into multiple gradient boosting decision tree models for training, and calculate the shared weights among the various gradient boosting decision tree models.

[0061] In this embodiment, the gradient boosting decision tree model is a machine learning algorithm that improves the accuracy and robustness of the model by iteratively constructing multiple decision trees and combining their prediction results. Shared weights refer to numerical values ​​used to represent the degree of parameter sharing among models during the training of multiple gradient boosting decision tree models, with the aim of optimizing the model ensemble effect.

[0062] The obtained sample dataset is used as input and fed into multiple gradient boosting decision tree models for training. Each model independently learns data features, such as predicting user focus weights or seat priorities. During training, the in-vehicle system calculates shared weights among the various gradient boosting decision tree models, which typically involves evaluating the correlation between models or determining weight allocation through cross-validation. After calculation, the in-vehicle system records these shared weights for subsequent model optimization steps, ensuring that the models can effectively combine the strengths of each model during integration, thereby improving overall prediction performance.

[0063] Step 203: Adjust the loss function of the multiple gradient boosting decision tree models according to the shared weights to obtain a weight prediction model composed of multiple trained gradient boosting decision tree models.

[0064] In this embodiment, the loss function is a function used in machine learning models to measure prediction error, and the model parameters are optimized by minimizing the loss function. The weight prediction model refers to an ensemble model composed of multiple trained gradient boosting decision tree models, used to predict user focus weights or decision priorities based on input data.

[0065] The in-vehicle system adjusts the loss function of multiple gradient boosting decision tree models based on the calculated shared weights. This typically involves adding weight terms to the loss function, such as through weighted averaging or regularization, to make the model focus more on the parts with higher shared weights during training. The in-vehicle system then retrains or fine-tunes these models based on the adjusted loss function, ensuring they work together and reducing overfitting. Finally, the in-vehicle system combines these trained gradient boosting decision tree models into an integrated weight prediction model that accurately outputs user focus weights for intelligent decision-making in multi-screen in-vehicle systems.

[0066] This application's embodiments, through data normalization, multi-model training, and loss function optimization, construct an efficient weight prediction model for the in-vehicle system. This model accurately determines the user's focus and seat priority within the vehicle, enabling automatic flow of entertainment content across multiple screens. This improves the intelligence and automation of multi-screen interaction, reduces manual operation, enhances the continuity of user experience and the compatibility of the in-vehicle system, while also optimizing energy efficiency and safety.

[0067] Optionally, step 103 includes: Step 1031: Identify the application type of the application displayed on the second screen.

[0068] In this application embodiment, application type refers to the category of an application in an in-vehicle multi-screen system based on its functions and resource consumption characteristics, such as exclusive application or copyable application. Exclusive application requires the use of a single screen resource, while copyable application supports multi-screen synchronous operation.

[0069] The in-vehicle system analyzes the applications currently displayed on the second screen using an application type recognition module. The system categorizes applications based on their process characteristics and functionalities; for example, it detects whether an application is a screen mirroring or streaming application and labels it as exclusive, or whether it is an online video platform and labels it as reproducible. The in-vehicle system uses predefined rules and algorithms to perform the classification, ensuring the recognition process is accurate and consistent.

[0070] Step 1032: Determine a screen transition strategy that matches the application type of the application.

[0071] In this embodiment, the screen transition strategy refers to a set of rules defined by the in-vehicle system based on the application type, used to manage the migration or duplication of applications between different screens. The strategy includes methods such as application mirroring, application multi-instance, or application remapping.

[0072] Based on the identified application type, the in-vehicle system selects a matching flow strategy from its policy library. For reproducible applications, the system employs a mirroring synchronization strategy, allowing the application to be displayed and operated simultaneously on multiple screens. For exclusive applications, the system uses a process migration strategy, including pausing the original process, rebinding the hardware interface, or re-initiating screen mirroring to the target screen. The in-vehicle system ensures seamless strategy execution to maintain a continuous user experience.

[0073] This application's embodiments can automatically identify application types and apply corresponding flow strategies, enabling intelligent migration and synchronization of entertainment content in in-vehicle multi-screen environments. This improves multi-screen collaboration efficiency, reduces manual user operations, enhances compatibility and energy efficiency, and optimizes security and resource allocation through dynamic focus management.

[0074] Optionally, step 1031 includes: Step 10311: Detect the process characteristics and display mode of the application displayed on the second screen.

[0075] In the embodiments of this application, process characteristics refer to the execution characteristics of an application during runtime, including states such as parallel running or single-line running; display mode refers to the way the application is presented on the screen, such as single-screen mode or multi-screen mode.

[0076] The in-vehicle system monitors the running status of applications on the second screen, extracting their process characteristics and display mode parameters. The system calls the process management interface to obtain parallel or single-line execution data of the application, and simultaneously reads the current screen configuration information from the display controller to determine whether the application is exclusively displayed on a single screen or shared across multiple screens.

[0077] Step 10312: If the process characteristics are parallel operation and the display mode is single-screen mode, the application type is determined to be a reproducible application type.

[0078] In the embodiments of this application, parallel execution means that the application can be executed in multiple threads or processes at the same time; single-screen mode means that the application displays content on only one screen.

[0079] The in-vehicle system analyzes the acquired process characteristics and display mode data. When the process characteristics indicate parallel operation and the display mode is single-screen, the in-vehicle system performs logical judgment and marks the application as a reproducible application type. The in-vehicle system updates the application type database and records this classification result for subsequent workflow decisions.

[0080] Step 10313: When the process characteristic is parallel running and the display mode is multi-screen mode, the application type is determined as an application type that can be opened in multiple instances.

[0081] In this application embodiment, multi-screen mode means that the application supports simultaneous display or interaction on multiple screens.

[0082] Based on the detection results, when the process characteristics are parallel operation and the display mode is multi-screen, the vehicle system triggers a classification algorithm to identify the application type as an application that can be run in multiple instances. The vehicle system stores this classification information in the application management module to ensure the initialization of the multi-screen asynchronous operation process.

[0083] Step 10314: If the process characteristic is single-line operation and the display mode is single-screen mode, the application type is determined to be an exclusive application type.

[0084] In this embodiment of the application, single-line execution means that the application only supports execution of a single process or thread.

[0085] Based on the input data, when the process is characterized by single-line operation and the display mode is single-screen, the vehicle system executes type determination logic to identify the application type as an exclusive application. The vehicle system then passes this result to the application execution layer for subsequent process migration or resource remapping processing.

[0086] This application embodiment achieves accurate identification and classification of application types in the in-vehicle multi-screen system. The in-vehicle system can automatically distinguish between copyable, multi-openable, and exclusive applications based on process characteristics and display modes, providing accurate input for subsequent multi-screen switching, improving the efficiency and compatibility of intelligent allocation of in-cabin entertainment content, and reducing manual intervention by users.

[0087] Optionally, the application types include: copy application types, multi-instance application types, and exclusive application types.

[0088] Step 1032 includes: Step 10321: If the application type is a copyable application type, the screen transition strategy is determined to start the multi-screen mirror display mode.

[0089] In this application embodiment, the replicable application type is an application classification, referring to application content that can be simultaneously displayed and operated on multiple screens without requiring independent processes or exclusive resources. Screen transition strategy is a set of rules defined by the in-vehicle system to manage the transfer and display of application content between screens. Multi-screen mirroring display mode is a display technology that replicates the same application content to multiple screens in real time, achieving synchronous operation and consistent display.

[0090] The in-vehicle system first identifies the application type as a copyable application. Based on predefined rules, the system sets the screen transition strategy to initiate multi-screen mirroring mode. The system then performs the multi-screen mirroring operation, synchronously copying the application content to the target screens, ensuring all screens display the same content and support synchronous interaction. The system monitors the mirroring process, adjusting the resolution to suit different screen sizes and maintain display consistency.

[0091] Step 10322: If the application type is a multi-instance application type, the screen transition strategy is determined to start a multi-process concurrent running mode.

[0092] In this application embodiment, the "multi-instance application type" is an application classification, referring to an application that supports multiple independent instances running simultaneously, each instance operating on a separate screen with no interference between processes. The multi-process concurrent running mode is a vehicle system operating state in which multiple independent processes of the same application execute simultaneously, each managing screen resources and user interaction.

[0093] The in-vehicle system detected that the application type allows for multiple instances. Based on its configuration logic, the system determines the screen transition strategy to launch a multi-process concurrent execution mode. The system creates new process instances of the application and allocates independent resources to each screen. The system coordinates the concurrent execution of multiple processes to ensure independent display and operation on each screen, avoiding process conflicts.

[0094] Step 10323: If the application type is an exclusive application type, the screen transition strategy is determined to pause the current process and remap it to the first screen.

[0095] In this embodiment, the exclusive application type is an application classification, referring to an application that requires exclusive use of specific screen resources during runtime and cannot be displayed or operated on other screens simultaneously. The first screen is the target display device designated by the in-vehicle system, used for remapping application content. Remapping is a technical process that transfers the application process from the original screen to a new screen and rebinds the hardware interface.

[0096] The in-vehicle system determines that the application is an exclusive application. The system then sets its screen transition strategy to pause the current process and remap it to the first screen. The system pauses the application's execution on the original screen, releasing occupied resources. Next, the system performs the remapping operation, redirecting the application process to the first screen and reinitializing the hardware interface and display protocol. Once the system verifies successful mapping, it resumes the application's execution on the target screen.

[0097] This application embodiment achieves intelligent flow of application content in a multi-screen environment through in-vehicle system application type recognition and policy execution, thereby improving screen resource utilization, user experience continuity and operational efficiency, while reducing the need for manual intervention.

[0098] Optionally, the method further includes: when a passenger in the front passenger seat and the rear seat actively triggers a signal, adjusting the first seat based on the time of the trigger signal and the preset permissions of the passenger in the front passenger seat and the rear seat.

[0099] In this embodiment of the application, the front passenger seat refers to the seat next to the driver in the vehicle, the rear seat refers to the seat area at the rear of the vehicle, and the passenger-initiated signal is an electronic signal generated by the passenger through a specific action or behavior, such as raising a hand, looking at the screen, or voice input. These signals are captured by the vehicle sensors and transmitted to the vehicle system for processing.

[0100] The in-vehicle system continuously monitors passenger behavior in the front passenger seat and rear seats by integrating sensor modules such as DMS and OMS. When a passenger performs a preset action, the sensors generate a trigger signal, which the in-vehicle system receives and analyzes in real time to confirm its validity. The in-vehicle system uses signal processing algorithms to filter noise, ensuring that only clear, active trigger signals are identified, thus providing reliable input for subsequent decision-making.

[0101] The in-vehicle system establishes a priority queue based on the timestamp of the triggered signals, processing earlier signals first. Simultaneously, the system retrieves a pre-defined permission database for passengers, comparing the permission levels of the front passenger and rear passengers; for example, the front passenger seat may have a higher security priority. The system applies a decision-making algorithm that integrates time and permission factors, calculates weights, and dynamically adjusts the focus based on the front passenger seat. This might involve shifting focus from the rear seats to the front passenger seat, or expanding the focus to support multi-screen interaction. The adjustment process includes updating the focus seat status, notifying the application execution layer to reallocate resources, and ensuring an uninterrupted user experience.

[0102] This application's embodiments enable the in-vehicle system to automatically detect passenger behavior and intelligently adjust the focus seat based on time and permission factors, achieving seamless transitions and efficient collaboration of multi-screen applications within the vehicle. This improves the automation level of cockpit interaction, reduces manual operation, optimizes resource allocation, and enhances the continuity and security of the user experience.

[0103] Optionally, the step of adjusting the first seat based on the time of the trigger signal and the preset permissions of the passengers in the front passenger seat and the rear seat when a passenger actively triggers the signal is detected includes: Upon detecting active triggering signals from passengers in the front passenger seat and rear seats, the first seat is determined based on the following method: Step 301: If the time interval between the trigger signals of the passengers in the front passenger seat and the rear seats is less than a preset time interval, the front passenger seat is designated as the first seat.

[0104] In this embodiment, the time interval refers to the time difference between two trigger signals, measured by the vehicle system clock module. The preset time interval is a fixed threshold configured in the vehicle system, used to determine whether the signals are close to synchronizing.

[0105] The vehicle system calculates the time difference between the trigger signals from the front passenger seat and the rear seats. If this difference is less than a preset time interval, the system determines the signals are near-synchronous triggers. Based on preset rules, the system sets the front passenger seat as the first seat, as it has a higher priority in the safety hierarchy. The system updates the status of the focus seat and notifies the decision weighting layer and application execution layer to allocate resources.

[0106] Step 302: If the time interval between the trigger signals of the passengers in the front passenger seat and the rear seats is greater than or equal to a preset time interval, the seat with the earliest trigger signal time shall be designated as the first seat.

[0107] In this embodiment, the trigger time refers to the precise timestamp of when the sensor detects the active trigger signal, which is recorded by the vehicle system's time module. The preset time interval is a threshold defined by the vehicle system to distinguish whether the signals are synchronized.

[0108] The vehicle system compares the time difference between the trigger signals from the front passenger seat and the rear seats. If this difference is greater than or equal to a preset time interval, the system determines the signal is asynchronously triggered. The system retrieves the timestamps of all trigger signals and identifies the seat with the earliest trigger time as the first seat. The system updates the priority of the focused seat and triggers the application execution layer to adjust the corresponding screen and application processes.

[0109] Step 303: If there are preset permissions for passengers in the front passenger seat and the rear seats, the seat corresponding to the passenger with the highest preset permission shall be designated as the first seat.

[0110] In this embodiment, preset permissions refer to passenger permission levels pre-configured by the in-vehicle system, such as based on age, seat type, or user-configured priority. Highest permissions refer to the highest level of permission determined by the in-vehicle system according to preset rules (such as security level or user settings).

[0111] The in-vehicle system checks the permission data of passengers in the front passenger seat and rear seats. If preset permission configurations exist, the system compares the permission levels of each seat. The system sets the seat corresponding to the passenger with the highest permission as the first seat and updates the focus decision module. This step ensures that the in-vehicle system can automatically select the optimal seat in the event of a permission conflict, reducing the need for user intervention.

[0112] This application embodiment automatically determines priority seats by real-time detection of passenger trigger signals, time intervals, and permission factors, thereby dynamically allocating screen resources and application processes. This improves the automation level of multi-screen interaction, ensures the continuity and security of content flow, while optimizing energy efficiency and user experience and reducing the need for manual operation.

[0113] Optionally, the method further includes: when the vehicle is started, setting the driver's seat as the default first seat and setting the main screen in front of the driver's seat as the first screen.

[0114] In this embodiment, the in-vehicle system designates the driver's seat as the default first seat. This involves identifying and assigning the driver's seat a priority position within the vehicle cabin. The in-vehicle system uses data from seat sensors, such as pressure sensors or position encoders, to determine the physical position and state of the driver's seat. Based on a predefined set of rules, the in-vehicle system marks the driver's seat as the default focus seat, meaning that in the absence of other triggering conditions, this seat has the highest priority for applying flow decisions. The in-vehicle system updates its internal data structure to record this assignment and ensures that subsequent operations are based on this default setting.

[0115] Optionally, the method further includes: Step 401: Monitor screen application anomalies during screen transition. The screen application anomalies include at least one of the following: signal loss, application blocking, or abnormal screen occupancy.

[0116] In this embodiment, the screen transition process refers to the operation flow of application windows automatically migrating or synchronizing between different display screens in a multi-screen vehicle system. Monitoring refers to the continuous collection and analysis of relevant data by the vehicle system. Screen application anomalies are abnormal states that occur during the operation of the vehicle system, including three types: signal loss, application blocking, and abnormal screen occupancy. Signal loss refers to the phenomenon of interrupted data flow from sensors or controllers. Application blocking refers to the state in which a software process cannot execute normally due to resource conflicts or logical errors. Abnormal screen occupancy refers to the error situation where the display hardware is occupied by an unauthorized or conflicting process.

[0117] The vehicle-mounted system initiates a real-time monitoring mechanism during screen transitions, continuously collecting sensor data streams, application process status, and screen resource allocation information through the anomaly detection module in the decision weight layer. The system employs a parallel processing architecture to simultaneously detect three types of anomalies: signal loss is detected by verifying data packet integrity and transmission intervals; application blocking is identified through process heartbeat detection and resource lock status analysis; and abnormal screen occupancy is detected through screen frame buffer access permission verification. The system compares the monitoring results with preset thresholds; when any abnormal indicator exceeds the safe range, an anomaly flag is immediately triggered and the anomaly type code is recorded.

[0118] Step 402: If an abnormality is detected in the screen application, provide the user with a confirmation interface or automatically return to the previous screen display state.

[0119] In this embodiment, the user confirmation interface is an interactive graphical prompt window generated by the vehicle system, containing an anomaly description and operation options. Automatic rollback refers to the state recovery operation autonomously performed by the vehicle system. The previous screen display status represents the last valid and stable combination of screen content layout and process allocation before the anomaly occurred.

[0120] Upon detecting an application anomaly on the screen, the in-vehicle system selects a handling strategy based on the severity of the anomaly. For recoverable anomalies, the system calls the front-end rendering module to generate a user confirmation interface, which displays an explanation of the anomaly type and provides options to continue the process or cancel the operation. For critical anomalies, the system directly executes an automatic rollback process: first, it pauses the current process; then, it reads the configuration parameters of the previous screen display state from the cache, including the application window position, screen resolution, and process binding relationship; finally, it reinitializes the display hardware through the screen control module and restores the application process to its pre-anomaly state. During execution, the system synchronously updates the state records of the decision weight layer to ensure the accuracy of the focus judgment model after rollback.

[0121] The embodiments of this application establish a complete closed loop for exception handling, which can promptly identify various operational exceptions during multi-screen transitions and adopt differentiated handling strategies based on the exception type.

[0122] In some embodiments, by real-time monitoring of in-vehicle occupant status (passenger analysis: whether they are frequent passengers, passenger age, etc.) and "focus seats" (such as the target position after a passenger moves, the current seat status), combined with vehicle mode, the system determines the flow requirements: display screens (central control, rear seats, front passenger seat, etc.), application display modes, screen launcher modes, etc. (child mode, care mode, application content recommendations, and different font sizes). It identifies application types (exclusive application categories / mirrored categories) and selects mirroring synchronization or process migration strategies; through multi-screen application projection linkage (such as central control screen → rear screen), it achieves seamless switching, ensuring a continuous user experience.

[0123] Based on the above technical principles, this application can effectively determine the cabin scenario and passenger status, providing passengers with an intelligent and automatic multi-screen interactive experience, improving multi-screen collaboration efficiency, and avoiding cumbersome manual operations.

[0124] In some embodiments, refer to Figure 2 A vehicle system architecture diagram for controlling a vehicle screen is provided, wherein: Information acquisition layer S1: DMS (Driver Monitoring System) and OMS (Occupancy Monitoring System) detect passenger position and line of sight; seat pressure sensors determine occupancy status; CDC cockpit controller provides signals for the current scene mode: movie mode, rest mode, and power-on mode when leaving the vehicle. Front and rear door opening / closing signals determine whether there are passengers getting in or out of the vehicle.

[0125] Decision weight layer S2: Focus Seat Determination Module: By comprehensively arbitrarily arbitrarily arbitrarily combining DMS / OMS data, seat occupancy signals, seat door opening and closing signals, etc., the module identifies the priority seat that needs to be served, such as: a rear passenger raising their hand triggering a focus shift; a front passenger getting off and moving to the rear; or the front and rear seats folding and connecting, allowing passengers to move within the cabin. The system determines whether task transfer and application type are required for the current cockpit task: whether each screen is lit; whether there is an application foreground process on the main screen; whether the user focus is on the main screen; and whether the current user focus screen is in a state where application content can be displayed (some national regulations require that application content cannot be displayed on the driver's main display screen while the vehicle is in motion).

[0126] Application type identification module: Based on the application form and process characteristics, it distinguishes between "replicable" (such as online video platforms, local multimedia applications) and exclusive (such as mobile screen mirroring, game streaming, etc.) applications.

[0127] Application Execution Layer S3: Screen Control: Wake-up and expansion of in-vehicle multi-screen (including but not limited to screen activation methods such as screen backlight activation and ceiling-mounted screen expansion). Application Activation: Keep the process of the currently owned application alive, and determine the application window flow method according to the application type: Application Mirroring: Mirror synchronization, mirroring projection for copyable applications, enabling multi-screen synchronous operation; Application Multi-Open: Projecting two windows of the same application process, enabling multi-screen asynchronous operation; Application Screen Remapping: For exclusive applications, the target application rendering process is transferred to the target screen, releasing the original screen resources. In particular, if some application processes are used on other devices, such as LeBao screen casting or mirroring, or streaming Switch hardware windows, consider recasting to the target screen window after disconnection (e.g., when a user carries a mobile device and uses LeBao screen casting, the connection is automatically reconnected and the casting window & screen are redirected when moving from the front row to the back row).

[0128] In some embodiments, the steps of the screen control method are as follows: Step 1, Triggering conditions: The vehicle is powered on, the CDC is in normal activation process, the vehicle system interface is connected to the vehicle's internal bus, and it listens for signals from DMS (Driver Monitoring System), OMS (Occupant Monitoring System), seat sensors, door opening and closing modules, etc., and collects signal data: Step P1: The signal processing module divides the monitored signals into three categories for parallel processing. Step P11, sensor layer signals: such as occupant posture, eye movement direction, whether the passenger is looking at the screen, and whether there is any getting in or out of the vehicle; Step P12, vehicle system status signals: such as seat pressure, seat switch signal, CDC control mode, rest / power-off mode; Step P13, Interactive trigger signals: such as raising hands in the back row, changes in the focus seat, changes in application opening priority, and other behavioral trigger signals.

[0129] Step 2: The CDC decision weight module performs a comprehensive judgment to determine whether the system is in a state where a multi-screen transition mechanism can be triggered and whether a multi-screen transition is required. Step M1, User Focus Determination: Is there a passenger raising their hand or looking at the screen? Has the seat occupancy status changed? Are there any driving restrictions (such as the inability to operate the entertainment screen while the driver is in the driver's seat)?

[0130] Step M2, Focus Seat and Screen Focus Determination Model: Figure 3 This is an example of a screen layout within the scope of this application.

[0131] The vehicle may include: a remote screen arrangement p1, a central control screen arrangement p2, a passenger-side screen arrangement p3, a rear ceiling-mounted screen p4, left and right headrest screens p5, and a right rear headrest screen p6.

[0132] according to Figure 4 This application will divide the layout of all commonly used vehicle positions inside the cabin into multiple focal rules. Figure 4 For example, not all detailed focus positions are considered. When the focus position changes, the CDC weight decision module will be triggered to perform multi-screen interaction judgment. For example, in Figure 4 In the view at the top right, if the focus is on the front row, then the focus screen is the central control screen and the remote screen; Figure 4 In the top left view, the focus is on the passenger side, and the focused screen is the passenger screen; Figure 4 In the lower left view, the focus position is the rear row, and the focus screen is the rear entertainment screen; Figure 4 In the view at the bottom right, the focus position is located in a separate position in the back row, and the focus screen is the headrest screen.

[0133] Example of arbitration rules: The default focus is on the driver; if the passenger or rear passenger raises their hand and looks at the screen, the focus will switch. If a single passenger is detected getting off and then getting back on (door opens + seat pressure occupancy + OMS), the focus shifts; If the passenger before the focus switch is still active (multiple passengers exist), the focus expands, and it is determined whether the application status should be multi-opened.

[0134] Gradient focus judgment weight: Furthermore, this application provides a gradient focus judgment weight. When some signals are missing (e.g., the seat sensor does not respond, the vehicle configuration does not have the sensor, etc.), a secondary confirmation prompt (voice / pop-up window) will be given to the user before the focus transfer is executed. The weight model is passivated and the automatic triggering logic is optimized based on the similar profiles of all existing terminal devices and the decision of the conditional user.

[0135] The application center processes application processes according to the rules issued by the weighting module: If it is a copyable application, start multi-screen mirroring (resolution adapts to the target screen). If the application can be run in multiple instances, enable application multi-instance (each application interacts with an independent process). If it is an exclusive application, pause the original process and remap it to the target screen hardware interface (re-initiate screen casting or switch streaming protocols, etc.). For standalone applications that occupy multiple screens, extend the screen rendering canvas to multiple screens (such as a car-wide KTV control panel).

[0136] The exception handling process is as follows: In step K1, if an application process is already running on the target screen, it is impossible to determine whether it needs to be kept alive (the focus area is shifted but shrunk, making it impossible to determine whether the application process needs to follow the focus). A second confirmation feedback can be given to the user. Step K2: If application remapping fails, provide the option to manually re-execute the task on the corresponding focus screen; Step K3: Multiple people simultaneously trigger focus grabbing.

[0137] Scenario: The passenger in the back seat and the front passenger in the front seat both raise their hands or look at the screen.

[0138] Processing strategy: Introduce a priority queue and process the following in the following order: Step F1, high safety level (passenger seat preferred, rear seats preferred); Step F2, triggering time sequence; Step F3, permission configuration (child seat preemption is disabled by default); Step F4: If the focus is unclear, a pop-up window will prompt the user to select a focus target.

[0139] Based on the foregoing embodiments, this application provides a screen control device, which includes various units and modules included in each unit. It can be implemented by a processor in a vehicle; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0140] Figure 5 This is a schematic diagram of the composition structure of a screen control device provided in an embodiment of this application, as shown below. Figure 5 As shown, the screen control device 40 includes: Acquisition module 401 is used to acquire a target signal, the target signal being a signal generated based on user focus shift; The determining module 402 is used to determine, based on the target signal, the first seat after the user focus shifts and the first screen corresponding to the first seat; determine the second screen before the user focus shifts, and the screen flow strategy matching the application displayed on the second screen; The flow module 403 is used to flow the display content of the application displayed on the second screen to the first screen according to the screen flow strategy.

[0141] Optionally, the target signal includes at least: sensor layer signal, system status signal, and interaction trigger signal; The determining module 402 is further configured to: calculate the focus weight of each seat based on sensor layer signals, system status signals, and interaction trigger signals; select the seat with the highest focus weight as the first seat after the user's focus is transferred; and match the corresponding first screen according to the first seat.

[0142] Optionally, the sensor layer signals include at least: seat occupancy status data and door status change data; the system status signals include at least: vehicle scene mode data; and the interaction trigger signals include at least: driver's line of sight and posture data, and the position and behavior data of the occupants. The determining module 402 is further configured to: input the driver's line of sight, the occupant's position and behavior data, the seat occupancy status data, the vehicle scene mode data and the door status change data into the weight prediction model to obtain the focus weight of each seat becoming the first seat.

[0143] Optionally, the device further includes: a training module, configured to: normalize the acquired sample driver's line of sight, sample occupant position and behavior data, sample seat occupancy status data, sample vehicle scene mode data, and sample door status change data to obtain a sample dataset; input the sample dataset into multiple gradient boosting decision tree models for training, calculate the shared weights among the various gradient boosting decision tree models; and adjust the loss function of the multiple gradient boosting decision tree models according to the shared weights to obtain a weight prediction model composed of multiple trained gradient boosting decision tree models.

[0144] Optionally, the determining module 402 is further configured to: identify the application type of the application displayed on the second screen; and determine a screen transition strategy that matches the application type of the application.

[0145] Optionally, the application types include: copy application types, multi-instance application types, and exclusive application types; The determining module 402 is further configured to: determine the screen transition strategy to start a multi-screen mirror display mode when the application type is a copyable application type; determine the screen transition strategy to start a multi-process concurrent running mode when the application type is a multi-instance application type; and determine the screen transition strategy to pause the current process and remap it to the first screen when the application type is an exclusive application type.

[0146] Optionally, the determining module 402 is further configured to: detect the process characteristics and display mode of the application displayed on the second screen; if the process characteristics are parallel running and the display mode is single-screen mode, determine the application type as a copyable application type; if the process characteristics are parallel running and the display mode is multi-screen mode, determine the application type as a multi-instance application type; if the process characteristics are single-line running and the display mode is single-screen mode, determine the application type as an exclusive application type.

[0147] Optionally, the determining module 402 is further configured to: adjust the first seat based on the time of the trigger signal and the preset permissions of the passengers in the front passenger seat and the rear seat when a trigger signal is detected from the front passenger seat and the rear seat.

[0148] Optionally, the determining module 402 is further configured to: determine the first seat based on the following methods when active triggering signals from passengers in the front passenger seat and the rear seat are detected: if the time interval between the triggering signals from passengers in the front passenger seat and the rear seat is less than a preset time interval, the front passenger seat is designated as the first seat; if the time interval between the triggering signals from passengers in the front passenger seat and the rear seat is greater than or equal to the preset time interval, the seat with the earliest triggering time is designated as the first seat; if passengers in the front passenger seat and the rear seat have preset permissions, the seat corresponding to the passenger with the highest preset permission is designated as the first seat.

[0149] Optionally, the determining module 402 is further configured to: when the vehicle is started, designate the driver's seat as the default first seat and designate the main screen corresponding to the driver's seat as the first screen.

[0150] Optionally, the transition module 403 is further configured to: monitor screen application anomalies during screen transition, the screen application anomalies including at least one of the following: signal loss, application blocking, screen occupancy anomalies; and, in the event of detecting the screen application anomalies, provide a user confirmation interface or automatically return to the previous screen display state.

[0151] This application embodiment achieves intelligent flow of application content based on user location and vehicle status through automated signal acquisition, focus determination, application type identification, and policy execution. This improves multi-screen collaboration efficiency, reduces manual operation, enhances compatibility and energy efficiency optimization, and ensures security and user experience continuity.

[0152] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0153] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, the personal information processing rules are clearly informed through signs / information, and authorization is obtained through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0154] It should be noted that, in the embodiments of this application, if the above-described screen control method 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. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a vehicle (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0155] This application provides a vehicle including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0156] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0157] This application provides a computer program including computer-readable code, wherein when the computer-readable code is run in a vehicle, a processor in the vehicle executes some or all of the steps in the above-described method.

[0158] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0159] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0160] It should be noted that, Figure 6 This is a schematic diagram of a hardware entity of a vehicle in an embodiment of this application, such as... Figure 6 As shown, the hardware entity of the vehicle 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: The processor 701 typically controls the overall operation of the vehicle 700.

[0161] Communication interface 702 enables the vehicle to communicate with other terminals or servers via a network.

[0162] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) from the processor 701 and various modules in the vehicle 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, communication interface 702, and memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 700 includes one or more cores.

[0163] It should be noted that the vehicle may include multiple processors 701, and each processor 701 can interact with each other through aggregation communication methods such as all-to-all, all-gather, or all-reduce. These processors 701 can be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors can also be single-core or multi-core processors. The processor can be a combination of a CPU and hardware chips. These hardware chips can be ASICs, PLDs, or combinations thereof. The PLDs can be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0164] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0165] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0166] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0167] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0168] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0169] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another vehicle system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0170] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0171] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0172] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0173] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0174] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes 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.

Claims

1. A method for controlling a screen, characterized in that, The method includes: Acquire a target signal, which is a signal generated based on user focus shift; Based on the target signal, determine the first seat after the user's focus shifts and the first screen corresponding to the first seat; Determine the second screen before the user's focus shifts, and the screen transition strategy that matches the application displayed on the second screen; According to the screen transition strategy, the display content of the application shown on the second screen is transitioned to the first screen.

2. The method according to claim 1, characterized in that, The target signal includes at least: sensor layer signal, system status signal, and interactive trigger signal; The step of determining the first seat after the user's focus shift and the first screen corresponding to the first seat based on the target signal includes: Based on sensor layer signals, system status signals, and interactive trigger signals, the focus weight of each seat is calculated. The seat with the highest focus weight will be the first seat after the user's focus shifts. The first screen is matched according to the first seat.

3. The method according to claim 2, characterized in that, The sensor layer signals include at least: seat occupancy status data and door status change data; the system status signals include at least: vehicle scene mode data; the interaction trigger signals include at least: driver's line of sight and posture data, and the position and behavior data of the occupants in the vehicle. The calculation of the focus weight for each seat based on sensor layer signals, system status signals, and interaction trigger signals includes: The driver's line of sight, the passenger's position and behavior data, the seat occupancy status data, the vehicle scene mode data, and the door status change data are input into the weight prediction model to obtain the focus weight of each seat becoming the first seat.

4. The method according to claim 3, characterized in that, The weight prediction model is trained through the following steps: The obtained sample driver's line of sight direction, sample passenger position and behavior data, sample seat occupancy status data, sample vehicle scene mode data and sample door status change data are normalized to obtain the sample dataset. The sample dataset is input into multiple gradient boosting decision tree models for training, and the shared weights between the various gradient boosting decision tree models are calculated. By adjusting the loss function of multiple gradient boosting decision tree models based on shared weights, a weight prediction model composed of multiple trained gradient boosting decision tree models is obtained.

5. The method according to claim 1, characterized in that, Determining a screen transition strategy that matches the application displayed on the second screen includes: Identify the application type of the application displayed on the second screen; Determine a screen transition strategy that matches the application type of the application.

6. The method according to claim 5, characterized in that, The application types include: application types that can be copied, application types that can be run in multiple instances, and exclusive application types. The process of determining a screen transition strategy that matches the application type of the application includes: When the application type is a copyable application type, the screen transition strategy is determined to start the multi-screen mirror display mode; When the application type is a multi-instance application type, the screen transition strategy is determined to start a multi-process concurrent running mode; When the application type is an exclusive application type, the screen transition strategy is determined to pause the current process and remap it to the first screen.

7. The method according to claim 6, characterized in that, The identification of the application type of the application displayed on the second screen includes: Detect the process characteristics and display mode of the application displayed on the second screen; When the process is characterized as running in parallel and the display mode is single-screen mode, the application type is determined to be a reproducible application type. When the process characteristics are parallel running and the display mode is multi-screen mode, the application type is determined to be an application type that can be run in multiple instances; When the process is characterized as running in a single line and the display mode is a single-screen mode, the application type is determined to be an exclusive application type.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: If a passenger in the front passenger seat or the rear seat actively triggers a signal, the first seat is adjusted based on the time of the trigger signal and the preset permissions of the passenger in the front passenger seat or the rear seat.

9. The method according to claim 8, characterized in that, The step of adjusting the first seat based on the timing of the trigger signal and the preset permissions of the passengers in the front passenger seat and the rear seat when a passenger actively triggers the signal is detected includes: Upon detecting active triggering signals from passengers in the front passenger seat and rear seats, the first seat is determined based on the following method: If the time interval between the trigger signals of the passengers in the front passenger seat and the rear seats is less than a preset time interval, the front passenger seat shall be designated as the first seat. If the time interval between the trigger signals of passengers in the front passenger seat and the rear seats is greater than or equal to a preset time interval, the seat with the earliest trigger signal time shall be designated as the first seat. If there are preset permissions for passengers in the front passenger seat and the rear seats, the seat corresponding to the passenger with the highest preset permission will be designated as the first seat.

10. The method according to any one of claims 1-7, characterized in that, The method further includes: When the vehicle is started, the driver's seat is set as the default first seat, and the main screen in front of the driver's seat is set as the first screen.

11. The method according to any one of claims 1-7, characterized in that, The method further includes: During screen transition, monitor screen application anomalies, which include at least one of the following: signal loss, application blocking, or abnormal screen occupancy. If an abnormality is detected in the screen application, a confirmation interface is provided to the user or the screen is automatically returned to the previous display state.

12. A screen control device, characterized in that, include: An acquisition module is used to acquire a target signal, which is a signal generated based on user focus shift; The determining module is used to determine the first seat after the user's focus shifts and the first screen corresponding to the first seat based on the target signal; Determine the second screen before the user's focus shifts, and the screen transition strategy that matches the application displayed on the second screen; The flow module is used to flow the display content of the application displayed on the second screen to the first screen according to the screen flow strategy.

Images