Method and apparatus for conditionally triggered vehicle setting configuration

Abstract

The present disclosure relates to methods and apparatus for conditionally triggered vehicle setting configuration. A system includes a processor configured to receive a user-selected vehicle detectable state and a corresponding user-defined state variable value. The processor is further configured to receive a user-defined vehicle executable action. The processor is further configured to save the state variable value as a condition for executing the vehicle executable action saved in conjunction with the state variable value. The processor is further configured to monitor the vehicle detectable state and, when it is determined via the monitoring that the vehicle detectable state corresponds to the user-defined state variable value, execute the vehicle executable action saved in conjunction with the state variable value.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for conditionally triggered vehicle settings configuration. Background Art

[0002] Smartphones are now an integral part of human life. While initially driven more by convenience or novelty, these devices now store a user's photo albums, keep them constantly connected to everyone they know, and provide them with virtually unlimited on-demand information. As smartphones have improved, so too has the ability to customize them. Since the typical phone model is one person per phone, customizations made by each individual are often permanent for any user.

[0003] Other electronic goods are devices such as tablet computers, laptop computers and desktop personal computers. These devices also offer customization options, and these options are usually entered to log in, because these devices tend to be shared by multiple users.

[0004] Ultimately, a class of customizable devices emerged that were shared, but often had static settings. These customizable devices might include home thermostats, home theater systems, and many mechanical devices around the house. While smart functionality could be incorporated into many of these devices to "recognize" the user, doing so typically involved a level of technology that would make the device cost-prohibitive.

[0005] From all of these examples, it's clear that people like the idea of being able to fine-tune their devices or make them "their own." And, since so much time and thought may have gone into customization, people also like the idea of not having to re-customize their devices every time they upgrade. Settings export / import for smartphones and computers has been enabling these ideas for some time. Most other customizable devices, on the other hand, require reconfiguration when upgrading. Summary of the Invention

[0006] In a first illustrative embodiment, a system includes a processor configured to receive a user-selected detectable vehicle state and a corresponding user-defined state variable value. The processor is further configured to receive a user-defined executable vehicle action. The processor is further configured to store the state variable value as a condition for executing the executable vehicle action stored in conjunction with the state variable value. The processor is further configured to monitor the detectable vehicle state and, when determining, through monitoring, that the detectable vehicle state corresponds to the user-defined state variable value, execute the executable vehicle action stored in conjunction with the state variable value.

[0007] In a second illustrative embodiment, a computer-implemented method includes automatically changing a vehicle system setting to match the user-defined setting value in response to a plurality of vehicle detectable state values corresponding to a user-defined state value, the user-defined state value being saved in conjunction with a predefined action that defines the state value as a condition for changing the vehicle system setting and defines the user-defined setting value.

[0008] In a third illustrative embodiment, a computer-implemented method includes connecting to a vehicle computer via a mobile device and requesting vehicle system data corresponding to a vehicle system state, the vehicle system state being stored on the mobile device in conjunction with a user-defined vehicle-executable action. The method further includes comparing the state data to a user-defined system state parameter, the parameter being stored as a trigger for executing the vehicle-executable action, and instructing the vehicle computer to execute the vehicle-executable action when the state data matches the parameter based on the comparison. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 An illustrative vehicle computing system is shown;

[0010] Figure 2 An illustrative example of a configuration process is shown;

[0011] Figure 3 An illustrative example of a macro execution process is shown;

[0012] Figure 4 An illustrative process is shown that allows macro portability. DETAILED DESCRIPTION

[0013] As required, detailed embodiments are disclosed herein; however, it will be understood that the disclosed embodiments are merely illustrative and may be embodied in various forms and alternatives. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to illustrate details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

[0014] Figure 1An example block diagram of a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle equipped with a vehicle-based computing system may include a visual front-end interface 4 located within the vehicle. If the interface is provided with, for example, a touch-sensitive screen, a user can also interact with the interface. In another illustrative embodiment, interaction occurs through button presses, a spoken dialogue system with automatic speech recognition and speech synthesis.

