DYNAMIC COMMUNICATION DATA USAGE

- INRIX INC.,

One or more techniques and/or systems are provided for selectively collecting vehicle telemetry data from one or more vehicles. For example, a communication data budget for a vehicle may be identified (e.g., a 5 GB per month data connection plan). A determination may be made as to whether the vehicle can provide vehicle telemetry data used to model a travel condition (e.g., road imagery, temperature, a windshield wiper state, and/or other vehicle telemetry data used to model a road safety condition). If the vehicle has remaining communication data budget available for transmission of the vehicle telemetry data without the vehicle exceeding the communication data budget for a billing cycle, then a data request for the vehicle telemetry data may be sent to the vehicle. Responsive to receiving the vehicle telemetry data from the vehicle, the travel condition may be modeled (e.g., the road condition may be determined as icy).

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 61/946,962 titled “DETERMINING HOV/HOT LANE TRAVEL TIMES”, filed on Mar. 3, 2014, which is hereby incorporated by reference.

BACKGROUND

Many vehicle manufacturers install data communication devices (e.g., a cellular communication device, an embedded modem, etc.) within vehicles. A vehicle manufacturer may bundle data connection plans for the vehicles into a bundled data connection plan with a communication provider. The bundled data connection plan may assume an average use per vehicle and may have a higher cost penalty if usage exceeds the total monthly amount. However, some drivers might not utilize the minimum allotted data transfer, and thus fees paid to the communication provider for data connection plans of such drivers may be wasted. Accordingly, it may be advantageous to utilize unused communication data of vehicles that may not otherwise use the minimum allotted data transfer amount.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Among other things, one or more systems and/or techniques for selectively collecting and/or providing vehicle telemetry data are provided herein. In an example, a data collection component is configured to identify a communication data budget for a vehicle (e.g., the vehicle may have a monthly data connection plan of 5 GB per month with a communication provider). The data collection component may determine that the vehicle can provide vehicle telemetry data used to model a travel condition, such as a road condition, a vehicle condition, a traffic condition, a driver behavior, etc. (e.g., the vehicle may be identified as traveling along a road for which the road condition is to be modeled using windshield wiper status information, real-time images of the road, braking and speed patterns of vehicles traveling along the road, etc.).

The data collection component may evaluate data usage information of the first vehicle (e.g., an amount of data used during a current billing cycle, a number of days remaining in the current billing cycle, an average amount of data expected to be used by the driver during the billing cycle, and/or other information that may be used to identify a data request threshold indicative of an amount of data reasonable to request from the vehicle without the vehicle exceeding the communication data budget during the billing cycle) to determine a remaining amount of communication data of the communication data budget. The data collection component may construct a data request based upon the vehicle telemetry data and the remaining amount of communication data (e.g., the data request may request an amount of data that is below the data request threshold). The data request may be sent to the vehicle (e.g., an instruction to collect and return windshield wiper status information now, and to collect, store, and later send real-time images of the road once the vehicle is allocated new communication data budget). The data collection component may receive a vehicle telemetry data response (e.g., the windshield wiper status information and later the real-time images) from the vehicle, and may model the travel condition based upon the vehicle telemetry data.

To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram illustrating an exemplary method of selectively collecting vehicle telemetry data from one or more vehicles.

FIG. 2A is a component block diagram illustrating an exemplary system for selectively collecting vehicle telemetry data from one or more vehicles.

FIG. 2B is a component block diagram illustrating an exemplary system for modeling a travel condition based upon vehicle telemetry data.

FIG. 3A is a component block diagram illustrating an exemplary system for selectively collecting vehicle telemetry data from a vehicle.

FIG. 3B is a component block diagram illustrating an exemplary system for selectively collecting vehicle telemetry data from a vehicle.

FIG. 3C is a component block diagram illustrating an exemplary system for modeling a travel condition based upon vehicle telemetry data.

FIG. 4A is a component block diagram illustrating an exemplary system for selectively collecting vehicle telemetry data from one or more vehicles.

FIG. 4B is a component block diagram illustrating an exemplary system for modeling a travel condition based upon vehicle telemetry data.

FIG. 5 is a component block diagram illustrating an exemplary system for selectively providing vehicle telemetry data to a data collection component.

FIG. 6 is an illustration of an exemplary computer readable medium wherein processor-executable instructions configured to embody one or more of the provisions set forth herein may be comprised.

