System for alerting rescue resources if a person falls into a body of water

Abstract

The present invention relates to a system for alerting rescue resources if a person falls into a body of water or seems to do so and comprising at least one primary smartphone (11) (distress smartphone) and one or more secondary smartphones (12) (assist smartphones) that comprise means, for instance an accelerometer, for detecting a fall, is able to locate a position and to interact with an external server (10). Said smartphones can act both as distress trigger devices, if a person carrying the device is potentially falling into the water, and act as community alert notification device if triggered by the server. The primary smartphone will send a fall signal to the server if located in vicinity to water (13).

Description

Technical field of the invention

[0001] The present invention relates to a system for alerting rescue resources if a person falls into a body of water or seems to do so and comprising at least one primary smartphone (distress smartphone), and one or more secondary smartphones (assist smartphones), said smartphones comprising means, for instance a gyroscope and an accelerometer for detecting a fall, and are able to locate a position, for instance by means of GNSS such as GPS and wherein data are being processed by a type of programmable software in the form of an application that also enables the smartphones to interact with a least one dedicated external server, which smartphones communicate by means of for example GSM, and can be used both for giving a distress signal and for assisting a rescue operation, wherein said rescue resources are being notified by the external server depending on whether predetermined factors are met, such as A) was the fall detection triggered within a pre-set short distance to open water (horizontal plane) defined by active geolocation which may vary if in a city from for instance 3 meters to the rim of water or for instance 5 meters to the rim of water in open country, B) was the velocity of the primary smartphone less than a predetermined speed such as 60 km / h before the fall was triggered, C) was the detected path of the specific fall detected by the primary smartphone not following a public road or railroad or similar, or deviating from this route, for instance by more than 45 degrees for more than 3 seconds, and D) was the specific fall detected by the primary smartphone less than for instance 150 meters above the sea level at the specific location, and after a fall alert the application will prompt the user with a request for sending an "I am ok"-signal to the external server in case of a false alarm, and after the end of a grace period (waiting for an "I am ok"-signal), the server will send out a distress message to the secondary smartphones and to other rescue systems.

[0002] The present description has been formed with the prerequisite that the reader has a general knowledge of telecommunication systems and software programming.Background of the invention

[0003] Smartphones on the market today have such high processor and power management capabilities that these portable devices are able to operate several applications in parallel along with normal transmitting features and protocols for handling data for example by external servers via GSM network and via Wi-Fi. In addition, smartphones of today are also equipped with gyroscope and accelerometer, which enables features for fall detection. This fact added with the use of GNSS location technology, for instance GPS, along with cellular location technology (Wi-Fi) make these cellular devices convenient to use in combination with an external server to improve the situation for persons potentially falling into water - by detecting a potential fall into water and alerting rescue resources.

[0004] In many of the western European societies, the demographic trends are changing towards moving from the countryside to the greater cities. Along with this, areas earlier used for industrial harbour purposes only, are today being developed into living- and recreational areas for the public. This results in more persons spending a greater amount of time "close to water" with the risk of falling into the water and for some with fatal consequences, as they drown. Many of these accidents happen when persons are alone with no one to rescue them or call out for help. The present invention is addressing this problem by utilizing fall detection and GPS data available in common "everyday" smartphones and combining these features with the specific but variable geolocation (indicating a close vicinity to water), as well as other parameters to release "potential drowning" alert notifications, via an external server, to public emergency response units as well as other smartphones within a certain perimeter, and also to locally installed emergency equipment.Prior art

[0005] The nature of the today's "potential drowning" alert inventions is in different setups focusing on wearable equipment to detect when a person has actually already fallen into the water e.g. by sensing the water ingress (see for instance Patent No. KR102238997B1: System for automatic distress reporting and drowning accident warning using smartphone application and methods thereof). Other systems are visually triggered by the shape of a person having entered the water in front of the detecting device (see Patent No. CN111028480A: Drowning detection and alarm system), by sensing temperature variance on an infrared camera (see Patent No. US8659661B2: Infrared camera systems and methods for maritime applications) or types of perimeter fences triggered if passed by persons (Patent No. GB2506128A: Position system tracking devices used aboard a waterborne vessel). Common for these inventions is that "potential drowning" alerts are not activated until an object is registered as being in the water, and then this information is sent to a "mother unit" for the specific device for further processing. The above-described systems often only cover a limited local area which could be e.g. pool areas, a pond, a beach, a specific harbour location or a waterborne structure.

[0006] Opposed to this, the nature of today's "potential fall" alert inventions is in different setups utilizing portable equipment to focus on the fall itself, when it has actually taken place saying that both an acceleration (beginning) and a de-acceleration (impact) have been observed (see Patent No. US2016078739A1: Wearable sends message on fall when worn) and maybe includes severity of the fall (see Patent No. US2023237894: System for detecting falls and discriminating the severity of falls), to set up priority level of the "potential fall" alert (selecting the correct notification phrase) that can be forwarded to e.g. an emergency response unit alarm board, along with identification data of the person in need, including geolocation. Most of the systems do allow the person that has fallen to abort the alert message before is distributed (see Patent No. US2021110682A1: Fall Detection Audio looping).

[0007] Common for today's drowning alert systems and fall alert systems that use wearable equipment is that they are all of the reactive type, reacting on events that have taken place. Meaning that the person, and thereby also the equipment is already entering the water when the situation is detected. To avoid short circuits in the wearable immediately after it is submerged in the water, this demands a water-resistant design, and also requires a special antenna setup to pick up a transmitting signal from a device being under the water when the first "alert" message is being released. A setup that does not go hand in hand with the common mainstream smartphones on the market (not all are waterproof), or the cellular networks being used for same (not designed for subsurface transmitting).

[0008] Another example of this type of prior art is described in Patent No. CN 113178052 (A Water falling alarm method and wearable equipment). According to said patent document, the water falling alarm method comprises following steps: current position information of a user is acquired through the wearable equipment; when it is detected that the wearable device falls into water, whether the current position information is located in a water area or not is determined; and when the current position information is located in the water area, alarm information is sent out. In this way, the water falling state and position of the user can be detected in time, and the purpose of timely rescue is achieved. More specifically, there is provided a method for falling water alarm on the end of a wearable device, wherein the method includes: Acquiring the current location information of the user through the wearable device; When it is detected that the wearable device has fallen into the water, determining whether the current location information is located in the water. When the current location information is in the water area, an alarm message is issued.

[0009] The detecting of whether the wearable device has fallen into the water includes: detecting, through the touch display screen of the wearable device, whether the sensing amount of the touch display screen exceeds a preset sensing amount threshold; and when the sensing amount of the touch display screen exceeds the sensing amount threshold, it is determined that the wearable device has fallen into the water.

[0010] The determining whether the current location information is located in the water area includes: sending the current location information to a network device to compare the current location information with map information through the network device to determine whether the current location information is located in the water area; and receiving a judgment result of whether the current location information is located in the water area returned by the network device.

