Vehicle system passive notification with remote device

Abstract

Comprehensive methods for monitoring vehicle systems: Determine whether a vehicle system to be monitored is in an alarm state; Determine whether a vehicle is occupied; and based at least partially on the vehicle system alarm status determination and whether it is determined that the vehicle is occupied, sending a vehicle system alarm based at least partially on a specific alarm status to a user's wireless device, the vehicle system is a parking brake monitoring system, characterized by Determine (807) based at least partially on the vehicle GPS coordinates whether the vehicle is on a slope, wherein sending (811) is further based at least partially on a determination that the vehicle is parked on the slope.

Description

BACKGROUND 1. Technical field

[0001] The exemplary embodiments generally relate to vehicle systems with passive reporting and a remote device. 2. Background

[0002] Mobile phone and PDA displays are increasingly capable of showing an ever more complex variety of information. Colored, touch-sensitive displays can offer users graphical interfaces, detailed figures, and a variety of other interactive information.

[0003] Furthermore, there is a growing societal need for on-demand access to information. In a world of Google, Yahoo!, and Wikipedia, users are becoming accustomed to having any and all information they desire readily available.

[0004] Although this information is useful in many areas, it is also often static. That is, it is fixed, factual information. However, the integration of dynamic "facts" has slowly begun.

[0005] It is now also possible to have updates, such as an update showing when an invoice is due, sent to a mobile phone, for example as a text message.

[0006] Monitoring of vehicle systems is known, for example, in EP 1 039 077 A2, US 6 930 614 B2, US 2001 / 0 020 893 A1, DE 198 34 126 A1, US 2009 / 0 216 399 A1, DE 10 2005 027 926 A1 and DE 603 ​​16 346 T2. SUMMARY

[0007] In a first exemplary embodiment, a method for monitoring a vehicle sensor includes activating one or more monitoring systems and monitoring the one or more activated monitoring systems.

[0008] Furthermore, the procedure includes detecting a change in the state of one or more monitored systems and sending an alarm to the user at the remote device if at least one of the one or more monitored systems has changed its state to a state in which an alarm should be sent.

[0009] In one embodiment of the invention, a method for monitoring vehicle systems according to claim 1 includes determining whether a vehicle system to be monitored is in an alarm state and determining whether a vehicle is occupied. Based at least partially on the determination of the vehicle system alarm state and whether it is determined that the vehicle is occupied, the method can send a vehicle system alarm based at least partially on a specific alarm state to a user's wireless device.

[0010] Advantageous embodiments of the invention are described in the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an illustrative example of a communication system through which a nomadic device can communicate with a vehicle; Fig. 2a-d show illustrative examples of vehicle-based communication modules that provide communication to a remote network; Fig. Figure 3 shows an illustrative example of communication between a remote wireless device and a vehicle-based wireless device; Fig. Figure 4 shows an exemplary embodiment for passively monitoring a vehicle system; Fig. Figure 5 shows another exemplary embodiment of a passive monitoring strategy; Fig. 6a shows an illustrative example of monitoring a trailer connection; Fig. Figure 6b shows a second example of monitoring a weather sensor; Fig. Figure 7 shows an illustrative example of a reporting strategy; Fig. Figures 8a-8b show an example of a parking brake monitoring system; Fig. Figure 9 shows an example of a security alarm monitoring and transmission system; and Fig. Figure 10 shows an illustrative example of providing monitoring states for a specific driver or a specific set of drivers. DETAILED DESCRIPTION

[0011] Detailed embodiments of the present invention are disclosed herein. It is understood, however, that the disclosed embodiments are only exemplary of an invention that can be implemented in various and alternative forms. The specific functional details disclosed herein are therefore not to be interpreted as limiting, but only as a representative basis for the claims and / or as a representative basis for teaching a person skilled in the art of the various ways in which the present invention can be used.

[0012] Fig. Figure 1 shows an illustrative example of a communication system through which a nomadic device can communicate with a vehicle 121. In this exemplary embodiment, a nomadic device (e.g., without limitation, a cellular telephone) 103 is used to send a communication through a cellular network 107. This communication is forwarded through a network 111 (e.g., without limitation, the cellular network, the Internet, etc.) to a central system 101. A device described in Fig. A similar system is available from CRAYON INTERFACE, INC.

[0013] In this exemplary embodiment, the central system is a server system that includes processing capability for signals from a nomadic device intended to interact with a remote vehicle 121.

[0014] For example, Server 101 can include an automatic connection server and / or web host. Furthermore, Server 101 can route an incoming signal from a nomadic device (ND)103 to the corresponding remote vehicle. Data transmitted in this manner can be sent using Data-Over-Voice, a Data Plan, or in any other suitable format.

[0015] Data can also be sent from a personal computer 105 through server 101 to the remote vehicle 121. In this case, the data will probably, but not necessarily, be sent via the internet 109.

[0016] As soon as server 101 receives the incoming data request from remote source 103, 105, the message is processed and / or forwarded to a vehicle 121. The vehicle can be identified by a header associated with one or more incoming data packets or can be identified based on, for example, a database search.

