Methods of controlling vehicle interfaces using device motion and near field communications

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002This invention relates generally to establishing a continuous communication session between a mobile device and a vehicle using Near Field Communications (NFC) and, more particularly, to a method for establishing a continuous communication session between a mobile device and a vehicle using NFC in which the mobile device can host applications in lieu of a vehicle controller, the device can be used to permit or restrict certain vehicle functions, and data can be continuously or intermittently transferred from the device to the vehicle and vice versa.

00032. Discussion of the Related Art

0004Wireless communication systems have become increasingly common in modern vehicles, enabling customer mobile devices to interact with vehicles in a variety of ways. Among the wireless technologies, Near Field Communications (NFC) provides inherently strong security by virtue of its very short wireless transmission range. Whereas Bluetooth and Wi-Fi signals travel well outside the confines of a host vehicle and are therefore susceptible to eavesdropping and more serious malicious attacks, the same is not true for NFC. NFC signal range is only 2-4 centimeters, thus making it infeasible for NFC signals to be intercepted by a device which is not physically located within the host vehicle.

0005Because of NFC's inherent security, its usage in vehicles may become prevalent. Although vehicle manufacturers have considered a number of features which use NFC to communicate with a customer mobile device, there remains a tremendous amount of untapped potential. In particular, NFC is typically used only for transferring a small amount of data on a one-time basis when two NFC devices are placed in close proximity. By combining the power of modern smart phones and other mobile devices with the security of NFC, and extending the NFC communications between the device and the vehicle to a continuous time session, it is possible to use the mobile device to provide value-added feature content to a vehicle without adding cost to the vehicle itself. It is also possible to simplify vehicles by replacing certain components with a combination of mobile device-based applications and NFC-based motion-detection.

SUMMARY OF THE INVENTION

0006In accordance with the teachings of the present invention, methods are disclosed for establishing continuous communications between a vehicle and a mobile device using Near Field Communications (NFC), and using the NFC communication to enable application hosting on the mobile device and other features. An NFC-enabled mobile device is placed in close proximity to an NFC antenna in the vehicle, where in one embodiment the NFC antenna is integrated into a wireless charging pad for the device. Continuous wireless NFC communications are established between the mobile device and the vehicle, such that the device can serve as a controller for in-vehicle systems. Control applications on the mobile device can include driver-commanded features such as operation of windows and door locks, as well as automatic features such as navigation and collision warning. Other uses of the NFC-enabled mobile device are also disclosed, such as event-based information capture and gesture-based control.

0007Additional features of the present invention will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0008<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a vehicle including a system which supports continuous time NFC communications with a mobile device;

0009<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart diagram of a method for establishing and maintaining a continuous time communications session between the vehicle and the mobile device via NFC;

0010<figref idref="DRAWINGS">FIG. 3</figref> is an illustration of the communications which take place when NFC is used to enable event-based information capture by the mobile device in the vehicle;

0011<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart diagram of a method for performing event-based information capture using the mobile device in the vehicle;

0012<figref idref="DRAWINGS">FIG. 5</figref> is an illustration of a first embodiment of gesture-based control of a vehicle feature, using the mobile device in conjunction with an NFC tag and Wi-Fi or Bluetooth communications;

0013<figref idref="DRAWINGS">FIG. 6</figref> is an illustration of a second embodiment of gesture-based control of a vehicle feature, using the mobile device in conjunction with multiple NFC tags and Wi-Fi or Bluetooth communications;

0014<figref idref="DRAWINGS">FIG. 7</figref> is an illustration of a third embodiment of gesture-based control of a vehicle feature, using the mobile device in conjunction with a vehicle-integrated NFC reader; and

0015<figref idref="DRAWINGS">FIG. 8</figref> is an illustration of a fourth embodiment of gesture-based control of a vehicle feature, using the mobile device in conjunction with multiple vehicle-integrated NFC readers.

DETAILED DESCRIPTION OF THE EMBODIMENTS

0016The following discussion of the embodiments of the invention directed to methods of controlling vehicle interfaces using device motion and Near Field Communications is merely exemplary in nature, and is in no way intended to limit the invention or its applications or uses.

0017Smart phones and other modern mobile devices possess computing and communications capability far exceeding the demands of most users. Mobile devices such as smart phones also include touch-screen user interfaces which provide virtually unlimited capability for user interaction with the device. At the same time, the rapid advancement of electronic controls in vehicles, along with the attendant availability of data on information busses, provides unprecedented opportunity for mobile device interactions with a vehicle. Although Wi-Fi and Bluetooth wireless protocols provide ample communications bandwidth to support device-vehicle interaction, the possibility exists that Wi-Fi and Bluetooth signals can be intercepted by a malicious entity outside the vehicle, thus making these wireless technologies suitable only for non-critical communications.

