Multi-user experience constraints for vehicle operating systems

Abstract

A computing device includes 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 a plurality of user profiles); and processing circuitry configured to execute the instance of the VOS. The VOS may authorize a plurality of user profiles to interact with an instance of a vehicle operating system via a plurality of displays communicatively coupled to a vehicle host unit, and determine an occupant area identifier based on which of the plurality of displays each of the plurality of user profiles interacts with to authorize each of the plurality of user profiles. The VOS may also obtain a user experience constraint for each of the plurality of user profiles based on the occupant area identifier, and constrain content across a plurality of user interfaces presented across the plurality of displays via a single instance of the VOS according to the user experience constraint.

Description

[0001] This application claims priority to U.S. Provisional Application Serial No. 63 / 371,445, filed on August 15, 2022, entitled “CONTEXT AWARE SAFETY FEATURES FOR VEHICLE OPERATING SYSTEMS,” and U.S. Provisional Application Serial No. 63 / 371,451, filed on August 15, 2022, entitled “SINGLE-INSTANCE MULTI-USERSUPPORT FOR VEHICLE OPERATING SYSTEMS,” each of which is incorporated herein by reference as if set forth herein in their respective entireties. Background Art

[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 (to provide a few examples) entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as control of 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.). The vehicle operating system 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. Although an 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 from the multiple user profiles to access (or in other words "log in") 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 is not distracted by the behavior of other user profiles when operating the vehicle. Summary of the invention

[0003] In general, various aspects of the technology described in the present disclosure relate to a single instance of a vehicle operating system that provides concurrent multi-user support. Rather than limiting access to a single user profile to a single instance of a vehicle operating system, a single instance of a vehicle operating system described in the present disclosure may allow multiple user profiles to access a single instance of the vehicle operating system. As vehicles have begun to integrate more and more displays within the vehicle's cabin, more users can safely interact with the vehicle operating system without distracting the operator of the vehicle (considering that in some examples, the operator has a limited field of view of these displays or no direct field of view of these displays, which may be set behind the operator for rear seat passengers). Therefore, multiple users associated with multiple user profiles can access the vehicle operating system 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 depend to some extent on the multiple user locations within the vehicle).

[0004] Multiple users may also interact with the vehicle operating system to jointly coordinate activities among the multiple users, such as sharing content among the multiple users, reviewing content viewed by other users of the multiple users, controlling audio playback among the multiple users (such as changing audio playback volume, coordinating playlists, etc.), messaging among the multiple users, collaborating on navigation directions by the multiple users, etc. In some cases, the multiple users may use gestures (such as swipe gestures, pinch gestures, and tap gestures) to indicate sharing of such content, which may allow for intuitive control of sharing among the multiple users.

[0005] Thus, various aspects of the technology described in the present disclosure can facilitate a better user experience while the vehicle is in motion, while still retaining the safety concerns of distracting the operator of the vehicle. By allowing multiple user profiles to access the vehicle operating system, the vehicle operating system can customize the user experience according to each individual user profile, thereby allowing preferences specific to each individual user profile to be applied. The vehicle operating system can also allow multiple users to coordinate activities (as noted above), which can improve the user experience while the vehicle is in motion. Given that the additional display (which can be separate from the main display of the vehicle head unit) can be located in the vehicle cabin where the operator of the vehicle cannot directly see the presented content, the vehicle operating system can allow for increased permissions in terms of access to content while also potentially limiting any distractions for the operator.

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

[0007] In this regard, different user experience constraints may be assigned to different occupants of a vehicle based not only on an occupant zone identifier associated with each of a plurality of displays but also potentially based on a display type (e.g., a virtual display or a physical display) and potentially a driving state (e.g., a parking state, an idle state, or a driving state). In combination with these different identifiers, display types, and vehicle states, fine control of presented applications (which may be non-distraction optimized applications and distraction optimized applications) or other user interfaces may be allowed via a user interface presented by a single operating system. This fine control of user experience constraints may provide a better user experience based on the occupant zone, display type, and possible vehicle state, and better prevent the driver of the vehicle from being distracted. Therefore, the techniques described in the present disclosure may improve the user experience of occupants of a vehicle implementing various aspects of the techniques described in the present disclosure, while also potentially providing a safer operating experience for the driver by preventing distractions that may cause vehicle operating failures.

[0008] In one example, the present disclosure describes a method comprising: executing, by a vehicle head unit, an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; authorizing, by the instance of the vehicle operating system, multiple user profiles to interact with the instance of the vehicle operating system; presenting, by the instance of the vehicle operating system, multiple user interfaces across multiple displays communicatively coupled to the vehicle head unit, each of the multiple user interfaces being associated with one or more user profiles of a plurality of user profiles; and interacting, via the multiple user interfaces, with multiple users associated with one or more user profiles of the plurality of user profiles to enable multiple users to interact with the instance of the vehicle operating system in order to control functionality associated with the vehicle head unit.

[0009] In another example, the present disclosure describes a computing device comprising: a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; one or more processors, the one or more processors being used to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: authorize multiple user profiles to interact with the instance of the vehicle operating system; and present multiple user interfaces across multiple displays communicatively coupled to a vehicle head unit, each of the multiple user interfaces being associated with one or more user profiles of the multiple user profiles, wherein the multiple user interfaces are configured to interact with multiple users associated with the one or more user profiles of the multiple user profiles to enable the multiple users to interact with the instance of the vehicle operating system to control functionality associated with the vehicle head unit.

[0010] In another example, the present disclosure describes a 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; authorize multiple user profiles to interact with the instance of the vehicle operating system via execution of a first instance of the vehicle operating system; present multiple user interfaces across multiple displays communicatively coupled to a vehicle head unit via execution of the first instance of the vehicle operating system, each of the multiple user interfaces being associated with one or more user profiles of a plurality of user profiles; and interact with multiple users associated with one or more user profiles of the plurality of user profiles via the multiple user interfaces to enable the multiple users to interact with the instance of the vehicle operating system in order to control functionality associated with the vehicle head unit.

[0011] In another example, the present disclosure describes a computing device comprising: components for executing an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; components for authorizing multiple user profiles to interact with the instance of the vehicle operating system; components for presenting multiple user interfaces across multiple displays communicatively coupled to a vehicle head unit, each of the multiple user interfaces being associated with one or more user profiles of a plurality of user profiles; and components for: interacting with multiple users associated with one or more user profiles of the plurality of user profiles via the multiple user interfaces to enable the multiple users to interact with the instance of the vehicle operating system in order to control functionality associated with the vehicle head unit.

[0012] In another example, the present disclosure describes a method comprising: executing an instance of a vehicle operating system by a vehicle head unit included in a vehicle, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; authorizing, by the instance of the vehicle operating system, the multiple user profiles to interact with the instance of the vehicle operating system via multiple displays communicatively coupled to the vehicle head unit; determining one or more occupant area identifiers based on which display of the multiple displays each of the multiple user profiles interacts with to authorize each of the multiple user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the multiple user profiles is associated; obtaining a user experience constraint for each of the multiple user profiles based on the one or more occupant area identifiers, the user experience constraint constraining content presented via each of the multiple displays for each of the multiple user profiles; and constraining content consumed by at least one of the multiple user profiles through multiple user interfaces presented across the multiple displays via a single instance of the vehicle operating system based on the user experience constraint.

[0013] In another example, the present disclosure describes a computing device comprising: a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; a processing circuit system configured to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: authorize multiple user profiles to interact with the instance of the vehicle operating system via multiple displays communicatively coupled to a vehicle head unit; determine one or more occupant area identifiers based on which display of the multiple displays each user profile of the multiple user profiles interacts with to authorize each of the multiple user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the multiple user profiles of the multiple user profiles is associated; obtain a user experience constraint for each of the multiple user profiles based on the one or more occupant area identifiers, the user experience constraint constraining content presented via each of the multiple displays for each of the multiple user profiles; and constrain content consumed by at least one of the multiple user profiles through multiple user interfaces presented across the multiple displays via a single instance of the vehicle operating system in accordance with the user experience constraint.

[0014] In another example, the present disclosure describes a 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; authorize multiple user profiles to interact with the instance of the vehicle operating system via execution of a first instance of the vehicle operating system; determine one or more occupant area identifiers based on which of a plurality of displays each of the plurality of user profiles interacts with to authorize each of the plurality of user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the plurality of user profiles is associated; obtain user experience constraints for each of the plurality of user profiles based on the one or more occupant area identifiers, the user experience constraints constraining content presented via each of the plurality of displays for each of the plurality of user profiles; and constrain content consumed by at least one of the plurality of user profiles via a plurality of user interfaces presented across the plurality of displays via a single instance of the vehicle operating system in accordance with the user experience constraints.

[0015] In another example, the present disclosure describes an apparatus comprising: a component for executing an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; a component for authorizing multiple user profiles to interact with the instance of the vehicle operating system via multiple displays communicatively coupled to a vehicle head unit; a component for determining one or more occupant area identifiers based on which of the multiple displays each of the multiple user profiles interacts with to authorize each of the multiple user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the multiple user profiles is associated; a component for obtaining a user experience constraint for each of the multiple user profiles based on the one or more occupant area identifiers, the user experience constraint constraining content presented via each of the multiple displays for each of the multiple user profiles; and a component for constraining content consumed by at least one of the multiple user profiles based on the user experience constraint via multiple user interfaces presented across the multiple displays by a single instance of the vehicle operating system.

[0016] 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 THE DRAWINGS

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

[0018] Figure 2 is a diagram illustrating an example of a vehicle including 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.

[0019] Figure 3 is a diagram illustrating different interaction models with multiple displays according to the vehicle operating system techniques described in this disclosure, including interactions occurring via a single-instance multi-user model and a multi-instance multi-user model.

[0020] Figure 4 is a diagram illustrating an example vehicle including a vehicle head unit configured to control audio content according to various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure.

[0021] Figure 5 and Figure 6 is a diagram illustrating audio control in a single-instance, multi-user vehicle operating system according to various aspects of the techniques described in this disclosure.

[0022] Figure 7 is an example Figure 1 A flowchart of example operations of a computing system shown in executing a vehicle operating system configured to perform various aspects of the techniques described in this disclosure.