[0017] The signal to vehicle 121 is transmitted by server(s) 101 through a network (e.g., an unlimited cellular network 113, the internet, etc.) and routed to vehicle 121 via a cellular network 115. In one embodiment, the signal can additionally be routed through a broadband network 114 (e.g., 802.11g or WiMAX). A remote communication module 200 in vehicle 121 receives the signal transmitted by server(s) 101 and processes it or forwards it to a corresponding processing system in vehicle 121.

[0018] In at least one exemplary embodiment, the vehicle 121 is also equipped with a communication transceiver, such as, but not limited to, a Bluetooth transceiver. This transceiver can allow communication with the nomadic device 103 using a direct signal 119, for example, when cellular networks are unavailable.

[0019] Fig. 2a-d show illustrative examples of vehicle-based communication modules that provide communication with a remote network.

[0020] Fig. Figure 2a shows an illustrative example of a communication module 200 combined with a GPS module, wherein a cellular module and GPS are located on different circuit boards.

[0021] In this exemplary embodiment, a communication module 200 can include a cellular (e.g., GSM or CDMA, without limitation) antenna 201 that can communicate with a remote server via a cellular network. The received cellular radio signal can be sent from the cellular antenna 201 to a multi-band cellular (e.g., GSM or CDMA, without limitation) decoder 219, which processes the received signal to generate information usable by the microprocessor 217.

[0022] In this exemplary embodiment, the multi-range cellular chip 219, including the flash memory 207 and RAM 211, is installed in the module as part of a removable device 223, including a SIM card 221. The SIM card 221 can contain user-identifying information that allows access to the cellular network under a specific user's plan.

[0023] Additionally, the module includes a GPS module 203, which can process and decode a signal from the GPS antenna 205 and send this information to a microprocessor 217.

[0024] The microprocessor also communicates with a vehicle data bus, which provides access to various vehicle modules, such as the RF module 215. Other modules, not shown, include, but are not limited to, the vehicle group, a remote GPS system (off-board), a radio module, etc. Examples of vehicle data buses include an SAE J1850 bus, a CAN bus, a GMLAN bus, and any other vehicle data bus known in the industry. The following are for illustrative purposes only: Fig. 2a-2d is shown using a CAN bus.

[0025] Fig. Figure 2b shows a second exemplary embodiment in which a cellular chip and GPS are located on the same circuit board 223. In this exemplary embodiment, the removable circuit board (this circuit board can also be permanently attached to the module) 223 can contain the SIM card 221, a GPS module including a GPS chip 203 and a GPS antenna 205a, and the multi-range cellular chip 219 including flash memory 207 and RAM 211.

[0026] In another embodiment, the GPS antenna 205b can be attached to the module separately from this circuit board 223. When a signal is received from the cellular antenna 201 and / or the GPS antenna 205b, the signal can be sent to the corresponding cellular / GPS module 203 for processing and then forwarded to the microprocessor 217. The microprocessor 217 is connected to the CAN transceiver 213 for connection to a vehicle network 214 and vehicle modules such as the RF module 215.

[0027] Fig. Figure 2c shows another exemplary embodiment in which the cellular module is standalone. In this exemplary embodiment, the GPS module, which contains the GPS antenna 205 and the GPS chip 203, can be connected to the microprocessor 217 via the CAN transceiver 213. Other vehicle modules, such as an RF module 215, can also be connected to the microprocessor via the CAN transceiver 213.

[0028] In this exemplary embodiment, the removable circuit board 223 can contain a SIM card 221 and a multi-band cellular module 219, as well as a flash memory 207 and RAM 211. Signals from the cellular antenna 201 can be sent to the circuit board 223 for processing by the multi-band cellular module 219 before being sent to the microprocessor 217.

[0029] Fig. Figure 2d shows another exemplary embodiment in which a cellular module is combined with an RF module 215 in the communication module 200. The RF module 215 can still communicate with the microprocessor 217 via the CAN transceiver 213. In this exemplary embodiment, the GPS module, including the GPS antenna 203a, 203b and the GPS chip 205a, 205b, can be located inside the communication module 200 or elsewhere in the vehicle, in which case it can communicate with the microprocessor 217 via the CAN transceiver 213.

[0030] In this embodiment, the cellular antenna 201 can in turn send a signal to the multi-band cellular module 219, including the flash memory 207 and RAM 211. The signal can be processed and sent to the microprocessor 217. The multi-band cellular module 219 can be located on a removable circuit board 223, which can also include a SIM card 221.

[0031] Fig. Figure 3 shows the operation of a communication module 200 according to an exemplary embodiment. The nomadic device (ND) 103 and / or the computer 105 may include software to facilitate the operation of one or more embodiments. The software may be downloaded to the ND 103 or the computer 105 from a website (such as an OEM website) or, as another example, may be factory-installed in the ND. In one embodiment, the software may be programmed in the Java language (manufactured and distributed by Sun Microsystems).

