SYSTEM COMPREHENSIVE OF A VEHICLE

Abstract

System, comprehensive: a vehicle (102) designed, in response to receiving a request from a mobile device (152) associated with a specific seating position to access a safe vehicle function, to request authorization from the driver for the mobile device (152) to access the function based on the seating position associated with the mobile device (152) and to query a local policy table (206) that defines, based on the associated seating position, which vehicle functions accessible to the mobile device (152) require authorization from the driver.

Description

TECHNICAL AREA

[0001] The invention generally relates to a system comprising a vehicle for managing the control of a mobile device of vehicle functions using guidelines. GENERAL STATE OF THE ART

[0002] A vehicle may allow the integration of multiple mobile devices to control vehicle functions and subsystems. However, a contextual problem can arise in managing the actual transfer of control between multiple devices while maintaining the overall safety of all vehicle occupants under a variety of dynamic automotive conditions. Such problems include determining who exercises control and how this changes, as well as whether an occupant is allowed to gain control and how this is enabled and achieved safely. Accordingly, there is a need to provide efficient systems and procedures for managing the control of mobile devices within vehicle systems, mitigating these risks in a centralized and effective manner.

[0003] German patent DE 10 2014 204 747 A1 discloses a system for determining the occupant's location in a vehicle using connected devices, wherein the location of a smartphone in the vehicle is determined and, based on this location, restrictions of the infotainment control are either lifted or set. Furthermore, US patent US 2014 / 0 310 739 A1 discloses a system for controlling a media system in a vehicle, in which an ID code of a portable smartphone and its position within the vehicle are determined in order to unlock more or fewer contents of the media system, if necessary. SUMMARY

[0004] According to the invention, a system according to claim 1 is proposed to mitigate the described problem. Preferred embodiments of the invention are the subject of the dependent claims.

[0005] In a first illustrative embodiment, a system includes a vehicle computing platform programmed to receive a request from a mobile device running a mobile application to access a safe vehicle function and to retrieve a vehicle seat position associated with a user of the mobile device. The computing platform is also programmed to query a local policy table for application permissions associated with the safe vehicle function and the vehicle seat position. The application permissions define which vehicle functions the mobile application can access based on the vehicle seat position. The computing platform can further be programmed to grant the mobile application access to the safe vehicle function according to the application permissions.The safe vehicle function can include vehicle climate control, vehicle navigation control, vehicle radio control, and / or vehicle seat control. The computing platform is further programmed to request driver authorization in response to a determination, based on the local policy table, that access to the safe vehicle function requires authorization by a driver of the vehicle.

[0006] In a second illustrative embodiment, a system includes a mobile device connected to a vehicle's computing platform, which is programmed to run a mobile application for accessing a vehicle subsystem and prompting a user to enter a vehicle seat position. The mobile device is also programmed to send an update to a policy table received from a remote server to the computing platform. This update includes a local policy table containing application permissions that define which vehicle functions the mobile application can access based on the vehicle seat position.The mobile device can further be programmed to display a "granted" indicator in response to the mobile application's computing platform granting access to the vehicle subsystem, and to display an "access denied" indicator in response to the mobile application's computing platform denying access to the vehicle subsystem. The mobile device can also be programmed to display a selection of vehicle subsystems available for occupant control and to prompt a user to select the vehicle subsystem to control.

[0007] A computer-implemented implementation can involve receiving a request from a mobile device running a mobile application to access a vehicle subsystem and retrieving a vehicle seat position associated with the mobile device from the mobile application. The process also includes querying a local policy table to determine application permissions associated with the vehicle subsystem and the vehicle seat position. The process then grants the mobile application access to the vehicle subsystem according to these application permissions. The process can further include updating the local policy table based on policy table updates issued by a remote server. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 illustrates an exemplary representation of a system configured to provide telematics services to a vehicle according to the embodiments of this disclosure; Fig. Figure 2 illustrates an exemplary representation of an architecture for authorization policies according to the embodiments of this disclosure; and Fig. Figure 3 illustrates an exemplary method for using guidelines to manage the control of a mobile device of vehicle functions and subsystems according to the embodiments of this disclosure. DETAILED DESCRIPTION