0018Near Field Communications (NFC) is a wireless communications technology which has become increasingly popular. NFC operates at 13.56 MHz and transfers data at up to 424 Kbits/second. NFC communications can be uni-directional or bi-directional. Communications between two NFC-compatible devices occurs when they are brought within a range of about four centimeters of one another. Thus, a simple wave or touch of an NFC device can establish an NFC connection which can then be used to transfer information of any sort.

0019An NFC tag is a very small stand-alone device with no power supply or network connectivity. One common type of NFC tag can contain up to 144 bytes of data, which is transferred to an NFC reader when the NFC reader device is passed within close proximity of the NFC tag. Additional memory can be included on a tag depending on the application requirements. NFC tags can be easily placed almost anywhere by including them in simple adhesive-backed paper or plastic stickers. NFC tags can be mounted behind a vehicle surface (as long as there is minimal blockage from metal surfaces) or affixed to the top of a vehicle surface such as the dashboard area or the center of the steering wheel. An NFC reader is a device which uses NFC wireless technology to transfer data from another device such as a tag. An NFC reader has no inherent data size limits, and in fact does not contain its own data; as the name implies, an NFC reader reads data and passes it along to a processor. An NFC transponder or NFC chip is a device which provides two-way data transfer via NFC.

0020NFC, in contrast to Wi-Fi and Bluetooth, provides for inherently secure wireless communications by virtue of its very short transmission range—typically 1-4 centimeters. However, NFC is traditionally used only for one-time transfer of small amounts of information. By extending NFC capability to support continuous time sessions and ongoing bi-directional data transfer, it is possible to realize the full potential of the mobile device to interact with the vehicle, using a convenient and secure wireless communications channel.

0021<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a vehicle <b>10</b> including a system <b>12</b> which supports continuous time NFC communications with a mobile device <b>14</b>. The system <b>12</b> includes a device interface module <b>16</b>, which in one embodiment is a charging pad which wirelessly charges the mobile device <b>14</b> when the device <b>14</b> is placed on the charging pad (the interface module <b>16</b>). Including the wireless charging feature into the interface module <b>16</b> allows a driver of the vehicle <b>10</b> to place his/her device <b>14</b> onto the module <b>16</b> and leave it there, where it can be used as a full-feature interface to the vehicle and retain a full battery charge for later use outside the vehicle <b>10</b>.

0022The interface module <b>16</b> includes an NFC chip <b>18</b>, which has an incorporated NFC antenna. The mobile device <b>14</b> also has an NFC chip <b>20</b>. Thus, when the device <b>14</b> is placed on the device interface module <b>16</b>, NFC communications are established between the device <b>14</b> and the interface module <b>16</b>. The device <b>14</b> runs an application <b>22</b>, which sends data to and/or receives data from the vehicle <b>10</b> via the interface module <b>16</b>. The interface module <b>16</b> in turn communicates with other elements of the system <b>12</b>, including modules <b>24</b>, <b>26</b> and <b>28</b>. The modules <b>24</b>-<b>28</b> are controllers for devices and actuators onboard the vehicle <b>10</b> which operate at comparatively low speeds. Examples of the modules <b>24</b>-<b>28</b> include controllers for door locks, window lifts, seat actuators and pedal actuators. More than three of the modules <b>24</b>-<b>28</b> could be included in the system <b>12</b>, as any appropriate low-speed control module can be allowed to interface with the mobile device <b>14</b> via the interface module <b>16</b>.

0023The interface module <b>16</b> also communicates with a gateway module <b>30</b>, which provides access to other low-speed and high-speed system data from the vehicle <b>10</b>. For example, the gateway module <b>30</b> can provide access to infotainment and telematics system data, to enable interaction of the device <b>14</b> with the vehicle <b>10</b> involving audio, video, phone and other such signals and data. The gateway module <b>30</b> can also provide data such as diagnostic trouble codes (DTCs) from an onboard controller to the device <b>14</b>, and can provide messages and other data from the device <b>14</b> to be displayed to the driver of the vehicle <b>10</b>. These examples will be discussed in detail below.

