阅读说明：本技术 手机即钥匙预测性车辆访问 (Mobile phone-key predictive vehicle access ) 是由 小蒂莫西·西维尔奇 福阿德·布内菲萨 贾拉勒·贾瓦尼 约亨·舒伯特 于 2020-10-09 设计创作，主要内容包括：本公开提供了“手机即钥匙预测性车辆访问”。一种计算机实现的方法包括经由预测性分析模型预测与车辆的未来接通事件相关联的时间间隔。所述预测性分析模型是至少部分地基于接通事件数据。所述方法包括：至少部分地基于所述预测的时间间隔来生成功率模式指令,所述功率模式指令被配置成致使车辆远程信息处理控制单元(TCU)或电话即钥匙(PaaK)系统将TCU状态从低能量状态改变为较高能量状态；以及基于所述预测的时间间隔来将所述功率模式指令传输到所述车辆TCU。(The present disclosure provides "mobile phone, i.e., key, predictive vehicle access". A computer-implemented method includes predicting, via a predictive analytics model, a time interval associated with a future key-on event of a vehicle. The predictive analytics model is based at least in part on turn-on event data. The method comprises the following steps: generating a power mode instruction based at least in part on the predicted time interval, the power mode instruction configured to cause a vehicle Telematics Control Unit (TCU) or a telephone-to-key (PaaK) system to change a TCU state from a low energy state to a higher energy state; and transmitting the power mode command to the vehicle TCU based on the predicted time interval.)

1. A computer-implemented method, comprising:

determining, via a predictive analytics model, a predicted time interval associated with a future turn-on event of a vehicle, wherein the predictive analytics model is based at least in part on turn-on event data;

determining a power mode instruction based at least in part on the predicted time interval, the power mode instruction configured to change a vehicle power state from a low energy state to a higher energy state; and

transmitting the power mode command to the vehicle based on the predicted time interval.

2. The computer-implemented method of claim 1, wherein changing the vehicle power state comprises causing a vehicle Telematics Control Unit (TCU) to change the vehicle power state from the low energy state to the higher energy state.

3. The computer-implemented method of claim 1, wherein changing the vehicle power state comprises causing a cell phone-key (PaaK) system to change the vehicle power state from the low energy state to the higher energy state.

4. The computer-implemented method of claim 1, wherein changing the vehicle power state comprises causing a cell phone-and-key (PaaK) system to change the PaaK system from the low energy state to the higher energy state.

5. The computer-implemented method of claim 1, wherein changing the vehicle power state comprises causing a cell phone-as-a-key (PaaK) system to change a vehicle Telematics Control Unit (TCU) from the low energy state to the higher energy state.

6. The computer-implemented method of claim 1, wherein changing the vehicle power state comprises causing a vehicle Telematics Control Unit (TCU) to change the vehicle TCU from the low energy state to the higher energy state.

7. The computer-implemented method of claim 1, wherein the turn-on event data comprises time information and date information associated with one or more of: unlocking the vehicle, actuating a door latch mechanism, opening a door, starting a motor, performing remote start/climate control, or indicating a user's intent to access or operate a vehicle function of the vehicle.

8. The computer-implemented method of claim 1, wherein the turn-on event data comprises Global Positioning Service (GPS) information indicative of a GPS location of one or more of the vehicle and a mobile device associated with the vehicle.

9. The computer-implemented method of claim 1, wherein the turn-on event data comprises key fob information associated with a key fob for performing one or more of: unlocking the vehicle, starting a motor, performing remote start/climate control, or indicating a user's intent to access or operate a vehicle function of the vehicle.

10. The computer-implemented method of claim 1, wherein the turn-on event data comprises user-level data associated with a user of the vehicle.

11. The computer-implemented method of claim 1, the computer-implemented method further comprising:

receiving, from one or more of a vehicle Telematics Control Unit (TCU) and a mobile device associated with the vehicle, the turn-on event data indicative of a plurality of turn-on events; and

generating the predictive analytics model based on the turn-on event data indicative of the plurality of turn-on events.

12. The computer-implemented method of claim 11, wherein the turn-on event data comprises fleet level data associated with vehicles in a plurality of fleets of vehicles; and is

Automatically grouping vehicles into the plurality of vehicle fleets based on vehicle make, model, first order approximate geographic location, trim level, or feature level.

13. The computer-implemented method of claim 1, wherein transmitting the power mode instruction comprises transmitting a wireless signal to a Bluetooth Low Energy (BLE) module associated with the vehicle, wherein the power mode instruction changes the vehicle power state from the low energy state to the higher energy state based at least in part on the predicted time interval.

14. The computer-implemented method of claim 1, further comprising transmitting the predictive analytics model to a mobile device.

15. The computer-implemented method of claim 14, wherein the mobile device is configured to determine the predicted time interval associated with the future turn-on event of the vehicle and transmit the power mode instruction to the vehicle.

Technical Field

The present disclosure relates to a cell phone or key (PaaK) system for a vehicle, and more particularly, to reducing latency associated with the PaaK system.

