System and method for determining optimal times to send OTA software update notifications and perform an OTA software update

Abstract

Systems and methods for performing over-the-air (OTA) software updates in response to an occurrence of a timing event identified using output from a vehicle usage model. In one example, a method sending a download confirmation notification and an installation confirmation notification for an over-the-air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in real-time, the real-time timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model, downloading the OTA software update in response to a download confirmation being accepted, and installing the OTA software update in response to an installation confirmation being accepted.

Description

SYSTEM AND METHOD FOR DETERMINING OPTIMAL TIMES TO SEND OTA SOFTWARE UPDATE NOTIFICATIONS AND PERFORM AN OTA SOFTWARE UPDATEFIELD

[0001] The disclosure relates to systems and methods for performing an over-the-air (OTA) software update based on a trigger identified with artificial intelligence (Al) and machine learning (ML).BACKGROUND

[0002] Performing over-the-air (OTA) software updates that update and modify relevant vehicle systems helps ensure that vehicles are performing optimally. However, existing OTA software update campaigns that are implemented by an original equipment manufacturer (OEM) are in many cases ineffective with regards to timely updates and modifications to vehicle systems. The ineffectiveness of the OTA update campaigns is due in part to drivers or passengers (e.g., a consumers) postponing or canceling the OTA software updates. Often times, drivers and passengers postpone or cancel the OTA software updates in response to receiving the OTA software update notification at inconvenient times. For example, a driver and / or passenger may be more likely to postpone or cancel the OTA software update if the time to finish the OTA software update exceeds the amount of time the driver and / or passenger anticipates being at a particular location.SUMMARY

[0003] The inventors have recognized the previously mentioned issues and have developed systems and methods to at least partially address the above issues. In particular, the inventors have developed a system for executing OTA software updates in a vehicle, comprising: sending a download confirmation notification and an installation confirmation notification for an over-the- air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in real-time, the real-time timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model, downloading the OTA software update in response to a download confirmation being accepted, and installing the OTA software update in response to an installation confirmation being accepted.

[0004] By using output from a vehicle usage model (e g., an artificial intelligence (AI) / a machine learning (ML) model), to identify one or more timing events suitable for displaying an OTA software update notification to a particular driver, the OTA software update is more likely to be accepted by the driver, and the OTA update is more likely to be completed successfully, and in a timely manner. For example, training the vehicle usage model on historical data, such as driver behavior data, vehicle behavior data, fleet behavior data, and the like enables the vehicle usage model to identify one or more timing events suitable for displaying the OTA update notification to the driver and output timing event data that indicates an occurrence of the identified timing event. The timing event data may include one or more vehicle locations, one or more times for each vehicle location, and a location label. In this way, an OTA update system may send a download confirmation notification and an installation confirmation notification to the driver and / or passenger in response to real-time occurrences of the identified timing / locations events.

[0005] The above advantages and other advantages, and features of the present description will be readily apparent from the following Detailed Description when taken alone or in connection with the accompanying drawings.

[0006] It should be understood that the summary above is provided to introduce in simplified form a selection of concepts that are further described in the detailed description. It is not meant to identify key or essential features of the claimed subject matter, the scope of which is defined uniquely by the claims that follow the detailed description. Furthermore, the claimed subject matter is not limited to implementations that solve any disadvantages noted above or in any part of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Some embodiments are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars are shown by way of example and for purposes of illustrative discussion of embodiments described herein. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments described herein may be practiced.

[0008] In the drawings:

[0009] FIG. 1. shows a block diagram of an exemplary embodiment of an over-the-air (OTA) update system configured to send OTA software update requests to a vehicle;

[0010] FIG. 2 shows an example in-vehicle computing system in accordance with one or more embodiments of the present disclosure;

[0011] FIG. 3 schematically shows an example process for generating a driver behavior profile dataset using a vehicle usage model;

[0012] FIG. 4 is a flow chart illustrating a method for performing over-the-air (OTA) software updates based on an occurrence of a real-time timing event;

[0013] FIG. 5 is a flow chart illustrating a method for identifying an occurrence of a real-time timing event;

[0014] FIG. 6 is a flow chart illustrating a method for generating a driver behavior profile dataset with a vehicle usage model;

[0015] FIG. 7 is a flow chart illustrating a method for training a vehicle usage model; and

[0016] FIGS. 8A-8C show pictorial diagrams of a time scale for performing over-the-air (OTA) software updates in accordance with one or more embodiments of the present disclosure.DETAILED DESCRIPTION

[0017] The present disclosure relates to determining when to send notifications requesting download and / or installation of an over-the-air (OTA) software update to a driver based on output from a vehicle usage model, which may be trained with artificial intelligence (Al) and machine learning (ML). The vehicle usage model is trained to identify one or more timing events for a particular driver wherein a timing event includes a vehicle being located at a particular location for a duration of time, the duration of time exceeding that of a duration of time for the OTA software update to finish. A plurality of datasets corresponding to different aspects of vehicle usage may be entered as input to train the vehicle usage model to identify the one or more timing events for that particular driver. The plurality of datasets may include historical data pertaining to driver behavior, vehicle behavior, fleet behavior, the environment, and the like.

[0018] In response to identifying the one or more timing events, each vehicle usage model outputs timing event data for the one or more timing events. The timing event data may include a driver identity, one or more vehicle locations, a location label for each vehicle location, one or more times for each location, a connectivity method, such as Wi-Fi or Cellular, and a duration of the timing event. In this way, a driver behavior profile dataset for the particular driver may be generated from the timing event data output from the vehicle usage model for that particular driver.The driver behavior profile datasets of one or more drivers may be stored in memory of an OTA server or an in-vehicle computing system. In this way, the timing event data included in the driver behavior profile dataset may be compared to real-time timing event data to determine whether an update notification may be sent to a driver and / or passenger via an in-vehicle user input device (e g., infotainment system or any other user interface), a mobile device and / or other computing device.

[0019] FIG. 1 illustrates an over-the-air (OTA) update system used to train a vehicle usage model that identifies one or more timing events and outputs corresponding timing event data. FIG. 2 depicts an in-vehicle computing system with a vehicle OTA system. An example process for generating a driver behavior profile is shown in FIG. 3. An OTA software update is performed according to the method shown in FIG. 4. FIG. 5 shows a method for determining an occurrence of a timing event. Generation of the driver behavior profile is performed according to the method described with respect to FIG. 6. FIG. 7 shows a method for training a vehicle usage model. As shown in FIGS. 8A-8C, time scales are provided for performing downloads and installations in response to user input received from download confirmation notifications and installation confirmation notifications.

[0020] An over-the-air (OTA) service system 100 is shown in FIG. 1. OTA service system 100 is incorporated into a computing system independent from a vehicle. For example, OTA service system 100 may be installed on a server. An OTA update system 102 may be operably / communicatively coupled to a user input device 132, a display device 134, and a vehicle 103 comprising a vehicle OTA module 105 and a user input device 109. Vehicle 103 may be a motor vehicle including drive wheels. Vehicle 103 may be a road automobile, among other types of vehicles.

[0021] In some examples, vehicle 103 may include a hybrid propulsion system including an energy conversion device operable to absorb energy from vehicle motion and / or the engine and convert the absorbed energy to an energy form suitable for storage by an energy storage device. Vehicle 103 may include a fully electric vehicle, incorporating fuel cells, solar energy capturing elements, and / or other energy storage systems for powering the vehicle. User input device 109 may be communicatively coupled to an in-vehicle computing system of the vehicle 103 and may comprise one or more of a touchscreen, a keyboard, a mouse, a trackpad, a motion sensing camera,or other device configured to enable a user to interact with and manipulate data within the in- vehicle computing system.

[0022] Further, the OTA update system 102 includes a processor 104 configured to execute machine readable instructions stored in non-transitory memory 106. Processor 104 may be single core or multi-core, and the programs executed thereon may be configured for parallel or distributed processing. In some embodiments, the processor 104 may optionally include individual components that are distributed throughout two or more devices, which may be remotely located and / or configured for coordinated processing. In some embodiments, one or more aspects of the processor 104 may be virtualized and executed by remotely-accessible networked computing devices configured in a cloud computing configuration.

[0023] The processor 104 also stores a software update module 114 that comprises instructions for an OTA software update campaign and performing OTA software updates for a vehicle 103. Software update module 114 may also comprise instructions for sending download confirmation notifications and installation confirmation notifications for OTA software updates to the vehicle 103. The software update module 114 may be used by the OTA update system 102 according to the method described in FIG. 5.

[0024] Non-transitory memory 106 may store a vehicle usage module 108, a training module 110, an inference module 112, a software update module 114, a vehicle usage database 116, a user input database 118, and driver behavior profile database 120. The vehicle usage module 108 may include at least one vehicle usage model, and instructions for implementing the vehicle usage model to identify one or more timing events and output data related to the one or more timing events as described in greater detail below. The vehicle usage module 108 may include trained and / or untrained vehicle usage models and may further include various data, or metadata pertaining to the one or more vehicle usage models stored therein.

[0025] Non-transitory memory 106 may further store a training module 110, which comprises instructions for training one or more of the vehicle usage models stored in vehicle usage module 108. Training module 110 may include instructions that, when executed by the processor 104, cause an OTA update system 102 to conduct one or more of the steps of method 400 for sending a notification regarding an OTA software update to a vehicle user and performing the OTA software update in response to an occurrence of a timing event, method 500 for identifying an occurrence of the timing event, method 600 for generating a plurality of driver behavior profiledatasets based on data output from a plurality of vehicle usage models, and method 700 for training a vehicle usage model to identify one or more timing events and output timing event data is discussed in more detail below in reference to FIGS. 4-7, respectively. In some embodiments, training module 110 includes instructions for implementing one or more gradient descent algorithms, applying one or more loss functions, and / or training routines, for use in adjusting parameters of one or more vehicle usage models of vehicle usage module 108.

[0026] Non-transitory memory 106 also stores an inference module 112 that comprises instructions for testing new data with the trained vehicle usage model. After the vehicle usage model has been trained, output from the trained vehicle usage model may be used by the OTA update system 102 to generate driver behavior profile data and store the driver behavior profile data in non-transitory memory, as described in FIG. 7. Additionally, a subset of timing event data included in the generated driver behavior profile database 120 may be stored in a vehicle OTA module 105 of the vehicle 103. The subset of timing event data is stored in driver behavior profile database 107. Driver behavior profile database 107 includes driver behavior profile data related to one or more drivers who operate the vehicle 103. Driver behavior profile data may be used to determine real-time occurrences of one or more timing events, as described in FIG. 5.