FIG. 7 illustrates an exemplary computing environment wherein one or more of the provisions set forth herein may be implemented.

 DETAILED DESCRIPTION

The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are generally used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth to provide an understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are illustrated in block diagram form in order to facilitate describing the claimed subject matter.

One or more systems and/or techniques for selectively collecting and/or providing vehicle telemetry data are provided herein. Many vehicles may subscribe to data connection plans with communication providers. The data connection plan may afford the vehicle with data communication capabilities, such as an ability for a vehicle navigation device to receive information from a remote source such as a travel route provider, a map provider, a weather provider, a music streaming service, etc. In an example, a vehicle manufacturer may procure a bundled data connection plan for a plurality of vehicles, where a vehicle is assigned a communication data budget for a periodic billing cycle. If the vehicle exceeds the communication data budget, then overage fees may be incurred. If the vehicle does not utilize the entire communication data budget, then payment for the unused portion may be wasted. Accordingly, as provided herein, vehicle telemetry data may be selectively requested from vehicles that may have available amounts of communication data that may otherwise not be fully utilized during a billing cycle. Efficient utilization of communication bandwidth may allow for the extraction of vehicle telemetry data, otherwise unattainable, which may be used to model travel conditions, such as a road condition, a traffic condition, a vehicle condition, etc., that may be used to provide drivers with robust information such as relatively more efficient and accurate travel routes and travel times that take into account such travel conditions.

An embodiment of selectively collecting vehicle telemetry data from one or more vehicles is illustrated by an exemplary method 100 of FIG. 1. At 102, the method 100 starts. At 104, a first communication data budget may be identified for a first vehicle. For example, the first vehicle subscribe to a 4 GB per 30 days data connection plan. At 106, the first vehicle may be determined as being capable of providing vehicle telemetry data used to model a travel condition (e.g., a road condition, a vehicle condition, a traffic condition, a user behavior such as whether a user is a safe or risky driver, etc.). The vehicle telemetry data may comprise a vehicle sensor reading (e.g., a tire pressure reading), a temperature, an image, a video, a state of a vehicle component (e.g., whether a turn signal is on), a weather condition, a driving behavior of the user (e.g., a driving behavior pattern that is derived from a braking pattern, an acceleration/deceleration pattern, turn signal usage, and/or any other driving pattern of the first vehicle), and/or a variety of other information.

In an example of determining whether a vehicle can provide relevant vehicle telemetry data, the travel condition may correspond to a geographical region (e.g., a road, a range of addresses, longitudinal/latitudinal coordinates, etc.). Communication connections may be established with vehicles within a threshold proximity to the geographical region (e.g., vehicles within the geographical region or vehicles traveling towards the geographical region that are less than 5 miles away). Vehicles, such as the first vehicle, with which communication connections are successfully established (e.g., and/or have available data communication budget, vehicle sensors for obtaining vehicle telemetry data, etc.) may be identified as being capable of providing relevant vehicle telemetry data (e.g., where a vehicle may be instructed to collect vehicle telemetry data while traveling within the geographical region).

In another example of determining whether a vehicle can provide relevant vehicle telemetry data, the travel condition may correspond to a road segment. A driving pattern of the first vehicle may be identified (e.g., the user generally travels along the road segment on the way to work). Responsive to the driving pattern indicating that the first vehicle will travel the road segment above a threshold probability (e.g., a 70% or greater confidence), the first vehicle may be identified as being capable of providing relevant vehicle telemetry data (e.g., where the first vehicle may be instructed to collected vehicle telemetry data while traveling the road segment).

At 108, first data usage information of the first vehicle may be evaluated to determine a first remaining amount of communication data of the first communication data budget. For example, the first vehicle may have used 2.5 GB of the 4 GB first communication data budget and may be on day 20 out of a 30 day periodic billing cycle. A projected amount of periodic communication usage may be determined for the first vehicle based upon the 30 day periodic billing cycle and a current amount of data usage for the 30 day periodic billing cycle (e.g., and/or other information such as an average data usage for previous 30 day periodic billing cycles). In an example, a data request threshold may be defined based upon the projected amount of periodic communication usage by the first vehicle (e.g., the first vehicle may be projected to use 1 GB more of the 4 GB first communication data budget in the remaining 10 days of the 30 day periodic billing cycle for a total usage of 3.5 GB, and thus the data request threshold may be set at 0.5 GB or less in order to avoid exceeding the first communication data budget). Thus, an amount of vehicle telemetry data not exceeding the data request threshold may be available to request from the first vehicle without the first vehicle incurring data overage fees.

