Patent Description:
<CIT> discloses a program stored in a computer-readable medium causes a computer to execute a process includes receiving, from an automobile in which a control program for controlling devices mounted on the automobile operates, an update request concerning the control program, classifying a plurality of correction programs corresponding to the update request into a plurality of groups on the basis of usable electric energy of a battery corresponding to a vehicle type to which the automobile belongs, an amount of the usable electric energy being stored in a memory, and transmitting the classified correction programs to the automobile for each of the groups.

<CIT> discloses that software for embedded vehicle computers in a motor vehicle is updated using a smart phone having Bluetooth connectivity or USB connectivity. An application program or "app" running the phone queries a server via the Internet, for any available software updates for a vehicle. The vehicle is identified to the server by the app using the vehicle identification number (VIN). When an update for an embedded computer is available, the server transfers the update as one or more files, which are transmitted to the phone via a cell phone network and stored in the phone until the phone can be linked to the vehicle. After the phone and vehicle are linked the update is transferred to the vehicle, preferably using Bluetooth. Software on the vehicle copies the new software into an appropriate memory device via a bus running through-out the vehicle.

Following below are more detailed descriptions of various concepts related to, and implementations of, methods, apparatuses, and systems for updating functionality of vehicular computing devices. The various concepts introduced above and discussed in greater detail below may be implemented in any of numerous ways.

The present disclosure is generally directed to solutions for updating functionality of vehicular computing devices. The solutions described address technical problems specific to updating functionality of vehicular computing devices, and may be applied to similar problems in other contexts as well. For example, a problem encountered with updating functionality of vehicular computing devices is that the vehicular computing devices are mobile and thus not reliably connected to a data network such as the Internet. Some vehicular computing devices may lack any suitable data network connection. By using an intermediary courier device, network connection reliability may be improved. In addition, the courier device may have access to networks that are not directly accessible by the vehicular computing devices. Another problem is that an update to a vehicular computing device may be disruptive to the vehicular computing device, and possibly to the vehicle itself. This disruption may not be acceptable, and it may be beneficial to minimize or eliminate any disruption when updating functionality of vehicular computing devices. The solutions described address this as well.

<FIG> is a block diagram of an illustrative network environment <NUM> and vehicle <NUM>, in accordance with an illustrative implementation. The illustrative network environment <NUM> can include at least one data processing system <NUM>, one or more client devices <NUM>, and one or more vehicles <NUM>.

The data processing system <NUM> can include an interface <NUM>. The data processing system <NUM> can include a natural language processor ("NLP") component <NUM> to parse audio-based inputs. The data processing system <NUM> can include an interface management component <NUM> to detect and manage the interfaces of other devices in the system <NUM>. The data processing system <NUM> can include an audio signal generator component <NUM> to generate audio-based signals. The data processing system <NUM> can include an application programming interface ("API") <NUM>. The data processing system <NUM> can include a response selector component <NUM> to select responses to audio-based input signals. The data processing system <NUM> can include a validation engine <NUM> to validate audio-based inputs received by the data processing system <NUM>. The data processing system <NUM> can include a data repository <NUM> in which the data processing system <NUM> can store parameters <NUM>, policies <NUM>, response data <NUM>, and templates <NUM>. The client device <NUM> and the vehicle <NUM> can include and execute instances of the components of the data processing system <NUM>. The data repository <NUM> can store update packages. The data repository <NUM> can store temporary recovery images. The client device <NUM> and the vehicle <NUM> can each include an instance of the data processing system <NUM>.

The system <NUM> can also include one or more client devices <NUM>. The client devices <NUM> can include sensors <NUM>, speakers <NUM>, interfaces <NUM>, and transducers <NUM>. The client devices <NUM> can execute an instance of the NLP component <NUM>. The system <NUM> can also include one or more data providers <NUM>. The system <NUM> can include one or more vehicles <NUM>. The vehicles <NUM> can include sensors <NUM>, speakers <NUM>, interfaces <NUM>, and transducers <NUM>. The vehicles <NUM> can execute an instance of the NLP component <NUM>. The components of the system <NUM> can communicate over a network <NUM>. In some implementations, one or more of the client devices <NUM> can be located within an instance of the vehicle <NUM>. For example, the client device <NUM> can be the mobile phone of a driver driving the vehicle <NUM>. (<FIG>, described below, illustrates an example in which two client devices <NUM> are present within the vehicle <NUM>, e.g., a driver's and another passenger's. ) One or more of the client devices <NUM> can be remote to the vehicles <NUM>. For example, after the driver parks and exits the vehicle <NUM> for work, the driver's mobile phone may be remote from the vehicle <NUM>.

The network <NUM> can include computer networks such as the Internet, local, wide, metro, or other area networks, intranets, satellite networks, other computer networks such as voice or data mobile phone communication networks, and combinations thereof. The network <NUM> can be used by the data processing system <NUM>, client devices <NUM>, and vehicles <NUM> to access information resources such as web pages, web sites, domain names, uniform resource locators, or data providers <NUM>. For example, the data processing system <NUM> can, via the network <NUM>, access a data provider <NUM> that provides weather data for specific locations, such as a location associated with a vehicle <NUM>. In some instances, a client device <NUM> may have a high bandwidth connection to the network <NUM> in a first context and a lower bandwidth connection to the network <NUM> in another context. For example, at home or at work, a client device <NUM> may be on a high-bandwidth "Wi-Fi" connection, whereas at other locations, the client device <NUM> may use a telephony-based mobile data network with a lower bandwidth. The telephony-based mobile data network may also have higher latency than the home or office "Wi-Fi" connection. The vehicle <NUM> can include a network interface to a network <NUM> independent of the client device <NUM>. The network interface specific to the vehicle <NUM> can have lower bandwidth and higher latency than the client device <NUM>. The network interface specific to the vehicle <NUM> may require an optional service plan that might not be activated and thus might not be available for use.

The network <NUM> can include, for example, a point-to-point network, a broadcast network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an Asynchronous Transfer Mode ("ATM") network, a Synchronous Optical Network ("SONET") network, a Synchronous Digital Hierarchy ("SDH") network, a wireless network or a wireline network, and combinations thereof. The network <NUM> can include a wireless link, such as an infrared channel or satellite band. The topology of the network <NUM> may include a bus, star, or ring network topology. The network <NUM> can include mobile telephone networks using any protocol or protocols used to communicate among mobile devices, including advanced mobile phone protocol ("AMPS"), time division multiple access ("TDMA"), code-division multiple access ("CDMA"), global system for mobile communication ("GSM"), general packet radio services ("GPRS"), or universal mobile telecommunications system ("UMTS"). Different types of data may be transmitted via different protocols, or the same types of data may be transmitted via different protocols.

The client devices <NUM> and the vehicles <NUM> can each include at least one logic device such as a computing device having a processor to communicate with each other with the data processing system <NUM> via the network <NUM>. The client devices <NUM> and the vehicles <NUM> can include an instance of the any of the components described in relation to the data processing system <NUM>. The client devices <NUM> and the vehicles <NUM> can include an instance of the data processing system <NUM>. The client devices <NUM> can include a desktop computer, laptop, tablet computer, personal digital assistant, smartphone, mobile device, portable computer, thin client computer, virtual server, speaker-based digital assistant, or other computing device. The vehicle <NUM> can be a car, truck, motorcycle, boat, aircraft, or other transportation device. The vehicle <NUM> can include one or more processors that can execute an instance of the data processing system <NUM> or any component thereof. The processors can be a component of the vehicle's head unit <NUM> (shown in <FIG>).