[0027] Non-transitory memory 106 further stores vehicle usage database 116. Vehicle usage database 116 may include for example, data acquired via car dealerships, in-vehicle systems, online databases, etc. For example, the vehicle usage database 116 may store vehicle data acquired via the in-vehicle systems for different vehicles and different drivers. More specifically, vehicle usage database 116 may include generic vehicle data, vehicle historical data, driver historical data, fleet historical data, environmental data, OTA operational historical data, and the like. Generic vehicle data may include vehicle model, model year, and vehicle characteristics, such as in-vehicle hardware modeling, in-vehicle software modeling, type of ECU, ECU specifications, and software running on the ECU. Vehicle historical data may include previous locations visited by the vehicle 103 and previous software updates performed on the vehicle as well as statistics regarding the software updates including percentage of successful software updates, update failure explanations, and duration of previous software updates.

[0028] Driver historical data may include previous locations visited by a particular driver, duration of idle time at each location, network availability and type (e.g., cellular Wi-Fi, etc.) at each location, and driver behavior related to previous software updates, including number ofsoftware update process initiations by the driver, number of software update rejections, number of software updates accepted, overall time before software update process initiation begins after notification is presented to the driver, and whether user input that causes the software update to be accepted or rejected is received. Fleet historical data may include a number of vehicles in each respective fleet, generic vehicle data, such as model year, for each vehicle and statistics regarding past software updates at the fleet level, including success rate, average duration to download, and average duration for installation.

[0029] OTA operation historical data may include statistics regarding software update campaigns, dates of the software update campaigns, number of vehicles included in the software update campaign, content updated within the software update campaign, success rate of the software update campaign, and software update campaign characteristics including number of retries and restrictions on connectivity methods (e.g., cellular, Wi-Fi, or both). In some embodiments, vehicle usage database 116 may include a plurality of training sets for training one or more vehicle usage models, the one or more vehicle usage models corresponding to different OEMs or vehicles manufactured by different vehicle manufacturers.

[0030] Non-transitory memory 106 further stores user input data in the user input database 118. User input database 118 may include user selected times and locations for receiving requests for OTA software updates, downloading OTA software updates, and installing OTA software updates. In some embodiments, the user input data may be included as part of the plurality of training sets for training the various vehicle usage models described above.

[0031] In some embodiments, the non-transitory memory 106 may include components disposed at two or more devices, which may be remotely located and / or configured for coordinated processing. In some embodiments, one or more aspects of the non-transitory memory 106 may include remotely-accessible networked storage devices configured in a cloud computing configuration.

[0032] User input device 132 may comprise one or more of a touchscreen, a keyboard, a mouse, a trackpad, a motion sensing camera, speech recognition, or other device configured to enable a user to interact with and manipulate data within OTA update system 102. In one example, user input device 132 may enable a user to make a selection of a vehicle data to use in training the ML models.

[0033] Display device 134 may include one or more display devices utilizing virtually any type of technology. In some embodiments, display device 134 may comprise a computer monitor. Display device 134 may be combined with processor 104, non-transitory memory 106, and / or user input device 132 in a shared enclosure, or may be peripheral display devices and may comprise a monitor, touchscreen, projector, or other display device known in the art, which may enable a user (e.g., an engineer) to interact with various data stored in non-transitory memory 106.

[0034] It should be understood that OTA update system 102 shown in FIG. 1 is for illustration, not for limitation. Another appropriate OTA update system may include more, fewer, or different components.

[0035] As shown in FIG. 2, a system according to the present disclosure may be communicatively coupled to a vehicle, and methods according to the present disclosure may be carried out based on vehicle data of the vehicle.

[0036] FIG. 2 shows a block diagram of an in-vehicle computing system 209 configured and / or integrated inside vehicle 200. In some examples, the in-vehicle computing system 209 may be a vehicle infotainment system configured to provide information-based media content (audio and / or visual media content, including entertainment content, navigational services, etc.) to a vehicle user to enhance the operator’s in-vehicle experience. The in-vehicle computing system 209 may include, or be coupled to, various vehicle systems, sub-systems, hardware components, as well as software applications and systems that are integrated in, or integratable into, vehicle 200 in order to enhance an in-vehicle and driving experience for a driver and / or a passenger.

[0037] In-vehicle computing system 209 may include one or more processors including an operating system processor 214 and an interface processor 220. Operating system processor 214 may execute an operating system on the in-vehicle computing system, and control input / output, display, playback, and other operations of the in-vehicle computing system. In particular, operating system processor may enable an over-the-air (OTA) update system, which may be an embodiment of OTA update system 102 of FIG. 1, to be communicatively coupled to a vehicle OTA system 205. In this way, the operating system processor 214 may enable the vehicle OTA system to perform OTA software update queries to determine whether a new OTA software update campaign is available.

[0038] Additionally, the vehicle OTA system 205 may store driver behavior profile datasets for one or more drivers, instructions executable by the vehicle OTA system 205 for performing OTAsoftware update queries, instructions for identifying an occurrence of a real-time timing event and generating a real-time timing event dataset based on relevant vehicle data, instructions for generating a location label for a vehicle location determined by GPS of a navigation system and / or the mobile device, and for executing instructions received from the OTA update system that download and install an OTA software update. For example, the vehicle OTA system 205 may include executable instructions that cause the processor 214 to identify when the vehicle is idle based on vehicle data obtained from vehicle systems / sensors and obtain relevant vehicle data for a real-time timing event and transmitting the relevant vehicle data to the vehicle OTA system 205 or the OTA update system.

[0039] In this way, the subsystems of in-vehicle computing system 209 and other vehicle systems may be updated with new software versions to increase performance of the vehicle 200. In some embodiments, the vehicle OTA system 205 may be integrated with the in-vehicle computing system 209. In other embodiments, the vehicle OTA system 205 may be communicatively coupled to the in-vehicle computing system 209 or other computing systems included in the vehicle 200. Interface processor 220 may interface with a vehicle control system 230 and sound processor for external sounds 213 via an inter-vehicle system communication module 222.

[0040] Inter-vehicle system communication module 222 may output data to other vehicle systems 231 and vehicle control elements, while also receiving data input from other vehicle components and systems 231, 261, e.g. by way of vehicle control system 230. When outputting data, inter-vehicle system communication module 222 may provide a signal via a bus corresponding to any status of the vehicle, the vehicle surroundings, or the output of any other information source connected to the vehicle. Vehicle data outputs may include, for example, analog signals (such as current velocity), digital signals provided by individual information sources (such as clocks, thermometers, location sensors such as Global Positioning System [GPS] sensors, etc.), digital signals propagated through vehicle data networks (such as an engine CAN bus through which engine related information may be communicated, a climate control CAN bus through which climate control related information may be communicated, and a multimedia data network through which multimedia data is communicated between multimedia components in the vehicle).

[0041] For example, the in-vehicle computing system 209 may retrieve from the engine CAN bus the current speed of the vehicle estimated by the wheel sensors, a current speed of the engineby the engine speed sensors, a power state of the vehicle via a battery and / or power distribution system of the vehicle, gear shift position, engagement of a parking break by the parking break sensors, an ignition state of the vehicle, etc. In addition, other interfacing means such as Ethernet may be used as well without departing from the scope of this disclosure.

[0042] A non-volatile storage device 208 may be included in in-vehicle computing system 209 to store data such as instructions executable by processors 214 and 220 in non-volatile form. The storage device 208 may store application data, including prerecorded sounds, to enable the in- vehicle computing system 209 to run an application for connecting to a cloud-based server and / or collecting information for transmission to the cloud-based server, such as the OTA update system. The application may retrieve information gathered by vehicle systems / sensors, input devices (e.g., user interface 218), data stored in volatile 219A or non-volatile storage device (e.g., memory) 219B, devices in communication with the in-vehicle computing system (e.g., a mobile device connected via a Bluetooth link), etc.

[0043] In-vehicle computing system 209 may further include a volatile memory 219A. Volatile memory 219A may be random access memory (RAM). Non-transitory storage devices, such as non-volatile storage device 208 and / or non-volatile memory 219B, may store instructions and / or code that, when executed by a processor (e.g., operating system processor 214 and / or interface processor 220), controls the in-vehicle computing system 209 to perform one or more actions.

[0044] A microphone 202 may be included in the in-vehicle computing system 209 to receive voice commands from a user, to measure ambient noise in the vehicle, to determine whether audio from speakers of the vehicle is tuned in accordance with an acoustic environment of the vehicle, etc. A speech processing unit 204 may process voice commands, such as the voice commands received from the microphone 202. In some embodiments, in-vehicle computing system 209 may also be able to receive voice commands and sample ambient vehicle noise using a microphone included in an audio system of the vehicle.

[0045] One or more additional sensors may be included in a sensor subsystem 210 of the in- vehicle computing system 209. For example, the sensor subsystem 210 may include a camera, such as a rear view camera for assisting a user in parking the vehicle and / or a cabin camera for identifying a user (e.g., using facial recognition and / or user gestures). Sensor subsystem 210 of in-vehicle computing system 209 may communicate with and receive inputs from various vehicle sensors and may further receive user inputs. For example, the inputs received by sensor subsystem210 may include transmission gear position, transmission clutch position, gas pedal input, brake input, transmission selector position, vehicle speed, engine speed, mass airflow through the engine, ambient temperature, intake air temperature, etc., as well as inputs from climate control system sensors (such as heat transfer fluid temperature, antifreeze temperature, fan speed, passenger compartment temperature, desired passenger compartment temperature, ambient humidity, etc.), an audio sensor detecting voice commands issued by a user, a fob sensor receiving commands from and optionally tracking the geographic location / proximity of a fob of the vehicle, etc. While certain vehicle system sensors may communicate with sensor subsystem 210 alone, other sensors may communicate with both sensor subsystem 210 and vehicle control system 230, or may communicate with sensor subsystem 210 indirectly via vehicle control system 230.

[0046] A navigation subsystem 211 of in-vehicle computing system 209 may generate and / or receive navigation information such as location information (e.g., via a GPS sensor and / or other sensors from sensor subsystem 210), route guidance, traffic information, point-of-interest (POI) identification, and / or provide other navigational services for the driver. Navigation subsystem 211 may include inputs / outputs 280, including analog to digital converters, digital inputs, digital outputs, network outputs, radio frequency transmitting devices, etc. The sound processor for external sounds 213 may also include a central processing unit 281, volatile memory 282, and nonvolatile (e.g., non-transient memory) 283.