Background

The cellular or key (PaaK) system employs a personal area network (e.g.,low power consumption (BLE), etc.) to detect and locate a mobile phone without requiring a dedicated antenna and controller to communicate at other frequencies (e.g., 125kHz, 315MHz, etc.). To extend the key-off time before the vehicle's battery is depleted, PaaK system enabled vehicles may cycle from a low power mode after a long period of parking to a higher power mode when the user actuates the door handle or performs another action to "wake up" the vehicle. Such a transition in vehicle power state may maximize availability and minimize energy usage. However, due to the time delay required to actuate the PaaK system to authenticate an approaching mobile device, conventional PaaK systems may not immediately actuate the vehicle (by switching the vehicle from a low power state to a higher power state) based on a user's request (e.g., sending an unlock door signal to a door unlock mechanism when a handle on the vehicle door is pulled). This is typically caused by the time delay required to power up the authentication processor, determine if the action and/or device associated with the wake-up action is authentic and valid, and to send a control signal for actuating the desired vehicle lock, latch, etc.

The use of a mobile device, i.e. a key, is disclosed in european patent publication No. EP2672739 (hereinafter the' 739 publication), assigned to Apple, Inc. The' 739 publication discloses using the mobile device and vehicle location for door unlock command decisions by "warm up" as the mobile device approaches the vehicle location. The' 739 publication relies only on mobile device location and does not disclose a predicted time interval for sending messages to transition the vehicle from a low power state to a higher power (operating) mode, nor does it take into account the latency issues associated with conventional PaaK authentication.

Disclosure of Invention

A computer-implemented method includes predicting, via a predictive analytics model, a time interval associated with a future key-on event of a vehicle. The predictive analytics model is based at least in part on turn-on event data. The method comprises the following steps: generating a power mode instruction based at least in part on the predicted time interval, the power mode instruction configured to cause a vehicle Telematics Control Unit (TCU) or a telephone-to-key (PaaK) system to change a TCU state from a low energy state to a higher energy state; and transmitting the power mode command to the vehicle TCU based on the predicted time interval.

Drawings

Specific embodiments are described with reference to the accompanying drawings. The use of the same reference numbers may indicate similar or identical items. Various embodiments may utilize elements and/or components other than those shown in the figures, and some elements and/or components may not be present in various embodiments. Elements and/or components in the drawings have not necessarily been drawn to scale. Throughout this disclosure, depending on the context, singular and plural terms may be used interchangeably.

FIG. 1 illustrates an example computing environment in which techniques and structures for providing the systems and methods disclosed herein may be implemented.

Fig. 2A illustrates an example embodiment of the present disclosure, where a predictive model operates from a mobile device to control power mode transitions according to embodiments described herein.

Fig. 2B illustrates another example embodiment of the present disclosure, where a predictive model operates from a remote server to control power mode transitions according to embodiments described herein.

FIG. 3 illustrates another example embodiment of the present disclosure in which an automotive computer includes a predictive model to control power mode transitions according to embodiments described herein.

FIG. 4 illustrates a block diagram of an example computer system for practicing embodiments described herein.

Fig. 5 is a flow chart of an example method according to the present disclosure.

Detailed Description

Overview

The systems and methods disclosed herein may provide a computing platform on servers, mobile devices, and/or PaaK-enabled vehicles that may reduce the latency associated with conventional PaaK vehicle actuations. The server or mobile device may send a message to the vehicle at a predetermined time to direct the handset, i.e., key system, on the vehicle to exit the low power, high latency mode and enter a higher power, low latency mode. These messages may be communicated via different means depending on the current location and/or state of the vehicle. These communication paths may include directly through a Telematics Control Unit (TCU) on the vehicle (via a telecommunications network or Wi-Fi) or through a connected mobile device (via a telecommunications network or Wi-Fi)Wi-Fi or other Radio Frequency (RF) device).

The schedule of these messages is constructed by analyzing the vehicle usage patterns via a predictive analysis model. By collecting turn-on time information and vehicle location data, the systems described herein can predict when a user is more likely to use the vehicle (e.g., commute to work in the morning on a weekday, or drive to a gym in a particular time frame in the evening). Additionally, the system may track date and time information and location at times indicating high latency, such as when a vehicle user cannot unlock the vehicle on a first attempt. These patterns may be unique to each vehicle and user, or an aggregated pattern from many vehicles and users collected into various groupings may be used and may be continually updated by the server as the server collects turn-on event information over time. For example, fleet vehicles may be automatically grouped into a fleet of vehicles, where the grouping is based on any combination of vehicle make, vehicle model, first approximate geographic location, vehicle trim level, and/or vehicle feature level.

