Multi-user management for vehicle operating systems

Abstract

A computing device comprising a memory configured to store an instance of a vehicle operating system ("VOS," where the instance of the vehicle operating system facilitates concurrent access by multiple user profiles) and processing circuitry configured to execute the instance of the VOS. The VOS may invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate multiple user profiles with multiple displays communicatively coupled to the vehicle head unit. The VOS may present, via the displays, user interfaces that provide user experiences based at least in part on a user profile associated with each display.

Description

MULTI-USER MANAGEMENT FOR VEHICLE OPERATING SYSTEMS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 587,524, filed 3 October 2023, the entire contents of which is incorporated herein by reference.BACKGROUND

[0002] A vehicle head unit (which may be referred to as an infotainment system) may be configured to execute a vehicle operating system to facilitate control of, to provide a few examples, entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as vehicle systems, such as heating, ventilation, and air conditioning (HVAC) systems, lighting systems, and seat control systems (including heating and / or cooling, seat adjustment, etc.). Vehicle operating systems may enable a single user profile to access a given instance of the vehicle operating system, where the single user profile is typically the operator of the vehicle. While the instance of the vehicle operating system may support multiple user profiles, the instance of the vehicle operating system may only allow a single user profile of the multiple user profiles to access (or in other words “log into”) the instance of the vehicle operating system. The instance of the vehicle operating system may limit access to a single user profile to ensure that the operator of the vehicle does not become distracted by other user profile behavior while operating the vehicle.SUMMARY

[0003] In general, various aspects of the techniques set forth in this disclosure are directed to a single instance of a vehicle operating system that provides concurrent multi-user support. Rather than limit access to a single user profile for the single instance of the vehicle operating system, a single instance of the vehicle operating system described in this disclosure may allow multiple user profiles to access the single instance of the vehicle operating system. As vehicles have begun integrating increasingly more displays in a cabin of the vehicle, more users may safely interface with the vehicle operating system without distracting an operator of the vehicle (considering that in some examples, the operator either has limited view of these displays or has no direct view of these displays, which may be disposed behind the operator for rear seat passengers). As such, multiple users associated with multiple user profiles may access the vehicle operating systems and interact with the vehicle to control various functionality provided via the vehicle head unit, such as entertainment, information,navigation, and voice calls as well as various vehicle systems (which may be, to some extent, dependent on the multiple user locations within the vehicle). The single instance of the vehicle operating system may provide login and logout functionality for multi-user, multidisplay environments of a vehicle while maintaining a consistent view of user profile assignment information. In this way, the vehicle operating system may provide different user experiences to each display within a vehicle based on data, preferences, configurations, etc. associated with a user profile logged on to a display.

[0004] The multiple users may also interface with the vehicle operating system to jointly coordinate activities among the multiple users, such as sharing content between the multiple users, reviewing content viewed by other users of the multiple users, control audio playback between the multiple users (such as change audio playback volume, coordinate on playlists, etc.), messaging between the multiple users, collaborating by the multiple users jointly on navigation directions, and the like. In some instances, the multiple users may use gestures, such as a swipe gesture, a pinch gesture, and a tap gesture, to indicate sharing of such content, which may allow for intuitive control of sharing between the multiple users.

[0005] As a result, various aspects of the techniques described in this disclosure may facilitate a better user experience when traveling in the vehicle while still preserving safety concerns with distracting the operator of the vehicle. As a result of permitting multiple user profiles to access the vehicle operating system, the vehicle operating system may tailor the user experience to each individual user profile allowing for preferences to be applied that are specific to each individual user profile. The vehicle operating system may also allow the multiple users to coordinate on activities (as noted above) that may improve the user experience while traveling in the vehicle. Given that the additional displays (which may be separate from a main display of the vehicle head unit) may be located in the cabin where the operator of the vehicle cannot directly see the content being presented, the vehicle operating system may permit increased permissions in terms of access to content while also potentially limiting any distractions to the operator.

[0006] In addition, various aspects of the techniques may enable the single vehicle operating system to define different user experience restrictions per occupant zone and possibly display type (e.g., virtual or physical display). Each occupant zone may be associated with an occupant zone identifier that identifies a particular occupant zone of a plurality of occupant zones (e.g., a driver occupant zone, a front passenger occupant zone, a backseat passenger occupant zone, etc.). Different user experience restrictions may be defined for each occupant zone identifier and also potentially for a display type (where passenger virtual displays, suchas front passenger virtual displays that share the same underlying physical display used for the driver occupant virtual display, may receive less stringent user experience restrictions compared to, as one example, the driver occupant zone). Allowing different user experience restrictions may allow occupants (other than the driver) to safely interact with the single operating system without distracting the driver while driving (or in other operational states, such as an idle state and a parked state).

[0007] In this respect, different occupants of a vehicle may be assigned different user experience restrictions based not only on an occupant zone identifier associated with each of the multiple displays, but also potentially based on a display type (e.g., virtual display or physical display) and potentially a driving state (e.g., a parked state, an idle state, or a driving state). Incorporating these different identifiers, display types, and vehicle states may allow for granular control of presenting applications (which may be non-di straction optimized applications and distraction optimized applications) or other user interfaces via the user interface presented by the single operating system. Such granular control of user experience restrictions may allow for a better user experience depending on occupant zone, display type, and possible vehicle state and better prevent distractions to a driver of the vehicle. As such, the techniques described in this disclosure may improve the user experience for occupants of the vehicle that implements various aspects of the techniques described in this disclosure, while also potentially providing a safer operating experience for the driver by preventing distractions that may result in faulty operation of the vehicle.

[0008] In one example, this disclosure describes a method comprising: executing, by a vehicle head unit included in a vehicle, an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoking a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; presenting, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoking the start function of the API to associate a second user profile with a second display of the plurality of displays; and presenting, via the second display, a second user interface that provides a second user experience based at least in part on the second profile being associated with the second display.

[0009] In another example, this disclosure describes a computing device including a memory configured to store an instance of a vehicle operating system, wherein the instance of thevehicle operating system facilitates concurrent access by multiple user profiles; processing circuitry configured to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoke the start function of the API to associate a second user profile with a second display of the plurality of displays; and present, via the second display, a second user interface that provides a second user experience based at least in part on the second user profile being associated with the second display.

[0010] In another example, this disclosure describes non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: execute an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoke the start function of the API to associate a second user profile with a second display of the plurality of displays; and present, via the second display, a second user interface that provides a second user experience based at least in part on the second user profile being associated with the second display.

[0011] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. l is a block diagram illustrating an example computing system that is configured to provide a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure.

[0013] FIG. 2 is a diagram illustrating an example of a vehicle that includes a computing system configured to execute a vehicle operating system that operates in accordance with various aspects of the single-instance multi-user techniques described in this disclosure.

[0014] FIG. 3 is a diagram illustrating different interaction models with multiple displays including interactions that occur via single instance multi-user models and multi-instance multi-user models in accordance with the vehicle operating system techniques described in this disclosure.

[0015] FIG. 4 is a diagram illustrating an example vehicle that includes a vehicle head unit configured to control audio content in accordance with various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure.

[0016] FIGS. 5 and 6 are diagrams illustrating audio control in a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure.

[0017] FIG. 7 is a block diagram illustrating an example computing device configured to manage user profiles for a single-instance, multi-user vehicle operating system, in accordance with various aspects of the techniques described in this disclosure.

[0018] FIG. 8 is a block diagram illustrating example displays configured to provide graphical user interfaces based at least in part on user profiles.

[0019] FIG. 9 is a flowchart illustrating example operation of the computing system shown in FIG. 1 in executing a vehicle operating system configured to perform various aspects of the techniques described in this disclosure.

[0020] FIG. 10 is a block diagram illustrating a single-instance, multi-user vehicle operating system providing multi-user experiences according to various aspects of the techniques described in this disclosure.

[0021] FIG. 11 is a flowchart illustrating example operation of VOS shown in the example of FIG. 10 in performing various aspects of the techniques described in this disclosure.DETAILED DESCRIPTION

[0022] FIG. l is a block diagram illustrating an example computing system that is configured to provide a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure. As shown in the example of FIG. 1, a computing system 100 includes a computing device 102. Although described with respect to a vehicle, the computing system 100 may be utilized in different contexts, including standalone computing systems (including laptop computers, desktop computers, workstations and the like), gaming systems, cellular telephones (including so-called “smartphones”), media systems (including streaming media systems), audio / visual (A / V) receivers, televisions (including so-called “smart televisions”), smart speakers, smart watches, thermostats(including so-called “smart thermostats”), smart glasses, or any other computing system.

[0023] In any event, computing device 102 may be an example of a vehicle computing device, such as a vehicle head unit. FIG. 1 illustrates only one particular example of computing device 102, and many other examples of computing device 102 may be used in other instances and may include a subset of the components included in example computing device 102 or may include additional components not shown in FIG. 1.

[0024] As further shown in the example of FIG. 1, computing device 102 includes presencesensitive display 112, one or more processors 140, one or more communication units 142, one or more input components 144, one or more output components 146, and one or more storage devices 148, and communication channels 149. Communication channels 149 may interconnect each of the components 112, 140, 142, 146, and / or 148 for inter-component communications (physically, communicatively, and / or operatively) and thereby allow components 112, 140, 142, 146, and 148 to communicate with one another. In some examples, communication channels 149 may include a system bus, a network connection, one or more inter-process communication data structures, or any other components for communicating data (also referred to as information). Although shown as including components 112, 140, 142, 146, and 148, computing device 102 (which may be referred to as “main computing device 102”) may include other components or less components than those shown, where such components may be included in other control units such as a telematic control unit (TCU).