[0047] External device interface 212 of in-vehicle computing system 209 may be coupleable to and / or communicate with one or more external devices 250 located external to vehicle 200. While the external devices are illustrated as being located external to vehicle 200, it is to be understood that they may be temporarily housed in vehicle 200, such as when the user is operating the external devices while operating vehicle 200. In other words, the external devices 250 are not integral to vehicle 200. The external devices 250 may include a mobile device 228 (e.g., connected via a Bluetooth, NFC, WIFI direct, or other wireless connection) or an alternate Bluetooth device of Bluetooth device 252. Mobile device 228 may be a mobile phone, smart phone, wearable devices / sensors that may communicate with the in-vehicle computing system via wired and / or wireless communication, or other portable electronic device(s).

[0048] The mobile device 228 may receive OTA software update notifications, such as download confirmation notifications and installation confirmation notifications, via the in-vehicle computing system 209 via the OTA update system. The mobile device 228 may receive user inputregarding accepting, postponing, or rejecting software downloads and installations. Other external devices include external services 246. For example, the external devices may include extravehicular devices that are separate from and located externally to the vehicle. Still other external devices include external storage devices 254, such as solid-state drives, pen drives, USB drives, etc. External devices 250 may communicate with in-vehicle computing system 209 either wirelessly or via connectors without departing from the scope of this disclosure. For example, external devices 250 may communicate with in-vehicle computing system 209 through the external device interface 212 over network 260, a universal serial bus (USB) connection, an On-Board Diagnostic (OBD) port, a direct wired connection, a direct wireless connection, and / or other communication link.

[0049] The external device interface 212 may provide a communication interface to enable the in-vehicle computing system to communicate with mobile devices associated with contacts of the driver. The external device interface 212 may additionally or alternatively provide a wireless communication interface to enable the in-vehicle computing system to synchronize data with one or more devices in the vehicle (e.g., the driver’s mobile device) via WIFI direct.

[0050] One or more mobile device applications 244 may be operable on mobile device 228. As an example, mobile device applications 244 may be operated to aggregate user data regarding interactions of the user with the mobile device. For example, mobile device applications 244 may aggregate data regarding positional information including locations frequented by the user and an amount of time spent at each location, etc. The collected data may be transferred by mobile device applications 244 to external device interface 212 over network 260. In addition, specific user data requests may be received at mobile device 228 from in-vehicle computing system 209 via the external device interface 212. The specific data requests may include requests for determining where the user is geographically located, an ambient weather condition (temperature, humidity, etc.) at the user’s location, etc. Mobile device applications 244 may send control instructions to components (e.g., microphone, amplifier etc.) or other applications (e.g., navigational applications) of mobile device 228 to enable the requested data to be collected on the mobile device or requested adjustment made to the components. Mobile device applications 244 may then relay the collected information back to in-vehicle computing system 209 in response to receiving consent from the owner of the vehicle 200.

[0051] Likewise, one or more external services applications 248 may be operable on external services 246. As an example, external services applications 248 may be operated to aggregate and / or analyze data from multiple data sources. The collected data may be transmitted to another device and / or analyzed by the application to determine a context of the driver, vehicle, and environment and perform an action based on the context (e.g., requesting / sending data to other devices).

[0052] Vehicle control system 230 may include controls for controlling aspects of various vehicle systems 231 involved in different in-vehicle functions. Vehicle control system 230 may also include controls for adjusting the settings of various vehicle controls 261 (or vehicle system control elements) related to the engine and / or auxiliary elements within a cabin of the vehicle, such as steering wheel controls, instrument panel controls, microphone(s), accelerator / brake / clutch pedals, a gear shift, door / window controls positioned in a driver or passenger door, seat controls, cabin light controls, audio system controls, cabin temperature controls, etc. Vehicle controls may also include internal engine and vehicle operation controls (e.g., engine controller module, actuators, valves, etc.) that are configured to receive instructions via the CAN bus or other in- vehicle communication network of the vehicle to change operation of one or more of the engine, exhaust system, transmission, and / or other vehicle system. The control signals may also control audio output at one or more speakers of the vehicle’s audio system.

[0053] In-vehicle computing system 209 may further include an antenna 206. Antenna 206 is shown as a single antenna, but may comprise one or more antennas in some embodiments. The in-vehicle computing system may obtain broadband wireless internet access via antenna 206, and may further receive broadcast signals such as radio, television, weather, traffic, and the like. The in-vehicle computing system may receive positioning signals such as GPS signals via one or more antennas 206. The in-vehicle computing system may also receive wireless commands via FR such as via antenna(s) 206 or via infrared or other means through appropriate receiving devices.

[0054] One or more elements of the in-vehicle computing system 209 may be controlled by a user via user interface 218. User interface 218 may include a graphical user interface presented on a touch screen, and / or user-actuated buttons, switches, knobs, dials, sliders, etc. For example, user-actuated elements may include steering wheel controls, door and / or window controls, instrument panel controls, audio system settings, climate control system settings, and the like. A user may also interact with one or more applications of the in-vehicle computing system 209 andmobile device 228 via user interface 218. In addition to receiving a user’s vehicle setting preferences on user interface 218, vehicle settings selected by in-vehicle control system may be displayed on user interface 218. Notifications and other messages (e.g., received messages), as well as navigational assistance, may be displayed to the user on a display of the user interface. User preferences / information and / or responses to presented messages may be performed via user input to the user interface. Additionally, a driver identity of the driver may be obtained and stored in a driver ID module 221 of the user interface 218.

[0055] Sound processor for external sounds 213 may be electrically coupled to a plurality of microphones that are external to vehicle 200 (e.g., external microphones). However, in other examples, the tasks and functions that may be performed by sound processor for external sounds 213 may be integrated into in-vehicle computing system 209.

[0056] FIG. 3 shows a process 300 for generating a driver behavior profile, and more specifically, a driver behavior profile dataset 314 based on output from a vehicle usage model 312. Vehicle usage model 312 is trained to identify one or more timing events wherein download confirmation notifications and installation confirmation notifications are more likely to be accepted by a driver. Timing events are combinations of time of day, time of week or time of month, and location. In addition to identifying the one or more timing events, the vehicle usage model is trained to output timing event data for the identified timing events.

[0057] The process 300 includes receiving vehicle usage data 301, which includes data collected from a plurality of drivers. Vehicle usage data 301 may include generic vehicle data, historical vehicle data, historical driver data, historical fleet data, environmental data, historical OTA operational historical data, and the like, as described above in FIG. 1. Generic vehicle data and historical vehicle data may indicate times and situations to notify a driver regarding an OTA software update for a specific model of vehicle based on a history of OTA software updates of the specific model of vehicle. Certain demographics of drivers may be more likely to own a specific model of vehicle.

[0058] For example, one demographic of drivers may be more likely to own a specific model with more technological features and may be more responsive to OTA software update download and installation confirmation notifications. In contrast, another demographic of drivers may be more likely to own a specific model with less technological features and may be less responsive to OTA software update download and installation confirmation notifications. Historical driverdata may indicate times and situations to notify a specific driver regarding an OTA software update and historical data may similarly indicate times and situations to notify a driver belonging to a specific fleet, where the fleet includes similar vehicles, of a specific OTA software update.

[0059] Vehicle usage data 301 may be stored in memory of over-the-air (OTA) update system, which may be an embodiment of the OTA update system 102 of FIG. 1. In one embodiment, the vehicle usage data 301 may be collected from vehicle dealerships that obtain population data regarding drivers that purchase certain types of vehicles. For example, drivers who purchase a sports utility vehicle (SUV) may include families with one or more children. Accordingly, SUVs may frequently be idle at parks, school gyms, or sports fields for significant periods of time.

[0060] In another embodiment, the vehicle usage data may be collected from sensors of a vehicle and / or from vehicle subsystems, including a navigation system that utilizes GPS. Output from vehicle speed sensors may indicate that a vehicle is not in motion and output from an engine speed sensor may indicate that an engine is idle. Additionally, gear shift position may be utilized to determine whether the vehicle is not in motion. Further, physical coordinates of a vehicle location may be determined with GPS and other relevant data may be obtained as well during a timing event wherein the vehicle is idle.

[0061] The process 300 may further include generating a plurality of subsets 303 of vehicle usage data for each driver by inputting the vehicle usage data 301 into a dataset generator 302. In this way, each dataset includes data pertaining to a single driver of one vehicle. Each subset may include three or more behavior datasets, including a driver behavior dataset 304, a vehicle behavior dataset 306, and a fleet behavior dataset 308. As another example, the subset may also include an environmental dataset that includes historical environmental data regarding the weather forecast when OTA software download confirmation notifications and installation confirmation notifications are accepted, rejected, and postponed by a driver of a vehicle.

[0062] The driver behavior dataset 304 includes vehicle usage data related to a particular driver. The vehicle behavior dataset 306 is location-based and includes vehicle usage data related to a particular type of vehicle in a particular location. In one embodiment, the type of vehicle may include pickup trucks. In alternative embodiments, the type of vehicle may be a specific model of vehicle, such as a Ford F-150. The fleet behavior dataset 308 is location-based and includes vehicle usage data related to a fleet of vehicles with similar characteristics. For example, a fleet of vehicle may include a fleet of commercial vehicles owned by an entity in North America. Asanother example, a fleet of vehicle may include different models of electric vehicles (EV) in the United Kingdom.

[0063] The process 300 includes inputting the driver behavior dataset 304, the vehicle behavior dataset 306, and the fleet behavior dataset 308 for that particular driver and estimated times 310 for the OTA software updates as input to the vehicle usage model 312 to generate a driver behavior profile dataset 314 for a particular driver. The vehicle usage model 312 may be one or more suitable ML model architectures, such as neural networks, random forest, decision trees, Bayesian networks, etc. For example, in some embodiment, a vehicle usage model be a recurrent neural network (RNN), a deep neural network (DNN), a Hidden Markov Model (HMM), or a Reinforcement Learning (RL) algorithm. The estimated times 310 includes a plurality of estimated times to download and install an OTA software update based on the size of the OTA software update.

[0064] As an example, the vehicle usage model may be trained, according to FIG. 7. As described above, a driver behavior profile dataset 314 may be generated by inputting vehicle usage data 301 of a particular driver and the estimated times 310 to the vehicle usage model 312. More specifically, to generate the driver behavior profile dataset 314, the vehicle usage data 301 for a particular driver and the plurality of estimated times 310 are entered as input to the vehicle usage model 312

[0065] In this way, the vehicle usage model 312 identifies one or more timing events wherein a vehicle is expected to be idle for a duration of time that exceeds a duration of time to finish (e g. download and install) the OTA software update. The vehicle usage model 312 outputs the driver behavior profile dataset 314 related to one or more timing events for that particular driver. The driver behavior profile dataset 314 includes timing event data such as a driver identity, one or more vehicle locations, one or more times for a particular vehicle location, and a connectivity method of a mobile computing device when download confirmation notification and installation confirmation notifications are received, a duration of the timing event, and the like.