Embodiments described herein may also utilize vehicle location information to improve the accuracy of the prediction. In one aspectThe predictive analytics model may predict a time interval associated with a future turn-on event of the vehicle. The predictive analytics model may be based, at least in part, on turn-on event data associated with vehicles and/or fleet vehicles configured to share such information. For example, if the vehicle is at the customer's home, the system may generate a prediction with a relatively high probability: the customer will commute to work on weekdays in the morning. If the vehicle is located elsewhere due to a vacation trip, the analysis system may selectively apply the surrogate predictive model based at least in part on the vehicle location, trajectory, date information, time information, and the like. Wi-Fi and/or by tracking nearby scans through a satellite positioning system (e.g., GPS)The network looks for the source of the location information.

The pre-scheduled wake-up messages sent from one or more centralized (cloud or other type-based) servers or connected mobile devices may provide vehicle intelligence that proactively determines when a low-power mode is unlikely to be acceptable, and when a higher-power mode is most likely to help reduce and/or eliminate vehicle entry and lag time in operation. Further, embodiments of the present disclosure may centrally manage (from a cloud-based server) how the predictive analytics system is built and sent to the vehicle, allowing for centralized control of the updatability and safety features of the vehicle receiving the predictive analytics model to be maintained. These and other advantages of the present disclosure are provided in greater detail herein.

Illustrative embodiments

The present disclosure now will be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments of the disclosure are shown, and which are not intended to be limiting.

FIG. 1 illustrates an example computing environment 100 that may include a vehicle 105, one or more servers 170, and a mobile device 120. The mobile device 120 may be communicatively coupled with the vehicle 105 and/or the server 170 via one or more networks 125, which may use one or more wireless channels 130 to transmit data. The mobile device 120 may include and/or be configured to execute one or more applications 135. The application may perform information retrieval steps that provide information to server 170 that may be used to generate predictive analytics models (e.g., predictive analytics model 205) described herein for authenticating user 140 of vehicle 105, for authenticating mobile device 120 on which application 135 may operate, and for providing control instructions to vehicle 105 as described according to embodiments herein.

The vehicle 105 may include an automotive computer 145, which may include one or more processors 150 and memory 155. The vehicle 105 may also include a vehicle TCU160, which may be disposed in communication with and/or as part of the automotive computer 145. In some example embodiments, the vehicle TCU160 may communicate information to and receive communications from the mobile device 120 and/or one or more servers 170, which may be associated with and/or include a telematics Service Delivery Network (SDN) (not shown in fig. 1). The vehicle 105 may also receive and/or be positioned to communicate with a Global Positioning System (GPS) 175.

Although shown as a sport utility truck, vehicle 105 may also take the form of any passenger or commercial vehicle, such as an automobile, truck, cross-over vehicle, van, mini-van, taxi, bus, work vehicle, or the like. Additionally, the vehicle 105 may be a manually driven vehicle, and/or configured to operate in a fully autonomous (e.g., unmanned) mode and/or a partially autonomous mode, and may include any powertrain system, such as a gasoline engine, one or more electrically actuated motors, a hybrid powertrain system, or the like.

According to an example embodiment, the user 140 may control one or more applications 135 operating on the mobile device 120 to communicate a wake-up message to the vehicle TCU 160. The wake-up message, which may be and/or include power mode instructions that control the TCU and/or the automotive computer 145, may be based at least in part on a predicted time interval associated with a future turn-on event of the vehicle 105. The predicted time interval may include a time or time range during which the user 140 may want to unlock and/or operate the vehicle 105.

In some aspects, the mobile device 120 may communicate with the vehicle 105 over one or more wireless channels 130, which may be encrypted or decrypted, and established between the mobile device 120 and the vehicle TCU 160. The mobile device 120 may communicate with the vehicle TCU160 on the vehicle 105 using a wireless transmitter (not shown in fig. 1) associated with the vehicle TCU 160. The transmitter may communicate with the mobile device 120 using a wireless communication network, such as one or more networks 125.

One or more networks 125 illustrate one example of a communication infrastructure in which connected devices illustrated in the computing environment 100 may communicate. One or more networks 125 may be and/or include the internet, private networks, public networks, or other configurations that operate using any one or more known communication protocols, such as transmission control protocol/internet protocol (TCP/IP),Low power consumption (BLE), Wi-Fi, and one or more cellular network technologies such as Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), high speed packet access (HSPDA), Long Term Evolution (LTE), global system for mobile communications (GSM), and fifth generation (5G), to name a few.

The vehicle TCU160 may provide communication with and control access to a plurality of vehicle computing modules, such as a Controller Area Network (CAN) bus 180, one or more Engine Control Modules (ECMs) 185, a Transmission Control Module (TCM)190, and/or a Body Control Module (BCM) 195. Control of and/or communication with other control modules not shown is possible and such control is contemplated. In some aspects, the vehicle TCU160 may control aspects of the vehicle 105 through the control modules 180-195 and implement one or more sets of instructions received from the application programs 135 operating on the mobile device 120.

The automotive computer 145 can include one or more processors 150 and computer-readable memory 155. According to the present disclosure, the automotive computer 145 may be installed in the engine compartment of the vehicle 105 (or elsewhere in the vehicle 105) as part of the PaaK system. In one example, the automotive computer 145 can include one or more processors 150 and computer-readable memory 155. In other example embodiments, the vehicle TCU160 may be integrated and/or integrated with the automotive computer 145. For simplicity, the computing system architecture of the automotive computer 145 may omit certain computing modules. It should be readily understood that the computing environment 100 shown in fig. 1 is one example of possible implementations in accordance with the present disclosure, and thus should not be viewed as limiting or exclusive.

