Centralized management of motor vehicle software applications and services.

(54) Title: CENTRALIZED ADMINISTRATION OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES.

(54) Title: CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND SERVICES.

(57) Summary

In one example, a network device 222 maintains a list 609 of available user application programs. The network device (222) approves at least one of the user application programs available for use on a specified make and model of motor vehicle, where approval is determined by or on behalf of the vehicle OEM or service providers. . The network device 222 forms a controlled list of applications 610 that identifies the approved applications. The network device 222 selects at least one application from the controlled list of approved applications for download 239 to a specific motor vehicle, where the selection is made by or on behalf of a motor vehicle owner. specific. The network device 222 wirelessly downloads the selected application program to the specific motor vehicle and causes the downloaded application program to be installed in a header unit 221 of the specific motor vehicle.

(57) Abstract

In one example, a network device (222) maintains a list (609) of available user application programs. The network device (222) approves at least one of the available user application programs for use in a specified motor vehicle make and model, where said approval is determined by or on behalf of the vehicle OEM or Service providers. The network device (222) forms a controlled list (610) of applications that identifies the approved applications. The network device (222) selects at least one application from the controlled list of approved applications for download (239) to a specific motor vehicle, where said selection is made by or on behalf of an owner of the specific motor vehicle. The network device (222) wirelessly downloads (250) the selected application program to the specific motor vehicle and causes the downloaded application program to be installed on a head unit (221) of the specific motor vehicle.

CENTRALIZED ADMINISTRATION OF APPLICATIONS AND SERVICES OF

MOTOR VEHICLE SOFTWARE

DESCRIPTION

This application claims priority of the following applications from the United States of America: application No. 12/777, 989 filed on May 11, 2010, titled: CENTRALIZED MANAGEMENT OF MOTOR VEHICLE SOFTWARE

<td>10 APPLICATIONS AND</td><td>SERVICES,</td><td>What is it</td><td>a</td><td>application</td>

<td>continued on</td><td>part of</td><td colspan="2">application</td><td>patent</td>

<td>North American No</td><td> . 12/729,207</td><td>filed</td><td colspan="2">on March 22,</td>

<td>2010, titled:</td><td>CENTRALIZED</td><td>MANAGEMENT</td><td>OF</td><td>VEHICLE ENGINE</td>

SOFTWARE APPLICATIONS AND SERVICES, which is a non-provisional application 15 of provisional application No. 61 / 252,066 filed on October 15, 2009, titled: CENTRALIZED

MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND

SERVICES, and provisional request No. 61 / 260,781 filed on November 12, 2009, entitled CENTRALIZED

MANAGEMENT OF MOTOR VEHICLE SOFTWARE APPLICATIONS AND

SERVICES each of which is incorporated herein by reference in its entirety.

Background and scope of the invention

A motor vehicle can be equipped with a main unit that has a user interface. The user interface can include various resource components such as a screen, speakers, a microphone, a touch screen and / or keyboard, etc. Smartphones and other mobile phones can download various applications that operate on the phone. A user can use a phone user interface to control the application and / or use the application in some way (such as seeing the display screen or listening to the audio output).

Extending mobile phone applications to the main unit has become a popular feature offered by various service providers and vehicle manufacturers. As a result, the user can take advantage of better user interface components offered by the main unit (eg larger screen and higher quality audio output). It is desirable to establish a mechanism to control, manage and arbitrate the extension of mobile telephone applications that operate on the main unit using the service control logic available on a remote server.

Vehicles can also be built with components that allow apps to be installed in the vehicle itself (instead of being installed on a mobile device). It is also desirable to control, manage and arbitrate the use of the vehicle interface by these applications.

Brief description of the invention

The following is a brief description of the invention in order to provide a basic understanding of some aspects of the invention. This brief description is not intended to identify the key / critical elements of the invention or to delimit the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description presented below.