At 110, a first data request may be constructed based upon the vehicle telemetry data and the first remaining amount of communication data. For example, the first data request may request the vehicle telemetry data or a portion thereof that does not exceed the data request threshold. In an example, if an amount of vehicle telemetry data requested by the first data request (e.g., a request for a 1 GB video) exceeds the data request threshold of 0.5 GB or less, then the first data request may not be sent to the first vehicle. The first data request for the vehicle telemetry data of the 1 GB video may be sent once the first vehicle receives a new allocation of the first communication data budget (e.g., once a subsequent 30 day periodic billing cycle starts). In another example where the amount of vehicle telemetry data requested by the first data request exceeds the data request threshold, an instruction may be included within the first data request. The instruction may instruct the first vehicle to collect measured vehicle telemetry data to send to a data collection component once the first vehicle receives the new allocation of the first communication data budget (e.g., once the subsequent 30 day periodic billing cycle starts).

At 112, the first data request may be sent to the first vehicle, such as where the amount of vehicle telemetry data requested by the first data request does not exceed the data request threshold (e.g., the first data request may request 0.1 GB of vehicle sensor data). At 114, a first vehicle telemetry data response may be received from the first vehicle. At 116, the travel condition may be modeled based upon the first vehicle telemetry data response, such as based upon the vehicle sensor data.

In an example where additional vehicle telemetry data is needed to model the travel condition, the first vehicle telemetry data response may be determined as comprising a first portion of the vehicle telemetry data (e.g., the 0.1 GB of vehicle sensor data but not a 1 GB video of a road segment). A second communication data budget for a second vehicle may be identified (e.g., a 6 GB per month data connection plan). The second vehicle may be determined as being capable of providing the vehicle telemetry data, such as the 1 GB video of the road segment, used to model the travel condition (e.g., the second vehicle may be traveling along the road segment). Second data usage information of the second vehicle may be evaluated to determine a second reaming amount of communication data of the second communication data budget (e.g., 4 GB may be remaining on day 25 out of a 30 day periodic billing cycle). A second data request may be constructed based upon the vehicle telemetry data and the second remaining amount of communication data (e.g., a request for the 1 GB video). The second data request may be sent to the second vehicle. A second vehicle telemetry data response, comprising a second portion of the vehicle telemetry data such as the 1 GB video, may be received from the second vehicle. The travel condition may be modeled based upon the first portion and the second portion of the vehicle telemetry data.

In an example, different amounts of vehicle telemetry data may be requested from vehicles based upon remaining amounts of communication data of respective vehicles. For example, responsive to determining that the second remaining amount of communication data (e.g., 4 GB out of 6 GB remaining for 5 days) is greater than the first amount of communication data (e.g., 2.5GB out of the 4 GB remaining for 10 days), a first amount of vehicle telemetry data to request from the first vehicle (e.g., the 0.1 GB of vehicle sensor data) and a second amount of vehicle telemetry data (e.g., the 1 GB video), greater than the first amount of vehicle telemetry data, may be specified. The first data request may be constructed based upon the first amount of vehicle telemetry data. The second data request may be constructed based upon the second amount of vehicle telemetry data. In this way, vehicle telemetry data may be selectively requested in various amounts based upon projected amounts of otherwise unutilized communication data budgets of vehicles. At 118, the method 100 ends.

FIGS. 2A-2B illustrate examples of a system 200, comprising a data collection component 202, for selectively collecting vehicle telemetry data from one or more vehicles. For example, a first vehicle 208, a second vehicle 204, a third vehicle 206, and/or other vehicles may have communication data plans with communication data budgets, as illustrated in FIG. 2A. For example, the data collection component 202 may maintain a first entry 212 for the first vehicle 208. The first entry 212 may indicate that the first vehicle 208 has a 5 GB communication data budget, that 3.5 GB has been used as of day 25 out of a 30 day billing cycle, that the first vehicle 208 is projected to use 4.5 GB for the 30 day billing cycle, and that a first data request threshold for requesting vehicle telemetry data should be less than 0.4 GB. The data collection component 202 may maintain a second entry 214 for the second vehicle 204. The second entry 214 may indicate that the second vehicle 204 has a 5 GB communication data budget, that 1.5 GB has been used as of day 25 out of a 30 day billing cycle, that the second vehicle 204 is projected to use 2.5 GB for the 30 day billing cycle, and that a second data request threshold for requesting vehicle telemetry data should be less than 2.2 GB.