[0066] The driver behavior profile dataset 314 may be sent to a location in memory of the OTA update system and / or in memory of a vehicle OTA module of a vehicle, which may be an embodiment of vehicle OTA system 205 of vehicle 200 of FIG. 2. In this way, the driver behavior profile dataset 314 may be obtained when access to memory of the OTA update system is not available.

[0067] Driver behavior profile datasets for other drivers, such as a second driver or a third driver, may be generated similarly by selecting the appropriate subset of vehicle usage data for the respective driver and inputting the subset as input to the vehicle usage model 312. More specifically, a driver behavior profile dataset may be generated by inputting a subset of vehicle usage data 301 for a different driver than the first driver and the plurality of estimated times 310 into the vehicle usage model 312. In some embodiments, the vehicle usage model 312 may identify one or more timing events and generate a driver behavior profile dataset 314 for all vehicles models from every vehicle manufacturer. In other embodiments, the vehicle usage model 312 may be one vehicle usage model of a plurality of vehicle usage models wherein each vehicle usage model is trained to identify one or more timing events and output timing event data for different vehicle manufacturers. In further embodiments, the vehicle usage model may be one vehicle usage model of the plurality of vehicle usage models wherein each vehicle usage model is trained to identify one or more timing events and output timing event data for different OEMs.

[0068] FIG. 4 is a flowchart illustrating a method 400 for performing an over-the-air (OTA) software update of a vehicle based on output from a vehicle usage model that identifies one or more timing events and outputs timing event data used to generate a driver behavior profile according to an embodiment of the present disclosure. Method 400 may be carried out according to instructions stored in non-transitory memory and executed by one or more processors of the OTA update system 102 of FIG. 1.

[0069] At 402, the method 400 includes creating an OTA software update campaign via an OTA update system. The OTA update system may be an embodiment of the OTA update system 102 of FIG. 1. The OTA software update campaign may be created in response to a new software version being available. The OTA software update campaign may include device groups based on region and vehicle model that may receive the OTA software update, the new software version each device may receive, and software and hardware criteria of the devices in order for the software update to be received by each device.

[0070] The OTA software update campaign may also include messages that are displayed to a user (e.g., a driver). The messages may disclose a purpose of the OTA software update, an anticipated download time for the OTA software update, and an anticipated installation time in notifications. In some embodiments wherein user consent is not received prior to performing the OTA software update, a single notification may be displayed to the user before downloading andinstalling the OTA software update. The single notification may alert the user about the OTA update campaign and may begin automatic download and installation of the OTA software update after the notification is displayed to the user.

[0071] In embodiments wherein user consent is received prior to performing the OTA software update, the notifications may include a download confirmation notification that requests a download of the OTA software update to an OTA vehicle system of a vehicle and an installation confirmation notification that requests an installation of the OTA software update to the OTA vehicle system. The download confirmation notification may alert the user about the OTA update campaign and may request user input before downloading the OTA software update. The installation confirmation notification may alert the user about the OTA software update campaign and may request user input before installing the OTA software update. In some embodiments, the OTA software update may be performed automatically without sending the download confirmation notification and the installation confirmation notification and without receiving user input that causes the download confirmation notification and installation confirmation notification to be accepted.

[0072] At 404, the method 400 includes sending a notification of the OTA software update campaign to a vehicle OTA system in response to an OTA software update query performed by the vehicle OTA system or by the driver. In one embodiment, the vehicle OTA system may periodically perform OTA software update queries to check for available OTA software update campaigns. In another embodiment, the vehicle OTA system may perform OTA software update queries in response to a real-time timing event identified using a driver behavior profile dataset stored in memory of the vehicle OTA system. In another embodiment, the vehicle OTA system may perform OTA software update queries in response to notifications sent to the vehicle from the OTA update system (e.g., OTA update system 102 of FIG. 1). More specifically, since the vehicle OTA system of the vehicle is communicatively coupled to the OTA update system, the OTA update system may search for an OTA software update campaign stored in memory (e.g., software update module 114 of FIG. 1) in response to the query. The OTA update system may send the notification of the OTA software update campaign to the vehicle OTA system responsive to one or more OTA software update campaigns being stored in memory.

[0073] At 406, the method 400 includes sending the download confirmation notification to a driver in response to a real-time timing event occurrence via the OTA update system. As describedabove, the download confirmation notification may include a message regarding the vehicle systems affected by the OTA software update and the anticipated duration of time to finish downloading the OTA software update. In some embodiments, the download confirmation notification may be displayed via a user interface of a mobile computing device (e.g., a mobile phone) or an in-vehicle computing system, such as in-vehicle computing system 209 of FIG. 2. The real-time timing event occurrence is identified with a driver behavior profile generated based on output from a vehicle usage model, which may be a vehicle usage machine learning (ML) model, according to the method described in FIG. 6.

[0074] At 408, the method 400 includes determining whether the download confirmation notification is accepted. The download confirmation notification may request user input prior to performing the download. User input may be received in response to a user interacting with a user input device communicatively coupled to a user interface of the mobile computing device or the in-vehicle computing device. The user interface may include widgets (e.g., buttons) that enable the download confirmation notification to be accepted, rejected, or postponed. The user input received at the widgets may cause the download confirmation notification to be accepted, rejected, or postponed.

[0075] For example, in one embodiment, the user interface may include a first widget, a second widget, and a third widget. User input received at the first widget may cause the download confirmation notification to be accepted. User input received at the second widget may cause the download confirmation notification to be rejected. User input received at the third widget may cause the download confirmation notification to be postponed. Alternate embodiments may utilize a different user interface configuration with fewer or more widgets. Regardless of the user interface configuration, user input received at a respective widget may cause the download confirmation notification to be accepted, postponed, or rejected.

[0076] In response to the download confirmation notification not being accepted, the method 400 includes determining whether the download confirmation request is postponed at 410. As described above, the download confirmation notification is not accepted when user input is not received at the respective widget that causes the download confirmation notification to be accepted. Similarly, the download confirmation notification may be postponed in response to receiving user input at a respective widget that causes the download confirmation notification to be postponed and not receiving user input at a respective widget that causes the download confirmationnotification to be rejected. In response to the download confirmation notification request being postponed, the method 400 includes sending the download confirmation notification to the driver in response to a real-time timing event occurrence via the OTA update system at 406 until the download confirmation notification is accepted at 406. In response to the download confirmation notification not being postponed, the method 400 includes receiving user input rejecting the download confirmation notification at 412. The download confirmation notification is rejected in response to receiving user input at the respective widget that causes the download confirmation to be rejected. The method 400 then ends.

[0077] Returning to 408, in response to the download confirmation notification being accepted, the method 400 includes downloading the OTA software update to the vehicle OTA system in response to a real-time timing event occurrence identified using a driver behavior profile dataset generated by a vehicle usage model at 414. The driver behavior profile dataset that comprises a driver behavior profile may be generated with the vehicle usage model for a particular driver using a trained vehicle usage ML model, according to the method described in FIG. 6. The OTA update system may send instructions and store instructions in memory of the vehicle OTA system that cause the OTA software update to be downloaded.

[0078] At 416, the method includes sending an installation confirmation notification to the driver via the OTA update system in response to a real-time timing event occurrence via the OTA update system. As described above, the installation confirmation notification may include a message regarding the vehicle systems affected by the OTA software update and the anticipated duration of time to finish installation of the OTA software update. In some embodiments, the installation confirmation notification may be displayed via the user interface of a mobile computing device (e.g., a mobile phone) or an in-vehicle computing system, such as in-vehicle computing system 209 of FIG. 2. The real-time timing event occurrence is identified based on output from a vehicle usage model, which may be a vehicle usage machine learning (ML) model, according to the method described in FIG. 5.

[0079] At 418, the method includes determining whether the installation confirmation notification is accepted. Similar to above, the installation confirmation notification may request user input prior to performing the download. User input may be received in response to a user interacting with a user input device communicatively coupled to a user interface of the mobile computing device or the in-vehicle computing device. The user interface may include widgets(e g., buttons) that enable the installation confirmation notification to be accepted, rejected, or postponed. The user input received at the widgets may cause the installation confirmation notification to be accepted, rejected, or postponed.

[0080] In response to the installation confirmation notification not being accepted, the method 400 include determining whether the installation confirmation notification is postponed at 420. As described above, the installation confirmation notification is not accepted when user input is not received at a respective widget that causes the installation confirmation notification to be accepted. Similarly, the installation confirmation notification may be postponed in response to receiving user input at a respective widget that causes the installation confirmation notification to be postponed and not receiving user input at a respective widget that causes the installation confirmation to be rejected.

[0081] In response to the installation confirmation being postponed, the method 400 includes sending the installation confirmation notification to the driver in response to a real-time timing event occurrence via the OTA update system at 416 until the installation confirmation notification is accepted. In some cases, the installation confirmation notification is not immediately accepted after downloading the OTA software update, which may be due to the duration of time for the download and installation to finish exceeding the duration of the real-time timing event. Consequently, the installation confirmation may be postponed. When download and installation of the OTA software update does not occur during the same timing event, the installation confirmation notification may be sent in response to a different timing event included in the driver behavior profile dataset.

[0082] At times, the OTA update system may be not communicatively coupled to the vehicle OTA system temporarily. As such, occurrences of real-time timing events may be identified with the driver behavior profile dataset stored in memory of the OTA vehicle system instead of the OTA update system. In this way, once the OTA software update is downloaded, the OTA software update may be installed regardless of not having access to the driver behavior profile dataset stored in memory of the OTA update system.

[0083] In response to the installation confirmation notification not being postponed, the method 400 include receiving user input rejecting the installation confirmation notification at 422. The installation confirmation notification may be rejected in response to receiving user input at therespective widget that causes the installation confirmation notification to be rejected. The method 400 then ends.

[0084] Returning to 416, in response to the installation confirmation notification being accepted, the method 400 includes installing the OTA software update via the vehicle OTA system in response to a real-time timing event occurrence identified using the driver profile behavior dataset at 424. The driver behavior profile dataset that comprises the driver behavior profile may be generated with the vehicle usage model for a particular driver using a trained vehicle usage ML model, according to the method described in FIG. 6. The OTA update system may send instructions and store instructions in memory of the vehicle OTA system that cause the OTA software update to be installed. The method 400 then ends.