[0023] Figure 8 is an example Figure 1 The illustrated VOS provides a block diagram of multiple user experience constraints in accordance with various aspects of the techniques described in this disclosure. DETAILED DESCRIPTION

[0024] Figure 1 is a block diagram illustrating an example computing system configured to provide a single-instance, multi-user vehicle operating system according to various aspects of the techniques described in this disclosure. Figure 1 As shown in the example of FIG. 1 , computing system 100 includes computing device 102. Although described with respect to a vehicle, computing system 100 may be used in different contexts, including stand-alone computing systems (including laptops, desktop computers, workstations, etc.), gaming systems, cellular phones (including so-called “smart phones”), media systems (including streaming media systems), audio / visual (A / V) receivers, televisions (including so-called “smart TVs”), smart speakers, smart watches, thermostats (including so-called “smart thermostats”), smart glasses, or any other computing system.

[0025] In any case, computing device 102 is an example of a vehicle computing device, such as a vehicle head unit. Figure 1Only one particular example of computing device 102 is illustrated, and many other examples of computing device 102 may be used in other instances and may include a subset of the components included in the example computing device 102, or may include Figure 1 Additional components not shown.

[0026] like Figure 1 As further shown in the example of , the computing device 102 includes a presence-sensitive 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, one or more storage devices 148, and a communication channel 149. The communication channel 149 can interconnect each of the components 112, 140, 142, 146, and / or 148 for inter-component communication (physically, communicatively, and / or operationally), and thereby allow the components 112, 140, 142, 146, and 148 to communicate with each other. In some examples, the communication channel 149 may include a system bus, a network connection, one or more inter-process communication data structures, or any other component for communicating data (also referred to as information). Although shown as including components 112, 140, 142, 146, and 148, the computing device 102 (which may be referred to as the "host computing device 102") may include other components or fewer components than those shown, where such components may be included in other control units such as a telematics control unit (TCU).

[0027] One or more communication units 142 of computing device 102 can communicate with external devices by sending and / or receiving data. For example, computing device 102 can use one or more communication units in communication unit 142 to send and / or receive radio signals on a radio network such as a cellular radio network. In some examples, communication unit 142 can send and / or receive satellite signals on a satellite network such as a global positioning system (GPS) network. Examples of communication unit 142 include network interface cards (e.g., Ethernet cards), optical transceivers, radio frequency transceivers, GPS receivers, or any other type of device that can transmit and / or receive information. Other examples of communication unit 142 may include controller area networks (CAN—operated via CAN bus) found in mobile devices and universal serial bus (USB) controllers, etc., shortwave radios (e.g., NFC, BLUETOOTH (including BLE)), GPS, 3G, 4G, 5G, and WIFI radios.

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

[0029] One or more output components 146 of computing device 102 may generate output. Examples of output are tactile output, audio output, and video output. In some examples, output components 146 of computing device 102 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), an organic light emitting diode (OLED), or any other type of device for generating tactile output, audio output, and / or visual output to a human or machine.

[0030] In some examples, presence-sensitive display 112 of computing device 102 may include the functionality of input component 144 and / or output component 146. Figure 1 In an example of , presence-sensitive display 112 may include presence-sensitive input (PSI) component 104 ("PSI component 104"), such as a presence-sensitive screen or a touch-sensitive screen. In some examples, presence-sensitive input component 104 may detect objects at and / or near presence-sensitive input component. As one example range, presence-sensitive input component 104 may detect objects, such as a finger or stylus, within two inches or less of presence-sensitive input component 104. Presence-sensitive input component 104 may determine a location (e.g., (x, y) coordinates) of the presence-sensitive input component at which the object was detected. In another example range, presence-sensitive input component 104 may detect objects within two inches or less of presence-sensitive input component 104, and other ranges are possible. Presence-sensitive input component 104 may use capacitive, inductive, and / or optical recognition techniques to determine the location of presence-sensitive input component 104 selected by a user's finger.

[0031] In some examples, presence-sensitive display 112 may also provide output to the user using tactile, audio, or video stimulation, as described with respect to output component 146. For example, 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 component 146. Although illustrated as an integrated component of computing device 102, in some examples, presence-sensitive display 112 may be an external component that shares a data or information path with other components of computing device 102 for sending and / or receiving input and output. For example, presence-sensitive display 112 may be a built-in component of computing device 102 that is located within and physically connected to an external package of computing device 102 (e.g., an in-vehicle screen installed in a dashboard of a vehicle). In another example, presence-sensitive display 112 may be an external component of computing device 102 that is located outside and physically separated from the package of computing device 102 (e.g., a monitor, projector, etc. that shares a wired and / or wireless data path with an electronic control unit of a vehicle). In some examples, presence-sensitive display 112 may be implemented by two separate components when located outside and physically separated from the packaging of computing device 102: presence-sensitive input component 104 for receiving input and display component 103 for providing output.

[0032] 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). Figure 1 As shown in the example of , one or more storage devices 148 can store a first instance of operating system 160A (OS 160A) and a second instance of operating system 160B (OS 160B). In some examples, storage component 148 is temporary storage, meaning that the primary purpose of storage component 148 is not long-term storage. Storage device 148 of computing device 102 can be configured as volatile memory for short-term storage of information, and therefore does not retain stored content in the event of a power outage. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art.

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

[0034] One or more processors 140 may implement functionality and / or execute instructions associated with the computing device 102. Examples of processors 140 include an application processor, a display controller, an auxiliary processor, 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 160B may be operable (or in other words, executed) by processor 140 to perform various actions, operations, or functions of computing device 102.

[0035] That is, OS 160A and / or OS 160B may form executable bytecodes that, when executed, cause processor 140 to perform specific operations in accordance with various aspects of the techniques described herein (and thereby make computing device 102 a special-purpose computer for execution). For example, processor 140 of computing device 102 may retrieve and execute instructions stored by storage device 148 that cause processor 140 to perform the operations described herein as being attributable to OS 160A and / or 160B. These instructions, when executed by processor 140, may cause computing device 102 to store information within storage device 148.

[0036] As described above, computing system 100 may be integrated or otherwise included in a vehicle. The vehicle may include one or more of the following: a bicycle, a tricycle, a unicycle, a motorcycle, an automobile, agricultural equipment (such as a tractor, a combine, etc.), construction equipment (dump trucks, cranes, etc.), military vehicles or equipment (tanks, weaponry, etc.), a truck, a semi-trailer (or in other words, a semi-trailer), aviation equipment (such as an airplane), marine equipment (such as a ship, a transport ship, a submarine, etc.), or any other type of vehicle.

[0037] Computing device 102 (which, as described above, may be referred to as vehicle head unit 102 and also as infotainment system 102) may be configured to execute a vehicle operating system, such as one or more of OS 160A and 160B (which may therefore also be referred to as vehicle OS 160A—VOS 160A and VOS 160B), to facilitate (to provide a few examples) entertainment (such as music, video, images, etc.), information, navigation, and voice calls, as well as control of 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 cases, the vehicle operating system 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.

[0038] The 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 regard, only a single user profile may access the single instance of the vehicle operating system at any given time.

[0039] To enable multiple concurrent user profiles, processor 140 may execute another instance of the vehicle operating system, which may require an additional processor and / or a higher processing power processor (which is generally more expensive). However, achieving efficient communication between two instances of the vehicle operating system may be difficult, making it impossible for users associated with multiple user profiles to share content with each other, thereby potentially limiting the user experience.

[0040] Thus, while an instance of a vehicle operating system may support multiple user profiles, the instance of the vehicle operating system may only allow a single user profile from 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 is not distracted by the activities of other user profiles while operating the vehicle.

[0041] Furthermore, an instance of a vehicle operating system may restrict content for a variety of reasons, including safety to prevent driver distraction (e.g., based on the operating state of the vehicle, such as driving, idle, and parked), privacy and security (e.g., through user profile constraints that may include age-based restrictions, content type restrictions, personal information security, etc.), etc. By allowing only a single user profile from multiple user profiles to access an instance of a vehicle operating system, an instance of a vehicle operating system may restrict other occupants of the vehicle from interacting with one or more displays with content that may or may not cause a distraction when operating the vehicle (e.g., a rear seat passenger display may be unnecessarily constrained to constraints configured for a single user profile that is typically associated with the driver rather than a rear seat passenger). These potentially unnecessary constraints may degrade the user experience provided to other occupants who are not actively operating the vehicle, and thereby potentially unnecessarily impact the user experience provided by a single instance of a vehicle operating system.

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

[0043] A single instance of a vehicle operating system may provide constraints for a single user profile, which may be defined based solely on the physical display port number, and which also apply to a single physical instrument panel display despite the display spanning multiple occupant zones and presenting multiple virtual displays. Thus, such constraints are even less granular because they do not allow for virtual displays, which may further degrade the user experience (e.g., given that a front passenger may be constrained to any constraints provided for the front operator occupant zone, even though presentation of content in the front passenger occupant zone may not be sufficiently intrusive to the operator of the vehicle to require such constraints).

[0044] According to 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 limiting access to a single user profile to a single instance of VOS 160, a single instance of VOS 160 described in this disclosure may allow multiple user profiles to access a single instance of VOS 160. As vehicles have begun to integrate more and more displays in the cabin of the vehicle, such as presence-sensitive enabled displays 150A-150N (“presence-sensitive enabled displays 150,” which may also be referred to as “displays 150”), more users may safely interact with VOS 160 without distracting the operator of the vehicle (given that in some examples, the operator has limited or no direct view of these displays 150, which may be located behind the operator for rear seat passengers). Thus, 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 depend to some extent on the multiple user locations within the vehicle).

[0045] Multiple users may also interact with VOS 160 to jointly coordinate activities among the multiple users, such as sharing content among the multiple users, reviewing content viewed by other users of the multiple users, controlling audio playback among the multiple users (such as changing audio playback volume, coordinating playlists, etc.), messaging among the multiple users, jointly collaborating on navigation directions by the multiple users, etc. In some cases, the multiple users may use gestures (such as swipe gestures, pinch gestures, and tap gestures) to indicate sharing of such content, which may allow for intuitive control of sharing among the multiple users.

