This invention relates to a system and a method for disseminating distress signals.

BACKGROUND OF THE INVENTION

US 8483654 B2 discloses a novel system and method for enhancing people's personal safety and incident reporting, wherein mobile devices are used to report and/or record both "91 1 " type situations and non- emergency situations. Users of the invention can record, transmit, stream, upload and/or send information from a threatening situation to a dispatcher at an emergency management office or facility and to the user's safety group. The dispatcher can assess the situation and, if the situation warrants action, then the information can be forwarded to the appropriate first responders. The system geo-locates the user and allows integration of camera feeds in the user's vicinity. The inventive system and method enables a user to contact a dispatcher and also to alert the user's safety group. Four pieces of software facilitate video, audio, images and/or text medium of communication between the user-in-distress and the dispatcher, first responders and the user's safety group.

US 8768294 B2 discloses a notification and tracking system for a mobile device. The system includes a mobile device application that is adapted to be stored in memory on the mobile device. The application, upon activation, determines the GPS coordinates of the mobile device, records digital images over a period of time, sends a preset message from the mobile device to at least one recipient, preferably an emergency responder, such as a security monitoring station, and sends the GPS coordinates and the digital images. The coordinates and images may be sent to a remote server for storage and which can be accessed by the emergency responder. The coordinates and images are periodically updated and sent while the program is activated. Existing systems and methods suffer from a number of drawbacks. These systems and methods are not developed to determine potential rescuers who are located, at the moment of incident, within a radius from the user. They also lack the ability to report on incidents, more especially, by attaching image or video, which could serve as evident in prosecution. Moreover, alert messages transmitted by these systems do not provide elaborate information on the location of the user. They also lack the user- friendliness which is especially helpful in the event that the user is physically disabled.

SUMMARY OF THE INVENTION

According to the invention, the drawbacks are overcome and improvements are achieved in a system for disseminating distress signals, which comprises: at least one device, particulars of which being registered to the system, capable of transmitting or receiving the distress signal and determining position of the device, wherein content of said signal are customisable by user and transmission of the signal can be initiated by said user; and a server capable of: registering the particulars; receiving the signal from any one of the devices from which the signal is transmitted; reading the position of the transmitting device; locating another device or other devices eligible to receive the signal for being located within a radius from said transmitting device, based on distance between the transmitting device and the receiving device, wherein the distance is determined by Euclidean vector; conveying said signal to said receiving device; conveying the signal to a monitoring unit through which a web portal is provided for a third-party member to view the signal; and providing a web page through which the user can view the signal.

Preferably, the signal comprises audio and/or visual data provided by a system analytic module. Advantageously, the server compiles the distress signals into a list and transfers said list to the devices and the monitoring unit.

Preferably, the distress signal is an alert message or an incident report. Advantageously, the incident report comprises description on an incident, location of said incident, and audio or visual data of the incident.

Preferably, the distress signal is capable of navigating the user of the receiving device to the location of the transmitting device, using a navigational module.

Advantageously, the distance between the transmitting device and the receiving device is determined by extracting primary and secondary vertical and/or horizontal distances between three extremis and centroid.

The invention also provides a method for disseminating distress signals, which comprises steps of: registering, by at least one device, particulars of the device to the system, wherein the device is capable of transmitting or receiving the distress signals; determining, by the device, position of the device itself; initiating, by the user, transmission of the signal from the device, wherein the signal is customisable by user; receiving, by the server, the signal from any one of the devices from which the signal is transmitted, wherein particulars of the devices are registered by the server; reading, by the server, the position of the transmitting device; locating, by the server, another device or other devices eligible to receive the signal for being located within a radius from said transmitting device, based on distance between the transmitting device and the receiving device, wherein the distance is determined by Euclidean vector; conveying, by the server, said signal to said receiving device; conveying, by the server, the signal to a monitoring unit through which a web portal is provided for a third-party member to view the signal; and providing, by the server, a web page through which the user can view the signal.

Preferably, the signal comprises audio and/or visual data provided by a system analytic module.

Advantageously, the method also comprises a step of compiling, by the server, the distress signals into a list and transfers said list to the devices and the monitoring unit. Preferably, the distance between the transmitting device and the receiving device is determined by extracting primary and secondary vertical and/or horizontal distances between three extremis and centroid.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The invention will now be described in greater detail, by way of example, with reference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a system, according to the invention, for a user in distress to disseminate a distress signal to at least one potential rescuer located within a distance from the user;

FIG. 2 is a flowchart showing registration process of an authority, according to the invention;

FIG. 3 is a flowchart showing registration process of a user, according to the invention; FIG. 4 is a flowchart showing user validation process, according to the invention;

FIG. 5 is a screen capture of a default alert message;

FIG. 6 is a flowchart showing configuration of an alert message;

FIG. 7 is a flowchart showing configuration of a user location; FIG. 8 is a screen capture showing configuration of a user location;

FIG. 9 is a flowchart showing retrieval of historical alert messages or reports;