[0085] FIG. 5 is a flowchart illustrating a method 500 for identifying occurrences of real-time timing events based on a driver behavior profile according to an embodiment of the disclosure. In some embodiments, method 500 may be carried out according to instructions stored in non- transitory memory and executed by one or more processors of the OTA update system 102 of FIG. 1. In other embodiments, method 500 may be carried out according to instructions stored in non- transitory memory and executed by one or more processors of an in-vehicle computing system or a vehicle OTA system of FIG. 2.

[0086] The method 500 includes, comparing the real-time timing event data with the driver behavior profile dataset stored in memory in response to receiving vehicle data that indicates a vehicle is idle and receiving an estimated time at 502. The vehicle data may include sensor data output from various sensors of a plurality of vehicle systems of a vehicle. For example, vehicle data may include vehicle speed data output from a speed sensor, engine speed data from an engine speed sensor, parking brake data from a parking brake sensor, gear shift position from gear sensors, and location data output from GPS sensors, a current time, connectivity method of a mobile device paired to the in-vehicle computing system, and the like. The vehicle may be considered idle when engine speed is low, a parking break is either engaged or disengaged and the gear shift position is in a parking mode. The estimated time for download and installation of the OTA software update may be obtained when a notification, such as the download confirmation notification and / or the installation confirmation notification, is received from the OTA update system.

[0087] A real-time timing event dataset that includes vehicle data at a start of the real-time timing event may be generated by the OTA vehicle system, which may be an embodiment of theOTA vehicle system of FIG. 2, based on vehicle data collected in response to the vehicle being idle. The real-time timing event dataset may include a driver identity determined with the driver ID module 221 of FIG. 2, a vehicle location determined via GPS sensors of the vehicle or a GPS system of a mobile device paired to the in-vehicle computing system, gear shift position determined via gear sensors, a current time, a connectivity method of a mobile device paired to the in-vehicle computing system, duration of time for the download to finish, duration of time for the installation to finish, and a duration of time for the software update to finish (e.g., download and installation), and the like. As an example, the real-time timing event dataset may include the following data: a VIN number (e.g., 4Y1SL65848Z411439), a GPS coordinate (e.g., 40.689263, - 74.044505), 9:23 PM, Friday, cellular, 35 minutes, 15 minutes, 50 minutes, etc.

[0088] To determine whether the real-time timing event dataset corresponds to an actual timing event, the real-time timing event dataset may be compared with timing event data included in a driver behavior profile dataset for a respective driver. Each timing event dataset included in the driver behavior profile dataset may include one or more vehicle locations, a location label for each vehicle location, and one or more times for each vehicle location, a duration of the timing event, and the connectivity method. In particular, the comparison of the real-time timing event dataset and the driver behavior profile dataset may include comparing the estimated time of the OTA software update with the duration of the timing event, vehicle locations, the location labels, comparing the connectivity methods, comparing the times, and the like.

[0089] At 504, the method 500 includes determining whether the timing event data included in the real-time timing event dataset and the driver behavior profile dataset match. The real-time timing event dataset and the driver behavior profile dataset may be considered matching when at least one timing event dataset included in the driver behavior dataset matches the real-time timing event dataset. In particular, the vehicle locations and the day of the date included in the real-time timing event dataset and the timing event dataset of the driver behavior profile dataset should match. Further, the current time included in the real-time timing event dataset should be the same as the start time or be at a time between the start time and end time of the timing event included in the timing event dataset. Additionally, the estimated time for the OTA update of the real-time timing event dataset should not exceed the duration of the timing event included in the timing event dataset.

[0090] In an example, the real-time timing event data may include the following data: VIN number, GPS coordinate, home, Monday, 8:30 PM, 1.5 hours, cellular, etc. More specifically, in the real-time timing event dataset, the driver identity is the VIN number, the GPS coordinate is the vehicle location, the location label is home, the date is on a Monday, the current time is 8:30 PM, the estimated time for the OTA update is 1.5 hours, and the mobile device is connected via the cellular network. A first timing event dataset included in the driver behavior profile dataset may include the following data: the VIN number, the GPS coordinate, home, Monday, 7:30 PM, 11 :59 PM, 4.5 hours, cellular, etc. In the first timing event dataset, the driver identity is the VIN number, the GPS coordinate is the vehicle location, the date is on a Monday, the timing event starts at 7:30 PM and ends at 11 :59 PM on Monday, the duration of the timing event is approximately 4.5 hours, and the mobile device is connected using a cellular network.

[0091] When compared to the first timing event dataset described above, the driver identity matches, the GPS coordinates match, the location labels match, the day of the date matches, the current time is between the start time and end time of the timing event, and the duration of the timing event exceeds that of the estimated time for the OTA software update. Since the vehicle location, day of the date, the time is within the time range of the timing event, and the estimated time is shorter than the timing event, the real-time timing event data is considered a true timing event.

[0092] In response to the timing event data matching, the method 500 includes alerting the system about an identified timing event at 506. In response to the timing event being identified, an alert may be sent to the OTA update system to enable the OTA update system to generate a download confirmation notification or an installation confirmation notification. In response to the timing event data not matching, the method 500 then ends.

[0093] The method 500 may deviate from the method described above without departing from the scope of the present disclosure. For example, for time sensitive embodiments wherein vehicle systems have not been updated with the most recent OTA software updates, the download confirmation notifications and the installation confirmation notification may be presented to the driver regardless of an occurrence of the real-time timing event to ensure desired performance of a vehicle. As another example, the timing event data may also include a location label for a GPS location. As such, a location label for a GPS location of a real-time timing event dataset may be generated by comparing the real-time timing event dataset to timing event datasets included in thedriver behavior profile and based on data obtained via the Internet, applications, such as online map services, and the like.

[0094] FIG. 6 is a flowchart illustrating a method 600 for generating a driver behavior profile with a vehicle usage machine learning (ML) model according to embodiments of the disclosure. For the purposes of the present disclosure, ML refers to a model that employs either artificial intelligence (Al) and / or machine learning (ML). The vehicle usage ML model may be trained according to the method described in FIG. 7. Method 600 may be carried out according to instructions stored in non-transitory memory and executed by one or more processors of the OTA update system 102 of FIG. 1.

[0095] At 602, the method 600 includes receiving a plurality of estimated times for various OTA software updates and vehicle usage data of a plurality of drivers. The plurality of estimated times includes estimated times for downloading, estimated times for installing, and combined estimated times for downloading and installing new software versions. In this way, one or more timing events may be identified wherein only a download of the OTA software finishes during the respective timing event, only an installation of the OTA software finishes during the respective timing event, and both the download and installation of the OTA software finish during the respective timing event.

[0096] In an example, for a particular software version, an estimated time to finish downloading the OTA software update may be approximately 120 minutes, an estimated time to finish installing the OTA software update may be approximately 20 minutes, and a combined estimated time to finish downloading and installing the OTA software update may be approximately 140 minutes. In another example, for a different software version, an estimated time to finish downloading the OTA software update may be approximately 45 minutes, an estimated time to finish installing the OTA software update may be approximately 10 minutes, and a combined estimated time for downloading and installing the OTA software update may be approximately 55 minutes.

[0097] By considering timing events wherein only the download may finish during a timing event, only the installation may finish during a timing event, and both of the download and installation finish during a timing event, a greater number of timing events may be identified, which in turn, may increase the frequency wherein a driver accepts a download confirmation notification and / or installation confirmation notification and the OTA software update is performed. As described herein, the vehicle usage data may include generic vehicle data, vehiclehistorical data, driver historical data, fleet historical data, environmental data, OTA operational historical data, and the like.

[0098] At 604, the method 600 includes for each driver, sorting relevant vehicle usage dataset into three or more behavior datasets, the three or more behavior datasets may include a driver behavior dataset, a vehicle behavior dataset, and a fleet behavior dataset. Additionally, the three or more behavior datasets may include an environmental dataset as described above. In some embodiments, each of the plurality of drivers may be different. In other embodiments, the plurality of drivers may include one or more of the same driver such that the same driver may account for more than one driver of the plurality of drivers when the respective driver operates more than one type of vehicle. In this way, the vehicle usage dataset may be sorted based on driver and type of vehicle. The vehicle usage data may be sorted into a plurality of subsets of vehicle usage data, the plurality of subsets of vehicle usage data being related to a single driver of the plurality of drivers. Each subset of data may further be sorted based on driver behavior data, vehicle behavior data, fleet behavior data, and the like.

[0099] For example, a first driver may drive a first type of vehicle, a second driver may drive a second type of vehicle, the first driver may drive a third type of vehicle. In this way, the first driver and first type of vehicle may be a first driver of the plurality of drivers, the second driver and the second type of vehicle may be a second driver of the plurality of drivers, and the first driver and a third type of vehicle may be a third driver of the plurality of drivers.

[0100] In this way, the vehicle usage data may be sorted into a first subset, a second subset, and a third subset. The first subset includes vehicle usage data corresponding to the first driver, the second subset includes vehicle usage data corresponding to the second driver, and the third subset incudes vehicle usage data corresponding to the third driver. Each of the first subset, the second subset, and the third subset may be sorted further based on driver behavior data, vehicle behavior data, fleet behavior data, and the like.

[0101] In an example, the first subset may be sorted into a driver behavior dataset for the first driver, a vehicle behavior dataset for the first driver, a fleet behavior dataset for the first driver, etc. The second subset may be sorted into a driver behavior dataset for the second driver, a vehicle behavior dataset for the second driver, fleet behavior dataset for the second driver, etc. The third subset may be sorted into a driver behavior dataset for the third driver, a vehicle behavior dataset for the third driver, a fleet behavior dataset for the third driver, etc.

[0102] At 606, the method 600 includes selecting one driver from the plurality of drivers. As described in FIG. 3, a vehicle usage ML model may identify one or more timing events for each driver of the plurality of drivers. The vehicle usage ML model identifies one or more timing events for a particular driver in a particular type of vehicle based on vehicle usage data corresponding to the particular driver operating a particular vehicle. Instructions configured, stored, and executed in memory by a processor may cause the processor to select one driver of the plurality of drivers. At 608, the method 600 includes selecting one estimated time from the plurality of estimated times. Instructions configured, stored, and executed in memory by a processor may cause the processor to randomly select one estimated time of the plurality of estimated times.

[0103] At 610, the method 600 includes generating a driver behavior profile dataset for the selected driver by inputting the selected estimated time and vehicle usage dataset into the vehicle usage ML model. As described herein, in some embodiments, the vehicle usage model may identify one or more timing events and output timing event data for different types of OEMs or vehicles manufactured by different vehicle manufacturers. In some embodiments, the vehicle usage ML model may be one vehicle usage ML model of a plurality of vehicle usage ML models.