The one or more processors 150 may be disposed in communication with one or more memory devices, such as the memory 155 and/or one or more external databases (not shown in fig. 1). The one or more processors 150 may utilize the memory 155 to store programs in the form of code and/or store data to perform aspects of the present disclosure, such as predicting a time interval associated with a turn-on event of the vehicle 105, generating power mode instructions configured to cause the vehicle TCU160 to change a TCU state from a low energy state to a higher energy state, and/or transmitting the power mode instructions to the vehicle TCU160 based at least in part on the predicted time interval.

The memory 155 may be a non-transitory computer readable memory. The processor 150 may be configured to execute computer-executable instructions stored in the memory 155 for performing the various functions of the PaaK system and for performing vehicle control capabilities according to the present disclosure. Accordingly, the memory 155 may be used to store code and/or data codes and/or data to perform operations in accordance with the present disclosure. The memory 155 may include any one or combination of volatile memory elements (e.g., Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), etc.) and may include any one or more non-volatile memory elements (e.g., Erasable Programmable Read Only Memory (EPROM), flash memory, Electrically Erasable Programmable Read Only Memory (EEPROM), Programmable Read Only Memory (PROM), etc.).

The memory 155 may be one example of a non-transitory computer-readable medium and may be used to store programs in the form of codes and/or data to perform various operations according to the present disclosure. The instructions in memory 155 may comprise one or more separate programs, each of which may comprise an ordered listing of computer-executable instructions for implementing logical functions. In another example implementation, some or all of the components of the automotive computer 145 may be shared with the vehicle TCU 160.

The memory 155 may store various code modules, such as a secure communication controller (not shown in fig. 1), for establishing one or more wireless channels 130 between the mobile device 120, the vehicle TCU160, and/or the car computer 145. Memory 155 may also receive one or more sets of instructions including predictive analytics model 205, which may be generated by and received from one or more servers 170.

Server 170 may be and/or include one or more cloud-computing mainframe computing platforms configured to receive PaaK and key fob usage data 200 (hereinafter "usage data 200") from vehicles 105 and/or other vehicles in a vehicle fleet (not shown in fig. 1). Fig. 4 (discussed in more detail below) depicts a computing system 400 that may be significantly similar and/or identical to server 170. Although described in this section with respect to user 140 and vehicle 105, it should be appreciated that usage data 200 may include and/or be associated with usage data from any number of users, vehicles, etc. For example, in one aspect, server 170 may also include and/or be positioned to communicate with a telematics SDN (not shown in fig. 1) that communicates with TCUs associated with other vehicles in the vehicle fleet.

In one example embodiment, the vehicle 105 (and more specifically, the vehicle TCU 160) may transmit the usage data 200 to the server 170 at predetermined time intervals during a daily vehicle usage process. For example, the usage data 200 may be transmitted by the TCU and/or received by the server 170 at periodic intervals (one hour, one day, one week, etc.). Usage data 200 may include date information and time information associated with the time at which user 140 has approached vehicle 105, unlocked vehicle 105, operated vehicle 105, and the like. These events are collectively referred to herein as turn-on events, and the date, time, and other information is referred to herein as turn-on event data 215.

In one embodiment, the server 170 may store the turn-on event data 215 as part of the predictive analytics system 210. In an exemplary embodiment, the server 170 may include and/or operate a predictive analytics system 210 that may be configured and/or programmed to receive, store, and process turn-on event data 215, GPS data 220, usage data 200, and other information associated with the user 140 and/or fleet vehicles associated with the server 170.

In one embodiment, the key fob usage data 225 may include information associated with a key fob 235 that is paired with the vehicle 105 and configured to control operational aspects of the vehicle. For example, key fobs are commonly used to control locking, unlocking, arming/disarming, light control, activation, and the like. Thus, the fob usage data 225 may include a fob identifier (not shown in fig. 1) that uniquely associates the fob 235 with the user 140, the vehicle 105, the vehicle TCU160, and/or the mobile device 120. In some aspects, the key fob usage data 225 may also include frequency information, signal strength information, time information, date information, GPS data, and/or other information that may be associated with determining a pattern associated with usage of the user 140 and the vehicle 105.

According to another embodiment, server 170 may access calendar information and/or other scheduling information having a particular activity date and time to determine user-level data 230 associated with user 140. Thus, the user-level data 230 can include schedule information associated with the user 140, which can be specific to the individual. User-level data 230 may include, for example, calendar information associated with a digital calendar (not shown), as well as patterns associated with user 140 that indicate that a turn-on event occurred during a particular week, at a particular time of day, on a particular calendar day, etc.