[0025] One or more communication units 142 of computing device 102 may communicate with external devices by transmitting and / or receiving data. For example, computing device 102 may use one or more of communication units 142 to transmit and / or receive radio signals on a radio network such as a cellular radio network. In some examples, communication units 142 may transmit and / or receive satellite signals on a satellite network such as a Global Positioning System (GPS) network. Examples of communication units 142 include a network interface card (e.g. an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and / or receive information. Other examples of communication units 142 may include a controller area network (CAN - operating via CAN bus), short wave radios (e.g., NFC, BLUETOOTH (including BLE)), GPS, 3G, 4G, 5G, and WIFI radios found in mobile devices as well as Universal Serial Bus (USB) controllers and the like.

[0026] One or more input components 144 of computing device 102 may receive input.Examples of input are tactile, audio, kinetic, and optical input, to name only a few examples.Input components 144 of computing device 102 include, in one example, a mouse, keyboard, touchpad, voice responsive system, video camera, buttons, scroll wheel, dial, control pad, a microphone (or, in other words, an audio capture device), or any other type of device for detecting input from a human or machine. Input components 144 may include cameras. In some examples, input component 144 may be a presence-sensitive input component, which may include a presence-sensitive screen, touch-sensitive screen, etc. separate from presencesensitive display 112.

[0027] One or more output components 146 of computing device 102 may generate output. Examples of output are tactile, audio, and video output. Output components 146 of computing device 102, in some examples, include a presence-sensitive screen (possibly separate from presence-sensitive display 112), a sound card, a video graphics adapter card, a speaker, a liquid crystal display (LCD), organic light emitting diode (OLED), or any other type of device for generating tactile, audio and / or visual output to a human or machine.

[0028] In some examples, presence-sensitive display 112 of computing device 102 may include functionality of input component 144 and / or output components 146. In the example of FIG. 1, presence-sensitive display 112 may include a presence-sensitive input (PSI) component 104 (“PSI component 104”), such as a presence-sensitive screen or touch- sensitive screen. In some examples, presence-sensitive input component 104 may detect an object at and / or near the presence-sensitive input component. As one example range, presence-sensitive input component 104 may detect an object, such as a finger or stylus that is within two inches or less of presence-sensitive input component 104. Presence-sensitive input component 104 may determine a location (e.g., an (x,y) coordinate) of the presencesensitive input component at which the object was detected. In another example range, presence-sensitive input component 104 may detect an object two inches or less from presence-sensitive input component 104 and other ranges are also possible. Presencesensitive input component 104 may determine the location of presence-sensitive input component 104 selected by a user’s finger using capacitive, inductive, and / or optical recognition techniques.

[0029] In some examples, presence-sensitive display 112 may also provide output to a user using tactile, audio, or video stimuli as described with respect to output component 146. For instance, presence-sensitive display 112 may include display component 103 that displays a graphical user interface. Display component 103 may be any type of output component that provides visual output, such as described with respect to output components 146. While illustrated as an integrated component of computing device 102, presence-sensitive display112 may, in some examples, be an external component that shares a data or information path with other components of computing device 102 for transmitting and / or receiving input and output. For instance, presence-sensitive display 112 may be a built-in component of computing device 102 located within and physically connected to the external packaging of computing device 102 (e.g., an in-vehicle screen mounted in a dashboard of a vehicle). In another example, presence-sensitive display 112 may be an external component of computing device 102 located outside and physically separated from the packaging of computing device 102 (e.g., a monitor, a projector, etc. that shares a wired and / or wireless data path with an electronic control unit of the vehicle). In some examples, presence-sensitive display 112, when located outside of and physically separated from the packaging of computing device 102, may be implemented by two separate components: a presence-sensitive input component 104 for receiving input and a display component 103 for providing output.

[0030] One or more storage devices 148 within computing device 102 may store information for processing during operation of computing device 102 (e.g., computing device 102 may store data accessed by operating system (OS) 160A and OS 160B during execution at computing device 102). As shown in the example of FIG. 1, one or more storage devices 148 may store a first instance of an operating system 160A (OS 160A) and a second instance of operating system 160B (OS 160B). In some examples, storage device 148 is a temporary memory, meaning that a primary purpose of storage device 148 is not long-term storage. Storage devices 148 of computing device 102 may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art.

[0031] Storage devices 148, in some examples, also include one or more computer-readable storage media. Storage devices 148 in some examples include one or more non-transitory computer-readable storage mediums. Storage devices 148 may be configured to store larger amounts of information than typically stored by volatile memory. Storage devices 148 may further be configured for long-term storage of information as non-volatile memory space and retain information after power on / off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage devices 148 may store program instructions and / or information (e.g., data) associated with OS 160A and / or 160B. Storage devices 148 may include a memory configured to storedata or other information (which is not shown for ease of illustration purposes) associated with OS 160 A and / or OS 160B.

[0032] One or more processors 140 may implement functionality and / or execute instructions associated with computing device 102. Examples of processors 140 include application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configured to function as a processor, a processing unit, a processing device, a controller area network (CAN - operating via a CAN bus), or other processing circuitry. OS 160A and / or OS 160B may be operable (or, in other words, executed) by processors 140 to perform various actions, operations, or functions of computing device 102.

[0033] That is, OS 160A and / or OS 160B may form executable bytecode, which when executed, cause processors 140 to perform specific operations (and thereby causing computing device 102 to become a specific-purpose computer by which to perform) in accordance with various aspects of the techniques described herein. For example, processors 140 of computing device 102 may retrieve and execute instructions stored by storage devices 148 that cause processors 140 to perform the operations described herein that are attributed to OS 160A and / or OS 160B. The instructions, when executed by processors 140, may cause computing device 102 to store information within storage devices 148.

[0034] As described above, computing system 100 may be integrated or otherwise included within a vehicle. The vehicle may include one or more of a bicycle, a tricycle, a unicycle, a motorcycle, an automobile, farm equipment (such as a tractor, combine, etc.), construction equipment (a dump truck, crane, etc.), military vehicle or equipment (a tank, armament, etc.), a truck, a semi-tractor (or, in other words, a semi-trailer), aviation equipment (such as an airplane), nautical equipment (such as a boat, carrier, submarine, etc.), or any other type of vehicle.

[0035] Computing device 102 (which may be, as noted above, referred to as vehicle head unit 102 and also as an infotainment system 102) may be configured to execute a vehicle operating system, such as one or more of OS 160A and 160B (which as a result may also be referred to as vehicle OS 160A - VOS 160A - and VOS 160B), to facilitate control of, to provide a few examples, entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as vehicle systems, such as heating, ventilation, and air conditioning (HVAC) systems, lighting systems, and seat control systems (including heating and / or cooling, seat adjustment, etc.). In some instances, vehicle operating systems may allow a single user profile to access a given instance of the vehicle operating system at once, where the single user profile is typically the operator of the vehicle.

[0036] This vehicle operating system may be referred to as a single-instance, single-user vehicle operating system. That is, a single instance of the vehicle operating system may only allow a single user profile to access the single instance of the vehicle operating system and require a user profile switch in which the single user profile is replaced with another single user profile. In this respect, only a single user profile can access a single instance of the vehicle operating system at any given time.

[0037] To enable multiple concurrent user profiles, processors 140 may execute another instance of the vehicle operating system, which may require additional processors and / or higher processing capacity processors (which are typically more expensive). However, there may be difficulties in enabling efficient communication between both instances of the vehicle operating system such that users associated with the multiple user profiles are unable to share content between one another, thereby potentially limiting the user experience.

[0038] As such, while the instance of the vehicle operating system may support multiple user profiles, the instance of the vehicle operating system may only allow a single user profile of the multiple user profiles to access (or in other words “log into”) the instance of the vehicle operating system. The instance of the vehicle operating system may limit access to a single user profile to ensure that the operator of the vehicle does not become distracted by other user profile behavior while operating the vehicle. By only allowing a single user profile of the multiple user profiles to access or otherwise log into the instance of the vehicle operating system, the instance of the vehicle operating system may not be able to provide a customized user experience to different users operating different displays; thereby, limiting and reducing the quality of user experiences.

[0039] Furthermore, the instance of the vehicle operating system may restrict content for a variety of reasons including safety to prevent driver distraction (e.g., based on an operational state of the vehicle, such as driving, idle, and parked), privacy and security (e.g., by way of user profile restrictions that may include age-based limits, content-type limits, personal information security, etc.), and the like. By allowing only a single user profile of the multiple user profiles to access the instance of the vehicle operating systems, the instance of the vehicle operating system may restrict content of other occupants of the vehicle interfacing with one or more displays that may or may not introduce distractions while operating the vehicle (e.g., a rear seat passenger display may be restricted unnecessarily to restrictions configured for the single user profile that is often associated with the driver rather than the rear seat passenger). These potentially unnecessary restrictions may degrade the user experience provided to other occupants that are not actively operating the vehicle, andthereby potentially unnecessarily impact the user experience provided by the single instance of the vehicle operating system.

[0040] The foregoing restrictions may be considered less granular in the sense that such restrictions apply only to the single user profile that is currently authorized to interact with the vehicle operating system rather than applying unique restrictions based on which display with which each of the multiple user profiles may interface. As vehicles begin to incorporate larger displays, a single physical display may present two or more virtual displays (e.g., a single physical dashboard display for front passengers may include two or more virtual displays - one or more for the front driver or, in other words, operator occupant zone, and one or more virtual displays for a front passenger occupant zone).

[0041] The single instance of the vehicle operating system may provide restrictions for the single user profile that may only be defined based on physical display port numbers, which would apply to the single physical dashboard display despite the display spanning multiple occupant zones and presenting multiple virtual displays. Such restrictions are therefore even less granular as the restrictions do not allow for virtual displays, which may further degrade the user experience (e.g., given that the front passenger may be restricted to whatever restrictions are provided for the front operator occupant zone despite that presentation of content in the front passenger occupant zone may not present sufficient distractions for the operator of the vehicle to warrant such restrictions).

[0042] In accordance with various aspects of the techniques described in this disclosure, computing system 100 may implement a single instance of a vehicle operating system, such as VOS 160A and / or 160B (“VOS 160”), that provides concurrent multi-user support. Rather than limit access to a single user profile for the single instance of VOS 160, a single instance of the VOS 160 described in this disclosure may allow multiple user profiles to access the single instance of VOS 160. As vehicles have begun integrating increasingly more displays, such as supporting presence-sensitive displays 150A-150N (“supporting presence-sensitive displays 150,” which may also be referred to as “displays 150”) in a cabin of the vehicle, more users may safely interface with VOS 160 without distracting an operator of the vehicle (considering that in some examples, the operator either has limited view of these displays 150 or has no direct view of these displays 150, which may be disposed behind the operator for rear seat passengers). As such, multiple users associated with multiple user profiles may access VOS 160 and interact with computing device 102 to control various functionality provided via computing device 102, such as entertainment, information, navigation, and voice calls as well as various vehicle systems (which may be, to some extent, dependent onthe multiple user locations within the vehicle).

[0043] The multiple users may also interface with VOS 160 to jointly coordinate activities among the multiple users, such as sharing content between the multiple users, reviewing content viewed by other users of the multiple users, control audio playback between the multiple users (such as change audio playback volume, coordinate on playlists, etc.), messaging between the multiple users, collaborating by the multiple users jointly on navigation directions, and the like. In some instances, the multiple users may use gestures, such as a swipe gesture, a pinch gesture, and a tap gesture, to indicate sharing of such content, which may allow for intuitive control of sharing between the multiple users.

[0044] In the example of FIG. 1, VOS 160A and VOS 160B may include user interface (UI) module 114A and UI module 114B, respectively (collectively referred to herein as “UI module 114”). UI module 114, as shown in the example of FIG. 1, may be operable by computing device 102 to perform one or more functions, such as receive input and send indications of such input to other components associated with computing device 102. UI module 114 may receive data from components associated with computing device 102 such as application module 118A and / or application module 118B. Using the data received, UI module 114 may cause other components associated with computing device 102, such as presence-sensitive display 112 or supporting presence-sensitive displays 150, to provide output based on the data. For instance, VOS 160A may invoke UI module 114A to display different graphical user interfaces (GUIs) on at least one of display 112 or displays 150 based on receiving data from application module 118A to log into or start a user profile on a particular display.

[0045] VOS 160A and VOS 160B may include application module 118A and application module 118B, respectively (collectively referred to herein as “application module 118”). Application module 118, as shown in the example of FIG. 1, may include functionality to perform any variety of operations on computing device 102. For instance, application module 118 may include a word processor, a text application, a web browser, a multimedia player, a calendar application, an operating system, a distributed computing application, a graphic design application, a video editing application, a web development application, or any other application. Application module 118 may include functionality to login and logout of a user profile on each of displays 150 and display 112. Application module 118 may include functionality to concurrently execute different applications on each of displays 150 and display 112. Application module 118 may include functionality to concurrently execute different applications on multiple displays based on a user profile associated with eachdisplay. That is, application module 118 may include functionality to execute an application on a display with application data specific to the user profile associated with the display. Application module 118, in various examples, may provide data to UI module 114 causing display 112 and / or displays 150 to display a GUI based on the data. Modules 114 and 118 may execute as one or more services of VOS 160 or a computing platform or may execute as one or more executable programs at an application layer of a computing platform. Although illustrated as internal to VOS 160 in the example of FIG. 1, modules 114 and 118 may be external to VOS 160, as illustrated in the example of FIG. 7.

[0046] In operation, computing device 102 may, as shown in the example of FIG. 1, interface with displays 150, which may be similar to if not substantially similar to presence-sensitive display 112. However, rather than integrate into computing device 102 similar to presencesensitive display 112, displays 150 may be communicatively coupled (via wire or wirelessly) to computing device 102 and integrated throughout the cabin of the vehicle or separate from the vehicle. That is, displays 150 may also, in some instances, represent tablets, smartphones, laptops, portable gaming device, portable video devices, augmented reality headsets, mixed reality headsets, virtual reality headsets, or any other device capable of interfacing with computing device 102 to present a user interface associated with VOS 160 (and / or applications executing in an application space presented by VOS 160, which may be separate from a privileged kernel space in which VOS 160 executes to facilitate interactions between the applications and underlying hardware, such as components 112, and 140-148).

[0047] In any event, processors 140 may execute an instance of a vehicle operating system, such as VOS 160A or VOS 160B. VOS 160A and VOS 160B may expose one or more application programming interfaces (APIs) 116A and 116B, respectively. VOS 160A and / or 160B may invoke functions of APIs 116 to facilitate concurrent access by multiple user profiles that are shown in the example of FIG. 1 as user profiles (UP) 161 A- 16 IN (“UP 161”) for VOS 160A and UP 163A-163N (“UP 163”) for VOS 160B. UP 161 / 163 may each define a set of access rights (or in other words privileges), preferences (e.g., for user interfaces, VOS 160 settings, etc.), and other user-specific configuration data or information. UP 161 / 163 may each be associated with a different user, although UP 161 and UP 163 may include user profiles for the same user. For example, UP 161 A and UP 163A may be associated with the same user.

[0048] Processors 140 may execute, as one example, VOS 160A and authorize multiple user profiles of UP 161 to interface with VOS 160A. To authorize multiple user profiles of UP 161, each of the users may register with VOS 160A, entering a username (associated with agiven one of UP 161) and a password to log into VOS 160A. Alternatively, any other way by which to log into VOS 160A may be enabled, such as scanning a quick response (QR) code with a camera of a smartphone, entering a personal identification number (PIN), performing a biometric process (e.g., a fingerprint scan, a retina scan, etc.), facial recognition or any other way by which to register a given user profile of UPs 161 with VOS 160A. OS 160A may compare the entered information with authentication information stored to UP 161 to authorize (or in other words authenticate) each of the multiple user profiles of UP 161 to interface with VOS 160 A.

[0049] In accordance with the techniques described herein, VOS 160A may expose APIs 116A and invoke functions of APIs 116A to associate user profiles with display 112, as well as each of displays 150. For example, VOS 160A may invoke a start function of APIs 116A to start or login a default user profile (e.g., UP 161 A) to display 112 when processors 140 boots the instance of VOS 160A. VOS 160A may output a list of user profiles to displays 150 via UI module 114. VOS 160A may receive inputs - via UI module 114 - detected from displays 150 to associate a user profile with a respective display of displays 150. For example, VOS 160A may send instructions to display 150A - via UI module 114 - to output a list of user profiles (e.g., UPs 161B-161N) that are currently not logged into or started on another display associated with VOS 160A. Display 150A may detect an input of a user selecting an icon or button associated with UP 16 IN via PSI component 104, for example. Display 150A may invoke UI module 114 to process the input as an indication to associate UP 161N with display 150A. UI module 114 may invoke the start function of APIs 116A - exposed by VOS 160A - to associate UP 161N with display 150A. VOS 160A may use APIs 116A to login to a default user profile on display 112, while concurrently using APIs 116A to login to different user profiles on each of displays 150. VOS 160A may present user interfaces (e.g., graphical user interfaces) via each of displays 112 and 150 that provide different user interfaces based on the user profile associated with the particular display. In this way, VOS 160A may provide different user experiences to display 112 and each of displays 150 based at least in part on which of UPs 161 are associated with which of displays 112 and 150.

[0050] VOS 160A may log out or otherwise switch user profiles assigned to any of displays 112 or 150. For example, display 112 may detect an input including a request to switch the default user profile (e.g., UP 161 A) currently associated with display 112 to another user profile (e.g., UP 161B). Display 112 may invoke UI module 114 to process the detected input. UI module 114 may invoke a stop function of APIs 116A - exposed by VOS 160A -to disassociate the default user profile (e.g., UP 161 A) from display 112. UI module 114 may invoke the start function of APIs 116A to associate the user profile (e.g., UP 16 IB) included in the request with display 112. UI module 114 may then send instructions to display 112 to present a user interface that provides a user experience based at least in part on the user profile (e.g., UP 161B) included in the request. For example, UI module 114 may interface with application module 118A to generate instructions for presenting a user interface based on application data, preferences, configuration information, etc. associated with the user profile (e.g., UP 161B) via display 112.

[0051] In some examples, VOS 160A may send instructions to displays 112 and / or 150, via UI module 114, to output a list of user profiles responsive to invoking the stop function of APIs 116A to disassociate a user profile from a display. Once VOS 160A disassociates a user profile on a display, VOS 160A may update the list of user profiles to include the user profile. VOS 160A may send instructions to output the list of user profiles responsive to receiving a request to stop a user profile on a display. Display 112 and / or displays 150 may detect inputs that include a selection of a user profile included in the list. Display 112 and / or displays 150 may invoke UI module 114A to process the detected input as an indication to associate the selected user profile with the display. UI module 114A may invoke the start function of APIs 116A to associate the selected user profile with the display that detected the input. In some examples, VOS 160A may associate a user profile on a display (e.g., a passenger display) based on instructions received from another display with greater access rights (e.g., a driver display). Although described as one user profile (e.g., UP 161A) being associated with one display (e.g., 112), in some instances, VOS 160A may associate the same user profile (e.g., UP 161 A) with two or more different displays (e.g., display 112, display 150A, etc.). In some instances, VOS 160A may create a user life-cycle event that a user profile (e.g., UP 161 A) is visible responsive to VOS 160A associating or assigning the user profile to a display by invoking the start function of APIs 116A. Similarly, VOS 160A may create a user life-cycle event that a user profile (e.g., UP 161 A) is invisible responsive to VOS 160A unassigning a user profile from a display by invoking a stop function of APIs 116A. VOS 160A may assign an occupant zone (e.g., driver occupant zone, passenger occupant zone, etc.) to visible user profiles.

[0052] The techniques may provide one or more technical advantages that realize one or more practical applications. For example, a single instance of an operating system (VOS 160A or VOS 160B) may effectively manage user profiles associated with multiple displays to improve user experiences provided to users operating the multiple displays. A singleinstance of an operating system managing user experiences provided on multiple displays may reduce computational resources (e.g., processing power, memory, etc.) required to provide a customized user experience on each display of the multiple displays. The single instance of the operating system may associate a user profile, occupant zone identifier, vehicle state, display type, etc. to a particular display of the multiple displays to customize and improve user’s experience operating each display, while maintaining restrictions that may be necessary (e.g., driver restrictions, safety restrictions, parental controls, etc.).

[0053] While discussed with respect to authentication, VOS 160A may also allow guest user profiles (as one of UP 161) in which authorization is provided without requiring any authentication. In this respect, guest user profiles may provide a limited experience (compared to authenticated UP 161) in terms of maintaining preferences, applications, etc. across different sessions but still enable functionality described below with respect to sharing content between multiple UPs 161 and the like.

[0054] In any event, VOS 160A may present multiple user interfaces across multiple displays (such as display 112 and one or more of displays 150) communicatively coupled to computing device 102. VOS 160A may, for authenticated UP of UP 161, present the user interface specific for each of the authenticated UP that maintains preference in terms of application organization, user interface theme, various VOS 160A settings (e.g., regarding notifications, accessibility, display configuration in terms of brightness, resolution, orientation, and the like, and any other type of OS setting). In any event, each of the multiple user interfaces are associated with one or more of UP 161.

[0055] VOS 160A may next interface, via the multiple user interfaces, with multiple users associated with multiple UP of UP 161 to enable the multiple users to interface with VOS 160A for purposes of controlling functionality associated with computing device 102. This functionality may include controlling navigation, changing content playback, changing user interface settings, controlling HVAC settings, sharing content between UP 161, and other functionality described below in more detail.

[0056] In some examples, processors 140 may represent a high processing capacity processor (which may be referred to as “processor 140 A”) and a low processing capacity processor (which may be referred to as “processor 140B”). In some instances, processor 140 may represent a processor capable of variable processing capacity having two or more distinct operating voltages that enable, at high voltages, high processing capacity and, at low voltages, low processing capacity. In this sense a single processor may represent both processor 140A and processor 140B, switching between the different processing modes (e.g.,high and low processing modes) to facilitate power conservation. Processor 140 A may provide additional processor cores compared to processor 140B (or in the instance where a single processor switches between processing mode, enabling additional cores in the high processing mode when compared to the low processing mode).

[0057] Processor 140A may execute VOS 160A, while processor 140B may execute VOS 160B. Processor 140A may execute VOS 160A for tasks that require higher processing, such as gaming, video conferencing, navigation, and other processor intensive tasks / applications. Processor 140B may execute VOS 160B for tasks that require lower processing, such as streaming audio, telephone calls, viewing images, text messaging, or other less processor intensive tasks / applications.

[0058] In some examples, processor 140A may execute VOS 160A concurrently to processor 140B executing VOS 160B. In instances of concurrent execution of VOS 160A and 160B, VOS 160A may present an interface by which VOS 160B may communicate with VOS 160A to facilitate various functionalities of computing device 102. This interface may represent an application programming interface (e.g., APIs 116B) that VOS 160B may invoke to facilitate inter-VOS communication between VOS 160A and VOS 160B to cooperatively facilitate support to functionality provided by computing device 102.

[0059] Utilizing different processing capacity processors may reduce energy consumption. Further, it may be cost prohibitive to install high processing capacity processor 140 capable of all of the functionality supported by computing device 102, where a low processing capacity processor 140 may allow the manufacturer to upgrade over time to add additional processors having high processing capacity (and / or possibly low processing capacity). Providing a framework for inter-VOS communication may allow for manufacturers to upgrade over time without having to configure a separate inter-VOS communication interface by which to facilitate access to the functionality of computing device 102 described in more detail below.

[0060] As further shown in the example of FIG. 1, computing device 102 may also interface with supporting audio capture devices 152A-152N (“supporting audio capture devices 152” or “audio capture devices 152”). Audio capture devices 152 may each represent a microphone or other transducer configured to capture audio data representative of a soundfield. Supporting audio capture devices 152 may also be referred to as “microphones 152.” In some examples, audio capture devices 152 may be integrated throughout one or more zones of the cabin of the vehicle that includes computing device 102. These zones may include an operator zone, one or more front passenger zones, and one or more rear passengerzones. As described below in more detail, these microphones 152 may capture (or, in other words, record, detect or otherwise sense) audio data that VOS 160 may use to adjust audio playback as well as support additional functionality provided by computing device 102.

[0061] In this way, various aspects of the techniques may facilitate a better user experience when traveling in the vehicle while still preserving safety concerns with distracting the operator of the vehicle. As a result of permitting multiple UP 161 / 163 to access VOS 160A / 160B, VOS 160A / 160B may tailor the user experience to each individual UP of UP 161 / 163 allowing for preferences to be applied that are specific to each individual UP. VOS 160A / 160B system may also allow the multiple users to coordinate on activities (as noted above) that may improve the user experience while traveling in the vehicle. Given that additional displays 150 (which may be separate from a main display, e.g., presence-sensitive display 112, of vehicle head unit 102) may be located in the cabin where the operator of the vehicle cannot directly see the content being presented, VOS 160A / 160B may permit increased permissions in terms of access to content while also potentially limiting any distractions to the operator.

[0062] In addition, various aspects of the techniques may enable VOS 160 to define different user experience restrictions per occupant zone (OZ) and possibly display type (DT, e.g., virtual or physical display type). Each occupant zone may be associated with an occupant zone identifier (OZID) 165A-165N (“OZID 165") and / or OZID 167A-167N (“OZID 167”) that identifies a particular occupant zone of a plurality of occupant zones (e.g., a driver occupant zone, a front passenger occupant zone, a backseat passenger occupant zone, etc.). VOS 160 may define different user experience restrictions for each occupant zone identifier and also potentially for a display type 171A-171N and / or display type 173A-173N (“DT 171 / 173,” where passenger virtual displays, such as front passenger virtual displays that share the same underlying physical display used for the driver occupant virtual display, may receive less stringent user experience restrictions compared to, as one example, the driver occupant zone). In another example, VOS 160 may define user experience restrictions for passenger occupant zones that are not applied to a driver occupant zone, such as a driver occupant zone may change user interface settings (e.g., a locale or language, user interface mode, a color display of user interfaces, etc.), while other occupant zones (e.g., the front passenger occupant zone) may not change user interface setting. Allowing different user experience restrictions may allow occupants (other than the driver) to safely interact with the single operating system without distracting the driver while driving (or in other operational states of the vehicle, such as an idle state and a parked state).

[0063] In operation, VOS 160 may determine, based on which of multiple displays (such as display component 103, additional displays 150, etc.) with which each of UP 161 / 163 interfaced to authorize each of UP 161 / 163, one or more of OZIDs 165 / 167. Each of OZIDs 165 / 167 may identify an occupant zone of the vehicle in which each of the UP 161 / 163 are associated. As such, each of UP 161 / 163 are associated with one or more OZIDs 165 / 167, which may allow VOS 160 to obtain user experience (UX) restrictions (UXR) that are specific to a given occupant zone of the vehicle. That is, VOS 160 may maintain a UXR mapping that defines assignment of UXR to each of UP 161 / 163 based on OZID 165 / 167. When attempting to authorize one or more of UP 161 / 163, VOS 160 may register within the UXR mapping each of the one or more UP 161 / 163 to a given OZID 165 / 167 along with possibly DT 171 / 173. VOS 160 may assign the UXR per application executed by VOS 160 and updated based on the operational state of the vehicle, as described in more detail below.

[0064] VOS 160 may next restrict, via multiple user interfaces presented across the multiple displays (e.g., display component 103, additional displays 150, etc.) and in accordance with the UXR defined for each of UP 161 / 163, the content with which at least one of UP 161 / 163 consume. As a result, VOS 160 may tailor UXR for the specific UP 161 / 163 based on the location of the display (possibly whether virtual or physical as defined by DT 171 / 173) within the vehicle (as defined by OZID 165 / 167) that may adapt to the operational state of the vehicle to potentially maintain safety (through limiting distractions for the operator of the vehicle) while also possibly improving the user experience for other occupants of the vehicle that are not operating the vehicle.

[0065] In this respect, different occupants of the vehicle may be assigned different user experience restrictions (as represented by UP 161 / 163) based not only on OZID 165 / 167 associated with each of the multiple displays, but also potentially based on a display type (e.g., virtual display or physical display) and a driving state (e.g., a parked state, an idle state, or a driving state). Incorporating these different identifiers, display types, and vehicle states may allow for granular control of presenting applications (which may be non-di straction optimized applications and distraction optimized applications) or other user interfaces via the user interface presented by the single operating system. Such granular control of user experience restrictions may allow for a better user experience depending on occupant zone, display type, and possible vehicle state and better prevent distractions to a driver of the vehicle. As such, the techniques described in this disclosure may improve the user experience for occupants of the vehicle that implements various aspects of the techniques described in this disclosure, while also potentially providing a safer operating experience forthe driver by preventing distractions that may result in faulty operation of the vehicle.

[0066] FIG. 2 is a diagram illustrating an example of a vehicle that includes a computing system configured to execute a vehicle operating system that operates in accordance with various aspects of the single-instance multi-user techniques described in this disclosure. As shown in the example of FIG. 2, an interior (which may be referred to as a “cabin”) of vehicle 200 may include a computing system in the form of vehicle head unit 202, which represents an example of computing device 102.

[0067] Vehicle head unit 202 is, in the example of FIG. 2, integrated into approximately a center portion (e.g., a center console) of a front dashboard 220. Vehicle head unit 202 includes a display 212, which may represent one example of presence-sensitive display 112. Display 212 may be displaced in a front dash 220 of vehicle 200. Display 212 may represent a single physical display that supports presentation of multiple virtual displays 213 A and 213B. Display 212 may present virtual display 213A in the driver occupant zone and virtual display 213B in a front passenger occupant zone.

[0068] Vehicle 200 may also include (in this example, physical) displays 250A and 250B, which may represent examples of displays 150 described above with respect to FIG. 1. Displays 250A and 250B are integrated into a rear passenger compartment of the cabin (i.e., in headrests of the front seats in the example of FIG. 2) on both the operator side (display 250A) and passenger side (display 250B). Although described as physical displays 250A and 250B in the example of FIG. 2, displays 250A and / or 250B may represent virtual displays.

[0069] As described above, VOS 160A may interface, via a first user interface (presented for example by virtual display 213B) associated with a first user profile (e.g., UP 161 A), with a first user (a front passenger) to interact with content presented by a second user interface (e.g., presented for example by display 250B) associated with a second user profile (e.g., UP 161B) of multiple UP 161. In some instances, VOS 160A may interfacing with the first user to one or more of view or initiate playback, at the first user interface, the content presented by the second user interface.

[0070] VOS 160A may also interface with the first user to control audio playback by the second user interface presented by display 250B. VOS 160A may interface with the first user to, via the first user interface presented by display 213B, change an audio volume associated with the audio playback by the second user interface presented by display 250B.

[0071] VOS 160A may also interface with the first user to enable the first user and the second user (e.g., an operator-side rear passenger) to jointly interact with the content presented by the second user interface presented by display 250B. In this example, VOS160 A may interface with the first user to enable the first user and the second user to jointly contribute to audio playback by the second user interface (such as by jointly collaborating on building an audio playlist). VOS 160A may also, as another example, interface with the first user to enable the first user and the second user to jointly contribute to a multi-user activity presented by the second user interface, where such multi-user activity may include a navigation activity in which both the first user and the second user contribute to navigation of vehicle 200 that includes vehicle head unit 202 and / or a multi-player video game presented by the second user interface.

[0072] While shown as multiple physical displays 212 / 250, various aspects of the techniques may operate with respect to a single physical display (or multiple physical displays) having separate logically separated displays (or so-called virtual displays 213 A and / or 213B). That is, a single physical display 212 / 250 may be logically split (e.g., via software) to represent two distinct physical displays (from the perspective of the instance of VOS 160). In this respect, a single physical display may represent multiple different displays and displays 212 / 250 may each represent a logically separate virtual display.

[0073] In this respect, various aspects of the techniques described herein may enable a number of different use cases, including the following:• A parent would like to see what their children are watching;• Parent or driver would like to control the volume from the children's displays;• Two or more passengers may want to contribute to some shared playlist; and• Two or more passengers may want to interact with the same content (like a multigame player).The following use cases may be enabled given that the techniques allow for the following:• Mirror displays contents when running on Android Auto;• Allow drivers and passengers mirror their display contents; and• Let driver or passenger send inputs, like (key, rotary, dpad, touch, etc events) to other's passenger displays.

[0074] In other words, various aspects of the techniques described herein may address problems associated with enabling mobile apps to interact with each other (same or different app) across concurrent multiple users on a single Android instance. As such, the techniques may enable interaction from rear seat to operator for adding a stop in navigation and / or interaction from an operator to rear seat (such as a child) for playing video.

[0075] VOS 160A may also interface, via the first user interface associated with UP 161 A, with a first user (front passenger) of the multiple users to share content presented by the first user interface with a second user interface of the multiple user interfaces associated with UP 161B. For example, VOS 160A may receive, at the first user interface presented as an example by display 213 A, a gesture that indicates the content presented by the first user interface is to be shared with the second user interface presented for example by display 250B. The gesture may include one or more of a swipe gesture, a pinch gesture, a tap gesture, or any other gesture associated with using presence-sensitive displays, such as display 213 A.

[0076] VOS 160A may be configured to, in some instances, present, at the first user interface, an animation indicating initiation of the content being shared. In addition or alternatively, VOS 160A may play audio indicating initiation of the content being shared. In some examples, VOS 160A may, when playing audio indicating initiation of the content being shared, play spatialized audio to reflect a position of the first user interface relative to a position of the second user interface.

[0077] In this respect, various aspects of the techniques may make cross-display interaction, such as sharing screens, more immersive using advanced user interface technologies. Based on the locational relationship between passenger zones in the vehicle, the techniques may enable the following:• Sending content from one display to another using gesture (swipe, click, etc.);• Visualizing the interaction using animation; and• Using spatial audio to show where the content is moving to make it more immersive.

[0078] Moreover, VOS 160A may determine, based on which UP 161 / 163 was used to authenticate or otherwise authorize interaction with VOS 160A via one or more of displays (virtual displays 213 A and / or 213B - “virtual displays 213” and / or displays 250A and / or 250B, which may be referred to as “physical displays 250”), one or more OZIDs 165 / 167. VOS 160A may assign virtual display 213 A OZID 165 A (as an example) that contains a value of zero (0) identifying the driver occupant zone, virtual display 213B OZID 165B (as another example) that contains a value of one (1) identifying the front passenger occupant zone, etc.

[0079] VOS 160A may, in some instances, also identify a display type 171 / 173 that indicates (possibly as a Boolean) whether each of displays for which authorization was provided to UP 161 / 163 to access VOS 160A is either a physical display or a virtual display (or in otherwords, is a virtual display 213 that is presented by at least one physical display 212). VOS 160A may utilize OZID 165 / 167 along with DT 171 / 173 to differentiate between virtual displays 213 presented via a same physical display 212 in order to appropriately assign UXR to UP 161 / 163. VOS 160A may also utilize OZID 165 / 167 along with possibly DT 171 / 173 to differentiate between display 212, virtual displays 213, and physical displays 250, assigning UXR to UP 161 / 163 based on one or more of OZID 165 / 157 and DT 171 / 173.

[0080] VOS 160A may further determine UXR based on a type of application executed by VOS 160A and then presented via each one of displays 212, 213, and / or 250. That is, in some instances, various applications executed with the application space presented by VOS 160A may be distraction optimized (“DO,” meaning such applications are optimized to reduce distractions and thereby may be executed with more limiting UXR compared to non- DO applications). For example, DO applications (which may be optimized for vehicle computing systems, such as vehicle head unit 202) may restrict the type of content presented or may improve upon the interface to facilitate less distractions compared to non-DO applications (which may be optimized for other computing platforms, such as laptop computers, smartphones, gaming systems, smart glasses, augmented / virtual / mixed reality systems, smartwatches, etc.). VOS 160A may allow DO applications to execute in limited UXR while limiting or preventing execution of non-DO applications in the same limited UXR.

[0081] VOS 160A may also determine an operating state of vehicle 200 (potentially via VOS 160B). The operating state of vehicle 200 may refer to various operating conditions in which VOS 160A may present various interfaces via displays 212 / 213 / 250. Such operating conditions may for example include a driving state, an idle state, a parked state, etc. VOS 160A may register each UP 161 / 163 via an API, providing OZID 165 / 167 determined for each UP 161 / 163 along with possibly DT 171 / 173. Upon registering each UP 161 / 163, VOS 160A may monitor application types being executed for each UP 161 / 163 along with the operational state of vehicle 200, updating UXR responsive to changes in application types and the operational state of vehicle 200.

[0082] VOS 160A may continually or periodically update UXR assigned to each UP 161 / 163 depending on changes to the operating state and / or application type. VOS 160A may assign different UXR, as one example, based on the driving state, the idle state, and the parked state. UXR for the driving state may be more limiting than UXR for the idle state (as distractions during the idle state represent less of a safety concern compared to the driving state), while UXR for the idle state may be more limiting than UXR for the parked state (where againdistractions during the parked state represent less of a safety concern compared to the idle state).

[0083] FIG. 3 is a diagram illustrating different interaction models with multiple displays including interactions that occur via single instance multi-user models and multi-instance multi-user models in accordance with the vehicle operating system techniques described in this disclosure. As discussed in this disclosure, vehicle displays, such as displays 212 and 250, are evolving from operator centric to whole car experiences, where passengers can have the following:• Personal curated experiences while commuting to work;• Communal experiences to enjoy a family fun trip; and• Shared experiences, while in a ride-sharing environment

[0084] Original equipment manufacturers (OEMs) may recognize these needs and are building cars to provide users with these experiences. These are no more seen as premium experiences but a value for a desirable vehicle.

[0085] In this respect, users may look for concurrent experiences across displays for a seamless and immersive experience, such as:• Navigation - add stops to driver from their display for ongoing journey;• Entertainment - Play and control video for kids in backseat or play games to keep them engaged & entertained;• Users - Access their own curated apps, content and data for entertainment and / or productivity; and• Personalization - Control my seat settings, HVAC control, alerts for my seat.

[0086] OEMs are thinking about following user interaction models, based on anticipation of user behaviors. There are 3 types of interactions models (shown in the example of FIG. 3):1. In-vehicle infotainment (IVI) Display is the primary controller for content on front seat entertainment (FSE) and rear seat entertainment (RSE); a. FSE and RSE have minimal controls - audio, play / pause, on / off etc.2. IVI Screen is mirrored across FSE / RSE, with passenger displays cannot select content or controls; and3. Content can be shared across all the screens, with each screen having its own individual controls.

[0087] There are the following user personas for multi-display scenarios:• Driver:o Interacting with cluster & IVI screens for driving and interacting with other screens in car• Front seat passenger: o Assisting to driver for navigation and passengers content using FSE• Rear seat passengers: o Interacting with RSE for content, controls and suggestions to driver for navigation• Guest: o Temporary riding in the car and wants to access some apps on passenger displays

[0088] FIG. 4 is a diagram illustrating an example vehicle that includes a vehicle head unit configured to control audio content in accordance with various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure. In the example of FIG. 4, a vehicle 400 may represent an example of vehicle 200 (shown in FIG. 2) in which a vehicle head unit 202 may enable privacy and sharing between different audio zones 404A- 404D (“audio zones 404”) within vehicle 400. Audio zone 404A may represent a front seat operator-side zone (also denoted a “front operator zone 404A”). Audio zone 404B may represent a front seat passenger-side zone (also denoted a “front passenger zone 404B”).Audio zone 404C may represent an operator-side rear passenger zone, while audio zone 404D may represent a passenger-side rear passenger zone.

[0089] In each of audio zones 404, vehicle 200 may include a respective one of audio capture devices 452A-452D (“audio capture devices 452”) and a respective one of speakers 454A- 454D (“speakers 454”). Audio capture devices 452 may represent examples of audio capture devices 152. Both audio capture devices 452 and speakers 454 may represent transducers capable of converting, in the instance of audio capture devices 452, sound pressure into electrical signals representative of a soundfield and, in the instance of speakers 454, electrical signals representative of a soundfield into the corresponding soundfield.

[0090] Although described as having a single one of audio capture devices 452 and a single one of speakers 454 in each of audio zones 404, each of audio zones 404 may include more or less audio capture devices 452 and more or less speakers 454. Further, while described as being transducers, any type of device capable of capturing audio data (transformed from the electrical signals captured by the audio capture devices 452) and reproducing a soundfield from electrical signals (transformed from audio data) may be utilized in one or more of audiozones 404. In addition, while four audio zones 404 are shown in the example of FIG. 4, vehicle 400 may include more or less audio zones 404.

[0091] In any event, VOS 160A may interface with the multiple users to control audio playback within one or more of zones 404 of a cabin of vehicle 400 that includes vehicle head unit 202. VOS 160A may, for example, interface with the multiple users to control audio volume in a single one of zones 404 of the cabin. As another example, VOS 160A may interface with the multiple users to control a focus of audio playback in at least one of zones 404 of the cabin.

[0092] As such, various aspects of the techniques may provide a central service for audio controls concurrently for all users (e.g., driver and / or passengers) to control audio settings (volume up / down, mute, unmute, or any other control). To facilitate this control, VOS 160A may provide a service to manage audio controls (e.g., volume, mute, settings, ducking, interruptions, etc.) so as to provide the following:• Manage controls independently for each user in their respective audio zones;• Manage focus for other users in separate zone;• While taking into consideration current safety restrictions; and• While taking into consideration current user roles (Driver, passenger, disable passenger, rear seat passenger).

[0093] In addition, one or more of audio capture devices 452 may capture audio data representative of a soundfield at each of one or more zones 404 (which is another way to refer to audio zones 404). VOS 160A may determine, based on the audio data representative of the soundfield occurring at each of zones 404, that a first user of the multiple users in a first zone (e.g., zone 404C) of the one or more zones is speaking in an attempt to audibly interface with vehicle head unit 202. VOS 160A may adjust, based on the audio data representative of the soundfield occurring at each of zones 404, audio playback at zones 404.

[0094] In terms of adjusting audio playback, VOS 160A may determine, based on the audio data representative of the soundfield occurring at each of zones 404, a noise level. VOS 160A may next adjust, based on the noise level, the audio playback at one or more of zones 404.

[0095] In this respect, various aspects of the techniques may address how to enable multi-mic support for VOS 160A. VOS 160A may, using audio data captured by audio capture devices 452, determine and / or perform the following:• Use mic to know which user is speaking, talking to adjust the volume controls byrecognizing user;• Map to display being used;• Provide better assistant response for the (speaking) user;• Detect noise level for each user (around their respective areas) and perform required audio changes for audio playback for comfortable audio listening;• Also combine audio information for each user to determine noise levels in the car and apply changes to speaker for a better listening environment;

[0096] FIGS. 5 and 6 are diagrams illustrating audio control in a single-instance, multi-user vehicle operating system in accordance with various aspects of the techniques described in this disclosure. In some instances, vehicle operating systems have limited scope in that such vehicle operating systems can only send audio from one zone to another for that particular application unique identifier (UID). Various aspects of the techniques described in this disclosure enable zones 404 to share audio to the cabin with the following objectives:• Share media audio from passenger to the main cabin;• Provide a mechanism for passengers not in main cabin to request for audio playback to main zone (e.g., operator zone 404A);• Provide a mechanism for driver to allow audio playback in the main zone;• Provide mechanism to share audio focus between two different zones; and• Disable volume control from non cabin owner from controlling volume;

[0097] For example, a passenger listening to media in the rear seat entertainment (RSE) zone (e.g., one of zones 404C or 404D) may send audio to the main cabin to allow for everyone in the car to listen to audio. While the passenger in the back seat RSE would select to send audio to the main cabin, the operator (or main cabin user) would still maintain control of allowing the audio play, as well as retaining control of the volume and other audio settings.

[0098] FIG. 5 shows a high level overview of the current audio architecture. Audio zones 404 are defined in configuration and are used to set up the audio routing for each audio zone 404. Each of audio zones 404 is defined as a collection of volume groups; each group contains a set of devices that are controlled on volume changes on the volume group. Each device can have different audio context’s routed into the device. The vehicle audio service may use the routing information on each audio zone to define a set of audio mixes, which VOS 160A may use to configure the audio routing for each of zones 404.

[0099] Referring next to FIG. 6, a configuration set-up is shown between the vehicle audio service and vehicle occupant zone service. For audio, the vehicle audio service may read theaudio zone ( audioZoneld ) to occupant zone Id ( occupantZoneld ) mapping from the configuration. This information may be sent to the car occupant zone service to set up the occupant zone configuration during initialization. Occupant zone service may maintain information about the occupant zone configuration and display port mapping, which may be read from the different configuration information.

[0100] The car audio service may register a VehicleOccupantZoneCallback on the occupant zone service. VOS 160A may trigger this service when there are any of the following changes in the vehicle occupant zone:• Display activation;• Audio Config changes;• Occupant Zone user assignments;• Passenger Start; and• Passenger Stop.

[0101] When the audio service receives the onOccupantZoneConfigChanged signal from the callback, the audio service of VOS 160A may automatically assign the users to their corresponding audio zone as follows:• Unloads previous user settings;• Removes previous user audio policy routing;• Loads audio settings for the new user;• Set up audio policy routing for the new user; and• Resets the audio focus mapping for the new user.

[0102] The audio service of VOS 160A may use the audio focus mapping to determine where the incoming focus request should be assigned.

[0103] To allow for the passenger to send audio to the main cabin there a couple of things that need to be in place:• Handle focus request in main cabin; and• Route passengers audio to the main CabinOnce the focus request has successfully changed from the passenger's own audio zone in vehicle 400, the audio routing can take place. For audio playback not yet started, the focus handling will automatically request focus in the main cabin zone with the rules already set with regards to audio usage priority (e.g., audio for media will be rejected by current phone call).

[0104] The passenger should be able to request to send audio to the main cabin, a promptwould pop up for the driver to accept. Alternatively, the driver can enable an automatic allow for passengers to play audio. If accepted the audio focus request can be transferred to the main cabin, if needed, and the playback can commence. If not accepted the passenger can be prompted with a message.

[0105] Because one goal of the functionality is to play media from passengers in the main cabin, the focus request for the passenger can be restricted to media only. Focus requests for other sounds (e.g. alarm, call, notification, etc.) should remain in the passenger’s respective zone. For the media focus request the logic could be as follow:• Send transient focus loss to passengers media apps;• Request Focus for passengers media app in main cabin;• Send focus gain if focus request is granted; and• If not granted due to higher priority sound (emergency, phone call): o Set focus request as delayed focus;■ Focus will be granted once higher priority focus is done; and o Alternative: Send focus back to the users zone

[0106] For passengers, where the user Id is used, a possible driver for audio routing may be the user id device affinity routing. This can still be utilized for sending the passengers audio to the main cabin as follows:• Find the main’s cabin media device (preferably a separate high quality device); and• Reset the passenger device affinity to share the cabin’s media device.

[0107] In addition, multi-zone audio (MZA) may facilitate playback of audio by various users, all playing audio on each individual audio zone 404. This may allow for users in the main cabin to play media or any other sounds, while users in a rear entertainment system also play media in their respective zones. This enables OEMs to potentially design complex audio infotainment systems where each passenger can tailor their own experience in vehicle 400.

[0108] Example use cases include the following:• In the car, the driver can play music while users in the backseat can have their own music / media played;• Users in the backseat can control their music volume without affecting the music playback of the driver;• First party music apps launched in the backseat can play sound in the backseat without any change.

[0109] One mechanism used for MZA is based on the dynamic audio policy, in particularusing the UID / userid based routing. This may allow for the audio policy to define routing based on audio attribute usages, UID, or userid. This may allow for applications or services to leverage the automatic routing of audio as configured by the dynamic audio policy. However, there exist APIs that can be used to route audio outside of the assigned audio devices. This has some impact in the car as applications are able to send audio to a particular zone without the users permission for example:• Rear seat entertainment (RSE) application from user A sending audio directly to the output device for the driver user in the main cabin.• RSE application from user A sending audio directly to the output device for a different RSE assigned to user B.This may raise some concerns for the driver safety as the main driver could be distracted upon arrival of an unwanted audio in the main cabin.

[0110] One possible goal of this aspect of the techniques is to allow the current dynamic audio policy to continue working but also limit the playback of audio for users (and their respective application / services) to play audio outside of a set of assigned zones, irrespective of the mechanism used to select devices for audio playback. A potential benefit for the users in the car is that such users will be able to consistently listen to audio in the car in a private and consistent manner.[OHl] The dynamic audio policy may provide a mechanism to set devices that can be used by a user for automatic routing via an audio policy API. This audio policy API may either be used or extended to limit application using the audio routing relative to a set of preferred devices to route audio outside of the limits of the audio policy user assignment. This should potentially limit the “forced” routing for devices defined within the audio policy.

[0112] FIG. 7 is a block diagram illustrating example computing device 702 configured to manage user profiles for a single-instance, multi-user vehicle operating system 760, in accordance with various aspects of the techniques described in this disclosure. In the example of FIG. 7, computing device 702, storage devices 748, UI module 714, VOS 760, User Profile (UP) application 792, and APIs 716 may represent examples of computing device 102, storage devices 148, UI module 114, VOS 160A, application module 118, and APIs 116A of FIG. 1, respectively. VOS 760 may operate in a kernel space that provides increased privileges (e.g., access rights, dedicated memory, etc.) that hosts an application space 779 with reduced privileges relative to the kernel space in order to moderate access by applications, including user profile (UP) application 792 which may be stored to storagedevices 748.

[0113] APIs 716 of FIG. 7 may include vehicle user service 794, vehicle occupant zone service 798, and activity manager service 796. Vehicle user service 794 may represent a software module (executed by underlying hardware, such as processors 140, that cause processors 140) to manage user profiles assigned to displays associated with computing device 702 (e.g., display 112 and / or displays 150 of FIG. 1). Vehicle occupant zone service 798 may represent a software module (executed by underlying hardware, such as processors 140, that cause processors 140) to manage user assignment information to displays associated with computing device 702 (e.g., display 112 and / or displays 150 of FIG. 1). Activity manager service 796 may represent a software module (executed by underlying hardware, such as processors 140, that cause processors 140) to manage functions associated with starting, stopping, and / or switching user profiles on displays associated with computing device 702 (e.g., display 112 and / or displays 150 of FIG. 1). Vehicle user service 794, vehicle occupant zone service 798, and activity manager 796 may represent example APIs 716 exposed by VOS 760 used to interface with UP application 792, on a per display basis (whether virtual or physical).

[0114] In accordance with the techniques described herein, UP application 792 may interface with UI module 714 to output a list of enrolled user profiles on one or more displays associated with computing device 702. UP application 792 and UI module 714 may include one or more APIs that may be invoked as an interface for UP application 792 and UI module 714 to exchange data and instructions. UP application 792 may interface with UI module 714 to output a list of enrolled user profiles that may be provided by vehicle user service 794. Vehicle user service 794 may receive an updated list of enrolled user profiles from activity manager service 796. Activity manager service 796 may pass a list of enrolled user profiles (e.g., by way of an indication - such as a pointer - to a location in storage devices 748 that stores the list of enrolled user profiles) that may include a state or status of user profiles, such as user profile creation, user profile removal, user profile visibility changes, etc. Vehicle user service 794 may pass the updated list of enrolled user profiles to UP application 792 by way of one or more indications (e.g., pointers) to a location in storage device 748 that stores the updated list of enrolled user profiles. In some instances, UP application 792 may invoke UI module 714 to output corresponding user assignment information with each listed enrolled user profile. UP application 792 may request and receive user assignment information from vehicle occupant zone service 798. For example, vehicle occupant zone service 798 may pass user assignment information as one or more indications (e.g., pointers) to a location instorage device 748 that stores the user assignment information.

[0115] User interface module 714 may operate as an interface between a user display (e.g., display 112 and / or displays 150 of FIG. 1) and UP application 792 to associate or disassociate a user profile with a display. For example, PSI 104 of display 112 may detect an input to start, stop, and / or switch a user profile associated with display 112. PSI 104 may invoke UI module 714 to process the detected input by correlating a selected icon, button, etc. to instructions for starting, stopping, and / or switching a user profile associated with display 112. User interface module 714 may relay the processed input to UP application 792. UP application 792 may send vehicle user service 794 a request to associate the user profile with display 112.

[0116] In an example when UP application 792 receives a processed input to associate a user profile with a display (e.g., login UP 161 A on display 112 of FIG. 1), UP application 792 may request vehicle user service 794 to start the selected user profile (e.g., UP 161 A) on the display (e.g., display 112) in which the input was detected. Vehicle user service 794 may call a start function managed by activity manager service 796 to associate the selected user profile with the display. Vehicle user service 794 may call a start function from activity manager service 796 using a proxy or software module implemented to interface vehicle user service 794 and activity manager service 796. Vehicle user service 794 may call the start function from activity manager 796 to associate the selected user profile with the display and provide a user experience based at least in part on the user profile being associated with the display.

[0117] In an example when UP application 792 receives a processed input to disassociate a user profile with a display (e.g., logout UP 161N on display 150A of FIG. 1), UP application 792 may request vehicle user service 794 to disassociate the current user profile (e.g., UP 161N) of the display (e.g., display 150A) in which the input was detected. Vehicle user service 794 may call a stop function managed by activity manager service 796. In some instances, when vehicle user service 794 calls the stop function from activity manager service 796, vehicle user service 794 may be configured to automatically call a start function from activity manager service 796 to associate a default user profile, empty user profile, guest user profile, etc. on the display. In some examples, responsive to vehicle user service 794 calling the stop function of activity manager service 796, UP application 792 may be configured to interface with UI module 714 to pass instructions to the display to output a list of enrolled user profiles that may be started on the display.

[0118] In an example when UP application 792 receives a processed input to switch a user profile (e.g., change UP 161 A on display 112 to UP 161N), UP application 792 may requestvehicle user service 794 to start the selected user profile (e.g., UP 16 IN) in the background. Vehicle user service 794 may call a start function managed by activity manager service 796. Vehicle user service 794 may call the start function from vehicle user service 794 to preliminarily associate the selected user profile (e.g., UP 16 IN) with the display (e.g., display 112) in the background. Vehicle user service 794 may then call a stop function from vehicle user service 794 to disassociate the previous user profile (e.g., UP 161 A) on the display (e.g., display 112). In this way, computing device 702 may present different, customized user interfaces via each display that provides a user experience (e.g., a personalized dashboard, personalized applications, personalized preferences, or other configuration information) based on the user profile being associated with a particular display.

[0119] In some examples, when vehicle user service 794 receives a request to start, stop, or switch a user profile on a display associated with computing device 702, vehicle user service 794 may send a request to vehicle occupant zone service 798 to update user assignment and / or unassignment information associated with each display type and / or OZID, as previously discussed. In some examples, prior to instructing UI module 714 to output a user interface on a display based at least in part on the user profile associated with the display, UP application 792 may request and receive user assignment information (e.g., display type, OZID, etc.) from vehicle occupant zone service 798. In this way, UP application 792 may provide a consistent view of assignment information when providing login and logout functionality for multi-user, multi-display environments.

[0120] FIG. 8 is a block diagram illustrating example displays 812, 850A, 850B, and 850C configured to provide graphical user interfaces 822A-822D, respectively, based at least in part on user profiles. In the example of FIG. 8, display 812, display 850A, display 850B, and display 850C may represent examples of presence-sensitive display 112 and / or supporting presence-sensitive displays 150. In some examples, displays 812 and 850 of FIG. 8 may represent examples of combinations of virtual displays and / or physical displays. Displays 812 and 850 may output graphical user interfaces (GUIs) 822 based on functions invoked by APIs 716 exposed by VOS 760 of FIG. 7, for example.

[0121] Display 812 may output GUI 822A associated with “USER 1.” In some instances, display 812 may include a driver display that may output GUI 822A by default when the vehicle operating system boots up. GUI 822A may include user dashboard 832A and user preferences 834A. User dashboard 832A may include applications, widgets, and / or other data that is specific to the user profile (e.g., “USER 1”) associated with GUI 822A. User preferences 834A may include audio preferences, temperature preferences, seat positionpreferences, or other configuration information specific to the user profile (e.g., “USER 1”) associated with GUI 822A. GUI 822A may include change user 824A. Change user 824A may include a detectable input that triggers a logout and / or login of a user profile on display 812. Change user 824A may detect an input from a user operating display 812 and send instructions to UP application 792 of FIG. 7, via UI module 714 for example, to request that a user profile be started or stopped on display 812.

[0122] Display 850A may output GUI 822B associated with “USER 2.” In some instances, display 850A may include a virtual or physical passenger display. Display 850A may output GUI 822B by default when the vehicle operating system boots up. For example, UP application 792 of FIG. 7 may be configured to establish default user profiles for one or more of displays 812 and 850. GUI 822B may include user dashboard 832B and user preferences 834B. User dashboard 832B may include applications, widgets, and / or other data that is specific to the user profile (e.g., “USER 2”) associated with GUI 822B. User preferences 834B may include audio preferences, temperature preferences, seat position preferences, or other configuration information specific to the user profile (e.g., “USER 2”) associated with GUI 822B. GUI 822B may include change user 824B. Change user 824B may include a detectable input that triggers a logout and / or login of a user profile on display 850A. Change user 824B may detect an input from a user operating display 850A and send instructions to UP application 792, via UI module 714, to request that a user profile be started or stopped on display 850A.

[0123] Display 850B may output GUI 822C associated with a list of enrolled user profiles that may be started on display 850B. Display 850B may include a physical or virtual passenger display. In some instances, display 850B may output GUI 822C by default when the vehicle operating system boots up. In some examples, display 850B may output GUI 822C responsive to UP application 792 of FIG. 7 initiating a logoff or stop of a user profile on display 850B. GUI 822C may include list of enrolled user profiles 836. In some examples, list of enrolled user profiles 836 may include enrolled user profiles that are currently not started or logged on to other displays. In some examples, list of enrolled user profiles 836 may include an option for a user to start a guest user profile on display 850B. Display 850B may output list of enrolled user profiles 836 based on data received from UP application 792 of FIG. 7. For example, UP application 792 may send a request to vehicle user service 794 to obtain an updated list and associated state of user profiles managed by activity manager service 796. Vehicle user service 794 may obtain list of enrolled users 836 from activity manager service 796 and send list of enrolled user profiles 836 to UPapplication 792. UP application 792 may send instructions to display 850B to output list of enrolled users 836 via UI module 714.

[0124] GUI 822C may include add user 826. Add user 826 may include a detectable input that triggers UP application 792 to output a GUI for a user operating display 850B to input information associated with a creation of a new user profile. UP application 792 may receive user profile information responsive to a user selecting add user 826. UP application 792 may send user profile information associated with the new user profile to activity manager 796 via vehicle user service 794, for example. Activity manager service 796 may update list of enrolled user profiles 836 to include user profile information of the new user profile. In general, activity manager service 796 may update list of enrolled user profiles 836 to include user profile information associated with any creation, removal, or changes of user profiles that UP application 792 receives.

[0125] Display 850C may output GUI 822D associated with a guest user profile. Display 50C may include a physical or virtual passenger display. VOS 760 may support multiple guest user profiles executing on different displays. For example, display 812 and displays 850 may be assigned different guest user profiles. GUI 822D may include user dashboard 832C and user preferences 834C associated with guest user profiles. User dashboard 832C may include default or pre-established guest dashboard settings, such as a simplified home screen. User preferences 834C may include default or pre-established guest preference settings. GUI 822D may receive inputs altering data or content of user dashboard 832C and / or user preferences 834C. In some examples, UP application 792 may initiate a soft delete function of APIs 716 to delete changes made to user dashboard 832C and / or user preferences 834C. In this way, UP application 792 may reduce storage space associated with maintaining guest user profiles and free up space for the creation of more guest user profiles. GUI 822D includes change user 824C. Change user 824C may include a detectable input that triggers a logout and / or login of the guest user profile on display 850C. Change user 824C may detect an input from a user operating display 850C and send instructions to UP application 792, via UI module 714, to request that the guest user profile be stopped and a selected user profile be started on display 850C. For example, UP application 792 may receive an input of a user selecting change user 824C. UP application 792 may invoke a stop function of activity manager service 796, via vehicle user service 794, to stop the guest user profile associated with GUI 822D. UP application 792 may also invoke a function of activity manager service 796 to delete any changes made to the guest user profile associated with GUI 822D (e.g., changes to user dashboard 832C and / or changes to user preferences 834C).UP application 792 may send instructions to display 850C, via UI module 714, to output list of enrolled users 836. Display 850C may receive an input from a user selecting a user profile from the outputted list of enrolled users 836 and relay the input to UP application 792, via UI module 714. UP application 792 may then invoke a start function of activity manager service 796 to login the selected user profile on display 850C.

[0126] FIG. 9 is a flowchart illustrating example operation of the computing system shown in FIG. 1 in executing a vehicle operating system configured to perform various aspects of the techniques described in this disclosure. As described above, one or more processors 140 of computing device 102 may execute an instance of a vehicle operating system, such as VOS 160A or VOS 160B, wherein VOS 160A and / or 160B facilitates concurrent access by multiple user profiles that are shown in the example of FIG. 1 as user profiles (UP) 161 A- 161N (“UP 161”) for VOS 160A and UP 163A-163N (“UP 163”) for VOS 160B (900).

[0127] Processors 140 may invoke, as one example, a start function of an API (e.g., APIs 116A) exposed by VOS 160A to associate a first user profile with a first display of a plurality of displays (902). For example, UI module 114A may invoke a start function of APIs 116A to associate UP 161 A with display 112. Processors 140 may present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display (904). For example, VOS 160A may send instructions to display 112 to output a user interface (e.g., GUI 822A of FIG. 8) that provides a user experience based at least in part UP 161 A being associated with display 112.

[0128] Processors 140 may invoke the start function of the API to associate a second user profile with a second display of the plurality of displays (906). For example, UI module 114A may invoke a start function of APIs 116A to associate UP 161N with display 150A. Processors 140 may present, via the second display, a second user interface that provides a second user experience based at least in part on the second user profile being associated with the second display (908). For example, VOS 160 A may send instructions to display 150A to output a user interface (e.g., GUI 822B of FIG. 8) that provides a user experience based at least in part UP 16 IN being associated with display 150A.

[0129] FIG. 10 is a block diagram illustrating a single-instance, multi-user vehicle operating system 1060 providing multi-user experiences according to various aspects of the techniques described in this disclosure. In the example of FIG. 10, VOS 1060 may represent one example of VOS 160A and / or VOS 160B shown in the example of FIG. 1. As discussed above, VOS 1060 may operate in a kernel space that provides increased privileges (e.g., access rights, dedicated memory, etc.) that hosts an application space 1079 have reducedprivileges relative to the kernel space in order to moderate access by applications, including user profile (UP) application 1092 and distraction optimized (DO) application 1080 (“UP application 1092” and "DO application 1080,” which may, although not shown in the example of FIG. 1, be stored to storage devices 148).

[0130] VOS 1060 may include UX manager 1062 and UX manager service 1064. UX manager 1062 may represent a software module (executed by underlying hardware, such as processors 140, that cause processors 140) to manage user experiences associated with registered applications (which register via the above noted API, which may be an API exposed by UX manager 1062). UP application 1092 may invoke the API to get current user experiences or user interfaces associated with a user profile started or stopped on a particular display. UX manager service 1064 may represent a service executing within VOS 1060 that manages a user experience associated with a user profile started on a display. For example, UX manager service 1064 may represent an example of vehicle user service 794, activity manager service 796, and / or vehicle occupant zone service 798 of FIG. 7.

[0131] UP application 1092 may request UX manager 1062 to invoke functions of UX manager service 1064 to provide a user experience to a display based on a user profile started on the display. For example, UX manager 1062 may invoke a start function of UX manager service 1064 to login into a default or selected user profile (e.g., UP 161 A) on a display (e.g., display 112). UX manager 1062 may invoke a start function and / or a stop function of UX manager service 1064 that may include assigning and / or unassigning, respectively, the default or selected user profile (e.g., UP 161 A) to a corresponding occupant zone identifier (e.g., OZIDs 165) or display type (e.g., DTs 171) associated with the display in which the default or selected user profile is to be started on (e.g., display 112). In some instances, UP application 1092 may instruct UX manager 1062 to invoke a start or stop function to login or logout a user profile from a display, and send instructions to DO application 1080 to update a user experience associated with the selected or default user profile with user experience restrictions based on display type and / or an occupant zone identifier.

[0132] VOS 1060, as further shown in the example of FIG. 1, includes a UXR manager 1082, a UXR manager service 1084, an operational state service 1086, a vehicle property service 1088, and a vehicle package manager service 1090. UXR manager 1082 may represent a software module (executed by underlying hardware, such as processors 140, that cause processors 140) to manage UXR for registered applications (which register via the above noted API, which may be an API exposed by UXR manager 1082). DO application 1080may invoke the API to get current UXR for DO application 880, while also registering a listening service for DO application 1080 to receive updates to or a replacement for UXR.

[0133] UXR manager service 1084 may represent a service executing within VOS 1060 that manages UXR map 1083 based on various properties or updates relative to UP 161 / 163, DT 171 / 173, operational state of the vehicle, such as vehicle 200 shown in the example of FIG. 2 (where such operational state may include driving state, idle state, parked state, speed changes, etc.), and application type (which in this example is assumed to be distraction optimized). Operational state service 1086 may represent a service of VOS 1060 that identifies an operational state of vehicle 200. Vehicle property service 1088 may represent a service that identifies various properties (e.g., current speed, seat belt status for occupants, location, mirror configuration, seat configuration, etc.) of vehicle 200. Vehicle package manager service 1090 may represent a service responsible for managing UXR for applications throughout the duration of authorization for UP 161 / 163 to access or otherwise interface with VOS 1060, including DO application 1080, on a per display basis (whether virtual or physical).

[0134] UP 161 / 163 may initially be authorized to access VOS 1060 in the manner described above, whereupon or during authorization, VOS 1060 may determine OZID 165 / 167 as well as possibly DT 171 / 173 (when virtual displays are present or created by UP 161 / 163) for each UP 161 / 163 authorized to access VOS 1060. More specifically, UXR manager service 1084 may map particular UP 161 / 163 to one or more of OZID 165 / 167 and potentially DT 171 / 173, creating UXR map 1083 (which may be updated via UXR manager 1082).

[0135] UXR manager service 1084 may interface with operational state service 1086 to obtain a current operational state of vehicle 200. UXR manager service 1084 may also interface with vehicle property service 1088 to obtain vehicle properties (e.g., speed changes). UXR manager service 1084 may determine, based on OZID 165 / 167 and possibly DT 171 / 173, the operational state, and vehicle properties, UXR for DO application 1080. UXR manager service 1084 may provide the determined UXR to vehicle package manager service 1090, which performs activity blocking (e.g., restricting content from being consumed via one or more of the multiple displays).

[0136] Via the listening service, DO application 1080 may receive the UXR and adapt the presentation of content to conform to the UXR provided via the listening service. Non-DO applications may, rather than adapt presentation of content to conform to the UXR provided via the listening service, continue to present content without adhering to the provided UXR, at which point vehicle package manager service 890 may perform activity blocking (or, inother words, content restriction) to ensure non-DO applications continue to conform to the determined UXR.

[0137] UXR manager service 1084 may update UXR map 1083 to specify the set of UXR determined for each OZID 165 / 167 and possible DT 171 / 173. UXR map 1083 may associate (or, in other words, map) operational states (such as a driving state, an idle state, and a parked state) to a set of restrictions that limit presentation of a dial pad (e.g., for initiating a telephone or video call), presentation of a keyboard (e.g., for searching, web browsing, texting, etc.), presentation of video or other content, and / or full restricted (in which case no content or at least the content specified above as a dial pad, keyboard, and video, may be presented). Any changes to UXR map 1083 may trigger a listening service to issue an interrupt or other flag or mechanism by which to inform DO application 880 of the UXR update and / or changes.

[0138] Given that UXR map 1083 may be specified granularly on a per display (whether virtual or physical) relative to OZID 165 / 167, UXR map 1083 may allow for different UXR for each display communicatively coupled to VOS 1060. As such, VOS 1060 may assign display 250A a different UXR than display 250B despite both of displays 250A and 250B being rear passenger displays for which distraction is not generally considered a safety concern in terms of distracting the operator sitting in the front driver occupant zone of vehicle 200. In instances where content is shared or there is collaboration between different occupant zones as described above, each individual UXR for each occupant zone may be enforced, which may result in different user experiences suitable for the determined level of distraction to the operator sitting in the front operator occupant zone of the vehicle.

[0139] While described above with respect to occupant zone identifiers, VOS 1060 may continue to rely on a physical port for physical displays that do not allow for the creation or support of virtual displays. That is, VOS 1060 may maintain backwards compatibility with identifying displays based on a physical port (or a virtual port for wireless physical displays) by which physical displays are communicatively coupled to vehicle head unit 202 and / or VOS 1060. In other words, while VOS 1060 may support an extension in which OZID 165 / 167 and possible DT 171 / 173 are used to uniquely identify both physical displays and virtual displays, VOS 1060 may continue to support physical port identifiers for uniquely identifying physical displays in order to maintain backward compatibility.

[0140] FIG. 11 is a flowchart illustrating example operation of VOS shown in the example of FIG. 10 in performing various aspects of the techniques described in this disclosure. A vehicle head unit, such as a vehicle head unit 102 and / or 202 shown in the examples of FIGS.1 and / or 2, may execute an instance of a vehicle operating system (such as vehicle operating system 1060), which may facilitate concurrent access by multiple user profiles (1100). VOS 1060 may authorize multiple UP 161 / 163 to interface with VOS 1060 via multiple displays (e.g., display 212, virtual displays 213A / 213B, physical displays 250A / 250B) to interface with VOS 1060 via multiple displays 212 / 213 / 250 communicatively coupled to vehicle head unit 102 / 202 (1102).

[0141] VOS 1060 may determine, based on which of multiple displays 212 / 213 / 250 with which each of UP 161 / 163 interfaced to authorize each of UP 161 / 163, one or more OZIDs 165 / 167 (1104). VOS 1060 may obtain, based on OZIDs 165 / 167, and for each of UP 165 / 167, user experience restrictions (UXR) that restrict content presented via each of displays 212 / 213 / 250 for each of UP 161 / 163 (1106). VOS 1060 may next restrict, via multiple user interfaces presented across multiple displays 212 / 213 / 250 by VOS 1060 and in accordance with UXR, the content with which at least one of UP 161 / 163 consume (1108).

[0142] In this way, the above described techniques may enable the following examples:

[0143] Example 1 : A method includes executing, by a vehicle head unit included in a vehicle, an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoking a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; presenting, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoking the start function of the API to associate a second user profile with a second display of the plurality of displays; and presenting, via the second display, a second user interface that provides a second user experience based at least in part on the second profile being associated with the second display.

[0144] Example 2: The method of example 1, further includes invoking a stop function of the API to disassociate the first user profile with the first display; invoking the start function of the API to associate a third user profile with the first display; presenting, via the first display, a third user interface that provides a third user experience based at least in part on the third user profile being associated with the first display.

[0145] Example 3: The method of example 2, wherein invoking the stop function of the API to disassociate the first user profile with the first display comprises: unassigning the first user profile from an occupant zone associated with the first display.

[0146] Example 4: The method of any of examples 1 through 3, wherein invoking the start function of the API to associate the second user profile with the second display comprises assigning the second user profile to an occupant zone associated with the second display.

[0147] Example 5: The method of example 4, wherein the occupant zone includes one of a front operator zone, a front passenger zone, an operator-side rear passenger zone, and a passenger-side rear passenger zone.

[0148] Example 6: The method of any of examples 4 and 5, further includes providing the second user experience based on a display type and the occupant zone associated with the second user profile, wherein the display type indicates that at least one of the plurality of displays is a virtual display that is presented by at least one physical display of the plurality of displays.

[0149] Example 7: The method of any of examples 1 through 6, wherein presenting the first user interface that provides the first user experience comprises: providing the first user experience based on an operational state of the vehicle, wherein the operational state of the vehicle comprises a driving state, an idle state, or a parked state.

[0150] Example 8: The method of any of examples 1 through 7, wherein at least one display of the plurality of displays outputs a list of user profiles.

[0151] Example 9: The method of any of examples 1 through 8, wherein the first user profile is a default user profile.

[0152] Example 10: The method of any of examples 1 through 9, wherein at least one of the first user profile and the second user profile are guest profiles.

[0153] Example 11 : The method of any of examples 1 through 10, wherein the plurality of displays are displaced about a cabin of the vehicle that include the vehicle head unit.

[0154] Example 12: The method of any of examples 1 through 11, wherein the plurality of displays include two or more of: the first display, the second display, a third display, and a fourth display.

[0155] Example 13: The method of any of examples 1 through 12, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the method further comprises executing a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0156] Example 14: A computing device includes a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitatesconcurrent access by multiple user profiles; processing circuitry configured to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoke the start function of the API to associate a second user profile with a second display of the plurality of displays; and present, via the second display, a second user interface that provides a second user experience based at least in part on the second user profile being associated with the second display.

[0157] Example 15: The computing device of example 14, wherein the instance of the vehicle operating system is further configured to: invoke a stop function of the API to disassociate the first user profile with the first display; invoke the start function of the API to associate a third user profile with the first display; present, via the first display, a third user interface that provides a third user experience based at least in part on the third user profile being associated with the first display.

[0158] Example 16: The computing device of example 15, wherein to invoke the stop function of the API to disassociate the first user profile with the first display, the instance of the vehicle operating system is configured to unassign the first user profile from an occupant zone associated with the first display.

[0159] Example 17: The computing device of any of examples 14 through 16, wherein to invoke the start function of the API to associate the second user profile with the second display, the instance of the vehicle operating system is configured to assign the second user profile to an occupant zone associated with the second display.

[0160] Example 18: The computing device of example 17, wherein the occupant zone includes one of a front operator zone, a front passenger zone, an operator-side rear passenger zone, and a passenger-side rear passenger zone.

[0161] Example 19: The computing device of any of examples 17 and 18, wherein the instance of the vehicle operating system is further configured to: provide the second user experience based on a display type and the occupant zone associated with the second user profile, wherein the display type indicates that at least one of the plurality of displays is a virtual display that is presented by at least one physical display of the plurality of displays.

[0162] Example 20: The computing device of any of examples 14 through 19, wherein to present the first user interface that provides the first user experience, the instance of the vehicle operating system is configured to provide the first user experience based on an operational state of the vehicle, wherein the operational state of the vehicle comprises a driving state, an idle state, or a parked state.

[0163] Example 21 : The computing device of any of examples 14 through 20, wherein at least one display of the plurality of displays outputs a list of user profiles.

[0164] Example 22: The computing device of any of examples 14 through 21, wherein the first user profile is a default user profile.

[0165] Example 23: The computing device of any of examples 14 through 22, wherein at least one of the first user profile and the second user profile are guest profiles.

[0166] Example 24: The computing device of any of examples 14 through 23, wherein the plurality of displays are displaced about a cabin of the vehicle that include the vehicle head unit.

[0167] Example 25: The computing device of any of examples 14 through 24, wherein the plurality of displays include two or more of: the first display, the second display, a third display, and a fourth display.

[0168] Example 26: The computing device of any of examples 14 through 25, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the instance of the vehicle operating system is further configured to: execute a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0169] Example 27: Computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to: execute an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoke the start function of the API to associate a second user profile with a second display of the plurality of displays; and present, via the second display, a second userinterface that provides a second user experience based at least in part on the second user profile being associated with the second display.

[0170] Example 28: The computer-readable storage medium of example 27, wherein the instructions further cause the one or more processors to: invoke a stop function of the API to disassociate the first user profile with the first display; invoke the start function of the API to associate a third user profile with the first display; present, via the first display, a third user interface that provides a third user experience based at least in part on the third user profile being associated with the first display.

[0171] Example 29: The computer-readable storage medium of example 28, wherein to invoke the stop function of the API to disassociate the first user profile with the first display, the instructions cause the one or more processors to unassign the first user profile from an occupant zone associated with the first display.

[0172] Example 30: The computer-readable storage medium of any of examples 27 through 29, wherein to invoke the start function of the API to associate the second user profile with the second display, the instructions cause the one or more processors to assign the second user profile to an occupant zone associated with the second display.

[0173] Example 31 : The computer-readable storage medium of example 30, wherein the occupant zone includes one of a front operator zone, a front passenger zone, an operator-side rear passenger zone, and a passenger-side rear passenger zone.

[0174] Example 32: The computer-readable storage medium of any of examples 30 and 31, wherein the instructions further cause the one or more processors to: provide the second user experience based on a display type and the occupant zone associated with the second user profile, wherein the display type indicates that at least one of the plurality of displays is a virtual display that is presented by at least one physical display of the plurality of displays.

[0175] Example 33: The computer-readable storage medium of any of examples 27 through32, wherein to present the first user interface that provides the first user experience, the instructions cause the one or more processors to provide the first user experience based on an operational state of the vehicle, wherein the operational state of the vehicle comprises a driving state, an idle state, or a parked state.

[0176] Example 34: The computer-readable storage medium of any of examples 27 through33, wherein at least one display of the plurality of displays outputs a list of user profiles.

[0177] Example 35: The computer-readable storage medium of any of examples 27 through34, wherein the first user profile is a default user profile.

[0178] Example 36: The computer-readable storage medium of any of examples 27 through35, wherein at least one of the first user profile and the second user profile are guest profiles.

[0179] Example 37: The computer-readable storage medium of any of examples 27 through36, wherein the plurality of displays are displaced about a cabin of the vehicle that include the vehicle head unit.

[0180] Example 38: The computer-readable storage medium of any of examples 27 through37, wherein the plurality of displays include two or more of: the first display, the second display, a third display, and a fourth display.

[0181] Example 39: The computer-readable storage medium of any of examples 27 through38, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the instructions further cause the one or more processors to execute to a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0182] Example 40: A computer program product includes execute an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoke a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; present, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoke the start function of the API to associate a second user profile with a second display of the plurality of displays; and present, via the second display, a second user interface that provides a second user experience based at least in part on the second user profile being associated with the second display.