[0104] As an example, a specific vehicle usage ML model may identify one or more timing events and output timing event data for vehicles with a specific type of OEM, and thus, may be trained on vehicle usage data obtained from a driver operating a vehicle configured with that particular type of OEM. Accordingly, a first vehicle usage ML model of the plurality of vehicle usage ML models may be trained to identify one or more timing events and output timing event data based on vehicle usage data for a vehicle with a first type of OEM, a second vehicle usage ML model of the plurality of vehicle usage models may be trained to identify one or more timing events and output timing event data based on vehicle usage data for a vehicle with a second type of OEM, etc.

[0105] Alternatively, the specific vehicle usage ML model of the plurality of vehicle usage ML models may identify one or more timing events and output timing event data for vehicles manufactured by a specific vehicle manufacturer, and thus, may be trained on vehicle usage data obtained from a driver operating a vehicle manufactured by a specific vehicle manufacturer (e.g., Ford, Subaru, Honda, etc.). Accordingly, the first vehicle usage ML model of the plurality of vehicle usage models may be trained to identify one or more timing events and output timing event data based on vehicle usage data for vehicles manufactured by Ford, the second vehicle ML usagemodel of the plurality of vehicle usage models may be trained to identify one or more timing events and output timing event data based on vehicle usage data for vehicles manufactured by Subaru, etc.

[0106] For embodiments wherein the vehicle usage ML model is one of the plurality of the plurality of vehicle usage ML models, the vehicle usage ML may be selected from a plurality of vehicle usage ML models based on one of the type of OEM a vehicle is configured with or based on the vehicle manufacturer. In this way, a vehicle usage profile dataset for the selected driver may be generated based on output from the selected vehicle usage ML model.

[0107] In an embodiment, a single vehicle usage ML model identifies one or more timing events and outputs timing event data for the one or more timing events for different OEMs and vehicles manufactured by different vehicle manufacturers. The first driver may be selected and the three or more behavior datasets for the first driver and the selected estimated time may be input to the vehicle usage ML model to identify one or more timing events and output corresponding timing event data of the identified one or more timing events for the first driver. More specifically, the first driver behavior dataset, the first vehicle behavior dataset, and the first fleet behavior dataset for the first driver and the selected estimated time may be input to the vehicle usage ML model to identify one or more timing events and output timing event data of the identified one or more timing events for the first driver.

[0108] In another embodiment, the first driver may be selected and thus, a first vehicle usage ML model may be selected for a first type of OEM. Timing event data may be generated by entering the selected estimated time and three or more behavior datasets for the first driver as input to the first vehicle usage ML model. To elaborate, one or more timing events may be identified and timing event data may be generated by entering the selected estimated time, the driver behavior dataset, the vehicle behavior dataset, and the fleet behavior dataset for the first driver as input to the first vehicle usage ML model

[0109] The timing event data may include one or more vehicle locations, a location label for each vehicle location, one or more times for each vehicle location, and a duration of each timing event for each location, a connectivity method for a mobile device, and the like. The one or more times may include certain days and / or times. In an example, one or more timing events may occur on weekends. A first timing event may occur at a home of the first driver between the hours of 3 AM and 7:30 AM on a Saturday with the first driver being connected via Wi-Fi and a secondtiming event may occur at the home of the first driver between the hours of 3 AM and 7:30 AM on a Sunday with first driver being connected via Wi-Fi.

[0110] The vehicle usage ML model (e.g., first vehicle usage ML model) may identify the first timing event and may output the following timing event data in response to identifying the first timing event: VIN number of first driver, GPS coordinates, home, Saturday, 3 AM, 7:30 AM, 4.5 hours, Wi-Fi, etc. The vehicle usage ML model may also identify a second timing event and may output the following timing event data in response to identifying the second timing event: VIN number of first driver, GPS coordinates, home, Sunday, 3 AM, 7:30 AM, 4.5 hours, Wi-Fi, etc. Both of the first timing event and the second timing event may be identified by the vehicle usage ML model. The timing event data may be temporarily stored in memory until all of the timing event data that comprises a driver behavior profile dataset for the selected driver is generated for each estimated time before permanently storing the driver behavior profile in memory of the vehicle OTA system and / or the OTA update system allocated for the driver behavior profile dataset.

[0111] At 612, the method 600 includes determining whether there are additional estimated times. In some embodiments, a total number of estimated times may be determined with the software update module before generating the timing event data. Instructions configured, stored, and executed in the vehicle usage module by the processor may cause the processor to determine the number of estimated times of the plurality of estimated times that are input into the vehicle usage ML model (e.g., first vehicle usage model). In this way, the software update module may monitor the number of estimated times that are used to generate the timing event data and the driver behavior profile dataset for the respective driver compared to the total number of estimated times.

[0112] In response to determining there are additional estimated times remaining, the method includes selecting one estimated time from the plurality of estimated times at 608, identifying one or more timing events and generating timing event data for identified one or more timing events with the newly selected estimated time, and sending the timing event data to the driver behavior profile dataset until there are no remaining estimated times. In response to determining there are no remaining times, the method includes storing the driver behavior profile dataset in memory of an OTA update system and memory of a vehicle OTA system at 614. By storing the driver behavior profile dataset in memory of the OTA update system and memory of the vehicle OTAsystem, both of the OTA update system and the vehicle OTA system may be able to identify realtime occurrences of timing events according to the method described in FIG. 5.

[0113] At 616, the method 600 includes determining whether there are additional drivers of the plurality of drivers. In some embodiments, a total number of drivers may be determined with the vehicle usage module before generating the driver behavior profile datasets for each driver. Instructions configured, stored, and executed in the vehicle usage module by the processor may cause the processor to determine the number of drivers of the plurality of drivers. In this way, the vehicle usage module may monitor the number of drivers that are used to generate the driver behavior profile datasets for each respective driver compared to the total number of drivers.

[0114] In response to determining there are additional drivers of the plurality of drivers, the method 600 includes selecting one driver at 606 and selecting one estimated time at a time to generate timing event data that are sent to a driver behavior profile dataset until there are no remaining estimated times and no remaining drivers. Returning to the example from above, the next selected driver may be the second driver followed by the third driver. In this way, a driver behavior profile may be generated for the second driver, the third driver, and any other drivers of the plurality of drivers. In response to determining there are no additional drivers of the plurality of drivers, the method 600 then ends.

[0115] Referring now to FIG. 7, a flowchart is shown of a method 700 for training a vehicle usage model to identify one or more timing events and output timing event data for the identified timing events in order to generate driver behavior profile datasets for a plurality of drivers. As described herein, timing events occur when one driver of a particular vehicle is located at one or more locations at one or more times. More specifically, a timing event occurs when a vehicle is expected to be idle for a duration of time that exceeds a duration of time to finish a particular over- the-air (OTA) software update. The vehicle usage model may be a non-limiting example of the vehicle usage model 312 of the process 300 of FIG. 3, according to an embodiment.

[0116] The vehicle usage model may be one or more artificial intelligence (AI) / machine learning (ML) models. In some embodiments, the vehicle usage ML model may be a single vehicle usage ML model that identifies one or more timing events and outputs timing event data for the identified timing events for all types of OEMS and different vehicle manufacturers. In other embodiments, the vehicle usage ML model may be one of a plurality of vehicle usage ML models.As described herein, each vehicle usage ML model may be trained with vehicle usage training data based on vehicles integrated with one type of OEM or produced by one vehicle manufacturer.

[0117] Method 700 may be executed by a processor of an over-the-air (OTA) update system, such as the OTA update system 102 of FIG. 1. Method 700 may be carried out according to instructions stored in non-transitory memory of the OTA update system (e.g., in a training module such as the training module 110 of the OTA update system 102 of FIG. 1) and executed by a processor of the OTA update system (e.g., the processor 104 of OTA update system 102 of FIG. 3). The vehicle usage ML model may be trained on training data comprising vehicle usage training data for a plurality of drivers operating different vehicles and a plurality of estimated times for downloading and installing an OTA software update. The vehicle usage training data may include timing event training data for one or more timing events, as described below. In some embodiments, the one or more sets of vehicle usage data may be stored in a vehicle usage database of an OTA update system, such as the vehicle usage database 116 of OTA update system 102 of FIG. 1.

[0001] At 702, the method 700 includes receiving an annotated vehicle usage training dataset and a plurality of estimated times, the annotated vehicle usage training dataset being annotated with ground truth timing event data. The annotated vehicle usage training dataset may include generic vehicle training data, vehicle historical training data, driver historical training data, fleet historical training data, environmental training data, OTA operational historical training data, and the like for the plurality of drivers. For example, annotated vehicle usage training data may be obtained from population data obtained from vehicle dealerships and or data collected from various sensors of different vehicle systems. The annotated vehicle usage training dataset may be annotated with one or more timing events for each estimated time of the plurality of estimated times. The annotated vehicle usage training dataset may be stored in a vehicle usage database of an OTA update system (e.g., FIG. 1).

[0002] At 704, the method 700 includes sorting the annotated vehicle usage training dataset into training datasets for each driver. As described above, the annotated vehicle usage training dataset comprises data collected for a plurality of drivers that operate at least one vehicle. For example, the annotated vehicle usage training dataset may be sorted into 10,000 subsets of annotated vehicle usage training data for each driver who operates a certain type of vehicle (e g. model). Each subset of annotated vehicle usage training data includes training data pertaining toone driver who operates one type of vehicle. In one embodiment, each subset of annotated vehicle usage training data may correspond to a different driver. In another embodiment, one or more subsets of annotated vehicle usage training data may correspond to the same driver when that driver operates more than one type of vehicle. In this case, a first subset of annotated vehicle usage training data includes training data when the driver operates a first type of vehicle and a second subset of annotated vehicle usage training data includes training data when the same driver operates a second type of vehicle.

[0118] At 706, the method 700 includes selecting one subset of annotated vehicle usage training data corresponding to one driver and one type of vehicle. Training of the vehicle usage ML model comprises training the vehicle usage model with three or more annotated behavior training datasets. As such, each subset of annotated vehicle usage training data may further be sorted into three or more annotated behavior training datasets based on a type of behavior training data. In particular, each subset of annotated vehicle usage training data may further be sorted to generate behavior training datasets based on driver behavior, vehicle behavior, fleet behavior, and the like. In other embodiments, the subset of annotated driving behavior data may also include environmental data, such as weather conditions and expected Cellular network load across time of day, weekdays, or time of year. In this way, each subset of annotated vehicle usage training data is sorted into three or more annotated behavior training datasets, including an annotated driver behavior training dataset, an annotated vehicle behavior training dataset, and an annotated fleet behavior training dataset, and the like. The annotated driver behavior training dataset includes vehicle usage training data related to vehicle usages of that particular driver. The annotated vehicle behavior training dataset includes vehicle usage related to a specific type of vehicle. The annotated fleet behavior training dataset includes vehicle usage data related to a fleet of vehicles with similar characteristics (e g., EVs that visit charging stations).

