CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to Provisional Patent Application S/N 62/048,969 filed on 09/11/2014. All disclosure of the Provisional application is incorporated at least by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is in the field of safety alert systems and pertains particularly to methods and apparatus for providing proactive safety and emergency response at least for children and/or pets trapped in a vehicle.

2. Discussion of the State of the Art

It is quite well known that particularly pets and children and occasionally elderly or disabled persons are sometimes left in a parked vehicle with no means for escape. Heat and/or other ambient conditions may change to form a dangerous or even fatal situation for a pet or a person. At the time of this application systems for vehicles are typically focused on theft prevention with the use of tamper alarms and accident reporting systems such as the well known On Star system for reporting accidents and the like and directing responders to the scene.

Therefore, what is clearly needed is a mobile alert system for vehicles that quickly detects dangerous situations within parked vehicles and reports to a responsible adult and/ or if unavailable to nearest authorities or first responders. BRIEF SUMMARY OF THE INVENTION

In an embodiment of the invention an alert system is provided comprising a processing and communication unit located in a vehicle and having a processor executing software from a non-transitory medium and a coupled data repository, a plurality of sensor interfaces to the processor interfacing to a plurality of sensors located at a variety of locations in the vehicle, a communication module coupled to the processor and enabled to at least send communications to an Internet network, a global positioning system (GPS) coupled to the processor, determining geographic location of the vehicle. The processor monitors data from the plurality of sensors, consults preprogrammed status information based on one or both of one or more sensor readings or combinations of sensor readings, and selects and sends according to the one or more sensor readings or combinations of sensor readings, by the communications module, a preprogrammed communication addressed to a particular Internet destination.

In one embodiment the plurality of sensors comprise one or more capacitive sensors in the vehicle to sense presence of a human or other animal, one or more temperature sensors, and one or more sensors sensing relative level of one or more gases in air in the vehicle. Also in one embodiment the one or more sensors sensing relative level of one or more gases in air in the vehicle, include one or more sensors sensing level of carbon dioxide gas. Also in one embodiment sensor status states are preprogrammed using specific threshold temperature and gas composition levels, and combinations of sensor input prejudged to indicate levels of danger to humans or other animals sensed to be in the vehicle. Also in one embodiment status states are categorized in ascending levels of danger or seriousness.

In one embodiment of the invention the processing and communication unit is powered by rechargeable battery connected to a charging system of the vehicle, such that the unit is battery-powered when the vehicle not operating such that the vehicle charger system is not working. Also in one embodiment the alert system is disabled when the vehicle is running and moving, and is enabled when the vehicle is not running and moving. Also in one embodiment the system further comprises a motion detector interfaced to the processor. Also in one embodiment the individual ones of the preprogrammed communications comprises a GPS location for the vehicle and a code uniquely related to a person responsible for the vehicle. And in one embodiment the system further comprises an Internet-connected server executing by a processor server software from an non-transitory medium , the Internet-connected server incorporating the particular Internet destination.

In one embodiment of the invention the Internet-connected server, executing the server software, stores telephone numbers associated with the unique codes indicating the vehicle or person, and, upon receiving an alert communication initiates a telephone call to the person associated with the code, the telephone call providing information about the alert. Also in one embodiment the telephone call indicates an alert seriousness level to the person. Also in one embodiment, upon initiating the telephone call, the server starts a timer having a time period, and in the event the person does not answer or call back during the time period, the server initiates an alert to one or more emergency services either preprogrammed or determined by stored information related to the GPS location of the vehicle. Also in one embodiment the server determines available emergency services are too remote from the GPS location, and determines and alerts a business or individual determined to be closer to the GPS location. In one embodiment the server, receiving an answer or a call back from the individual associated with the code in an alert message during the time period, cancels the alert. And in one embodiment the server continues to monitor messages from the vehicle, and if sensor conditions initiating an alert continue to indicate a dangerous situation, the server indicates new calls to the responsible individual, or in time to emergency services.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Fig. 1 is an architectural view of a communications network supporting a mobile alert system in a vehicle according to an embodiment of the present invention. Fig. 2 is a front elevation view of the vehicle of Fig. 1 with network support and a version of the mobile alert system of Fig. 1 embedded therein.

Fig. 3 a diagram of a web interface for registering the mobile alert system of Figs. 1 and 2 with an alert management and forwarding service entity according to an embodiment of the present invention.

Fig. 4 is a process flow chart depicting general steps for managing an alert triggered by system sensors of the mobile alert system of Figs. 1 and 2.

Fig. 5 is an architectural overview of a communications network over which an alert progressing to an emergency may be managed according to an embodiment of the present invention.

Fig. 6 is a process flow chart depicting more granular steps for registering the mobile alert system and prioritizing sensor devices according to an embodiment of the invention.

Fig. 7 is a process flow chart depicting steps for determining an alert state from collected sensor data and for managing the alert to resolution.

Fig. 8 is a process flow chart depicting more granular steps for handling an alert from the mobile alert system of Figs. 1 and 2.

DETAILED DESCRIPTION OF THE INVENTION

In various embodiments described in enabling detail herein, the inventor provides a mobile safety alert system for vehicles. The inventors provide a unique system that leverages hardware and software technology in and capable of being coupled to a vehicle to provide ways that safety of especially children, pets, and some adults may be best protected relative to behavior of a responsible adult. The present invention is described in enabling detail using the following examples, which may describe more than one relevant embodiment falling within the scope of the present invention.