In one example, a network device stores a _ mapping of application operation modes for conditions¹of the vehicle such as a first condition of the vehicle powered but not in motion and a second condition of the vehicle in motion. The network device receives a wirelessly transmitted request (sent by a vehicle's wireless transmitter or a vehicle-attached mobile device) for a particular application to use a vehicle-powered interface. The network device compares an application identifier specified in the received request for allocation or mapping. The network device then identifies a portion of the vehicle interface according to the comparison and signals control software in the vehicle to allow access by a particular application to only the identified portion of the vehicle interface. The app can reside on the mobile device and use the vehicle interface as an extended interface, or the app can reside on the vehicle itself. Additional aspects and advantages of this invention will become apparent from the following detailed description of preferred embodiments, which proceed with reference to the accompanying figures.

Brief description of the figures

Figure 1 illustrates a system for controlling the use of a main unit as an extended interface for a telephone application in a secure and intelligent manner.

FIG. 2A illustrates a flow chart showing the operation of the software 32 of FIG. 1.

Figure 2B illustrates a flow chart showing a containment scheme that can be used by the software 32 of Figure 1.

Figure 3 illustrates a flow chart showing the operation of the software 30A-B in Figure 1.

Figure 4 illustrates a system for selecting and distributing applications for a vehicle in a safe and intelligent way.

Figure 5 illustrates a flowchart showing the operation of the software of Figure 4.

Figure 6 illustrates in more detail the system shown in Figures 4-5.

Figure 7 illustrates a system for selecting and distributing applications for a vehicle in a safe and intelligent way according to user preferences.

Figure 8 illustrates a flowchart showing the operation of the software of Figure 7.

Figure 9 illustrates in more detail the system shown in Figures 7-8.

Figure 10 illustrates a system for selecting a graphical head unit interface in accordance with a main unit configuration.

Figure 11 shows a system for generating and sending remote compute approvals to the main unit.

Figure 12 shows a graphics system for pushing graphical user interface updates to the main unit in response to mobile devices. A request for a new application or user web portal is submitted by selecting a new request.

Figure 13A illustrates a flow chart showing before operation of a parental control scheme.

Figure 13B illustrates a flow chart showing the operation of the parental control system.

Detailed description of preferred modalities

In one example, a user couples a phone to a main unit of the motor vehicle via a wired or wireless connection in order to use the main unit as an extended interface for the phone. The user can allow to control an application on the phone through the interface of the main unit, depending on a determination through a remote server as described in the following paragraph. Similarly, the user may be allowed to see or hear an application output on the interface of the main unit, depending on a determination via a remote server as described in the following paragraph.

Novel client control software on the phone and head unit comes in contact with the novel server control software on a remote server via a wireless connection that extends from the phone. The client control software identifies a phone application to use the main unit as an extended interface. The server control software compares the identified phone application with one or more databases accessible by the remote server. Based on the comparison, the server control software determines whether the identified request will be allowed to use the head unit as an extended interface and, if so, which components of the head unit interface will be allowed to be used by the application. The server control software indicates the client control software to control the phone and the main unit according to the determination. Consequently, any use of the main unit as an extended interface can be controlled in a safe and intelligent way.

Figure 1 illustrates a system for controlling the use of a main unit as an extended interface for

<td>an application of</td><td>phone</td><td>of</td><td>a way</td><td>safe</td><td>and</td>

<td>intelligent.</td><td></td><td></td><td></td><td></td><td></td>

<td>The system</td><td colspan="2">100 includes</td><td>the software</td><td>30A and</td><td>30B</td>

<td colspan="2">configured in respectively</td><td>a</td><td>mobile phone</td><td colspan="2">20 (or other</td>

mobile device) and the main unit 21 (or other interface powered by a motor vehicle, such as a user interface integrated with a steering wheel or a user interface integrated with a rear seat). The software and interfaces 30A and 30B with software 32 configured on a remote server 22 to regulate and control when and how applications 40 operating on telephone 20 access I / O resources 1-4 from main unit 21.

FIG. 2A illustrates a flow chart showing the operation of the software 32 of FIG. 1.

At block 201, the software 32 receives a request for a particular application 40 on the telephone 20 to use the interface (including input 24 of resources 1-2 and output 25 of resources 3-4) of the main unit 21. The request it includes a user identifier corresponding to the user of the motor vehicle and / or the main unit 21, an application identifier corresponding to the particular application 40 and information on the state of the vehicle. The user identifier may be an identifier provided by the user when the control software 30A was first activated on the mobile phone 100, the user's telephone number, etc.

At block 202, software 32 authenticates the user. This may include determining whether the user identified by the user identifier matches a subscriber database 11 for the service of extending the telephone interface 20 using the main unit 21. If the user is not authenticated at diamond 203 , then at block 204A, software 32 signals software 30A / B to block access by application 40 to main unit 21. It should be understood that system 100 can be configured such that block 202 is optional.

Otherwise, if the user is authenticated, then in block 204B of the software 32 he authenticates the application 40 by comparing the identifier of the application with a list of applications 12 (also referred to as a white list). This list 12 can be compared by the version number such that a particular version of an application 40 can be identified in the list, while a different version is excluded. If the particular application 40 (or a particular version) is not listed 12 in diamond 205, then in block 204A the software 32 signals the software 30A-B to block access by the application 40 to the main unit 21.

<td>Of</td><td>the</td><td>contrary,</td><td>yes</td><td>the application</td><td>40 is</td>

<td>authenticated,</td><td>to</td><td>continuation,</td><td>in</td><td>block 206 the</td><td>software</td>

<td>32 compare the</td><td colspan="2">identifier of</td><td>the</td><td colspan="2">application and information</td>

the current state of the vehicle with a mapping of 15 application modes of operation. As shown, mapping 15 may have an entry 17 for each application 40 in list 12. Each entry 17 includes a mapping that is customized for the corresponding application 40. For example, an input 17 for application A maps the state of the vehicle moving vehicle &lt;X with resources 1, 2 and 4 (specifically, application A will allow access only to screen 1, speaker 2 and to microphone 4 under this vehicle condition), while input 17 for application C maps or assigns the status of the moving vehicle vehicle &lt;X only to resources 2 and 4 (specifically, application C will be allowed to access the 2 speakers and a microphone 4). A real example may be a navigation application A and a video game of application C, where even when a passenger is present the system 100 will not allow the video game application C that is displayed on the main unit 21 screen 1, since it is considers it to be too distracting for the driver, while the navigation application can be displayed on screen 1 of main unit 21. Another real application can be a vehicle with a plurality of interfaces, such as a main unit and a screen attached to the back of a seat. An application may have access to the rear seat display in conditions where the same request would not be allowed access to the main unit.

It should be understood that, in other examples, the allocation 15 can be stored in the mobile phone 20.

In this case, the comparison described in the previous paragraph can be made by the control software 30A. In such a case, the control software 30A checks the current status of the vehicle by communicating with the main unit

21.

At block 207, software 32 identifies a set of all or some of the I / O resources of main unit 21 according to the comparison. At block 208, the software 32 indicates the remote control software to provide the particular application 40 with access only to those I / O resources 1-4 of the identified set. In one example, such signaling or indication may include control of software 30A on mobile phone 20, such that all access requests sent from mobile phone 20 conform to the identified set of I / O resources. In another example, such signaling may include controlling the software 30B on the main unit 21 to block the access requests sent from the mobile phone 20 in any way such as just by deactivating the I / O resources on the main unit 21. In still other examples, such signaling may include controlling both software 30A and software 30B.

Figure 2B illustrates shows a flowchart containment scheme that can be used by the software 30B of figure 1. A containment scheme can be used in addition to the scheme shown in figure 2A.

At block 209, software 30B determines if any of the I / O resources in the identified set are currently in use. 'If neither is in use on diamond 210, then on the block. 211A software 30B provides access to the particular application to only those I / O resources in the identified set.

Otherwise, if at least one of the resources in the set is in use, then, at block 211B, the software 30B identifies a classification by resource 13 of the requests for each of the resources in use of the identified set. This is shown in Figure 1, where there is a 13 classification for each resource 1-4. At block 212, software 30B compares the identifier of

<td>application</td><td>with</td><td>the)</td><td colspan="2">classification(</td><td>is) 13</td><td>per resource for</td>