The data collection component 202 may determine that 1.5 GB of real-time imagery of road conditions (e.g., vehicle telemetry data from a vehicle camera) is to be collected from vehicles in order to model a travel condition 232 indicative of safety conditions along a road (e.g., an icy road condition, a traffic accident, traffic congestion, etc.). The data collection component 202 may determine that the 1.5 GB of real-time imagery may exceed the first data request threshold of 0.4 GB for the first vehicle 208, and thus the data collection component 202 may refrain from requesting the real-time imagery from the first vehicle 208. The data collection component 202 may determine that the 1.5 GB of real-time imagery does not exceed the second data request threshold of 2.2 GB for the second vehicle 204, and thus the data collection component 202 may send a data request 216 for the real-time imagery to a vehicle data provider component 210 of the second vehicle 204. FIG. 2B illustrates the vehicle data provider component 210 sending vehicle telemetry data 230 of the real-time imagery to the data collection component 202 for modeling of the travel condition 232.

FIGS. 3A-3C illustrate examples of a system 300, comprising a data collection component 302, for selectively collecting vehicle telemetry data from one or more vehicles. FIG. 3A illustrates the data collection component 302 maintaining a first entry 304 for a first vehicle 308. The first entry 304 may indicate that the first vehicle 308 has a 5 GB communication data budget, that 3.5 GB has been used as of day 27 out of a 30 day billing cycle, that the first vehicle 308 is projected to use 4.5 GB for the 30 day billing cycle, and that a first data request threshold for requesting vehicle telemetry data should be less than 0.4 GB. The data collection component 302 may maintain a second entry 306 for a second vehicle. The second entry 306 may indicate that the second vehicle has a 5 GB communication data budget, that 3.1 GB has been used as of day 27 out of a 30 day billing cycle, that the second vehicle is projected to use 2.5 GB for the 30 day billing cycle, and that a second data request threshold for requesting vehicle telemetry data should be less than 1.4 GB.

The data collection component 302 may determine that a travel condition corresponding to a vehicle behavior of the first vehicle 308 is to be modeled. The data collection component 302 may determine that temperature information, windshield information, and video of the first vehicle traveling along a road may be used for modeling the travel condition of the vehicle behavior. The data collection component 302 may evaluate the first entry 304 to determine that the first vehicle 308 has a data request threshold of less than 0.4 GB based upon the first vehicle being projected to use 4.5 GB for the 30 day billing cycle and having used 3.5 GB of the 5 GB communication budget (e.g., less than a 5% probability or any other threshold probability that the 5 GB communication data budget will be exceeded during the 30 day billing cycle if less than 0.4 GB of vehicle telemetry data is provided to the data collection component 302). Accordingly, the data collection component 302 may construct a data request 312. The data request 312 may instruct the first vehicle 308 to collect temperature and windshield information while traveling along the road and to send the temperature and windshield information back to the data collection component 302 because the temperature and windshield information may use less than 0.4 GB. The data request 312 may instruct the first vehicle 308 to capture and store video while driving along the road, and to upload the video during the next billing cycle once a new allocation of communication data budget is allocated to the first vehicle 308. The data request 312 may be sent to a vehicle data provider component 310 of the first vehicle 308.

FIG. 3B illustrates the vehicle data provider component 310 accessing vehicle sensors of the first vehicle 308 to obtain first measured vehicle telemetry data comprising the temperature and windshield information while the first vehicle 308 travels the road. The vehicle data provider component 310 may record the video while the first vehicle 308 travels the road, and may store the video as stored vehicle telemetry data for subsequent transmission to the data collection component 302. The vehicle data provider 310 may send a first vehicle telemetry data response 330, comprising the temperature and windshield information, to the data collection component 302. The data collection component 302 may store the temperature and windshield information as stored temperature and windshield information 332.

