GB2472787A

GB2472787A - A personalised notification system for safety purposes

Info

Publication number: GB2472787A
Application number: GB0914347A
Authority: GB
Inventors: Yuping Yang
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-08-17
Filing date: 2009-08-17
Publication date: 2011-02-23
Also published as: GB0914347D0

Abstract

A personalized notification system for safety purpose consists of a number of wireless detectors, such as carbon monoxide detectors, smoke detectors, heat rate detectors or blood pressure detectors. These send their outputs to a local computer. The system allows a user to specify his preference rules as to which people should be notified of an alarm situation, via which devices (communication means — mobile phone, email, voice mail, instant message etc.) which may depend on the time, day of week, and date. When an event occurs, the system performs a real-time reasoning based on the predefined user preferences and makes a decision on what actions should be taken appropriately. According to the reasoning result, a message is sent to different people. The system can be used in different scenarios where people want to be notified regardless of their location whenever a sensor detects a situation that needs their attention.

Description

I

A Personalised Notification System for Safety Purpose

DESCRIPTION

Technical Field

This invention relates to a system which can intelligently notify a user in the event that data detected by a sensor reaches the pre-defined threshold. User can define his preference rules specifying a message should be sent to which devices of which people at what circumstances. When triggered by an incoming event, the system makes a decision according to user preferences and a message is sent to the right people and right device.

Background

Many smoke or monoxide detectors can set off an alarm when the level of smoke or monoxide in a room reaches a certain level. This is very helpful when someone is in the building as the person can be alerted and appropriate actions can then be taken. However, in the case that no one is in the building or people in the building are in deep sleep in other rooms, setting off an alarm becomes little useful. People want to be notified via the devices they are currently using regardless of their location -they might be at work, in a gym, on a business trip, etc. In the case that they are in a place far away, they may want other people who are trustable and close to the building (e.g., parents, spouse, friends, neighbours) to be notified. If one is in deep sleep and cannot be waken up by the alarm, a notification message should be sent to other relevant people who can then take appropriate actions. The same idea also applies to patients wearing, for example, blood pressure monitor or heart rate monitor. In the event that the blood pressure/heart rate of a patient reaches a threshold, a message should be sent to the patient's GP, family members, etc. who may not be with the patient at that time. This could be life saving in some cases.

Summary

This invention overcomes the problem that people cannot get to know immediately that some building/someone related to them is in danger when they are not in the particular building or with the particular person. In addition, it allows one to specify whom he wants to be notified in the event that he or his property is in danger.

The increasing popularity of mobile devices means people could have access to different devices at different time. In the event that something or someone is in danger, for example, the smoke/monoxide level in a building or the blood pressure/heart rate of a patient reaches a pre-defined threshold, relevant people want to be notified promptly wherever they are and whatever devices they use. Currently, the most popular devices people use include mobile phones, computers and landline phones. Therefore, the designed system here aims at notifying people via those three types of devices. Different from any existing traditional notification systems, the system here provides users with a means for specifying their rule-based preferences, which form the basis for the system to take appropriate actions by inference, i.e. send a notification message to the right people and the right devices/endpoints.

The system here consists of four major parts in terms of functionalities: detector, processing application, user preference rules, and message sender.

BRIEF DESCRIPTION OF FIGURES

The following three accompanying figures illustrate the idea of this invention: Figure 1 provides an overview of the system.

Figure 2 gives an example of user preferences.

Figure 3 presents the data flow among major system components.

DETAILED DESCRIPTION

Scenario 1: Susan is pregnant and is wearing a Foetal Heart Rate (FHR) detector as the baby has been experiencing some suspicious symptoms. The threshold of the FHR has been set to a value suggested by Susan's GP. Susan has specified her own preference rules, which have been agreed by her GP, so that in the event that the FHR reaches the threshold, if it is within the working hours of her GP, a notification message will be sent to the GP's office phone as well as his working email address; if it is outside the working hours of her GP but between 6pm and 9pm, a message will be sent to the GP's home phone and his mobile phone; otherwise a message will be sent to the office phone of the 24-hour maternity emergency department. Whoever receives the message will contact Susan by, for example, calling her asking about her physical condition, and then decide to send an ambulance or not.