<td>decide</td><td>yes</td><td>the</td><td>application</td><td> 40</td><td>has</td><td>priority for</td>

<td>anyone</td><td>of</td><td>the</td><td>resources</td><td>in</td><td>use</td><td>of the subset</td>

identified (can be done via signaling since rating 13 is displayed on the remote server or the rating may have been sent to the vehicle interface in a previous process). This comparison will indicate whether the application that is currently using a particular resource in use is considered to have a higher or lower priority than the requesting application for that resource in use. At block 213, the software 30B provides access to the particular application 40 only to those of the I / O resources 1-4 of the identified set that are either not currently in use or in use by a lower priority application.

Figure 3 illustrates a flow chart showing the operation of the software 30A-B in Figure 1.

At block 301, software 30A-B sends a request for a particular application 40 on phone 20 to use the interface of main unit 21. At block 302, software 30A-B again receives a signal indicating whether application 40 is authorized or not to access main unit 21 at this time, and if so, it sends an identification that resources 1-4 can be used. If application 40 is not authorized on diamond 303, then at block 304A of software 30A-B 'a notification is issued that application 40 is not authorized to access the main unit. This notification could be output by mobile phone 20 or main unit 21, or both.

Otherwise, if application 40 is authorized on diamond 303, then, at block 304B, software 30A-B controls mobile phone 20 and main unit 21 to cause application 40 to extend to identified resources. If only a subset of possible resources for application 40 (from respective mapping 17) are used due to a conflict, then software 30A-B can generate a notification to alert the driver to the lowest priority request to be suspended earlier to activate the highest priority request. In another example, if the resources are currently used by a lower priority request, the 30A-B software can automatically suspend / terminate the lower priority request and allow the highest priority application to be activated by the required resources.

If it is determined that the application 40 can be extended to the main unit 21, the server 22 can download corresponding control panel software for the main unit to control the application 40. Having downloaded this software to the main unit 21 on the basis of the requested application, a service provider can consequently customize and update the control panel when new applications or updates for existing applications are available. The main unit may have a web code renderer to display the control panel software.

Referring again to Figure 1, software 30A-B interfaces with software 32 via a wireless connection that extends from telephone 20. This wireless connection can use a packet data connection (including but not limited to GPRS, EDGE, EVDO, UMTS, WiMAX, WiFi, etc.), Short Message Service (SMS), or in-band signaling modems on the mobile phone 20 and on remote server 22 as described in US Patents 6,144,336; 6,690,681 and 6,493,338.

Still referring to Fig. 1, it is noted that the mobile phone 20 can be coupled to the main unit 21 via a connection such as a USB, Bluetooth or WiFi connection. These are only examples, however, and in other cases a different connection and / or protocol may be suitable for using the interface of the main unit 21 for the application 40 of the telephone 20.

It should be understood that the mapping or mapping 15 can have any other state of the vehicle and that the four illustrated examples are merely some examples. For example, another state of the vehicle could be if the vehicle is moving more than X speed and a passenger is present.

It should be understood that main unit 21 may include less than all of the sample resources shown or other resources not shown. For example, another possible resource I / O component is a text-to-speech component.

In the illustrated example, a first application can be allowed to access a first subset of whatever resources are actually present in main unit 21 on the basis of an intelligent decision by system 100, while a different second application is allowed it can allow you access to a second subset of resources or even all of the resources.

It should be understood that the applications 40 can be classified by resource, as illustrated or they can be only a single classification including all applications 40. The system 100 is implemented with the classification by resource, as shown, but the concepts described in this document could be implemented in another application classification system, regardless of resources.

Figure 4 illustrates a system for selecting and distributing applications for a vehicle in a safe and intelligent way.

One difference between the Figure 1 system previously discussed and the Figure 4 system is the application installation location. Whereas the AC applications in system 100 of FIG. 1 are installed and operating on mobile phone 20 (using the main unit 21 or other interface powered by the vehicle as an extended interface), the JL applications in system 200 of Figure 4 are installed on the main unit 221 or other component powered by the vehicle. In system 200 of FIG. 4, software 230-232 enables a vendor to select which applications can be installed on main unit 221 and control the distribution of selected applications in the vehicle.

<td></td><td>Before</td><td>to argue</td><td>the details</td><td>of the system</td><td> 200</td><td>in</td>

<td>the</td><td>paragraphs</td><td>following,</td><td>must be</td><td colspan="2">evident that</td><td>the</td>

<td colspan="2">structures and</td><td>functions of the</td><td>10C system</td><td>i described</td><td>in</td><td>the</td>