Fig. 1 is an architectural view of a communications network 100 supporting a mobile alert system in a vehicle according to an embodiment of the present invention. Communications network 100 includes a mobile cellular network 102. Mobile network 102 may be accessed by a unique mobile alert system integrated within the electrical system of a vehicle such as vehicle 112 depicted herein. Vehicle 112 is depicted including a mobile device 113 carried in the vehicle by an adult that may be responsible for the vehicle, such as the vehicle owner. Device 113 may be a cellular telephone, a personal digital assistant, a pad device, or another sort of mobile communication device. Device 113 may connect to mobile network 102 for services.

In one implementation, vehicle 112 includes an on-board diagnostic system (OBD), which typically includes a micro controller and firmware or software for enabling connection of an external diagnostic system to diagnose any issues with vehicle systems, and connection for reporting vehicle status and data. An OBD system such as system 114 includes at least one OBD connector or plug not illustrated enabling connection by an external system. In one implementation the mobile alert system of the invention may connect to an OBD system such as system 114 for obtaining vehicle systems data.

Vehicle 112 includes a modular hardware unit 118, hereinafter termed mobile alert system 118. Mobile alert system 118 may include a micro controller, a rechargeable battery and a communications module such as a SIM module (not illustrated in Fig. 1). System 118 may be integrated wired or wirelessly to OBD system 114 in one

implementation. System 118 may also be interconnected to the vehicle charging system such that a rechargeable battery in system 118 may be charged during vehicle operation. Mobile alert system 118 is also referred to as CAPS system by the inventor, the acronym CAPS standing for Children Adult and Pet Safety.

Alert system 118 in one embodiment hosts a software application (SW) 115. SW 115 may execute when system 118 is powered on and may receive and process data from any sensors that may be connected thereto. Alert system 118 may include or have electronic or wireless connection to one or more sensors (not illustrated) for detecting presence of a child, pet or possibly compromised adult by virtue of processing single or a combination of sensor readings in one implementation of the invention. A compromised adult refers in this specification at least to an adult that is elderly, disabled, a patient, or otherwise unable, without assistance, to exit a vehicle.

SW 118 includes data processing and state determination capabilities, state referring to the state of the vehicle relative to internal temperature, internal atmosphere composition, and whether or not there are lifeforms in the vehicle such as a child or children, one or more pets, or one or more compromised adults. Communication components of system 118 (not detailed in Fig. 1) are capable of connecting to and sending at least text messages over mobile network 102 to one or more than one known destination number.

Mobile network 102 includes apparatus such as tower 117 and or satellites for carrying wireless communications and supports roaming for mobile coverage. Mobile network 102 may be a third generation or fourth generation (3G,4G) network. Network 102 includes a gateway 110 that is connected to an Internet network 101 through a network backbone 105. Backbone 105 represents all of the lines equipment and access points that make up the Internet network as a whole including connected sub-networks. Mobile network 102 includes a gateway 116 having connection to a telephony switch 119 located in the well known publicly-switched telephone network (PSTN) 103. PSTN 103 also has connection to Internet 101 via a gateway 106.

Internet backbone 105 supports an Internet server 120 hosted by a service provider that may forward alerts of communications network 100 to known destination numbers. The forwarding service works in concert with mobile system 118 to forward any alerts sent thereto to a client that is the responsible authority over the vehicle, such as a vehicle owner for example. The forwarding service is enabled by SW 126 executing on server 120. SW 126 includes an ability to parse alert messages, manage database entries (registered alerts), and to make contact with various third parties such as police, fire, medical, and other authorities that might respond to an emergency that has stemmed from a non-response to an alert notification. Server 126 includes a data repository 125, which may be a customer information system (CIS) in one implementation, documenting client whom are registered for alert forwarding services. SW 126 may include a web page suitable for fixed and mobile Internet-capable devices that may enable users who have a mobile alert system in their vehicle to become clients of the service and register for services. Registration information may be stored in repository 125 and may include client information and additional family information of the client (other vehicle drivers, kids, pets, etc.). Registration information may include vehicle information such as make, model, year, color, and general condition for use in emergency contact if required. Registration information also includes in one embodiment a unique mobile alert system identification number so that the vehicle system may be directly associated with a client. Registration may also require the client to provide at least one alert notification phone number (typically a cell phone) so that a destination number is available at server 120 to forward alerts. In one implementation a client may furnish more than one number in a perhaps prioritized notification list.

Mobile alert system 118 may draw power in one embodiment from a charged lithium ion battery when vehicle 112 is not running. When vehicle 112 is running, the system may typically be in sleep mode, among other possible modes of operation, and charging back to a full charge state. Mobile alert system 118 may operate solely on the battery for a period of time for as much, in one embodiment, as 24 hours. Opening the vehicle and starting the engine may function to put system 118 into a sleep mode or to a more low power mode while the car is being driven. In one implementation mobile alert system 118 may be connected to and may periodically receive data from any of the onboard vehicle systems covered by the CPU of OBD 114. In one implementation mobile alert system 118 is modular and may be dismounted and unplugged from a vehicles electrical charging system. In this implementation the system might be charged externally and remounted and plugged into the vehicle, or in some instances

reprogrammed an applied to a different vehicle..