In one example embodiment, predictive analytics system 210 may generate predictive analytics model 205 based at least in part on usage data 200 and transmit predictive analytics model 205 to mobile device 120 associated with vehicle 105. For example, mobile device 120 may receive predictive analytics model 205, store predictive analytics model 205 on a computer memory (not shown) of mobile device 120, and access predictive analytics model 205 using application 135. Fig. 2A illustrates one embodiment in which the mobile device 120 is used to perform the prediction and analysis steps of determining a likely date and/or time (e.g., a predicted time interval associated with a future turn-on event of the vehicle 105) at which the user 140 is predicted to unlock and/or operate the vehicle 105. FIG. 3 illustrates an embodiment in which the automotive computer 145 is used to perform the prediction and analysis steps of determining a likely date and/or time in which the user 140 is predicted to unlock and/or operate the vehicle 105.

Considering first fig. 2A, an example embodiment of the present disclosure is shown in which mobile device 120 receives predictive analytics model 205 from server 170, predicts a time interval for a future turn-on event of vehicle 105, and transmits power mode instructions 260 to vehicle 105. In the exemplary embodiment of fig. 2A, user 140 may approach vehicle 105 while holding mobile device 120. Predictive analytics model 205 may determine a predicted time interval for transmitting power mode instructions from mobile device 120 to vehicle 105 via automotive computer 145 or via vehicle TCU160 (as shown in fig. 1).

It should be appreciated that a predicted time or a predicted time interval is used herein to describe a time or time window during which a user is predicted to perform an action or series of actions associated with a turn-on event of the vehicle 105 within a predetermined probability value range. While a discussion of techniques for predicting activities using stochastic or other methods known in the art of data analysis may be outside the scope of this specification, it should be understood that any of several known machine learning techniques are possible and are contemplated for use herein.

According to an example embodiment, the mobile device 120 may determine the predicted time interval based at least in part on data inputs that may include, for example, user GPS location information 240 indicating the current location of the user 140, vehicle GPS location information 245 indicating the current vehicle GPS location (or alternatively, vehicle GPS location information 245 associated with the vehicle 105 that may include a set of coordinates indicating the last known geographic location of the vehicle 105 as determined in the last higher power mode), user visit time/date information 250 indicating the historical date and time of the turn-on event, and/or user schedule information 255 indicating user-specific data. As introduced above, in one example embodiment, the predicted time interval may be a time span (e.g., having a start date and/or time and an end date and/or time) based on one or more values indicating that a turn-on event is imminent. The key-on event may be, for example, actuating a door latch mechanism, opening a door, starting a motor, performing remote start/climate control, etc.

In fig. 2A, a user 140 is shown approaching the vehicle 105. The time and location of the user 140 approaching the vehicle 105 may be predictable based on past data indicating similar vehicle usage patterns. For example, the user 140 may use the vehicle 105 to commute to and from work according to their repeated personal schedule. In this example, the user 140 may stop the vehicle 105 at an office location between 8:00 am and 8:15 am on most mondays, and return to the vehicle 105 between 5:00 pm and 5:10 pm on most mondays. While the vehicle 105 may generate GPS data, such as GPS data 220 as shown in fig. 1, when in a higher power mode, the vehicle GPS data may indicate that the vehicle location may not be available due to the vehicle 105 being in a low power mode. As the user 140 approaches the vehicle 105, the vehicle GPS information may not be available to determine when to transition the TCU160 from the low power mode to the higher power mode, and thus the vehicle GPS data may not be useful. Thus, the predicted time interval associated with a future key-on event of the vehicle 105 may provide such additional practical applications.

In other aspects, the user GPS location information 240 may indicate location coordinates of the user 140 that match a repeating pattern of user GPS coordinates (stored as user access time/date information 250) prior to a vehicle-on event in the past. Thus, when the mobile device 120 determines that the user 140 is within a predetermined distance (e.g., 50 feet, 10 feet, 5 feet, etc.) from the vehicle 105, the mobile device 120 may transmit the power mode instructions 260 to the TCU160 based at least in part on the user GPS location information 240 determined by the mobile device 120GPS system.

In this example, the mobile device 120 may actively run one or more applications 135 (execute instantiation) and predict a time interval associated with a future turn-on event of the vehicle 105. The prediction may be based on the day of the week, the date, the GPS location of the mobile device 120, the GPS location of the vehicle 105, and/or a calendar event associated with the user 104 stored in a digital calendar (not shown) or in another manner (e.g., via a social media calendar, etc.). Thus, in the example embodiment of fig. 2A, the mobile device 120 may be configured to predict a time interval associated with a future turn-on event of the vehicle 105 and transmit the power mode instructions 260 to the vehicle TCU 160.

In some aspects, the transmit power mode instructions 260 may include transmitting a wireless signal to a Bluetooth Low Energy (BLE) module associated with the vehicle 105. The power mode instructions 260 may include one or more encoded instructions configured to cause the vehicle TCU160 to change the TCU state from a low energy state to a higher energy state predicted time interval using the predictive analytics model 205 stored on the mobile device 120.