[0032] In one or more embodiments, a user can control a vehicle with multiple ND 103 units or computers 105. Additionally or alternatively, the user can use one ND 103 or one computer 105 to operate components of multiple vehicles.

[0033] The user can activate and operate the software by pressing one or more buttons or keys on their ND 103 and / or Computer 105. In one exemplary embodiment, the ND 103 and / or Computer 105 can be equipped with a "hot button" from which the software can be activated. Alternatively or additionally, the user can activate and operate the software by selecting from a menu in a graphical user interface (GUI) displayed on the ND 103 and / or Computer 105.

[0034] Furthermore, computer-readable storage media, including but not limited to hard disk drives, solid-state and volatile storage media, floppy disks, CDs, DVDs, flash drives, Zip drives, etc., may contain instructions that facilitate one or more of the exemplary embodiments. The instructions are typically machine-readable and executable by a processor on, for example, without limitation, the nomadic device, the server, and / or the vehicle-based microprocessor.

[0035] Alternatively or additionally, the user can operate and activate the software by means of one or more speech-activated commands received by the ND 103 and / or the computer 105. The ND 103 and / or the computer 105 may include speech recognition software for interpreting and processing commands from a user into machine-readable language. In one embodiment, the speech recognition software may be programmed and / or stored on the web server. Non-limiting examples of a user include a vehicle owner, a vehicle passenger, a vehicle maintenance technician, or a vehicle dealer.

[0036] When a request is made (e.g., by pressing a key or by voice), one or more data packets can be transmitted from the ND 103 or the computer 105, as shown in Block 300. Non-limiting examples of data (i.e., information) transmitted in the data packets may include a mobile device identification number (MIN), a customer identification number, the one or more commands triggered by the ND 103 and / or 105, and the vehicle identification number (VIN). Furthermore, in some embodiments, the one or more data packets transmitted by the ND 103 and / or the computer 105 may include instructions for operation according to the one or more requests made by the user.

[0037] Back on Fig. 3. Referring to this, a connection to server(s) 101 can be established before or after the transmission of the data packets, as shown in block 302. Server(s) 101 may or may not be a web server. Once a connection to server(s) 101 is established, the data packets can be received by server(s) 101, as shown in block 304. Alternatively or additionally, a direct connection can be established between the ND 103 or the computer 105 and the cellular communication module 200 (i.e., without establishing a connection to server(s) 101). Accordingly, the function of one or more embodiments of the present invention can be performed without a server.

[0038] Server 101 can process one or more received commands for transmission to vehicle 121. Processing the data packet may include, but is not limited to, authentication of the one or more commands, user authentication (e.g., determining whether the user is a registered user), and authentication of the cellular / mobile phone (e.g., comparing the MIN with the VIN) transmitted in the data packet.

[0039] In a non-limiting embodiment, the server(s) 101 can process the data packet using one or more lookup tables and checking the information in the data packets against the one or more tables.

[0040] Server 101 may communicate with one or more databases (not shown). The data may be retrieved from third-party databases / servers, such as those of original equipment manufacturers (OEMs) (e.g., vehicle manufacturers), or entered manually by a user (e.g., an OEM).

[0041] In one exemplary embodiment, a determination can be made on server(s) 101 as to whether the user has any personal preferences as shown in block 306. While the preferences may be stored elsewhere, the Fig. 3. For display purposes, the functionality is based on the personal preferences stored on the server(s) 101.

[0042] The personal preferences can be stored on the server(s) 101. Alternatively or additionally, the personal preferences can be stored in the (not shown) memory of the ND 103 or the computer 105. In a further embodiment, the personal preferences can be stored on the vehicle (e.g., on the SIM card 221, the microprocessor 217 of the cellular communication module 200, or in a memory module located elsewhere in the vehicle). In this latter embodiment, the server(s) 101 can forward the data packets to the vehicle without further processing.

[0043] Back on Fig. 3. By reference to this, if the user has personal preferences associated with one or more vehicle components, the server 101 can receive instructions to access the stored preferences as shown in block 308. In one embodiment, the instructions can be transmitted with the one or more data packets received by the ND 103 and / or the computer 105. The server 101 can extract or read these instructions from the data packets to retrieve the stored personal preferences.

[0044] In an exemplary embodiment, a further determination can be made on server(s) 101 as to whether a personal identification number (PIN) is required to access personal preferences or to operate one or more features of the software as shown in block 312. The PIN can be stored on server(s) 101 or transmitted with the data packets transmitted by the ND 103 and / or computer 105. If a PIN is required, server(s) 101 can transmit a PIN request as shown in block 314. The request can be transmitted to one or more storage locations (e.g., a database) on server(s) 101 or to the remote terminals 103, 105.The PIN can be retrieved from server(s) 101 using, for example, a lookup table based on information such as a VIN, customer number, MIN, or other non-limiting identifiers. It is understood that the PIN can be retrieved by any other technically known means, and the above example is for illustrative purposes only.