Scenario 2: Susan has a smoke detector installed in her house close to the kitchen. Susan has set her preference rules, so that if both she and her husband are at work and the smoke level in her house reaches the pre-defined threshold, a message should be sent to her mobile phone, her office phone, her husband's mobile phone and her neighbour's home landline respectively; if it is during night, a message should be sent to her parents' home landline and her home landline as she normally switches off all the mobile phones before sleeping; if she and her family members are on holiday and far away from home, a message should be sent to her friend's mobile phone, her friend's personal email address and her neighbour's home landline.

In the case that Susan's parents receive a message during night, they could try to make a phone call to Susan in case that everyone in the house is in deep sleep and thus no one hears the alarm. If no one picks up the phone, they could consider either contacting Susan's neighbour or calling 999.

Referring to Figure 1, a detector ii consists of a sensor, a microprocessor, an alarm and a wireless transmitter. The sensor is the actual detecting part. When the sensor output reaches a certain discrimination level, the microprocessor -a circuit part comprising a printed circuit board -produces a discrimination output.

The microprocessor then triggers the alarm and sends the output to the wireless transmitter. The wireless transmitter sends the data to a Wireless Receiver that is integrated with the computer 12 nearby. Possible wireless communication channels include WiFi, Bluetooth and ZigBee protocols. The computer is connected to the Internet and has a Processing Application running on it.

As shown in Figure 2, a Client Application 21 is provided, which allows user to specify his preferences in a facilitated way. It also allows user to define groups of people and groups of endpoints so that he can specify a message should be sent to a person/group at what circumstances. The Client Application may be a Web application or a standard GUI application allowing remote access (e.g., using Java Remote Method Invocation) and is separated from the Processing Application 22. It can run on any Java enabled mobile device. User can view or change his preferences locally or remotely via the Client Application once authenticated with the Processing Application.

A rule is of form Event-Condition-Action, which performs actions in response to events and is for the purpose of real-time reasoning. When the Processing Application 22 receives data originated from a detector, it is regarded as an event. For different events, different conditions and actions can be specified so that the events will be treated differently. Elements involved in the condition of a rule include date, day and time and those involved in the action of a rule include a person, an endpoint, a group of people and a group of endpoints.

Preference rules are stored in an XML file 23. User can specify multiple rules. For each rule, user can assign a priority. A rule with higher priority precedes a rule with lower priority. For example, a user has specified two rules for notifying him that the monoxide level in his house reaches the threshold -rule A says if the user is on a business trip, a message should be sent to his parents, and rule B says if it is working time, a message should be sent to his office phone and working email address. The user has assigned higher priority to rule A so that if the user is on a business trip and it is working time, a message will be sent to his parents instead of his office.

Figure 3 gives an example of user preference rules. James is a doctor who works in a general hospital from Tuesday to Thursday, and works in a private clinic on Friday and Saturday. So he has his holidays on Sunday and Monday. His working hours are normally from 9am to 5pm. He has planned to spend summer vacation from 01/08/2009 to 31/08/2009. The listed four preference rules show that his preferences may vary with time, dates and working places. James assigns priority 2 to Rule 4 and priority 1 to the rest three rules.

Since Rule 4 has higher priority, it precedes the other rules.

User can also have multiple XML files, e.g., one for the family as a whole and one for the housewife when she is the only one staying in the house for a relatively long period (e.g., half a year). Via the Client Application user can specify which XML file is active, i.e. which set of preferences should be considered when handling an event. This approach makes it convenient to switch among different sets of preferences.

At the time when the Processing Application 22 receives data from the Wireless Receiver, it creates a new thread that is dedicated to handling the data. A component called Data Flow Controller (DFC) 24 is created which forms the heart of the thread and manages the whole data flow. The DFC reads from the XML file storing user preferences 23, creates an instance of Rule Engine 25, and feeds the preference information into the Rule Engine. The Rule Engine gets the properties of the computer system clock including calendar date, day and time, use them as parameters, and deduces from preference rules which people and endpoints should be contacted taking into account rule's priority. This information is then passed to the DFC.

The DFC creates an instance of the Message Sender 26 and instructs it what message should be sent to which endpoints.