The client device <NUM> and the vehicle <NUM> can include at least one sensor <NUM>, at least one transducer <NUM>, at least one audio driver, and at least one speaker <NUM>. The sensor <NUM> can include a microphone or audio input sensor. The sensor <NUM> can also include at least one of a proximity sensor, an ambient light sensor, a temperature sensor, a motion sensor, an accelerometer, or a gyroscope. The sensor can include an occupancy or weight sensor. The transducer <NUM> can convert the audio input into an electronic signal. The audio driver can include a script or program executed by one or more processors of the client device <NUM> or the vehicle <NUM> to control the speaker <NUM>. The speaker <NUM> can render audio signals by converting electrical signals into audible waves. In some implementations, a sensor <NUM> may include a receiver for a satellite-based location service. Examples of system satellite-based location services (also known as global navigation satellite systems, "GNSS") include the U. Global Positioning System ("GPS"), the Russian Global Navigation Satellite System ("GLONASS"), and the European Union's Galileo system.

The client device <NUM> and the vehicle <NUM> can be associated with an end user that enters voice queries as input audio signal into the client device <NUM> or the vehicle <NUM> (via the sensor <NUM>) and receives audio output in the form of a computer generated voice that can be provided from the data processing system <NUM>. In response to the input audio signals, the client device <NUM> and the vehicle <NUM> can also receive action data structures to perform predetermined functions or actions. The interface <NUM> can receive or provide data messages to the direct action API <NUM> of the data processing system <NUM> and enable communication between the components of the system <NUM>. The client device <NUM> and the vehicle <NUM> can also include a user interface that enables a user to interact with the components of the system <NUM>.

The system's data processing system <NUM> can include at least one server having at least one processor. For example, the data processing system <NUM> can include a plurality of servers located in at least one data center or server farm. The data processing system <NUM> can determine from an audio input signal a request and a trigger keyword associated with the request. Based on the request and trigger keyword, the data processing system <NUM> can generate or select response data. The response data can be audio-based or text-based. For example, the response date can include one or more audio files that when rendered provide an audio output or acoustic wave. The data within the response data can also be referred to as content items. The response data can include other content (e.g., text, video, or image content) in addition to audio content.

The data processing system <NUM> can include multiple, logically grouped servers and facilitate distributed computing techniques. The logical group of servers may be referred to as a data center, server farm or a machine farm. The servers can be geographically dispersed. A data center or machine farm may be administered as a single entity, or the machine farm can include a plurality of machine farms. The servers within each machine farm can be heterogeneous-one or more of the servers or machines can operate according to one or more type of operating system platform. The data processing system <NUM> can include servers in a data center that are stored in one or more high-density rack systems, along with associated storage systems, located for example in an enterprise data center. The data processing system <NUM> with consolidated servers in this way can improve system manageability, data security, the physical security of the system, and system performance by locating servers and high performance storage systems on localized high performance networks. Centralization of all or some of the data processing system <NUM> components, including servers and storage systems, and coupling them with advanced system management tools allows more efficient use of server resources, which saves power and processing requirements and reduces bandwidth usage. Each of the components of the data processing system <NUM> can include at least one processing unit, server, virtual server, circuit, engine, agent, appliance, or other logic device such as programmable logic arrays configured to communicate with the data repository <NUM> and with other computing devices.

The data processing system <NUM> can include the data repository <NUM>. The data repository <NUM> can include one or more local or distributed databases and can include a database management system. The data repository <NUM> can include computer data storage or memory and can store one or more parameters <NUM>, one or more policies <NUM>, response data <NUM>, and templates <NUM>, among other data. The parameters <NUM>, policies <NUM>, and templates <NUM> can include information such as rules about a voice based session between the client device <NUM>, data processing system <NUM>, and vehicle <NUM>. The response data <NUM> can include content items for audio output or associated metadata, as well as input audio messages that can be part of one or more communication sessions with the client device <NUM>.

An application, script, program, digital assistant application or other components that are associated with the data processing system <NUM> can be installed at the client device <NUM> or the vehicle <NUM>. The application can enable the client device <NUM> (e.g. via the interface <NUM>) or vehicle <NUM> to communicate input audio signals (and other data) to the interface <NUM> of the data processing system <NUM>. The application can enable the client device <NUM> and the vehicle <NUM> to drive components of the client device <NUM> and the vehicle <NUM> to render the output audio signals.

The data processing system's NLP component <NUM> can receive input audio signals. The data processing system <NUM> can receive the input audio signal from the client device <NUM> or the vehicle <NUM>. A first device can execute the NLP component <NUM> and the NLP component <NUM> can receive the input audio signal from a second device. For example, the vehicle <NUM> can execute the NLP component <NUM> and the input audio signal can be received from the client device <NUM>.

The NLP component <NUM> can convert input audio signals into recognized text by comparing the input audio signal against a stored, representative set of audio waveforms and choosing the closest matches. The representative waveforms can be generated across a large set of input audio signals. Once the input audio signal is converted into recognized text, the NLP component <NUM> can match the text to words that are associated, for example, via a learning phase, with actions or output audio signals.

From the input audio signal, the NLP component <NUM> can identify at least one request or at least one trigger keyword corresponding to the request. The request can indicate intent or subject matter of the input audio signal. The trigger keyword can indicate a type of action likely to be taken. For example, the NLP component <NUM> can parse the input audio signal to identify at least one request to open the vehicle's windows or skip to a next audio file in a music playlist. The trigger keyword can include at least one word, phrase, root or partial word, or derivative indicating an action to be taken. For example, the trigger keywords "go" or "ok.

The response selector component <NUM> can obtain information from the data repository <NUM>, where it can be stored as part of the response data <NUM>. The response selector component <NUM> can query the data repository <NUM> to select or otherwise identify response phrases or content item, e.g., from the response data <NUM>.

The audio signal generator component <NUM> can generate or otherwise obtain an output signal that includes the content item. The data processing system <NUM> can execute the audio signal generator component <NUM> to generate or create an output signal corresponding to the content item or request. For example, once a request is fulfilled, the signal generator component <NUM> can generate an audio output signal that includes the phrase "The action was completed.

The interface <NUM> can be a data interface or a network interface that enable the components of the system <NUM> to communicate with one another. The interface <NUM> of the data processing system <NUM> can provide or transmit one or more data packets that include the action data structure, audio signals, or other data via the network <NUM> to the client device <NUM> or vehicle <NUM>. For example, the data processing system <NUM> can provide the output signal from the data repository <NUM> or from the audio signal generator <NUM> to the client device <NUM>. The data processing system <NUM> can also instruct, via data packet transmissions, the client device <NUM> or the vehicle <NUM> to perform the functions indicated in the action data structure. The output signal can be obtained, generated, transformed to or transmitted as one or more data packets (or other communications protocol) from the data processing system <NUM> (or other computing device) to the client device <NUM> or the vehicle <NUM>.

The direct action API <NUM> of the data processing system <NUM> can generate, based on, for example, the request, action data structures. The action data structure can include data or instructions for the execution of a specified action to satisfy the request. In some implementations, the action data structure can be a JSON formatted data structure or an XML formatted data structure.

Depending on the action specified in the request, the direct action API <NUM> can execute code or a dialog script that identifies the parameters required to fulfill the request. The action data structures can be generated responsive to the request. The action data structure can be included in messages that are transmitted to or received by the client device <NUM> or the vehicle <NUM>. Based on the request parsed by the NLP component <NUM>, the direct action API <NUM> can determine to which of the client devices <NUM> or the vehicles <NUM> the message should be sent. For example, if an input audio signal includes "open a window," the NLP component <NUM> can identify the action word "open a window. " The direct action API <NUM> can package the request into an action data structure for transmission to a vehicle <NUM>. The direct action API <NUM> can access a vehicle ID from the response data <NUM> to determine which vehicle is associated with the user that generated the request. Once received, the vehicle <NUM> can process the action data structure and open the vehicle's window.