[0008] Here, embodiments of the present disclosure are described. It is understood, however, that the disclosed embodiments are merely examples and that other embodiments may take different and alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of certain components. Accordingly, the specific structural and functional details disclosed here are not to be interpreted as limiting, but merely as a representative basis to teach a person skilled in the art the different uses of the embodiments.It is understood by the average person skilled in the art that various features illustrated and described with respect to any of the figures can be combined with features illustrated in one or more other figures to create embodiments not explicitly illustrated or described. The combinations of illustrated features provide representative embodiments for typical applications. However, various combinations and modifications of the features, consistent with the teachings of this disclosure, may be desirable for certain applications or implementations.

[0009] A mobile application running on a mobile device connected to a vehicle can request access to one or more safe vehicle functions and subsystems. Examples of safe vehicle functions include, but are not limited to, access to a vehicle radio system, climate control system, navigation system, seating system, audio system, and sunroof system. In one example, the user can run the application on a mobile phone, with the application requesting permission to control the radio. If permission is granted, the available radio stations and settings are displayed to the user on the mobile device. Similarly, if the system determines that driver authorization is required to transfer control to the user (a vehicle occupant), the system will request this authorization through the vehicle's human-machine interface (HMI).If the driver grants permission, the occupant can then proceed to change the radio settings from the mobile device as they wish.

[0010] If the mobile application has access to the vehicle's functions and subsystems, the vehicle can authenticate the application using one or more security mechanisms. For example, each application can be associated with an application identifier, and the vehicle can validate that the identifier is included in a list of applications authorized to communicate with the vehicle. Alternatively, each application can be associated with specific application programming interface (API) calls to which the application is authorized, and the vehicle can validate the commands the application sends to the vehicle to ensure that the application is making API calls that are specified as permissible.

[0011] When the application logs into the vehicle's computer system, it provides the vehicle with the application identifier. The vehicle computer system can then check a policy table downloaded from a remote server to identify an application policy associated with the provided application identifier. The application policy can specify whether the application is granted access to and control of the associated vehicle subsystem, and what restrictions and permissions apply. If the policy table file does not contain policy permissions for the application identifier, the vehicle computer system can request an update of the policy table file from the remote server.The updated policy table file provided by the server may contain updated policy permissions and other application information.

[0012] Fig. Figure 1 illustrates an example of a System 100 configured to provide telematics services to a Vehicle 102. The Vehicle 102 can include various types of passenger vehicles, such as compact SUVs, all-terrain vehicles (SUVs), trucks, motorhomes (RVs), boats, aircraft, or other mobile machinery used for transporting people or goods. Telematics services can include, but are not limited to, navigation, route guidance, vehicle diagnostics, local business search, accident reporting, and hands-free calling. In one example, the System 100 might include the SYNC system, manufactured by the Ford Motor Company in Dearborn, MI. It should be noted that the illustrated System 100 is merely an example, and more, fewer, and / or differently arranged elements could be used.

[0013] The computer platform 104 may include one or more processors 106 configured to execute instructions, commands, and other routines to support the procedures described herein. For example, the computer platform 104 may be configured to execute instructions from vehicle applications 110 to provide functions such as navigation, accident reporting, satellite radio decryption, and hands-free calling. Such instructions and other data may be managed non-volatilely using a variety of electronically readable storage media 112. The computer-readable storage medium 112 (also referred to as processor-readable medium or memory) includes any non-volatile medium (e.g., a physical medium) involved in providing instructions or other data that can be read by the processor 106 of the computer platform 104.Computer-executable instructions can be assembled or interpreted by computer programs created using a variety of programming languages ​​and / or technologies, including, but not limited to, Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl, and PL / SQL, either alone or in combination.

[0014] The computing platform 104 can be equipped with various features that allow vehicle occupants to interface with it. For example, the computing platform 104 can include an audio input 114, configured to receive voice commands from vehicle occupants via a connected microphone 116, and an additional audio input 118, configured to receive audio signals from connected devices. The additional audio input 118 can be a physical connection, such as a power cable or a fiber optic cable, or a wireless input, such as a Bluetooth audio connection. In some examples, the audio input 114 can be configured to provide audio processing capabilities, such as pre-amplifying low-level signals and converting analog inputs into digital data for processing by the processor 106.