FIG. 3C illustrates the vehicle data provider component 310 sending a second vehicle telemetry data response 340, comprising the stored vehicle telemetry data of the video, to the data collection component 302 based upon the first vehicle 308 receiving a new allocation of communication data budget (e.g., a new billing cycle may result in the new allocation). The data collection component 302 may store the video as stored video information 342. The data collection component 302 may model the travel condition 334 of the vehicle behavior based upon the stored temperature and windshield information 332 and the video information 342. For example, the travel condition 334 may indicate how the first vehicle 308 drives on snowy roads (e.g., the temperature, windshield status, and video may be indicative of how the first vehicle 308 performed on the snowy road).

FIGS. 4A-4B illustrate examples of a system 400, comprising a data collection component 402, for selectively collecting vehicle telemetry data from one or more vehicles. FIG. 4 illustrates the data collection component 402 defining a geographical region 410 (e.g., an address range, a road, locational coordinates, etc.) used to identify vehicles within the geographical region 410 as being capable of providing vehicle telemetry data. The data collection component 402 may identify a first vehicle 412, a second vehicle 416, and a third vehicle 420 as being within a threshold proximity of the geographical region 410. The data collection component 402 may maintain a first entry 404 for the first vehicle 412. The first entry 404 may indicate that the first vehicle 412 has a 3 GB communication data budget, that 2.7 GB has been used as of day 29 out of a 30 day billing cycle, and that a first data request threshold for requesting vehicle telemetry data should be less than 0.1 GB. The data collection component 402 may maintain a second entry 406 for the second vehicle 416. The second entry 406 may indicate that the second vehicle 416 has a 4 GB communication data budget, that 3.5 GB has been used as of day 29 out of a 30 day billing cycle, and that a second data request threshold for requesting vehicle telemetry data should be less than 0.3 GB. The data collection component 402 may maintain a third entry 408 for the third vehicle 420. The third entry 408 may indicate that the third vehicle 420 has a 4 GB communication data budget, that 3.7 GB has been used as of day 29 out of a 30 day billing cycle, and that a third data request threshold for requesting vehicle telemetry data should be less than 0.25 GB.

The data collection component 402 may determine that vehicle telemetry data, comprising weather data, driver behavior data, and vehicle sensor data, can be used to model a travel condition such as a traffic congestion condition for the geographical region 410. The data collection component 402 may determine that the first vehicle 412 can provide the weather data because the weather data of 0.05 GB does not exceed the first data request threshold of 0.1 GB. The data collection component 402 may determine that the second vehicle 416 can provide the driver behavior data (e.g., a braking pattern, acceleration/deceleration patterns, etc.) because the driver behavior data of 0.27 GB does not exceed the second data request threshold of 0.3 GB (but would exceed the first data request threshold of 0.1GB and the third data request threshold of 0.25 GB). The data collection component 402 may determine that the third vehicle 420 can provide the vehicle sensor data because the vehicle sensor data of 0.2 GB does not exceed the third data request threshold of 0.25 GB (but would exceed the first data request threshold of 0.1 GB).

Accordingly, the data collection component 402 may send a first data request 424 to a first vehicle data provider component 414 of the first vehicle 412 for the weather data. The data collection component 402 may send a second data request 426 to a second vehicle data provider component 418 of the second vehicle 416 for the driver behavior data. The data collection component 402 may send a third data request 428 to a third vehicle data provider component 422 of the third vehicle 420 for the vehicle sensor data.

FIG. 4B illustrates the first vehicle data provider component 414 collecting the weather data and sending a first vehicle telemetry data response 450, comprising the weather data, to the data collection component 402. The second vehicle data provider component 418 collects the driver behavior data and sends a second vehicle telemetry data response 452, comprising the driver behavior data, to the data collection component 402. The third vehicle data provider component 422 collects the vehicle sensor data and sends a third vehicle telemetry data response 454, comprising the vehicle sensor data, to the data collection component 402. The data collection component 402 may use the weather data, the driver behavior data, and/or the vehicle sensor data to model a travel condition 456 indicating of driving safety conditions of the geographical region 410.

FIG. 5 illustrates an example of a system 500, comprising a vehicle data provider component 506, for selectively providing vehicle telemetry data to a data collection component 502. The vehicle data provider component 506 may be associated with a vehicle. The vehicle data provider component 506 may establish a communication connection with the data collection component 502. The vehicle data provider component 506 may transmit location data, such as global positioning system (GPS) data, of the vehicle to the data collection component 502 over the communication connection.