[0015] exist Figure 1 In the illustrated illustrative embodiment 1, a processor 3 controls the operation of at least a portion of a vehicle-based computing system. The processor disposed within the vehicle allows for onboard processing of commands and routines. In addition, the processor is connected to both non-persistent memory 5 and persistent memory 7. In this illustrative embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. Generally speaking, persistent (non-temporary) memory can include all forms of memory that preserve data when a computer or other device loses power. Such memory includes, but is not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0016] The processor is also provided with several different inputs that allow the user to interact with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which may be a touchscreen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. Input to both the microphone and the auxiliary connector is converted from analog to digital by a converter 27 before being transmitted to the processor. Although not shown, the numerous vehicle components and auxiliary components that communicate with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and from the VCS (or its components).

[0017] The outputs of the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs may also be generated to a remote Bluetooth device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) along the bidirectional data streams shown at 19 and 21, respectively.

[0018] In one illustrative embodiment, the system 1 communicates (17) with a user's mobile device 53 (e.g., a cell phone, smartphone, PDA, or any other device with a wireless remote network connection) using the Bluetooth transceiver 15. The mobile device can then be used to communicate (59) with a network 61 outside the vehicle 31 by, for example, communicating (55) with a cellular tower 57. In some embodiments, the cellular tower 57 can be a Wi-Fi access point.

[0019] Exemplary communication between the nomadic device and the Bluetooth transceiver is represented by signal 14 .

[0020] The button 52 or similar input may be used to instruct the nomadic device 53 to pair with the Bluetooth transceiver 15. Accordingly, the CPU is instructed that the onboard Bluetooth transceiver is to pair with the Bluetooth transceiver in the nomadic device.

[0021] Data may be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the nomadic device 53, data over voice, or DTMF tones. Optionally, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer data (16) between the CPU 3 and the network 61 over the voice band. The nomadic device 53 may then be used to communicate (59) with the network 61 outside the vehicle 31, for example, by communicating (55) with a cellular tower 57. In some embodiments, the modem 63 may establish communication (20) with the cellular tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem, and the communication 20 may be cellular communication.

[0022] In one illustrative embodiment, the processor is provided with an operating system including an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another communication method that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0023] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communications. In the data-over-voice embodiment, a technique known as frequency division multiplexing (FDM) can be implemented when the owner of the nomadic device can speak over the device while data is being transmitted. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300 Hz to 3.4 kHz in one example). While FDM was common for analog cellular communications between the vehicle and the internet and is still used, it has largely been replaced by a mix of code domain multiple access (CDMA), time domain multiple access (TDMA), and spatial domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan may allow for broadband transmission and the system can use a much wider bandwidth (speeding up data transmission). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) mounted to the vehicle 31. In another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communicating via, for example, but not limited to, an 802.11g network (ie, Wi-Fi) or a WiMax network.

[0024] In one embodiment, incoming data can be transmitted through the nomadic device via data-over-voice or a data plan, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data can be stored on a HDD or other storage medium 7 until the data is no longer needed.

[0025] Other sources that may interact with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having a connection to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony) and Lynx TM (Texas Instruments), EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for electrical or optical communication.

[0026] Additionally, the CPU may communicate with various other auxiliary devices 65. These devices may be connected via wireless connections 67 or wired connections 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless healthcare devices, portable computers, and the like.

[0027] Additionally or alternatively, the CPU may be connected to a vehicle based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) transceiver 71. This may allow the CPU to connect to a remote network while within range of the local router 73.

[0028] In addition to the example processes being performed by a vehicle computing system located in the vehicle, in certain embodiments, the example processes may also be performed by a computing system in communication with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the processes depending on the specific implementation of the system. By way of example and not limitation, if a process includes a step for sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform that portion of the process because the wireless device does not "send and receive" information with itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0029] In each of the illustrative embodiments discussed herein, exemplary, non-limiting examples of processes that may be performed by a computing system are shown. For each process, it is feasible that the computing system performing the process be configured as a dedicated processor for performing the process for the limited purpose of performing the process. All processes need not be performed, and should be understood as examples of various types of processes that may be performed to implement elements of the present invention. Additional steps may be added to or removed from the exemplary processes as needed.

[0030] With respect to the illustrative embodiments described in the accompanying figures showing illustrative process flows, it should be noted that a general-purpose processor may be temporarily used as a special-purpose processor for the purpose of performing some or all of the exemplary methods illustrated by these figures. While executing code providing instructions for performing some or all of the steps of the methods, the processor may be temporarily repurposed as a special-purpose processor until the methods are completed. In another example, to the extent appropriate, firmware running on a pre-configured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the methods or some reasonable variation thereof.