0024Using the architecture depicted in <figref idref="DRAWINGS">FIG. 1</figref>, the mobile device <b>14</b> effectively becomes a configurable virtual control interface for devices onboard the vehicle <b>10</b>, as represented by the modules <b>24</b>-<b>28</b>. For example, the application <b>22</b> can provide a touch-screen interface to allow the driver to control vehicle windows, door locks, seats, audio volume, etc. It is easily envisioned that the application <b>22</b> could also retain preferences for the owner of the device <b>14</b>, and these preferences could be employed whenever the device <b>14</b> is placed on the interface module <b>16</b> to establish NFC communications. Such preferences could include radio station presets, seat and pedal positions, climate control settings and others.

0025The application <b>22</b> could also provide a more sophisticated feature such as collision warning or lane departure warning. If the vehicle <b>10</b> is equipped with radar or other object detection systems, and if the vehicle <b>10</b> does not include specific collision or lane departure warning software, it is possible to host these features on the device <b>14</b> and provide warnings and information to the vehicle's driver. Likewise, if the vehicle <b>10</b> is equipped with a short-range communication transceiver (e.g., Dedicated Short Range Communications, Wi-Fi, or other peer-to-peer networking technologies) that is operating in transmit-only mode, it is possible to augment this system using the device <b>14</b> and enable a variety of driver warning and information features. Additionally, if the vehicle <b>10</b> is equipped with a short range communication transceiver and running a subset of potential warning and information features, additional features can be enabled using the device <b>14</b> and the described interface. Hosting the advanced features in the application <b>22</b> on the mobile device <b>14</b> offers at least two distinct advantages. First, the cost of the vehicle <b>10</b> can be lower because the vehicle <b>10</b> does not need to provide computing hardware (the processing, memory and storage required by the feature) and software for the feature which is hosted on the device <b>14</b>. Second, application development and deployment is a well-established and rapid process on smart phones such as the device <b>14</b>, thus enabling new applications and features to be developed and deployed by a variety of sources throughout the lifecycle of the vehicle <b>10</b>.

0026The traditional method of device interaction using NFC, where a one-time exchange of data occurs when two devices are brought into proximity, is clearly insufficient to support the features of the system <b>12</b> described above. These features, including using the mobile device <b>14</b> as a user interface to vehicle systems, and hosting applications on the device <b>14</b> to provide information and control features to the vehicle <b>10</b>, can only be realized if the NFC exchanges between the mobile device <b>14</b> and the interface module <b>16</b> are extended to a continuous time session.

0027<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart diagram <b>40</b> of a method for establishing and maintaining a continuous time communications session between the vehicle <b>10</b> and the mobile device <b>14</b> via NFC. The process begins at box <b>42</b> with no network communications between the vehicle <b>10</b> and the device <b>14</b>, and any feature applications on the device <b>14</b>, such as the application <b>22</b>, are asleep or not running. At decision diamond <b>44</b>, the vehicle <b>10</b>—specifically the interface module <b>16</b>—detects the presence of an NFC-enabled device—in this case, the device <b>14</b>. If no NFC-enabled device is detected at the decision diamond <b>44</b>, all network services are disabled by the interface module <b>16</b> at box <b>46</b>, and the process returns to the box <b>42</b> with no NFC network connection. If an NFC-enabled device is present at the decision diamond <b>44</b>, then at decision diamond <b>48</b> a determination is made whether the NFC-enabled device is authorized to communicate with the vehicle <b>10</b>. Authorization could mean that the application <b>22</b> is present on the device <b>14</b> and was legitimately purchased, or it could mean that the device <b>14</b> has been registered as a master or guest mobile device for the particular vehicle <b>10</b>, or a combination of both. The registration process could include an authentication process outside the vehicle where once the vehicle pairing has occurred, a subsequent authorization request is made to a call center or enterprise portal before vehicle access and control is granted. Such remote authorization and revocation could be used to prohibit unauthorized vehicle usage (e.g., if the customer phone has been stolen), enable other parties (e.g., family or friends) to use the vehicle or enable authorities to remotely access or disable services on a stolen vehicle. The authorization check at the decision diamond <b>48</b> is meant to preclude an unrecognized and/or unauthorized device from establishing NFC communications with the vehicle <b>10</b>. If an unauthorized device is detected at the decision diamond <b>48</b>, network services are disabled at the box <b>46</b>.