The action data structure can include information for completing the request. For example, the action data structure can be a XML or JSON formatted data structure that includes attributes used in completing or otherwise fulfilling the request. The attributes can include a location of the vehicle <NUM>, a location of the client device <NUM>, an authorization level of a user associated with a client device <NUM>, a vehicle identifier, an interface identifier, a vehicular state, or a request state. The request state can include one or more attributes that should be satisfied before the action is fulfilled. For example, the request "Ok, change the song" the request state may have the attribute {requestor:[authorized, passenger]} indicating that the request should be an explicitly authorized user or a passenger in the vehicle.

The direct action API <NUM> can retrieve a template <NUM> from the repository <NUM> to determine which fields or attributes to include in the action data structure. The direct action API <NUM> can determine necessary parameters and can package the information into an action data structure. The direct action API <NUM> can retrieve content from the repository <NUM> to obtain information for the attributes of the data structure.

The direct action API <NUM> can populate the fields with data from the input audio signal. The direct action API <NUM> can also populate the fields with data from the data provider <NUM>, the client device <NUM>, or the vehicle <NUM>. The direct action API <NUM> can prompt a user for additional information when populating the fields. The templates <NUM> can be standardized for different types of actions, such as playing media files through the vehicle's head unit, responding to messages, and performing functions within the car. The action data structure can initially be generated by a direct action API <NUM> executed by a remote data processing system <NUM>. The remote data processing system <NUM> can transmit the action data structure to the data processing system <NUM> of the vehicle <NUM>, which can add fields and attributes to the action data structure.

The direct action API <NUM> can obtain response data <NUM> (or parameters <NUM> or policies <NUM>) from the data repository <NUM>, as well as data received with end user consent from the client device <NUM> to determine location, time, user accounts, logistical or other information in order to reserve a car from the car share service. The response data <NUM> (or parameters <NUM> or policies <NUM>) can be included in the action data structure. When the content included in the action data structure includes end user data that is used for authentication, the data can be passed through a hashing function before being stored in the data repository <NUM>.

The data processing system <NUM> can include, interface, or otherwise communicate with the validation engine <NUM>. The validation engine <NUM> can validate or otherwise determine if the actions and functions associated with action data structures should be executed or fulfilled. When validated, the validation engine <NUM> can enable the request to be fulfilled. The validation engine <NUM> can determine if the requestor has the authority to have the action fulfilled, whether it is safe to fulfill the action, or whether other functions should be fulfilled in place of the requested function or action.

For example, in response to receiving the input audio signal "Ok, open the trunk," the validation engine <NUM> can determine not to open the trunk because the vehicle <NUM> is driving down a road and opening the trunk would not be safe. In another example, in response to receiving the input audio signal, "Ok, next song," the validation engine <NUM> can determine the user has the authority to change the song and skip to the next song. The validation engine <NUM> can be executed by or a component of the client device <NUM> and the vehicle <NUM>. For example, the vehicle <NUM> may execute a local instance of the validation engine <NUM> when the vehicle <NUM>. The vehicle <NUM> can offload computational work to the remote validation engine <NUM> when the validation engine <NUM> has a connection to the network <NUM> and process the requests with a local instance of the validation engine <NUM> when the vehicle <NUM> does not have a connection to the network <NUM>.

The validation engine <NUM> can validate the actions based on data from external sensors data, such as data received from the data providers <NUM>, sensors <NUM> of the client device <NUM>, and sensors <NUM> the vehicle <NUM>. The validation engine <NUM> can also validate the actions based on the administrative rights of a user that generated the input audio signal. The validation engine <NUM> can validate the actions based on the vehicular state of the vehicle <NUM>.

The validation engine <NUM> can determine a vehicular state of the vehicle <NUM> based on a set of sensor data. The vehicular state can indicate the current state of the vehicle <NUM> where the request is to be fulfilled. The vehicular state can indicate whether the vehicle <NUM> is moving, in park, or idling. The vehicular state can indicate the speed of the vehicle <NUM>. The validation engine <NUM> can use a combination of sensor data to determine the vehicular state. The combination of sensor data can be used to differentiate different states that might have similar conditions. For example, the different states of stopped at a red light, stopped in a parking lot, stopped in traffic, and in park in a parking lot may have some similar conditions (e.g., a vehicle speed of <NUM> mph), but different functions may be authorized in each of the different states. For example, it may be safe to open the trunk when the vehicle <NUM> is in park in a parking lot but not when the vehicle <NUM> is stopped at a red light. The vehicular state can include a plurality of substates, such as a movement state, an external environment state, an internal environment state, and a device state.

The movement sub-state can include attributes such as current and average speed, current and average acceleration, driving mode status, and gear status. The external environment sub-state can include attributes such as external weather conditions (e.g., raining, sunny, or snowing), external temperature, external weather condition forecast, and external temperature forecast. The internal environment sub-state can include attributes such as an internal temperature and an internal zone temperature. The device sub-state can include attributes such as HVAC status (e.g., air conditioning on, air conditioning off, heating on, etc.), window status, lock status, truck status, door ajar status, sunroof status, heated seat status, heated steering wheel status, headlight status, and interior light status.

The validation engine <NUM> can determine the vehicular state based on a set of sensor data that can include sensor data from the client devices' sensors <NUM>, sensor data from the vehicles' sensors <NUM>, data from the data provider <NUM>, or any combination thereof. Some of the attributes within the vehicular state can be determined from a single sensor (e.g., door ajar status) and others can be determined from a combination of sensor signals (e.g., movement status can be determine from a combination of speed data and gear data).

The sensor data from the client device <NUM> can include location data determined by cellular tower triangulation or a GNSS receiver in the client device <NUM>, speed data determined by integrating the location data, acceleration data, account data, authorization data, or any combination thereof. The sensor data can include data from one or more data providers <NUM>. The data providers <NUM> can be internet-based data repositories. The data providers <NUM> can make their data available by, for example, an API. The data providers <NUM> can provide weather data, location data, event data, location review data, forecast data, or any combination thereof to the validation engine <NUM>.

The validation engine <NUM> can determine a request state based on the request parsed from the input audio file. The validation engine <NUM> can determine the request state based on a second set of sensor data. The data of the first and second set of sensor data can be received as an updating data signal, a vector, data array, scalar value, or other format of data. The request state can include a plurality of attributes under which the action of the request can be executed or that are required for the request to be fulfilled. The request state can be a component of or derived from the action data structure. For example, the request "OK, open the trunk," can include a request state with attributes that indicate the trunk can only open when in a parked condition and when the requested by the driver or an authorized passenger. For example, the request state can be {movement state: parked, requestor: authorized passenger}.

The second set of sensor data for determining the request state can include sensor data from the first set of sensor data the validation engine <NUM> used to determine the vehicular state. The second set of data can also include the location of the client device <NUM> (or a user associated therewith) within the vehicle <NUM>.

The validation engine <NUM> can compare the request state to the vehicular state to determine whether the action of the action data structure should be executed, performed, or further processed. For example, the vehicular state may indicate that the vehicle <NUM> is parked in a parking lot, with the windows closed, and with the external conditions of rain (e.g., {movement state:parked, windows:closed, external condition:rain}). For example, where the input audio signal is "OK, open the windows," the validation engine <NUM> may determine that the request state for the request require that the request come from an authorized user, the driving attribute can be driving or parked, and the weather attribute has to be non-rain (e.g., {requestor:authorized, movement state: [driving, parked], external condition: [sunny, overcast, cloudy]}). Comparing the vehicular state to the request state, the validation engine <NUM> can determine that the vehicular state's external condition attribute does not match (or is not an element of) the request state's external condition attribute. Because the states do not match, the validation engine <NUM> can determine the request should not be fulfilled because it is raining outside the vehicle <NUM> and the windows should not be opened when it is raining.

