U.S. patent application number 12/351566 was filed with the patent office on 2009-06-11 for method and system for performing programmatic actions based upon vehicle appropximate locations.
This patent application is currently assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to NEAL J. ALEWINE, JONATHAN L. GABEL, JOSEPH G. RUSNAK, ANTHONY W. WROBEL, JR..
Application Number | 20090150070 12/351566 |
Document ID | / |
Family ID | 36585130 |
Filed Date | 2009-06-11 |
United States Patent
Application |
20090150070 |
Kind Code |
A1 |
ALEWINE; NEAL J. ; et
al. |
June 11, 2009 |
METHOD AND SYSTEM FOR PERFORMING PROGRAMMATIC ACTIONS BASED UPON
VEHICLE APPROPXIMATE LOCATIONS
Abstract
A system for communicating between networked applications and
vehicles that includes a vehicle response server and a vehicle
response agent. The vehicle response server can manage
communications between at least one vehicle and at least one
application remotely located from the vehicle, wherein the
application can provide activation contexts to the vehicle. The
vehicle response agent can be disposed in the vehicle. The vehicle
response agent can receive the activation contexts and determine
event occurrences based in part upon the activation contexts and in
part upon a location of the vehicle relative to previously defined
geographical boundaries specified by the vehicle response
server.
Inventors: |
ALEWINE; NEAL J.; (Lake
Worth, FL) ; GABEL; JONATHAN L.; (Charlotte, NC)
; RUSNAK; JOSEPH G.; (Durham, NC) ; WROBEL, JR.;
ANTHONY W.; (Raleigh, NC) |
Correspondence
Address: |
Novak Druce + Quigg LLP
CityPlace Tower, 525 Okeechobee Blvd., Fifteenth-Floor
WEST PALM BEACH
FL
33401
US
|
Assignee: |
INTERNATIONAL BUSINESS MACHINES
CORPORATION
Armonk
NY
|
Family ID: |
36585130 |
Appl. No.: |
12/351566 |
Filed: |
January 9, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11011635 |
Dec 14, 2004 |
|
|
|
12351566 |
|
|
|
|
Current U.S.
Class: |
701/408 |
Current CPC
Class: |
G06Q 30/0261 20130101;
G06Q 30/0266 20130101; G06Q 30/0251 20130101; G06Q 30/0252
20130101; G01C 21/26 20130101 |
Class at
Publication: |
701/207 |
International
Class: |
G01C 21/00 20060101
G01C021/00 |
Claims
1. A computer-implemented method for facilitating communications
between at least one vehicle and at least one application remotely
located from the vehicle based on vehicle approximate locations,
the method comprising the steps of: defining by a vehicle response
server a plurality of geographical boundaries for a region;
associating a plurality of applications linked to the vehicle
response server with particular ones of the geographical
boundaries; conveying activation contexts and associated actions
for the contexts from the applications to the vehicle response
server; as a vehicle having a vehicle response agent travels,
determining a geographical boundary in which the vehicle resides;
conveying activation contexts of applications associated with the
determined geographical boundary from the vehicle response server
to the vehicle within the determined geographical boundary, wherein
different activation contexts are actuated as the vehicle travels
from one geographical boundary to another; determining by the
vehicle response agent within the vehicle an occurrence of a
context event specified by an activation context based upon vehicle
state information; conveying by the vehicle response agent within
the vehicle to an application associated with the activation
context via the vehicle response server vehicle-specific
information responsive to the occurrence of the context event; and
performing by the application at least one programmatic action
responsive to receiving the vehicle-specific information.
2. The method of claim 1, wherein the vehicle response server
imposes a geographical boundary constraint upon the activation
context received from the at least one remotely located application
before conveying the activation context to the vehicle response
agent within the vehicle.
3. The method of claim 1, further comprising the steps of:
administratively modifying the defined geographical boundaries
within the vehicle response server; and conveying the modified
geographical boundaries to the vehicle response agent within the
vehicle, thereby automatically and dynamically changing conditions
for the occurrence of the context event.
4. The method of claim 1, wherein the vehicle response agent within
the vehicle receives different activation contexts from different
applications, wherein each of the different applications is bound
by the geographical boundaries so that context events are only
actuated when the vehicle is located within a geographical boundary
corresponding to a geographical boundary to which the application
that conveyed the associated activation context is bound.
5. The method of claim 4, wherein the vehicle-specific information
includes a context indication from the vehicle response agent
within the vehicle to the application that conveyed the activation
context that triggered the occurrence.
6. The method of claim 5, wherein the context indication includes
at lest one value obtained from a vehicle sensor of the
vehicle.
7. The method of claim 6, wherein the vehicle sensor indicates a
level of fluid within the vehicle.
8. The method of claim 3, wherein data conveyed between the vehicle
response agent within the vehicle and the different applications
are conveyed to the vehicle response server before being conveyed
to an intended destination, where the vehicle response server is a
communication intermediary between the vehicle response agent
within the vehicle and the different applications.
9. The method of claim 4, wherein data is exchanged between the
vehicle response agent within the vehicle and the vehicle response
server and between the vehicle response server and the different
applications utilizing a standardized vehicle response language
specifically designed for vehicle-based information exchanges.
10. The method of claim 1, wherein the vehicle response server
includes a geofencing application, wherein the programmatic action
performed by the vehicle response agent within the vehicle alerts
the geofencing application when the vehicle travels from one of the
geographical boundaries to another.
11. The method of claim 1, wherein the vehicle response server
includes a traffic mapping application, wherein the programmatic
action performed by the vehicle response agent within the vehicle
provides a speed of the vehicle and a location of the vehicle to
the traffic mapping application.
12. The method of claim 1, wherein the vehicle response server
includes a Web browser through which a vehicle tracking application
is accessed, wherein the vehicle response agent within the vehicle
provides location information to the vehicle tracking
application.
13. A computer-implemented system for facilitating communications
between at least one vehicle and at least one application remotely
located from the vehicle based on vehicle approximate locations,
the system comprising: a vehicle response server configured to
manage communications between the at least one vehicle and at least
one application remotely located from the vehicle, including:
define a plurality of geographical boundaries for a region;
associate a plurality of applications linked to the vehicle
response server with particular ones of the geographical
boundaries; receive activation contexts and associated actions for
the contexts from the applications; determine a geographical
boundary in which a vehicle resides; and convey activation contexts
of applications associated with the determined geographical
boundary from the vehicle response server to the vehicle within the
determined geographical boundary, wherein different activation
contexts are actuated as the vehicle travels from one geographical
boundary to another; a vehicle response agent disposed in the
vehicle configured to determine an occurrence of a context event
specified by an activation context based upon vehicle state
information; and convey to an application associated with the
activation context via the vehicle response server vehicle-specific
information responsive to the occurrence of the context event; and
wherein the application performs at least one programmatic action
responsive to receiving the vehicle-specific information.
14. The system of claim 13, the vehicle response agent further
comprising: a context processor configured to translate said
activation contests into vehicle-specific conditions for the event
occurrences; a communication engine configured to wirelessly
exchange digitally encoded information with the vehicle response
server; and a sensor monitor configured to receive vehicle sensor
input and correlate the vehicle sensor input to the vehicle
specific conditions.
15. The system of claim 13, wherein the vehicle response server and
the vehicle response agent utilize a vehicle response language that
includes data types and functions specifically defined for
obtaining and processing vehicle sensor input.
16. A machine-readable storage having stored thereon, a computer
program having a plurality of code sections, said code sections
executable by a machine for causing the machine to perform the
steps of: defining by a vehicle response server a plurality of
geographical boundaries for a region; associating a plurality of
applications linked to the vehicle response server with particular
ones of the geographical boundaries; conveying activation contexts
and associated actions for the contexts from the applications to
the vehicle response server; as a vehicle having a vehicle response
agent travels, determining a geographical boundary in which the
vehicle resides; conveying activation contexts of applications
associated with the determined geographical boundary from the
vehicle response server to the vehicle within the determined
geographical boundary, wherein different activation contexts are
actuated as the vehicle travels from one geographical boundary to
another; determining by the vehicle response agent within the
vehicle an occurrence of a context event specified by an activation
context based upon vehicle state information; conveying by the
vehicle response agent within the vehicle to an application
associated with the activation context via the vehicle response
server vehicle-specific information responsive to the occurrence of
the context event; and performing by the application at least one
programmatic action responsive to receiving the vehicle-specific
information.
17. The machine-readable storage of claim 16, wherein the
in-vehicle device receives different activation contexts from
different applications, wherein each of the different applications
is bound by the geographical boundaries so that context events are
only actuated when the vehicle is located within a geographical
boundary corresponding to a geographical boundary to which the
application that conveyed the associated activation context is
bound.
18. The machine-readable storage of claim 17, the step of
performing at least one previously determined programmatic action
further comprises the step of: conveying a context indication from
the in-vehicle device to the application that conveyed the
activation context that triggered the occurrence.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of, and accordingly
claims the benefit of, U.S. patent application Ser. No. 11/011,635,
filed with the U.S. Patent and Trademark Office on Dec. 14, 2004,
now U.S. Pat. No. ______, the disclosure of which is hereby
incorporated by reference.
BACKGROUND
[0002] 1. Field of the Invention
[0003] The present invention relates to the fields of computer
software and networking and, more particularly, to a technique
through which programmatic actions can be performed based upon
vehicle approximate locations.
[0004] 2. Description of the Related Art
[0005] Many applications exist that would benefit from knowing an
approximate location of a vehicle and being able to trigger a
programmatic action to occur within the vehicle based upon this
approximate location or being able to take a programmatic action
based upon the approximate location. Applications that would
benefit from vehicle proximate location information include a vast
variety of applications, such as push advertising, vehicle
tracking, traffic mapping, vehicle navigation, and the like.
[0006] For example, a gas station application may want to present a
"coupon" to a customer low on gas when that customer is approaching
an associated gas station. In such an example, an in-vehicle
programmatic action of informing the vehicle driver of the "coupon"
can be executed. Further, an extra vehicle programmatic action can
also be executed that causes the gas station to automatically apply
the coupon when the targeted vehicle pays for fuel at a pump.
[0007] Despite the potential benefits of communicating data between
vehicles and remotely located applications, conventional
technologies have failed to overcome difficulties associated with
remote applications communicating with vehicles. One technical
difficulty relates to communications between several mobile
vehicles and several remote applications hosted at a fixed
location. While wireless communications are possible with a vehicle
using methodologies such as those used for mobile telephony and
vehicle GPS, these methodologies generally require either a
constant communication connection or periodic status polling/status
response messages to be conveyed between each vehicle and each
remote application. Such communication methodologies are designed
for point-to-point information exchanges and do not provide easily
scalable solutions capable of being ported to vehicle/application
communications. That is, when the number of remote applications and
the number of vehicles grow, communications complexity and cost can
grow geometrically. What is needed is a scalable, cost efficient,
and secure technology for permitting applications to communicate
with vehicles, resulting in context dependent programmatic actions
that are based in part upon vehicle location.
SUMMARY OF THE INVENTION
[0008] One aspect of the present invention can include a system for
communicating between networked applications and vehicles. The
system can include a vehicle response server and a vehicle response
agent. The vehicle response server can manage communications
between at least one vehicle and at least one application remotely
located from the vehicle, where the application can provide
activation contexts to the vehicle. The vehicle response agent can
be disposed in the vehicle. The vehicle response agent can receive
the activation contexts and determine event occurrences based in
part upon the activation contexts and in part upon a location of
the vehicle relative to previously defined geographical boundaries
specified by the vehicle response server.
[0009] Another aspect of the present invention includes a
computerized method where an in-vehicle computing device
communicates with at least one computing device outside the
vehicle. The computerized method can include the step of defining
geographical boundaries through which at least one vehicle
travelway extends. An activation context can be conveyed from the
at least one remote computing device to an in-vehicle device,
wherein the activation context is dependent upon the geographical
boundaries. As a vehicle travels along the vehicle travelway, the
geographical boundary in which the vehicle resides can be
determined. Additionally, an in-vehicle device can determine an
occurrence of a context event specified by the activation context.
The occurrence can be based in part upon the determined
geographical boundary. The in-vehicle device can perform at least
one previously determined programmatic action associated with the
context event responsive to the occurrence. Different context
events are actuated as the vehicle travels along the travelway
based upon vehicle location as defined by the geographical
boundaries.
[0010] It should be noted that the invention can be implemented as
a program for a controlling computer to implement the functions
described herein, or as a program for enabling a computer to
perform the process corresponding to the steps disclosed herein.
This program may be provided by storing the program in a magnetic
disk, an optical disk, a semiconductor memory, any other recording
medium, or distributed via a network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] There are shown in the drawings, embodiments which are
presently preferred, it being understood, however, that the
invention is not limited to the precise arrangements and
instrumentalities shown herein.
[0012] FIG. 1 is a schematic diagram illustrating a system in which
vehicles communicate with remotely located applications in
accordance with an embodiment of the inventive arrangements
disclosed herein.
[0013] FIG. 2 is a schematic diagram illustrating a system in which
applications can obtain and utilize vehicle context information in
accordance with an embodiment of the inventive arrangements
disclosed herein.
[0014] FIG. 3 is a table including several data items that can be
used by a vehicle response language in accordance with an
embodiment of the inventive arrangements disclosed herein.
[0015] FIG. 4 is a table including comparison operators that can be
used by a vehicle response language in accordance with an
embodiment of the inventive arrangements disclosed herein.
[0016] FIG. 5 is a table including several vehicle response
language functions in accordance with an embodiment of the
inventive arrangements disclosed herein.
[0017] FIG. 6 is a flow chart of a method for finding a vehicle
proximate location in accordance with an embodiment of the
inventive arrangements disclosed herein.
DETAILED DESCRIPTION OF THE INVENTION
[0018] FIG. 1 is a schematic diagram illustrating a system 100 in
which vehicles communicate with remotely located applications in
accordance with an embodiment of the inventive arrangements
disclosed herein.
[0019] In system 100, a grid is established across a designated
geographical region. A vehicle travelway 150 can span multiple
defined segments of the grid. As a vehicle 132, 134 travels along
the travelway, information can be conveyed between the vehicle 132,
134 and one or more remotely located computing devices 122,
124.
[0020] The computing devices 122, 124 can be communicatively linked
to each other via network 104 so that information can be exchanged
between the remotely located devices. Additionally, device 122 can
be communicatively linked to a wireless transceiver 112 via network
102 and device 124 can be communicatively linked to a wireless
transceiver 114 via network 106. Wireless transceiver 112 can be
within range of vehicle 132, thereby facilitating communications
between vehicle 132 and device 122. Similarly, wireless transceiver
114 can be within communication range of vehicle 134. As vehicle
132 and vehicle 134 travel along travelway 150, different
transceivers can be used to maintain communication between remotely
located devices 122, 124 and vehicles 132, 134.
[0021] Devices 122, 124 can host multiple applications. These
applications can interact with the vehicles by conveying event
triggering conditions or activation contexts to the vehicles 132,
134. The vehicles 132 and 134 can receive the activation contexts
and determine based upon state information within an in-vehicle
computing device whether one or more contexts events defined in
part by the activation contexts occur. These context events can
result in the execution of one or more context-dependent
programmatic actions.
[0022] Additionally, system 100 can be configured so that the
different applications only communicate with vehicles located
within defined geographical boundaries. For example, applications
hosted on device 122 may define application contexts that apply
only to vehicles located in the grid blocks defined by Grid A-I,
Grid A-II, and Grid B-II. Similarly, applications hosted on device
124 may define activation contexts that apply only to vehicles
located in the grid block defined by Grid E-V. Vehicles 132, 134
can ignore application contexts that specify conditions for
geographical boundaries outside the vehicle's present location.
[0023] It should be noted that the present invention can be
utilized in conjunction with any definable geographical boundary
and the invention is not limited to a uniform grid that is shown in
system 100. That is, geographical boundaries can vary in shape and
are not intended to be limited to square grid units. Often, since
wireless transceivers 112, 114 have approximately circular coverage
areas, for example, circular geographical boundaries can be
preferred. Other factors like terrain, road layouts, and the like,
however, can result in rectangular geographical boundaries, oblong
geographical boundaries, and the like being preferred.
Additionally, even within a region, geographical boundaries need
not be uniform meaning that one geographical boundary can be a
different size and shape than another. Moreover, multiple logically
defined grids can be specified for a given region, where different
logical grids (each defining geographical boundaries for the same
region) can be used by different applications.
[0024] It should also be noted that the vehicles 132, 134 can
represent any transportation mechanism and that the travelway 150
can be any suitable pathway upon which the vehicle 132, 134
travels. For example, when the vehicle 132, 134 is a car, truck, or
van, the travelway 150 can include a road, highway, bridge, and the
like. When the vehicle 132, 134 is a boat, the travelway 150 can
include a river or other waterway. When the vehicle 132, 134 is a
train, the travelway 150 can include train tracks. When the vehicle
132, 134 is a plane, the travelway 150 can include a flight
path.
[0025] FIG. 2 is a schematic diagram illustrating a system 200 in
which applications can communicate with vehicles in accordance with
an embodiment of the inventive arrangements disclosed herein. In
one embodiment, the system 200 can be used for communications
between vehicle 132 and device 122 and between vehicle 134 and
device 124.
[0026] System 200 can include at least one vehicle 202, a vehicle
response server 220, and one or more applications 230. The vehicle
202 can be any device in, upon, or by which a person or property is
or may be transported or drawn upon a travelway, excepting devices
moved by human power or used exclusively upon rails or tracks. For
example, the vehicle 202 can include an automobile, truck, van,
motorcycle, moped, recreational vehicle (RV), and other such
transportation devices.
[0027] The vehicle 202 can include an in-vehicle device within
which a vehicle response agent 203 resides. The vehicle response
agent 203 can include a machine-readable set of programmatic
instructions configured to receive an activation context 250 from
the vehicle response server 220, extract conditions from the
activation context 250 to generate at least one monitored
vehicle-specific event, to monitor for the event occurrence, and to
wirelessly convey an indication of the event, which can be referred
to as a context indication 252, to the vehicle response server 220.
The activation context 250 can be associated with one or more
geographical boundaries in which the vehicle 202 is located. The
activation context 250 can be selectively enabled or disabled in
accordance with the associated geographical boundaries.
[0028] In one embodiment, the vehicle response agent 203 can
include a context processor 204, a communication engine 206, and a
sensor monitor 208. The context processor 204 can translate one or
more activation contexts 250 into one or more vehicle-specific
events. That is, the context processor 204 can place generic
vehicle agnostic queries into a vehicle-specific context. The
context processor 204 can then monitor input from various sensors
of the vehicle 202 to determine if the vehicle-specific events
occur. When the events do occur, the vehicle response agent 203 can
take one or more actions specified within the activation context
250. For example, the vehicle response agent 203 can convey the
context indication 252 to the vehicle response server 220.
[0029] The communication engine 206 can establish a communication
link across network 242 with the vehicle response server 220
through which digitally encoded information can be conveyed, such
as the activation context 250 and the context indication 252. The
network 242 can be any wireless network, including, but not limited
to one or more wireless local area networks, a satellite network, a
radio network, a mobile telephony network, and the like.
[0030] The sensor monitor 208 can be a memory and processing unit
configured to receive vehicle sensor input. The sensor monitor 208
can correlate the vehicle sensor input into vehicle specific
conditions, which in turn can activate the vehicle specific events
established by the context processor 204. Sensor monitor 208 can
include any of a variety of sensors including, but not limited to,
fluid level sensors, temperature sensors, air pressure sensors,
navigational sensors, speed and distance sensors, and other sensors
that measure vehicle-specific values.
[0031] The sensor monitor 208 can be linked to a vehicle's computer
control module, a Global Positioning System (GPS), a mobile
telephony system, electronic controls such as powered windows, and
other in-vehicle systems. Additionally, sensors not typically
included within vehicle 202 can be added to the vehicle 202 to
provide input for the sensor monitor 208. For example, a barometer
can be added to the vehicle 202 to provide environmental input to
one or more weather-based applications 230. In another example, a
pre-paid toll sensor/transceiver can be added to the vehicle 202 to
record/transmit information to toll-related applications 230.
[0032] The vehicle response server 220 can be any computing device
that manages communications between at least one vehicle 202 and at
least one application 220 remotely located from the vehicle 202.
The vehicle response server 220 can consolidate requests from the
various applications 230 so that the vehicle 202 does not receive a
series of redundant information requests. The vehicle response
server 220 can also include security and authentication routines to
ensure that only those application requests 230 approved by the
vehicle 202 owner are conveyed to the vehicle. Consequently, the
vehicle response server 220 can function as a firewall that only
permits approved and sanitized information to be conveyed to the
vehicle response agent 203, where sanitation can check messages for
viruses and other malicious software before the messages are
conveyed to the vehicle 202.
[0033] In one embodiment, the vehicle response server 220 can
represent a single server or network element. The vehicle response
server 220 can also be a logical entity consisting of a multitude
of geographically distributed hardware components that are
communicatively linked to one another via a network.
[0034] Each application 230 can include a set of machine-readable
instructions designed to perform a specific instruction.
Application 230 can include one program or a group of programs that
are designed to automatically execute at least one
context-dependent programmatic action based upon an event
occurrence within vehicle 202. Application 230 can be an
application hosted by the vehicle response server 220 and can be an
application remotely located and functionally independent of the
vehicle response server 220.
[0035] Each application 230 can convey a message 254 to the vehicle
response server 220 that indicates a set of conditions for
triggering the context dependent programmatic action. The vehicle
response sever 220 can trigger the context dependent action via
message 256, which can include any and all parameters needed by the
application 230, such as vehicle specific values derived from a
sensor or data store accessible to the vehicle response server
220.
[0036] Each application can be linked to the vehicle response
server 220 through a network 244. The network 244 can represent any
communication mechanism capable of conveying digitally encoded
information. More specifically, the network 244 can include a
computer network such as a Local Area Network (LAN) or a Wide Area
Network (WAN), a telephony network such as a Public Switched
Telephony Network (PSTN) or a mobile telephony network, a cable
network, a satellite network, a broadcast network, and the like.
The network 244 can use wireless as well as line-based
communication pathways.
[0037] Further, the network 244, as well as the network 242, can
encode information in accordance with any communication protocol,
such as a packet-based communication protocol or a circuit based
communication protocol. Networks 242 and 244 can also convey
information in a secure fashion, where conveyed information can be
encrypted before transmittal, thereby requiring an information
recipient to utilize a corresponding decryption key (password,
certificate, public key, and private key) to access the conveyed
information in a comprehensible fashion.
[0038] In one contemplated arrangement, the vehicle response agent
203, the vehicle response server 220, the application 230, and
combinations thereof can communicate using messages written in a
defined vehicle response language that includes data types and
functions specifically defined for obtaining and processing vehicle
context information.
[0039] FIG. 3 is a table 300 including several data items that can
be used by a vehicle response language in accordance with an
embodiment of the inventive arrangements disclosed herein. Table
300 can include, but is not limited to data items for vehicle
identification, time, longitude, latitude, speed, odometer,
direction, engine oil level, engine temperature, engine tachometer,
tank fuel level, and wiper settings. Each data item has an
associated short identifier, a unit type, and a brief
description.
[0040] As shown in table 300, Vehicle ID has a short identifier of
ID, can be a string value, and can uniquely define a vehicle. Time
has a short identifier of TIME, can be a time value, and can be
used for expression evaluation. Longitude has a short identifier of
LONG, can have a unit type of degrees, and can be a GPS supplied
longitude value for a vehicle. Latitude has a short identifier of
LAT, can have a unit type of degrees, and can be a GPS supplied
latitude value for a vehicle. Speed has a short identifier of
SPEED, can have a unit type of miles per hour or kilometers per
hour, and can represent a current vehicle speed. Odometer has a
short identifier of ODO, can have a unit type of miles or
kilometers, and can represent a vehicle's permanent or trip
odometer value. Direction has a short identifier of DIR, can have a
unit type of degrees, and can represent a compass bearing of the
vehicle. Engine Oil Level has a short identifier of OIL, can have a
unit type of quarts or liters, and can represent a level of oil for
a vehicle. Engine Temperature has a short identifier of TEMP, can
have a unit type of degrees Fahrenheit or Celsius, and can specify
an engine temperature. Engine Tachometer has a short identifier of
TACH, can have a unit type of revolutions per minute, and can be a
tachometer value for the vehicle. Tank Fuel Level has a short
identifier of FUEL, can have a unit type of gallons or liters, and
can signify how much gas is currently in a vehicle's tank. Wiper
Setting has a short identifier of WIPER, can have a unit type of
setting level, and can correspond to the current setting of the
windshield wipers of a vehicle.
[0041] It should be appreciated that the data types of table 300
are not intended as an exhaustive list of data types for the
vehicle response language, and that other similar data types are
contemplated herein. For example, data types for headlamp setting,
battery charge, tire pressure, exterior temperature, turn signals,
radio station, radio volume, seat position, window setting, rear
view mirror adjustment, and other vehicle specific data types can
be included in the vehicle response language.
[0042] It should also be appreciated that the data types of table
300 can be used not only to obtain current vehicle conditions but
may also be used to remotely adjust these conditions. For example,
an authorized remote application can use vehicle response language
data types to close a window or lock a door of a vehicle that has
been stationary for a predetermined period.
[0043] FIG. 4 is a table 400 including comparison operators that
can be used by a vehicle response language in accordance with an
embodiment of the inventive arrangements disclosed herein. The
comparison operators can include operators for EQUALS, LESS THAN,
GREATER THAN, LESS THAN OR EQUAL TO, GREATER THAN OR EQUAL TO, NOT
EQUAL, and NOT. The vehicle response language is not limited to
these comparison operators, and other operators can be utilized.
For example, a SYNONYM operator (not shown) can be utilized by the
vehicle response language.
[0044] In addition to the comparison operators, logical operators
including, but not limited to, AND, OR, XOR, and NOT can be used to
form logical expressions. Arithmetic functions can also be used to
mathematically manipulate compatible numeric data types. It should
be appreciated that expressions can be nested, parenthetically
grouped, and negated. Further, the order of operation processing
and nesting robustness can be configured by design implementers to
suit programming needs for which the vehicle response language is
intended to satisfy.
[0045] FIG. 5 is a table 500 including several vehicle response
language functions in accordance with an embodiment of the
inventive arrangements disclosed herein. The functions can include,
but are not limited to, a DistanceTo function, a GridLocation
function, a Change function, and a PercentChange function, each
having defined operands and return values.
[0046] The DistanceTo function can have a two-way location vector
operand and can return a distance. The GridLocation function can
have operands for start longitude, longitude division, end
longitude, start latitude, latitude division, and end latitude.
GridLocation can return an integral grid sector identifier for
location grid. Change can have an input parameter of varying type
and can return a positive/negative value indicating a change in the
input parameter since a designated time, which can be the last time
the Change function was called. PercentChange can be similar to
Change, except the return value is expressed as a percentage.
[0047] It should be appreciated that the functions of the vehicle
response language are not to be limited to those shown in table 500
and that any of a variety of other functions are contemplated
herein. For example, the vehicle response language can include
functions for remotely adjusting a data type to a user-established
setting, obtaining a data type value, presenting a notification to
a driver, and other such functions.
[0048] FIG. 6 is a flow chart of a method 600 for finding a vehicle
proximate location in accordance with an embodiment of the
inventive arrangements disclosed herein. Method 600 can be
performed in the context of system 100 and/or system 200 as well as
within the context of any other system in which programmatic
actions that are dependent upon vehicle approximate locations
occur.
[0049] The method 600 can begin at step 605 where a vehicle
response server can define several geographical boundaries for a
region. In step 610, applications linked to the vehicle response
server can be associated with particular ones of the defined
geographical boundaries. In step 615, the applications can convey
application contexts and associated actions for the contexts to the
vehicle response server.
[0050] In step 620, the vehicle response server can convey the
activation contexts and geographical restrictions for the contexts
to one or more vehicles. In one embodiment, only those vehicles
within a given geographical boundary are conveyed activation
contexts that apply to that boundary. The conveyance of activation
contexts can occur through any of a variety of wireless
communication mechanisms. These communication mechanisms can
include both targeted and untargeted mechanisms with the untargeted
communication mechanisms being preferred for areas with significant
population density for reasons of scalability.
[0051] For example, the voice response server can broadcast the
activation contexts for a geographical area from a wireless
transceiver located within that area. In another example, the voice
response server can use a mobile telephony network to establish a
communication link with a vehicle and convey over this link the
activation context information. Mobile telephony networks can be
used to supplement coverage areas having a relatively low user
population, which would not justify the expense of dedicated
broadcast transceivers.
[0052] In step 625, after the activation context has been conveyed
to a vehicle, an in-vehicle device can determine based upon vehicle
state information and the activation context when one or more
context events occur. In step 630, one or more in-vehicle
programmatic actions can occur responsive to event occurrences.
Particular ones of these programmatic actions can result in
vehicle-specific information being conveyed to one or more remote
applications linked to the vehicle response server. The
vehicles-specific information can include information obtained from
vehicle sensors, such as a fluid level of the vehicle, a speed of
the vehicle, and the like. The remote applications can perform
programmatic actions responsive to receiving the vehicle-specific
information.
[0053] For example, in one embodiment, a remote application can
includes a geofencing application. A programmatic action performed
by the in-vehicle device can alerts the geofencing application when
the vehicle travels from one of the geographical boundaries to
another. The geofencing application can then take appropriate
responsive actions, such as informing an agent that the vehicle has
traveled beyond defined geofenced areas for that vehicle.
[0054] In another situation, the remote application can include a
traffic mapping application. A programmatic action performed by the
in-vehicle device can provides a speed of the vehicle and a
location of the vehicle to the traffic mapping application. The
traffic application can use information conveyed from a plurality
of vehicles to determine if traffic is flowing smoothly, if traffic
is slow, or if traffic has stopped. The traffic application can
provide suggestions based upon discerned traffic patterns to
dynamically re-route vehicles from high congestion travelways to
alternative travelways.
[0055] In still another embodiment, a remote application can be
vehicle tracking application that is accessible by client computing
devices via a Web browser. A programmatic action of the in-vehicle
device can provide location information to the vehicle tracking
application. This location information can be presented to
authorized users via the Web browser.
[0056] While the in-vehicle device and remote applications are
performing programmatic actions, the vehicle itself can be
traveling from one geographical boundary to another. Thus in step
635, a determination (made from within the in-vehicle device, from
within the vehicle response server, or both) can be made that the
vehicle travels from one geographical boundary to another. In step
640, activation contexts corresponding to the new geographical
boundary can be enabled and activation contexts corresponding to
the old geographical boundary can be deactivated. The method can
then loop from step 640 to step 620 where new activation context
for the new boundaries can be conveyed to the vehicles and
responsive programmatic actions can be taken.
[0057] It should be appreciated that the in-vehicle device can
receive different activation contexts from different applications.
The received activation contexts can be bound by geographical
boundaries so that context events are only actuated when the
vehicle is located within a geographical boundary corresponding to
a geographical boundary to which the application that conveyed the
associated activation context is bound.
[0058] It should be noted that when data is a standardized vehicle
response language specifically designed for vehicle-based
information exchanges can be used to exchange data between the
in-vehicle device and the vehicle response server and between the
vehicle response server and the different applications. For
example, the standardized vehicle response language used in
particular embodiment of method 600 can include items defined in
FIG. 3, comparison operators defined in FIG. 4, and/or functions
define in FIG. 5.
[0059] The present invention may be realized in hardware, software,
or a combination of hardware and software. The present invention
may be realized in a centralized fashion in one computer system, or
in a distributed fashion where different elements are spread across
several interconnected computer systems. Any kind of computer
system or other apparatus adapted for carrying out the methods
described herein is suited. A typical combination of hardware and
software may be a general purpose computer system with a computer
program that, when being loaded and executed, controls the computer
system such that it carries out the methods described herein.
[0060] The present invention also may be embedded in a computer
program product, which comprises all the features enabling the
implementation of the methods described herein, and which when
loaded in a computer system is able to carry out these methods.
Computer program in the present context means any expression, in
any language, code or notation, of a set of instructions intended
to cause a system having an information processing capability to
perform a particular function either directly or after either or
both of the following: a) conversion to another language, code or
notation; b) reproduction in a different material form.
[0061] This invention may be embodied in other forms without
departing from the spirit or essential attributes thereof.
Accordingly, reference should be made to the following claims,
rather than to the foregoing specification, as indicating the scope
of the invention.
* * * * *