0028If an authorized device is detected at the decision diamond <b>48</b>, network services are enabled at box <b>50</b>. That is, two-way NFC communications are established between the mobile device <b>14</b> and the vehicle <b>10</b> via the interface module <b>16</b>. In order to maintain an ongoing, continuous time communications session between the device <b>14</b> and the vehicle <b>10</b>, it is necessary to periodically test the NFC communications channel and the status of the device <b>14</b>. These tests are carried out at decision diamonds <b>52</b> and <b>54</b>. At the decision diamond <b>52</b>, it is determined whether an authorized NFC-enabled device, such as the mobile device <b>14</b>, is still present on the interface module <b>16</b>. The presence test could be in the form of a Packet Delivery Ratio (PDR) test, where the PDR must exceed a certain threshold in order to signify device presence. If the device presence test is passed at the decision diamond <b>52</b>, then at decision diamond <b>54</b> a performance challenge is issued to the device <b>14</b> by the system <b>12</b>. The performance challenge could be a small computing task or communications task, which is intended to ensure that the device <b>14</b> is responsive and able to perform as a vehicle-attached device. Such a performance challenge will be an ongoing requirement to maintain vehicle access and the nature of the challenge will vary in a random fashion to prevent applications from avoiding the performance test.

0029If the performance challenge is passed at the decision diamond <b>54</b>, then vehicle services are enabled for the device <b>14</b> at box <b>56</b>. At the box <b>56</b>, warning-type services are configured and/or provided. Warning-type services are those services provided by the mobile device <b>14</b> to the vehicle <b>10</b> which involve informational displays and audio/visual warnings, but do not involve control of vehicle functions. At the box <b>56</b>, the warning-type services can be configured—for example, by defining what type of warning (audio tone, flashing indicator, etc.) is to be issued for each type of alert provided by the device <b>14</b>. Also at the box <b>56</b>, the warning-type services are provided—for example, if the device <b>14</b> hosts a driver attentiveness application and the application detects driver drowsiness, a combination of audio and haptic warnings could be issued to the driver of the vehicle <b>10</b>.

0030If access to control-type services is also to be provided to the mobile device <b>14</b>, then at decision diamond <b>58</b> a second, more stringent performance challenge can be issued. If the performance challenge at the decision diamond <b>58</b> is passed, then at box <b>60</b>, control-type services are configured and/or provided. Control-type services are those services provided by the device <b>14</b> to the vehicle <b>10</b> which involve actual control of vehicle functions. For example, if the device <b>14</b> hosts an adaptive cruise control (ACC) application, and the device <b>14</b> determines through vehicle-to-vehicle (V2V) communications that the vehicle <b>10</b> is getting too close to a vehicle in front of it, then the device <b>14</b> could issue a command to the vehicle <b>10</b> to slow down. The device <b>14</b> could similarly host a lane keeping application or many other types of real-time control applications, using V2V, V2I and other data sources.

0031Separation of the warning-type services at the box <b>56</b> from the control-type services at the box <b>60</b> allows the two types of services to be configured differently, or for warning-type services to be enabled while control-type services are disabled. Additionally, the two different service types may have different performance criteria. Thus, the performance challenges at the decision diamond <b>58</b> may be more difficult and/or more frequent then the performance challenges at the decision diamond <b>54</b>.

0032If the PDR does not exceed the threshold at the decision diamond <b>52</b>, or if the performance challenge is not passed at the decision diamonds <b>54</b> or <b>58</b>, then the process moves to box <b>62</b> where a brief wait is carried out before the process returns to the decision diamond <b>52</b> where the device presence test is re-tried. After a certain number of wait cycles at the box <b>62</b>, or a certain amount of total elapsed time, the NFC communications session times out, and network services are disabled at box <b>64</b>. At box <b>66</b>, both the system <b>12</b> and the device <b>14</b> are returned to the state they were in when the process began at the box <b>42</b>—that is, NFC communications are deactivated by the system <b>12</b>, and the application(s) <b>22</b> on the device <b>14</b> are asleep or not running. This condition would be communicated to the driver in some form (audio/visual/haptic) to indicate that the requested feature or service is not available due to device capabilities, due to the device <b>14</b> being out of position of the NFC reader or due to the device <b>14</b> being outside of NFC communication range (i.e., customer picked up device). In the case where the customer picks up the device <b>14</b>, the system <b>12</b> may fall back on a secondary communication channel (e.g., Bluetooth or Wi-Fi) until the device <b>14</b> is replaced to the charging pad (the interface module <b>16</b>). A reminder may be displayed to the driver while the system <b>12</b> is running in this state that the device <b>14</b> should be restored to the pad location for optimal performance, security and safety.