[0031] With all the customizable gadgets available to humanity, perhaps the most expensive and one of the most customizable "devices" is the car. These highly complex machines offer a wide range of user-configurable customizations at roughly 50 to 100 times the cost of a phone or computer. Modern cars have the advantage of both wireless communication technology and advanced internal computing technology. The combination of these features makes the car itself a highly customizable and even portable customization experience. Although physical customization of vehicles has been possible for many years, users generally don't try to adopt the same spoiler and install the same spoiler on every car they drive, for example. On the other hand, it may be more desirable for users to have electronic customization, such as a radio setting that follows the user from vehicle to vehicle.

[0032] The world of car ownership may also be undergoing a paradigm shift, with users more frequently sharing vehicles with other users and / or using short-term, hourly rentals to access vehicles for simple, everyday tasks. In such an environment, without portable customization features, it's unlikely that a user would spend 10 minutes of a one-hour rental configuring the vehicle to suit their preferences. Therefore, one aspect of the illustrative embodiments includes a set of portable customization features that can follow a user from vehicle to vehicle.

[0033] Another challenge with vehicle customization is that vehicles are highly specialized, even before customization. Different makes and models (even different makes and models from the same manufacturer) may have internal controls in different locations. In this situation, most casual users may spend several seconds searching for a desired function, then forgo using it if they can't find the control for that function.

[0034] For example, a user might prefer a vehicle interior temperature of 72 degrees Fahrenheit in the summer and 76 degrees Fahrenheit in the winter. Alternatively, the user might prefer a vehicle interior temperature of 72 degrees Fahrenheit whenever it's at least 60 degrees Fahrenheit outside, and 76 degrees Fahrenheit when it's below 60 degrees Fahrenheit. In current models, users typically use "feel" to determine the outside temperature (i.e., whether the user feels hot, cold, or comfortable) and then set the interior temperature accordingly, as the interior temperature is typically initially within a few degrees of the outside temperature. However, if the user is not extremely uncomfortable and cannot quickly figure out how to operate the vehicle's HVAC system, the user may simply ignore the setting change and continue driving to their destination in a slightly uncomfortable manner. Or, worse still, the user may begin driving and continue fiddling with the control settings as the vehicle progresses. To accommodate scenarios such as this, the illustrative embodiments allow for "triggered" portable user preferences. That is, a user can define a set of conditions and actions once, and then any vehicle can be notified of the conditions and actions, use internal sensing capabilities to check the conditions, and act according to the actions.

[0035] Using the same example as above, a user can configure a set of conditions and actions using a smartphone interface or even a vehicle interface. These settings can be saved to a portable device (phone) or the cloud, and whenever the user enters a suitably equipped vehicle, the configuration can be exported to the vehicle. In the above example, the vehicle will determine the outside temperature and automatically set the interior HVAC controls without the user ever having to interact with or even locate the actual HVAC controls. This would allow people who frequently use various vehicles for short periods of time to simply "carry" the vehicle settings with them. Even when entering a rental vehicle or taxi, the settings can be exported to the vehicle so that the user's settings can be implemented during the drive. This can be very convenient in these situations, as passengers often ride in the back of the vehicle and are often unable to even reach the vehicle's HVAC and radio settings, let alone adjust them.