In general use of the invention mobile alert system 118 may become active when a client has parked and turned off vehicle 112. Activation may be automatic on the engine being turned off, or may require manual activation in some cases. The mobile alert system may initialize a number of coupled sensors to collectively gather information from inside the vehicle such as temperature, atmospheric conditions including the presence of carbon dioxide (C02), and the presence of one or more lifeforms inside the vehicle. Certain combinations of sensor results may be preprogrammed to equate to a hazardous or dangerous state, at which time an alert may be generated describing the current state in the vehicle, and the alert, such as a pre-programmed text message, may be sent to server 120 on Internet backbone 105 through gateway 110. The inventor prefers sending text messages over communications network 100 due to light (digital content) and more reliable arrival over the network than heavier forms of media. However, in robust network areas heavier media such as live voice telephony might be employed for certain types of alert where emergency action may be required.

The communication module in system 118 in one embodiment generates and sends a text message (Alert) to server 120 when sensors connected to the mobile alert system have reported data for an active period that at least in combination shows, upon analysis of SW 115, that a critical or dangerous state is occurring within vehicle 112. In one implementation system 118 may also push a message or signal wirelessly to such as an electronic remotely-operable keypad having a battery and a wireless receiver associated with the vehicle for remote operation.

Server 120 with the aid of SW 126 receives an alert, for example from system 118 in vehicle 112. SW 126 instructs a server look up of specific information in the alert message such as the unique ID number of the system, the list of sensors involved, and an alert type and or level. An alert is based on intelligence from the system as gathered from the sensors that a child, pet, or adult that may be disabled or elderly has been left in the vehicle or, in some cases, of children or an elderly or compromised adult has somehow entered the vehicle without attendance from a responsible adult (client of server 120), in most cases the vehicle owner.

When server 120 receives an alert in one embodiment it creates an alert entry in a database such as in connected repository 125. The alert entry may include but is not limited to descriptive vehicle information and license number information, mobile alert system ID number, client name, and perhaps other names of persons closely associated with the vehicle such as other drivers in a family, etc. The alert entry may contain a list of the active sensors and their last readings. In one implementation the alert entry may also contain an alert level such as low danger, medium danger, or high danger.

Server 120 aided by SW 126 may forward the received alert to a person responsible for the vehicle. The server may look up a destination number in routing based on the ID number of the reporting CAPS system. Once the number of the responsible adult is found the message may be sent from server 120 to a client operating the communications device hosting the number, such as device 113. In this case device 113 may be in the possession of the client who, according to sensor analysis has left the vehicle. Server 120 records time and may begin a small time window starting on "send" and expiring after a set period. The receiving client must respond within the allotted time period to prevent escalation of the alert state into an emergency state. In one implementation the timed period is approximately 30 seconds but may be more or less depending upon circumstances of the alert.

When server 120 forwards an active alert to a client it generates in one embodiment a random message identification code that the client must include in a response to the forwarded message. Active state for an alert means that the alert entry in the database is active and waiting for a response from the client within the given amount of time. Server 120 aided by SW 126 may deactivate an alert entry if the client responds to a forwarded alert message, and may then address the situation uncovered by the sensors of the mobile alert system. The alert may be deactivated, in one implementation, if some event changes the facts on the ground before the client has responded to a forwarded alert. A state change may be reported by the system that overrides the previous alert sent by the system, such as the client has returned to the vehicle and started the engine putting the mobile alert system into a sleep or charging mode and causing the system to report that state to the server before going offline.

The client is generally required to respond to a forwarded alert within the predisposed time frame in order to prevent server 120 from contacting one or more than one emergency number supplied by the client or otherwise obtained by the server for the local area of the vehicle. If the client fails to respond to a forwarded alert within the time frame to respond (TTR) then the server will report the unfolding emergency.

Determination of a critical situation requiring an alert is made on the mobile alert system as a result of ongoing sensor analysis.

One with skill in the art will realize that a most dangerous period is when the client is away from the vehicle. Therefore the default operating period for the mobile alert system may be activated whenever the vehicle is turned off and the client leaves the vehicle. However this is not a rigid limitation of the current invention. In one embodiment the mobile alert system may detect levels of carbon monoxide while the vehicle is running or idling. In one implementation a client may be able to activate the mobile alert system by phone in certain situations like after a carjacking that may have resulted in a child or pet left in the vehicle after it was commandeered. The vehicle may then be tracked using GPS tracking techniques.

Fig. 2 is a front elevation view of vehicle 112 of Fig. 1 with network support and a version of the mobile alert system of Fig. 1 integrated therein. Vehicle 112 is depicted herein with a portion removed for clarity. Mobile alert system 118 has a rechargeable battery such as a lithium ion battery 205. Battery 205 may have a charging connection to the vehicle charging system and may be charged fully while the vehicle is running. In this mode the mobile alert system may or may not be used while charging. In this implementation system 118 includes a micro controller with memory that may host S W 115.

A communications module 207 in one embodiment generates alerts in the form of text messages to server 120 through mobile network 102 whenever a particular sensor data analysis uncovers a potentially critical or dangerous situation. In one

implementation, communications module 207 is a SIM908 component. Communications module 207 is capable of accessing a global system for mobile communications (GSM) network with a general packet radio service (GPRS) enabling packet-based services with a continuous Internet connection. Module 207 may access the network to place a call, send a text message, and use Internet through at least a 3G network. Module 207 may be operated in a voltage range of 3.0V to 4.8V and may communicate through a serial peripheral interface (SPI) which controller 206 may provide. SIM908 module 207 also works with any SIM cards from major service providers such as AT&T™.