[0015] The computing platform 104 can also provide one or more audio outputs 120 to an input of an audio module 122 with audio playback functionality. In other examples, the computing platform 104 can provide the audio output for the occupant by using one or more permanently assigned loudspeakers (not shown). The audio module 122 can include an input selector 124, which is configured to provide an audio amplifier 128 with audio content from a selected audio source 126 for playback via the vehicle loudspeakers 130 or headphones (not shown). Audio sources 126 can include, for example, decoded amplitude-modulated (AM) or frequency-modulated (FM) radio signals and audio signals from audio playbacks of compact discs (CDs) or digital versatile discs (DVDs).Audio sources 126 may also include audio data received by the computing platform 104, such as audio content generated by the computing platform 104, audio content decoded from flash memory sticks connected to a USB (universal serial bus) subsystem 132 of the computing platform 104, and audio content routed through the computing platform 104 from the additional audio input 118.

[0016] The computing platform 104 can use a speech interface 134 to provide a hands-free interface. The speech interface 134 can support speech recognition of audio data received via the microphone 116 according to a grammar associated with available commands, and the generation of speech prompts for output via the audio module 122. The speech interface 134 can utilize probabilistic speech recognition techniques by comparing the grammar to the input speech. In many cases, the speech interface 134 can include a default user profile setting for use by the speech recognition functions, allowing the speech recognition to be configured to provide good results on average, leading to a positive experience for the maximum number of initial users.In some cases, the system may be configured to temporarily mute or otherwise overwrite the audio source specified by the input selector 124 when an audio request can be issued by the computing platform 104 and another audio source 126 is selected for playback.

[0017] The computing platform 104 can also receive input from controls of a human-machine interface (HMI) 136, which is configured to enable interaction between occupants and the vehicle 102. For example, the computing platform 104 can interface with one or more buttons or other HMI controls configured to call functions on the computing platform 104 (e.g., audio buttons on the steering wheel, a talk button, controls on the instrument panel, etc.). The computing platform 104 can also control or otherwise communicate with one or more displays 138 configured to provide visual output to the vehicle occupants via a video control 140.In some cases, the display 138 may be a touchscreen which is further configured to receive touch-based input from the user via a video control 140, whereas in other cases the display 138 may simply be a display without the possibility of input by touch.