[0045] For example, it may be desirable to restrict certain features to PIN only. A tracking feature, for instance, might be PIN-restricted because, depending on the features available on the phone, it could also allow someone who found a cell phone to locate and potentially gain access to the vehicle. Accordingly, the tracking feature might require a PIN for activation.

[0046] In one exemplary embodiment, once a PIN has been entered, it does not necessarily need to be entered again until the phone has been deactivated and reactivated.

[0047] Server 101 can receive the PIN as shown in block 316. The PIN can then be checked for validity as shown in block 318. If the PIN is incorrect, Server 101 can retransmit the request as shown in loop 320. In one embodiment, a user can re-enter the PIN a predetermined number of times (e.g., three or five times) after entering an incorrect PIN. If the PIN is correct, Server 101 can retrieve the personal preferences associated with the request as shown in block 322 and transmit the one or more data packets containing the stored preferences to the cellular communication module as shown in block 310.

[0048] If a PIN is not required to access personal preferences, or if no preferences are stored, upon receiving one or more data packets, server 101 can transmit the one or more data packets to the cellular communication module as shown in block 310. The one or more data packets can be transmitted via the network (e.g., cellular network 113 or the internet). The cellular communication module 200 can then receive the one or more data packets via the network (e.g., via the GSM antenna 201) as shown in block 326. One or more signals can then be generated for transmission to the vehicle CAN network 214, as shown in block 328 (e.g., by the multi-band GSM decoder 219).

[0049] In one embodiment, the one or more signals can be decoded and translated by the microprocessor 217, which can communicate with the GSM decoder 219 via electrical communication, for transmission to the CAN interface (e.g., CAN transceiver 213 and vehicle network 214). (Communication with / through other vehicle system buses that differ from the CAN bus is also possible.) The one or more signals can be decoded by the vehicle network 214 for design purposes. The one or more signals (including the data packets) can then be transmitted to the CAN interface (e.g., the CAN transceiver 213) as shown in block 330.

[0050] Upon receiving one or more request signals, the CAN transceiver 213 can transmit the one or more request signals via the vehicle network 214 to the one or more vehicle components.

[0051] After completion of one or more functions based on the user's request / command, the CAN transceiver 213 can receive the one or more result signals transmitted by the one or more vehicle components, as shown in block 332. The CAN transceiver 213 can transmit the one or more return signals to the microprocessor 217 to extract one or more return data packets for transmission to the ND 103 and / or 105, as shown in block 334. Transmission can be effected via the GSM antenna 201 over the network 115.

[0052] When transmitting one or more result data packets as shown in block 336, the data packets can be transmitted to the remote terminals 103 and / or 105. In one embodiment, the return data packets can be routed through server 101 as shown in block 338, which may or may not further process the data packets for transmission to the remote terminals 103 and / or 105. The result data packet(s) can be transmitted to and received by terminal 103 and / or computer 105 as shown in block 340.

[0053] A report can be generated and displayed to the user as shown in block 342. The report can be generated each time the user requests one or more functions. Alternatively or additionally, the report can be generated at predetermined intervals or according to a user preference (e.g., monthly or whenever a user specifically requests a report).

[0054] In at least one exemplary embodiment, communication is possible between a vehicle-based cellular module and a remote wireless device. This communication can be used, among other things, to send the GPS coordinates of a vehicle to the wireless device. The GPS coordinates can be transmitted to a wireless transceiver via a vehicle system bus or via another connection (for example, RF or Bluetooth if the GPS is not connected to a vehicle system bus).

[0055] Fig. Figure 4 shows an exemplary embodiment for passively monitoring a vehicle system. In this exemplary embodiment, monitoring is activated, 401. Monitoring can be activated from a vehicle computer system such as the FORD SYNC system. For example, without limitation, a user could select from a keypad menu or activate monitoring of a specific vehicle system by voice. In this way, numerous vehicle systems can be passively monitored.

[0056] In another exemplary embodiment, passive system monitoring can be activated from a remote source such as a cell phone or a PC. In this exemplary embodiment, the user can, for example, pull up a menu and select a system or systems to be monitored. The signal is then sent, for example, from the selecting remote device to a server, and the server forwards the call to the appropriate vehicle. Verification of the request can be performed on the server side or on the vehicle itself.

[0057] Once monitoring is activated, a microprocessor within the vehicle can begin monitoring a selected sensor 403, for example, via a vehicle system bus. In this illustrative example, a signal can be sent to or received from the sensor, querying its state. The sensor can be a binary sensor (e.g., in a first state or a second state) or it can monitor for a specific threshold change. This monitoring can be performed periodically using a turn-on strategy or continuously.

[0058] Furthermore, in this exemplary embodiment, a power source can be provided to power the microprocessor and / or the sensor itself. Typically, a sensor will require some power, and it may be desirable to use a power source other than the battery. A capacitor can be provided by the vehicle to power the system, or a limited battery charge can be used. In at least one exemplary embodiment, monitoring can be performed, for example, every X minutes to prevent the power source from being continuously drained.