[0036] Figure 2An illustrative example of a configuration process is shown. In this example, at 201, a user can configure a set of vehicle settings using any vehicle interface, or a phone interface, or a PC interface. In the configuration process, the user can select one or more vehicles as a basis for configuring the settings, or the user can be presented with a list of all possible settings. This can be important because different vehicles have different sensing and configuration capabilities, and settings (especially those enabled by specific triggers) may not be universally portable. For the purposes of this example, the model will be described as having access to all possible settings and sensors (e.g., sensors deployed on a manufacturer's line), but it is also possible to limit the settings to those available in one or more preferred vehicles, for example.

[0037] In this example, at 203, the process presents a list of trigger types. These are trigger categories that the user can use to select specific variables within the category and configure trigger values for those variables. For example, but not limited to, the trigger type could be "weather," the variable could be "temperature," and the value could be "72 degrees Fahrenheit." In another example, the trigger type could be "time," the variable could be "day of the week," and the value could be "weekend." Other possible categories include, but are not limited to, connection status, location, inputs, occupants, etc. Some non-limiting examples of variables in these categories include connection status→BT headset connection, location→point of interest (POI) proximity, inputs→radio power button interaction, occupants→number of occupants.

[0038] While the paradigm described for triggering is type→variable→value, other models can be used. The more general idea is that a vehicle can detect conditions that can be used to activate defined actions.

[0039] In this example, at 205, the user selects at least one trigger type, and at 207, the system presents a set of configurable variables corresponding to the selected trigger type. Then, at 209, the user selects one or more variables, and at 211, the system receives user-defined values for these variables. A non-limiting list of example values (using the examples from above) is presented below for illustration purposes only:

[0040] Weather → Temperature → <72 degrees Fahrenheit

[0041] Time → Hours → Between 5pm and 7pm

[0042] Connection Status → BT Headset Connection → Connected

[0043] Location → Point of Interest Proximity → < 5 miles from Home POI

[0044] Input → Radio Power Button Interaction → Press 4 times within 5 seconds

[0045] Crew → Number of Crew → > 1

[0046] In this example, the user can continue to add conditions as desired to build highly customized situations under which the action can occur at 213. For example, the user can enter all of the above examples so that the action only occurs when the temperature is below 72 degrees Fahrenheit, the time is between 5 PM and 7 PM, a Bluetooth headset is connected, the user is less than 5 miles from home, the user presses the radio power button four times within 5 seconds, and the user is not alone in the car.

[0047] Once the user has finished building a set of conditions, the process presents the configurable vehicle systems at 215. These configurable vehicle systems are systems that can be controlled or configured in response to a trigger state. These systems include, but are not limited to, HVAC, radio, seats, windows, horn, vehicle computer (e.g., to save content), navigation, lighting, door locks, etc. At 217, the process receives the user's selection of one or more systems to be controlled, and at 219, the process receives any configurable values for these systems (e.g., HVAC settings, window heights, radio settings, etc.). The system then saves a macro at 221 that defines what action to take based on what trigger is detected at what value.

[0048] Figure 3 An illustrative example of a macro execution process is shown. In this example, at 301, the process loads a collection of macros associated with a user. The origin of these macros is referenced Figure 4 are discussed in more detail.

[0049] Once the macros associated with the user are loaded, the system loads the conditions associated with each triggerable action at 303. For example, if these conditions are conditions upon which one or more actions depend, the system can initiate processing to monitor temperature, speed, and proximity to the home POI at 305. If any of the variable values are met at 307 (e.g., the temperature drops below 72 degrees Fahrenheit, or the vehicle is within 2 miles of the home POI), the process can set a flag corresponding to the condition being met at 309.

[0050] In this example, the action is triggered by all conditions being met simultaneously. That is, if a condition is met and then subsequently unmet, the process will not consider the condition to be met at all times unless it is met at the same time as all other required conditions are met. In other examples, the process may only detect the satisfaction of each condition at a certain point during driving, and the format selected may also be a user-configurable option.

[0051] Here, if any variable value is "unsatisfied" at 311, that is, if a previously satisfied variable value has changed (e.g., the temperature has risen above 72 degrees Fahrenheit), the process resets the previously set flag at 313. Finally, at 315, the process determines whether all values for a given action are satisfied, and if so, the process executes the action at 317. Otherwise, the process will continue to monitor variable values until all conditions for the particular macro are satisfied.

[0052] Figure 4 An illustrative process for enabling macro portability is shown. In this example, a user configures a series of conditions and corresponding actions, and these conditions and actions can be employed in any vehicle the user is in, provided that sufficient monitoring capabilities and configurable systems are present in that vehicle. Here, the macros are stored on a portable device (e.g., a smartphone, smartwatch, tablet, etc.) that can communicate with multiple vehicles, but in other examples, the macros can be stored for user profiles located in the cloud.

[0053] In this example, at 401, the process detects the presence of a connected portable device. If the device has storage capacity, then at 403, the process may determine whether the device includes any user-defined macros. Since the macros are stored on the device, the vehicle itself does not even have to know the user's identity in order to implement the macros. Instead, the vehicle can determine the permissibility of the macros (e.g., the macros must come from the device running the ride-sharing app, the driver must approve the macro loading, etc.) and only load the macros without ever knowing the user's identity. In a cloud-based model (where the macros are stored for a user profile), the process may need to know the user ID (which can be obtained from the device) or the device ID associated with the user profile in the cloud.

[0054] Since the macros have conditions associated with them, the vehicle will need to be able to detect those conditions in order to ensure that all conditions for triggering an action are met. At 405, the vehicle can check the conditions associated with each macro, and at 407, the vehicle can determine if any sensing capabilities required to verify the conditions are missing.

[0055] If all appropriate sensing is available, the process may store the macro locally at 409 for execution when appropriate conditions are met. If any sensing capabilities are missing, the process may ignore the macros or, for example, alert the user that a macro will execute based on a subset of conditions at 411. If the user chooses to proceed despite the lack of sensors at 413, the process may temporarily modify the macro and store the modified macro at 415. For example, if the vehicle lacks a rain sensor and the condition of playing sentimental music exists while the vehicle is traveling at a speed below 35 mph and in the rain, the new macro will only activate when the vehicle is traveling at a speed below 35 mph.

[0056] Users can also save temporary changes, save changes for a specific vehicle or class / make / model of vehicle, or discard changes at the end of a drive.

[0057] Specific applications may also have configurable macros associated with the application. For example, a ride-hailing application may have a subset of configurable functions that are granted automatic permissions for execution when a vehicle ordered through the application arrives. These functions can be unlocked during the ride, and the locally stored macros can be deleted at the end of the ride. This allows users of the ride-hailing vehicle to dynamically configure the ride experience. In another example, a ride-sharing application may have similar functionality, such as unlocking functions during the rental period. The system can then revert to stock settings in the latter case and to driver preferences in the former case. In some of these cases, the user may be limited in which functions can be controlled, but this will allow the user to enter any short-term vehicle and have the vehicle configured responsively, as if the user were actively controlling the configurable systems.

[0058] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the invention. Rather, the terms used in the specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, the features of the various implementing embodiments may be combined in a logical manner to produce context-appropriate variations of the embodiments described herein.

Claims

1. A system for conditionally triggered vehicle setting configuration, comprising: The processor is configured to: wirelessly requesting vehicle system status data corresponding to a plurality of vehicle system states, the vehicle system status data being stored on the mobile device in conjunction with a user-defined vehicle-executable action; comparing vehicle system state data for each of the plurality of vehicle system states to a corresponding user-defined system state parameter, the system state parameter being saved as a trigger for performing the vehicle-executable action; wirelessly instructing a vehicle computer connected to the mobile device to execute the vehicle-executable action when the vehicle system state data matches the system state parameter for all vehicle system states based on the comparison; receiving an error message in response to the request, the error message indicating that vehicle system state data is unavailable for at least one vehicle system state of the plurality of vehicle system states; The trigger is modified to exclude a system state parameter corresponding to the unavailable vehicle system state data.

2. The system of claim 1, wherein: The vehicle system status data includes at least a time of day.

3. The system of claim 1, wherein: The vehicle system status data includes at least the current temperature.

4. The system of claim 1, wherein: The vehicle system state data includes a specific series of vehicle input button interactions.

5. The system of claim 1, wherein: The vehicle system status data includes a status value related to a position.

6. A computer-implemented method comprising: Connecting to the vehicle computer via a mobile device; wirelessly requesting, via the mobile device, vehicle system status data corresponding to a plurality of vehicle system statuses, the vehicle system status data being stored on the mobile device in conjunction with a user-defined vehicle-executable action; comparing, via the mobile device, vehicle system state data for each of the plurality of vehicle system states to a corresponding user-defined system state parameter, the system state parameter being saved as a trigger for performing the vehicle-executable action; wirelessly instructing the vehicle computer from the mobile device to execute the vehicle-executable action when the vehicle system state data matches the system state parameter for all vehicle system states based on the comparison; receiving an error message in response to the request, the error message indicating that vehicle system state data is unavailable for at least one vehicle system state of the plurality of vehicle system states; The trigger is modified to exclude a system state parameter corresponding to the unavailable vehicle system state data.

7. The method according to claim 6, wherein: The vehicle system status data includes at least a time of day.

8. The method of claim 6, wherein: The vehicle system status data includes at least the current temperature.

9. The method of claim 6, wherein: The vehicle system state data includes a specific series of vehicle input button interactions.

10. The method of claim 6, wherein: The vehicle system status data includes a status value related to a position.

11. The method according to claim 6, wherein: The step of modifying further comprises modifying the trigger in response to a user instruction for modifying the trigger.

12. The method of claim 6, wherein: The vehicle-enactable action includes changing a vehicle system setting to match a user-defined system setting saved on the mobile device.

Images