For each endpoint, the Message Sender creates a new thread which is dedicated to sending a message to that particular endpoint. This way, a message can be sent to different endpoints simultaneously which speeds up the way of sending a message to multiple endpoints and leads to higher efficiency.

The Message Sender categorizes endpoints into three types: email, mobile phone and landline. For each type of endpoints, a message is dealt in a different way.

To send a message to an email address, the Message Sender may use JavaMail API, a platform-independent and protocol-independent framework to build mail and messaging applications.

To send a message to a landline phone, the Message Sender may use Voicent Gateway -an open-standard based, advanced server software product that links telephones with computers, which can also covert text to speech so that the message will be transformed into a voice mail which can be received by any type of phone. This requires a voice modem 14 (shown in Figure 1) connected to the server computer.

To send a message to a mobile phone, either of the following two approaches can be used: 1) Connecting a GSM phone/modem to the COM port of the server computer; 2) Using service interfaces provided by a third-party SMS service provider. For the first approach, the Message Sender can use USMProLib, a Java library that provides a Java API for working with the SMS and EMS, or SMSL1b, a Java library which allows one to send/receive SMS messages via a compatible GSM modem or GSM phone 13 (shown in Figure 1), for sending messages to mobile phones. The second approach requires to sign a contract with a third-party SMS service provider, who will provide interfaces for sending/receiving messages. The Message Sender can invoke these interfaces for sending messages.

Unique to the system is the manner in which it can notify the right people via the right endpoints at the right time according to user preferences.

Claims

Claims A personalised notification system for safety purpose consisting of a set of wireless detectors (e.g., monoxide detector, smoke detector, heart rate detector, blood pressure detector) that detects, for example, certain level of monoxide in a house, and sends the detected data via a wireless receiver to a computer nearby; the computer receives the data, checks the preference rules pre-defined by the user, and takes actions accordingly so that a message is sent to the devices/end-points preferred by the user according to the current user context (e.g., time, day, date).
2. The personalised notification system of claim 1 in which any one of the said wireless detectors is an integrated unit of a sensor, a microcontroller, an alarm and a wireless transmitter.
3. The personalised notification system of claim 1 in which the said wireless receiver is integrated with the said computer and receives signals from the said wireless detectors.
4. The personalised notification system of claim 1 in which the said computer is connected to the public Internet.
5. The personalised notification system of claim 1 in which the said computer receives data via the wireless receiver and invokes a thread to retrieve the right set of user pre-defined preference rules from the storer.
6. The personalised notification system of claim 1 in which the said computer analyses the retrieved preference rules and decides what actions to take taking account of user context.
7. The personalised notification system of claim 1 in which the said computer invokes a thread for each of the devices/end-points specified in the preference rules and sends a message to it notifying the recipient, for example, that the monoxide level in the user's house reaches the threshold. The devices/end-points could be mobile phones, landline phones and email addresses of different people.
8. The personalised notification system of claim 2 in which the said sensor generates an electric indicator signal that is either digital or analog.
9. The personalised notification system of claim 2 in which the said sensor sends the indicator signal to the said microcontroller.
10. The persorialised notification system of claim 2 in which the said microcontroller processes the received sensor signal, and compares the indicator level with the pre-determined threshold level. If the pre-determined threshold level is reached, the microcontroller generates two signals: one for triggering the alarm and the other for the wireless transmitter.
11. The personalised notification system of claim 2 in which the said alarm is activated by the corresponding output signal of the microcontroller.
12. The personalised notification system of claim 2 in which the microcontroller sends the corresponding output signal to the said wireless transmitter.
13. The personalised notification system of claim 2 in which the said wireless transmitter transmits the data.
14. The personalised notification system of claim 5 in which the said thread is generated each time the said computer receives data via the wireless receiver.
15. The personalised notification system of claim 5 in which the said preference rules are represented using XML.
16. The personalised notification system of claim 5 in which the said storer is a file system storing a set of XML files, each of which contains the preference rules defined by a user.
17. The personalised notification system of claim 5 in which the said storer can be accessed remotely by users via a client application. Users can specify or change his preference rules via the client application.
18. The personalised notification system of claim 5 in which access to the said storer is password protected.
19. The personalised notification system of claim 7 in which the said thread is one of multiple threads generated by the said computer.