[0046] In operation, Figure 1As shown in the example of , computing device 102 may interact with display 150, which may be similar to (if not substantially similar to) presence-sensitive display 112. However, rather than being integrated into computing device 102 similar to presence-sensitive display 112, display 150 may be communicatively coupled (via wire or wirelessly) to computing device 102 and integrated throughout a cabin of a vehicle or separate from the vehicle. That is, in some cases, display 150 may also represent a tablet, a smartphone, a laptop, a portable gaming device, a portable video device, or any other device capable of interacting with computing device 102 to present a user interface associated with VOS 160 (and / or an application executed in an application space presented by VOS 160, which application space may be separate from a privileged kernel space in which VOS 160 executes to facilitate interaction between applications and underlying hardware (such as units 112 and 140-148)).

[0047] In any case, processor 140 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 configured to access the vehicle in a manner consistent with the vehicle's operating system. Figure 1 160A and UP 163A-163N ("UP 163") of 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, but UP 161 and UP 163 may include user profiles of the same user. For example, UP 161A and UP 163A may be associated with the same user.

[0048] As one example, the processor 140 may execute the VOS 160A and authorize multiple user profiles of the UP 161 to interact with the VOS 160A. In order to authorize the multiple user profiles of the UP 161, each of the multiple users may register with the VOS 160A, thereby entering a username (associated with a given UP in the UP 161) and a password to log into the VOS 160A. Alternatively, any other means by which to log into the VOS 160A may be enabled, such as scanning a quick response (QR) code using a camera of a smartphone, entering a personal identification number (PIN), performing a biometric process (e.g., fingerprint scanning, retinal scanning, etc.), facial recognition, or any other means by which a given user profile of the UP 161 is registered with the VOS 160A. The OS 160A may compare the entered information with the authentication information stored in the UP 161 to authorize (or in other words, authenticate) each of the multiple user profiles of the UP 161 to interact with the VOS 160A.

[0049] Although discussed with respect to authentication, VOS 160A may also allow for an authorized guest user profile (as one of the UPs 161) to be provided without any authentication. In this regard, the guest user profile may provide a limited experience (compared to an authenticated UP 161) in terms of maintaining preferences, applications, etc. across different sessions, but still achieve the functionality described below with respect to sharing content between multiple UPs 161, etc.

[0050] In any case, VOS 160A may present multiple user interfaces across multiple displays (such as display 112 and one or more of display 150) communicatively coupled to computing device 102. For authenticated UPs of UP 161, VOS 160A may present a user interface specific to each of the authenticated UPs that maintains preferences in application organization, user interface themes, various VOS 160A settings (e.g., regarding notifications, accessibility, display configuration in terms of brightness, resolution, orientation, etc., and any other type of OS settings). In any case, each of the multiple user interfaces is associated with one or more of the UPs of UP 161.

[0051] The VOS 160A may then interact with multiple users associated with multiple UPs in the UPs 161 via multiple user interfaces to enable multiple users to interact with the VOS 160A to control functionality associated with the computing device 102. This functionality may include controlling navigation, changing content playback, changing user interface settings, controlling HVAC settings, sharing content between UPs 161, and other functionality described in more detail below.

[0052] In some examples, processor 140 may represent a high processing capability processor (which may be referred to as "processor 140A") and a low processing capability processor (which may be referred to as "processor 140B"). In some cases, processor 140 may represent a processor with variable processing capability, the processor having two or more distinct operating voltages, the processor implementing high processing capability at the high voltage and implementing low processing capability at the low voltage. In this sense, a single processor may represent both processor 140A and processor 140B, thereby switching between different processing modes (e.g., a high processing mode and a low processing mode) to facilitate power conservation. Processor 140A may provide additional processor cores compared to processor 140B (or in instances where a single processor switches between processing modes, implement additional cores in the high processing mode when compared to the low processing mode).

[0053] 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, phone calls, viewing images, text messaging, or other less processor-intensive tasks / applications.

[0054] In some examples, processor 140A may execute VOS 160A concurrently with processor 140B executing VOS 160B. In instances where VOS 160A and 160B execute concurrently, VOS 160A may present an interface by which VOS 160B may communicate with VOS 160A to facilitate various functionality of computing device 102. The interface may represent an application programming interface that VOS 160B may call to facilitate inter-VOS communication between VOS 160A and VOS 160B to cooperatively facilitate support for functionality provided by computing device 102.

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

[0056] like Figure 1As further shown in the example of , computing device 102 may also interact 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 representing a sound field. 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 areas of a cabin of a vehicle that includes computing device 102. These areas may include an operator area, one or more front passenger areas, and one or more rear passenger areas. As described in more detail below, 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 and support additional functionality provided by computing device 102.

[0057] In this way, various aspects of the technology can promote a better user experience when the vehicle is traveling, while still retaining the safety issues of distracting the operator of the vehicle. Since multiple UPs 161 / 163 are allowed to access the VOS 160A / 160B, the VOS 160A / 160B can customize the user experience according to each individual UP in the UP 161 / 163, thereby allowing the application of preferences specific to each individual UP. The VOS 160A / 160B system can also allow multiple users to coordinate activities (as noted above), which can improve the user experience when the vehicle is traveling. Given that the additional display 150 (which can be separated from the main display of the vehicle head unit 102, such as the presence sensitive display 112) can be located in the vehicle's cabin where the operator of the vehicle cannot directly see the presented content, the VOS 160A / 160B can allow for increased permissions in terms of access to content while also potentially limiting any distractions to the operator.