Figures 1-3 can be combined with the structures and functions of System 200 (Figures 4-6) in a single system. For example, a single system could include some applications installed on a mobile phone using a vehicle interface as an extended interface and some applications installed on a vehicle component.

Figure 5 illustrates a flowchart showing the operation of the software of Figure 4.

At block 501, in response to the vehicle having been activated, the control software 230 sends a signal 244 to the server 222 indicating that the vehicle is started. Signal 244 can be sent through a local connection, such as a USB or Bluetooth connection to be transmitted by mobile device 220 in a wireless telecommunications network.

At block 502, software 232 checks a download directory 239 (sometimes referred to as a litter box) associated with the vehicle to determine if there are any applications to be downloaded to the vehicle. A scheme to intelligently select the applications that are present in the download directory

239 will be discussed in detail later with reference to Figure 6.

If verification by software 232 indicates that download directory 239 includes at least one application, the process continues. For now, for illustration purposes it is assumed that download directory 239 includes 240 (JL) applications. Accordingly, at block 503, software 232 generates and sends signals 245 to make IP gateway software 231 on mobile phone 220 function as an IP gateway for relaying requests to main unit 221. In one example, signals 245 include communications to dynamically load mobile phone 220 with software 231 in response to the determination in block 502 and cause software 231 to operate on it for download to the vehicle. Signals 245 cannot occur if mobile phone 220 is already loaded with software 231 and is ready for IP gateway operation. In other examples, signals 245 could originate from control software 230 on main unit 221 in response to detection of vehicle ignition.

At block 504, software 232 generates and sends IP packets 250 to download applications 240 to the vehicle. IP 250 packets are received by mobile phone 220 and forwarded by operation of software 231 to main unit 221. In block 505, software 230 receives IP 230 packets and installs 240 (JL) applications in the vehicle ( installation may be on components of main unit 221 or other vehicle components).

Thereafter, a vehicle user can operate the JL applications using the main unit 221 as an interface. It should be understood that software 230 and software 232 can operate in accordance with any of the principles described in Figures 1-3. For example, software 230 and 232 can regulate the use of the I / O resources of main unit 221 by the active application (s) according to the current state of the vehicle. As another example, on systems where applications are installed in the vehicle and on a mobile device, the 230 and 232 software can include all the applications that the vehicle interface uses in an application ranking / priority table similar to the table 13 (figure 1).

In one example, main unit 221 includes a web code processor (renderer) 299, for example, an HTML processor, controlled by software 230. The web code processor (renderer) 299 is configured to display the HTML code, but unlike a browser, it does not allow the user to freely navigate to web sites. Specifically, the web code processor 299 displays only the applications authorized by the provider, for example, those specified by the server 222.

It should be understood that the flow chart described above controls the update applications installed in the vehicle. The vehicle can also be pre-loaded with certain applications so that some of the applications installed in the vehicle are downloaded according to the flow chart, while others are installed there during manufacturing.

Thus, based on the principles outlined above, vehicles can be manufactured without applications installed on the vehicle, but instead, applications can be downloaded to vehicles when drivers are present in vehicles. The types of applications downloaded to vehicles are governed by the preferences defined in the network server provided by the drivers.

Figure 6 illustrates in more detail the system shown in Figures 4-5.

It was previously explained that server 222 includes a download directory 239 of requests waiting to be downloaded on a per-vehicle basis. Figure 6 illustrates the user web portals 601, 604, and 605 that may be involved in the selection of applications in the download directory 239 and describes an example of use of these web portals 601, 604, and 605.

A provider such as a vehicle OEM operates portal 601. Using an interface such as a computing terminal 625, the provider controls an application selection portion 608 of web portal 601 with communications 650 to mount the controlled list 610 of applications. from the 609 list of all applications that can be installed in the vehicle. In general, the construction of list 610 of list 609 includes the validation of applications from a technical point of view and / or from a supplier business point of view.

The provider also sends communications 651 to select applications from control list 610 to be installed in a particular vehicle. These selections can be based on an assignment or mapping of some vehicle models to the applications, for example. These 652 selections are entered in the download directory

239.

As for the list of all available applications 609, it should be understood that this list can be assembled by applications developed by the provider and / or by third parties. In the case of third parties that provide the applications, the third party uses the request submission portion 618 of the web portal 604 (which is hosted on a provider-operated web server in one example) to submit a 649 request to be included in the list 609.

A vehicle user can also select the applications to be included in the download directory 239 using a computing terminal 626, for example using any computing device accessible to the Internet, such as a mobile device or a desktop computer. The computer terminal 626 accesses the application selection portion 628 of the user's web portal 605 (which is hosted on a provider-operated web server in one example) to view the checklist 610 of the applications that can be installed in your vehicle. The user can send 661 communications to select applications from the 610 control list that the user would like to install in their vehicle. These selections 662 are entered in download directory 239.

The user's web portal 605 can also be configured to allow a user to delete particular applications from download directory 239, for example, the user may wish to delete one of the selected applications 652 from providers added to download directory 239 via from the provider. Deletion can be done by deleting an application that has already been submitted to directory 239 or by indicating that a particular application is not desired before such application is added to the download folder or directory 239.

Accordingly, the applications can be accumulated in the download directory by the vehicle 239. Upon vehicle start-up, such applications can be downloaded and installed in the vehicle. Download directory 239 can then accumulate new applications until a new vehicle start-up.

It should be understood that an interface similar to that of the 605 web portal can be displayed on the vehicle's main unit. The user can then make selections from this type of interface to select applications from the 610 checklist. The selected applications can be immediately downloaded to the vehicle instead of being placed in the download directory when the selections are made from the interface.