[0011] As stated above, there are drawbacks to such a system. There is a great risk that a fall will not be registered correctly if the system must rely on whether or not a screen of a wearable device is in contact with large amounts of water. In this case there is a risk of the phone already being made inoperable due to ingress of water.Object of the invention

[0012] It is an object of the present invention to devise a system for alerting rescue resources if a person falls into a body of water or seems to do so that overcomes drawbacks of the prior art.Summary of the invention

[0013] According to the invention the system for alerting rescue resources if a person falls into a body of water or seems to do so comprises at least one primary smartphone (distress smartphone), and one or more secondary smartphones (assist smartphones), said smartphones comprising means, for instance a gyroscope and an accelerometer for detecting a fall, and are able to locate a position, for instance by means of GNSS such as GPS and wherein data are being processed by a type of programmable software in the form of an application that also enables the smartphones to interact with a least one dedicated external server, which smartphones communicate by means of for example GSM, and can be used both for giving a distress signal and for assisting a rescue operation, wherein said rescue resources are being notified by the external server depending on whether predetermined factors are met, such as A) was the fall detection triggered within a pre-set short distance to open water (horizontal plane) defined by active geolocation which may vary if in a city from for instance 3 meters to the rim of water or for instance 5 meters to the rim of water in open country, B) was the velocity of the primary smartphone less than a predetermined speed such as 60 km / h before the fall was triggered, C) was the detected path of the specific fall detected by the primary smartphone not following a public road or railroad or similar, or deviating from this route, for instance by more than 45 degrees for more than 3 seconds, and D) was the specific fall detected by the primary smartphone less than for instance 150 meters above the sea level at the specific location, and after a fall alert the application will prompt the user with a request for sending an "I am ok"-signal to the external server in case of a false alarm, and after the end of a grace period (waiting for an "I am ok"-signal), the server will send out a distress message to the secondary smartphones and to other rescue systems, said rescue system being characterized in that said predetermined factors being calculated by the smartphone and / or the server in advance of the fall of the primary phone, and said primary smartphone will send a fall signal immediately when a fall is detected to the external server (10) if triggered by the fall detection mechanism. It should be understood that some calculations can be performed by the server, if deemed advantageous - for instance in a low power situation of the primary smartphone - but in the preferred embodiment of the invention, the primary smartphone will comprise all necessary information before a potential fall and will contact the server and send all necessary information as soon as a fall is detected in a situation where all other conditions are also met.

[0014] The invention claimed in the present application addresses this mentioned "has happened" methodology, by proactively releasing the "potential drowning" message to an external server connected to the cellular network - if a fall to water is suspected to happen. Meaning that a distress signal is submitted when the person is still on dry land, providing better cellular network conditions, before the person has entered the water and thereby also before the smartphone is being submerged, which has a high potential for short circuiting the portable device and then losing signal to cellular network. The system according to the present invention has only one target and that is to ensure that rescue resources are being alerted in case of a person falls into the water - hence it is only actively responding to fall detection (rapid movement change) in close horizontal vicinity to open water. To reduce non-critical alarming to rescue resources, a number of conditions are being checked and included in the fall detections algorithm, such as: making sure the device is not on a plane, in a train / car or similar crossing water, on a bridge / in a tunnel, or on a fastmoving speedboat / jet ski, and also if the device falling path is pointing away from the water rim. Finally, the person in distress carrying the smartphone will get the chance to abort a non-critical event, within a certain grace period.

[0015] In order to achieve this, an external server is to be configured with software and protocols for communicating with fixed-line and cellular networks and be able to process the data in the system. In addition, a software application (an app) needs to be installed on the smartphones which are part of the system (community). The same application is to be used for all involved smartphones, since they are capable of acting both as the distress smartphone or primary smartphone when being worn by a person potentially falling to the water or as assist smartphones or secondary smartphones, when being positively responded to by the person wearing the smartphone, after being selected by the external server to receive an alert notification.

[0016] According to a preferred embodiment of the invention, the system is characterized in that the external server also sends an alarm message to a public alarm board, and the alarm message (verbal and MMS, SMS, and / or e-Call) holds information on time of accident, position (GPS coordinates and / or public name of place), name of person in distress and contact info, wherein the message can be cancelled by an alarm board operator (for instance by dialling a 3 digit code), and the full rescue mission can also be abandoned by the alarm board operator, in which case other categories of rescue resources receive a message to abandon mission.

[0017] This is a very convenient method for sending an alarm message.

[0018] According to another embodiment the system according to the invention, the external server sends a request to volunteers to assist, in batches of for instance 24 to the community for instance in a 4 step range (0-600, 600-1150, 1150-1650, 1650-2000 meters) aiming to fill up from the inner range, wherein the goal is that up to six persons will head for the site of accident, and wherein the full rescue mission can be abandoned by one of the six secondary smartphones if at location of the accident, for instance within a radius of 20 meters, which abandoning process will be guided on the secondary smartphone by a voice message and can be performed by pushing a button on the screen of the secondary smartphone for for instance 10 seconds, and if the mission is abandoned the other categories of rescue resources receive a message to abandon mission.

[0019] This method will expand the amount of rescue resources.

[0020] Preferably the system comprises an algorithm that prioritizes potential volunteers in shortest distance to scene of accident, as described: first priority group stakeholders will receive a digital message from the external server: >>A person has fallen into the water within 600 meters from your location, are you able to assist? (stakeholder is asked to prompt YES or NO on the secondary smartphone)<<, and if the question is not responded to by the stakeholder or the answer is not received by the external server within for instance 12 seconds it will be taken as a NO, and in case that less than six potential volunteers have replied YES or the answer has not been received by the external server within the 12 seconds, then the second priority group will receive a digital message from the external server: >>A person has fallen into the water within 1150 meters from your location, are you able to assist? (potential volunteer is asked to prompt YES or NO on the secondary smartphone), and if the question is not responded to by the stakeholder or the answer is not received by the external server within (new) 12 seconds it will be taken as a NO, and in case that less than 6 stakeholders in total, amongst first and second priority group have replied YES or their answer has not been received by the external server within the timeframe of in total 24 seconds from start of first digital message, then the third priority group will receive a digital message from the external server: >>A person has fallen into the water within 1650 meters from your location, are you able to assist? (stakeholder is asked to prompt YES or NO on the secondary smartphone)<<, and if question is not responded to by the stakeholder or the answer is not received by the external server within (new) 10 seconds it will be taken as a NO, and in case that less than 6 stakeholders in total amongst the first, second, and third priority group have replied YES or their answer has not been received by the external server within the 10 seconds (total 34 seconds from start of first digital message), then the fourth priority group will receive a digital message from the external server: >>A person has fallen into the water within 2 kilometres from your location, are you able to assist? (stakeholder is asked to prompt YES or NO on the secondary smartphone)<<, and if the question is not responded to by the stakeholder or the answer is not received by the external server within (new) 20 seconds it will be taken as a NO and session on the secondary smartphones will end.

[0021] This a very convenient way to expand the rescue resources.