In one implementation mobile alert system 118 has electronic connection to a vehicle wiring hub 213 in a fashion that integrates the unit to the vehicle charging system. Certain actions taken in the vehicle during operation may trigger on and off states, sleep or awake states, or other actions from the mobile alert system. For example, turning the vehicle on and then driving may serve to place the mobile alert system in a non-active charging mode. Parking and turning off the vehicle may place the mobile alert system in active mode.

In one implementation capacitive sensors such as sensors 208 are provided and disposed within the cushion portion and back portion of seats 201 and 202 including the driver seat. The sensors may be a model or version of MPR121 peripheral sensors from Freescale™. An MPR121 detects presence by measuring capacitance change between the probes it provides and a detected object. Since living beings function as electrical conductors, MPR121 is fully capable of detecting human presence. The sensors work with 3.3V, consumes very little power as it only draws 29μΑ on average, and lastly, communicates through I2C protocol which controller 206 is capable of using. In this implementation there is at least one capacitive sensor for each seat in vehicle. This implementation depicts a sensor in each seat back portion as well, although this is not required in order to practice the invention. Broken lines depict wired connections between the sensors and micro controller 206. In some embodiments the sensors may communicate by a near-field wireless system or BlueTooth™

Vehicle 112 is shown with optionally a child car seat 203. Child seat 203 may be adapted to practice the invention by making it a peripheral device that includes sensors that may be connected to micro controller 206. For example, capacitive sensors 215 may be provided in the seat and back portion of seat 203 for detecting a child in the seat. This may not be required to practice the invention, as a stock child seat with a child seated within may be detected using the sensors in the main vehicle seats provided the under portion of the child seat is conductive. In some embodiments the child seat may have an electrical connector that may connect to a matching connector to connect the seat electrically to the mobile alert system and thereby incorporate the sensors in the child seat into the list of active sensors available to mobile alert system 118. In a further variation buckles or snap components of the straps used to secure the child into seat 203 may include capacitive sensors that report if a strap is or is not closed-connected. In still a further variation of the implementation a sensor 208 may also be added to the floor area of a vehicle trunk 209 in order to detect if a person is in the trunk of the car.

In one embodiment a C02 sensor device 211 is provided to mobile alert system 118 to monitor levels of carbon dioxide within the vehicle space to help confirm that a person or a pet is still in the vehicle during an active sensing period. The C02 sensor type used in this implementation may be a K-30 sensor from C02Meter™.com. Sensor 211 includes a microcontroller that may drive an algorithm for refining accuracy of the sensor output during operation so it may be operated with very low or little maintenance. Sensor 211 detects any dangerous rise in C02 within vehicle 112, typically while it is parked or stationary. If a rise in current C02 breaches a predetermined threshold then it is highly likely a person or pet is inside the vehicle.

In this implementation, C02 sensor 211 uses a non-dispersive infrared sensor to measure the C02 in the air trapped in the vehicle interior. The sensor operates by beaming an infrared light through a chamber of inert gas toward an infrared sensor. C02 absorbs infrared light, therefore the infrared sensor detects attenuation of the infrared light through the gas chamber to determine the concentrations of C02 in the air within the vehicle. Sensor 211 is able to detect C02 from 0 to about 10,000 parts per million (PPM). Sensor 211 includes both a digital output (12C) and an analog output (UART). A broken line depicts connection of sensor 211 to mobile alert system controller 206. In one implementation sensors may be widely distributed within the vehicle while in another implementation they may be wholly or partially co-located on a panel or in a special enclosure without departing from the spirit and scope of the present invention.

In this implementation a temperature or heat sensor 210 capable of measuring ambient temperature is provided within vehicle 112 and connected to controller 206 of mobile alert system 118. In this implementation the temperature sensor 210 is a

DS18B20 temperature sensor. Other temperature sensors may be substituted without departing from the spirit and scope of the present invention.

Mobile alert system 118 includes in one embodiment a motion detector 214.

Motion detector 214 may be a Grid-EYE™ device known to the inventors. Motion sensor 214 in this embodiment uses an 8x8 array of thermophile transducers which can detect the quantity of an infrared signal. A thermistor is available on motion detector 214 for measuring temperature but may be less accurate than temperature sensor 210. Motion detector 214 draws 3.3 V or 5V in a variation of the device. It consumes 4.5 mA when awake and only 2mA when asleep. Motion detector 214 may be toggled from normal mode to sleep mode.

All of the sensors distributed in the vehicle may be wired to a hub device that connects to micro controller 206, or each sensor may use a dedicated line. In one implementation sensors that are adapted for wireless communications may be used and may connect to system 118 wirelessly. The use of more than a single sensor to detect the presence of a person or a pet within the vehicle provides an elevated level of accuracy with one sensor type validating or at least confirming the reading of another sensor type. For example, if a child seat capacitive sensor detects the presence of a child, elevated C02 may confirm or at least reassure the result. SW 115 may be programmed to observe specific sensor data thresholds for capacitance, motion, and temperature where one or a combination of the data thresholds must be breached before an alert may be sent out.

Communications module 207 may in one implementation generate and send a text alert message to server 120 through gateway 110. Server 120 aided by SW 126 receives the message, validates the ID of the mobile alert system and creates an active alert entry. Server 120 starts a time window of a predisposed duration and immediately forwards the alert to an associated client (113) number, the forwarded message containing a randomly generated code that the client must include in a response to the alert. Moreover the client must respond within the predisposed time window starting from the time the alert entry is stored or at least from the time the client is forwarded the alert message.