Figure 7 illustrates a system for selecting and distributing applications to a vehicle in a safe and intelligent way according to user preferences.

One difference between the Figure 1 system previously discussed and the Figure 7 system is the installation location for the applications. While the AC applications in system 100 of FIG. 1 are installed and operating on mobile phone 20 (using the main unit 21 or other vehicle-powered interface as an extended interface), the MP / QS applications in system 300 of Figure 7 are installed in the main unit 321 or other component powered by the vehicle. In system 300 of FIG. 7, software 330332 enables a vendor to select which applications can be installed on the main unit 321 and control distribution of the selected applications to the vehicle.

Before discussing the details of system 300 in the following paragraphs, it should be apparent that the structures and functions of systems 100 and 200 described in Figures' 1-6 can be combined with the structures and functions of system 300 (figures 7-8) in a single system. For example, a single system could include some applications installed on a mobile phone using a vehicle interface as an extended interface and some applications installed on a vehicle component.

Figure 8 illustrates a flow chart showing the operation of the software of Figure 7.

At block 801, main unit 321 is communicatively paired to a mobile device such as mobile phone 320. In one example, connection 540 is established through the Bluetooth pairing of main unit 321 and mobile phone 320. The Bluetooth pairing may be in response to the vehicle starting up (causing the main unit to turn on and search for a Bluetooth device), although it should be clear that the Bluetooth pairing could result from other circumstances such as turning on the phone mobile 320, mobile phone 320 is within range of main unit 321, reconnection after another Bluetooth device was disconnected from main unit 321, etc. In other examples, the communication connection can be established by a user connecting the mobile phone 320 to the main unit 321 by means of a connection

USB.

At block 802, the control software 330 has access to a mobile phone number 320. It should be understood that mobile phones are activated with a particular phone number in conjunction with subscription to a calling plan, which is the number control software telephone 330 that is read from mobile phone 320. In one example, signaling 542 to obtain the telephone number is performed using Bluetooth signaling.

At block 803, · the control software 330 sends signals 543 to the server 322. The signaling 543 can be sent through a local connection, such as a USB, Bluetooth or WiFi connection to be transmitted by the mobile device 320 in a network wireless telecommunications. The content of signaling 543 may be similar to signal 244 which was described in more detail above with respect to FIG. 4, but may further provide the obtained telephone number.

At block 804, control software 332 compares the telephone number included in signaling 543 for assignment or mapping 350. The mapping maps each of a plurality of AB download directories accessible through this particular main unit 321 to a home phone number. For example, in mapping or mapping a first phone number is mapped to download directory A and a second phone number is mapped to download directory B. Control software 332 selects one of AB download directories based on Comparison of phone number received for allocation 350.

Software 332 then checks the selected directory from one of the AB download directories to determine if there are applications that are stored in the selected directory. A scheme for intelligently selecting the applications that are present in the AB directory download is discussed in detail later with reference to Figure 9. For now, we'll assume that, for illustration purposes, the 339A and 339B download directories currently include the 340A (MP) and 340B (QS) applications, respectively, in addition to the front-end 369A and 369B settings of the main unit. .

As briefly mentioned in the previous paragraph, the AB download directories include main unit front end AB configurations, respectively, in addition to the 340A and 340B applications. AB settings can be stored as HTML code or other web code that is compatible with the 399 web code processor. Depending on which of the main unit AB interface settings is downloaded to the main unit 321, a screen 380 of the main unit 321 will show a different graphical user interface. Each of the different 369A and 369B web code files will produce a different graphical user interface when displayed using the 380 display and the 399 processor. For example, each GUI may have its own custom user settings, such as a particular wallpaper selected by a user. A schematic for generating the different front-end AB configurations of the interface unit will be discussed in more detail below, referring to Figure 9.

At block 805, software 332 generates and sends signals to make IP link gate software 331 on mobile phone 320 function as an IP link gate for transmitting applications to main unit 321 similar to the scheme described in figure 4. In an example, similar to that of Figure 4, signaling of this type includes communications to dynamically load mobile phone 320 with software 331 to cause software 331 to operate on it for download to the vehicle. This signaling may not occur if the mobile phone 320 is already loaded with the 331 software and ready for the operation of the IP gateway. In other examples, signaling or signals 345 could come from control software 330 on main unit 321 after connection 540 is established.

At block 806, software 332 generates and sends IP 545 packets to any of the MP applications and configuration A or QS applications and configuration B. IP 545 packets are received by mobile phone 320 and forwarded via the operation of the software 331 to the main unit 321. It should be understood that, in this particular illustration, IP 545 packets include both applications and a configuration for the graphical user interface, but in other scenarios IP 545 packets could contain either an application or a configuration. Also, it should be clear that if there are no applications at a certain time in the selected download directory and no changes have occurred in the settings stored in the download directory since a previous download, then IP 545 packets cannot be sent.

At block 807, the software 330 receives the IP 545 packets and installs the applications included there in the vehicle (the installation can be in the components of the main unit 321 or other components of the vehicle). The software 330 also processes the configuration coming from the IP 545 packets using the 399 web code processor to generate a particular graphical user interface based on the detected phone number.

Next, the graphical user interface exiting through screen 380 will correspond to a configuration of the AB configurations stored in the selected download directory. A vehicle user can operate the installed MP or QS applications using the 321 main unit as an interface.

It should be understood that the 330 and 332 software can operate according to any of the principles described in Figures 1-3. For example, the software 330 and 332 can regulate the use of the I / O resources of the main unit 321 by the active application (s) according to the current state of the vehicle. As another example, on systems where applications are installed both in the vehicle and on a mobile device, the 330 and 332 software may include all applications that use the vehicle interface in an application ranking / priority table similar to table 13 (figure 1).