[0022] According to yet another embodiment of the system, up to six volunteers are guided to the scene of accident and are guided to what to do when approaching in the following way: If a stakeholder volunteers to help, by responding yes on the secondary smartphone, when being notified that a person has fallen into the water then four steps are being initiated: Step 1) a map showing the location of the accident and the calculated nearest walking route from where the stakeholder is at that moment (route can be changed to bike- or car route), is immediately being established by data received from the external server by the secondary smartphone, the route and ETA to the scene of accident along with elapsed time from when the person fell into the water, is shown on the secondary smartphone screen; Step 2) When the stakeholder is approaching for instance 30 meters from the location of where accident was reported, additional data is forwarded from the external server to the secondary smartphone which will initiate that the route map mentioned in step 1 will change to the name of the person owning the primary smartphone and will be shown on the screen along with other possible information such as for instance height, weight and age, and the location of nearby rescue equipment is being shown on the screen, such as nearby lifebuoys and / or nearby rescue ladder(s), and thereafter a verbal message on the secondary smartphone (in national language if nothing pre-selected), is being initiated and will be rolling until next step: >>you are helping (e.g. Peter) please do shout out the name when approaching, and also start to locate the rescue equipment, but continue towards the site of the accident<<; and Step 3) when the stakeholder is within for instance 5 meters from the location of where the accident was reported, additional data is forwarded by the external server to the secondary smartphone which will initiate that the verbal message mentioned in step 2, is abandoned along with the screen that was showing route, personal data, and rescue equipment closes, and the screen will now show the map of the present site, pointing out the location of where the primary smartphone was triggered by the accident, showing nearest located lifebuoy and rescue hook or rescue ladder, and on the same map, the forecasted drift direction of the person in the water and estimated drift distance will be shown based on the data submitted from the external server with forecasted water current (speed and direction), where the system will combine this information with the already running elapsed time from detected fall into water (this elapsed time, as mentioned in step 1, was at that point submitted from the external server to the secondary smartphone), and a new verbal message on the secondary smartphone (in national language if nothing pre-selected), is also initiated: >>If you are first person arriving at site or alone, shout out continuously: "HELP; A PERSON HAS FALLEN INTO THE WATER" and look from this place to the water in the drifting direction, and if you arrive and there are more persons at the site you will together decide to move out from the fall site generally in the direction of the drift / downstream, and it is further decided that one person should call the public emergency number, and on one person that is running for lifebuoy / rescue pole«, wherein the verbal message is repeated twice and then a new verbal message is initiated: »If you see the person located in the water, then throw a lifebuoy or anything else for buoyancy and if the device has a strap keep control of the line so the person can be pulled towards you, and if the person is brought on dry land then commence first aid and / or provide other assistance, and do not leave until public emergency responders take over<<; Step 4) when public emergency responders arrive at scene, or in the event that public emergency responders are already at accident site when stakeholder arrives in step 3, or in the event that the person owning the primary smartphone is at site within a perimeter of for instance 20 meter, confirming that it was a no-critical alert then the stakeholder can activate a dismiss signal on the secondary smartphone which will be transmitted to the external server by pushing a button on the screen and holding it for 10 seconds, which will initiate a verbal message on the secondary smartphone (in national language if nothing pre-selected) >>You are now cancelling the alert triggered by (name of the primary smartphone owner), please confirm by holding the button for another 5 seconds, and if it is a "false alarm" and only secondary smartphone responders have arrived at the site but no public emergency responders is at the site, then also contact public emergency board by phone for calling off the rescue«, and once the 10 second abandon mission signal has been received by the external server, it will send a abandon mission signal to any secondary smartphones that has been notified on the specific event, and the screen of each triggered secondary smartphone will show »rescue notification aborted« and also a verbal message on the secondary smartphone (in national language if nothing pre-selected) is initiated: »The fall into water alert has been aborted and no further assistance is needed. Thank you for helping<<, and the external server also sends an abandon mission notification as SMS and or MMS to the public alarm board, that text message would contain sentences that: >>message was generated from an automatic drowning alert system first triggered at (time) at (location) for (name of owner of the primary smartphone)..., mission actively aborted at (time) by a person at site (name on owner of secondary smartphone that sent the abandon mission signal)..., with the cell phone number..., that alerted community have been informed..., and that automatically operated rescue equipment has received mission aborted signal<<, and the external server also sends an abort mission signal to the IP address for the local rescue devices that have been involved in the mission.

[0023] This is an example of how the rescue mission will be performed from the view of owners of secondary smartphones (assist smartphones).

[0024] In another feature that, advantageously, can be used on the secondary smartphones, the name of the person that has fallen into the water is being shown on the secondary smartphones and persons are requested to shout out the name when approaching the scene of accident.

[0025] In another embodiment, if a risk of drowning notification is validated to be real by the algorithm, the external server transmits a start mission command to relevant i) local fixed rescue equipment or to ii) remotely operated or autonomously operated rescue equipment, wherein the local fixed rescue equipment receives a start mission signal that is being repeated every 10 seconds until the mission is called off by the external server by transmitting an abort mission signal, and said local fixed rescue equipment will only receive the command from the external server if within a radius of for instance 75 meters from the location of the "potential drowning" accident where the radius of 75 meter is framed as a parallel belt following the rim of the water breaching out for instance 5 meters to dry side of the said rim and for instance 10 meters to the wet side of said rim, and the remotely or autonomously operated rescue equipment will be receiving a timestamped start mission trigger signal by the external server if the equipment installation point is within a radius of for instance 600 meters from the location of the "potential drowning" accident, and the start mission trigger signal will be repeated every 10 seconds from the external server until mission is later called off by the external server when sending an abandon mission signal to the involved equipment, and the equipment will receive a timestamped first GPS position of the accident including geofence coordinates, sent by the external server that setup the frames for allowed mission zone, and the starting radius will be for instance 20 meters from the location of the accident, and besides the first radius setting, the geofencing will be bordered by any rim of the water (only operating above open water), and followed by first geofence notification, the autonomous equipment will receive dynamic timestamped GPS geofence coordinates every 60 seconds that set up adjusted borders for the allowed mission zone, so as to allow the perimeter in the forecasted drift direction to be expanded in line with the estimated drift distance based on current data and elapsed time, and by the end of mission the external server sends an abort mission signal to the equipment.

[0026] These measures ensure an efficient use of the rescue resources.

[0027] In another embodiment the system besides the first geo location also comprises a variable search area, which estimates the location of person in water, and this is calculated, based on time since the fall was triggered and available current data for the specific area.

[0028] As a strong current can make a person drift very far, it is a great advantage to take the current into consideration.

[0029] The external server may also advantageously be connected to a national or regional forecast website similar to e.g. "windy.com", so as to obtain forecasted and in some places, live updated current data, which is to be used, for calculation of adjustments of the dynamic border, which is expanded in the direction of the current, to ensure search is also done in the area, where the person in water could have drifted to.

[0030] In this way, it is possible to obtain very precise data for making the search and rescue operation more efficient.