When the validation engine <NUM> determines that the function should not be fulfilled, the validation engine <NUM> can generate a request for confirmation that is presented to the user via the interface <NUM> of the client device <NUM> or vehicle <NUM>. The request for confirmation can ask the user if the user would like to override the validation engine's decision not to fulfill the request. When the validation engine <NUM> determines that the function should not be fulfilled, the validation engine <NUM> can offer to modify the action data structure. Continuing the above example, the validation engine <NUM> can generate an audio-based prompt asking if the user would like to tile the sunroof.

<FIG> is a block diagram of an illustrative top view, and interior cabin, of the vehicle <NUM>. The interior cabin of the vehicle <NUM> can include a plurality of seats, and each of the seats may include one or more sensors <NUM>. The sensors <NUM> can be weight or occupancy sensors. The interior cabin of the vehicle <NUM> can include a plurality of speakers <NUM>. The vehicle <NUM> can also include a head unit <NUM>, which can execute one or more of the components described in relation to the data processing system <NUM> or the vehicle <NUM>. For example, the head unit <NUM> may provide features and functionalities such as navigation, entertainment, vehicle climate control, vehicle operation, personal digital assistant, or speaker-based digital assistant, for example. The speakers <NUM> can generate sub-audible tones <NUM> with user authorization, for example. The sub-audible tones <NUM> can be tones rendered by the speakers <NUM> that are not within the normal frequency range detectable by users. The system can use audible tones in place of the sub-audible tone <NUM>.

The validation engine <NUM> can determine the relative position of a client device <NUM> within the vehicle <NUM>. The position of the client device <NUM> can be incorporated into one or more attributes of the request state or vehicular state. The position or location of the client devices <NUM> be a relative position and can include different levels of resolution. For example, the relative location can be regions related to one of the seats, regions related to different zones (e.g., the client devices <NUM> are in the front zone and no client devices <NUM> are in the back zone). The relative location of the client devices <NUM> within the vehicle <NUM> can be determined using sub-audible tones <NUM>. The relative location of the client devices <NUM> within the vehicle <NUM> can be determined based on sensor data from the sensors <NUM>. The relative location of the client devices <NUM> within the vehicle <NUM> can be determined based on a combination of the sub-audible tones and sensor data from the sensors <NUM>.

The validation engine <NUM> can determine the relative location of a client device <NUM> by determining a time difference between the transmission of a sub-audible tone <NUM> and the receipt of the sub-audible tone <NUM> by a client device <NUM>. For example, the head unit <NUM> can cause one of the speakers <NUM> to generate a sub-audible tone <NUM>. The speaker <NUM> can generate the sub-audible tone <NUM> at a first time. A client device <NUM> that is relatively closer to the speaker <NUM> that generated the sub-audible tone <NUM> will receive the sub-audible tone <NUM> before a client device <NUM> that is relatively farther from the speaker <NUM> that generated the sub-audible tone <NUM>. Once a client device <NUM> receives or otherwise detects the sub-audible tone <NUM>, the client device <NUM> can generate a receipt notification that the client device <NUM> transmits to the head unit <NUM> or the data processing system <NUM>. The receipt notification can indicate a second time at which the speaker <NUM> received the sub-audible tone <NUM>. The receipt notification can be transmitted to the data processing system <NUM> via a cellular network, Wi-Fi network local to the vehicle <NUM>, or via a short-range radio communication protocol such as BLUETOOTH. The validation engine <NUM> can determine the length of time between the generation of the sub-audible tone <NUM> and when the client device <NUM> received the sub-audible tone <NUM> (e.g., the time difference between the first and second times in the above example). Different speakers <NUM> can generate different sub-audible tones <NUM> at different times to enable the data processing system <NUM> to triangulate the location of the client device <NUM> within the vehicle <NUM>.

The validation engine <NUM> can determine the location of the client devices <NUM> based on data from the sensors <NUM>. The sensors <NUM> can be weight sensors that can determine if a seat <NUM> is occupied. For example, the validation engine <NUM> can determine the seat <NUM> is occupied when the sensor <NUM> registers a weight above a predetermined threshold. The validation engine <NUM> can determine, using the sub-audible tone <NUM> that a client device <NUM> is near one of the seats <NUM>. The validation engine <NUM> can confirm that a user is associated with the client device <NUM> based on receiving sensor data that the sensor <NUM> of the determined seat <NUM> is detecting weight. The sensor data can be used to prevent a user form accessing functions that are only available to certain zones or users. For example, text messaging may be disabled on the client device <NUM> associated with the driver but enabled for the client devices <NUM> associated with passengers in the other seats <NUM> of the vehicle <NUM>. If a driver were to lean over and move his client device <NUM> into the area of the passenger seat <NUM>, based on the sub-audible tones <NUM>, the validation engine <NUM> may determine that the client device <NUM> is associated with the passenger seat <NUM> and should be allowed to generate requests to use the text messaging program. The validation engine <NUM> can receive weight data of <NUM> lbs. from the sensor <NUM> in the passenger seat <NUM> and determine that a user is not actually in the passenger seat <NUM> and may prevent the driver's client device <NUM> from accessing the text message functionality. The validation engine <NUM> may update the relative locations of the client devices <NUM> in the vehicle <NUM> only after detecting the opening and closing of a door of the vehicle <NUM>.

<FIG> is a block diagram of illustrating separation between the vehicle <NUM> and an update package source, e.g., an update server <NUM>. A client device <NUM> may serve as a courier, receiving an update package from the update server <NUM> via the network <NUM> at a network access point <NUM> and subsequently transfer the received update package to a vehicular computing device <NUM> at the vehicle <NUM> via a vehicle access point <NUM>.

The vehicular computing device <NUM> is a computing device on board the vehicle <NUM>. The vehicular computing device <NUM> may be installed in the vehicle <NUM>, attached to the vehicle <NUM>, or otherwise present in the vehicle <NUM>. In some implementations, the vehicular computing device <NUM> is the head unit <NUM> shown in <FIG> and described above. In some implementations, the vehicular computing device <NUM> manages one or more functions for the vehicle <NUM>. For example, the vehicular computing device <NUM> may manage features in the vehicle such as automated door locks, automated windows and sunroofs, windshield wipers, alarm systems, entertainment systems, voice-interaction systems, vehicle performance, vehicle diagnostics, and so forth. Updates to the functionality of the vehicular computing device <NUM> may be sourced from an update server <NUM> that is remote from the vehicular computing device <NUM>. In some implementations, the vehicular computing device <NUM> is connected to the update server <NUM> via a network <NUM>. In some implementations, the vehicular computing device <NUM> is not connected to the update server <NUM>. For example, the vehicular computing device <NUM> may lack adequate network connectivity for an update (or may have no network connectivity at all).

The update server <NUM> may be one or more servers (e.g., one or more servers in a server farm or data center) configured to provide update packages. The update server <NUM> can be implemented using a computer system <NUM>, e.g., as described below in reference to <FIG>. The update server <NUM> can store, or has access to a data storage system storing, one or more update packages for vehicular computing systems. An update package may include data for updating core functionality such as a device driver, operating system kernel-level code, or support features for installed software. An update package may include data for updating add-on features such as features provided by installed software. An update package may include new software (or "apps") for installation. As an example, an update package may include data for updating functionality of a head unit <NUM>. An update package may include multiple update portions, e.g., a first portion for updating core functionality and a second portion for updating one or more third-party applications. An update package may include verification aides such as checksums, hash signatures, encrypted signatures, or estimated install time, for example. An update package can include installation timing criteria for regulating when an update may be installed. For example, an update may be incompatible with installation while the vehicle <NUM> is in motion (e.g., the update might alter how the vehicle <NUM> operates). Update packages are described in more detail below.