In the example described above, the control software 330 has access to a telephone number of the mobile phone 320 to distinguish the mobile phone 320 from other mobile phones. In other examples, the control software on the main unit 321 may access a different value on a communicatively coupled mobile phone to unambiguously identify the mobile phone than other mobile phones. Other examples of values ​​may include, but are not limited to, a physical mobile phone address. In such other examples, it should be apparent that such values ​​are used in the mapping or mapping, for example if the other values ​​are physical addresses then the mapping or mapping includes physical addresses correlated to download directories.

In the example described above, the control software 330 sends the unique access identifier (phone number in this example) to the server 322. In other examples, the assignment 350 can be stored in the vehicle. In such a case, the control software 330 identifies a particular download directory listed in the mapping or mapping according to the comparison and sends an identifier specifying the particular download to the server 322. Server 322 can then respond with IP 545 packets that send data from the identified download directory.

Figure 9 illustrates in more detail the system shown in Figures 7-8.

It was previously explained that server 322 includes a plurality of download directories 339A-B of applications waiting to be downloaded. Figure 9 illustrates the user web portal 905 that may be involved in creating the 339A-B download directories and selecting applications on a per directory basis and describes an example of using this 905 web portal.

A vehicle user can create a plurality of profiles corresponding to the vehicle with the profile creation portion 930 of the user web portal 905. A profile can be created for each person who can use the vehicle. A field 927 requests a unique phone number or other unique identifier of a mobile phone, respectively, that corresponds to each person. A name of each person or other information for each person can be obtained with the phone number (s). After or during profile creation, server 322 creates a download directory for each profile and updates mapping mapping

350 for each number / directory combination. In some examples, portion 930 may be configured to allow a user to classify the created profiles so that if the main unit can be coupled to more than one of the mobile devices simultaneously (this may depend on the connection protocol as long as it is possible), the best classified of the corresponding profiles will be the one used.

During or after profiling, the 905 web portal can be used to select applications to be included in the 339A-B download directories using a 926 computing terminal, for example, using any accessible Internet computing device, such as a mobile device or desktop computer. The computer terminal 926 accesses the application selection portion 928 of the user web portal 905 (which, in one example, is hosted on a provider-operated web server) to view the controlled list of applications that can be installed on the vehicle. The user can then send 961 communications to select the applications from the control list that the user wants to install in their vehicle based on each directory. These selections 962 are respectively fed into the 339A-B download directories on a per directory basis.

User web portal 495 can also be configured to allow a user to remove particular applications from 339A-B download directories, for example the user may wish to remove one of the selected provider 952 applications added to the download directories. loads 339A or 339B through the provider depending on each directory. Deletion can be by deleting an application you have already submitted to download directories 339A or 339B, or by indicating that a particular application is unwanted before the application is added to download directories

339A or 339B.

User web portal 905 may also include a main unit front end customization configuration portion 928. This portion 928 allows new 369A-B configurations to be added to 339A-B download directories, with each person's custom configuration according to their requests. For example, a first desktop background can be added to the 339A download directory and a different second desktop background can be added to the 339B download directory. Other customizations may include custom GUI buttons and custom GUI layout, custom images, etc.

Based on the above, applications can be accumulated in 339A-B download directories by vehicle based on each directory. Once the main unit is docked with a particular device on mobile devices, data from a corresponding directory in the 339A-B download directories can be downloaded and installed in the vehicle to provide a customized set of applications and an interface custom user.

It should be understood that an interface similar to that of portal 905 can be displayed on the vehicle's main unit. The user can then make selections from this interface to select applications from the controlled list. Selected requests can be immediately downloaded to the vehicle instead of being placed in the download directory when selections are made from the interface.

Figure 10 illustrates a system for selecting a graphical head unit interface in accordance with a main unit configuration.

System 1000 includes a server 1022 and a main unit 1021 that can include components similar to any of the servers described above and main units. It should be appreciated that server 1022 and main unit 1021 communicate using a mobile device (not shown) that is docked with main unit 1021. Main unit 1021 includes control software 1030 and server 1022 includes control software 1032.

Software 1032 identifies a configuration of main unit 1021, for example, by polling 1081 of main unit 1021 to collect information. The 1030 software responds 1082 with identification information for the configuration of the 1021 main unit. The 1082 response may include at least one of the following: vehicle make / model / year, a predefined code, or an ad hoc list of the 1021 head unit settings (such as color / monochrome display, native resolution, etc. .)

The software 1032 then selects from a plurality of graphical user interfaces based on the information from the main unit 1082. For example, if the information 1082 from the main unit includes a predefined code, the software 1032 can compare the code for a mapping Stored 1085 codes with YZ graphical user interfaces. The selected graphical user interface corresponds to a particular configuration of main unit 1021 as reported by information 1082. For example, if main unit 1021 has a monochrome display, the graphical user interface (GUI) may be interface Y While the 1021 main unit has a color display, the selected GUI may be the Z interface. Or, perhaps, if the 1021 head unit has a native resolution of a first value, the interface. The selected GUI can be the Y interface, while if the 1021 head unit has a native resolution of a second value, the selected GUI can be the Z interface. If the make / model / year interface of the car indicates the interior of a first design, for example a luxury motif, the GUI selected may be the Y interface, whereas if the make / model / year of the car indicates the interior of a second design, for example a sports motif, the selected GUI GUI may be the Z interface.