[0031] According to yet another embodiment of the invention the system may comprise a training and testing regime, and smartphone owners are prompted as a minimum 1 time per month to participate, and to ensure accuracy of the fall and location equipment and that persons know how the alarm sounds and how / when to mute, the following is being tested: 1) accuracy of the GPS location compared with the map when standing close to any water rim, and the result will be logged; 2) Test of accelerometer by simulating a fall or by informing app when asked on the screen; 3) test of app, which can be performed in partnership with more smartphones, where one acts as primary smartphone and the rest act as secondary smartphones, and the test will be performed by submitting relevant persons and each will get a code to enable the app to open a test environment, and from here a scenario can be played by persons, without sending "distress signals" to any other equipment outside of the test environment.

[0032] The dual purpose of training and testing can be achieved through this method.

[0033] As a summary, the system to alert rescue resources if person falls into water or seems to do so comprises smartphones having common fall and location features, which have been programmed via an application (app) to interact with an external server. Said smartphones will act both a distress trigger (now primary smartphone) if a person carrying the device is potentially falling into water and act as community alert notification device (now called secondary smartphones) if activated by the external server. The primary smartphone will send a fall signal immediately to the external server if triggered by the fall detection mechanism, but only if located in close vicinity to water, which varies if in a city (primarily cellular location technique) or in the open country (primarily GNSS location technique), and simultaneously to the detected fall the primary smartphone will start to prompt the person carrying the smart phone as text message and voice for an "I am ok" response. Whether this detected fall signal from the primary smartphone is handled as a real distress, depends on dynamics in the detected fall, and if certain conditions in the algorithms are met. If the external server does not receive an "I am ok" within a dynamic "grace time" from the primary smartphone, and that certain other criteria are met (e.g. not being in a car passing a bridge by a public road), then the external server sends out alert signals to a public emergency board and to the secondary smartphone in a perimeter to the location of where the potential fall was triggered. In batches of 24 persons being member of the community and carrying secondary smartphones are asked by the external server if willing to help. If as many as 6 persons within the perimeter responds yes to assist, these 6 persons will be picked as they have the shortest distance to site of accident, and they are then forwarded info of where to run and who to assist. In addition, a "start mission" command is being sent to possible connected local rescue devices e.g. alarm horns, illuminated ladders, infrared guided search lights and autonomous infrared guided drones in a defined vicinity to the location of the accident.

[0034] The public emergency board receives both voice and SMS, MMS, and / or e-Call messages with personal data on the person in distress, as well as time and location of accident. Voice messages as well as the complete rescue mission can also be abandoned from here. Secondary smartphones as well as locally installed rescue equipment will then receive an abandon mission / abort mission signal from the external server.

[0035] When a maximum of 6 community secondary smartphones volunteer to help, they will receive various information from the external server, such as text and route info on the screen and voice messages. Messages change upon approaching the site of the accident asking for certain actions to be done. Also, the search area is being expanded depending on water current and elapsed time for mission. Each of the, up to 6 persons, carrying a secondary smartphone are able to abandon the mission e.g. in case that public first responders are approaching the scene of accident or if confirmed by the person that would have been carrying the primary smartphone that it was a non-critical event. Certain actions are to be performed if calling off the mission. For instance, the secondary smartphones need to be present within a radius of for instance 20 meter from the scene of accident. Other secondary smartphones involved in the mission, as well as the public alarm board and the locally installed rescue equipment will then receive an abandon mission / abort mission signal from the external server.

[0036] The external server is able to notify 2 types of locally installed rescue equipment. The first type comprises remotely operated autonomous devices, which could be an infrared guided drone. The drone would receive coordinates for the accident by the external server, but also a dynamic geofencing which for instance is depending on the drift path and elapsed time for the mission. The second type of equipment is "on / off" equipment that is being send a start mission signal by the external server depending on the close vicinity to the scene of accident. Equipment in this category could be e.g. flood lights. Such equipment is only provided with a signal from the external server and functionally is solely controlled by equipment vendor(s).

[0037] According to the invention, the system to alert rescue resources if person falls into water, does have features incorporated to assist with machine learning, to improve accuracy of the fall detection part, and to improve accuracy of the GPS and cellular positioning features.Description of drawings

[0038] In the following, the invention will be described in further details referring to the drawings, in which: Figure 1 shows the topology of the system, Figure 2 shows priority principles when inviting the community to assist, and Figure 3 shows the principles of dynamic perimeter setting depending on the current. Detailed description of the invention

[0039] A regime of interrelated functions in a smartphone (equipped with standard fall detection mechanism such as accelerometer, gyroscope and location identification functionality as GPS positioning as well as cellular positioning Wi-Fi + GSM transmitting functionality and Wi-Fi receiver) and executing server(s) (can be more than one server, depending of the area covered by the system, now called external server) are providing "risk of drowning" emergency notifications to defined rescue resources in case a person carrying the specific smartphone (now defined as a primary smartphone or distress smartphone) 11 falls in the vicinity of water and thereby potentially into the water. Whether said rescue resources are actually being notified by the executing server(s) 10, depends on whether predetermined factors are met: A) Was the "I am ok" function in the primary (distress) smartphone not responded to or not received by the executing server(s) within a variable grace period? B) Was the fall detection triggered within a pre-set short distance to open water (horizontal plane) 13 defined by active geolocation? C) Was the velocity of the primary smartphone 31 less than 60 km / h before the fall was triggered? D) Was the detected path of the specific fall detected by the primary smartphone not following a public road or railroad or deviating from this route > 45 degrees > 3 seconds? Was the specific fall detected by the primary smartphone less than 150 meters above sea level at the specific location? Regarding the variable grace period - which is the time the user can abandon transmission of the alert notification from the external server(s) - this is divided into at least 3 categories depending on the probability of whether or not the fall actually was a fall into the water or still only in the vicinity, e.g. on the quayside. 1.) A long grace period which as an example could be 60 seconds: If the path of the triggering rapid movement on the primary smartphone 11 is determined to be away from the edge of the water and no impact has been detected. 2.) Mean grace period: If the path of the triggering rapid movement on the primary smartphone is determined to be against the edge of the water or an impact was registered. 3.) Short grace period: If events for the second category have been triggered and a second rapid movement or impact was detected or if a possible moisture detector in this specific brand of primary smartphone gives a signal that is received by the external server 20.

[0040] If prerequisites for fall alert are met and it has not been confirmed as being non-critical by the user of the primary smartphone 21, by responding to the "I am ok" function within the grace period - then the external server 20 will release "potential drowning" notifications to 3 different types of targets (X, Y, Z).X) Public emergency response resources