[0059] As part of this exemplary procedure, the system periodically checks whether the power source is running low. 405 If the power source runs low, a low-current alarm can be sent to a user. 407 This alarm can be sent, for example, to a remote device such as a cellular phone or a PC. In this illustrative example, the signal is sent from a vehicle microprocessor through a cellular module to a remote server. The signal is then routed from the remote server to the appropriate remote device, and the user is then notified of a low-current state of the power source.

[0060] Once the notification has been sent, the system can continue monitoring (403). If monitoring continues with a low power source, the system may not further warn the user about the low power condition. If the power is not low, or once the low power alarm has been sent, the system then checks whether there has been a change in the sensor's state (409). If there has been no change in the sensor's state, the system can continue monitoring the sensor (403).

[0061] If a change in the sensor state occurs, an alarm can be sent to the user (411). For example, this alarm can be sent to a remote device such as a cell phone or a PC. This alarm can be sent in the same way as the low-current alarm.

[0062] Fig. Figure 5 shows another exemplary embodiment of a passive monitoring strategy. In this exemplary embodiment, the vehicle system receives a signal 501. This signal can be transmitted from a remote device such as a cellular phone or a PC. The signal is routed from the remote device to the vehicle system via a server. The signal can be checked for validity, for example, at the server or at the vehicle.

[0063] Once the signal has been received, the system in this exemplary embodiment checks the charge of the power source 503 (other than the battery in this embodiment), which is used to power the microprocessor and / or the sensor.

[0064] When the power source 505 is charged, the system activates the sensor and / or the monitoring of the microprocessor 515. In this exemplary embodiment, if the secondary power source 505 is not charged, the system sends a notification to the user to choose to use a battery 507. Thus, in this embodiment, the vehicle battery can be used as an alternative power source to the secondary power source.

[0065] The system then receives a response from user 509 (for example, sent from a remote device) instructing the system whether the user wants the system to use the battery instead of the secondary power source. If user 511 does not want to use the battery, the system then shuts down.

[0066] If the user wishes to use the battery as a power source, the system activates a battery check option 517. Because the battery is used for vital functions such as starting a vehicle, in this exemplary embodiment the user is first given the option to use the battery. Even if the user chooses to use the battery, in this embodiment the system will monitor the battery to ensure that sufficient power remains in the battery to power the vehicle.

[0067] Once the battery test has been initiated, the monitoring system is activated 515. After the monitoring system has been activated, the vehicle system checks whether the battery test is activated 519.

[0068] When the battery is low 523, the system terminates monitoring 525 to conserve battery power. In another exemplary embodiment, a final check of the monitoring system can be performed. In this embodiment, monitoring 525 is terminated as soon as it is determined that the battery level is low. Since the user may still believe that the sensor is being monitored, the user is notified of the low battery status and the termination of monitoring 527. If the battery check is not enabled or if the battery is not low, the system continues to monitor the sensor(s) selected by the user for monitoring.

[0069] In another exemplary embodiment, not shown here, the system can also monitor the secondary power source and then notify the user when this source runs out of power and provide the option to use the battery 507.

[0070] Fig. Figure 6a shows an illustrative example of monitoring a trailer connection. Similar strategies can be used to monitor a variety of devices. This is just one example of a binary monitoring system, where a state is either on or off.

[0071] In this exemplary embodiment, trailer connection monitoring is activated 601. The monitoring system checks whether the trailer is still connected 603. This can be done by checking a power connection to the trailer or by using a secondary sensor provided to monitor the connection. If the trailer is still connected, monitoring continues 601. If the trailer is not connected, the system sends an alarm to the user on a remote device 605.

[0072] Furthermore, in certain systems, such as trailer monitoring, a secondary action can be performed. In this exemplary embodiment, it may be desirable to activate an alarm system 607. This could, for example, prevent the theft of a trailer while simultaneously notifying the user via a remote device.

[0073] In another, in Fig. In the illustrative example shown in Figure 6b, a sensor with a threshold value is monitored. In this example, the device is a rain gauge and / or a barometer 611. A rain gauge could detect the presence of moisture on a sensor or the windshield, and a barometric pressure change could signal the onset of a storm. Such monitoring could be useful, for example, when a sunroof or window is down.

[0074] In this exemplary embodiment, the system checks one or more sensors to see if a change in the weather has occurred (613). This could be done by the systems mentioned above or by additional systems. If the weather conditions have not changed, the system continues to check the sensors (611). If the weather conditions do change (for example, if a threshold value on a barometer is exceeded), an alarm is sent to the user via a remote device. The alarm can be sent in the ways already mentioned.

[0075] As with the trailer coupling, a secondary action can be performed. In this exemplary embodiment, the secondary action could be raising the windows of a car or the roof of a convertible 617. Alternatively, a user could be given the option of having the vehicle system perform one or more of these actions.