Assuming no response from the client within the predisposed time to respond (TTR), server 120 may make contact using text, voice over Internet (VoIP), or live telephony contact to an emergency response service such as a police emergency dispatch service 216. In one implementation an emergency response to an alert by the server may involve multiple contacts each to a different service such as police, fire, and medical. In one implementation a TTR is approximately 30 seconds. In one implementation different time windows may be observed for different emergency levels. For example, if a pet is left behind in the vehicle but the temperature is not a factor, the TTR may be relaxed somewhat. It is important to note herein that temperature rise and temperature lowering may be sensed and used as criteria for an emergency.

In one implementation GPS tracking of the vehicle may provide server 120 with GPS coordinates of the vehicle and those coordinates may be mapped or otherwise used to determine at the server which emergency response locations to contact. A GPS apparatus may be a part of system 118 to provide for such service when no GPS is available in the vehicle otherwise. Such contact may include all of the pertinent information about the vehicle, knowledge of who may be in the vehicle whether human or pet, and the location of the vehicle. In a variation to this implementation, server 120 may listen or wait for resolution of an emergency after it was reported by the server before ceasing contact attempts to emergency services or other local contact locations where help may be available. For example, if GPS has the vehicle in a gas station parking lot and the client is sick in the bathroom with a child or pet in the car and an emergency is reported but the client does not respond, the server may attempt to contact the gas station attendant and inform him or her of the developing emergency situation.

Fig. 3 is an elevation view of an interactive web interface 301 for registering the mobile alert system of Figs. 1 and 2 with an alert management and forwarding service entity according to an embodiment of the present invention. The mobile alert system of the invention is integrated with a web-based forwarding service as previously discussed. A registering process may be carried out by a client using an internet-capable device such as from mobile phone 113. After providing typical registration particulars such as name, address, email, perhaps financial information, and mobile number, interface 301 asks a client for one or more alert numbers to call if an alert is received from the system. The client may type in or insert the numbers into a text entry box 302 presented on interface 301. In one implementation a primary alert number may be the mobile number of the primary driver of the car. If there is more than one frequent driver of the vehicle, the mobile numbers of other drivers may also be added to a list of alert numbers.

In one implementation a client may also provide one or more emergency response numbers into field 302. Any numbers provided to the service may be validated before acceptance of the numbers. In one implementation, the service has access to a database of emergency response locations having contact numbers and location data that may be used to infer locality to an incident. In this implementation, the client is not responsible for providing any emergency contact information. GPS tracking of the vehicle by the communications module in the vehicle may provide location data with every alert the system send out.

In one implementation, a client may determine or at least configure priorities and inclusion of the sensors that will be used to detect presence of a child, pet, or

compromised adult in the vehicle. In one implementation the sensors are stock and activated for use by default wherein the client may not tamper with them. In one implementation a mobile alert system sensor array may require calibration and some testing before becoming active in a first period of operation. In this implementation interface 301 presents a checklist of sensors including a proximity (capacitive sensor), Infrared sensor (motion), C02 sensor, and temperature sensor. All of these may be checked by default. There may be additional sensors added to the configuration of sensors without departing from the spirit and scope of the present invention. In one implementation sound may be detected with a microphone. In the same or in another implementation, video may be recorded. However in a preferred implementation only low-power-consuming sensors are deployed to maximize battery life for other operations like communications. Once a client has selected sensors from list 301, he or she may select an activation option 302 to activate the service for the registered mobile alert system. A reset button on the hardware case of the mobile alert system may require activation to "sync" changes made to configuration settings with the database of server 120.

Fig. 4 is a process flow chart 400 depicting general steps for managing an alert triggered by system sensors of the mobile alert system of Figs. 1 and 2. At step 401 the mobile alert system such as system 118 of Fig. 1 collects data from one or more peripheral sensors. In one implementation the system automatically boots whenever the client stops the host vehicle and turns off the engine. At step 402, the mobile alert system aided by SW makes a determination whether or not the collected data indicates an alert situation, which may be generally defined as a critical situation. The system may parse and analyze the sensor data in periodic operations. Sensor data that is benign may be immediately purged from the system in one implementation.

If at step 402 the mobile alert system determines that there is no critical situation the process may loop back to step 401 until a situation may be identified. If the mobile alert system determines at step 402 that a critical situation has been identified, the communications module of the mobile alert system generates a text message alert addressed to an Internet server that may forward the alert to a responsible client associated with the system host vehicle. The message may include at least the identification number of the mobile alert system, and identification of the sensors and readings that preceded the alert. In one implementation every alert message carries identical weight from the perspective of the Internet forwarding service. More particularly every received alert results automatically in a forwarded alert notification to the associated client number or numbers in case of more than one client.

At step 404 the mobile alert system sends the generated message to the server. The server parses the message for the device ID number at step 405 and looks it up in a database. In one implementation the server may parse out an alert level from two or more alert type or level possibilities. However this is not required to practice the invention. At step 406, the server creates an alert entry in the database and forwards the alert message as a notification text alert to at least one client-provided mobile number. Also in step 406 the server may include a randomly generated code inserted into or otherwise associated with the message that is returned to the server in any reply to the notification alert. The server may also timestamp the alert entry and start a time period quantifying a time to respond (TTR) to the forwarded alert notification in step 406.