[0119] Each subset of annotated vehicle usage training dataset for a driver may have respective annotations wherein each respective annotation includes timing event training data for one or more timing events for each estimated time. The respective annotations may be considered the ground truth annotations. For example, the respective subset of annotated vehicle usage training dataset may be annotated with one or more timing events and corresponding timing event training data wherein the duration of the one or more timing events exceeds that of one estimated time (e g., 70 minutes). The respective subset of annotated vehicle usage training dataset may also be annotatedwith one or more timing events and corresponding timing event training data wherein the duration of the one or more timing events exceeds that of another estimated time (e.g., 90 minutes).

[0120] More specifically, each respective annotation of the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset may also be annotated with one or more timing events and the corresponding timing event training data of the one or more timing events. In this way, the annotated driver behavior training dataset may be annotated with timing event data included specifically in the annotated driver behavior training dataset. Similarly, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and other annotated behavior training datasets may be annotated with timing event included specifically in the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the other annotated behavior training datasets, respectively.

[0121] In particular, the respective subset of annotated vehicle usage training dataset for a particular driver, and thus the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, etc., may be annotated with one or more vehicle locations, a location label for each vehicle location, one or more times for each vehicle location, a connectivity method (e.g., via Wi-Fi or Cellular) of a mobile computing device, a duration of the one or more timing events, and the like for the one or more timing events. In this way, the vehicle usage ML model may be trained to recognize one or more timing events for an estimated time and output timing event data related to the one or more timing events.

[0122] At 708, the method 700 includes selecting one estimated time from the plurality of estimated times. Instructions configured, stored, and executed in memory by a processor may cause the processor to randomly select one estimated time from the plurality of estimated times. At 710, the method 700 includes inputting the selected set of annotated vehicle usage training data and the selected estimated time into the vehicle usage ML model. The respective vehicle usage model ML model may be either a single vehicle usage ML model or one vehicle usage ML model of the plurality of vehicle usage ML models, each of the plurality of vehicle usage ML models corresponding to either one type of OEM or one vehicle manufacturer.

[0123] As described above, the selected subset of annotated vehicle usage training data was sorted into the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the like for each driver. Accordingly,the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the selected estimated time may be entered as input to the vehicle usage ML model. As described herein, the vehicle usage ML model may be a single vehicle usage ML model that identifies one or more timing events and outputs timing event data for the one or more timing events for various OEMs and vehicles produced by different vehicle manufacturers. The vehicle usage ML model may alternatively be one model of the plurality of vehicle usage ML models where each of the vehicle usage ML models is trained on annotated vehicle usage training data for either a specific type of OEM or vehicles produced by a particular vehicle manufacturer.

[0124] As an example, a first vehicle usage ML model may correspond to drivers that may operate a vehicle manufactured by Ford, a second vehicle usage ML model correspond to drivers that may operate a vehicle manufactured by Subaru, and a third vehicle usage ML model may correspond to drivers that may operate a vehicle manufactured by Kia. If the selected subset of annotated vehicle usage training data corresponds to a driver operating a Ford vehicle, the subset of annotated vehicle usage training dataset, including the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the like, and the selected estimated time is entered as input to the first vehicle usage ML model. Similarly, if the selected subset of annotated vehicle usage training data corresponds to the driver operating a Subaru vehicle, the annotated vehicle usage raining dataset, including the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the like, and the selected estimated time is entered as input to the second vehicle usage ML model.

[0125] At 712, the method 700 includes receiving timing event data from the respective vehicle usage ML model. The vehicle usage model ML may output timing event data for one or more identified timing events included in the respective subset of annotated vehicle behavior training dataset, and more particularly, in the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset, and the like.

[0126] At 714, the method 700 includes comparing the ground truth timing event data and output timing event data and adjusting model parameters of the vehicle usage ML model. More specifically, the ground truth timing event data of the subset of annotated driver behavior training dataset may be compared with the timing event data output from the vehicle usage ML model. Inan example, a loss function of the respective vehicle usage ML model may be determined based on the ground truth timing event data of the subset of the annotated vehicle usage training dataset, including the annotated driver behavior training dataset, the annotated fleet behavior training dataset, the annotated fleet behavior training dataset, and output timing event data. As such, the loss function of the respective vehicle usage ML model may be used to update the parameters of the vehicle usage ML model.

[0127] At 716, the method 700 includes determining whether additional estimated times remain in the plurality of estimated times. The plurality of estimated times may include a pre-determined number of estimated times. If less than all of the pre-determined number of estimated times have been selected and used to train the respective vehicle usage ML model (e.g., at least some estimated times remain), or if the respective vehicle usage ML model is otherwise determined to not be fully trained, method 700 returns to 708 to select a next estimated time and use the next estimated time to train the respective vehicle usage ML model. However, if at 716 it is determined that each estimated time has been selected and used to train the respective vehicle usage ML model (and no more estimated times remain), or if the respective vehicle usage ML model is otherwise determined to be fully trained, method 700 proceeds to 718, which includes determining whether additional subsets of annotated vehicle usage training data remain.

[0128] The plurality of subsets of annotated vehicle usage training data may include a predetermined number of subsets of annotated vehicle usage training data. If less than all of the predetermined number of subsets have been selected and used to train the respective vehicle usage ML model (e.g., at least some subsets remain), or if the respective vehicle usage ML model is otherwise determined to not be fully trained, method 700 returns to 706 to select a next subset and use the next subset to train the vehicle usage ML model. However, if at 718 it is determined that each subset has been selected and used to train the vehicle usage ML model (and no more subsets remain), or if the respective vehicle usage ML model are otherwise determined to be fully trained, the method 700 then returns.

[0129] In some embodiments, the vehicle usage ML model or the plurality of vehicle usage ML models may be periodically trained on new timing event data acquired via the vehicle systems. In this way, the driver behavior profde datasets may re-generated for each driver as new timing event data for each driver is obtained.

[0130] As illustrated in FIG. 8A, FIG. 8B, and FIG. 8C, pictorial diagrams on time scales 800, 801, 802 for performing download and installation of an over-the-air (OTA) software update in response to user input received. In particular, FIG. 8A illustrates a first scenario wherein the vehicle OTA system and / or OTA update system does not identify a timing event. FIG. 8B illustrates a second scenario wherein the OTA update system identifies a timing event but the OTA software update is not installed. FIG. 8C illustrates a third scenario in the

[0131] At tl, the time scales 800, 801, and 802 include the vehicle OTA system, which may be an embodiment of the vehicle OTA system 205 of FIG. 2, receiving a notification from the OTA update system that an OTA software update campaign is available in FIG. 8A, FIG. 8B, and FIG. 8C. The notification may be sent in response to the vehicle OTA update system performing an OTA software update query. At t2, the time scales 800, 801, and 802 include the in-vehicle computing system receiving vehicle data indicating that the vehicle is idle and thus, that a realtime timing event may be occurring in FIG. 8 A, 8B, and 8C. The method described in FIG. 6 may determine whether a real-time timing event occurred.

[0132] Turning to FIG. 8A, at t3, the time scale 800 includes the driver behavior profile data not matching the real-time timing event data. As described herein, the driver behavior profile data may not match the real-time timing event data when the vehicle locations do not match, the driver identities do no match, the current time is not within a time range between the start time and end time of the timing event, and / or the estimated time exceeds the duration of the timing event. At t4, the time scale 800 includes the OTA update system not sending a download confirmation notification or an installation confirmation notification.

[0133] As shown in FIGS. 8B and 8C, at t3, the time scales 801, 802 includes the driver behavior profile data matching the real-time timing event data. As described herein, the driver behavior profile data may match the real-time timing event data when the vehicle locations do not match, the driver identities match, the current time is within a time range between the start time and end time of the timing event, and / or the estimated time does not exceed the duration of the timing event.

[0134] In response to a timing event being identified, the time scales 801, 802 include the OTA update system sending a download confirmation notification to a mobile device of the driver at t4. The download confirmation notification is configured to receive user input that may cause the OTA software update to be accepted, rejected, or postponed. At t5, the time scales 801, 802 include the vehicle driver accepting the download confirmation notification and the softwareupdate being downloaded by the vehicle OTA system. Responsive to the download confirmation notification being accepted, the time scales 801, 802 include the OTA update system sending a download confirmation notification to the mobile device of the driver at t6. Similarly, the installation confirmation notification is configured to receive user input that may cause the OTA software update to be accepted, rejected, or postponed.

[0135] In FIG. 8B, at t7, the time scale 801 includes the vehicle driver rejecting or postponing the installation confirmation notification and the OTA software update not being installed. Another installation confirmation notification may be sent in response to a next occurrence of a timing event after the initial installation confirmation notification is rejected or accepted. Returning to FIG. 8C, at t7, the time scale 802 includes the vehicle driver accepting the installation confirmation notification and the OTA software update is installed via the vehicle OTA system.

[0136] The technical effect of sending download confirmation notifications and installation confirmation notifications for an over-the-air (OTA) software update for a vehicle in response to identifying an occurrence of a timing event based on a driver behavior profile dataset generated from output from a vehicle usage model trained is that the OTA software update is more likely to be performed, which may increase the performance of the targeted vehicle systems of the vehicle, and at fleet level, improve the overall portion of vehicles which are up to date, with latest software.

[0137] The disclosure also provides support for a method, comprising: sending a download confirmation notification and an installation confirmation notification for an over-the-air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in realtime, the timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model, downloading the OTA software update in response to a download confirmation being accepted, and installing the OTA software update in response to an installation confirmation being accepted. In a first example of the method, the vehicle usage model identifies one or more timing events and outputs timing event data for the one or more timing events wherein a frequency of a particular driver accepting the download confirmation and installation confirmation is increased.

[0138] In a second example of the method, optionally including the first example, timing data includes a driver identity, a plurality of locations, a location label for each location, one or more times for each location, a connectivity method of a mobile computing device when download confirmation notification and installation confirmation notifications are received, and a durationof the timing event, and the like. In a third example of the method, optionally including one or both of the first and second examples, that vehicle usage model is a single vehicle usage model that identifies one or more timing events and generates timing event data for a plurality of drivers operating vehicles produced by different vehicle manufacturer and integrated with different OEMs.

[0139] In a fourth example of the method, optionally including one or more or each of the first through third examples, the vehicle usage model is one vehicle usage model of a plurality of vehicle usage models that identifies one or more timing events and generates timing event data for a plurality of drivers operating vehicles that integrate one type of OEM. In a fifth example of the method, optionally including one or more or each of the first through fourth examples, the vehicle usage model is one vehicle usage model of a plurality of vehicle usage models that identifies timing events and generates timing event data for a plurality of drivers operating vehicles produced by one vehicle manufacturer.