The low energy state and the higher energy state are generally referenced herein to describe operating states associated with TCU energy consumption from an onboard power source, such as a vehicle battery or battery pack (not shown in fig. 2A). It should be appreciated that the TCU system may place the vehicle TCU in a low energy state to allow and/or limit vehicle functions. The energy state may limit wireless communication between the vehicle TCU160 and other devices within communication range of the vehicle 105, and prevent other types of wireless communication with the TCU when in a low energy state to conserve battery power when parked for long periods of time. One example technique for TCU power state management is described in U.S. patent No.9,462,545 (hereinafter the' 545 patent "), assigned to Ford Global technology LLC. The' 545 patent describes a system that places a vehicle TCU in a sleep mode and initiates a higher power mode (e.g., a TCU extended power mode) to establish a data session with a telecommunications network. These non-limiting examples for the low power mode and the higher power mode are submitted merely to provide examples and are not intended to limit functionality that may be enabled, disabled, and/or otherwise changed by altering the TCU power state.

For example, the pre-processor 151 may remain active (i.e., receive continuous power) in a lower power mode such that when in the low power mode, a clock maintains time information, date information, etc., while the secure processor 153 is powered down or otherwise in a limited power mode. Thus, the pre-processor 151 may receive one or more BLE signals from the mobile device 120 and trigger a higher energy state based on the approaching mobile device 120. The BLE signal may include power mode instructions 260, which may be configured to change the TCU state from a low energy state to a higher energy state based at least in part on the predicted time interval.

Fig. 2B illustrates another example embodiment of the present disclosure in which predictive model 205 operates from remote server 270 to control power mode transitions. In fig. 2B, the user 140 is shown approaching the vehicle 105. As the user 140 approaches the vehicle 105, the vehicle GPS information may not be available to determine when to transition the TCU160 from the low power mode to the higher power mode, and thus the vehicle GPS data may not be useful. Thus, the predicted time interval associated with a future key-on event of the vehicle 105 may provide such additional practical applications.

In this example, the remote server 170 may actively run one or more applications (e.g., may be substantially similar to the application program 135 shown with reference to fig. 1) (perform instantiation), and predict a time interval associated with a future turn-on event of the vehicle 105. The prediction may be based on the day of the week, the date, the GPS location of the mobile device 120, the GPS location of the vehicle 105, and/or a calendar event associated with the user 104 stored in a digital calendar (not shown) or in another manner (e.g., via a social media calendar, etc.). Thus, in the example embodiment of fig. 2B, the server 170 may be configured to predict a time interval associated with a future turn-on event of the vehicle 105 and transmit the power mode instructions 260 to the vehicle TCU 160.

In some aspects, the transmit power mode instructions 260 may include transmitting a wireless signal to a TCU 260 associated with the vehicle 105. The power mode instructions 260 may include one or more encoded instructions configured to cause the vehicle TCU160 to change the TCU state from a low energy state to a higher energy state predicted time interval using the predictive analytics model 205 stored on the mobile device 120.

FIG. 3 illustrates an embodiment in which the automotive computer 145 is used to perform the prediction and analysis steps of determining a likely date and/or time in which the user 140 is predicted to unlock and/or operate the vehicle 105. As shown in FIG. 3, the automotive computer 145 may receive the predictive analytics model 205 from the server 170 and generate power mode instructions 320 using the automotive computer 145. In one aspect, the preprocessor 151 can determine a current time, date, etc., and determine whether the current time and date correspond to a predicted time interval that can be saved as part of the predictive analytics model 205, which can be stored in the memory 155 of the automotive computer 145. In response to determining that the current time, date, etc., is within the time interval indicated by the predictive analytics model 205, the pre-processor 151 may signal the security processor 153 to transition to a higher energy state to authenticate the mobile device 120 (and, by extension, the user 140) as the user 140 approaches the vehicle 105. Thus, FIG. 3 shows the user 140 approaching the vehicle 105, which may occur during a predicted date and time interval determined by the automotive computer 145.

Once the safety processor 153 is preemptively in a higher energy state, the safety processor may verify the safety and authentication of the mobile device 120 as the user 140 approaches the vehicle 105. The vehicle TCU160 and/or the car computer 145 may receive the PaaK security credentials 310 from the application 135 operating on the mobile device 120 and determine the authenticity of the mobile device 120 to access the vehicle 105 and the safe operation of the turn-on event based at least in part on the PaaK security credentials, user GPS location information 305, and/or other information. Verifying the security credentials may include comparing the user GPS location information 305 with stored user GPS location information 240, vehicle GPS location information 245, and/or other data, such as user access time/date information 250 and/or user schedule information 255.

In one aspect, when the vehicle TCU160 receives the power mode instruction 320 before the entity of the user 140 arrives (that is, for example, before the user contacts the vehicle to unlock the vehicle), the pre-processor 142 may begin the process of powering up the security processor 153, considering the PaaK security credentials 310 received from the mobile device 120 as the user 140 approaches the vehicle 105, and performing other authentication steps. Thus, based at least in part on the power mode instructions 260, the described system of fig. 3 may have little or no delay caused by the safe processor 153 entering a higher energy state prior to a turn-on event.

FIG. 4 illustrates a block diagram of an exemplary computer system 400 for practicing embodiments described herein. The computing system 400 described herein may be implemented in hardware, software (e.g., firmware), or a combination thereof. Computing system 400 (also referred to herein as system 400) may be substantially similar and/or identical to server 170 shown in fig. 1-3.

As shown in fig. 4, the computing system 400 may include one or more processors 405, a memory 410 communicatively coupled to the one or more processors 405, and an input/output adapter 415 that may be communicatively connected with an external device. Computing system 400 may be operatively connected to and communicate information with one or more internal and/or external memory devices (such as, for example, one or more databases 430) via storage interface 420. Computing system 400 may include one or more network adapters 425 that enable the computing system 400 to be communicatively connected with one or more networks 125. In one embodiment, computing system 400 may include one or more IP-based networks for communicating between computing system 400 and any external devices. In such embodiments, computing system 400 may also include one or more telecommunications adapters 440. Computing system 400 may also include and/or be connected with one or more input devices 445 and/or one or more output devices 450 via I/O adapter 415.

The one or more processors 405 are collectively a hardware device for executing program instructions (also known as software) that can be stored in a computer-readable memory, such as memory 410. The one or more processors 405 may be a custom made or commercially available processor, a Central Processing Unit (CPU), multiple CPUs, an auxiliary processor associated with the computing system 400 among several other processors, a semiconductor based microprocessor (in the form of a microchip or chip set), or any device commonly used to execute instructions.

The one or more processors 405 may be disposed in communication with one or more memory devices (e.g., memory 410 and/or one or more external databases 430, etc.) via the storage interface 408. Storage device interface 408 may also connect to one or more storage devices using a connection protocol such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), Universal Serial Bus (USB), fiber channel, Small Computer System Interface (SCSI), and the like, including but not limited to one or more databases 430 that may include, for example, removable disk drives, vehicle computing system memory, cloud storage, and/or one or more other storage drives (not shown).