At step 407 the server determines whether or not there is a response to the forwarded alert notification from the associated client or clients that were targets of alert forwarding. If the server determines that a response was received by the associated client within the TTR set for the database entry at step 407, the server may update the database and deactivate the alert entry at step 410. In this case the process may end at step 411. The alert entry may not be deleted however for the purpose of record keeping such as maintaining a log of the activity that may be made available to clients of the service. If the server determines at step 407 that no response was received meaning that the TTR expired for the alert entry, the process moves to step 408 where the server may contact third-party entities such as a first responder unit or organization and report the unfolding emergency.

In one implementation, the server may determine at step 409 whether an initial reporting of an emergency was successfully registered and that responders are headed to the scene. For example, making one report at one responder organization and reporting to others as well may be accomplished until it is recognized that the issue is resolved or at least under management by first responders. If the server determines that the reporting of the unfolding emergency was successful at step 409 the process may resolve to step 410 where the entry may be deactivated and may end at step 411 for that particular interaction.

Fig. 5 is an architectural overview of a communications network 500 over which an alert progressing to an emergency is managed according to an embodiment of the present invention. Network 500 includes Internet 101 and mobile network 102. Vehicle 112 includes communications module 207 capable of bi-directional communication with server 120 through gateway 110. This is illustrated also by broken arrows indicating communication in both directions.

Communications module 207 may also include a global positioning satellite (GPS) receiver and may subscribe to GPS tracking service offered through a GPS service provider such as a GPS server 502 having connection to a data repository 503 containing GPS location data in a GPS network 501. GPS network simply refers to a computer access point (server 502) that receives GPS data results directly or indirectly through another computing device from one or more of the known GPS satellites. A bidirectional broken arrow illustrates communication between communications module 207 of the mobile alert system of Fig. 1 and server 502 through gateway 110.

Server 120 with the aid of SW 126 may obtain the GPS location of vehicle 112 at such time when an alert is received from communications module 207. When the mobile alert system is booted or otherwise made active from sleep mode, it may record its current GPS location coordinates and include the data in any alert message sent to server 120. In this way should an alert escalate into an emergency that must be managed, the server has exact coordinates of vehicle 112.

The communications network includes an emergency response network 504. Emergency response network 504 includes a gateway 505 to Internet backbone 105 and to mobile network 110. In case of an alert with an expired TTR, server 120 may make telephony contact via a telephony application and dialer (not illustrated) but assumed present as components of SW 126 to one or more entities in emergency response network 504 such as fire 508, police 507, and medical 506 emergency services. The GPS location of vehicle 112 may, in one implementation, aid SW 126 in looking up appropriate emergency numbers closest to the last GPS location of the vehicle. In this example, server 120 may contact any one, a combination of or all of emergency response entities fire 508, police 507, and medical service 506 through gateway 110 as illustrated by the directional arrow from gateway 110 to gateway 505. In another example

communications may go through gateway 505. In one implementation communication may be bi-directional between emergency services and server 120 through a telephony application with interactive voice or touch- tone capabilities or via live operators or dispatch personnel. In this implementation server 120 may obtain response data from emergency response network 504 relative to success of reporting and resolution of the issue. Server 120 may add such information to an alert entry that is otherwise deactivated but retained for records.

In one implementation, GPS data of vehicle 112 may help server 120 to look up contact numbers of local destinations at the same or very near the vehicle. A local network 509 generally represents communications destination points very close or near the same GPS coordinates as the vehicle. Network 509 has a local gateway 513 and includes a store 512, a gas station 511, and a neighbor 510. In this implementation server 120 may, if local services are not near enough for a quick response or for some other reason deemed appropriate, make telephony contact with local numbers of businesses or neighbors that are known to be at or near the GPS location of the vehicle. In one example, if a client has left a pet in vehicle 112 and is shopping in store 512, but left his mobile in the vehicle, server 120 may make contact with a telephone number of the store after GPS data shows vehicle in the store parking lot. In another example, a child might have gotten into vehicle 112 sometime after it was parked and may be locked inside. GPS data indicating the vehicle is at the client home may prompt the server to contact one or all of the immediate neighbors of the client to attempt to report the unfolding emergency.

In the above described implementation, contacting local destinations near to the GPS location of vehicle 112 may be an option when professional services are far off, in bad weather situations, if a professional service did not respond or was not available, etc. GPS tracking of vehicle 112 is not required to practice the present invention but may add significant advantage in time saved to locate the vehicle after an emergency situation has developed. In one implementation where emergency numbers are determined on the fly based on GPS, an algorithm for prioritizing a list of numbers to attempt to dial may be provided where the closest number relative to the GPS location of vehicle 112 is dialed first and then the next closest number, etc. Other criteria may also be observed in prioritizing emergency numbers such as professional services or volunteer services. In one embodiment server 120 may send text messages to local emergency entities in place of telephone calls.

Fig. 6 is a process flow chart 600 depicting more granular steps for registering the mobile alert system and prioritizing sensor devices according to an embodiment of the invention. At step 601 a user (client) accesses a website to register a mobile alert system installed in the client vehicle. At step 602 the user may provide, in addition to name and other pertinent information, a valid email address, a device ID, and a telephone number into the appropriate text entry fields to notify in a case of emergency. At step 603, the website may validate the user and create a database entry for the user to store data relative to the user.

