Patent Application
20120154145
The present disclosure relates generally to information handling systems (IHSs), and more particularly to a mobile IHS with an automated emergency service provider contact system.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Some IHSs are considered ‘portable’ or ‘mobile’ IHSs (e.g., phones, notebook computers, tablet computers, and a variety of other mobile/portable IHSs known in the art) because their size and weight allow their user to carry them around virtually anywhere. Such IHSs typically provide communication capabilities for their user, and in the case of, for example, phone IHSs, may allow a user to contact an emergency service provider (e.g., by calling an emergency service provider contact number) to request emergency services in the event the user it presented with an emergency. However, IHS users may find themselves in situations where they need emergency services but are unable to use the IHS to contact an emergency service provider. For example, an IHS user may be presented with an emergency that renders the user unconscious, paralyzed, or otherwise unable to operate the IHS to contact an emergency service provider.
Accordingly, it would be desirable to provide an improved emergency service provider contact system.
According to one embodiment, an emergency service provider contact system includes a portable chassis, a processor housed in the portable chassis, a storage housed in the portable chassis and coupled to the processor, a communications module housed in the portable chassis and coupled to the processor, at least one sensor housed in the portable chassis and coupled to the processor, a display housed in the portable chassis and coupled to the processor, and a non-transitory, computer-readable medium housed in the portable chassis and coupled to the processor. The non-transitory, computer-readable medium includes instructions that, when executed by the processor, cause the processor to monitor the at least one sensor and, in response to detecting an alert event through the at least one sensor, search the storage using the alert event to retrieve contact information for at least one emergency service provider that is associated with the alert event, and contact the emergency service provider through the communications module using the contact information.
For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an IHS may be a personal computer, a PDA, a consumer electronic device, a display device or monitor, a network server or storage device, a switch router or other network communication device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The IHS may include memory, one or more processing resources such as a central processing unit (CPU) or hardware or software control logic. Additional components of the IHS may include one or more storage devices, one or more communications ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The IHS may also include one or more buses operable to transmit communications between the various hardware components.
In one embodiment, IHS 100,
Referring now to
Referring now to
Referring now to
Referring now to
The method 500 then proceeds to block 506 where one or more alert events are defined. In an embodiment, an alert event is reading from one of the sensors 118 that exceeds a threshold reading and may indicate that the IHS (and its corresponding user) require emergency services. In such an embodiment, the IHS may prompt for (e.g., using the display 110, 206), or have predefined, one or more alert events that includes one or more respective threshold readings for the sensors 118, and each alert event may be stored in the storage 108. For example, an alert event may be defined that includes a threshold reading of a 10G force from an accelerometer (e.g., which may indicate a car accident.) In another example, an alert event may be defined that includes a threshold reading of a temperature exceeding 150 degrees Fahrenheit from a temperature sensor (e.g., which may indicate a fire.) In another example, an alert event may be defined that includes a threshold reading of a predetermined amount of a harmful chemical from a chemical sensor (e.g., which may indicate a chemical poisoning.) In another example, an alert event may be defined that includes a threshold reading of gunshot detected by a microphone within a predefined distance from the IHS. Furthermore, an alert event may be defined that includes a plurality of threshold readings on respective sensors 118. For example, an alert event may be defined that includes a threshold reading of a velocity of at least 35 miles per hour (e.g., from a GPS sensor), followed by a 10G force from an accelerometer (e.g., which may indicate a car accident.) In another example, an alert event may be defined that includes a threshold reading of a temperature increase of 50 degrees Fahrenheit from a temperature sensor in a time period of less than 1 minute (e.g., which may indicate a fire.) In another example, an alert event may be defined that includes a threshold reading of a temperature below a predetermined level (e.g., 30 degrees Fahrenheit) from a temperature sensor for more than a predetermined time period (e.g., 2 hours, which may indicate hypothermic conditions) In another example, an alert event may be defined that includes a threshold reading of a loss of GPS awareness from a GPS sensor followed by a threshold reading of a temperature above or below a predetermined level (e.g., 120 degrees Fahrenheit or 30 degrees Fahrenheit—i.e., extreme heat or cold) from a temperature sensor in a predetermined time period (e.g., 1 minute—i.e., suddenly.) While a plurality of alert events have been described above, such description is not meant to be limiting, and one of skill in the art will recognize how accelerometers, global positioning system (GPS) modules or other location sensing technologies, magnetometers, gyros (single and multi-axis), temperature sensors, electromagnetic sensors, skin conductivity sensors, compasses, chemical sensors, Geiger counters, proximity sensors, noise sensors (e.g., microphones), pressure sensors, humidity sensors, allergen sensors, air pollution sensors, subsonic and ultrasonic field sensors, light sensors, and/or a variety of other sensors known in the art, may be used to create alert events relying on threshold readings from one or more of those sensors that may indicate that a user of the IHS needs emergency services.
The method 500 then proceeds to block 508 where an emergency service provider and/or an emergency contact are associated with each alert event. Each alert event may be associated with one or more emergency service providers, and that association may be stored in the storage 108. For example, an alert event that indicates a fire may be associated with a fire department, an alert event that indicates a car accident may be associated with an emergency medical service, an alert event that indicates a gunshot may be associated with a police department, an alert event that indicates a user of the IHS is lost in the wilderness may be associated with a location specific emergency response service such as a search and rescue service, etc. Furthermore, any alert event may be associated with more than one emergency service provider (e.g., the alert event that indicates a fire may be associate with the fire department and an emergency medical service, the alert event that indicates a gunshot may be associate with the police department and an emergency medical service, etc.) Each alert event may also, or separately, be associated with one or more emergency contacts, and that association may be stored in the storage 108. For example, any of the alert events discussed above may also be associated with a spouse, relative, co-worker, etc. In another example, an alert event that indicates a high stress level in a user of the IHS may be associated with a spouse, relative, co-worker, etc. While a plurality of alert events/emergency service provider and/or emergency contact associations have been described above, such description is not meant to be limiting, and one of skill in the art will recognize that a variety of other associations may be made without departing from the scope of the present disclosure.
The method 500 then proceeds to block 510 where the emergency service provider contact system monitors for an alert event. In an embodiment, the emergency service provider contact system is enabled such that the event interpretation engine 406 may use the sensor communication engine to monitor readings from the one or more sensors 118. In an embodiment, the emergency service provider contact system may be disabled at any time if, for example, the user of the IHS determines that any current conditions may unwantedly trigger an alert event. The method 500 then proceeds to decision block 512 where it is determined whether an alert event has occurred. In an embodiment, the event interpretation engine 406 may retrieve the alert events stored in the storage 108 and compare readings from the one or more sensors 108 with the threshold readings that define the alert events. If no reading or combination of readings from any one or combination of the sensors 108 exceeds the threshold reading or combinations of readings that define an alert event, the method 500 returns to block 510 where the emergency service provider contact system continues to monitor for an alert event.
If a reading or combination of readings from any one or combination of the sensors 108 exceeds the threshold reading or combinations of readings that define an alert event, the method 500 proceeds to block 514 where an emergency service provider and/or emergency contact are determined to be associated with the alert event. However, prior to contacting the emergency service provider and/or emergency contact, the event interpretation engine may do an algorithmic analysis of other sensor readings to reduce ‘false positives’, or the contacting of emergency service providers and/or emergency contacts when there is no emergency. In an embodiment, the event interpretation engine 406 may use the sensor communication engine 404 or stored sensor readings to determine at least one secondary event from one or more of the sensors 118 and use that secondary event to corroborate the alert event. For example, if an alert event indicates that a car accident has occurred due to detecting a traveling velocity of 50 miles per hour followed by a 10G force, the event interpretation engine 406 may determine whether the stored sensor readings in the storage include a sound recording having a decibel level high enough to indicate a car collision. If the secondary event does not corroborate the alert event (i.e., there is no sound recording having the proper decibel level), the emergency service provider and/or emergency contact associated with that alert event are not contacted. However, if the secondary event corroborates the alert event (i.e., there is a sound recording having the proper decibel level), the emergency service provider and/or emergency contact are contacted. In an embodiment, the emergency service provider contact system may warn the user (e.g., using the display, an audio alert from the IHS, and/or a variety of other methods known in the art) that an emergency service provider and/or emergency contact is about to be contacted.
The event interpretation engine 406 may use the alert event determined to have occurred in decision block 512 to search the storage 108 for any emergency service providers and/or emergency contacts associated with that alert event and retrieve the emergency service provider information and/or emergency contact information for the associated emergency service providers and/or emergency contacts. The method 500 then proceeds to block 516 where one or more emergency service providers and/or emergency contacts are contacted. The event interpretation engine 406 uses the emergency service provider information and/or emergency contact information retrieved in block 514 in the method 500 and the network communication engine 410 to contact the emergency service providers and/or emergency contacts associated with the alert event determined to have occurred in decision block 512. In an embodiment, the emergency service providers and/or emergency contacts may be contacted through network communication engine 410 over the network 308 using methods known in the art (e.g., voice message using a phone number, text message using a phone number, email message using an email address, etc.) The message provided to the emergency service providers and/or emergency contacts may be a generic message (e.g., “user requests emergency services”) and may use location sensors to provide directions to the emergency service providers and/or emergency contacts (e.g., “user requests emergency services at 1234 Congress Avenue, Austin Tex. 78701”). Furthermore, the message provided to the emergency service providers and/or emergency contacts may include specifics from the sensor readings that resulted in the alert event (e.g., “user requests emergency services for a likely car accident detected due to a traveling velocity of 50 miles per hour followed by a 10G force”, or “user requests emergency services for possible hypothermia detected due to an exposure to a temperature of 5 degrees Fahrenheit for over 2 hours”. In an embodiment, the message provided to the emergency service providers and/or emergency contacts may include contact information for the user (e.g., a phone number.) In an embodiment, the emergency services provider contact system may request confirmation that emergency service provider and/or emergency contact are going to respond to the request for emergency service. In an embodiment, the emergency services provider contact system may contact the emergency service provider and/or emergency contact associated with the alert event determined to have occurred at decision block 512 periodically (e.g., every 20 minutes.)
The method then proceeds to block 518 where the emergency services provider contact system continues to monitor using the sensors 118. The event interpretation engine 406 may use the sensor communication engine 404 to use the one or more sensors to monitor and record all information being detected by the sensors 118. In an embodiment, information detected by the sensors before, during, and/or after the alert event is monitored, recorded, and saved in the storage 408. The method 520 then proceeds to block 520 where historical data is provided. In an embodiment, the IHS may be used by the emergency service provider(s) and/or the emergency contact(s) to retrieve any information detected by the sensors 118 and stored in the storage to help diagnose the users situation. Thus, an emergency service provider contact system is provided that allows an emergency service provider and/or emergency contact to be automatically contacted in the event a user of the system experiences an emergency that may not allow the user to contact help themselves.
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.