0033Many examples of applications running on the device <b>14</b> and providing services to the vehicle <b>10</b> via a continuous NFC communications session can be envisioned. One example is the use of the device <b>14</b> as a control interface for many different driver-controlled components and features of the vehicle <b>10</b>—such as seat position, window opening and closing, door locks, HVAC controls, radio controls, etc. These features can all be accessed via a touch-screen interface on the device <b>14</b>. The features could also be accessed via voice command on the device <b>14</b>, such as a command for “driver's window up halfway”. Because most modern smart phones support voice commands, the application <b>22</b> on the device <b>14</b> could easily convert the voice commands to control signals which are provided to the vehicle <b>10</b> via the NFC interface. This illustrates a particular advantage to using the device <b>14</b> as an interface to the vehicle <b>10</b>—the ability to provide a value-added feature to the driver by taking advantage of existing capability in the device <b>14</b>, and avoiding adding the cost of a voice recognition system to the vehicle <b>10</b>.

0034More advanced applications are also possible, including applications which gather real-time information from a variety of sources and provide signals to the vehicle <b>10</b> for information or warning-type services or control-type services, such as the adaptive cruise control and lane keeping applications discussed above. furthermore, as the percentage of vehicles carrying smart phones increases, many types of crowd-sourced data applications become much more robust. Such applications can provide warnings of slow traffic ahead, alternate route navigation assistance, and many other features. These types of innovative and highly functional applications will develop organically in the smart phone market, thus allowing the mobile device <b>14</b> to provide many new features and services to the vehicle <b>10</b>, even if the vehicle <b>10</b> is several years old and the features were not envisioned when the vehicle <b>10</b> was developed. The system <b>12</b> enables this functionality by taking advantage of the inherent security of wireless communications via NFC, and extending the NFC communications to a continuous time session.

0035The continuous NFC session management algorithm described above enables the mobile device <b>14</b> to serve as a user interface device for vehicle systems, and also to host applications which provide additional features to the vehicle <b>10</b>. Many other use cases are also enabled by the algorithm, made possible by the continuous time communications and by the security inherent in NFC's short signal range.

0036One such use case is for vehicle mobilization and immobilization—that is, using the device <b>14</b> as a sort of “digital key” for vehicle access and usage permissions. The presence of the device <b>14</b> on the interface device <b>16</b> can become a metaphor for a physical key in the ignition of the vehicle <b>10</b>. In other words, the vehicle <b>10</b> won't run unless a properly authorized device <b>14</b> is placed on the interface device <b>16</b> and the device <b>14</b> passes its credentials along to the vehicle <b>10</b>.

0037With the device <b>14</b> serving as a digital key for the vehicle <b>10</b>, many other features can also be provided. For example, a master or owner device serving as the device <b>14</b> may provide unrestricted capability in the vehicle <b>10</b>. However, a guest device serving as the device <b>14</b> may have restrictions placed on the vehicle <b>10</b>, such as geo-fencing (limiting the geographic area that the vehicle <b>10</b> can operate within), speed and performance settings (such as maximum speed, maximum acceleration, etc.) and other limits (such as no phone calls or texting from the device <b>14</b>). The guest device concept can be applied to a child, other family member or friend of the vehicle owner, or guest device permissions can be provided on an as-needed, real-time basis by way of a ride sharing service.

0038In the case of a ride sharing service, for example, a customer may use her smart phone to rent a vehicle “in downtown Ann Arbor, Mich., from 6:00-10:00 pm tonight”. The ride sharing service would select an available vehicle, which could be from a pool of company vehicles or a privately-owned vehicle which is available for rent. The ride sharing service would then download the access information to the available vehicle (now the vehicle <b>10</b>) and to the customer's smart phone (now the device <b>14</b>). The customer can then use the device <b>14</b> to gain access to and operate the vehicle <b>10</b>, with any restrictions placed on it, as discussed above.

0039Vehicle personalization is also possible when using the device <b>14</b> for vehicle access and mobilization. Personalization settings, such as seat and pedal positions, HVAC and radio preferences, performance settings, and others, can be made available by the device <b>14</b> and used by the vehicle <b>10</b>. These personalization settings can be provided by any type of the device <b>14</b> used in the vehicle <b>10</b>—whether the device <b>14</b> belongs to a master or owner, a regular guest such as a child, or a one-time guest such as a ride sharer.

0040Event-based information capture is another feature which can be used in conjunction with the continuous time communications capability described above, or used without it. In event-based information capture, a driver can use an NFC-equipped smart phone or other device to capture information from in-vehicle display events, and gather additional information or take certain actions based on the information captured. Examples range from automatically identifying and buying a song which is currently playing on a radio station, to getting detailed information related to a “check engine” message which was displayed.