The network access point <NUM> is a connection to the network <NUM>. The network access point <NUM> may be situated in a residence, a hotel, a work place, a coffee shop, or anywhere else that may provide access to the network <NUM>. The network access point <NUM> can include a wireless access point, such as a Wi-Fi hotspot. The network access point <NUM> can include a hub, switch, router, or other network device providing a link to the network <NUM>. The client device <NUM> can be physically connected to the network access point <NUM>, e.g., using a universal serial bus ("USB") cable or an Ethernet cable. The client device <NUM> can be connected wirelessly to the network access point <NUM>, e.g., using an IEEE <NUM> protocol over radio transmission. The client device <NUM> can use a short-range radio protocol such as near-field communications ("NFC") or BLUETOOTH to establish a communication link to the network access point <NUM>. The client device <NUM> can use the short-range radio protocol for data communications to the network access point <NUM>. The client device <NUM> can use the short-range radio protocol to initiate or configure a higher bandwidth connection using a second protocol, and can use the second protocol for data communications to the network access point <NUM>. The client device <NUM> can detect the network access point <NUM>; for example, the network access point <NUM> may periodically emit a beacon frame containing a service set identifier ("SSID"), and the client device <NUM> may receive the beacon frame and detect availability of the network access point <NUM> for access to the network <NUM>.

The client device <NUM> can be configured to request an update package, e.g., responsive to one or more trigger conditions. For example, a trigger condition may be that the client device <NUM> detects the access point <NUM>, the client device <NUM> is in communication with the network access point <NUM>, the client device <NUM> is in a physical location near (or proximate to) the network access point <NUM>, that a threshold length of time has elapsed since a previous update request, for example. The client device <NUM> can periodically send a request to an update server <NUM> to check for updates. The update request can identify one or more components that the client device <NUM> is able to update. The client device <NUM> can maintain a catalog of devices (such as a vehicular computing device <NUM>, e.g., the head unit <NUM>, in the vehicle <NUM>) that the client device <NUM> routinely or occasionally communicates with and could transfer an update package to. The client device <NUM> may request an update package for one or more of the devices in the catalog. The client device <NUM> can request an update package for specific software components installed on a device, or to be installed on a device. For example, a vehicular computing device <NUM> may include a navigation application and an audio entertainment application and the client device <NUM> may request updates for the audio entertainment application more frequently (e.g., daily) than for the navigation application (e.g., monthly). The update request can include a generalized request for any available updates and the update server <NUM> selects the updates to be delivered in the update package. For example, the update server <NUM> may obtain location data for the vehicle <NUM> and select only location-relevant updates (e.g., only maps for a geographic region encompassing the vehicle location, only points of interest data for destinations within a threshold distance of the vehicle location, only updates in languages commonly used in the vehicle location, etc.) In some examples, a vehicle dealership may request location-specific updates prior to selling a vehicle; the vehicle dealership may request regionally relevant updates, promotional updates, dealer-specific updates, etc. A manufacturer (or original equipment manufacturer, "OEM") can customize update packages for installation at the vehicle dealership, such that applications, firmware, etc., may be updated at a sales destination and thus closer to a point and time of sale. A purchaser may select from a menu of OEM offerings and the vehicle dealership may configure an update package in accordance with the purchaser selections.

The request for an update can include a request for installation of a new functionality, e.g., installation of a new application. The request for an update can include a request for an upgrade to an installed functionality, e.g., an upgrade to an installed application. The request for an update can include a request for an update to data used by an installed application, e.g., new maps for a navigation system or new media content for an entertainment system.

The vehicle access point <NUM> is a connection to a vehicular computing device <NUM>, e.g., the head unit <NUM>, in the vehicle <NUM>. The vehicle access point <NUM> is able to communicate with the client device <NUM> to facilitate data communication between the client device <NUM> and the vehicular computing device <NUM>. The vehicle access point <NUM> can include a wireless access point, such as a Wi-Fi hotspot. The network access point <NUM> can include a hub, switch, router, or other network device providing a link to the network <NUM>. The client device <NUM> can be physically connected to the network access point <NUM>, e.g., using a universal serial bus ("USB") cable or an Ethernet cable. The client device <NUM> can be connected wirelessly to the network access point <NUM>, e.g., using an IEEE <NUM> protocol over radio transmission. The client device <NUM> can use a short-range radio protocol such as near-field communications ("NFC") or BLUETOOTH to establish a communication link to the vehicle access point <NUM>. The client device <NUM> can use the short-range radio protocol for data communications to the vehicle access point <NUM>. The client device <NUM> can detect the vehicle access point <NUM>; for example, the vehicle access point <NUM> may periodically emit a beacon frame containing a service set identifier ("SSID"), and the client device <NUM> may receive the beacon frame and detect availability of the vehicle access point <NUM> for access to the vehicular computing device <NUM> in the vehicle <NUM>. The client device <NUM> uses the short-range radio protocol to initiate or configure a higher bandwidth connection using a second protocol, and uses the second protocol for data communications to the vehicle access point <NUM>. The client device <NUM> can detect the vehicle access point <NUM>; for example, the vehicle access point <NUM> may periodically emit a discovery signal alerting the client device <NUM> to its availability to connect (or vice versa, such that the client device <NUM> emits a discovery signal alerting the vehicle access point <NUM> to its availability to connect).

The client device <NUM> may be moved between locations with network access points <NUM> and a vehicle <NUM> with a vehicle access point <NUM>. For example, an owner, driver, passenger, or other person with access to the vehicle <NUM> may carry the client device <NUM> into the vehicle <NUM>. That is, the client device <NUM> may be at a first location with the network access point <NUM> (where it can request and obtain an update package) and then later be at a second location (i.e., in the vehicle <NUM>) with the vehicle access point <NUM> (where it can transfer the update package to the vehicle computing device <NUM>). The transfers can be transparent to a person operating the client device <NUM>. The client device <NUM> can passively request the update package without interaction with the person operating the client device <NUM>. For example, the client device <NUM> can passively transfer the update package to the vehicle computing device <NUM> without interaction with the person operating the client device <NUM>. The client device <NUM> can also actively engage with the person operating the client device <NUM>, e.g., providing notifications or alerts of update progress, or requesting explicit permission to proceed with a data transfer.

The client device <NUM> can be simultaneously connected to both the network access point <NUM> and the vehicle access point <NUM>. In such circumstances, the client device <NUM> may transfer data from the update server <NUM> to the vehicle computing system <NUM> without storing data locally, or with only minimal local storage (e.g., buffering).

<FIG> is a ladder diagram of a data exchange <NUM> for installing an update package. In brief overview, a client device <NUM> detects (arrow <NUM>) a network connection to the network access point <NUM> and uses the network access point <NUM> to transmit (arrow <NUM>) an update request to an update server <NUM>. The update server <NUM> responds (arrow <NUM>) by transmitting an update package to the client device <NUM>, which receives the update package from the update server <NUM> via the network access point <NUM>. The client device <NUM> stores (arrow <NUM>) the update package in local memory, for later use in updating functionality of the vehicle computing device <NUM>. The client device <NUM> can perform one or more validations to verify the authenticity, validity, and integrity of the update package. At a later time, when the client device <NUM> has been moved into communication range of the vehicle computing device, the client device <NUM> detects (arrow <NUM>) a connection to the vehicle access point <NUM> and transfers (arrow <NUM>) the stored update package to the vehicle computing device <NUM> via the vehicle access point <NUM>. The vehicle computing device <NUM> stores (arrow <NUM>) the update package in local memory and uses it to update functionality of the vehicle computing device <NUM>. The vehicle computing device <NUM> may, in some implementations, perform one or more validations to verify the authenticity, validity, and integrity of the update package. The vehicle computing device <NUM> can perform one or more validations to verify the success or failure of the update installation, and can roll-back a failed installation to revert the vehicle computing device <NUM> to a state prior to the installation. For example, the vehicle computing device <NUM> may capture a recovery image prior to installing the update and revert or roll-back to the recovery image in the event of a failed update installation.