[0058] Additionally, various aspects of the technology may enable the VOS 160 to define different user experience constraints by occupant zone (OZ) and possibly display type (DT, e.g., virtual display or physical display type). Each occupant zone may be associated with an occupant zone identifier (OZID) 165A-165N ("OZID 165") and / or an OZID 167A-167N ("OZID 167") that identifies a particular occupant zone among a plurality of occupant zones (e.g., a driver occupant zone, a front passenger occupant zone, a rear seat passenger occupant zone, etc.). The VOS 160 may define different user experience constraints for each occupant zone identifier and potentially also for display types 171A-171N and / or display types 173A-173N ("DT 171 / 173," where a passenger virtual display (such as a front passenger virtual display that shares the same underlying physical display for a driver occupant virtual display) may receive less stringent user experience constraints than, for example, a driver occupant zone. Allowing different user experience constraints may allow passengers (other than the driver) to safely interact with a single operating system without distracting the driver while driving (or in other operating states of the vehicle, such as an idle state and a parked state).

[0059] In operation, VOS 160 may determine one or more OZIDs in OZIDs 165 / 167 based on which display of a plurality of displays (such as display assembly 103, additional display 150, etc.) each UP in UP 161 / 163 interacts with to authorize each UP in UP 161 / 163. Each OZID in OZIDs 165 / 167 may identify an occupant area of ​​the vehicle with which each UP in UP 161 / 163 is associated. Thus, each UP in UP 161 / 163 is associated with one or more OZIDs 165 / 167, which may allow VOS 160 to obtain user experience (UX) constraints (UXRs) specific to a given occupant area of ​​the vehicle. That is, VOS 160 may maintain a UXR mapping that defines the assignment of UXRs to each UP in UP 161 / 163 based on OZIDs 165 / 167. When attempting to authorize one or more of the UPs 161 / 163, the VOS 160 may register each of the one or more UPs 161 / 163 within a UXR map to a given OZID 165 / 167 and possibly a DT 171 / 173. The VOS 160 may assign UXRs per application executed by the VOS 160 and updated based on the operating state of the vehicle, as described in more detail below.

[0060] The VOS 160 may then constrain the content consumed by at least one of the UPs 161 / 163 via multiple user interfaces presented across multiple displays (e.g., display assembly 103, additional display 150, etc.) in accordance with the UXR defined for each of the UPs 161 / 163. Thus, the VOS 160 may tailor the UXR of a particular UP 161 / 163 based on the location of the display within the vehicle (as defined by OZID 165 / 167) (which may be virtual or physical, as defined by DT 171 / 173), which may be adapted to the operating state of the vehicle to potentially maintain safety (by limiting distraction for the operator of the vehicle) while also potentially improving the user experience for other occupants of the vehicle who are not operating the vehicle.

[0061] In this regard, different user experience constraints (as represented by UP 161 / 163) may be assigned to different occupants of a vehicle based not only on the OZID 165 / 167 associated with each of the multiple displays but also potentially based on the display type (e.g., virtual display or physical display) and driving state (e.g., parking state, idle state, or driving state). In combination with these different identifiers, display types, and vehicle states, fine control of presented applications (which may be non-distraction optimized applications and distraction optimized applications) or other user interfaces may be allowed via a user interface presented by a single operating system. This fine control of user experience constraints may provide a better user experience based on occupant zone, display type, and possible vehicle state, and better prevent distraction of the driver of the vehicle. Therefore, the techniques described in the present disclosure may improve the user experience of occupants of a vehicle implementing various aspects of the techniques described in the present disclosure, while also potentially providing a safer operating experience for the driver by preventing distractions that may cause vehicle operating failures.

[0062] Figure 2 is a diagram illustrating an example of a vehicle including 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 the present disclosure. Figure 2 As shown in the example of , the interior of vehicle 200 (which may be referred to as a “vehicle cabin”) may include a computing system in the form of a vehicle head unit 202 , which represents an example of computing device 102 .

[0063] exist Figure 2In the example of FIG. 1 , the vehicle head unit 202 is integrated into a generally central portion (e.g., center console) of a front instrument panel 220. The vehicle head unit 202 includes a display 212, which may represent an example of a presence-sensitive display 112. The display 212 may be displaced in the front instrument panel 220 of the vehicle 200. The display 212 may represent a single physical display that supports the presentation of multiple virtual displays 213A and 213B. The display 212 may present a virtual display 213A in a driver occupant area and a virtual display 213B in a front passenger occupant area.

[0064] Vehicle 200 may also include (in this example, physical) displays 250A and 250B, which may represent the above-mentioned Figure 1 An example of a display 150 is described. Displays 250A and 250B are integrated into the rear passenger compartment of the vehicle cabin on both the operator side (display 250A) and the passenger side (display 250B) (ie, Figure 2 in the headrests of the front seats in the example shown). Figure 2 Although physical displays 250A and 250B are described in the example of FIG. 1 , displays 250A and / or 250B may represent virtual displays.

[0065] As described above, VOS 160A may interact with a first user (front passenger) via a first user interface (e.g., presented by virtual display 213B) associated with a first user profile (e.g., UP 161A) to interact with content presented by a second user interface (e.g., presented by display 250B) associated with a second user profile (e.g., UP 161B) in the plurality of UPs 161. In some cases, VOS 160A may interact with the first user to do one or more of the following: view content presented by the second user interface at the first user interface or initiate playback.

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

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

[0068] Although illustrated as multiple physical displays 212 / 250, various aspects of the technology may operate with respect to a single physical display (or multiple physical displays) having separate logically separated displays (or so-called virtual displays 213A 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 an instance of the VOS 160). In this regard, a single physical display may represent multiple different displays, and the displays 212 / 250 may each represent a logically separated virtual display.

[0069] In this regard, various aspects of the techniques described herein may enable a number of different use cases, including the following: Parents want to see what their kids are watching; A parent or driver wishes to control the volume from the child display; Two or more passengers may want to contribute to a shared playlist; and Two or more passengers may want to interact with the same content (eg, multiplayer gaming). Given that these technologies allow the following use cases to be achieved: Mirror display content when running on Android Auto; Allowing drivers and passengers to mirror their displays; and Let the driver or passenger send input to someone else's passenger display (typing, rotation, D-pad, touch, etc. events).

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

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

[0072] In some cases, VOS 160A may be configured to present an animation at the first user interface indicating the initiation of the content being shared. Additionally or alternatively, VOS 160A may play audio indicating the initiation of the content being shared. In some examples, VOS 160A may play spatialized audio to reflect the positioning of the first user interface relative to the positioning of the second user interface while playing the audio indicating the initiation of the content being shared.

[0073] In this regard, various aspects of the technology may use advanced user interface techniques to make cross-display interactions (such as shared screens) more immersive. Based on the positional relationship between passenger areas in the vehicle, the technology may achieve the following: Use gestures (swipe, tap, etc.) to send content from one display to another; Use animations to visualize interactions; and Use spatial audio to show content moving to a location making it more immersive.

[0074] In addition, the VOS 160A may determine one or more OZIDs 165 / 167 based on which UP 161 / 163 is used to authenticate or otherwise authorize interaction with the VOS 160A via one or more of the displays (virtual displays 213A and / or 213B ("virtual displays 213") and / or displays 250A and / or 250B (which may be referred to as "physical displays 250")). The VOS 160A may assign an OZID 165A containing a value of zero (0) for identifying a driver occupant area to the virtual display 213A (as an example), an OZID 165B containing a value of one (1) for identifying a front passenger occupant area to the virtual display 213B (as another example), and so on.

[0075] In some cases, the VOS 160A may also identify a display type 171 / 173 that indicates (possibly a Boolean value) whether each of the displays for which the UP 161 / 163 is provided with authorization to access the VOS 160A is a physical display or a virtual display (or in other words, a virtual display 213 presented by at least one physical display 212). The VOS 160A may utilize the OZID 165 / 167 and the DT 171 / 173 to distinguish between virtual displays 213 presented via the same physical display 212 in order to appropriately assign UXRs to the UP 161 / 163. The VOS 160A may also utilize the OZID 165 / 167 and possibly the DT 171 / 173 to distinguish between displays 212, virtual displays 213, and physical displays 250, thereby assigning UXRs to the UP 161 / 163 based on one or more of the OZID 165 / 157 and the DT 171 / 173.

[0076] The VOS 160A may further determine the UXR based on the type of application executed by the VOS 160A and then presented via each of the displays 212, 213, and / or 250. That is, in some cases, various applications executed utilizing the application space presented by the VOS 160A may be distraction optimized ("DO," meaning that such applications are optimized to reduce distractions and, thus, may be executed utilizing a more restrictive UXR than non-DO applications. For example, a DO application (which may be optimized for a vehicle computing system such as the vehicle head unit 202) may constrain the type of content presented, or may improve the interface to facilitate reduced distractions compared to a non-DO application (which may be optimized for other computing platforms such as laptops, smartphones, gaming systems, smart glasses, augmented / virtual / mixed reality systems, smart watches, etc.). The VOS 160A may allow DO applications to execute in a restricted UXR while limiting or preventing non-DO applications from executing in a similarly restricted UXR.

[0077] The VOS 160A may also determine the operating state of the vehicle 200 (potentially via the VOS 160B). The operating state of the vehicle 200 may refer to various operating conditions in which the VOS 160A may present various interfaces via the display 212 / 213 / 250. Such operating conditions may include, for example, a driving state, an idle state, a parking state, etc. The VOS 160A may register each UP 161 / 163 via an API, thereby providing an OZID 165 / 167 and possibly a DT 171 / 173 determined for each UP 161 / 163. When registering each UP 161 / 163, the VOS 160A may monitor the type of application being executed by each UP 161 / 163 and the operating state of the vehicle 200, thereby updating the UXR in response to changes in the application type and the operating state of the vehicle 200.

[0078] The VOS 160A may continuously or periodically update the UXR assigned to each UP 161 / 163 according to changes in the operating state and / or application type. As an example, the VOS 160A may assign different UXRs based on the driving state, the idle state, and the parking state. The UXR for the driving state may be more restrictive than the UXR for the idle state (because distraction during the idle state represents a smaller safety issue than the driving state), and the UXR for the idle state may be more restrictive than the UXR for the parking state (where again, distraction during the parking state represents a smaller safety issue than the idle state).

[0079] Figure 3 is a diagram illustrating different interaction models with multiple displays according to the vehicle operating system technology described in this disclosure, including interactions occurring via a single instance multi-user model and a multi-instance multi-user model. As discussed in this disclosure, vehicle displays such as displays 212 and 250 are evolving from operator-centric to a whole vehicle experience, where passengers may have the following: A personally curated experience on your commute to get off work; Enjoy the shared experience of a fun family trip; and Shared experience in a ride-sharing environment

[0080] Original Equipment Manufacturers (OEMs) recognize these needs and are manufacturing cars to provide these experiences to users. These are no longer seen as high-end experiences, but rather as desired vehicle values.

[0081] In this regard, users may seek concurrent experiences across displays for a seamless and immersive experience such as: Navigation – adds stops to an ongoing journey to the driver on their display; Entertainment – ​​Play and control videos or games for children in the back seat to keep them engaged and entertained; Users – access their own curated apps, content, and data for entertainment and / or productivity; and Personalization—Control my seat settings, HVAC controls, alerts for my seats.

[0082] Based on the expected user behavior, OEMs are considering following the following user interaction models. There are 3 types of interaction models ( Figure 3 ) 1. The in-vehicle infotainment (IVI) display is the primary controller for content on the front seat entertainment (FSE) and rear seat entertainment (RSE); a. FSE and RSE have minimal controls—audio, play / pause, on / off, etc. 2. The IVI screen is mirrored across the FSE / RSE, with no content selection or control available on the passenger display; and 3. Content can be shared across all screens, with each screen having its own individual controls.

[0083] The following user images exist in a multi-monitor scenario: Driver: Interact with cluster and IVI screens for driving and interacting with other screens in the car Front seat passengers: Assisting drivers with navigation and passenger content using FSE Rear seat passengers: Interact with RSE for content, control and navigation advice to the driver Visitors: Traveling temporarily in a car and want to access some apps on the passenger display

[0084] Figure 4 is a diagram illustrating an example vehicle including a vehicle head unit configured to control audio content according to various aspects of the single-instance multi-user vehicle operating system techniques described in this disclosure. Figure 4 In the example of FIG. 4 , vehicle 400 may represent vehicle 200 ( Figure 2 400) in which vehicle head unit 202 can enable privacy and sharing between different audio zones 404A-404D ("audio zones 404") within vehicle 400. Audio zone 404A can represent the front seat operator side zone (also represented as "front operator zone 404A"). Audio zone 404B can represent the front seat passenger side zone (also represented as "front passenger zone 404B"). Audio zone 404C can represent the operator side rear passenger zone, and audio zone 404D can represent the passenger side rear passenger zone.

[0085] In each of the audio zones 404, the vehicle 200 may include a corresponding audio capture device in the audio capture devices 452A-452D ("audio capture devices 452") and a corresponding speaker in the speakers 454A-454D ("speakers 454"). The audio capture device 452 may represent an example of the audio capture device 152. The audio capture device 452 and the speaker 454 may each represent a transducer, which in the example of the audio capture device 452 can convert sound pressure into an electrical signal representing a sound field, and in the example of the speaker 454, the transducer can convert the electrical signal representing the sound field into a corresponding sound field.

[0086] Although described as having a single audio capture device 452 and a single speaker 454 in each of the audio zones 404, each of the audio zones 404 may include more or fewer audio capture devices 452 and more or fewer speakers 454. Further, although described as transducers, any type of device capable of capturing audio data (converted from electrical signals captured by the audio capture device 452) and reproducing a sound field from electrical signals (converted from audio data) may be utilized in one or more of the audio zones in the audio zones 404. Furthermore, although described as transducers, any type of device capable of capturing audio data (converted from electrical signals captured by the audio capture device 452) and reproducing a sound field from electrical signals (converted from audio data) may be utilized in one or more of the audio zones in the audio zones 404. Figure 4 Four audio zones 404 are shown in the example of FIG. 4 , but vehicle 400 may include more or fewer audio zones 404 .

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

[0088] Thus, various aspects of the technology may provide a central service for audio control for all users (e.g., driver and / or passenger) concurrently to control audio settings (volume up / down, mute, unmute, or any other control). To facilitate this control, the VOS 160A may provide services to manage audio controls (e.g., volume, mute, settings, ducking, interruptions, etc.) to provide the following: Manage controls independently for each user in each user's corresponding audio zone; Manage focus for other users in a separate area; Also taking into account current security constraints; and The current user role (driver, passenger, disabled passenger, rear seat passenger) is also taken into account.

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

[0090] In adjusting audio playback, the VOS 160A may determine a noise level based on audio data representative of the sound field present at each of the zones 404. The VOS 160A may then adjust audio playback at one or more of the zones 404 based on the noise level.

[0091] In this regard, various aspects of the technology may address how to implement multi-microphone support for the VOS 160A. The VOS 160A may use the audio data captured by the audio capture device 452 to determine and / or perform the following: Using microphones to understand which user is speaking, talking to adjust volume control by identifying the user; Map to the display being used; Provide better assistant responses for (speaking) users; Detecting the noise level around each user (their respective zone) and performing the audio changes required for audio playback to achieve comfortable audio listening; It also combines each user's audio information to determine the noise level inside the car and applies changes to the speakers for a better listening environment;

[0092] Figure 5 and Figure 6 is a diagram illustrating audio control in a single instance, multi-user vehicle operating system according to various aspects of the technology described in this disclosure. In some cases, the vehicle operating system has limited scope in that such vehicle operating system can only send audio from one zone to another zone for that specific application unique identifier (UID). Various aspects of the technology described in this disclosure enable zone 404 to share audio to the vehicle cabin for the following purposes: Share media audio from passengers to the main cabin; Providing a mechanism for passengers not in the main car to request audio playback to the main area (e.g., operator area 404A); Providing a mechanism for the driver to allow audio playback in the main zone; Providing a mechanism to share audio focus between two different zones; and Disable volume control from non-carriage owners to control volume;

[0093] For example, a passenger listening to media in a rear seat entertainment (RSE) zone (e.g., one of zones 404C or 404D) can send the audio to the main cabin to allow everyone in the car to listen to the audio. Although the passenger in the rear seat RSE would choose to send the audio to the main cabin, the operator (or main cabin user) would still maintain control over allowing the audio to play, as well as maintaining control over the volume and other audio settings.

[0094] Figure 5 A high-level overview of the current audio architecture is shown. The audio routes for each audio zone 404 are set using the audio zones 404 defined in the configuration. Each audio zone in the audio zones 404 is defined as a collection of volume groups; each group contains a set of devices that are controlled based on volume changes on the volume group. Each device can have different audio contexts routed to the device. The vehicle audio service can use the routing information for each audio zone to define a set of audio mixes that the VOS 160A can use to configure the audio routes for each zone in the zones 404.

[0095] Next reference Figure 6 , showing the configuration setup between the vehicle audio service and the vehicle occupant zone service. For audio, the vehicle audio service can read the audio zone (audioZoneId) to occupant zone Id (occupantZoneId) mapping from the configuration. This information can be sent to the car occupant zone service to set up the occupant zone configuration during initialization. The occupant zone service can maintain information about the occupant zone configuration and display port mappings, which can be read from different configuration information.

[0096] The Car Audio Service may register a VehicleOccupantZoneCallback on the Occupant Zone Service. The VOS 160A may trigger this service when there is any of the following changes to the vehicle occupant zone: Display activation; Audio configuration changes; Crew area user assignment; Passenger starts; and Passengers stop.

[0097] When the audio service receives the onOccupantZoneConfigChanged signal from the callback, the audio service of the VOS 160A may automatically assign users to their corresponding audio zones as follows: Uninstall previous user settings; Remove the previous user audio policy routing; Load audio settings for new users; Set up audio policy routing for new users; and Reset audio focus mapping for new users.

[0098] The audio service of VOS 160A may use the audio focus map to determine where incoming focus requests should be assigned.

[0099] In order to allow passengers to send audio to the main car, a few things need to be in place: Handle focus requests in the main car; and Routing passenger audio to the main car Audio routing can proceed once the focus request has been successfully changed from the passenger's own audio zone in the vehicle 400. For audio playback that has not yet begun, the focus handling will automatically request focus in the main cabin zone using the rules that have been set regarding audio usage priority (e.g., a current phone call will deny audio for media).

[0100] The passenger should be able to request that the audio be sent to the main car, and a prompt will pop up for the driver to accept. Alternatively, the driver can enable automatic permission for the passenger to play audio. If accepted, the audio focus request can be transferred to the main car (if necessary) and playback can begin. If not accepted, the passenger can be prompted with a message.

[0101] Since one goal of this functionality is to play media from passengers in the main car, focus requests from passengers can be constrained to media only. Focus requests for other sounds (e.g., alarms, calls, notifications, etc.) should remain in the passenger's corresponding zone. For media focus requests, the logic might be as follows: Send instantaneous focus loss to the passenger media app; Request focus for a passenger media app in the main car; If the focus request is granted, sending a focus gain; and If not approved due to a higher priority sound (emergency, phone call): Set the focus request to delayed focus; Focuses will be approved once higher priority focuses are completed; and Alternative: Send focus back to the user area

[0102] For passengers using userId, a possible driver for audio routing could be userid device affinity routing. This can still be used to send passenger audio to the main car, as follows: Locate the main compartment's media device (preferably a single high-quality device); and Resets passenger device affinity to media devices in shared cars.

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

[0104] Example use cases include the following: In a car, the driver can play music, while rear seat users can play their own music / media; Users in the rear seats can control the volume of their music without affecting the driver's music playback; First-party music apps launched in the rear seats can play the sound in the rear seats without any changes.

[0105] One mechanism for MZA is based on dynamic audio policies, specifically using UID / userld based routing. This may allow audio policies to define routing based on audio attribute usage, UID or userld. This may allow an application or service to take advantage of automatic routing of audio as configured by dynamic audio policies. However, there are APIs that can be used to route audio outside of the assigned audio device. This has some impact on cars, as applications can send audio to a specific zone without user permission, for example: A rear seat entertainment (RSE) application from user A sends audio directly to an output device for a driver user in the main cabin. The RSE application from user A sends the audio directly to the output device for a different RSE assigned to user B. This may raise some concerns about driver safety, as the primary driver may be distracted by unwanted audio in the primary cabin.

[0106] One possible goal of this aspect of the technology is to allow current dynamic audio policies to continue to work, but also restrict audio playback for users (and their corresponding applications / services) to playing audio outside a set of assigned zones, regardless of the mechanism used to select devices for audio playback. For users in cars, a potential benefit is that such users will be able to continue listening to audio in the car in a private and consistent manner.

[0107] Dynamic audio policies can provide a mechanism to set devices that users can use for automatic routing via the audio policy API. The audio policy API can be used or extended to restrict applications to use audio routing relative to a set of preferred devices to route audio outside of the restrictions assigned by the audio policy user. This should potentially limit "forced" routing of devices defined within the audio policy.

[0108] Figure 7 is an example Figure 1 Flowchart of example operations of a computing system as it executes a vehicle operating system configured to perform various aspects of the techniques described in the present 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 operations performed by Figure 1 160A and UP 163A-163N ("UP 163") of VOS 160B are shown as concurrent access (700) by multiple user profiles.

[0109] As one example, processor 140 may execute VOS 160A and authorize multiple user profiles of UP 161 to interact with VOS 160A (702). VOS 160A may present multiple user interfaces across multiple displays (such as display 112 and one or more of display 150) communicatively coupled to computing device 102 (704). VOS 160A may then interact with multiple users associated with multiple UPs in UP 161 via multiple user interfaces to enable multiple users to interact with VOS 160A to control functionality associated with computing device 102 (706). The functionality may include controlling navigation, changing content playback, changing user interface settings, controlling HVAC settings, sharing content between UPs 161, and other functionality described above.

[0110] Figure 8 is an example Figure 1 The VOS shown is a block diagram of providing multiple user experience constraints according to various aspects of the techniques described in this disclosure. Figure 8 In the example of Figure 1As discussed above, VOS 860 may operate in kernel space, which provides increased privileges (e.g., access rights, dedicated memory, etc.), hosting application space 879, which has reduced privileges relative to kernel space to mitigate the use of applications, including distraction optimization (DO) application 880 ("DO application 880", which although in Figure 1 , but may be stored in storage device 148) for access.

[0111] like Figure 1 As further shown in the example of , VOS 860 includes UXR manager 882, UXR manager service 884, operation status server 886, vehicle attribute service 888 and vehicle package manager service 890. UXR manager 882 may represent a software module (executed by underlying hardware such as processor 140) that manages (enables processor 140) UXR for registered applications (which are registered via the API indicated above, which may be an API exposed by UXR manager 882). DO application 880 may call the API to obtain the current UXR for DO application 880, and may also register a listening service for DO application 880 to receive updates or replacements of UXR.

[0112] UXR Manager Service 884 may represent a service executed within VOS 860 that is based on various attributes or updates relative to UP 161 / 163, DT 171 / 173, vehicle such as Figure 2 860) and the type of application (which in this example is assumed to be distraction optimized). The operating state service 886 may represent a service of the VOS 860 that identifies the operating state of the vehicle 200. The vehicle attribute service 888 may represent a service that identifies various attributes of the vehicle 200 (e.g., current speed, seat belt status of occupants, position, mirror configuration, seat configuration, etc.). The vehicle package manager service 890 may represent a service responsible for managing the UXR for applications on a per-display (whether virtual or physical) basis throughout the duration that the UP 161 / 163 is authorized to access or otherwise interact with the VOS 860, including the DO application 880.

[0113] A UP 161 / 163 may initially be authorized to access the VOS 860 in the manner described above, whereupon or during authorization, the VOS 860 may determine the OZID 165 / 167 and possibly the DT 171 / 173 (when a virtual display exists or is created by a UP 161 / 163) of each UP 161 / 163 that is authorized to access the VOS 860. More specifically, the UXR manager service 884 may map a particular UP 161 / 163 to one or more of the OZID 165 / 167 and potentially the DT 171 / 173, thereby creating a UXR map 883 (which may be updated via the UXR manager 882).

[0114] The UXR manager service 884 may interact with the operating state service 886 to obtain the current operating state of the vehicle 200. The UXR manager service 884 may also interact with the vehicle attribute service 888 to obtain vehicle attributes (e.g., speed change). The UXR manager service 884 may determine the UXR for the DO application 880 based on the OZID 165 / 167 and possibly the DT 171 / 173, the operating state, and the vehicle attributes. The UXR manager service 884 may provide the determined UXR to the vehicle package manager service 890, which performs activity blocking (e.g., restricting content from being consumed via one or more of the multiple displays).

[0115] Via the listening service, the DO application 880 may receive the UXR and adjust the presentation of the content to comply with the UXR provided via the listening service. Non-DO applications may not adjust the presentation of the content to comply with the UXR provided via the listening service, but may continue to present the content without complying with the provided UXR, at which point the vehicle package manager service 890 may perform activity blocking (or in other words, content constraints) to ensure that the non-DO application continues to comply with the determined UXR.

[0116] The UXR manager service 884 may update the UXR map 883 to specify the set of UXRs determined for each OZID 165 / 167 and possibly DT 171 / 173. The UXR map 883 may associate (or in other words, map) an operating state (e.g., a driving state, an idle state, and a parking state) to a set of constraints that restrict the presentation of a dial pad (e.g., for initiating a phone or video call), the presentation of a keyboard (e.g., for searching, web browsing, texting, etc.), the presentation of a video or other content, and / or a complete constraint (in which case no content may be presented, or at least the content specified above as a dial pad, keyboard, and video may not be presented). Any changes to the UXR map 883 may trigger the listening service to issue an interrupt or other flag or mechanism by which the DO application 880 is notified of UXR updates and / or changes.

[0117] Given that the UXR map 883 may be granularly specified on each display (whether virtual or physical) relative to the OZID 165 / 167, the UXR map 883 may allow for different UXRs for each display communicatively coupled to the VOS 860. Thus, the VOS 860 may assign a different UXR to display 250A than to display 250B, even though displays 250A and 250B are both rear passenger displays where distraction is not generally considered a safety issue in terms of distracting an operator seated in the front driver passenger area of ​​the vehicle 200. In instances where content is shared or collaboration exists between different passenger areas as described above, each separate UXR for each passenger area may be enforced, which may result in a different user experience appropriate for the determined driver distraction level of the operator seated in the front operator passenger area of ​​the vehicle.

[0118] Although described above with respect to passenger zone identifiers, the VOS 860 may continue to rely on physical ports for physical displays that do not allow for the creation or support of virtual displays. That is, the VOS 860 may maintain backward compatibility with identifying displays based on the physical port (or virtual port for wireless physical displays) by which the physical display is communicatively coupled to the vehicle head unit 202 and / or the VOS 860. In other words, while the VOS 860 may support extensions in which OZIDs 165 / 167 and possibly DTs 171 / 173 are used to uniquely identify both physical and virtual displays, the VOS 860 may continue to support physical port identifiers to uniquely identify physical displays in order to maintain backward compatibility.

[0119] Fig. 9 is an example Figure 8 A flow chart of an example operation of a VOS in performing various aspects of the techniques described in this disclosure is shown in FIG. Figure 1 The vehicle head unit 102 and / or 202 shown in the example of and / or 2 may execute an instance of a vehicle operating system (such as a vehicle operating system 860) (900) that may facilitate concurrent access by multiple user profiles. The VOS 860 may authorize multiple UPs 161 / 163 to interact with the VOS 160 via multiple displays (e.g., display 212, virtual display 213A / 213B, physical display 250A / 250B) to interact with the VOS 860 via multiple displays 212 / 213 / 250 communicatively coupled to the vehicle head unit 102 / 202 (902).

[0120] The VOS 860 may determine one or more OZIDs 165 / 167 based on which display of the plurality of displays 212 / 213 / 250 each UP in the UP 161 / 163 interacts with to authorize each UP in the UP 161 / 163 (904). The VOS 860 may obtain a user experience constraint (UXR) for each UP in the UP 165 / 167 based on the OZID 165 / 167, the UXR constraining the content presented via each display in the display 212 / 213 / 250 for each UP in the UP 161 / 163 (906). The VOS 860 may then constrain the content consumed by at least one UP in the UP 161 / 163 via a plurality of user interfaces presented across the plurality of displays 212 / 213 / 250 by the VOS 860 according to the UXR (908).

[0121] In this way, the above techniques can achieve the following examples:

[0122] Example 1. A method comprising: executing, by a vehicle head unit, an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; authorizing, by the instance of the vehicle operating system, the multiple user profiles to interact with the instance of the vehicle operating system; presenting, by the instance of the vehicle operating system, a plurality of user interfaces across a plurality of displays communicatively coupled to the vehicle head unit, each of the plurality of user interfaces being associated with one or more of the plurality of user profiles; and interacting, via the plurality of user interfaces, with a plurality of users associated with the one or more of the plurality of user profiles to enable the plurality of users to interact with the instance of the vehicle operating system in order to control functionality associated with the vehicle head unit.

[0123] Example 2. A method as described in Example 1, wherein the instance of the vehicle operating system includes a first instance of the vehicle operating system, wherein the method further includes executing a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0124] Example 3. A method as described in Example 2, wherein the vehicle head unit includes a high processing power processor that executes the first instance of the vehicle operating system, wherein the vehicle head unit includes a low processing power processor that executes the second instance of the vehicle operating system, and wherein the high processing power processor provides greater processing power than the low processing power processor.