FIG. 10 is a flowchart showing transmission of an alert message;

FIG. 1 1 is a flowchart showing transmission of an incident report; FIG. 12 is a flowchart showing viewing of alert messages and incident reports through a mobile application or a system homepage;

FIG. 13 is a screen capture showing location of a user in distress; FIG. 14 is a screen capture showing close-up view of said location and relevant alert message;

FIG. 15 is a flowchart showing configuration of a user group; and

FIG. 16 is a flowchart showing authority monitoring on alert messages and incident reports through a webpage or a console.

As shown in FIG. 1 , the system comprises a plurality of mobile devices 101 , 104, 105, 106, a server 102, and a monitoring unit 103. A potential rescuer could be any one of a next-of-kin 104 of the user, another user 105, or a member of an authority, e.g. a police officer or a member of a neighbourhood watch team 106. An application is installed in the device, wherein the application comprises: a registration module for the user to register to the system; an alert module for the user to customise content of the signal and to initiate transmission of an alert message; a report module for the user to prepare an incident report which can be sent out to an authority, wherein said alert message or incident report is capable of navigating the potential rescuer to the location where the incident occurs; and a navigational module for determining position of the device. The server 102 is used for registering the user and the potential rescuer, receiving the signal from the device 101 , reading the position determined by the navigational module and the position of the rescuer, utilising said positions to calculate, e.g. using Euclidean vector, distance between the user and the rescuer, determining if the rescuer is an eligible receiver by judging if the rescuer is located within a radius, e.g. 3 km, from the user, and transmitting the signal to the eligible receiver if any. The server 102 compiles a list of alert messages, and sends the list to the user device 101 or the monitoring unit 103. The member of the authority registers to the system through the monitoring unit 103, and receives the message or the report from the server 102. The monitoring unit 103 provides a web portal for the member to view the message or the report. The server provides a web page through which the user and the potential rescuer can view the report. The system may also comprises a system analytic module, e.g. closed cable television (CCTV), for providing audio and/or visual data capable of being included in the message or the report.

Distance between the transmitting device 101 and the receiving device is determined by Euclidean vector. Euclidean distance is determined by extracting primary and secondary vertical and/or horizontal distances between three extremis and centroid.

FIG. 2 shows the registration process for authorities, e.g. police force and neighbourhood watch team (also known as Rukun Tetangga in Malaysia), from a console provided by a web-based system. In 201 , the user is required to fill in user particulars, i.e. the user's role, profile picture, identity card number, username, password, mobile phone number, security ID, address, latitude and longitude, and e-mail address. All of these particulars are mandatory for registration. Once the user has input all the particulars, data format validation is performed. If the input data format is incorrect (202 = NO), the system will prompt a message to notify the user that the data input is invalid. If all input data format are correct (202 = YES), the system will then check whether there is any duplication of information with existing records in the database. If there is a duplicate (203 = YES), the user is not registered and is prompted with a message indicating that the record exists in the database. Otherwise, the input data is inserted into the server database (203 = NO). A successful registered message is displayed to the user once the system has successfully inserted the data into the database (create a new record in database) and the registration process is complete. While the registration for police force and the watch team is done via web console, the system allows registration of public users via mobile platforms, e.g. Android and iOS. Said registration is based on the user's mobile phone number which uniquely represents the user. Detailed registration process for the public users is shown in FIG. 3. The process begins with a user fills in his/her mobile phone number, and the number is compared with the existing records in the server database. If the number does not exist in the database (301 = NO) and is not a police or the watch team user (302 = NO), an SMS with an authorization code is sent to the user's mobile phone (303). If the user fails to enter the valid authorization code (304= NO), he/she can opt for resending a new authorization code action to his/her mobile number. If the authorization code entered is valid (304 = YES), the user is redirected to the user detail interface to fill in their personal data (306) which is username, identity card number and a profile photo, and then continue with data validation. If all data entered is valid (307 = YES), the public user is registered into the server database and is redirected to the application's homepage. Otherwise, the user needs to make changes to the data they have filled in (306) to ensure a successful registration. If a wrong mobile phone number is filled in, the user can choose to use another mobile phone number and repeat the registration process as in 301 .

For convenience and to create a user friendly interface to all users, the system has an integrated login module for three types of users, which are the police, the watch team and public users. For police and the watch team, during their first time login to the application using a mobile device, the system will match the mobile number entered with the pre-registered records in server database. If the mobile number belongs to a police or a member of the watch team, the user is directed to the user detail interface and is required to fill in their personal data which is username, identity card number and profile photo, and proceed with data validation. As for public user, the same login process flow is applied after authentication step at 306 in FIG. 3. A successful login process will end with a redirection to the homepage. In the event of a next login, based on FIG. 4, if a user's record exists in their local database (401 = YES), the user is redirected to system homepage (402). Otherwise, the application redirects the user to the registration process to register as a new user (403).