[0183] Example 41 : The computer program product of example 40, wherein the instructions further cause the at least one processor to: invoke a stop function of the API to disassociate the first user profile with the first display; invoke the start function of the API to associate a third user profile with the first display; present, via the first display, a third user interface that provides a third user experience based at least in part on the third user profile being associated with the first display.

[0184] Example 42: The computer program product of example 41, wherein to invoke the stop function of the API to disassociate the first user profile with the first display, theinstructions cause the at least one processor to unassign the first user profile from an occupant zone associated with the first display.

[0185] Example 43: The computer program product of any of examples 40 through 42, wherein to invoke the start function of the API to associate the second user profile with the second display, the instructions cause the at least one processor to assign the second user profile to an occupant zone associated with the second display.

[0186] Example 44: The computer program product of example 43, wherein the occupant zone includes one of a front operator zone, a front passenger zone, an operator-side rear passenger zone, and a passenger-side rear passenger zone.

[0187] Example 45: The computer program product of any of examples 43 and 44, wherein the instructions further cause the at least one processor to: provide the second user experience based on a display type and the occupant zone associated with the second user profile, wherein the display type indicates that at least one of the plurality of displays is a virtual display that is presented by at least one physical display of the plurality of displays.

[0188] Example 46: The computer program product of any of examples 40 through 45, wherein to present the first user interface that provides the first user experience, the instructions cause the at least one processor to provide the first user experience based on an operational state of the vehicle, wherein the operational state of the vehicle comprises a driving state, an idle state, or a parked state.