[0041] A voice message is being sent to the public alarm board 14, that would be the normal point of contact for "drowning accidents". This is a number that can vary from region to region in any country. As an example, it would be reached by dialling the phone number 112 if in Denmark. The message would contain sentences, in the national language, that: >>message is generated from a drowning alert device and that a person named..., with the cell phone number..., has been detected as fallen into the water at time..., at position (where position could be GPS coordinates as well as What3Words coordinates)..., possible name of fall location..., that same information including location has been sent by text to number<<. The voice message will be repeated four times and then hung up and call repeated if not stopped by the operator, confirming receival, typing a three digit code (exclusive for the call) or dialling a separate phone number (exclusive for the region) followed by typing previously mentioned three digit code..., that upon finalized job or false alarm, the mission can be aborted by the alarm board operator 14 by dialling a separate phone number (exclusive for the region) and type in previously mentioned three digit code twice. Also, an SMS, MMS, and / or e-Call message is being sent to the public alarm board, which would be the normal point of contact for "drowning accidents". A number that can vary from region to region in any country. As an example, it could be reached by texting to number 999 if in the UK. The text message would contain sentences such as: >>message was generated from a drowning alert device and a person named..., with the cell phone number..., has been detected as fallen into the water at time..., at position (where position could be GPS coordinates as well as What3Words coordinates)..., possible name of fall location (MMS will also deliver a map of the detected fall location)..., that same information including location has been sent as a voice message to the alarm board phone number (exclusive for the region)..., that message was sent automatically and can be commented on by contacting..., where a specific company name with specific contact details would be stated..., and that upon finalized job or false alarm the mission is to be aborted from alarm board operator by contacting the external server by dialling a separate phone number (exclusive for the region) and enter the previously mentioned three digit code twice<<. Once this action is received by the external server 10, ref section Y step 4, this will send a abandon mission signal to any secondary (assist) smartphone that has been notified on the specific event where the screen on each triggered secondary smartphone 22 will show >>rescue notification aborted« and also a verbal message on the secondary smartphone (in national language if nothing pre-selected) is initiated: »The fall into water alert has been aborted and no further assistance is needed. Thank you for helping<<. The external server also sends an abort mission signal to the IP address of the local rescue devices 15 and 35 that have been involved in the mission, ref section Z.

[0042] Y) Stakeholders in a defined radius from the site of accident and connected to the community: Providing they carry a smartphone that is part of the "potential drowning" system by having same type of software installed and enabled, which concludes it being part of the community (in the following defined as secondary smartphones 22), a data signal forming a question is transmitted from the external server if the secondary smartphone is being identified to be up to 2000 meters away (in a straight line) 29 from the site of accident. However, whether the secondary smartphone 22 is contacted from the external server 20 or not, depends on the number of secondary smartphones 22 identified in the area of the accident. The goal is that 6 stakeholders (persons carrying a secondary smartphone) are being directed to the scene of accident - where stakeholders within shortest distance to accident will be prioritized.

[0043] The first priority group is within 600 meters of the accident 26, second priority group is within the range of 600-1150 meters from the accident 27, third priority group is within the range of 1150-1650 meters from the accident 28, and the fourth priority group is within the range of 1650-2000 meters from the accident 29.

[0044] Starting with first priority group stakeholders, they will get a digital message from the external server: >>A person has fallen into the water within 600 meters from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone). If question is not responded to by the stakeholder or the answer is not received by the external server 20 within 12 seconds it will be taken as a NO. In case that less than six stakeholders have replied YES or the answer has not been received by the external server within the 12 seconds, then the second priority group will then get a digital message from the external server: >>A person has fallen into the water within 1150 meters from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone 22). If question is not responded to by the stakeholder or the answer is not received by the external server 20 within (new) 12 seconds, it will be taken as a NO. In case that less than six stakeholders in total amongst first and second priority group persons have replied YES or their answer has not been received by the external server within the timeframe of in total 24 seconds from start of first digital message, the third priority group will get a digital message from the external server: >>A person has fallen into the water within 1650 meters from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone 22). If question is not responded to by the stakeholder or the answer is not received by the external server 20 within new 10 seconds, it will be taken as a NO. In case that less than six stakeholders in total amongst the first, second, and third priority group have replied YES or their answer has not been received by the external server within the 10 seconds (total 34 seconds from start of first digital message), the fourth priority group will now get a digital message from the external server: >>A person has fallen into the water within 2 kilometres from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone 22). If question is not responded to by the stakeholder or the answer is not received by the external server 20 within (new) 20 seconds, it will be taken as a NO and the session on the secondary smartphones will end.

[0045] If a stakeholder volunteers to help by responding YES on the secondary smartphone 22 when being notified that a person has fallen into the water, four steps are being initiated.

[0046] Step 1) A map showing the location of the accident and the calculated nearest walking route from where the stakeholder is at that moment (route can be changed to bike or car route) is immediately being established by data received from the external server 20 by the secondary smartphone 22. Route and ETA to scene of accident along with elapsed time from when the person fell into the water, is shown on the secondary smartphone screen.

[0047] Step 2) When the stakeholder is approaching for instance 30 meters from the location of where accident was reported, additional data is forwarded from the external server 20 to the secondary smartphone 22, which will initiate that the route map mentioned in step 1 will change setup where the name of the person owning the primary smartphone 21 is being shown on the screen along with other relevant information such as height, weight and age. Also, the location of nearby rescue equipment 15 is being shown on the map - which could e.g. be nearest lifebuoy and nearest rescue ladder. A verbal message on the secondary smartphone 22 (in national language if nothing pre-selected), is now being initiated and will be active until next step: >>you are helping (e.g. Peter) please, do shout out the name when approaching, also start to locate the rescue equipment, but continue towards the site of the accident<<.

[0048] Step 3) When the stakeholder is within for instance 5 meters from the location of where the accident was reported, additional data is forwarded by the external server 20 to the secondary smartphone 22 which will initiate that the verbal message mentioned in step 2 is ceased, and the screen that was showing route + personal data and rescue equipment closes down. The screen will now show the map of the present site, pointing out the location of the site where the primary smartphone 21 was triggered by the accident, showing nearest located lifebuoy 15 and rescue hook or rescue ladder. On the same map the forecasted drift direction of the person in the water and estimated drift distance will be shown 36 - this is based on the data submitted from the external server 30 with forecasted water current (speed and direction) 39, where the secondary smartphone 22 and / or the server will combine this information with the already running elapsed time from detected fall into water (this elapsed time, as mentioned in step 1, was at that point submitted from the external server 20 to the secondary smartphone) 22. Just to highlight the importance of this feature, a current of 1 knot = 0,514 m / s can potentially make a person drift up to 30 meters per minute. In major rivers in Europe, it is not abnormal to see currents between 4-8 knots. A new verbal message on the secondary smartphone 22 (in national language if nothing pre-selected), is also initiated: >>If you are first person arriving at site or alone, shout out continuously: "HELP; A PERSON HAS FALLEN INTO THE WATER" and look from this place out over the water in the drifting direction. If you arrive and there are more persons at the site, all of you have to decide on spreading out from the fall site and move in direction of the drift / downstream. You should choose one person who should call the public emergency number 14, and also choose one person running for lifebuoy / rescue pole« 15. The verbal message is repeated twice and then a new verbal message is initiated: »If you see the person located in the water, throw a lifebuoy or anything else for buoyancy and if the device has a strap keep control of the line so the person can be pulled towards you. If the person is brought on dry land, commence first aid and / or provide other assistance. Do not leave until public emergency responders take over<<.