[0076] Fig. Figure 7 shows an exemplary embodiment of a notification strategy. In at least one exemplary embodiment, it might be desirable to determine whether the vehicle is actually occupied before notifying the driver of a change in its condition. For example, if a "lights on" status were sent to a telephone, it might be annoying for a driver to receive this notification while still in the vehicle. Accordingly, in this exemplary embodiment, the system checks whether the vehicle is still occupied before sending a notification.

[0077] There are numerous ways to determine vehicle occupancy, and all are suitable for implementing the exemplary embodiments. For example, a non-exhaustive list includes checking the vehicle's electrical state, checking whether the doors have opened and closed, checking whether an interior camera has detected the presence of passengers, checking for no change in position and / or movement of an accelerometer for a certain period of time, and checking for no speech activity or sounds on an interior microphone.

[0078] Some or all of the above examples can be used. Furthermore, a single example might suffice to determine occupancy / unoccupancy, or it might be desirable to use several of the examples together (e.g., without limitation, doors have opened and closed, and the vehicle's power state is "off").

[0079] Numerous passive monitoring strategies can be used and / or combined with vehicle occupancy detection. For example, a lamp and / or door alarm can be available. In this example implementation, a vehicle can detect whether lamps have been left on and / or one or more doors have been left ajar.

[0080] Although not necessary, in the present implementation the detection is combined with the vehicle occupancy detection strategy, so that a user is only notified when it is reasonably determined that the vehicle is unoccupied.

[0081] Furthermore, for at least some number of these detection strategies, notification could then be carried out when, for example, a power shutdown is performed (in order to use the residual current of the vehicle to perform the detection).

[0082] In another illustrative example, a sensor check (lights on and / or door open) is performed when a user locks a vehicle with the key fob. This typically indicates that the user is both a) no longer in the vehicle and b) will be leaving the vehicle for some time.

[0083] In a further exemplary embodiment, as in Fig. Figure 8A-B shows a parking brake monitoring system. This can be particularly helpful with manual transmissions, although it is equally applicable to automatic and hybrid transmissions.

[0084] In the first, in Fig. In the exemplary embodiment shown in 8a, the system checks whether the vehicle has been parked and / or whether the vehicle is in neutral and switched off (801). This is not an exhaustive determination of when, for example, a parking brake check could be applied; at least one other suitable implementation would be when the vehicle is in neutral and the brake pedal has not been depressed. The system then checks whether the parking brake is engaged (802).

[0085] If the brake is not engaged, the system checks the GPS coordinates of the vehicle 803 and cross-references them with the topographic map 805 or any other map that would show a sloping incline.

[0086] If the vehicle is on a slope 807, the user will be notified 809 that the parking brake is not engaged. Fig. 8b is the procedure of Fig. 8a similar, except that instead of GPS detection and comparison 803, 805 a slope sensor is used in the vehicle 813.

[0087] Although both of these methods can be combined with vehicle occupancy detection, it might be desirable to forgo occupancy detection in these cases, since at present, if an occupant who has left a vehicle in neutral on a slope without the brakes engaged has left the vehicle, it might be too late to stop the vehicle from rolling away.

[0088] In another exemplary embodiment, a vehicle can transmit the charge / charged state of a battery if it is an electric vehicle or, for example, a hybrid.

[0089] Built-in vehicle systems could also be used for rental car assistance, for example. Vehicle locations, rental agreements, payment information, fuel levels, etc., could be instantly transmitted to one or more handheld devices (renter, owner, etc.).

[0090] All of the above examples represent general embodiments that are typically carried out when a vehicle is switched off or left in one location. However, there are a number of additional possible passive monitoring alarms that can be activated and / or provided when a vehicle is switched on. In general, in these cases, the sensor(s) can be powered by the vehicle with little concern that the battery will be drained by powering the sensor(s).

[0091] In a first exemplary embodiment, an example of passive monitoring of the switched-on vehicle includes a safety status alarm. This can include, but is not limited to, a low battery warning, a bulb failure warning, a diagnostic code setting warning, a service due warning, an excessive temperature warning (oil, coolant, brakes, transmission, etc.), a low oil pressure warning, a low tire pressure warning (vehicle, trailer), and a parking brake engaged warning while driving. Certain of these warnings, such as the parking brake warning, can be addressed without having to go to a repair station. In other cases, the location or telephone number of the nearest / applicable repair shop can be uploaded to the user's remote device in conjunction with the report.

[0092] Fig. Figure 9 shows an example of a safety alarm monitoring and transmission system. In this exemplary embodiment, one or more safety sensors are monitored by the system 901.

[0093] If an alarm is required (903), then the system determines whether additional information (such as an address, telephone number, etc. of a service workshop / dealer / gas station, etc.) is needed (905).

[0094] If additional information is required, the system searches for the additional information 907 and adds it to the alarm message 909. The alarm message is then transmitted to the user 911 (the message is also transmitted even if no additional information is provided).

[0095] It is also possible to implement a number of active alarm thresholds to track the driving performance / condition of a certain group of drivers or a specific driver.