The server may validate a user in step 603 by responding to a given email address to make sure it is the client's address, texting to the number given thereby validating the mobile number of the client, and by checking the device ID against a database containing the ID number of sold units. A list of sensors may also be entered into the database in accordance with the device ID. Server 120 prompts the user via web interface to reset his or her device at step 605 to synchronize all of the data at the server and on the mobile alert system.

At step 605, the user now a client may activate a reset button on the mobile alert system to sync the data at both locations. The mobile alert system generates a text message containing the device identification (DID) number and at least a list of active sensors at step 606. At step 607 server 120 receives the text message and updates the database. At step 608 the server aided by SW 126 (Fig. 1) may determine whether or not the database entry is a first data sync for the client. If at step 608 the system determines that is is a first sync the sensor priorities are set to 0 in anticipation of the client configuring priorities of the sensors in the list of sensors. At step 612 the client may determine whether or not to configure sensor priorities. If the client does not determine to configure sensor priorities at step 612 the process may skip to stem 614 where an error message may be sent to the client.

If the client determines to configure sensor priorities at step 612 the priority for each sensor may be configured in step 613. In one implementation the server provides a default list of sensors and priorities and the client may review and make changes. In one implementation the client may not select or configure sensors used in the mobile alert system. In this exemplary process, the client may hit the reset button on the mobile alert system to sync the data with the server at step 615. The process may end at step 615.

At step 608 if the server determines it is not a first data sync then the server may look up the current list of active sensors and their configured priorities and returns the data to the mobile alert system. At step 611 the mobile alert system communications module or device receives the data from the server. The process may resolve again to step 612. If the client decides to change current priorities relative to the list of active sensors on the device the client will be required to reset the device to sync the data with the web server.

Fig. 7 is a process flow chart 700 depicting steps for determining an alert state from collected sensor data and for managing the alert to resolution. At step 701 the mobile alert system boots up. The mobile alert system may be manually booted or it may boot automatically based on a triggered action. In one implementation the mobile alert system may boot or wake up from a sleep mode when the client parks the vehicle and turns off the engine. This may be when the system is most useful.

The battery life of the mobile alert system may power the system with the engine off for up to 24 hours in one embodiment before the battery is depleted. In one implementation the system may be programmed to stay on for a specified period of time shorter than the estimated battery life after the engine in the vehicle is turned off. It might be critical to detect presence in the vehicle during a specified period of time after the vehicle is turned off and the client leaves the vehicle. It is also possible that a child may get into the vehicle some time after it is left parked and the sensing time has expired such as when the child is playing. Therefore, in one implementation after a specified sensing period expires, the system may go back into sleep mode or low power mode with sensors deactivated. The mobile alert system may be programmed to wake up if a door of the vehicle or the trunk lid of the vehicle is opened any time after the alert system has gone to sleep.

In one implementation the mobile alert system automatically boots in step 701 when a client turns off the engine of the vehicle. The sensors connected to the system may be activated at step 702. In one implementation the mobile alert system records the exact time that the system was booted and the sensors were activated at step 703. The amount of time that expires when a child or pet is left in a vehicle in hot weather is critical from the point of view of rescuing the child. The activated sensors may begin collecting data from inside the vehicle at step 704 and one or more algorithms may be called or executed in step 704 in order to analyze sensor data at step 705. At step 705 the sensor data may be analyzed in combination (of sensors) and results may be compared against certain data thresholds that when breached trigger an alert.

At step 706 the mobile alert system may determine whether or not an adult is present in the vehicle. In this example adult refers to the client. If the client is present in the vehicle the process may loop back to step 704 for collecting more sensor data. If the mobile alert system determines there no adult in the vehicle (client has left vehicle) the system may determine whether or not a child or pet is still in the vehicle at step 707. If the mobile alert system has not detected a presence of a child or pet in the vehicle at step 707, the process may resolve back to step 704 where more sensor data is collected for analysis. If the mobile alert system determines that there is a pet or child left in the vehicle at step 707, the process may move to step 708.

At step 708 when there is a child or pet detected in the vehicle the system may determine if a temperature threshold of the ambient temperature within the vehicle has breached a preset temperature threshold. If the mobile alert system determines no breech of a temperature threshold at step 708, the process may move back to step 704 for collecting more sensor data. A temperature threshold may be predetermined for hot weather and established as a triggering point for an alert. Moreover, a temperature threshold may also be predetermined for cold weather. The threshold point should not be a temperature that might cause critical events in the vehicle.

If the mobile alert system has determined that a temperature threshold has been breached at step 708 and there is a child or pet left in the vehicle as determined at step 707, the mobile alert system generates an alert message and sends the message in step 709 to an Internet server analogous to server 120 of Fig. 1. The server may record the data from the alert message received in a connected database and calculate any time lapsed since the alert system recorded the time at step 703. At step 712 the server may determine whether or not to deactivate the event before notification of authorities. For example, if a client returns to the vehicle before the server makes a determination to contact emergency authorities an alert entry in the database may be deactivated.

In the event that the alert is not deactivated at step 712, the web server generates a time sensitive alert message and sends it to the client. Time sensitive refers to a window of time set by the server from the beginning of the notification of the client to the time a client responds to the communication. Such a time window might be dynamically changed by the server depending upon the data it has received and parsed. For example, the time window may be shortened considering time already elapsed since the mobile alert system began tracking the time. In one implementation, the default time between notification and client response is approximately 30 seconds.