[0049] Step 4) When public emergency responders arrive at scene, or in the event that public emergency responders are already at accident site when stakeholder arrives in step 3, or in the event that the person owning the primary distress smartphone is at site, within a perimeter of for instance 20 meters, confirming that it was a not critical alert, the stakeholder can activate a dismiss signal on the secondary smartphone 22 which will be transmitted to the external server by pushing a button on the screen and holding it for for instance 10 seconds. This will initiate a verbal message on the secondary smartphone 22 (in national language if nothing pre-selected) >>You are now cancelling the alert triggered by (name on primary smartphone owner) please confirm by holding the button for another 5 seconds. If it is a "false alarm" and only secondary smartphone responders have arrived at the site, but no public emergency responders are at the site, also contact public emergency board by phone for calling off the rescue mission<<. Once the 10 second abandon mission signal has been received by the external server 20, it will send an abandon mission signal to any secondary smartphone 22 that has been notified on the specific event where the screen on each triggered secondary smartphone 22 will show >>rescue notification aborted« and also a verbal message on the secondary smartphone 22 (in national language if nothing pre-selected) is initiated: »The fall into water alert has been aborted and no further assistance is needed. Thank you for helping<<. The external server 20 will also send an abandon mission notification as an SMS and / or MMS to the public alarm board 14, and that text message would contain following sentences: >>message was generated from an automatic drowning alert system first triggered at (time) at (location) for (name of person / owner of the primary smartphone 21) ..., now mission actively aborted at (time) by a person at site (name of owner of secondary smartphone 22 that sent the abandon mission signal)..., with the cell phone number..., that alerted community have been informed..., that automatically operated rescue equipment has been sent mission aborted signal<<. The external server will also send an abort mission signal to the IP address of the local rescue devices 15 and 35 that have been involved in the mission, ref below section Z.

[0050] Z) Installed rescue equipment, within a defined perimeter of the accident: Especially in some harbour and river quay sides, different local rescue equipment has been installed, with the purpose of improving the situation for persons falling into the water. This could be lifebuoy cabinets (which are also seen on many beaches) where quayside models are sometimes equipped with a portable rescue ladder 15 and a rescue hook. Also fixed mounted rescue ladders going from below the water surface to dry ground are seen in some places as well as fixed flood lights, where much of the equipment is illuminated for better visibility during dark hours. In the future when Internet of Things (IoT) and consistent 5G GSM coverage will be more common, one could think of an even higher automation level of equipment which e.g. could be a running light function on existing illumination, but also the future could bring us event triggered alarm horns, infrared guided search lights as well as autonomous infrared guided drones 35 to be installed. It should be noted that none of the mentioned equipment or developments thereof in this section Z is part of this present invention. In this section Z the description should be understood as a part of the present invention: If prerequisites for fall alert are met and it has not been confirmed non-critical by the user of the primary smartphone 21 by responding to the "I am ok" function within the grace period - the external server will release a "potential drowning" notification to any of the above equipment mentioned in section Z, if these are set up with protocols to receive and process the trigger signals via WAN / LAN connected through ethernet, Wi-Fi or a GSM module. Provided the equipment is connected to the external server 10 and the GPS coordinates consequently mapped in the control unit for the external server, said rescue equipment will be triggered in the two levels: R (remote) or S (stationary), located within predefined maximum perimeters to the specific location of the "potential drowning" accident (initially received by the external server 30 from the primary smartphone 21). Level R or level S equipment will not be allowed to send any abort mission signal to the external server 30, these will only be allowed to receive an abort mission signal from the external server 30.

[0051] Level R) Equipment triggered by level R is defined as remotely operated or autonomously operated equipment 35 that needs a start mission trigger signal, a GPS or What3Words location as a target point for the activity, including a dynamic mission area (geofence), and when mission is completed an abandon mission signal. Equipment in this category could be, but is not limited to, infrared guided autonomous drones 35, infrared guided autonomous waterborne vessels (e.g. a motorized lifebuoy), motion guided cameras with or without night vision (infrared), motion guided searchlights with or without night vision (infrared).

[0052] R1) Level R equipment will be receiving a timestamped start mission trigger signal by the external server if equipment installation point, similar to equipment homebase, is within a radius of for instance 600 meters from the location of the "potential drowning" accident (initially received by the external server from the primary smartphone). The start mission trigger signal will be repeated every 10 seconds from the external server until mission is later called off by the external server when sending an abandon mission signal to the involved Level R equipment.

[0053] R2) Level R equipment will receive a timestamped GPS coordinate sent by the external server.

[0054] R3) Level R equipment will receive timestamped first GPS geofence coordinates 36, sent by the external server 30 that setup the frames for allowed mission zone. Start perimeter will be for instance 20 meters from the location of the accident (initially received by the external server 20 from the primary smartphone) 21. Besides the first perimeter setting, the geofencing will be framed by any rim of the water (only operating above open water). Internally programmed restrictions in the remotely operated equipment will not be superseded.

[0055] R4) Followed by the first geofence notification described in R3, the level R equipment will receive a dynamic timestamped GPS geofence every 60 seconds sent by the external server that setup adjusted coordinate frames for the allowed mission zone 36-38. This is to allow the perimeter in the forecasted drift direction to be expanded in line with the estimated drift distance. The calculation of said distance is only done in the external server 30 and based on forecasted water current (speed and direction) combined with the elapsed time from detected fall to water. Just to highlight the importance of this feature, a current of 1 knot = 0,514 m / s can potentially make a person drift up to 30 meters per minute. In major rivers in Europe, it is not abnormal to see currents between 4-8 knots. Other limitations mentioned in R3 will remain.

[0056] R5) If the person in distress (carrying the primary smartphone 21) is located or detected by any of the level R, the equipment will handle as per own algorithm, which is not a part of the present invention. The external server 30 is for IT security reasons not meant for receiving any signals from any level R equipment.

[0057] R6) Referring to section Y step 4, a search and rescue mission can be aborted for more reasons - but only by human interference. When this is initiated, an abandon mission signal is sent from the external server 30 to the IP address for any of the local rescue devices 35 that have been involved in the mission. Then, the equipment is expected to cease operation, but this will solely be handled as per own algorithm of each equipment and is not a part of the present invention.

[0058] Level S) Equipment triggered by level S is defined as statically operated equipment that needs a start mission trigger signal, and upon completion an abandon mission signal. Equipment in this category could be, but is not limited to, illuminated lifebuoy cabinets, illuminated hang off points for portable rescue ladders and rescue hooks, fixed mounted illuminated rescue ladders, fixed flood lights 15 or normal bridge / dock / quayside illuminations (sometimes dimmable), fixed mounted flashlights, and / or fixed mounted sirens marked with signs (e.g. saying: in case of alarm look out for person in the water).

[0059] S1) Level S equipment will be receiving a timestamped start mission trigger signal by the external server if equipment installation point is within a radius of for instance 75 meters from the location of the "potential drowning" accident (initially received by the external server 20 from the primary smartphone 21), where the 75 meter radius is framed as a parallel belt following the rim of the water breaching out for instance 5 meters to dry side of the said rim and for instance 10 meters to the wet side of said rim. The start mission trigger signal will be repeated every 10 seconds from the external server 10 until the mission is later called off by the external server 10 when sending an abandon mission signal to the involved Level S equipment.