The memory 410 may include any one or combination of volatile memory elements (e.g., Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), etc.) and may include any one or more non-volatile memory elements (e.g., Erasable Programmable Read Only Memory (EPROM), flash memory, Electronically Erasable Programmable Read Only Memory (EEPROM), Programmable Read Only Memory (PROM), etc.).

The instructions in memory 410 may comprise one or more separate programs, any of which may comprise an ordered listing of computer-executable instructions for implementing logical functions. In the example of fig. 4, the instructions in memory 410 may include an operating system 455. The operating system 455 may control the execution of other computer programs, such as generating predictive analytics models as described herein, receiving and storing usage data 200 (described with respect to fig. 1), and performing other tasks, such as providing scheduling, input-output control, file and data management, memory management, and communication control and related services.

The program instructions stored in memory 410 may also include application data 460, which may include data associated with predictive analytics system 210, instructions for receiving usage data 200, and instructions for analyzing usage data 200. In one example, the usage data 200 may include user profile information 470 and fleet of vehicles information 475, which may indicate other vehicles (not shown in FIG. 4) identified in a fleet of vehicles, computing elements associated with the vehicles, usage patterns, and the like. User profile information 470 and/or fleet information 475 may be stored in database 430 and accessed by computing system 400 to determine and/or generate predictive model 204 and/or other elements of predictive analytics system 210. The program instructions in memory 410 may also include instructions for controlling system 400 and/or interacting with the system through user interface 465.

The I/O adapter 415 may connect a number of input devices 445 to the computing system 400. Input devices 445 may include, for example, a keyboard, mouse, microphone, sensor, and the like. Output device 450 may include, for example, a display, speakers, a touch screen, and so forth. I/O adapter 415 may be configured to operatively connect one or more input/output (I/O) devices 407 to computing system 400. For example, I/O adapter 415 may connect a keyboard and mouse, touch screen, speakers, tactile output device, or other output device. Finally, the I/O devices connectable to the I/O adapter 415 may also include devices that communicate both input and output, such as, but not limited to, a Network Interface Card (NIC) or modulator/demodulator (for accessing other files, devices, systems, or networks), a Radio Frequency (RF) or other transceiver, a telephone interface, a bridge, a router, and so forth.

Fig. 5 is a flow chart of an example method 500 of the present disclosure. The method 500 generally includes step 505, which may include predicting, via the predictive analytics model 205, a predicted time interval associated with a future turn-on event of the vehicle 105, wherein the predictive analytics model 205 is based at least in part on the turn-on event data. The turn-on event data may include time information and date information associated with unlocking the vehicle 105, and may include Global Positioning Service (GPS) information indicative of a GPS location of one or more of the vehicle 105 and a mobile device associated with the vehicle 105 (e.g., the mobile device 120). In some aspects, the turn-on event data may also include key fob usage data 225, which may provide details indicating how, when, and where key fob 235 was used to unlock vehicle 105 in the past. In other aspects, the turn-on event data can include user-level data associated with a user of the vehicle 105 (e.g., the user 140).