[0189] Example 47: The computer program product of any of examples 40 through 46, wherein at least one display of the plurality of displays outputs a list of user profiles.

[0190] Example 48: The computer program product of any of examples 40 through 47, wherein the first user profile is a default user profile.

[0191] Example 49: The computer program product of any of examples 40 through 48, wherein at least one of the first user profile and the second user profile are guest profiles.

[0192] Example 50: The computer program product of any of examples 40 through 49, wherein the plurality of displays are displaced about a cabin of the vehicle that include the vehicle head unit.

[0193] Example 51 : The computer program product of any of examples 40 through 50, wherein the plurality of displays include two or more of: the first display, the second display, a third display, and a fourth display.

[0194] Example 52: The computer program product of any of examples 40 through 51, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the instructions further cause the at least one processor to executea second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0195] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer- readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0196] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, ultra Blu-ray, etc. where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope of computer-readable media.

[0197] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used may refer to any of the foregoing structures or any other structure suitable for implementation of the techniques described. In addition, in some aspects, the functionality described may be provided within dedicated hardware and / or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0198] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0199] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: executing, by a vehicle head unit included in a vehicle, an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; invoking a start function of an application programming interface (API) exposed by the instance of the vehicle operating system to associate a first user profile with a first display of a plurality of displays communicatively coupled to the vehicle head unit; presenting, via the first display, a first user interface that provides a first user experience based at least in part on the first user profile being associated with the first display; invoking the start function of the API to associate a second user profile with a second display of the plurality of displays; and presenting, via the second display, a second user interface that provides a second user experience based at least in part on the second profile being associated with the second display.