0041<figref idref="DRAWINGS">FIG. 3</figref> is an illustration of the communications which take place when NFC is used to enable event-based information capture by the mobile device <b>14</b> in the vehicle <b>10</b>. When information of interest is displayed anywhere on the console or dashboard area of the vehicle <b>10</b>, the driver taps or waves the mobile device <b>14</b> at a spot <b>80</b> where the information is being displayed. There can be several of the spots <b>80</b> in the vehicle <b>10</b>, which could be in the navigation or map display (e.g., NFC antennas mounted behind the glass or reflective surface of the display), in the radio display, in a vehicle diagnostic display, and/or elsewhere—including non-dynamic display areas (areas that have printed text, graphics or are back-lit) such as vehicle knobs, switches or handles. For example, a back-lit LED may be used as a cue to inform the driver where to tap the phone. Such a cue could use color or a specific flashing rate to gather the driver's attention. Each of the spots <b>80</b> in the different display locations of the vehicle <b>10</b> is equipped with an NFC tag or transponder which detects the tap of the device <b>14</b> and responds by transferring the relevant information. In one embodiment, the spots <b>80</b> each include an NFC tag which simply identifies the location which was tapped (such as “radio”) and the application <b>22</b> on the device <b>14</b> requests current information for the location (such as the name of the song being played on the radio) from the vehicle <b>10</b> via Bluetooth or Wi-Fi. In another embodiment, the spots <b>80</b> each include an NFC chip or transponder which directly provides the relevant information when the device <b>14</b> is brought within NFC range.

0042In either of the embodiments described above, the device <b>14</b> receives a small amount of information of interest—such as a name of a song on the radio, a diagnostic trouble code (DTC) indicator associated with a warning message, or a name of a point of interest displayed on a map. The application <b>22</b> on the device <b>14</b> takes context-specific action based on the type of information which is captured. In most cases, the device <b>14</b> will need to gather additional details associated with the captured information. The application <b>22</b> causes the device <b>14</b> to communicate via its cellular carrier <b>82</b> to the internet <b>84</b> or other cloud-based data sources. Examples of data sources accessed by the device <b>14</b> include a vehicle manufacturer's DTC/service database <b>86</b> and a satellite radio service database <b>88</b>. The application <b>22</b> displays the originally captured information and the additional details to the driver, along with optional actions which may be taken by the driver. Several examples are discussed below.

0043<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart diagram <b>100</b> of a method for performing event-based information capture using the mobile device <b>14</b> in the vehicle <b>10</b>. At box <b>102</b>, information is displayed on a display unit in the vehicle <b>10</b>. At box <b>104</b>, if interested in acting on the information displayed, the driver waves the device <b>14</b> at the spot <b>80</b> associated with the displayed information. At box <b>106</b>, for the embodiment where the spot <b>80</b> is equipped with an NFC tag, the tag provides its identification information to the device <b>14</b>. At box <b>108</b>, the device <b>14</b> requests and receives from the vehicle <b>10</b> the appropriate information relating to the displayed event. The application <b>22</b> on the device <b>14</b> can automate the tasks at the box <b>108</b>, where the device <b>14</b> initiates Wi-Fi or Bluetooth communications with the vehicle <b>10</b> if such communications are not already active, the device <b>14</b> sends the information request for the event associated with the identified spot <b>80</b>, and the device <b>14</b> receives the information from the vehicle <b>10</b>.

0044At box <b>110</b>, the device <b>14</b> uses its cellular carrier <b>82</b> to request and receive additional details related to the information captured from the vehicle <b>10</b>. The request for detail is typically directed to an internet- or cloud-based data source, such as a search engine, an auto manufacturer or a satellite radio service. At box <b>112</b>, the device <b>14</b> displays the detailed data which it received at the box <b>110</b>, along with the information originally captured from the vehicle <b>10</b>. At box <b>114</b>, the driver uses the device <b>14</b> to perform additional actions based on the detailed data provided.

0045At box <b>116</b>, for the embodiment where the spot <b>80</b> is equipped with an NFC transponder, the transponder provides the information relating to the displayed event directly to the device <b>14</b> via NFC. In this case, there is no need for a separate Wi-Fi or Bluetooth communications channel. At the box <b>110</b>, the device <b>14</b> then proceeds to use its cellular service to request and receive additional details related to the information captured from the vehicle <b>10</b>.