The vehicle data provider component 506 may utilize one or more vehicle sensors (e.g., a brake sensor, a speed sensor, a windshield wiper sensor, a temperature sensor, a vehicle computer, a camera, and/or any other device that may obtain data about the vehicle and/or driving conditions) to obtain vehicle telemetry data during operation of the vehicle. The vehicle data provider component 506 may store the vehicle telemetry data as stored vehicle telemetry 514 within a data storage device 508 (e.g., stored vehicle telemetry data corresponding to vehicle sensor data, barking patterns, images of roads, etc.) for subsequent transmission to the data collection component 502.

In an example, the vehicle data provider component 506 may receive a data request 504 for imagery of road (XYZ). The vehicle data provider component 506 may determine that stored vehicle telemetry data 510 comprises the imagery of road (XYZ). The vehicle data provider component 506 may determine a current remaining amount of communication data of a communication data budget of the vehicle (e.g., 3 GB may remain of a 5 GB communication data budget on day 27 of a 30 day billing cycle). The vehicle data provider component 506 may determine a current data request threshold, such as 1 GB, based upon a current remaining amount of communication data of the data communication budget, such as an amount of data that can be used to transmit vehicle telemetry data where the vehicle is projected to have a probably of exceeding the 5 GB communication data budget below a threshold (e.g., less than a 5% probability or any other threshold probability that the 5 GB communication data budget will be exceeded during the 30 day billing cycle if 1 GB of vehicle telemetry data is provided to the data collection component 502). Responsive to the vehicle telemetry data not exceeding the current data request threshold of 1 GB (e.g., the stored vehicle telemetry data 510 may be 0.6 GB), a current vehicle telemetry data response 512, comprising the stored vehicle telemetry data 510 of the imagery of the road (XYZ), may be sent to the data collection component 502 over the communication connection.

In an example, the vehicle data provider component 506 may receive a data request for vehicle telemetry data not yet obtained by the vehicle data provider component 506 (e.g., a request for a video of a road that the vehicle is currently traveling). The vehicle data provider component 506 may query one or more vehicle sensors, such as a video camera, of the vehicle to obtain measured vehicle telemetry data, such as the video. The vehicle data provider component 506 may determine a data request threshold, such as 0.4 GB, based upon a remaining amount of communication data of a communication data budget for the vehicle. Responsive to the vehicle telemetry data, such as the video, not exceeding the data request threshold (e.g., the video may be 0.3 GB), a vehicle telemetry data response, comprising the video, may be sent to the data collection component 502 over the communication connection. Responsive to the vehicle telemetry data, such as the video, exceeding the data request threshold (e.g., the video may be 0.8 GB), the vehicle telemetry data may be stored and marked for subsequent transmission to the data collection component 502.

Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An example embodiment of a computer-readable medium or a computer-readable device is illustrated in FIG. 6, wherein the implementation 600 comprises a computer-readable medium 608, such as a CD-R, DVD-R, flash drive, a platter of a hard disk drive, etc., on which is encoded computer-readable data 606. This computer-readable data 606, such as binary data comprising at least one of a zero or a one, in turn comprises a set of computer instructions 604 configured to operate according to one or more of the principles set forth herein. In some embodiments, the set of computer instructions 604 are configured to perform a method 602, such as at least some of the exemplary method 100 of FIG. 1, for example. In some embodiments, the set of computer instructions 604 are configured to implement a system, such as at least some of the exemplary system 200 of FIGS. 2A-2B, at least some of the exemplary system 300 of FIGS. 3A-3C, at least some of the exemplary system 400 of FIGS. 4A-4B, and/or at least some of the exemplary system 500 of FIG. 5, for example. Many such computer-readable media are devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing at least some of the claims.

As used in this application, the terms “component,” “module,” “system”, “interface”, and/or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

FIG. 7 and the following discussion provide a brief, general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of FIG. 7 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Example computing devices include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Although not required, embodiments are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.

FIG. 7 illustrates an example of a system 700 comprising a computing device 712 configured to implement one or more embodiments provided herein. In one configuration, computing device 712 includes at least one processing unit 716 and memory 718. Depending on the exact configuration and type of computing device, memory 718 may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in FIG. 7 by dashed line 714.