Once a graphical user interface has been selected the software 1032 performs an IP packet transfer 1045 from the graphical interface selected from the graphical user interfaces YZ. It should be understood that IP 1045 packet transfer can use the above described IP gateway software of the mobile phone (not shown). The 1030 software automatically installs the received graphical user interface. The selected graphical user interface can replace a default graphical user interface 1090 or an already downloaded graphical user interface that resides on main unit 1021 prior to transfer 1045.

It should be understood that the front end configurations described above can be applied to the selected and installed GUI user interface. For example, a selected GUI may be installed on the main unit 1021 and then further modified in appearance based on a custom front end selection according to a phone number of the mobile device currently paired to the main unit.

1021.

Figure 11 shows a system for generating and sending remote compute approvals to the main unit.

System 1100 includes a server 1122 and a main unit 1121 that can include components similar to any of the servers described above and main units. It should be appreciated that server 1122 and main unit 1121 communicate using a mobile device 1131. Main unit 1121 includes control software 1130 and server 1122 includes control software 1132.

The 1121 main unit includes a remote viewing desktop program, such as Virtual Network Computing (VNC^(R&gt;) the 1148 client connects to the 1149 VNC server running on the 1131 mobile device. By way of background, a VNC client and a server communicate to show the current view of the server desktop or other view at that time in the customer's screen.

The human interface device (s) connected directly to the client, for example, keyboard, mouse, etc., can be used in conjunction with the displayed image to remotely control the computing device running on the VNC server. If an application is running or running in full screen mode on the computing device with the VNC server, then the computing device with the VNC server controls that application (rather than the entire desktop).

The 1130 control software receives a request

1155 from the mobile device 1131 specifying a particular application X (1140). The 1130 control software identifies the application identifier corresponding to the 1155 request, either by extracting the identification itself from the 1155 request or by using a search based on information obtained from the request or any communication with the 1131 mobile device. Control software 1130 sends communication 1156 that contains the application identifier.

The 1132 control software compares the application identifier with an internal table and generates a VNC 1157 approval for application X. VNC 1157 approval specifies the particular conditions under which the VNC is approved in combination for this X application. For example, if Application X is a navigation application, the 1157 approval could specify that the VNC is approved only when the vehicle is stationary or moving. Conversely, if application X is a media authoring application, approval 1157 could specify which VNC is approved only when the vehicle is stopped.

VNC 1157 approval can also specify different approvals depending on whether the application is running in full screen mode or windowed mode. For example, the navigation application could be approved when the vehicle is in motion, but only as long as the navigation application is running on the 1131 mobile device in full screen mode. This will immediately prevent VNC functionality if the user switches the navigation application to windowed mode while the vehicle is in motion.

VNC 1157 approval can also specify phone numbers. For example, VNC may be allowed when the 1131 mobile device is running a media player application, but only if the mobile device has a particular phone number (this can be used as a form of parental control).

The 1130 control software stores the received VNC 1157 approval in an 1135 approval database

VNC. The 1130 control software continuously monitors the conditions based on the VNC approvals stored in the 1135 database to generate the 1160 control signal. The 1160 control signal controls whether the view

1161 The mobile device 1131 can be displayed at that time on a screen of the main unit 1121 by the VNC client 1148. The control signal 1160 also controls whether the inputs made using an input interface of the main unit 1121 will be sent 1162 to the VNC server. 1149.

Figure 12 shows a graphics system for pushing user interface updates to the main unit in response to mobile devices that submit a request for a new application or the user web portal by selecting a new request.

The 1200 system includes a 1222 server and a 1221 head unit that can include components similar to any of the servers and main units described above. It should be appreciated that the server 1222 and the main unit communicate 1221 using a 1231 mobile device.

Server 1222 .. may receive an indication of a new application to be used on the 1200 system in at least two different ways (the term new application refers to an application that has not previously been downloaded to main unit 1221 and / or used to main unit 1221 as an extended interface). In one form, mobile device 1231 sends an indication of a new X application (1240) to use main unit 1221 as an extended interface. More specifically, this indication is an approval request 1271 generated and sent by the control software 1230 in response to receiving a request 1270 from the mobile device 1231.

Another way that server 1222 can receive an indication of a new application is from control over user web portal 1205. The user 1205 web portal is similar to the previously described web portals. Using an application selection tool 1228, a user can use any remote computer to select the applications to be included in a corresponding download directory (not shown) for installation on the main unit. Thus, a received selection 1274 that includes a new application is another form of indication of a new application to be used in the 1200 system.

In response to detecting such an indication, the 1232 control software determines whether to transmit a

IP 1245 including a graphical user interface update for the new X application. It should be apparent that no transfer of such IP packets will be sent if a new X application is not included in the application list (Figure 6) previously discussed. In one example, the graphical user interface update modifies a previously selected and installed graphical user interface (Figure 10) to add an icon to access the new X application. In another example, the graphical user interface update includes any other form of update packet transfer for a previously selected graphical user interface installed for the operation of the new X application. The 1230 control software automatically installs the update in response upon sending the 1270 application and / or the 1274 selections. It should be evident that the 1245 transfer can be included with a download from the application itself in the event that the download is expected for the vehicle supply in a download directory.

Figure 13A illustrates a flow chart showing the pre-operation of a parental control scheme.

In block 1301, the server designates at least one profile that is under parental control. This profile can be selected by the account of assets, for example, marking a selection through the web portal.

At block 1302, the server receives a login for a user designated as a parent (usually the account holder) for the profile subject to parental control. In block 1303, the server makes a list of applications related to the profile subject to parental control to be displayed through the web portal.

In block 1304, after displaying the list, the server receives the selections from the displayed list. The server can store these selections in the profile that is subject to parental control. Selections can include applications from the list and / or obtain more detailed information in the case of a conditional approval (a conditional approval is discussed in detail later).

Figure 13B illustrates a flow chart showing the operation of the parental control system.

At block 1320, in response to a mobile phone communicatively coupled with the main unit, the main unit obtains a phone number from the mobile phone to be used to communicate with the server. In block 1321, the central unit sends the phone number to the server for analysis. If the obtained phone number does not agree with a profile designated as subject to parental control, then the parental control process is completed in block 1322.

Otherwise, if the obtained phone number corresponds to the profile subject to parental control, then in block 1323 the server is run in parental control. In one example, the execution of such blocks 13231327 includes, similar to the VNC approval process, which are discussed in the next paragraph.

In block 1323, · the server transmits a parental control message to the main unit. At block 1324, the main unit continuously tracks conditions based on the parental control message. At block 1325, the main unit blocks a particular application from using the main unit as an extended interface and / or blocks a particular application installed and running on the main unit. For example, the main unit may receive an indication that the home mobile phone has received a phone call, but then it blocks the use of the main unit as an extended interface for the phone call. Or, in another example, the head unit could block an attempt to run a media player application on the head unit. Continuous monitoring can be facilitated by a database on the main unit that stores the received parental control messages.

At block 1326, the main unit conditionally blocks a particular application from using the main unit as an extended interface and / or running or running directly on the main unit. For example, the main unit 'might receive an indication that the particular mobile phone has received a phone call, but then block the use of the main unit as a conditional extended interface based on the value of a caller ID field in the incoming call. More specifically, the parental control message could designate certain telephone numbers as exceptions to the main unit's prevention of providing an extended interface for the telephone. The head unit gets the caller ID value from the cell phone and blocks the cell phone from using a head unit interface conditionally. In another example, the head unit could block a conditional application based on a vehicle status, for example, the head unit blocks the mobile phone from being able to use a head unit interface only if the vehicle is in motion.

In block 1327, the main unit does not block the particular application if the application is allowed according to the parental control message. In this case,

<td> 10</td><td>unit</td><td>main allows</td><td>that</td><td>application operate</td><td>of</td>

<td></td><td>agree with</td><td>approval by</td><td colspan="2">the server for example</td><td>in</td>

<td></td><td>function of</td><td>if the application</td><td>It's in</td><td colspan="2">the controlled list</td>

<td></td><td>(figure 6).</td><td></td><td></td><td></td><td></td>

<td></td><td colspan="2">It should be evident</td><td>what in</td><td>other examples,</td><td>a</td>

<td> 15</td><td colspan="2">system can apply a</td><td>scheme</td><td colspan="2">parental control</td>

using different processes from those specifically described above. For example, in another example, processes in blocks 1323-1327 are not used. Instead, the head unit continually reports application conditions and requests to the server, which dynamically withdraws an ongoing approval according to parental control settings. The server then controls the head unit to block an unapproved ongoing application.

It will be obvious to those skilled in the art that many changes can be made to the details of the embodiments described above without departing from the underlying principles of the invention. The scope of the present invention should therefore be determined only by the following claims.

Most of the equipment discussed above comprises associated hardware and software. For example, the typical navigation device probably includes one or more processors and the executable software on such processors to carry out the described operations. The term software is used in its common sense, which refers to programs or routines (subroutines, objects, plug-ins, etc.), as well as data, which can be used by a machine or a processor. As is known, computer programs generally comprise instructions that are stored on machine-readable or computer-readable storage media. Some embodiments of the present invention may include executable programs or instructions that are stored on machine-readable or computer-readable storage media, such as digital memory. It does not imply that equipment in the conventional sense is required in any particular form of presentation. For example, various processors, embedded or something similar, can be used in equipment such as the components described in this document.

The memory for storing software again is known. In some embodiments, the memory associated with a given processor may be stored in the same physical device such as the processor (on-board memory), for example, RAM or FLASH memory placed within an integrated circuit microprocessor or something similar. In other examples, the memory comprises a separate device, such as an external disk drive, a storage array, portable FLASH. In such cases, the memory becomes associated with the digital processor when the two are operatively coupled to each other, or in communication with each other, for example by means of an I / O port, network connection, etc., in such a way that the processor can read a file stored in memory. The associated memory may be read-only by design (ROM) or by virtue of permission settings, or it may not be. Other examples include but are not limited to WORM, EPROM, EEPROM, FLASH, etc. Those technologies are often applied in semiconductor solid state devices. Other memories may comprise moving parts, such as a conventional rotating disk unit. All of these memories are machine readable or computer readable and can be used to store executable instructions to implement the functions described in this document.

A software product refers to a memory device in which a series of executable instructions are stored in a machine-readable form, so that a suitable machine or processor, with proper access to the software product, can execute the instructions. to carry out a process executed by the instructions. Software products are sometimes used

<td>to distribute the</td><td>software.</td><td>Any</td><td>type</td><td>memory</td>

<td>machine readable,</td><td>including</td><td colspan="2">without limitation</td><td>the ones that</td>

<td>summary above,</td><td>They may be</td><td>used</td><td colspan="2">to do a</td>

<td>software product</td><td colspan="2">That said, too</td><td>I know</td><td>knows that the</td>

<td>software can be</td><td>distributed</td><td>through</td><td>of</td><td>transmission</td>

electronic (download), in which case it will not typically be a corresponding software product at the transmitting end of the transmission, or the receiving end, or both.

Having described and illustrated the principles of the invention in a preferred embodiment thereof, it will be apparent that the invention can be modified in arrangement and detail without departing from such principles. All modifications and variations that fall within the essence and scope of the following claims are claimed.