0046Many different use-case scenarios are possible for event-based information capture. When used with the vehicle infotainment system, captured information can include a title and/or artist of a song currently being played. The device <b>14</b> can then retrieve additional information about the song and/or artist, such as the album on which the song appears, song lyrics, other works by the artist, etc. Follow-up actions offered by the device <b>14</b> include buying the song MP3 file, buying the whole album, buying tickets for a concert by the artist, etc. Advertising information could also be provided by a satellite radio or digital radio service provider when a commercial is aired. From the vehicle navigation system, information about points of interest—both commercial and public—can be provided. Point of interest actions could include calling a restaurant to make reservations, or learning the hours of operation of a museum. Integration between the vehicle's phone and the device <b>14</b> can also be provided, such as capturing contact information on the device <b>14</b> from an incoming call on the vehicle's phone, or transferring a call from the vehicle's phone to the mobile device <b>14</b>.

0047The information capture feature would also be a convenient way for a customer to purchase a satellite radio service subscription. The customer could tap the device <b>14</b> at the spot <b>80</b> in the radio to capture the satellite radio identifier from the NFC tag in the radio. From the device <b>14</b>, the customer could then purchase the service from the satellite radio service provider, who could then send an activation request via the telematics service provider to the vehicle <b>10</b>, which would then activate the satellite radio service subscription.

0048When used with the vehicle diagnostic system, tell-tale messages (warnings or notices about the status of a system) can be captured, and additional detail can be obtained from the vehicle manufacturer. For example, a dashboard display may simply provide a “Check Engine” message, but one or more specific DTCs may be recorded by an engine controller. The device <b>14</b> can capture the DTC information and retrieve additional detail about it, and provide the details—what the problem is, and how severe it is—to the driver. As a follow-up action, the device <b>14</b> could schedule an appointment for vehicle service, including transferring the DTC data to the service facility via the telematics system.

0049The event-based information capture feature described above offers great utility to the drive—providing detailed information and follow-up action options related to many different data items which could be displayed in the vehicle <b>10</b>, and doing so when the driver simply waves or taps the mobile device <b>14</b> at the data item of interest.

0050Other methods of NFC-based interaction between the mobile device <b>14</b> and the vehicle <b>10</b> are also possible. One broad category of device-vehicle interaction using NFC may be referred to as gesture-based control. In gesture-based control, motion of the NFC-enabled device <b>14</b> is detected by one or more NFC tags or readers in the vehicle <b>10</b>, and the motion is used to infer a control command for a device or feature. For example, moving the device <b>14</b> in an upward motion adjacent to a window could be interpreted to mean “close this window”.

0051Gesture-based control can be implemented in several ways, as depicted in <figref idref="DRAWINGS">FIGS. 5-8</figref>. <figref idref="DRAWINGS">FIG. 5</figref> is an illustration of a first embodiment of gesture-based control of a vehicle feature, using the mobile device <b>14</b> in conjunction with an NFC tag and Wi-Fi or Bluetooth communications. An NFC tag <b>130</b> is placed in the vehicle <b>10</b> at a location where the tag <b>130</b> is representative of a particular vehicle feature. For example, the NFC tag <b>130</b> could be placed in a door of the vehicle <b>10</b> where it represents a window opening/closing control. The NFC tag <b>130</b> does not communicate with other vehicle systems—it is a standalone tag which includes data identifying it as a window control tag. When the device <b>14</b> is passed over the tag <b>130</b>, the device <b>14</b> reads the data from the tag <b>130</b> and determines that the driver wishes to invoke a window control. The device <b>14</b> then uses its own motion detection sensors, such as gyroscopic sensors and accelerometers, to determine the type of motion that the device <b>14</b> was experiencing when it was passed over the tag <b>130</b>. For example, an upward motion would mean “close this window”. The device <b>14</b> communicates the functional command to a controller <b>140</b> in the vehicle <b>10</b> using another wireless communications technology, such as Bluetooth or Wi-Fi.

0052In the first embodiment of gesture-based control shown in <figref idref="DRAWINGS">FIG. 5</figref>, many of the NFC tags <b>130</b> could be placed in the vehicle <b>10</b>, one for each different system or feature. For example, one of the NFC tags <b>130</b> could be placed in the driver's door or door pillar for window control, one in the driver's door handle for door lock control, one adjacent to the driver's seat for seat position control, etc. Both translational and rotational control commands can be provided by the device <b>14</b>, as most smart phones include sensors capable of measuring both types of motion. Rotational control commands could be used to control outside rear-view mirrors, for example.