[0125] Example 4. The method of any combination of Examples 1 to 3, wherein the plurality of displays are displaced around a cabin of a vehicle including the vehicle head unit.

[0126] Example 5. A method as described in any combination of Examples 1 to 4, wherein the multiple displays include two or more of: a first display integrated into an operator side of a front dashboard of a vehicle cabin that includes the vehicle head unit; a second display integrated into a center console of the front dashboard; a third display integrated into a passenger side of the front dashboard; and a fourth display integrated into a rear passenger compartment of the cabin.

[0127] Example 6. The method of any combination of Examples 1 to 5, wherein the plurality of displays includes one or more computing devices associated with at least one user of the plurality of users who is a passenger of a vehicle including the vehicle head unit.

[0128] Example 7. A method as described in any combination of Examples 1 to 6, wherein the multiple user interactions associated with one or more of the multiple user profiles include: interacting with the multiple users to control audio playback within one or more areas of a cabin of a vehicle including the vehicle head unit.

[0129] Example 8. The method of Example 7, wherein the one or more areas of the vehicle cabin include one or more of: a front operator area, a front passenger area, an operator-side rear passenger area, and a passenger-side rear passenger area.

[0130] Example 9. The method of any combination of Examples 7 and 8, wherein interacting with the plurality of users to control the audio playback comprises interacting with the plurality of users to control audio volume in a single zone of the one or more zones of the vehicle cabin.