[0096] For example, in at least one exemplary embodiment, a valet mode (use by an authorized third party) can be set (valet class). Similarly, a specific driver mode can be set, for example, by using a certain key to start the car, without limitation. This can be useful if a young person or other unreliable driver is operating the car.

[0097] When one of these modes is selected, the system can send alerts to a user if certain thresholds are exceeded. These alerts include, but are not limited to, over-temperature monitoring, monitoring of driving with the parking brake engaged, monitoring of aggressive driving, monitoring of leaving certain "geo-fence" areas, monitoring of excessive speed, air cushion deployment, or other vehicle safety system activation monitoring (in which case, whether the vehicle is in a specific user mode or not, a secondary message can be sent to any and all stored emergency contact information). Additional alerts may include a "drowsy driver" alert, determined using a Driver Impairment Monitor (DIMON) or other algorithm.

[0098] Additionally, a "seat stuck" alarm can be sent if the fuel level is low or at zero, the tire pressure is low or zero, the engine has a shutdown fault code assigned, the engine temperatures are extremely high, etc., and the vehicle is not moving.

[0099] Further checks before sending an alarm may include determining that multiple unsuccessful attempts have been made to start the vehicle. Additionally, the system may verify the vehicle's GPS coordinates to determine that the vehicle is not at home or in a parking lot, etc.

[0100] Seatbelt alarms can also be sent to parents of young drivers or to the drivers themselves if a certain distance is driven without a seatbelt fastened.

[0101] Another example of potential monitoring of an active vehicle could be a robbery alarm, where an interior microphone detects the utterance of a certain phrase and notifies emergency contacts and / or the police that a vehicle occupant may be at risk of being robbed. This could be followed by a reply message to the occupant informing them that a robbery has been detected and that the vehicle is now being tracked via GPS. Of course, it might be desirable not to notify the occupants, thus preventing the hijackers from taking evasive action by leaving the vehicle and taking the hostage with them.

[0102] Additionally or as an alternative, a certain button combination (of door locks, windows, etc.) could be recognized to inform about a robbery situation.

[0103] Finally, in another exemplary embodiment, a curfew alarm can be provided, which notifies a user that the vehicle will be driven after a specified curfew.

[0104] Each and every one of these monitoring states does not necessarily have to be tied to a "valet" or "young driver" mode; they can all be made generally available to any driver if desired.

[0105] Fig. Figure 10 shows an illustrative example of providing monitoring states for a specific driver or set of drivers.

[0106] In this exemplary embodiment, the system checks whether a specific driver or driver class is active 1001. As already mentioned, this could be a “valet” setting or could, for example, be activation of the vehicle by a certain key given to a specific driver (such as a young person).

[0107] The system then checks to determine whether specific alarms are assigned to this particular driver or driver class (1003). These may include, but are not limited to, the alarms mentioned above.

[0108] If there are no specific alarms, the system can end (1005). If specific alarms are assigned, the system monitors one or more sensors assigned to those alarms (1007). If an alarm condition exists (1009), the system warns a user (1011) of the condition. Otherwise, the system returns to monitoring the sensors (1007).

[0109] In another exemplary embodiment, GPS tracking can be used to determine, for example, a towing incident. If the vehicle's GPS coordinates change and the vehicle has not been started, it is likely that the vehicle is being towed, and the owner can be warned. If the customer is notified of the vehicle's movement and it is unlikely that a towing incident has occurred, the customer could also be given the option to notify 911 via the vehicle's system, and the vehicle's GPS coordinates could be tracked.

[0110] A vehicle monitoring method according to the invention particularly comprises: monitoring one or more vehicle safety systems while a vehicle is in operation to detect an unsafe condition; and sending an alarm to a handheld device when an unsafe condition is detected.

[0111] The following will continue to be given priority: Determine whether additional information regarding the correction of the unsafe condition should be included in the alarm; and, based on this determination, include additional information regarding the correction of the unsafe condition with the alarm sent, preferably including a telephone number and / or address of a service provider.

[0112] In particular, safety systems include at least one bulb condition monitoring system, one battery charge condition monitoring system, one parking brake condition monitoring system and / or one component temperature condition monitoring system and / or one maintenance due condition monitoring system and / or one panic alarm monitoring system.

[0113] A further method according to the invention for vehicle monitoring comprises: determining whether a specific driver class is present in a vehicle; determining one or more class-specific predefined systems for monitoring based at least partially on a specific driver class; monitoring one or more class-specific predefined systems while the vehicle is in operation to detect a predefined state; and

[0114] Sending an alarm to a handheld device when a predefined condition is detected.

[0115] In particular, a "valet" class (e.g., temporary use by a temporarily authorized third party) may be provided as a driver class, and its determination may be based at least partially on the "valet" function being set by a driver. Specifically, the driver class may be a specific driver, and its determination may be based at least partially on starting the vehicle with a specific key.

[0116] Preferably, the one or more class-specific predefined systems may include parking brake condition monitoring and / or crash safety system deployment monitoring and / or seat belt condition monitoring and / or aggressive driving monitoring.