In one embodiment, prior to predicting the predicted time interval, method 500 may include a preliminary step of generating predictive analytics model 205. Generating the predictive analytics model 205 may include receiving turn-on event data (e.g., the usage data 200) from one or more of the vehicle TCU160 and/or the mobile device 120 associated with the vehicle 105, which may be indicative of turn-on events of the vehicle 105 and/or other vehicles in the fleet of vehicles.

Then, after predicting the predicted time interval, the method may comprise step 510: based at least in part on the predicted time interval, power mode instructions (e.g., power mode instructions 260 and/or 320) are generated that may be configured to cause the vehicle TCU160 to change the TCU state from a low energy state to a higher energy state.

The method may include another step 515, which may include transmitting a power mode command (e.g., one of power mode commands 260 and/or 320) to the vehicle TCU160 based on the predicted time interval. In some aspects, transmitting the power mode instructions 260, 320 includes transmitting a wireless signal to a Bluetooth Low Energy (BLE) module associated with the vehicle, wherein the power mode instructions change the TCU state from a low energy state to a higher energy state based at least in part on the predicted time interval.

The pre-scheduled wake-up message from the server 170 or a connected mobile device (e.g., mobile device 120) may provide vehicle intelligence that proactively determines when a low-power mode may not be acceptable to the user 140, and/or when a higher-power mode is most likely to help reduce and/or eliminate lag time for the vehicle 105 to enter and operate. Further, embodiments of the present disclosure may centrally manage (from one or more cloud-based servers 170) how predictive analytics system 210 is constructed and transmitted to vehicle 105, thereby allowing centralized control that may maintain the updatability and safety features of vehicle 105 after receiving predictive analytics model 205.

In the foregoing disclosure, reference has been made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific implementations in which the disclosure may be practiced. It is to be understood that other implementations may be utilized and structural changes may be made without departing from the scope of the present disclosure. References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a feature, structure, or characteristic is described in connection with an embodiment, it will be recognized by those skilled in the art that such feature, structure, or characteristic may be used in connection with other embodiments whether or not explicitly described.

It will also be understood that the word "example" as used herein is intended to be non-exclusive and non-limiting in nature. More particularly, the word "exemplary," as used herein, indicates one of several examples, and it is to be understood that no undue emphasis or preference is placed on the particular examples described.

A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. The computing device may include computer-executable instructions, where the instructions are executable by one or more computing devices (such as those listed above) and stored on a computer-readable medium.

With respect to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It is also understood that certain steps may be performed simultaneously, that other steps may be added, or that certain steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating various embodiments and should not be construed as limiting the claims in any way.

Accordingly, it is to be understood that the above description is intended to be illustrative, and not restrictive. Many embodiments and applications other than the examples provided will be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. Future developments are anticipated and intended in the arts discussed herein, and the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the present application is capable of modification and variation.

Unless explicitly indicated to the contrary herein, all terms used in the claims are intended to be given their ordinary meaning as understood by those of skill in the art described herein. In particular, the use of singular articles such as "a," "the," "said," etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary. Conditional language such as "can," "may," or "may" is generally intended to convey that certain embodiments may include certain features, elements, and/or steps, while other embodiments may not include such features, elements, and/or steps, unless specifically stated otherwise, or otherwise understood within the context of use. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required by one or more embodiments.

According to one embodiment, the invention also features transmitting the predictive analytics model to an automotive computer onboard the vehicle.

According to one embodiment, the automotive computer on the vehicle is configured to determine a predicted time interval associated with a future key-on event of the vehicle and transmit a power mode instruction to the vehicle.

According to the present invention, there is provided a system having: a processor; and a memory for storing executable instructions, the processor configured to execute the instructions to: determining, via a predictive analytics model, a predicted time interval associated with a future turn-on event of a vehicle, wherein the predictive analytics model is based at least in part on turn-on event data; determining a power mode instruction based at least in part on the predicted time interval, the power mode instruction configured to cause a vehicle Telematics Control Unit (TCU) to change from a low energy state to a higher energy state; and transmitting the power mode command to the vehicle TCU based on the predicted time interval.

According to one embodiment, the turn-on event data comprises time information and date information associated with: unlocking the vehicle, actuating a door latch mechanism, opening a door, starting a motor, performing remote start/climate control, or similar vehicle function indicating a user's intent to access or operate the vehicle.

According to the present invention, there is provided a vehicle having: a processor; and a memory for storing executable instructions, the processor configured to execute the instructions to: determining, via a predictive analytics model, a predicted time interval associated with a future turn-on event of a vehicle, wherein the predictive analytics model is based at least in part on turn-on event data; determining a power mode instruction based at least in part on the predicted time interval, the power mode instruction configured to cause a vehicle cell phone, i.e., key (PaaK) system, to change from a low energy state to a higher energy state; and adjusting a power mode of the vehicle from a low energy state to a higher energy state based on the power mode command.