<FIG> is a flowchart of an example method <NUM> for transferring an update package. In broad overview, at act <NUM>, the client device <NUM> detects a first connection to a communication network and, at act <NUM>, transmits an update request to an update server via the communication network. At act <NUM>, the client device <NUM> receives an update package responsive to the request. At act <NUM>, the client device <NUM> can validate the received update package. At act <NUM>, the client device <NUM> stores the update package in local memory. Portions of the update package may be stored as the update package is received; the order of these acts is not limiting. After the client device <NUM> has been moved into a vehicle <NUM>, the client device <NUM> transfers the stored update image to the vehicular computing device <NUM>. In particular, at act <NUM>, the client device <NUM> detects a second connection, this time to the vehicular computing device <NUM> (or to the vehicular access point <NUM> for communication with the vehicular computing device <NUM>) and at act <NUM>, the client device <NUM> transmits the stored update package to the vehicular computing device <NUM>.

At act <NUM>, the client device <NUM> detects a first connection to a communication network. For example, the client device <NUM> may detect a connection to a network access point <NUM>, as described above. The client device <NUM> can measure network connectivity to an update server <NUM>. For example, the client device <NUM> may send a packet (e.g., a UDP "ping") to the update server <NUM> and measure a length of time until it receives a response. If the update server <NUM> responds within a threshold length of time, the client device <NUM> has detected a connection to the update server <NUM> via a communication network. The client device <NUM> can determine that the communication network is suitable for use (or not). For example, the client device <NUM> may be configured to avoid downloading update packages over mobile telephony networks to avoid data usage fees.

At act <NUM>, transmits an update request to an update server via the communication network. The update request can specify the vehicular computing system <NUM> to be updated. The update request can specify functionalities of the vehicular computing system <NUM> to be updated. For example, in some implementations, the client device <NUM> run an application that manages updates for the vehicular computing device <NUM> and determines what needs to be updated. The client device <NUM> can manage updates for multiple vehicular computing devices <NUM>.

At act <NUM>, the client device <NUM> receives an update package responsive to the request. The client device <NUM> can receive the update package as a single data file. The client device <NUM> can receive the update package as a set of data files. The data files may include update data for one or more functionalities of the vehicular computing device <NUM>. For example, the received update package may include map data for a navigation system, media content for an entertainment system, or modifications to vehicle utilities, for example. The received update package may include metadata describing how and when to install the updates. For example, the update package may include parameters indicating that particular updates can be applied at any time, only when a utility is not in use, only when the vehicle is parked, only when the vehicle is in a garage, and so forth. The received update package may include verification aides such as checksums, hash signatures, encrypted signatures, or estimated install time, for example. For example, the update server <NUM> may prepare a dataset for the update package responsive to an update request (e.g., the request transmitted in act <NUM>) and create a hash of the dataset for inclusion in the update package. The update server <NUM> may include a cryptographic signature in the update package. For example, the update server <NUM> may include, in the update package, a copy of the hash of the dataset encrypted using a private asymmetrical encryption key for use as the cryptographic signature (this may then be verified using a corresponding public key, known to be authentic based on a third-party certificate or other chain of trust).

In some instances, transmission of the update package from the update server <NUM> to the client device <NUM> can be interrupted. The client device <NUM> can attempt to recover from the interruption by sending additional requests to the update server <NUM> and appending data to the received update package.

At act <NUM>, the client device <NUM> can validate the received update package to verify the authenticity, validity, and integrity of the update package. An update package is authentic if it comes from an authentic source (i.e., if the update server <NUM> is authentic and the update package comes from the update server <NUM>, then it too is authentic). An update package is valid if the update instructions contained in the update package are valid instructions. An update package has integrity if the transmission is complete and error free (i.e., if the update package sent by the update server <NUM> is identical to the update package received by the client device <NUM>). For example, a checksum, file size, or hash may be used to confirm integrity. In some implementations, validation includes extracting a verification aide from the update package and using it to validate the update package. For example, the verification aide may be a hash of a dataset included in the update package; the client device <NUM> calculates a hash of the dataset and compares the calculated hash to the included hash to confirm that they match. The included hash can be cryptographically signed and the client device <NUM> uses a security certificate associated with a valid source of the update package to authenticate it. The update package is authentic if the signature is valid and has integrity if the hashes match. The client device <NUM> can analyse contents of the update package to confirm that the update is valid. For example, if the update package includes conflicting updates, the package may be invalid.

At act <NUM>, the client device <NUM> stores the update package in local memory. The client device <NUM> can compress the update package. The update package can also be already compressed, e.g., by the update server <NUM>. The client device <NUM> can decompresses the update package and store it in one or more files. For example, the update package may include updates for multiple systems and the client device <NUM> may store the updates as independent files. These files may, in turn, be update packages. The client device <NUM> can maintain enough free space to store the update package. The update server <NUM> can notify the client device <NUM> of the size of the update package and the client device <NUM> only proceeds with receiving the update package if enough space is available.

At act <NUM>, the client device <NUM> detects a second connection, this time to the vehicular computing device <NUM> (or to the vehicular access point <NUM> for communication with the vehicular computing device <NUM>). The second connection can use a short-range radio communication protocol such as BLUETOOTH or NFC. The client device <NUM> can be physically connected to the vehicular access point <NUM>, e.g., using a wired link.

At act <NUM>, the client device <NUM> can transmit the stored update package to the vehicular computing device <NUM>. The client device <NUM> can download the update package to the vehicular computing device <NUM> slowly, over multiple connections. For example, if the connection to the vehicular computing device <NUM> is a low-bandwidth connection (e.g., BLUETOOTH), the transfer may take a significant length of time, which may be subject to interruptions.

<FIG> is a flowchart of an example method <NUM> for installing an update package. In broad overview, at act <NUM>, the vehicular computing device <NUM> receives the update package from the client device <NUM>, e.g., as described above in reference to <FIG>. At act <NUM>, the vehicular computing device <NUM> can validate the received update package. At act <NUM>, the vehicular computing device <NUM> schedules installation of the update package for when installation is compatible with vehicle operation state. At act <NUM>, the vehicular computing device <NUM> determines whether the vehicle <NUM> (or the vehicle computing device <NUM>) is in a state that is compatible with installation. If in a compatible operation state at act <NUM>, then at act <NUM> the vehicular computing device <NUM> creates a recovery image. At act560, the vehicular computing device <NUM> installs the update package. At act <NUM>, the vehicular computing device <NUM> determines whether the installation was successful. If installation was successful, then at act <NUM> the vehicular computing device <NUM> commits the installation. If installation was not successful, then at act <NUM> the vehicular computing device <NUM> rolls the installation back to the recovery image from act <NUM>. This particular recovery strategy is provided as an example. In some implementations, alternative recovery strategies are used. For example, in some implementations, vehicular computing device <NUM> may maintain a modification log as installation steps are performed. The vehicle computing device <NUM> may, in some implementations, maintain data suitable for rolling-back to revert memory to a pre-update state.

At act <NUM>, the vehicular computing device <NUM> receives the update package from the client device <NUM>. For example, the client device <NUM> may transfer the update package to the vehicular computing device <NUM> using the method <NUM> described above in reference to <FIG>.

