Patent Publication Number: US-7212916-B2

Title: Obtaining contextual vehicle information

Description:
BACKGROUND 
   1. Field of the Invention 
   The present invention relates to the fields of computer software and networking and, more particularly, to a technique through which applications can obtain contextual vehicle information. 
   2. Description of the Related Art 
   Most vehicles include a multitude of sensors that produce output, which can be presented to a vehicle driver to inform the driver of a condition pertaining to the vehicle. Sensors can indicate, for example, fuel level, oil pressure, engine temperature, vehicle speed, battery charge, and the like. Other vehicle sensors, such as a thermometer, a compass, and a Global Positioning System (GPS), can indicate an environmental state surrounding the vehicle. 
   Many remote applications would benefit from receiving vehicle input, and being able to take programmatic actions responsive to this input. For example, a gas station application may want to present a coupon to a customer low on gas when approaching an associated gas station. In another example, a parent may want to monitor the fluid levels and warning indicators on a parent-owned vehicle used by a teenager. 
   Conventional technologies, however, have failed to overcome difficulties associated with remote applications utilizing contextual information from 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. 
   One sociological difficulty in permitting remote applications to obtain contextual vehicle information pertains to driver privacy and safety. Vehicle contextual information can be used to track a driver&#39;s location, habits, and routines to an extent that makes many drivers extremely uncomfortable. Further, companies providing access to the vehicle contextual information can have liability and customer relation concerns when using unsecured information conveyance techniques. What is needed is a scalable, cost efficient, and secure technology for permitting remotely located applications to obtain contextual vehicle information. 
   SUMMARY OF THE INVENTION 
   One aspect of the present invention can include a system for permitting remotely located applications to obtain information about vehicle conditions and responsively perform programmatic actions based upon the vehicle conditions/context. The system can include a vehicle response server and a vehicle response agent. The vehicle response server can manage communications between one or more vehicles and at least one application that is remotely located from each vehicle. The application can automatically execute at least one context-dependent programmatic action based upon an event occurrence triggered by vehicle sensor input. The vehicle response agent, which resides within the vehicle, can receive an activation context that specifies conditions for the event occurrence. The vehicle response agent can then monitor the vehicle for the event occurrence and, when appropriate, wirelessly convey an indication of the event occurrence to the vehicle response server. The indication can result in the automatic execution of the at least one context-dependent programmatic action at the remote location. 
   Another aspect of the present invention can include a method for obtaining contextual vehicle information. The method can include the step of conveying an activation context from a remote computing device to an in-vehicle device. The activation context can be associated with at least one context-dependent programmatic action. The in-vehicle device can determine an occurrence of a context event specified by the activation context. Responsive to the occurrence, a context indication can be conveyed to the remote computing device, where the context indication can cause the context-dependent programmatic action to execute. The vehicle and the remote computing device can be communicatively linked through a wireless network. 
   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 
     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. 
       FIG. 1  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. 
       FIG. 2  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. 
       FIG. 3  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. 
       FIG. 4  is a table including several vehicle response language functions in accordance with an embodiment of the inventive arrangements disclosed herein. 
       FIG. 5  is a flow chart of an interaction between a gas station and a vehicle in accordance with an embodiment of the inventive arrangements disclosed herein. 
       FIG. 6  is a flow chart of a method for obtaining vehicle context information to be used by one or more applications in accordance with an embodiment of the inventive arrangements disclosed herein. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1  is a schematic diagram illustrating a system  100  in which applications can obtain and utilize vehicle context information in accordance with an embodiment of the inventive arrangements disclosed herein. System  100  can include at least one vehicle  102 , a vehicle response server  120 , and one or more applications  130 . 
   The vehicle  102  can be any device in, upon, or by which a person or property is or may be transported or drawn upon a highway, excepting devices moved by human power or used exclusively upon rails or tracks. For example, the vehicle  102  can include an automobile, truck, van, motorcycle, moped, recreational vehicle (RV), and other such transportation devices. 
   The vehicle  102  can include an in-vehicle device within which a vehicle response agent  103  resides. The vehicle response agent  103  can include a machine-readable set of programmatic instructions configured to receive an activation context  150  from the vehicle response server  120 , extract conditions from the activation context  150  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  152 , to the vehicle response server  120 . 
   In one embodiment, the vehicle response agent  103  can include a context processor  104 , a communication engine  106 , and a sensor monitor  108 . The context processor  104  can translate one or more activation contexts  150  into one or more vehicle-specific events. That is, the context processor  104  can place generic vehicle agnostic queries into a vehicle-specific context. The context processor  104  can then monitor input from various sensors through the sensor monitor  108  of the vehicle  102  to determine if the vehicle-specific events occur. When the events do occur, the vehicle response agent  103  can take one or more actions specified within the activation context  150 . For example, the vehicle response agent  103  can convey the context indication  152  to the vehicle response server  120 . 
   The communication engine  106  can establish a communication link across network  142  with the vehicle response server  120  through which digitally encoded information can be conveyed, such as the activation context  150  and the context indication  152 . The network  142  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. 
   The sensor monitor  108  can be a memory and processing unit configured to receive vehicle sensor input. The sensor monitor  108  can correlate the vehicle sensor input into vehicle specific conditions, which in turn can activate the vehicle specific events established by the context processor  104 . Sensor monitor  108  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. 
   The sensor monitor  108  can be linked to a vehicle&#39;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  102  can be added to the vehicle  102  to provide input for the sensor monitor  108 . For example, a barometer can be added to the vehicle  102  to provide environmental input to one or more weather-based applications  130 . In another example, a pre-paid toll sensor/transceiver can be added to the vehicle  102  to record/transmit information to toll-related applications  130 . 
   The vehicle response server  120  can be any computing device that manages communications between at least one vehicle  102  and at least one application  130  remotely located from the vehicle  102 . The vehicle response server  120  can consolidate requests from the various applications  130  so that the vehicle  102  does not receive a series of redundant information requests. The vehicle response server  120  can also include security and authentication routines to ensure that only those application requests  130  approved by the vehicle  102  owner are conveyed to the vehicle. Consequently, the vehicle response server  120  can function as a firewall that only permits approved and sanitized information to be conveyed to the vehicle response agent  103 , where sanitation can check messages for viruses and other malicious software before the approved messages are conveyed to the vehicle  102 . 
   In one embodiment, the vehicle response server  120  can represent a single server or network element. The vehicle response server  120  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. 
   Each application  130  can include a set of machine-readable instructions designed to perform a specific instruction. Application  130  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  102 . Application  130  can be an application hosted by the vehicle response server  120  and/or can be an application remotely located and functionally independent of the vehicle response server  120 . 
   Each application  130  can convey a message  154  to the vehicle response server  120  that indicates a set of conditions for triggering the context dependent programmatic action. The vehicle response server  120  can trigger the context dependent action via message  156 , which can include any and all parameters needed by the application  130 , such as vehicle specific values derived from a sensor or data store accessible to the vehicle response server  120 . 
   Each application  130  can be linked to the vehicle response server  120  through a network  144 . The network  144  can represent any communication mechanism capable of conveying digitally encoded information. More specifically, the network  144  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  144  can use wireless as well as line-based communication pathways. 
   Further, the network  144 , as well as the network  142 , can encode information in accordance with any communication protocol, such as a packet-based communication protocol or a circuit based communication protocol. Networks  142  and  144  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, private key) to access the conveyed information in a comprehensible fashion. 
   In one contemplated arrangement, the vehicle response agent  103 , the vehicle response server  120 , the application  130 , 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. 
     FIG. 2  is a table  200  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  200  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. 
   As shown in table  200 , 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&#39;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&#39;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. 
   It should be appreciated that the data types of table  200  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. 
   It should also be appreciated that the data types of table  200  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. 
     FIG. 3  is a table  300  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. 
   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. 
     FIG. 4  is a table  400  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. 
   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. 
   It should be appreciated that the functions of the vehicle response language are not to be limited to those shown in table  400  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. 
     FIG. 5  is a flow chart of an interaction  500  between a gas station application and a vehicle in accordance with an embodiment of the inventive arrangements disclosed herein. The interaction  500  can be performed in the context of a vehicle communication system, such as the system  100  of  FIG. 1 . 
   Interaction  500  can begin in step  505 , where a gas station application can connect with a context server, which in one embodiment can include a vehicle response server  120  of  FIG. 1 . In step  510 , the gas station application can submit a request to be notified when any vehicle that has less than half a tank of fuel passes within ten miles of a designated gas station. In step  515 , the context server can convey the gas station defined context event (within ten miles having less than half a tank of fuel) to one or more proximate vehicles. 
   In one embodiment, a proximate vehicle can include any vehicle within a communication range of the context server or a transceiver controlled by the context server. In another embodiment, the proximate vehicle can refer to any vehicle a predefined distance from the gas station. For example, a proximate vehicle can be any vehicle within 15 miles of a gas station traveling in the general direction of the gas station. In another example, the gas station can reside within a defined grid, and a proximate vehicle can be any vehicle traveling within that grid. 
   In step  520 , an in-vehicle device can receive the context event from the context server. In one embodiment, the in-vehicle device can include the vehicle response agent  103  of  FIG. 1 . In step  525 , the in-vehicle device can monitor for the gas station event. In step  530 , the in-vehicle device can determine that the gas station event has occurred (within ten miles and having less than half a tank of gas). In step  535 , the in-vehicle device can indicate the event occurrence to the context server. In step  540 , the context server can convey the event occurrence to the gas station application. The context server can also convey additional vehicle information to the gas station application. The additional information can be obtained from the in-vehicle device or from a data store pertaining to the vehicle that is maintained by the context server. 
   In step  545 , the gas station application can generate an electronic coupon customized for the vehicle. In step  550 , the gas station application can send the coupon to the context server. In step  555 , the context server can convey the electronic coupon to the in-vehicle device. In step  560 , the in-vehicle device can present the coupon to a driver via a vehicle user interface. 
   In one embodiment, the interaction  500  can utilize a vehicle response language having characteristics like those presented in  FIGS. 2 ,  3 , and  4 . In such an embodiment, the in-vehicle device can use the following pseudo code routine to detect the event of passing within 10 miles of a gas station when the vehicle has less than half a tank of fuel. The event triggers the conveyance of the vehicle ID and Tank Fuel Level to the context server. 
   IF Fuel &lt;0.5 tank AND
         DistanceTo(gas station longitude coordinate, gas station latitude coordinate) &lt;10 miles THEN   RETURN Vehicle ID   RETURN Tank Fuel Level       

   END IF 
     FIG. 6  is a flow chart of a method  600  for obtaining vehicle context information to be used by one or more applications in accordance with an embodiment of the inventive arrangements disclosed herein. The method  600  can be performed in the context of-a vehicle communication system, such as the system  100  of  FIG. 1 . In one embodiment, the method can utilize a vehicle response language having characteristics like those presented in  FIGS. 2 ,  3 , and  4 . Method  600  is not limited in this regard and can be performed in the context of any system including one or more vehicles and at least one server wirelessly connected to the vehicles. Likewise, the steps in method  600  can be implemented in any programming language and is not limited to any particular vehicle response language. 
   Method  600  can begin in step  605  where at least one application can register a vehicle event with a vehicle response server. A vehicle event can be any event dependant upon a condition occurring within a vehicle that is unique to the vehicle. Consequently, a vehicle event is determined within the context of a specific vehicle. 
   In step  610 , the vehicle response server can define an activation context for the vehicle event. The activation context need not be identical to the vehicle event. In one embodiment, the vehicle event can be written in an application specific format and the activation context can be written in an application independent format. 
   In another embodiment, one or more activation contexts can be defined to include multiple related vehicle events. For example, one activation context can be defined to occur when a vehicle is low on fuel, another when the vehicle is low on oil, and another to indicate when a vehicle travels from one defined grid to another. These activation contexts (sent to vehicles) can be used by the vehicle response server to reply to a multitude of application submitted events. Application submitted events for the exemplary activation contexts can include events triggered when a vehicle using diesel gasoline is low on fuel (submitted by a first application), when a vehicle is low on fuel and needs a quart of oil (submitted by a second application), when a vehicle approaching a gas station is low on fuel (submitted by a third application), and other such occurrences submitted by any number of applications. 
   In step  615 , when the vehicle event results in one or more activation context that is not being currently tracked, the vehicle response server can wirelessly convey the activation context to one or more vehicle response agents, each agent being located within a vehicle. In step  620 , each vehicle response agent can analyze vehicle conditions to determine if conditions specified by the activation context have been satisfied. If not, the method can proceed to step  625 , where additional sensor input can be received over time. The additional sensor input can represent an altered state for vehicle conditions. The method can loop from step  625  to step  620 , where the vehicle response agent can analyze vehicle conditions in light of the altered vehicle state. 
   When the conditions for one or more activation events have been satisfied, the method can progress to step  630 , where the vehicle response agent can convey a context event occurrence indication to the vehicle response server. The vehicle response agent can also convey one or more relevant vehicle values (such as fuel reading, vehicle location, and the like) to the vehicle response server when conveying the occurrence indication. 
   In step  635 , the vehicle response server can adjust server variables and/or perform server actions to reflect the occurrence of the event. In step  640 , the vehicle response server can determine whether any vehicle events submitted by registered applications have been triggered by the context event occurrence. In step  645 , the vehicle response server can convey one or more electronic messages to one or more registered applications. Each electronic message can be tailored to the vehicle event of an associated application. Content within the electronic messages can also be tailored to the information privileges granted to the message receiving application. In step  650 , each application receiving an electronic message can perform one or more context-dependent programmatic actions based upon the message content, where the context of programmatic action refers to a vehicle specific context. 
   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. 
   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. 
   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.