[0131] Example 10. A method as described in any combination of Examples 7 to 9, wherein interacting with the multiple users to control the audio playback includes: interacting with the multiple users to control the focus of the audio playback in at least one of the one or more areas of the vehicle compartment.

[0132] Example 11. The method of any combination of Examples 7 to 10, further comprising: capturing, by one or more audio capture devices communicatively coupled to the vehicle head unit, audio data representative of the sound field at each of the one or more zones.

[0133] Example 12. The method as described in Example 11 further includes: determining that a first user among the multiple users in a first area of ​​the one or more areas is speaking in an attempt to audibly interact with the vehicle head unit based on the audio data representing the sound field occurring at each area of ​​the one or more areas.

[0134] Example 13. The method of any combination of Examples 11 and 12, further comprising adjusting audio playback at the one or more zones based on the audio data representing the sound field occurring at each of the one or more zones.

[0135] Example 14. A method as described in Example 13, wherein adjusting the audio playback includes: determining a noise level based on the audio data representing the sound field occurring at each of the one or more areas; and adjusting the audio playback at the one or more areas based on the noise level.

[0136] Example 15. A method as described in any combination of Examples 1 to 14, wherein the multiple user interactions associated with the one or more user profiles of the multiple user profiles include: interacting with a first user of the multiple users via a first user interface of the multiple user interfaces associated with a first user profile of the multiple user profiles to interact with content presented by a second user interface of the multiple user interfaces associated with a second user profile of the multiple user profiles.

[0137] Example 16. The method of Example 15, wherein interacting with the first user comprises interacting with the first user to do one or more of: view content presented by the second user interface or initiate playback at the first user interface.

[0138] Example 17. The method of any combination of Examples 15 and 16, wherein interacting with the first user of the plurality of users comprises interacting with the first user to control audio playback by the second user interface.

[0139] Example 18. The method of Example 17, wherein interacting with the first user to control the audio playback comprises interacting with the first user to change, via the first user interface, an audio volume associated with the audio playback by the second user interface.

[0140] Example 19. The method of any combination of Examples 15 to 18, wherein interacting with the first user comprises interacting with the first user to enable the first user and the second user to jointly interact with the content presented by the second user interface.

[0141] Example 20. The method of Example 19, wherein interacting with the first user to enable the first user and the second user to jointly interact with the content includes: interacting with the first user to enable the first user and the second user to jointly facilitate audio playback by the second user interface.

[0142] Example 21. A method as described in any combination of Examples 19 and 20, wherein interacting with the first user to enable the first user and the second user to jointly interact with the content includes: interacting 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.

[0143] Example 22. The method of Example 21, wherein the multi-user activity comprises a navigation activity in which both the first user and the second user facilitate navigation of a vehicle including the vehicle head unit.

[0144] Example 23. The method of any combination of Examples 21 and 22, wherein the multi-user activity comprises a multi-player video game presented by the second user interface.

[0145] Example 24. A method as described in any combination of Examples 1 to 23, wherein the multiple user interactions associated with the one or more user profiles of the multiple user profiles include: interacting with a first user of the multiple users via a first user interface of the multiple user interfaces associated with a first user profile of the multiple user profiles to share content presented by a second user interface of the multiple user interfaces associated with a second user profile of the multiple user profiles.

[0146] Example 25. The method of Example 24, wherein interacting with the first user comprises receiving a gesture at the first user interface indicating that the content presented by the first user interface is to be shared with the second user interface.

[0147] Example 26. The method of Example 25, wherein the gesture comprises one or more of a swipe gesture, a pinch gesture, and a tap gesture.

[0148] Example 27. The method of any combination of Examples 24 to 26, further comprising: presenting, by the first user interface, an animation indicating initiation of the content being shared.

[0149] Example 28. The method of any combination of Examples 24 to 27, further comprising: playing audio indicating initiation of the content being shared.

[0150] Example 29. The method of Example 28, wherein playing the audio comprises playing spatialized audio to reflect the positioning of the first user interface relative to the positioning of the second user interface.

[0151] Example 30. A computing device comprising: a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; one or more processors, the one or more processors used to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: authorize the multiple user profiles to interact with the instance of the vehicle operating system; and present multiple user interfaces across multiple displays communicatively coupled to a vehicle head unit, each of the multiple user interfaces being associated with one or more user profiles of the multiple user profiles, wherein the multiple user interfaces are configured to interact with multiple users associated with the one or more user profiles of the multiple user profiles to enable the multiple users to interact with the instance of the vehicle operating system to control functionality associated with the vehicle head unit.