In other embodiments, device 712 may include additional features and/or functionality. For example, device 712 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in FIG. 7 by storage 720. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage 720. Storage 720 may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory 718 for execution by processing unit 716, for example.

The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 718 and storage 720 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 712. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of device 712.

Device 712 may also include communication connection(s) 726 that allows device 712 to communicate with other devices. Communication connection(s) 726 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 712 to other computing devices. Communication connection(s) 726 may include a wired connection or a wireless connection. Communication connection(s) 726 may transmit and/or receive communication media.

The term “computer readable media” may include communication media. Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Device 712 may include input device(s) 724 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 722 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 712. Input device(s) 724 and output device(s) 722 may be connected to device 712 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 724 or output device(s) 722 for computing device 712.

Components of computing device 712 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 712 may be interconnected by a network. For example, memory 718 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.

Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 730 accessible via a network 728 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 712 may access computing device 730 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 712 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 712 and some at computing device 730.

Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein. Also, it will be understood that not all operations are necessary in some embodiments.

Further, unless specified otherwise, “first,” “second,” and/or the like are not intended to imply a temporal aspect, a spatial aspect, an ordering, etc. Rather, such terms are merely used as identifiers, names, etc. for features, elements, items, etc. For example, a first object and a second object generally correspond to object A and object B or two different or two identical objects or the same object.

Moreover, “exemplary” is used herein to mean serving as an example, instance, illustration, etc., and not necessarily as advantageous. As used herein, “or ” is intended to mean an inclusive “or” rather than an exclusive “or”. In addition, “a” and “an” as used in this application are generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Also, at least one of A and B and/or the like generally means A or B and/or both A and B. Furthermore, to the extent that “includes”, “having”, “has”, “with”, and/or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising”.

Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

Claims

1. A system for selectively collecting vehicle telemetry data from one or more vehicles, comprising:

a data collection component configured to: identify a first communication data budget for a first vehicle; determine that the first vehicle can provide vehicle telemetry data used to model a travel condition; evaluate first data usage information of the first vehicle to determine a first remaining amount of communication data of the first communication data budget; construct a first data request based upon the vehicle telemetry data and the first remaining amount of communication data; send the first data request to the first vehicle; receive a first vehicle telemetry data response from the first vehicle; and model the travel condition based upon the first vehicle telemetry data response.

2. The system of claim 1, the first vehicle telemetry data response comprising a first portion of the vehicle telemetry data, and the data collection component configured to:

identify a second communication data budget for a second vehicle;
determine that the second vehicle can provide the vehicle telemetry data used to model the travel condition;
evaluate second data usage information of the second vehicle to determine a second remaining amount of communication data of the second communication data budget;
construct a second data request based upon the vehicle telemetry data and the second remaining amount of communication data;
send the second data request to the second vehicle;
receive a second vehicle telemetry data response from the second vehicle, the second vehicle telemetry data response comprising a second portion of the vehicle telemetry data; and
model the travel condition based upon the first portion of the vehicle telemetry data and the second portion of the vehicle telemetry data.

3. The system of claim 2, the data collection component configured to:

responsive to determining that the first remaining amount of communication data is greater than the second remaining amount of communication data: specify a first amount of vehicle telemetry data to request from the first vehicle; specify a second amount of vehicle telemetry data to request from the second vehicle, the first amount of vehicle telemetry data greater than the second amount of vehicle telemetry data; construct the first data request based upon the first amount of vehicle telemetry data; and construct the second data request based upon the second amount of vehicle telemetry data.

4. The system of claim 1, the travel condition corresponding to a road segment, and the data collection component configured to:

identify a driving pattern of the first vehicle;
responsive to the driving pattern indicating that the first vehicle will travel the road segment above a threshold probability, determine that the first vehicle can provide the vehicle telemetry data; and
construct the first data request to instruct the first vehicle to collect new vehicle telemetry data while traveling the road segment.

5. The system of claim 1, the travel condition corresponding to at least one of a road condition, a vehicle condition, or a traffic condition.

6. The system of claim 1, the vehicle telemetry data corresponding to at least one of a vehicle sensor reading, a temperature, an image, a video, a state of a vehicle component, a weather condition, or a driving behavior of the user derived from at least one of a braking pattern, an acceleration pattern, a deceleration pattern, a turn signal usage, or a driving pattern of the first vehicle.

7. The system of claim 1, the data collection component configured to:

define a data request threshold based upon a projected amount of periodic communication usage by the first vehicle; and
responsive to the vehicle telemetry data not exceeding the data request threshold, construct the first data request to send to the first vehicle.

8. The system of claim 7, the data collection component configured to:

determine the projected amount of periodic communication usage based upon a periodic billing cycle and a current amount of data usage for the periodic billing cycle.

9. The system of claim 7, the data collection component configured to:

responsive to the vehicle telemetry data exceeding the data request threshold, refrain from constructing the first data request to send to the first vehicle.

10. The system of claim 9, the data collection component configured to:

responsive to determining that a new allocation of the first communication data budget has occurred for the first vehicle, construct the first data request to send to the first vehicle.

11. The system of claim 7, the data collection component configured to:

responsive to the vehicle telemetry data exceeding the data request threshold, include an instruction, within the first data request, for the first vehicle to collect measured vehicle telemetry data to send to the data collection component upon the first vehicle receiving a new allocation of the first communication data budget.

12. The system of claim 1, the data collection component configured to:

determine that the travel condition corresponds to a geographical region;
establish communication connections with one or more vehicles within a threshold proximity to the geographical region; and
send data requests, for the vehicle telemetry data, to the one or more vehicles based upon the vehicle telemetry data not exceeding data request thresholds of the one or more vehicles.

13. The system of claim 12, the geographical region comprising at least one of an address range, a road, or locational coordinates.

14. A system for selectively providing vehicle telemetry data to a data collection component, comprising:

a vehicle data provider component configured to: receive a data request for vehicle telemetry data of a vehicle; query one or more vehicle sensors of the vehicle to obtain measured vehicle telemetry data; determine a data request threshold based upon a remaining amount of communication data of a communication data budget for the vehicle; and responsive to the measured vehicle telemetry data not exceeding the data request threshold, send a vehicle telemetry data response, comprising the measured vehicle telemetry data, to a data collection component over a communication connection.

15. The system of claim 14, the vehicle data provider component configured to:

responsive to the measured vehicle telemetry data exceeding the data request threshold: store the measured vehicle telemetry data as stored vehicle telemetry data within a data storage device; and mark the stored vehicle telemetry data for subsequent transmission to the data collection component.

16. The system of claim 15, the vehicle data provider component configured to:

responsive to determining that a new allocation of the communication data budget has occurred for the vehicle, send the vehicle telemetry data response, comprising the stored vehicle telemetry data, to the data collection component over the communication connection.

17. The system of claim 14, the vehicle data provider component configured to:

determine that the vehicle telemetry data corresponds to a geographical location; and
trigger querying the one or more vehicle sensors to obtain the measured vehicle telemetry data based upon a determine that the vehicle is within a threshold proximity of the geographical location.

18. The system of claim 14, the vehicle data provider component configured to:

obtain current vehicle telemetry data during operation of the vehicle;
store the current vehicle telemetry data as stored vehicle telemetry data within a data storage device; and
responsive to receiving a second data request corresponding to the stored vehicle telemetry data: determine a current data request threshold based upon a current remaining amount of communication data of the communication data budget for the vehicle; and responsive to the stored vehicle telemetry data not exceeding the current data request threshold, send a current vehicle telemetry data response, comprising the stored vehicle telemetry data, to the data collection component over the communication connection.

19. The system of claim 14, the vehicle data provider component configured to:

periodically transmit location data of the vehicle to the data collection component.

20. A method for selectively collecting vehicle telemetry data from one or more vehicles, comprising:

identifying a communication data budget for a vehicle;
determining that the vehicle can provide vehicle telemetry data used to model a travel condition;
evaluating data usage information of the vehicle to determine a remaining amount of communication data of the communication data budget;
constructing a data request based upon the vehicle telemetry data and the remaining amount of communication data;
sending the data request to the vehicle;
receiving a vehicle telemetry data response from the vehicle; and
modeling the travel condition based upon the vehicle telemetry data response.
Patent History
Publication number: 20170070616
Type: Application
Filed: Mar 2, 2015
Publication Date: Mar 9, 2017
Applicant: INRIX INC., (KIRKLAND, WA)
Inventor: David DiMeo (Northville, MI)
Application Number: 15/122,734
Classifications
International Classification: H04M 15/00 (20060101); H04B 1/3822 (20060101);