[0018] The computing platform 104 can also be configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. These in-vehicle networks 142 can include, for example, one or more of the following: a vehicle control local area network (CAN), an Ethernet network, or a media-based system transmission (MOST). Through these in-vehicle networks 142, the computing platform 104 can communicate with other systems in the vehicle 102, such as a vehicle modem 144 (which may not be present in some configurations), a global positioning system (GPS) module 146 configured to provide the current location and direction of travel of the vehicle 102, and various vehicle ECUs 148 configured to cooperate with the computing platform 104.Among other things, the vehicle ECUs (148) can include, for example, a powertrain control module configured to control the engine's operating components (e.g., idle speed control, fuel supply components, emissions monitoring components, etc.) and to monitor the engine's operating components (e.g., the status of engine diagnostic codes); a body control module configured to manage various performance control functions, such as exterior lighting, interior lighting, keyless entry, remote start, and to check the status of access points (e.g.,The vehicle 102 includes the closing status of the hood, doors and / or trunk; a radio communication device configured to communicate with key fobs or other local devices of the vehicle 102; and a climate control management module configured to control and monitor the heating and cooling system components (e.g., control of compressor clutch and blower fan, temperature sensor information, etc.).

[0019] As illustrated, the audio module 122 and the HMI controllers 136 can communicate with the computing platform 104 via a first in-vehicle network 142-A, and the vehicle modem 144, the GPS module 146, and the vehicle ECUs 148 can communicate with the computing platform 104 via a second in-vehicle network 142-B. In other examples, the computing platform 104 can be connected to more or fewer in-vehicle networks 142. Additionally or alternatively, one or more HMI controllers 136 or other components can be connected to the computing platform 104 via other in-vehicle networks 142, which differ from the networks shown, or directly without a connection to an in-vehicle network 142.

[0020] The computing platform 104 can also be configured to communicate with mobile devices 152 belonging to the vehicle occupants. These mobile devices 152 can be any portable computing devices, such as mobile phones, tablet computers, smartwatches, laptops, portable music players, or other devices capable of connecting to the computing platform 104. In many examples, the computing platform 104 can include a wireless transmitter-receiver 150 (e.g., a Bluetooth module, a Zigbee transmitter-receiver, a Wi-Fi transmitter-receiver, an IrDA transmitter-receiver, an RFID transmitter-receiver, etc.) configured to communicate with a compatible wireless transmitter-receiver 154 of the mobile device 152.Additionally or alternatively, the computing platform 104 can communicate with the mobile device 152 via a wired connection, such as a USB connection between the mobile device 152 and the USB subsystem 132. In some examples, the mobile device 152 may be battery-powered, while in other cases, the mobile device 152 obtains at least part of its power from the vehicle 102 via a wired connection.

[0021] The communication network 156 can provide connectivity services to devices connected to the communication network 156, such as packet-switched network services (e.g., internet access, VoIP communication services). An example of a communication network 156 could be a cellular network. Mobile devices 152 can provide network connectivity to the communication network 156 via a device modem 158 of the mobile device 152. To simplify communication over the communication network 156, mobile devices 152 can be associated with unique device identifiers (e.g., Mobile Device Numbers (MDNs), Internet Protocol (IP) addresses, etc.) to identify the communication of the mobile devices 152 over the communication network 156.In some cases, occupants of the vehicle 102 or devices authorized to connect to the computing platform 104 can be identified by the computing platform 104 according to the data on paired devices 160 stored in the storage medium 112.The paired device data 160 may, for example, indicate the unique device identifiers of the mobile devices 152, which were previously paired with the vehicle 102's computing platform 104, secret information shared between the paired device and the computing platform 104, such as connection keys and / or personal identification numbers (PINs), and the last used or device priority information, so that the computing platform 104 can automatically reconnect to the mobile devices 152 without user intervention, which correspond to the data in the paired device data 160.

[0022] When a mobile device 152, which supports network connectivity, is paired with the computing platform 104, the mobile device 152 can allow the computing platform 104 to use the network connectivity of the device modem 158 to communicate with the remote telematics server 162 or the remote computing device via the communication network 156. For example, the computing platform 104 can use a data-over-speech plan or a data plan of the mobile device 152 to communicate information between the computing platform 104 and the communication network 156. Additionally or alternatively, the computing platform 104 can use the vehicle modem 144 to communicate information between the computing platform 104 and the communication network 156 without using communication facilities of the mobile device 152.

[0023] Similar to the computing platform 104, the mobile device 152 can include one or more processors 164 configured to execute instructions from mobile applications that are loaded from a storage medium 168 of the mobile device 152 into a memory 166 of the mobile device 152. In some examples, the mobile applications can be configured to communicate with the computing platform 104 via the wireless transmitter-receiver 154 and with the remote telematics server 162 or other network services via the device modem 158. The computing platform 104 can also include a device linking interface 172 to facilitate the integration of functions of the mobile applications into the grammar of commands available via the voice interface 134.The device linking interface 172 can also provide mobile applications with access to vehicle functions and information available to the computing platform 104 via the vehicle's in-vehicle networks 142. An example of a device linking interface 172 is the SYNC-APPLINK component of the SYNC system, provided by the Ford Motor Company in Dearborn, MI.

[0024] Fig. Figure 2 illustrates an exemplary representation of an architecture 200 for authorization policies. As illustrated, the architecture 200 includes a vehicle 102 with a policy management device 210, which is connected to a backend server 218 via the communication network 156. The policy management device 210 can be configured to maintain a local policy table 206 and recorded application usage 208. The mobile device 152 can run a mobile application 202, which is associated with an application tag 204 and includes an application proxy 212 that facilitates communication with the backend server 218 using the communication network 156. The backend server 218 can be configured to provide access to a key management system 220 and a remote application management system 222, which maintain a master policy table 224.As explained in detail below, the remote management system 222 can be configured to provide updates 214 to the policy table to the vehicle 102 via the application proxy 212 of the mobile device 152.

[0025] The mobile application 202 can be an application installed on the mobile device 152 for use with the computing platform 104 of the vehicle 102. According to embodiments of the present disclosure, the mobile application 202 can request access to one or more secure vehicle functions and subsystems. In one example, the mobile application 202 can request access to the vehicle's climate control system to allow an occupant to adjust the heating and / or cooling within the vehicle 102. In this case, driver authorization to transfer control may or may not be necessary. If occupant zone control is configured in the occupant's seat position (the seat position being associated with the mobile device), the system automatically grants the mobile application's access request, and the occupant can proceed to make the desired control settings from the mobile device.However, if occupant zone control is not available in the occupant seat position, the system will prompt the driver via the HMI to authorize the transfer of control to the occupant. Among other things, the mobile application 202 can also provide access to the vehicle's navigation, radio, and audio systems.

[0026] The local policy table 206 can be configured to store key information that describes in detail the application permissions in the vehicle 102. Application permissions can include information about which vehicle subsystems the vehicle occupants can access, when driver authorization is required to transfer control to a non-primary mobile device, and when access to the vehicle subsystem must be terminated and control returned to a driver. Thus, the local policy table 206 can define the type of interaction permitted between the computing platform 104 and a given mobile application 202.

[0027] The authorization information may, for example, include a list of vehicle systems deemed permissible for use by the mobile application 202. The local policy table 206 may also include authorization information based on the vehicle seat position associated with the mobile device. For example, if the mobile device is a non-primary device, the application authorizations may include information about which vehicle functions and subsystems can be accessed without first requesting authorization from a driver. This may depend on whether local / occupant zone controls are configured in the vehicle seat position associated with the mobile device.For example, the application permission to allow an occupant to adjust the vehicle's climate control may depend on whether local climate controls are configured in the occupant's seat position. Similarly, application permissions may be coded to grant rear-seat occupants access to rear infotainment systems without requiring driver authorization. The local policy table 206 may also contain information about how and when the vehicle requests updates to the local policy table 206, as well as information about how to contact a source of updated local policy tables 206 (e.g., a URL or other address of the backend server 218).

[0028] The recorded application usage 208 can include the logged use of the API and the use of the systems of the vehicles 102 or other vehicle functions whose authorization for the mobile application 202 is controlled. Thus, the recorded application usage 208 can include collected usage data regarding how users use the mobile application 202 in the vehicle 102.

[0029] The policy management facility 210 can be configured to manage permissions of the mobile application 202 for the vehicle 102's computing platform 104. For example, the policy management facility 210 can maintain the local policy table 206. When a mobile application 202 is initiated or powered on, the policy management facility 210 can identify the permissions associated with the mobile application 202 based on the local policy table 206. Furthermore, when the mobile application 202 interacts with the computing platform 104, the policy management facility 210 can record the mobile application 202's use of vehicle APIs and systems in the application usage record 208.

[0030] The policy management facility 210 of the computing platform 104 can also be configured to manage communication with the backend server 218. Regarding requests or responses between the policy management facility 210 and the backend server 218, the policy management facility 210 can be configured to initiate communication with the backend server 218. For example, the policy management facility 210 can send a message to the backend server 218 to inform it that the vehicle 102 is active and waiting for information. In some cases, the backend server 218 can send an unsolicited message to a specific vehicle 102 and push it to the cloud. However, the message cannot be delivered to the vehicle 102 until the computing platform 104 connects and requests it from the backend server 218.

[0031] The policy management facility 210 can be configured to request the backend server 218 to provide the vehicle 102 with updates to the local policy table 206. These policy table updates 214 can include, for example, a new local policy table 206 to replace the currently stored local policy table 206 with the policy management facility 210, or updates to an existing local policy table 206 to extend the current entries in the local policy table 206. The policy table update 214 can be based on the most up-to-date information maintained by the remote application management system 222 in a master policy table 224 containing the most recent permissions of the mobile application 202.For example, the policy management facility 210 can request an update to the local policy table 206 if a mobile application 202 requests access to a vehicle subsystem and the local policy table 206 lacks the application authorization information for that subsystem or vehicle function.

[0032] The policy management unit 210 can also be configured to provide the backend server 218 with the recorded application usage 208 for remote review and processing. For this purpose, the policy management unit 210 can provide an application usage update message 216 containing the recorded application usage 208 information stored by the vehicle 102. This allows the system to verify that the mobile application 202 is appropriately using the vehicle 102's APIs and systems.

[0033] The wireless transmitter-receiver 115 of the vehicle 102 can be connected to a paired mobile device 152 (e.g., via a Bluetooth connection, a USB connection, etc.) such that the communication features of the mobile device 152 can be used to allow the computing platform 104 to communicate with the backend server 218 via the communication network 156. The communication network 156 can accordingly be used by the mobile device 152 via a mobile data plan of the mobile device 152 (e.g., to provide the computing platform 104 with TCP / IP-based communication functionalities). Additionally or alternatively, the computing platform 104 can use the vehicle modem 144 to communicate data between the processor 106 and the communication network 156.Messages sent to vehicle 102 via communication network 156 can be queued in the cloud until a connection to vehicle 102 can be established or until the message expires. In one example, the functionality for creating the queue and expiring the message can be implemented via backend server 218. The functionality for creating a message queue on communication network 156 can also serve as a first line of defense against server denial-of-service attacks.

[0034] Fig. Figure 3 illustrates an exemplary procedure for using policies to manage a mobile device's control of vehicle functions and subsystems. The system is initially at rest at 300 until, at 302, a request is received from a mobile device running a mobile application to access a vehicle subsystem. For example, the request might be to access the vehicle's radio, climate control, navigation, or audio system. Then, at 304, the SYNC device designation is determined—specifically, whether the request is from a primary mobile device (the vehicle's driver) or a non-primary mobile device (a vehicle occupant, including both front and rear occupants).The device identifier can be determined by the mobile application, which prompts the user to enter their vehicle seat position into the mobile device. Alternatively, the vehicle seat position associated with the mobile device can be determined by a sensor or other similar mechanism for determining the position / orientation of the mobile device within the vehicle. If the device identifier is primary at 304, then the access request at 310 is rejected or denied. This illustrative procedure applies only to non-primary devices, as there are no requirements when a driver uses a smart device connection for remote control. A driver is granted access to all permissible vehicle subsystems; therefore, this does not apply to primary devices.

[0035] If the device identifier is not primary at decision block 304, the system authenticates the application using the local policy table 306. If an application identifier is not found in the local policy table, the system requests a policy table update from the remote server (as described above in relation to...). Fig.(discussed in section 2). Once the application has been authenticated using one of the security mechanisms discussed above, the system then queries the local policy table to determine whether the access request is valid and can be granted at decision block 308. If not, the access request is denied at 310. If an access request is valid at decision block 308, the system then queries the policy table at decision block 312 to determine the specific application permissions corresponding to the selected vehicle subsystem and the vehicle seat position associated with the mobile device. During this query, the system also determines, based on the application permissions, whether the access request can be automatically acknowledged (thus reducing driver distraction) or whether driver authorization is required.An access request can be automatically acknowledged if an occupant / local zone control is located in the vehicle seat position associated with the mobile device. If the access request concerns the vehicle's heating and / or cooling controls and separate occupant controls are located in the seat position associated with the mobile device, the system can be configured to automatically acknowledge such a request, as shown in Block 320. However, if no separate occupant controls are located in the seat position, the system will prompt the driver for authorization via the HMI, as shown in Block 314. Additionally, access to some vehicle subsystems, such as adjusting the radio, will always require driver authorization.

[0036] After requesting driver authorization to transfer control of a vehicle subsystem to the mobile application associated with a non-primary device at 314, a timeout period is initiated at 316. If the driver does not respond to the driver authorization request before the timeout period 316 expires, the mobile application's access request is denied at 310. Similarly, if the driver denies authorization at 318 before the timeout at 316 expires, the mobile application's access request is denied at 310. Conversely, if the driver grants authorization at 318 before the timeout at 316 expires, the access request at 320 is granted.

[0037] When granting access to the mobile application to control the selected vehicle subsystem, the driver is notified and / or alerted about the transfer of control, and the mobile application is informed that the request has been granted. This authorization is displayed on the mobile device to alert the user of the status change and to allow the user to control the functionality associated with the selected vehicle subsystem. The driver can terminate access to a vehicle subsystem via the mobile application at any time using the HMI. Access to the vehicle subsystem can also be terminated by the ignition cycle, which closes the mobile application through the vehicle's interface and deactivates or disables any remote control feature in the vehicle.Furthermore, after a predetermined amount of time, the mobile application will switch itself off and transfer control back to the driver.

[0038] As can be seen from the representative embodiments described herein, the embodiments according to the present disclosure effectively mitigate risks associated with managing control across multiple devices within a vehicle, while reducing driver distraction.

[0039] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the disclosure. The terms used in the description are descriptive rather than limiting, and it is understood that various modifications can be made without departing from the spirit and scope of the disclosure. Furthermore, the features of different implementing embodiments can be combined to form further embodiments of the disclosure. While the best mode has been described in detail, the person skilled in the art will recognize various alternative designs and embodiments included in the scope of the following claims.Although various embodiments may be described as advantageous or preferred over other embodiments with respect to one or more desired properties, the person skilled in the art recognizes that one or more properties may be compromised in order to achieve desired system attributes, which depend on the specific application and implementation. These attributes include, among others: cost, strength, service life, life cycle costs, marketability, appearance, packaging, size, operability, weight, manufacturability, ease of assembly, etc. The embodiments discussed here, which are described as less desirable than other embodiments or implementations according to the prior art with respect to one or more properties, are not outside the scope of protection of the disclosure and may be desirable for certain applications.

Claims

[1] System, encompassing: a vehicle (102) designed, in response to receiving a request from a mobile device (152) associated with a specific seating position to access a safe vehicle function, to request authorization from the driver for the mobile device (152) to access the function based on the seating position associated with the mobile device (152) and to query a local policy table (206) that defines, based on the associated seating position, which vehicle functions accessible to the mobile device (152) require authorization from the driver. [2] System according to claim 1, wherein the safe vehicle function is vehicle navigation control or radio control. [3] System according to claim 1, wherein the vehicle (102) is further designed to: to deny the mobile device (152) access to the safe vehicle function in response to the failure to receive driver authorization within a predetermined time period; and the mobile device (152) provides access to the safe vehicle function in response to the receipt of driver authorization within the predetermined time period. [4] System according to claim 1, wherein the vehicle (102) is further designed to deny the mobile device (152) access to a second safe vehicle function in response to the mobile device (152) attempting to access the second safe vehicle function for which the mobile device (152) lacks authorization according to the local policy table (206). [5] System according to claim 1, wherein the vehicle (102) is further designed to in response to receiving a request from the mobile device (152) to access a second safe vehicle function and identifying that the local policy table (206) is missing permissions associated with the second safe vehicle function and the seating position associated with the mobile device (152), to send an application message to the mobile device (152) requesting an update of the policy table from a remote server (218). [6] System according to claim 1, wherein the vehicle (102) is further designed to provide the mobile device (152) with access to a second safe vehicle function in response to receiving a request from the mobile device (152) to access the second safe vehicle function and to determining, based on the local policy table (206), that the second safe vehicle function includes occupant controls located within a vehicle occupant zone associated with the seating position. [7] System according to claim 6, wherein the vehicle (102) is further configured to request a driver authorization for user access to the second safe vehicle function in response to receiving the request from the mobile device (152) to access the second safe vehicle function and to determining, based on the local policy table (206), that the occupant controls are not located in the vehicle occupant zone. [8] System according to claim 1, wherein the request is generated by the mobile device (152) by a mobile application (202) running on the mobile device (152), and the vehicle (102) is further designed to terminate the mobile application (202) in response to receiving a driver request to terminate the mobile application (202). [9] System according to claim 6, wherein the vehicle (102) comprises a human-machine interface (136), and the vehicle (102) is designed to display a driver notification on the human-machine interface (136) in response to the mobile device (152) being provided with access to the second safe vehicle function, indicating that access has been provided to the mobile device (152). [10] System according to claim 1, wherein the vehicle (102) is further designed to authenticate the mobile device (152) on the basis of the local guideline table (206). [11] System, encompassing: a mobile device (152) connected to a computing platform (104) of a vehicle (102) which is programmed to to run a mobile application (202) to access a vehicle subsystem; to prompt a user to enter a vehicle seat position; and to send an update of a policy table to the computing platform (104) that was received from a remote server (218), including a local policy table (206) with application permissions that define which functions of the vehicle (102) the mobile application (202) can access based on the vehicle seat position. [12] System according to claim 11, wherein the mobile device (152) is further programmed to display an indicator for granted in response to the fact that the computing platform (104) provides access to the vehicle subsystem to the mobile application (202), and to display an indicator for access denied in response to the fact that the computing platform (104) denies access to the vehicle subsystem to the mobile application (202). [13] System according to claim 11, wherein the mobile device (152) is further programmed to display a selection of vehicle subsystems available for occupant control and to prompt the user to select the vehicle subsystem to be controlled.

Images