[0152] Example 31. A computing device as described in Example 30, wherein the instance of the vehicle operating system includes a first instance of the vehicle operating system, wherein the one or more processors are 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 through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0153] Example 32. A computing device as described in Example 31, wherein the one or more processors include a high processing power processor that executes the first instance of the vehicle operating system, wherein the one or more processors include a low processing power processor that executes the second instance of the vehicle operating system, and wherein the high processing power processor provides greater processing power than the low processing power processor.

[0154] Example 33. The computing device of any combination of Examples 30 to 32, wherein the plurality of displays are displaced around a cabin of a vehicle including the vehicle head unit.

[0155] Example 34. A computing device as described in any combination of Examples 30 to 33, wherein the multiple displays include two or more of: a first display integrated into an operator side of a front dashboard of a vehicle cabin that includes the vehicle head unit; a second display integrated into a center console of the front dashboard; a third display integrated into a passenger side of the front dashboard; and a fourth display integrated into a rear passenger compartment of the cabin.

[0156] Example 35. A computing device as described in any combination of Examples 30 to 34, wherein the plurality of displays includes one or more computing devices associated with at least one user of the plurality of users who is a passenger of a vehicle including the vehicle head unit.

[0157] Example 36. A computing device as described in any combination of Examples 30 to 35, wherein the plurality of user interfaces are configured to interact with the plurality of users to control audio playback within one or more areas of a cabin of a vehicle including the vehicle head unit.

[0158] Example 37. The computing device of Example 36, wherein the one or more areas of the cabin include one or more of: a front operator area, a front passenger area, an operator-side rear passenger area, and a passenger-side rear passenger area.

[0159] Example 38. The computing device of any combination of Examples 36 and 37, wherein the plurality of user interfaces are configured to interact with the plurality of users to control audio volume in a single zone of the one or more zones of the vehicle cabin.

[0160] Example 39. A computing device as described in any combination of Examples 36 to 38, wherein the plurality of user interfaces are configured to interact with the plurality of users to control a focus of audio playback in at least one of the one or more areas of the vehicle cabin.

[0161] Example 40. The computing device of any combination of Examples 36 to 39, further comprising: one or more audio capture devices configured to capture audio data representing a sound field at each of the one or more regions.

[0162] Example 41. A computing device as described in Example 40, wherein the instance of the vehicle operating system is further configured to: determine, based on the audio data representing the sound field present at each of the one or more areas, that a first user among the multiple users in a first area of ​​the one or more areas is speaking in an attempt to audibly interact with the vehicle head unit.

[0163] Example 42. A computing device as described in any combination of Examples 40 and 41, wherein the instance of the vehicle operating system is further configured to adjust audio playback at the one or more regions based on the audio data representing the sound field present at each of the one or more regions.

[0164] Example 43. A computing device as described in Example 42, wherein the instance of the vehicle operating system is further configured to: determine a noise level based on the audio data representing the sound field occurring at each of the one or more areas; and adjust the audio playback at the one or more areas based on the noise level.

[0165] Example 44. A computing device as described in any combination of Examples 30 to 43, wherein a first user interface of the plurality of user interfaces associated with a first user profile of the plurality of user profiles is configured to interact with the first user of the plurality of users to interact with content presented by a second user interface of the plurality of user interfaces associated with a second user profile of the plurality of user profiles.

[0166] Example 45. A computing device as described in Example 44, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to interact with the first user to perform one or more of the following: viewing content presented by the second user interface at the first user interface or initiating playback.

[0167] Example 46. A computing device as described in any combination of Examples 44 and 45, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to interact with the first user to control audio playback performed by the second user interface.

[0168] Example 47. A computing device as described in Example 46, wherein the first user interface of the multiple user interfaces associated with a first user profile of the multiple user profiles is configured to interact with the first user to change, via the first user interface, an audio volume associated with the audio playback performed by the second user interface.

[0169] Example 48. A computing device as described in any combination of Examples 44 and 45, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to interact with the first user to enable the first user and the second user to jointly interact with the content presented by the second user interface.

[0170] Example 49. A computing device as described in Example 48, wherein the first user interface of the multiple user interfaces associated with a first user profile of the multiple user profiles is configured to interact with the first user to enable the first user and the second user to jointly facilitate audio playback performed by the second user interface.

[0171] Example 50. A computing device as described in any combination of Examples 48 and 49, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to interact 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.

[0172] Example 51. The computing device of Example 50, wherein the multi-user activity comprises a navigation activity, wherein the first user and the second user both facilitate navigation of a vehicle including the vehicle head unit.

[0173] Example 52. A computing device as described in any combination of Examples 50 and 51, wherein the multi-user activity includes a multi-player video game presented by the second user interface.

[0174] Example 53. A computing device as described in any combination of Examples 30 to 52, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to interact with a first user 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 a second user profile of the multiple user profiles.

[0175] Example 54. A computing device as described in Example 53, wherein the first user interface of the multiple user interfaces associated with the first user profile of the multiple user profiles is configured to receive a gesture indicating that content presented by the first user interface is to be shared with the second user interface.

[0176] Example 55. The computing device of Example 54, wherein the gesture comprises one or more of a swipe gesture, a pinch gesture, and a tap gesture.

[0177] Example 56. The computing device of any combination of Examples 53 to 55, wherein the first user interface is further configured to present an animation indicating initiation of the content being shared.

[0178] Example 57. The computing device of any combination of Examples 53 to 56, wherein the first user interface is further configured to play audio indicating initiation of the content being shared.

[0179] Example 58. The computing device of Example 57, wherein the first user interface is configured to play spatialized audio to reflect the positioning of the first user interface relative to the positioning of the second user interface.

[0180] Example 59. A 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; authorize the multiple user profiles to interact with the instance of the vehicle operating system via execution of a first instance of the vehicle operating system; present a plurality of user interfaces across a plurality of displays communicatively coupled to a vehicle head unit via execution of the first instance of the vehicle operating system, each of the plurality of user interfaces being associated with one or more of the plurality of user profiles; and interact with a plurality of users associated with the one or more of the plurality of user profiles via the plurality of user interfaces so as to enable the plurality of users to interact with the instance of the vehicle operating system in order to control functionality associated with the vehicle head unit.

[0181] Example 1A. 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; authorizing, by the instance of the vehicle operating system, the multiple user profiles to interact with the instance of the vehicle operating system via multiple displays communicatively coupled to the vehicle head unit; determining one or more occupant area identifiers based on which of the multiple displays each user profile of the multiple user profiles interacts with to authorize each of the multiple user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the multiple user profiles of the multiple user profiles is associated; obtaining a user experience constraint for each of the multiple user profiles based on the one or more occupant area identifiers, the user experience constraint constraining content presented via each of the multiple displays for each of the multiple user profiles of the multiple user profiles; and constraining the content consumed by at least one of the multiple user profiles via multiple user interfaces presented across the multiple displays by the single instance of the vehicle operating system in accordance with the user experience constraint.

[0182] Example 2A. The method of Example 1A, further comprising: determining a display type for each of the plurality of displays, wherein the display type indicates that at least one of the plurality of displays is a virtual display presented by at least one physical display of the plurality of displays.

[0183] Example 3A. The method of Example 2A, wherein the at least one virtual display is presented via the at least one physical display concurrently with another virtual display in the plurality of displays.

[0184] Example 4A. The method of Example 2A or 3A further comprises obtaining an operating state of the vehicle, wherein obtaining the user experience constraint comprises obtaining the user experience constraint based on the occupant zone identifier, the display type, and the operating state.

[0185] Example 5A. A method as described in Example 4A, wherein obtaining the operating state includes obtaining one of a driving state, an idle state, and a parking state, wherein obtaining the user experience constraint includes one of the following: obtaining a first user experience constraint based on the driving state, obtaining a second user experience constraint based on the idle state, and obtaining a third user experience constraint based on the parking state, wherein the first user experience constraint is more restrictive than the second user experience constraint, and wherein the second user experience constraint is more restrictive than the third user experience constraint.

[0186] Example 6A. The method of Examples 1A to 5A, further comprising: receiving a registration of the user experience constraint for the occupant region identifier via an application programming interface; and updating the user experience constraint for at least one client application based on the registration of the user experience constraint.

[0187] Example 7A. The method of Example 6A, wherein the at least one client application comprises a non-distraction optimized application, and wherein the user experience constraints for the non-distraction optimized application are more restrictive than the user experience constraints for the distraction optimized application.

[0188] Example 8A. A method as described in Examples 1A to 7A, wherein the instance of the vehicle operating system includes a first instance of the vehicle operating system, wherein the method further includes executing a second instance of the vehicle operating system, and wherein the first instance of the vehicle operating system includes an interface through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0189] Example 9A. The method of Examples 1A to 8A, wherein the plurality of displays are displaced around a cabin of the vehicle including the vehicle head unit.

[0190] Example 10A. A method as described in Examples 1A to 9A, wherein the multiple displays include two or more of: a first display integrated into an operator side of a front dashboard of a cabin of the vehicle including the vehicle head unit; a second display integrated into a center console of the front dashboard; a third display integrated into a passenger side of the front dashboard; and a fourth display integrated into a rear passenger compartment of the cabin.

[0191] Example 11A. The method of Examples 1A to 10A, wherein the occupant area includes one of: a front operator area, a front passenger area, an operator-side rear passenger area, and a passenger-side rear passenger area.

[0192] Example 12A. A computing device comprising: a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle operating system facilitates concurrent access by multiple user profiles; a processing circuit system configured to execute the instance of the vehicle operating system, wherein the instance of the vehicle operating system is configured to: authorize the multiple user profiles to interact with the instance of the vehicle operating system via multiple displays communicatively coupled to a vehicle head unit; determine one or more occupants based on which display of the multiple displays each user profile in the multiple user profiles interacts with to authorize each user profile in the multiple user profiles a region identifier, each of the one or more occupant region identifiers identifying an occupant region of the vehicle in which each of the plurality of user profiles is associated; obtaining a user experience constraint for each of the plurality of user profiles based on the one or more occupant region identifiers, the user experience constraint constraining content presented via each of the plurality of displays for each of the plurality of user profiles; and constraining the content consumed by at least one of the plurality of user profiles via a plurality of user interfaces presented across the plurality of displays by the single instance of the vehicle operating system in accordance with the user experience constraint.