0053<figref idref="DRAWINGS">FIG. 6</figref> is an illustration of a second embodiment of gesture-based control of a vehicle feature, using the mobile device <b>14</b> in conjunction with multiple (two or more) NFC tags and Wi-Fi or Bluetooth communications. In the second embodiment, NFC tags <b>132</b>, <b>134</b> and <b>136</b> are placed in close proximity of one another, and are collectively used to represent one vehicle feature, such as a door lock. As in the first embodiment, the NFC tags <b>132</b>-<b>136</b> are standalone tags containing a small amount of identification data, but not connected to other vehicle systems. When the device <b>14</b> is passed over the tags <b>132</b>, <b>134</b> and <b>136</b>, the device <b>14</b> reads the data from each tag in succession. From this, the device <b>14</b> determines not only what vehicle feature is to be controlled, but also what the direction of control is. For example, if the device <b>14</b> encounters the NFC tags <b>132</b>-<b>134</b>-<b>136</b> in that order, the device <b>14</b> knows that the driver wishes to lock the doors. If the device <b>14</b> encounters the NFC tags <b>136</b>-<b>134</b>-<b>132</b> in that order, the device <b>14</b> knows that the driver wishes to unlock the doors. As in the first embodiment, the device <b>14</b> communicates the actual functional command to the controller <b>140</b> in the vehicle <b>10</b> using another wireless communications technology, such as Bluetooth or Wi-Fi. Tag layouts may be defined in a linear, grid or an arbitrary shape. Given a sufficient number of tags, this would enable a variety of complex input gestures to be derived from device movement across and around the defined pattern.

0054<figref idref="DRAWINGS">FIG. 7</figref> is an illustration of a third embodiment of gesture-based control of a vehicle feature, using the mobile device <b>14</b> in conjunction with a vehicle-integrated NFC chip. An NFC chip <b>142</b> communicates with a controller <b>150</b>. The NFC chip <b>142</b> is placed in a location appropriate for the system or feature which it represents, such as a window control. When the mobile device <b>14</b> is passed over the NFC chip <b>142</b>, the chip <b>142</b> detects an NFC signal from the device <b>14</b> and communicates to the controller <b>150</b> that a window control is forthcoming. At the same time, the device <b>14</b> determines that it has passed over the NFC chip <b>142</b>, and ascertains that the chip <b>142</b> represents a window control. The device <b>14</b> uses its own sensors to determine its motion profile, and sends its motion or gesture profile parameters to the chip <b>142</b> via NFC. For example, an upward motion indicates that the window is to be closed. The NFC chip <b>142</b> passes the window control command along to the controller <b>150</b>, which executes the command. In this case, no Bluetooth or Wi-Fi communications are used.

0055<figref idref="DRAWINGS">FIG. 8</figref> is an illustration of a fourth embodiment of gesture-based control of a vehicle feature, using the mobile device <b>14</b> in conjunction with multiple vehicle-integrated NFC chips. In this embodiment, NFC chips <b>144</b>, <b>146</b> and <b>148</b> communicate with the controller <b>150</b>. When the device <b>14</b> passes over the chips <b>144</b>-<b>148</b>, each of the chips <b>144</b>-<b>148</b> sends a signal to the controller <b>150</b> indicating it has been contacted by the device <b>14</b>. The sequence of the signals from the chips <b>144</b>-<b>148</b> indicates not only the system being controlled but also the direction of the control. For example, if the device <b>14</b> encounters the NFC chips <b>144</b>-<b>146</b>-<b>148</b> in that order, the controller <b>150</b> knows that the driver wishes to lock the doors. If the device <b>14</b> encounters the NFC chips <b>148</b>-<b>146</b>-<b>144</b> in that order, the controller <b>150</b> knows that the driver wishes to unlock the doors. In this embodiment, the controller <b>150</b> receives all of the information it needs from the NFC chips <b>144</b>-<b>148</b>. The device <b>14</b> does not need to transmit any motion information in this embodiment; the command gesture is detected by the chips <b>144</b>-<b>148</b> and the command is interpreted by the controller <b>150</b>.

0056By extending the inherently secure NFC technology to include continuous time communications sessions, while integrating device charging and other features, the methods disclosed herein provide many features to the vehicle driver in a secure and convenient package. At the same time, these methods allow the vehicle manufacturer to offer advanced features, while reducing cost and improving reliability via a reduction in the number of physical switches and controls.

0057The foregoing discussion discloses and describes merely exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion and from the accompanying drawings and claims that various changes, modifications and variations can be made therein without departing from the spirit and scope of the invention as defined in the following claims.