[0117] Another embodiment of a method according to the invention for monitoring a vehicle sensor comprises: Activating one or more monitoring systems; Monitoring one or more activated monitoring systems; checking a power source supplying power to one or more monitoring systems to determine whether the power source is below a certain threshold; Sending a low-current alarm to a user at a remote device when it is determined that the power source is below the threshold; Discontinue monitoring of one or more monitored systems when the power source is below the threshold; Detecting a change in the state of one or more monitored systems; and Sending an alarm to the user at the remote device when at least one of the one or more monitoring systems has changed its state to a state in which an alarm should be sent. Key to symbols

[0118] Fig. 2a 201 Cellular antenna 205 GPS antenna 203 GPS module 207,211 Flash RAM 219 Multi-range cellular building block 221 SIM card 213 CAN transceiver 217 Microprocessor 215 High-frequency module Fig. 2b 207,211 Flash RAM 219 Multi-range cellular building block 201 Cellular antenna 213 CAN transceiver 205A GPS antenna 203 GPS module 221 SIM card 217 Microprocessor 215 High-frequency module 205b GPS antenna Fig. 2c 201 Cellular antenna 207,211 Flash RAM 219 Multi-range cellular building block 221 SIM card 213 CAN transceiver 217 Microprocessor 215 High-frequency module 205 GPS antenna 203 GPS module Fig. 2d 207 Flash 211 RAM 219 Multi-range cellular building block 203b GPS antenna 205b GPS module 221 SIM card 201 Cellular antenna 215 High-frequency module 217 Microprocessor 203a GPS antenna 205a GPS module 213 Vehicle bus transceiver 225 RKE TPMS two-way RKE antennas 214 vehicle bus network Fig. 3 300 Transmitting one or more request data packets 302 Establishing a connection to the server 304 Receiving one or more request data packets 308 Receiving instructions for accessing stored preferences 306 saved preferences? 310 Transmitting a request for one or more data packets 322 Retrieving saved preferences 312 PIN required? No, no Yes, yes 314 Transferring PIN request 316 PIN received 318 PIN correct? 326 Receiving data packets at the communication module 328 Decoding one or more signals for communication with the vehicle network 330 Listening for / transmitting one or more signals to / from the vehicle network 342 Displays of status / result for users 340 Transferring one or more result data packages 338 Receiving one or more result data packets at server(s) 336 Transmitting one or more data packets 334 Extracting one or more result data packages 332 Receiving one or more result signals from vehicle component(s) Fig. 4 401 Enable monitoring 403 Monitor sensor 411 Send sensor alarm Send 407 Low current alarm 405 Low power? YJ NN 409 Sensor change? YJ NN Fig. 5 501 Signal received Send option 507 “Use battery” 509 Signal received Use battery 511? 513 End 503 Check load 505 loaded? 515 Activate system 517 Activate battery check Notify 527 users about the end of monitoring 521 Monitor system 519 Battery test? NN YJ 523 Low battery? YJ 525 End monitoring Fig. 6a YJ 601 Monitor trailer connection 603 trailers attached? 605 Send alarm 607 Activate vehicle alarm Fig. 6b 611 Rain gauge / barometer monitoring 613 weather conditions? 615 Send alarm 617 Turn up window / roof YJ Fig. 7 701 Detect alarm condition 703 Vehicle unoccupied? Alert 705 users 707 back to sensor Fig. 8a 801 Vehicle in park and / or neutral gear m / o electricity? 802 Parking brake engaged? Check 803 GPS coordinates 805 coordinates cross-referenced with a topographic map 807 Vehicle on a slope? 809 End Alert 811 users YJ Fig. 8b 801 Vehicle in park and / or neutral gear m / o electricity? 802 Parking brake engaged? 813 Check tilt sensor 807 Vehicle on a slope? 809 End Alert 811 users YJ Fig. 9 901 Check security status(s) 903 Alarm needed? 905 additional pieces of information needed? 911 alarm transmitted Search 907 additional pieces of information 909 Add additional information to the alarm YJ Fig. 10 1001 Is a specific driver or driver class active? 1003 Alarms assigned to the driver class? 1007 sensors monitor 1009 Alarm status present? Alert 1011 users 1005 End YJ

Claims

Method for monitoring vehicle systems comprising: determining whether a vehicle system to be monitored is in an alarm state; determining whether a vehicle is occupied; and, based at least in part on the vehicle system alarm state determination and whether it is determined that the vehicle is occupied, transmitting a vehicle system alarm based at least in part on a certain alarm state to a user's wireless device, wherein the vehicle system is a parking brake monitoring system, characterized by determining (807) based at least in part on the vehicle GPS coordinates, whether the vehicle is on a slope, wherein the transmission (811) is further based at least in part on a determination that the vehicle is parked on the slope. The method according to claim 1, further comprising performing a secondary action based at least partially on the determination of the vehicle system alarm state and whether it is determined that the vehicle is occupied.

Images