[0060] S2) Referring to section Y step 4, a search and rescue mission can be aborted for several reasons - but only by human interference. When this is initiated, an abandon mission signal is sent from the external server to the IP address of the local rescue devices 15 that have been involved in the mission. Then, the equipment is expected to cease the operation, but this will be handled by other parties as this is executed per equipment algorithm of each equipment and is not a part of the present invention.

[0061] W) The system that is set up for sending alerts automatically based on algorithms is to a high degree depending on getting a valid data set from the fall detection as well as location positioning equipment, accelerometers, and gyroscope. Features are incorporated into the app to assist with machine learning, to improve accuracy of the fall detection part, and to improve accuracy of the GPS and cellular positioning features along with a training environment, where more than one person can obtain a code to make a live test with one device being appointed to be primary smartphone 21 and others to be secondary smartphones 22. In this training environment a full scenario can then be played without triggering any other smartphones, alarm boards etc.Reference numerals

[0062] 10:External server 11:Primary smartphone 12:Secondary smartphone 13:Close vicinity to water 14:Public emergency board 15:Locally installed stationary rescue equipment 20:External server 21:Primary smartphone 22:Secondary smartphone 23:Close vicinity to water 26:600 meters from scene of accident. First priority volunteer group 27:1150 meters from scene of accident. Second priority volunteer group 28:1650 meters from scene of accident. Third priority volunteer group 29:2000 meters from scene of accident. Fourth priority volunteer group 30:External server 31:Primary smartphone 35:Locally installed remotely operated or autonomous rescue equipment 36:First perimeter setting, branching out as the current direction 37:Second perimeter setting, branching out as the current direction 38:Third perimeter setting, branching out as the current direction 39:Regional or national, current forecast or live date

Claims

1. System for alerting rescue resources if a person falls into a body of water or seems to do so and comprising at least one primary smartphone (11) (distress smartphone), and one or more secondary smartphones (12) (assist smartphones), said smartphones comprising means, for instance a gyroscope and an accelerometer for detecting a fall, and are able to locate a position, for instance by means of GNSS such as GPS and wherein data are being processed by a type of programmable software in the form of an application that also enables the smartphones to interact with a least one dedicated external server, which smartphones communicate by means of for example GSM, and can be used both for giving a distress signal and for assisting a rescue operation, wherein said rescue resources are being notified by the external server depending on whether predetermined factors are met, such as A) was the fall detection triggered within a pre-set short distance to open water (horizontal plane) defined by active geolocation which may vary if in a city from for instance 3 meters to the rim of water or for instance 5 meters to the rim of water in open country, B) was the velocity of the primary smartphone (21) less than a predetermined speed such as 60 km / h before the fall was triggered, C) was the detected path of the specific fall detected by the primary smartphone not following a public road or railroad or similar, or deviating from this route, for instance by more than 45 degrees for more than 3 seconds, and D) was the specific fall detected by the primary smartphone less than for instance 150 meters above the sea level at the specific location, and after a fall alert the application will prompt the user with a request for sending an "I am ok"-signal to the external server in case of a false alarm, and after the end of a grace period (waiting for an "I am ok"-signal), the server will send out a distress message to the secondary smartphones and to other rescue systems, characterized in that said predetermined factors being calculated by the smartphone and / or the server in advance of the fall of the primary phone, and said primary smartphone will send a fall signal immediately when a fall is detected to the external server (10) if triggered by the fall detection mechanism.

2. System according to claim 1, characterized in that the external server (10) also sends an alarm message to a public alarm board, and the alarm message (verbal and MMS, SMS, and / or e-Call) holds information on time of accident, position (GPS coordinates and / or public name of place), name of person in distress (11) and contact info, wherein the message can be cancelled by an alarm board operator (14) (for instance by dialling a 3 digit code), and the full rescue mission can also be abandoned by the alarm board operator, in which case other categories of rescue resources receive a message to abandon mission.

3. System according to claim 1 or 2, wherein the external server (10) sends a request to volunteers to assist, in batches of for instance 24 to the community for instance in a 4 step range (0-600, 600-1150, 1150-1650, 1650-2000 meters) (26-29) aiming to fill up from the inner range, wherein the goal is that up to six persons will head for the site of accident, and wherein the full rescue mission can be abandoned by one of the six secondary smartphones if at location of the accident, for instance within a radius of 20 meters, which abandoning process will be guided on the secondary smartphone (22) by a voice message and can be performed by pushing a button on the screen of the secondary smartphone for for instance 10 seconds, and if the mission is abandoned the other categories of rescue resources receive a message to abandon mission.

4. System according to any of claims 1-3, and comprising an algorithm that prioritizes potential volunteers in shortest distance to scene of accident, as described: first priority group stakeholders will receive a digital message from the external server (20): >>A person has fallen into the water within 600 meters from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone), and if the question is not responded to by the stakeholder or the answer is not received by the external server (10) within for instance 12 seconds it will be taken as a NO, and in case that less than six potential volunteers have replied YES or the answer has not been received by the external server within the 12 seconds, then the second priority group will receive a digital message from the external server: >>A person has fallen into the water within 1150 meters from your location, are you able to assist?<< (potential volunteer is asked to prompt YES or NO on the secondary smartphone), and if the question is not responded to by the stakeholder or the answer is not received by the external server within (new) 12 seconds it will be taken as a NO, and in case that less than 6 stakeholders in total, amongst first and second priority group have replied YES or their answer has not been received by the external server within the timeframe of in total 24 seconds from start of first digital message, then the third priority group will receive a digital message from the external server: >>A person has fallen into the water within 1650 meters from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone), and if question is not responded to by the stakeholder or the answer is not received by the external server within (new) 10 seconds it will be taken as a NO, and in case that less than 6 stakeholders in total amongst the first, second, and third priority group have replied YES or their answer has not been received by the external server (10) within the 10 seconds (total 34 seconds from start of first digital message), then the fourth priority group will receive a digital message from the external server: >>A person has fallen into the water within 2 kilometres from your location, are you able to assist?<< (stakeholder is asked to prompt YES or NO on the secondary smartphone), and if the question is not responded to by the stakeholder or the answer is not received by the external server within (new) 20 seconds it will be taken as a NO and session on the secondary smartphones will end.