[0193] Example 13A. A computing device as described in Example 12A, wherein the vehicle operating system is further configured to determine a display type for each of the plurality of displays, wherein the display type indicates that at least one of the plurality of displays is a virtual display presented by at least one physical display of the plurality of displays.

[0194] Example 14A. The computing device of Example 13A, wherein the at least one virtual display is presented via the at least one physical display concurrently with another virtual display in the plurality of displays.

[0195] Example 15A. A computing device as described in Example 13A or 15A, wherein the vehicle operating system is further configured to obtain an operating state of the vehicle, wherein the vehicle operating system is configured to obtain the user experience constraint based on the occupant area identifier, the display type, and the operating state.

[0196] Example 16A. A computing device as described in Example 15A, wherein the vehicle operating system is configured to obtain one of a driving state, an idle state, and a parking state, wherein the vehicle operating system is configured to obtain a first user experience constraint based on the driving state, a second user experience constraint based on the idle state, and a third user experience constraint based on the parking state, wherein the first user experience constraint is more restrictive than the second user experience constraint, and wherein the second user experience constraint is more restrictive than the third user experience constraint.

[0197] Example 17A. A computing device as described in Examples 12A to 16A, wherein the vehicle operating system is further configured to: receive a registration of the user experience constraint for an occupant zone identifier via an application programming interface; and update the user experience constraint for at least one client application based on the registration of the user experience constraint.

[0198] Example 18A. The computing device of Example 17A, wherein the at least one client application comprises a non-distraction optimized application, and wherein the user experience constraints for the non-distraction optimized application are more restrictive than the user experience constraints for the distraction optimized application.

[0199] Example 19a. A computing device as described in Examples 12A to 18A, wherein the instance of the vehicle operating system includes a first instance of the vehicle operating system, wherein the processing circuit 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 through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the multiple user profiles.

[0200] Example 20A. A 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; authorize the multiple user profiles to interact with the instance of the vehicle operating system via execution of a first instance of the vehicle operating system; determine one or more occupant area identifiers based on which of the multiple displays each user profile in the multiple user profiles interacts with to authorize each of the multiple user profiles in the multiple user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the multiple user profiles in the multiple user profiles is associated; obtain a user experience constraint for each of the multiple user profiles based on the one or more occupant area identifiers, the user experience constraint constraining content presented via each of the multiple displays for each of the multiple user profiles in the multiple user profiles; and constrain the content consumed by at least one of the multiple user profiles via multiple user interfaces presented across the multiple displays via the single instance of the vehicle operating system in accordance with the user experience constraint.

[0201] 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 through a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium corresponding to: a tangible medium, such as a data storage medium; or a communication medium, including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0202] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer. Moreover, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwaves are used to send instructions from a website, server or other remote source, then coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwaves are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other transient media, but rather relate to non-transient tangible storage media. Disks and optical disks such as used include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks and blue optical disks, ultra blue light, etc., where disks usually reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

[0203] 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 circuit systems. Thus, the term "processor" as used may refer to any of the aforementioned structures or any other structure suitable for implementing the described techniques. Furthermore, in some aspects, the described functionality may be provided within dedicated hardware and / or software modules. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

[0204] The technology of the present disclosure can be implemented in a wide variety of devices or equipment, including wireless handsets, integrated circuits (ICs), or a group of ICs (e.g., chipsets). Various components, modules, or units are described in the present disclosure to emphasize the functional aspects of the device configured to perform the disclosed technology, but the components, modules, or units do not necessarily need to be implemented by different hardware units. Instead, as described above, the various units can be combined in a hardware unit, or provided by a collection of interoperable hardware units including one or more processors as described above in combination with appropriate software and / or firmware.

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

Claims

1. A method comprising: executing, by a vehicle head unit included in a vehicle, an instance of a vehicle operating system, wherein said instance of said vehicle operating system facilitates concurrent access by a plurality of user profiles; authorizing, by the instance of the vehicle operating system, the plurality of user profiles to interact with the instance of the vehicle operating system via a plurality of displays communicatively coupled to the vehicle head unit; determining one or more occupant area identifiers based on which of the plurality of displays each of the plurality of user profiles interacts with to authorize each of the plurality of user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the plurality of user profiles is associated; obtaining, for each of the plurality of user profiles based on the one or more occupant zone identifiers, a user experience constraint that constrains content presented via each of the plurality of displays for each of the plurality of user profiles; as well as Content consumed by at least one user profile of the plurality of user profiles is constrained according to the user experience constraints via a plurality of user interfaces presented across the plurality of displays by a single instance of the vehicle operating system.

2. The method of claim 1, further comprising: A display type is determined for each of the plurality of displays, wherein the display type indicates that at least one of the plurality of displays is a virtual display presented by at least one physical display of the plurality of displays. 3 . The method of claim 2 , wherein the at least one virtual display is presented via the at least one physical display concurrently with another virtual display of the plurality of displays.

4. The method of claim 2, further comprising: obtaining the operating status of the vehicle, Wherein obtaining the user experience constraint comprises obtaining the user experience constraint based on the occupant zone identifier, the display type, and the operating state.

5. The method according to claim 4, wherein obtaining the operating state comprises obtaining one of a driving state, an idle state, and a parking state, Wherein obtaining the user experience constraint comprises one of the following: obtaining a first user experience constraint based on the driving state, obtaining a second user experience constraint based on the idle state, and obtaining a third user experience constraint based on the parking state, wherein the first user experience constraint is more restrictive than the second user experience constraint, and The second user experience constraint is more restrictive than the third user experience constraint.

6. The method of claim 1, further comprising: receiving, via an application programming interface, a registration of the user experience constraint for the occupant zone identifier; as well as The user experience constraints for at least one client application are updated based on the registration of the user experience constraints.

7. The method according to claim 6, wherein the at least one client application comprises a non-distraction optimized application, and The user experience constraints for the non-distraction optimized application are more restrictive than the user experience constraints for the distraction optimized application.

8. The method according to claim 1, wherein said instance of a vehicle operating system comprises a first instance of said 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 through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the plurality of user profiles.

9. The method of claim 1, wherein the plurality of displays are displaced about a cabin of the vehicle including the vehicle head unit.

10. The method of claim 1, wherein the plurality of displays comprises two or more of: a first display integrated into an operator side of a front instrument panel of a cabin of the vehicle including the vehicle head unit; a second display, the second display being integrated into a center console of the front instrument panel; a third display integrated into the passenger side of the front instrument panel; as well as A fourth display is integrated into a rear passenger compartment of the vehicle cabin.

11. The method of claim 1, wherein the occupant area includes one of: a front operator area, a front passenger area, an operator-side rear passenger area, and a passenger-side rear passenger area.

12. A computing device comprising: a memory configured to store an instance of a vehicle operating system, wherein the instance of the vehicle 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: authorizing the plurality of user profiles to interact with the instance of the vehicle operating system via a plurality of displays communicatively coupled to the vehicle head unit; determining one or more occupant area identifiers based on which of the plurality of displays each of the plurality of user profiles interacts with to authorize each of the plurality of user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the plurality of user profiles is associated; obtaining, for each of the plurality of user profiles based on the one or more occupant zone identifiers, a user experience constraint that constrains content presented via each of the plurality of displays for each of the plurality of user profiles; as well as Content consumed by at least one user profile of the plurality of user profiles is constrained according to the user experience constraints via a plurality of user interfaces presented across the plurality of displays by a single instance of the vehicle operating system.

13. A computing device as described in claim 12, wherein the vehicle operating system is further configured to determine a display type for each of the plurality of displays, wherein the display type indicates that at least one of the plurality of displays is a virtual display presented by at least one physical display of the plurality of displays.

14. The computing device of claim 13, wherein the at least one virtual display is presented via the at least one physical display concurrently with another virtual display of the plurality of displays.

15. The computing device of claim 13, wherein the vehicle operating system is further configured to obtain an operating state of the vehicle, Wherein the vehicle operating system is configured to obtain the user experience constraint based on the occupant zone identifier, the display type, and the operating state.

16. The computing device of claim 15, wherein the vehicle operating system is configured to obtain one of a driving state, an idle state, and a parking state, wherein the vehicle operating system is configured to obtain a first user experience constraint based on the driving state, obtain a second user experience constraint based on the idle state, and obtain a third user experience constraint based on the parking state, wherein the first user experience constraint is more restrictive than the second user experience constraint, and The second user experience constraint is more restrictive than the third user experience constraint.

17. The computing device of claim 12, wherein the vehicle operating system is further configured to: receiving, via an application programming interface, a registration of the user experience constraint for the occupant zone identifier; and The user experience constraints for at least one client application are updated based on the registration of the user experience constraints.

18. The computing device of claim 17, wherein the at least one client application comprises a non-distraction optimized application, and The user experience constraints for the non-distraction optimized application are more restrictive than the user experience constraints for the distraction optimized application.

19. The computing device of claim 12, wherein said instance of a vehicle operating system comprises a first instance of said vehicle operating system, wherein the processing circuitry 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 through which to communicate with the second instance of the vehicle operating system to facilitate concurrent access by the plurality of user profiles.

20. A non-transitory computer-readable storage medium having stored thereon instructions that, when executed, cause one or more processors to: executing an instance of a vehicle operating system, wherein said instance of said vehicle operating system facilitates concurrent access by a plurality of user profiles; authorizing the plurality of user profiles to interact with the instance of the vehicle operating system via execution of the first instance of the vehicle operating system; determining one or more occupant area identifiers based on which of the plurality of displays each of the plurality of user profiles interacts with to authorize each of the plurality of user profiles, each of the one or more occupant area identifiers identifying an occupant area of ​​the vehicle with which each of the plurality of user profiles is associated; obtaining, for each of the plurality of user profiles based on the one or more occupant zone identifiers, a user experience constraint that constrains content presented via each of the plurality of displays for each of the plurality of user profiles; as well as Content consumed by at least one user profile of the plurality of user profiles is constrained according to the user experience constraints via a plurality of user interfaces presented across the plurality of displays by a single instance of the vehicle operating system.

Images