U.S. patent application number 15/122734 was filed with the patent office on 2017-03-09 for dynamic communication data usage.
This patent application is currently assigned to INRIX INC.. The applicant listed for this patent is INRIX INC.. Invention is credited to David DiMeo.
Application Number | 20170070616 15/122734 |
Document ID | / |
Family ID | 54055737 |
Filed Date | 2017-03-09 |
United States Patent
Application |
20170070616 |
Kind Code |
A1 |
DiMeo; David |
March 9, 2017 |
DYNAMIC COMMUNICATION DATA USAGE
Abstract
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).
Inventors: |
DiMeo; David; (Northville,
MI) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
INRIX INC., |
KIRKLAND |
WA |
US |
|
|
Assignee: |
INRIX INC.,
KIRKLAND
WA
|
Family ID: |
54055737 |
Appl. No.: |
15/122734 |
Filed: |
March 2, 2015 |
PCT Filed: |
March 2, 2015 |
PCT NO: |
PCT/US15/18278 |
371 Date: |
August 31, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61946962 |
Mar 3, 2014 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
A61B 5/4845 20130101;
G06F 16/29 20190101; H04W 4/48 20180201; G07C 5/008 20130101; B60W
2050/0089 20130101; B60W 30/143 20130101; G06Q 30/0283 20130101;
G08G 1/093 20130101; A61B 5/024 20130101; G01C 21/3617 20130101;
G08G 1/096775 20130101; H04W 4/029 20180201; G06Q 2240/00 20130101;
G08G 1/07 20130101; G08G 1/0962 20130101; G08G 1/0112 20130101;
H04B 1/3822 20130101; B60W 40/09 20130101; B60W 2710/18 20130101;
G05D 1/0011 20130101; H04M 15/60 20130101; G01C 21/3415 20130101;
G05D 1/021 20130101; G07B 15/063 20130101; H04L 67/02 20130101;
G08G 1/0141 20130101; G08G 1/0965 20130101; G01C 21/3608 20130101;
G05D 1/0088 20130101; G08G 1/096822 20130101; H04W 4/40 20180201;
B60W 2040/0809 20130101; B60W 2554/00 20200201; B60W 2720/10
20130101; G08G 1/0967 20130101; G08G 1/097 20130101; H04L 67/306
20130101; B60W 40/04 20130101; G06Q 50/30 20130101; A61B 5/0476
20130101; B60R 16/0236 20130101; B60W 2540/22 20130101; G08G 1/065
20130101; G06N 20/00 20190101; B60W 2552/00 20200201; H04W 4/42
20180201; G01C 21/3655 20130101; G01C 21/3667 20130101; G07B 15/00
20130101; H04L 9/3247 20130101; G06Q 20/102 20130101; G06Q 40/08
20130101; H04B 7/18504 20130101; B60W 2555/20 20200201; G08G
1/096725 20130101; G08G 1/096741 20130101; B60W 2040/0872 20130101;
A61B 5/02055 20130101; B64C 39/024 20130101; A61B 5/0531 20130101;
B60W 40/08 20130101; G08G 1/0129 20130101; G08G 1/096791 20130101;
G08G 1/096811 20130101; B64C 2201/123 20130101; G01C 21/3682
20130101; G08G 1/0145 20130101; G08G 1/012 20130101; B60W 2710/1044
20130101; G01C 21/3469 20130101; G08G 1/096838 20130101; H04W 4/024
20180201; H04W 4/50 20180201; H04W 12/08 20130101 |
International
Class: |
H04M 15/00 20060101
H04M015/00; H04B 1/3822 20060101 H04B001/3822 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.).
[0005] 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.
[0006] 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
[0007] FIG. 1 is a flow diagram illustrating an exemplary method of
selectively collecting vehicle telemetry data from one or more
vehicles.
[0008] FIG. 2A is a component block diagram illustrating an
exemplary system for selectively collecting vehicle telemetry data
from one or more vehicles.
[0009] FIG. 2B is a component block diagram illustrating an
exemplary system for modeling a travel condition based upon vehicle
telemetry data.
[0010] FIG. 3A is a component block diagram illustrating an
exemplary system for selectively collecting vehicle telemetry data
from a vehicle.
[0011] FIG. 3B is a component block diagram illustrating an
exemplary system for selectively collecting vehicle telemetry data
from a vehicle.
[0012] FIG. 3C is a component block diagram illustrating an
exemplary system for modeling a travel condition based upon vehicle
telemetry data.
[0013] FIG. 4A is a component block diagram illustrating an
exemplary system for selectively collecting vehicle telemetry data
from one or more vehicles.
[0014] FIG. 4B is a component block diagram illustrating an
exemplary system for modeling a travel condition based upon vehicle
telemetry data.
[0015] FIG. 5 is a component block diagram illustrating an
exemplary system for selectively providing vehicle telemetry data
to a data collection component.
[0016] 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.
[0017] FIG. 7 illustrates an exemplary computing environment
wherein one or more of the provisions set forth herein may be
implemented.
DETAILED DESCRIPTION
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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).
[0022] 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).
[0023] 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.
[0024] 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).
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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).
[0034] 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.
[0035] 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).
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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".
[0059] 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.
* * * * *