2. The method of claim 1, further comprising: invoking a stop function of the API to disassociate the first user profile with the first display; invoking the start function of the API to associate a third user profile with the first display; and presenting, via the first display, a third user interface that provides a third user experience based at least in part on the third user profile being associated with the first display.

3. The method of claim 2, wherein invoking the stop function of the API to disassociate the first user profile with the first display comprises: unassigning the first user profile from an occupant zone associated with the first display.

4. The method of claim 1, wherein invoking the start function of the API to associate the second user profile with the second display comprises assigning the second user profile to an occupant zone associated with the second display.

5. The method of claim 4, wherein the occupant zone includes one of a front operator zone, a front passenger zone, an operator-side rear passenger zone, and a passenger-side rear passenger zone.

6. The method of claim 4, further comprising: providing the second user experience based on a display type and the occupant zone associated with the second user profile, wherein the display type indicates that at least one of the plurality of displays is a virtual display that is presented by at least one physical display of the plurality of displays.

7. The method of claim 1, wherein presenting the first user interface that provides the first user experience comprises: providing the first user experience based on an operational state of the vehicle, wherein the operational state of the vehicle comprises a driving state, an idle state, or a parked state.

8. The method of claim 1, wherein at least one display of the plurality of displays outputs a list of user profiles.

9. The method of claim 1, wherein the first user profile is a default user profile.

10. The method of claim 1, wherein at least one of the first user profile and the second user profile are guest profiles.

11. The method of claim 1, wherein the plurality of displays are displaced about a cabin of the vehicle that include the vehicle head unit.

12. The method of claim 1, wherein the plurality of displays include two or more of: the first display, the second display, a third display, and a fourth display.

13. The method of claim 1, wherein the instance of a vehicle operating system comprises a first instance of the vehicle operating system, wherein the method further comprises executing a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface by which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

14. A computing device comprising means for performing any of the methods of claims 1-13.

15. A computing system comprising means for performing any of the methods of claims 1-13.

16. A computer-readable storage medium encoded with instructions that cause one or more processors of a computing system to perform any of the methods of claims 1-13.

17. A computer program product comprising at least one non-transitory computer- readable media including one or more instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods of claims 1-13.

Images