The system provides the function to set a default alert message, i.e. an SOS message, to make sure that the emergency message can be delivered to surrounding users or authorities in the fastest way without the need for the user to retype it. An example of the default alert message is shown in FIG. 5. To edit the default alert message, user is required to tap on the existing message, change the message and finally tap on the save button. A successfully saved message is displayed to indicate that the saving process is complete.

FIG. 7 is the flow chart for preconfiguring locations. This function allows a user to add new preconfigured locations, edit, or delete existing locations. Initially, this function displays all locations that have been preconfigured by the user. If no preconfigured location is found from the local database (702 = NO), the application will display no data available message as shown in FIG. 7. By tapping on the "ADD" button at top-right corner, the user can add new preconfigured locations. If all fields are filled in, the information is inserted to the local database and the application continues to display all existing preconfigured locations. By tapping on an existing preconfigured location, a user can edit the location information such as changing the name (e.g. home, office) or the location's address (709 = YES). Once the user has changed the data, the local database is updated (710) and the application continues to display all preconfigured locations. To remove an existing location from the location list (707 = YES), the user may employ the standard long tap for Android devices, or "slide to the left" for iOS devices, and click on the discard icon to delete the location. FIG. 9 shows the process of retrieving historical alert messages or reports. This function allows a user to keep track on their personal records on emergency alerts and incident reports that has been sent. To display the history, the system will fetch all history data from local and server database (901 ). If there is no history data, a "data not available" message is displayed on screen of user device. If the user chooses to refresh the history list (905 = YES), the system fetches the history data from the server and updates new data (906), if available, to the local database. The application then continues to display the history, or "data not available" message if history data is empty. The flow of transmitting an alert message is shown in FIG. 10. When there is an emergency, a user can issue a text-based alert message to other users by tapping on "SEND SOS" button in the homepage. User is required to either choose a preconfigured location, or self-describe the current location in detail (1001 ). However, the location detail can be left blank as it will capture the current GPS location of the mobile phone. When the user taps on the "SEND" button (1002), information regarding the emergency event such as GPS location, time, location detail, and SOS message is inserted into the server database (1004). Once the information is successfully inserted into the database, the server fetches a list of users

(1005) , consisting of the user's next of kin which has been preconfigured, and other users which are selected by calculating the distance between the user in distress and the surrounding users or authorities within a predetermined radius. All these selected users are added to the alert list

(1006) and notification on the incident is pushed to the alert list users

(1007) via Google Cloud Messaging (GCM). Notification is received by the alert list users as long as they have network connection on their mobile phones.

FIG. 1 1 shows the process of reporting an incident. A user can also report on suspicious activities by tapping on the "REPORT" button. The user is then redirected to the report page and is required to fill in report details such as the incident description, location details of the incident or attach images from the incident (1 101 ). The report can only be sent when there is at least one field filled in (1 102 = NO). Once the report is sent, a report successfully sent message is displayed (1 103) to the user to indicate that the report event is successfully inserted into the server database (1 104). Then, the server fetches user's next of kin as well as the nearby users (1 105), by computing the distance between the user making the report and other surrounding users or authorities, and adds them into the alert list (1 106). Notification will then be pushed to the alert list users (1 107) so that they can provide help as soon as possible.

In the system, a user who is within a predetermined distance with a user that triggers a distress signal or sends a report can view the alert or report detail through homepage. The flow of this viewing process is shown in FIG. 12. The incident details can be viewed by tapping on a particular location cursor on the map as in FIG. 13 and further tapping on the message redirects the user to the detail page as shown in FIG. 14. Information such as the time, GPS location, description location details, and also image of the incident from reports is shown in the detail page. User also has the option to choose preinstalled navigation applications (1204) such as Google Map, Waze or Apple Maps to navigate to the location of incident by tapping on the location cursor on the map in detail page.

FIG. 15 shows the group setting function. This setting allows a user to add his/her friends and family into a group so that whenever the user sends a distress signal, the signal can reach them via push notification. Once the user clicks on the Add User option (1502 = YES), the user can search user using phone number or username, from database or phone contact (1503) to choose the particular contact to add that user to the group list and update group user to database (1506). User can also delete an existing group user by deleting it from the group (1507 = YES). This action also removes the group user from the server database.

Alert messages and reports on incidents that are sent by users can be monitored by police administrators from a control centre. This process is shown in FIG. 16. Whenever there is an emergency triggered or report sent from public, the incident is inserted into the server database. The web-based console system will then receive the incident's information from database (1601 ) and display it in the Incident List tab at the console's web browser. The incident is displayed as a pointer in the console map as well (1602). If the police user clicks on the particular incident either on the map or the incident list (1603 = YES), it will show the details of the incident such as GPS coordinates, alarm sending time, and a message describing the event and address (1604). If the police user clicks on disarm emergency button for a particular incident (1605 = YES), it disarms the incident and removes it from incident list and console map. The status of the incident is updated to disarm in the server database (1607) to indicate that the incident is no longer in active.