At step 714 the system may determine whether a notified client has responded within the preset time limit or not. In one implementation the alert notification is a text message including the nature of the alert, alert data, and list of sensors involved in determining the critical nature of the alert. The server may generate and include a random code or number that must be present in the client reply in order to verify the response was from the notified client's device. If the system determines that the client has responded within the time frame imposed for response the process may move to step 712 where the system determines whether to deactivate the event.

If the client has responded within the time limit imposed it may not guarantee the alert will be deactivated. For example, the client may respond but GPS of the client may show a far distance from the vehicle and with time being calculated the server might still alert one or more third parties of the emergency. The process may move to step 710 where the alert may be updated and deactivated. The alert entry may be archived in the database for the purpose of record keeping and later review. If the client has not responded to the notification within the allotted time frame at step 714, the server may contact third party entities and report the unfolding emergency and the exact location of the vehicle at step 715. Third parties may include emergency response professionals such as medical, fire and police services. Third parties may also include persons available at locations very near the vehicle such as a store, gas station, neighbor, etc.

Fig. 8 is a process flow chart 800 depicting more granular steps for handling an alert from the mobile alert system of Figs. 1 and 2. In this more detailed process, it is assumed that the client has responded in a timely manner to an alert message and the alert is deactivated. At step 801 the communications component of the mobile alert system sends an alert message to the server the message including at least the device or hardware ID and a list of sensors triggering the alert. A step 802, the server logs (records) the alert creating an alert entry in a database and generates a text alert or notification of an alert to a client-supplied number, which may typically be the client's communications device like a cell phone, a smart phone, an iPAD, or other device supporting network

communications and send and receipt of at least text-based messages. In one

implementation the server generates a fresh message to the client. In another

implementation the server appends the received text and forwards the appended version to the client.

At step 803 the server sends the alert notification message and a randomly generated code or number to the client device. In one implementation the random code is also temporarily cached or permanently recorded in association with the client account. The server may impose a TTR on the alert notification that may be displayed in real time on the client's communications device. In this example, the server has received a timely message from the client with the generated code embedded into the message reply or otherwise associated or attached to the message. The server leverages the code in the received message to look up the client account that the code has been associated with and validates the code is from the client. If the code is correct the server may deactivate the alert entry in the database. However, in the event a TTR does expire meaning that the client either did not get the text alert or that the client just did not respond within the allotted time window, the server may contact third party entities including authorities.

In one implementation of the mobile alert system, the system may be designed to boot up whenever the car has stopped moving for a certain period of time but is still running. In this way the sensor devices may be activated before the client steps out of the vehicle for faster detection time. As soon as the system boots and detects life within the vehicle it may raise some connected audible alarm that a client just leaving the vehicle might notice, such as a horn honking, lights flashing, or other quick audible or visual warnings that the client left a pet or child in the car. This implementation may be because of a very high ambient temperature or a very low ambient temperature occurring at the time of operation. Horn honking and flashing of emergency and headlights may also alert any passersby of the unfolding emergency.

If the temperature is 110 degrees for example, and the client leaves a pet in the car there would not be much time to rescue the animal. Therefore, there may be a special warning mode that immediately warns the client in multiple ways, such as just after the client steps out of the vehicle. For example, if the sensors detect presence of a pet or person left behind almost immediately or seconds after the client has left and is perhaps still near the vehicle, a warning may be issued to the client. In a variation of this implementation the client may have a remote activate able FOB key that may vibrate or make an unpleasant sound if the client has left a child or pet in a vehicle that is out in an extremely dangerous environment.

In one implementation, a client may access the mobile alert system directly from a cellular phone running a device access application using short range wireless

communication to communicate with the system. In another implementation the mobile alert system of the invention includes a USB port that enables a client or service technician access to the hardware and software of the system. In one implementation a client may add and configure additional sensors to the system including audio, gas, visual and other types of sensors.

Some automobile OBD systems are rather sophisticated, and include

computerized ability to perform certain functions on remote command. It is well-known, for example, that the On-Star™ system enables a client who has locked his or her keys in a vehicle, to call an On-Star™ operator by phone, who may then command the computerized system in the car to unlock a door of the vehicle. In one embodiment of the invention, operable with automobiles that afford remote operation of vehicle functions, the server, detecting a set of circumstances indicating an alert situation, may command functions remotely to alleviate a dangerous situation. For example, sensing a pet or a person in the vehicle, and an unsafely high temperature, the server may remotely roll down one or more windows to attempt to cool the local environment and alleviate the situation. In a situation with a pet or person in a vehicle and unsafe low temperature, the server may command a heater to help alleviate the dangerous situation. There are many other possibilities.

It will be apparent to one with skill in the art that the mobile alert system of the invention may be provided using some or all of the mentioned features and components without departing from the spirit and scope of the present invention. It will also be apparent to the skilled artisan that the embodiments described above are specific examples of a single broader invention that may have greater scope than any of the singular descriptions taught. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.

It will also be apparent to the skilled person that the arrangement of elements and functionality for the invention is described in different embodiments in which each is exemplary of an implementation of the invention. These exemplary descriptions do not preclude other implementations and use cases not described in detail. The elements and functions may vary, as there are a variety of ways the hardware may be implemented and in which the software may be provided within the scope of the invention. The invention is limited only by the breadth of the claims below.