At act <NUM>, the vehicular computing device <NUM> can validate the received update package. The vehicular computing device <NUM> may validate the received update package to verify the authenticity, validity, and integrity of the update package. An update package can be authentic if it comes from an authentic source (i.e., if the update server <NUM> is authentic and the update package comes from the update server <NUM>, then it too is authentic). An update package can be valid if the update instructions contained in the update package are valid instructions. An update package has integrity if the transmission is complete and error free (i.e., if the update package sent by the update server <NUM> is identical to the update package received by the vehicular computing device <NUM>). For example, a checksum, file size, or hash may be used to confirm integrity. In some implementations, validation includes extracting a verification aide from the update package and using it to validate the update package. For example, the verification aide may be a hash of a dataset included in the update package; the vehicular computing device <NUM> calculates a hash of the dataset and compares the calculated hash to the included hash to confirm that they match. The included hash can be cryptographically signed and the vehicular computing device <NUM> uses a security certificate associated with a valid source of the update package to authenticate it. The update package is authentic if the signature is valid and has integrity if the hashes match. The vehicular computing device <NUM> can analyse contents of the update package to confirm that the update is valid. For example, if the update package includes conflicting updates, the package may be invalid. The client device <NUM> can validate the update package prior to transmitting it to the vehicular computing device <NUM>, and the vehicular computing device <NUM> relies on evidence provided by the client device <NUM> of the validity.

At act <NUM>, the vehicular computing device <NUM> schedules installation of the update package for when installation is compatible with vehicle operation state. The update package may indicate parameters or restrictions for when and how updates in the update package are installed. For example, an update to a navigation system may include a parameter requiring that the vehicle <NUM> be parked, or at least not be in motion, while the update is applied. The vehicular computing device <NUM> can schedule the installation by setting event interrupts triggered by installation requirements. For example, if an installation requires that the vehicle be parked, an interrupt may be triggered when the vehicular computing device <NUM> determines that the vehicle is parked and the interrupt can then be used to cause installation of updates. The vehicular computing device <NUM> can schedule installation for a time of day. For example, the installation may be scheduled for <NUM> AM, or another time when the vehicle <NUM> is most likely unused. The vehicular computing device <NUM> may schedule different updates from a single update package, each update scheduled independently. An update can be classified with a severity level, e.g., updates addressing the safety of the vehicle <NUM> may be more severe (more important) than updates to an entertainment function. The vehicular computing device <NUM> can prioritize installation of the more severe updates. Some updates may include installation restrictions, such as a restriction that a particular update not be installed while the vehicle <NUM> is being driven.

At act <NUM>, the vehicular computing device <NUM> determines whether the vehicle <NUM> (or the vehicle computing device <NUM>) is in a state that is compatible with installation. For example, the vehicular computing device <NUM> may determine whether the vehicle <NUM> has been parked. Different types of vehicles may have different characteristics that would logically be described as parked. The vehicular computing device <NUM> can detect one or more of these characteristics and determines whether the vehicle <NUM> is parked based on an analysis thereof. Some example characteristics, described in more detail below, include whether the vehicle <NUM> is in a mechanical or computerized state indicating that it is parked, whether the vehicle <NUM> is in motion, and whether the vehicle <NUM> is at a "home" location known to be a frequently used parking location. Additional or alternative characteristics may be used. The vehicular computing device <NUM> can assign each characteristic a confidence score representing measurements for the respective characteristic and a correspond weight for whether the measurement indicates that the vehicle is park. The vehicular computing device <NUM> can then use an aggregation of the confidence scores to determine a likelihood that the vehicle <NUM> is parked.

One example characteristic that may be used for determining whether a vehicle is parked is whether the vehicle <NUM> is in a mechanical or computerized state indicating that it is parked. For example, common personal automobiles with an internal combustion engine use a gearing system and a transmission for shifting gears. The transmission may be automatic or manual. An automatic transmission may have a "park" setting on the automatic transmission; shifting such a vehicle into "park" may indicate that the vehicle is parked, which may be further indicate by application of a parking brake. One or more sensors <NUM>, e.g., a transmission sensor, may detect that the transmission is in park or that a parking brake has been applied. On the other hand, a manual transmission does not have a "park" setting. Such a vehicle might be considered parked if the vehicle is in gear (the clutch is not engaged) and (in some instances) the parking brake is applied. Some electric engine automobiles do not have a gearing system and thus don't have a transmission. Some such electric engine automobiles have a driver interface for "shifting" the vehicle into neutral or park; however, the act of shifting modifies a computer control setting for the electric engine, and is not a transmission action. Even so, the vehicle has a detectable state of "parked" when the computer control setting designates that the vehicle is parked. Further, the electric vehicle may have a parking brake, where application of the parking brake may be detectable evidence that the vehicle is parked. The vehicle <NUM> can include a sensor <NUM> for sensing a status of the transmission, where the transmission status sensor can indicate a transmission state of parked. The transmission status sensor is a virtual sensor for a virtual transmission, e.g., on a vehicle that does not have a physical transmission (such as an electric automobile).

Another example characteristic that may be used for determining whether a vehicle is parked is whether the vehicle <NUM> is at a "home" location known to be a frequently used parking location. For example, the vehicle <NUM> may have a sensor <NUM> for using satellite signals to determine location. Examples of system satellite-based location services (also known as global navigation satellite systems, "GNSS") include the U. Global Positioning System ("GPS"), the Russian Global Navigation Satellite System ("GLONASS"), and the European Union's Galileo system. If the determined location is a "home" parking location, the vehicle may be parked. The vehicular computing device <NUM> may be in communication with a beacon or network access point associated with a "home" location and the vehicular computing device <NUM> may use this communication as evidence that the vehicle is in the associated "home" location. The "home" parking location is programmatically configured, e.g., by a vehicle operator or owner. The "home" parking location can be learned, e.g., using a machine learning algorithm. The "home" parking location may be an owner or operator's residence, place of business, or any other location the vehicle <NUM> is regularly or routinely parked. A vehicle <NUM> may have multiple "home" parking locations.

Another example characteristic that may be used for determining whether a vehicle is parked is whether the vehicle <NUM> is in motion. The vehicle <NUM> may include one or more sensor <NUM> for detecting motion. For example, a sensor <NUM> may be in communication with an odometer for the vehicle, and may determine whether the odometer is measuring an increase in distance traveled over a small increment of time (e.g., a second or a fraction of a second). The vehicle <NUM> has a sensor <NUM> for using satellite signals to determine location and the vehicular computing device <NUM> uses a rate of change in location to determine to whether the vehicle is in motion. Some satellite-based location systems have accuracy to within a few meters, which may be inadequate for detecting small movements but may be sufficiently accurate for detecting larger movements. That is, the satellite-based location system may be a useful failsafe to confirm other measurements. The vehicle <NUM> can include a motion sensor such as an accelerometer. The client device <NUM> can include a motion sensor such as an accelerometer, and the vehicle <NUM> may be in communication with the client device <NUM> such that it can use the motion sensor of the client device <NUM> to determine that the vehicle <NUM> is not in motion. The motion sensor can be connected to a drivetrain for the vehicle <NUM> and can detect whether the vehicle <NUM> is sending power to the wheels of the vehicle <NUM>. The vehicle <NUM> can include on-board diagnostics ("OBD") or on-board diagnostics type <NUM> ("OBD-II") port for connection to maintenance equipment (e.g., in an auto-shop). For example, a dongle may be connected to the OBD or OBD-II port, and the dongle may report motion data from the vehicle <NUM> to either or both of the vehicular computing device <NUM> and the client device <NUM>.

At act <NUM> the vehicular computing device <NUM> creates a recovery image. The vehicular computing device <NUM> can save a copy of software or firmware to be updated such that, in the event of an installation failure, the copy can be used to undo the installation. The vehicular computing device <NUM> can maintain a mirror copy of modifiable data, such that an installation to one copy is only applied to the other copy on a commit; that is, the mirror is a recovery image.

At act <NUM>, the vehicular computing device <NUM> installs the update package. In some implementations, the update package includes a set of update instructions for installing or modifying functionality provided by the vehicular computing device <NUM>. The update package may include blocks of binary data to be written to particular memory locations. The update package may include instruction for a sequence of installation steps. The update package may include data files to be copied to specific data management locations. The update package may include compressed data and instructions to decompress the compressed data. The update package may include instructions for updates to multiple applications, such that each update may be applied independently.