[0140] The disclosure also provides support for an over-the-air (OTA) update system, comprising: a processor, and a non-transitory memory including instructions that when executed cause the processor to: send a download confirmation notification and an installation confirmation notification for an over-the-air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in real-time, the timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model, download the OTA software update in response to a download confirmation being accepted, and install the OTA software update in response to an installation confirmation being accepted. In a first example of the system, the vehicle OTA system of a vehicle is communicatively coupled to the OTA update system to perform OTA software update queries, to receive OTA download confirmation notifications, receive OTA installation confirmation notifications, and receive one or more driver profile datasets from the OTA update system.

[0141] In a second example of the system, optionally including the first example, one or more driver profile behavior datasets are stored in memory of the OTA update system and in memory of the vehicle OTA system. In a third example of the system, optionally including one or both of the first and second examples, download confirmation notifications and installation confirmation notifications are sent to a mobile computing device via the vehicle OTA system and / or the OTA update system. In a fourth example of the system, optionally including one or more or each of thefirst through third examples, download confirmation notifications and installation confirmation notifications are sent are sent to an interface of an in-vehicle computing system.

[0142] The disclosure also provides support for a method, comprising: creating an OTA software update campaign via an OTA update system, sending a notification of the OTA software update campaign to a vehicle OTA system in response to an OTA software update query performed by the vehicle OTA system, downloading an OTA software update via the vehicle OTA system in response to a real-time timing event occurrence identified using a driver behavior profile dataset generated by a vehicle usage ML model, and installing the OTA software update via the vehicle OTa system in response to real-time timing event occurrence identified using the driver behavior profile dataset. In a first example of the method, downloading the OTA software update via the vehicle OTA system in response to the real-time timing event occurrence identified using the driver behavior profile dataset generated by the vehicle usage ML model optionally comprises: sending a download confirmation notification to a vehicle driver via the OTA update system in response to the real-time timing event occurrence via the OTA update system, and receiving user input that causes a download confirmation to be accepted.

[0143] In a second example of the method, optionally including the first example, installing the OTA software update via the vehicle OTA system in response to real-time timing event occurrence identified by the vehicle usage ML model optionally comprises: sending an installation confirmation notification to a vehicle driver via the OTA update system in response to the realtime timing event occurrence via the OTA update system, and receiving user input that causes an installation confirmation to be accepted. In a third example of the method, optionally including one or both of the first and second examples, identifying the real-time timing event occurrence comprises in response to receiving vehicle data that indicates a vehicle is idle and receiving an estimated time for the OTA software update, comparing real-time timing event data with the driver behavior profile dataset stored in memory.

[0144] In a fourth example of the method, optionally including one or more or each of the first through third examples, generating one or more driver behavior profile datasets with a plurality of vehicle usage ML models comprises: receiving a plurality of estimated times for various OTA software updates and vehicle usage data of a plurality of drivers, for each driver, sorting relevant vehicle usage data into three behavior datasets, the three behavior datasets including a driver behavior dataset, a vehicle behavior dataset, and a fleet behavior dataset, and for each driver,selecting a driver from the plurality of drivers. In a fifth example of the method, optionally including one or more or each of the first through fourth examples, the method further comprises: for each estimated time, selecting one estimated time from the plurality of estimated times, generating the driver behavior profile dataset for the selected driver by inputting the selected estimated time and a subset of a vehicle usage dataset into the vehicle usage ML model, and storing a driver behavior profile dataset behavior in memory of the OTA update system and memory of the vehicle OTA system.

[0145] In a sixth example of the method, optionally including one or more or each of the first through fifth examples, training of the vehicle usage ML model comprises training the vehicle usage ML model with three or more annotated behavior training datasets. In a seventh example of the method, optionally including one or more or each of the first through sixth examples, the three or more annotated behavior training datasets include an annotated driver behavior training dataset, an annotated vehicle behavior training dataset, an annotated fleet behavior training dataset, and the like. In an eighth example of the method, optionally including one or more or each of the first through seventh examples, each respective annotation of the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset being annotated with one or more timing events and timing event training data of the one or more timing events.

[0146] The description of embodiments has been presented for purposes of illustration and description. Suitable modifications and variations to the embodiments may be performed in light of the above description or may be acquired from practicing the methods. The methods may be performed by executing stored instructions with one or more logic devices (e.g., processors) in combination with one or more additional hardware elements, such as storage devices, memory, image sensors / lens systems, light sensors, hardware network interfaces / antennas, switches, actuators, clock circuits, etc. The described methods and associated actions may also be performed in various orders in addition to the order described in this application, in parallel, and / or simultaneously. Further, the described methods may be repeatedly performed. The described systems are exemplary in nature, and may include additional elements and / or omit elements. The subject matter of the present disclosure includes all novel and non-obvious combinations and subcombinations of the various systems and configurations, and other features, functions, and / or properties disclosed.

[0147] As used in this application, an element or step recited in the singular and proceeded with the word “a” or “an” should be understood as not excluding plural of said elements or steps, unless such exclusion is stated. Furthermore, references to “one embodiment” or “one example” of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. The terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements or a particular positional order on their objects. The following claims particularly point out subject matter from the above disclosure that is regarded as novel and non-obvious.

Claims

CLAIMS:

1. A method, comprising: sending a download confirmation notification and an installation confirmation notification for an over-the-air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in real-time, the timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model; downloading the OTA software update in response to a download confirmation being accepted; and installing the OTA software update in response to an installation confirmation being accepted.

2. The method of claim 1, wherein the vehicle usage model identifies one or more timing events and outputs timing event data for the one or more timing events wherein a frequency of a particular driver accepting the download confirmation and installation confirmation is increased.

3. The method of claim 2, wherein timing data includes a driver identity, a plurality of locations, a location label for each location, one or more times for each location, a connectivity method of a mobile computing device when download confirmation notification and installation confirmation notifications are received, and a duration of the timing event, and the like.

4. The method of claim 1, wherein that vehicle usage model is a single vehicle usage model that identifies one or more timing events and generates timing event data for a plurality of drivers operating vehicles produced by different vehicle manufacturer and integrated with different OEMs.

5. The method of claim 1, wherein the vehicle usage model is one vehicle usage model of a plurality of vehicle usage models that identifies one or more timing events and generates timing event data for a plurality of drivers operating vehicles that integrate one type of OEM.

6. The method of claim 1, wherein the vehicle usage model is one vehicle usage model of a plurality of vehicle usage models that identifies timing events and generates timing event data for a plurality of drivers operating vehicles produced by one vehicle manufacturer.

7. An over-the-air (OTA) update system, comprising: a processor; and a non-transitory memory including instructions that when executed cause the processor to: send a download confirmation notification and an installation confirmation notification for an over-the-air (OTA) software update to a vehicle OTA system in response to an occurrence of a timing event in real-time, the timing event being one driver of a particular vehicle being located at one or more locations at one or more times and identified based on output from a vehicle usage model; download the OTA software update in response to a download confirmation being accepted; and install the OTA software update in response to an installation confirmation being accepted.

8. The system of claim 7, wherein the vehicle OTA system of a vehicle is communicatively coupled to the OTA update system to perform OTA software update queries, to receive OTA download confirmation notifications, receive OTA installation confirmation notifications, and receive one or more driver profile datasets from the OTA update system.

9. The system of claim 8, wherein one or more driver profile behavior datasets are stored in memory of the OTA update system and in memory of the vehicle OTA system.

10. The system of claim 7, wherein download confirmation notifications and installation confirmation notifications are sent to a mobile computing device via the vehicle OTA system and / or the OTA update system11. The system of claim 7, wherein download confirmation notifications and installation confirmation notifications are sent are sent to an interface of an in-vehicle computing system.

12. A method, comprising: creating an OTA software update campaign via an OTA update system; sending a notification of the OTA software update campaign to a vehicle OTA system in response to an OTA software update query performed by the vehicle OTA system; downloading an OTA software update via the vehicle OTA system in response to a realtime timing event occurrence identified using a driver behavior profile dataset generated by a vehicle usage ML model; and installing the OTA software update via the vehicle OTA system in response to real-time timing event occurrence identified using the driver behavior profile dataset.

13. The method of claim 12, wherein downloading the OTA software update via the vehicle OTA system in response to the real-time timing event occurrence identified using the driver behavior profile dataset generated by the vehicle usage ML model optionally comprises: sending a download confirmation notification to a vehicle driver via the OTA update system in response to the real-time timing event occurrence via the OTA update system; and receiving user input that causes a download confirmation to be accepted.

14. The method of claim 12, wherein installing the OTA software update via the vehicle OTA system in response to real-time timing event occurrence identified by the vehicle usage ML model optionally comprises: sending an installation confirmation notification to a vehicle driver via the OTA update system in response to the real-time timing event occurrence via the OTA update system; and receiving user input that causes an installation confirmation to be accepted.

15. The method of claim 12, wherein identifying the real-time timing event occurrence comprises in response to receiving vehicle data that indicates a vehicle is idle and receiving an estimated time for the OTA software update, comparing real-time timing event data with the driver behavior profile dataset stored in memory.

16. The method of claim 12, wherein generating one or more driver behavior profile datasets with a plurality of vehicle usage ML models comprises: receiving a plurality of estimated times for various OTA software updates and vehicle usage data of a plurality of drivers; for each driver, sorting relevant vehicle usage data into three behavior datasets, the three behavior datasets including a driver behavior dataset, a vehicle behavior dataset, and a fleet behavior dataset; and for each driver, selecting a driver from the plurality of drivers.

17. The method of claim 16, further comprising: for each estimated time, selecting one estimated time from the plurality of estimated times; generating the driver behavior profile dataset for the selected driver by inputting the selected estimated time and a subset of a vehicle usage dataset into the vehicle usage ML model; and storing a driver behavior profile dataset behavior in memory of the OTA update system and memory of the vehicle OTA system.

18. The method of claim 12, wherein training of the vehicle usage ML model comprises training the vehicle usage ML model with three or more annotated behavior training datasets.

19. The method of claim 18, wherein the three or more annotated behavior training datasets include an annotated driver behavior training dataset, an annotated vehicle behavior training dataset, an annotated fleet behavior training dataset, and the like.

20. The method of claim 19, wherein each respective annotation of the annotated driver behavior training dataset, the annotated vehicle behavior training dataset, the annotated fleet behavior training dataset being annotated with one or more timing events and timing event training data of the one or more timing events.

Images