5. System according to any of claims 1 to 4, wherein up to six volunteers are guided to the scene of accident and are guided to what to do when approaching in the following way: If a stakeholder volunteers to help, by responding YES on the secondary smartphone (22), when being notified that a person has fallen into the water then four steps are being initiated: Step 1) a map showing the location of the accident and the calculated nearest walking route from where the stakeholder is at that moment (route can be changed to bike- or car route), is immediately being established by data received from the external server (10) by the secondary smartphone (22), the route and ETA to the scene of accident along with elapsed time from when the person fell into the water, is shown on the secondary smartphone (22) screen; Step 2) When the stakeholder is approaching for instance 30 meters from the location of where accident was reported, additional data is forwarded from the external server (10) to the secondary smartphone (22) which will initiate that the route map mentioned in step 1 will change to the name of the person owning the primary smartphone (21) and will be shown on the screen along with other possible information such as for instance height, weight and age, and the location of nearby rescue equipment (15) is being shown on the screen, such as nearby lifebuoys and / or nearby rescue ladder(s), and thereafter a verbal message on the secondary smartphone (22) (in national language if nothing pre-selected), is being initiated and will be rolling until next step: >>you are helping (e.g. Peter) please do shout out the name when approaching, and also start to locate the rescue equipment, but continue towards the site of the accident<<; and Step 3) when the stakeholder is within for instance 5 meters from the location of where the accident was reported, additional data is forwarded by the external server (10) to the secondary smartphone (22) which will initiate that the verbal message mentioned in step 2, is abandoned along with the screen that was showing route, personal data, and rescue equipment closes, and the screen will now show the map of the present site, pointing out the location of where the primary smartphone (21) was triggered by the accident, showing nearest located lifebuoy (15) and rescue hook or rescue ladder, and on the same map, the forecasted drift direction (36-38) of the person in the water and estimated drift distance will be shown based on the data submitted from the external server with forecasted water current (speed and direction), where the system will combine this information with the already running elapsed time from detected fall into water (this elapsed time, as mentioned in step 1, was at that point submitted from the external server to the secondary smartphone), and a new verbal message on the secondary smartphone (in national language if nothing pre-selected), is also initiated: >>If you are first person arriving at site or alone, shout out continuously: "HELP; A PERSON HAS FALLEN INTO THE WATER" and look from this place to the water in the drifting direction, and if you arrive and there are more persons at the site you will together decide to move out from the fall site generally in the direction of the drift / downstream, and it is further decided that one person should call the public emergency number, and on one person that is running for lifebuoy / rescue pole«, wherein the verbal message is repeated twice and then a new verbal message is initiated: »If you see the person located in the water, then throw a lifebuoy or anything else for buoyancy and if the device has a strap keep control of the line so the person can be pulled towards you, and if the person is brought on dry land then commence first aid and / or provide other assistance, and do not leave until public emergency responders take over<<; Step 4) when public emergency responders arrive at scene, or in the event that public emergency responders are already at accident site when stakeholder arrives in step 3, or in the event that the person owning the primary smartphone (21) is at site within a perimeter of for instance 20 meters, confirming that it was a no-critical alert then the stakeholder can activate a dismiss signal on the secondary smartphone which will be transmitted to the external server (10) by pushing a button on the screen and holding it for 10 seconds, which will initiate a verbal message on the secondary smartphone (in national language if nothing pre-selected) >>You are now cancelling the alert triggered by (name of the primary smartphone owner), please confirm by holding the button for another 5 seconds, and if it is a "false alarm" and only secondary smartphone responders have arrived at the site but no public emergency responders is at the site, then also contact public emergency board by phone<<, and once the 10 second abandon mission signal has been received by the external server, it will send a abandon mission signal to any secondary smartphones (22) that has been notified on the specific event, and the screen of each triggered secondary smartphone (22) will show >>rescue notification aborted« and also a verbal message on the secondary smartphone (22) (in national language if nothing pre-selected) is initiated: »The fall into water alert has been aborted and no further assistance is needed. Thank you for helping<<, and the external server (10) also sends an abandon mission notification as SMS and or MMS to the public alarm board, that text message would contain sentences that: >>message was generated from an automatic drowning alert system first triggered at (time) at (location) for (name of owner of the primary smartphone)..., mission actively aborted at (time) by a person at site (name on owner of secondary smartphone that sent the abandon mission signal)..., with the cell phone number..., that alerted community have been informed..., and that automatically operated rescue equipment has received mission aborted signal<<, and the external server also sends an abort mission signal to the IP address for the local rescue devices (15 and 35) that have been involved in the mission.

6. System according to any of claims 1-5, wherein the name of the person that has fallen to water is being shown on the secondary smartphones (22) and persons are requested to shout out the name when approaching the scene of accident.

7. System according to any of claims 1 to 6, wherein if a risk of drowning notification is validated to be real by the algorithm, external server (10) transmits a start mission message to relevant i) local fixed rescue equipment (15) or to ii) remotely operated or autonomously operated rescue equipment (35), wherein the local fixed rescue equipment receives a start mission signal that is being repeated every 10 sec until the mission is called off by the external server by transmitting an abort mission signal, and said local fixed rescue equipment (15) will only receive the command from the external server (30) if within a radius of for instance 75 meters from the location of the "potential drowning" accident where the radius of 75 meters is framed as a parallel belt following the rim of the water breaching out for instance 5 meters to dry side of the said rim and for instance 10 meters to the wet side of said rim, and the remotely or autonomously operated rescue equipment (35) will be receiving a timestamped start mission trigger signal by the external server (30) if the equipment installation point is within a radius of for instance 600 meters from the location of the "potential drowning" accident, and the start mission trigger signal will be repeated every 10 seconds from the external server (30) until mission is later called off by the external server when sending an abandon mission signal to the involved equipment, and the equipment will receive a timestamped first GPS position of accident including geofence coordinates, sent by the external server (30) that setup the frames for allowed mission zone, and the starting radius will be 20 meters from the location of the accident, and besides the first radius setting, the geofencing will be bordered by any rim of the water (only operating above open water), and followed by first geofence notification, the autonomous equipment (35) will receive dynamic timestamped GPS geofence coordinates every 60 seconds that set up adjusted borders for the allowed mission zone, so as to allow the perimeter in the forecasted drift direction to be expanded in line with the estimated drift distance (36-38) based on current data (39) and elapsed time, and by the end of mission the external server (30) sends an abort mission signal to the equipment.

8. System according to any of claims 5 to 7, wherein the system besides the first geo location also comprises a variable search area (36-38), which estimates the location of person in water, and this is calculated, based on time since the fall was triggered and available current data for the specific area (39).

9. System according to any of claims 5 to 8, wherein the external server is connected to a national or regional forecast website similar to e.g. "windy.com", so as to obtain forecasted and in some places, live updated current data, which is to be used, for calculation of adjustments of the dynamic border, which is expanded in the direction of the current, to ensure search is also done in the area, where the person in water could have drifted to.

10. System according to any of claims 1-9, wherein it comprises a training and testing regime, and smartphone owners are prompted as a minimum 1 time per month to participate, and to ensure accuracy of the fall and location equipment and that persons know how the alarm sounds and how / when to mute, the following is being tested: 1) accuracy of the GPS location compared with the map when standing close to any water rim, and the result will be logged; 2) Test of accelerometer by simulating a fall or by informing app when asked on the screen; 3) test of app, which can be performed in partnership with more smartphones, where one acts as primary smartphone and the rest act as secondary smartphones, and the test be performed by submitting to relevant persons and each will get a code to enable the app to open a test environment, and from here a scenario can be played by persons, without sending "distress signals" to any other equipment outside of the test environment.

Images