At act <NUM>, the vehicular computing device <NUM> determines whether the installation was successful. An update package can include a test sequence for verifying a successful installation. For example, an application may have been successfully installed if the application can be started. The update package can include one or more diagnostics for verifying a successful installation. The vehicular computing device <NUM> can include a self-diagnostic routine for confirming that the vehicular computing device <NUM> is in a proper operating state.

At act <NUM>, if installation was successful, the vehicular computing device <NUM> commits the installation. The vehicular computing device <NUM> can delete the recovery image. The vehicular computing device <NUM> can copy a primary dataset over a mirror image of the dataset. The vehicular computing device <NUM> can set a flag indicating a successful installation. The vehicular computing device <NUM> can update a catalog of installed version numbers.

At act <NUM>, if installation was not successful, the vehicular computing device <NUM> rolls the installation back to the recovery image from act <NUM>. For example, the vehicular computing device <NUM> may overwrite the installed instructions using a recovery image. The vehicular computing device <NUM> can generate an error message to be propagated back to the update server <NUM> (e.g., via the client device <NUM>) in the event of a failed installation.

<FIG> is a block diagram illustrating a general architecture for a computer system <NUM> that may be employed to implement elements of the systems and methods described and illustrated herein. The computer system or computing device <NUM> can include or be used to implement the system <NUM> or its components such as the data processing system <NUM>. The computing system <NUM> includes a bus <NUM> or other communication component for communicating information and a processor <NUM> or processing circuit coupled to the bus <NUM> for processing information. The computing system <NUM> can also include one or more processors <NUM> or processing circuits coupled to the bus for processing information. The computing system <NUM> also includes main memory <NUM>, such as a random access memory ("RAM") or other dynamic storage device, coupled to the bus <NUM> for storing information, and instructions to be executed by the processor <NUM>. The main memory <NUM> can be or include the data repository <NUM>. The main memory <NUM> can also be used for storing position information, temporary variables, or other intermediate information during execution of instructions by the processor <NUM>. The computing system <NUM> may further include a read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information and instructions for the processor <NUM>. A storage device <NUM>, such as a solid state device, magnetic disk or optical disk, can be coupled to the bus <NUM> to persistently store information and instructions. The storage device <NUM> can include or be part of the data repository <NUM>.

The computing system <NUM> may be coupled via the bus <NUM> to a display <NUM>, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device <NUM>, such as a keyboard including alphanumeric and other keys, may be coupled to the bus <NUM> for communicating information and command selections to the processor <NUM>. The input device <NUM> can include a touch screen display <NUM>. The input device <NUM> can also include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor <NUM> and for controlling cursor movement on the display <NUM>. The display <NUM> can be part of the data processing system <NUM>, the client computing device <NUM> or other component of <FIG>, for example.

The described client device <NUM> may act as a courier or intermediary device between the vehicular computing device <NUM> and an update server <NUM>. In some implementations, the client device <NUM> may also have applications installed thereon that interact with the vehicular computing device <NUM>. Updates for such applications may be coordinated so as to update both the elements installed on the client device <NUM> and corresponding elements installed at the vehicular computing device <NUM> in a coordinated manner. In some implementations, the applications installed on the client device <NUM> may independently generate requests for updates. The applications installed on the client device <NUM> can interact with a coordinator application on the client device <NUM>, and the coordinator application may generate a unified update request.

As described, because the client device <NUM> acts as a courier for the transfer of data to the vehicular computing device <NUM>, the vehicular computing device <NUM> does not need a separate data connection (e.g., a mobile telephony data plan) to support the described updates. However, the vehicular computing device <NUM> may have access to a second data connection (e.g., a mobile telephony data plan) and may augment the update using the second data connection. For example, the update package may include update data along with instructions for the vehicular computing device <NUM> to contact the update server <NUM> for installation steps or verification steps, e.g., out-of-band authentication or validation steps.

The client device <NUM> or the vehicular computing device <NUM> can present a user interface enabling an owner, operator, driver, or passenger of the vehicle <NUM> to control an update process. For example, the user interface may allow for scheduling an update, initiating an update, authorizing an update, pausing an update, resuming an update, or terminating an update. In some implementations, the user interface is voice controlled, e.g., via an voice controlled assistant application.

For situations in which the systems discussed herein collect personal information about users, or may make use of personal information, the users may be provided with an opportunity to control whether programs or features that may collect personal information (e.g., information about a user's social network, social actions or activities, a user's preferences, or a user's location), or to control whether or how to receive content from a content server or other data processing system that may be more relevant to the user. In addition, certain data may be anonymized in one or more ways before it is stored or used, so that personally identifiable information is removed when generating parameters. For example, a user's identity may be anonymized so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, postal code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about him or her and used by the content server.

The subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. The subject matter described in this specification can be implemented as one or more computer programs, e.g., one or more circuits of computer program instructions, encoded on one or more computer storage media for execution by, or to control the operation of, data processing apparatuses. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. While a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate components or media (e.g., multiple CDs, disks, or other storage devices).

The terms "data processing system" "computing device" "component" or "data processing apparatus" encompass various apparatuses, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations of the foregoing. The described computing devices, including the client device <NUM>, the data processing system <NUM> components, and the vehicular computing device <NUM> can include or share one or more data processing apparatuses, systems, computing devices, or processors.

A computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program can correspond to a file in a file system. A computer program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs (e.g., components of the data processing system <NUM>) to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatuses can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.

The subject matter described herein can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification, or a combination of one or more such back-end, middleware, or front-end components.

The computing systems described may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network (e.g., the network <NUM>). In some implementations, a server transmits data (e.g., data packets representing a content item) to a client device (e.g., for purposes of presenting data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server (e.g., received by the data processing system <NUM> from the client computing device).

The separation of various system components does not require separation in all implementations, and the described program components can be included in a single hardware or software product. For example, certain components can be a single component, app, or program, or a logic device having one or more processing circuits, or part of one or more servers of the data processing system <NUM>.

Having now described some illustrative implementations, it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts and those elements may be combined in other ways to accomplish the same objectives. Acts, elements and features discussed in connection with one implementation are not intended to be excluded from a similar role in other implementations or implementations.

Any implementation disclosed herein may be combined with any other implementation or embodiment, and references to "an implementation," "some implementations," "one implementation" or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation may be included in at least one implementation or embodiment. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation may be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

References to "or" may be construed as inclusive so that any terms described using "or" may indicate any of a single, more than one, and all of the described terms. For example, a reference to "at least one of 'A' and 'B'" can include only 'A', only 'B', as well as both' A' and 'B'. Such references used in conjunction with "comprising" or other open terminology can include additional items.

Claim 1:
A method to update functionality of a vehicular computing device (<NUM>) of a vehicle (<NUM>), the method comprising:
receiving (<NUM>), by the vehicular computing device and from an intermediate courier device (<NUM>) via a communication network, an update package;
scheduling (<NUM>) installation of the received update package, wherein scheduling installation of the received update package comprises determining one or more installation requirements for when to install the received update package;
determining (<NUM>) whether the one or more installation requirements are satisfied, wherein determining whether the one or more installation requirements are satisfied comprises determining, based on a location sensor (<NUM>), whether the vehicle is located at a parking location at which the vehicle is regularly or routinely parked; and
in response to determining that the one or more installation requirements are satisfied:
creating (<NUM>) a recovery image of current software or firmware of the vehicular computing device;
installing (<NUM>) the received update package by executing a sequence of installation instructions included in the received update package;
determining (<NUM>) whether the installation of the received update package was successful; and
in response to determining that the installation of the received update package was successful:
committing (<NUM>) the installation of the received update package.