Patent Description:
While it is possible to locate users on land with a high level of accuracy, this is thanks to the benefit of multiple systems that work together to triangulate location, such as Global Positioning System (GPS), mobile cell towers, and additional sensors. This level of accuracy cannot be achieved off-shore because these systems do not exist off-shore. In order to have their locations tracked, larger water vessels have dedicated location technology that triggers a location to be sent via satellite to a tracking tool periodically. However, these location tracking mechanisms are computationally and practically expensive, and thus locations are sent infrequently (e.g., every <NUM> minutes). Moreover, smaller water vessels typically do not have dedicated tracking technology due to their expense. This results in a hampered ability to find users who may be in distress, thus resulting in failed rescue efforts where a distressed mariner cannot be found.

In modern times, most people, including mariners on board a water vessel, carry mobile phones that are capable of determining and transmitting location information when within cell phone range (e.g., within twenty miles from shore). However, when rescue is needed, even if a water vessel is within cell phone range, a mariner does not know how to contact an agency responsible for rescuing distressed mariners (e.g., the United States Coast Guard). This is because, unlike land rescue, where dialing <NUM> in the United States (and similar numbers globally) is well known to connect a user to a local law enforcement agency, there is no established system for water rescue. This lack of infrastructure additionally contributes to failed rescue efforts for distressed mariners. Even if a distressed mariner could figure out how to connect to a rescue agency, the rescue agency may have no means of locating the mariner because the rescue agency may have no means of acquiring the mariner's location. Moreover, the mariner may leave communications coverage (e.g., as a current carries the water vessel out of range), leaving the rescue agency with no recourse to contact the mariner.

<CIT> (CLAWSON JEFFREY discloses systems and methods to guide an emergency dispatcher in responding to emergency communications. The systems and methods allow the dispatcher to use one or more of a plurality of communication methods to communicate with a person needing assistance, e.g. SMS/MMS messages.

To address and overcome the aforementioned problems, the present invention provides a method in accordance with method claim <NUM>, corresponding non-transitory computer-readable medium claim <NUM>, and corresponding system claim <NUM>. Further, preferred embodiments of the invention are provided in accordance with dependent claims <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, respectively.

The disclosed embodiments have other advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.

The Figures (FIGS. ) and the following description relate to preferred embodiments by way of illustration only.

A letter after a reference numeral, such as "120a" indicates the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as "<NUM>" refers to any or all of the elements in the figures bearing that reference numeral (e.g., "<NUM>" in the text refers to reference numerals "120a" and/or "120b" in the figures). The term "real-time" in the text is used merely for convenience, and could encompass substantially real-time (i.e., within a threshold amount of time of the event occurring).

In an example, a dedicated number for receiving a simple message service (SMS) message from a distressed mariner (e.g., "<NUM>") may be used to initiate rescue proceedings for the mariner. SMS messages are useful in such situations because they require less data than other forms of communication and can be successfully transmitted and received even with a poor connection. An authorization link may be sent by a rescue agency in an SMS message responsive to a distress message, the authorization link enabling location sharing from the mariner's mobile device, even where a poor connection exists. Where location sharing ends because a mariner goes dark (e.g., boat of the distressed mariner drifts out of a communication range or the mariner's device fails), the systems and methods disclosed herein are able to find the right rescue agency, and to predict where the boat may be based on the location data points already received from the distressed mariner and perhaps other environmental factors (e.g., current and weather information).

One example of a disclosed system, method and computer readable storage medium includes enabling accurate estimation of a location of a water vessel. The rescue system transmits a Short Message Service (SMS) message to a user device on the water vessel, the SMS message including a selectable option that, when selected, causes a location of the user device to be shared. Based on a selection by a user of the user device of the selectable option, the system receives a plurality of location coordinates from the user device at a plurality of respective times, each respective location coordinate describing a respective location of the user device at its respective time. The system computes an estimated location of the water vessel based on the plurality of location coordinates and an elapsed time between a current time and a time at which a last-received location coordinate was received. The system transmits the estimated location to a responder device.

In an embodiment of the disclosed system, method and computer readable storage medium includes enabling assignment of a responder unit to a user on a water vessel. The rescue system transmits a Short Message Service (SMS) message to a user device on the water vessel, the SMS message comprising a selectable option that, when selected, causes a location of the user device to be shared. Based on a selection by a user of the user device of the selectable option, the system receives a plurality of location coordinates from the user device at a plurality of respective times, each respective location coordinate describing a respective location of the user device at its respective time. The system selects a responder unit to assign to the user based on the plurality of location coordinates and a location of each of a plurality of candidate responder units. The system transmits location information to a responder device of the selected responder unit, the location information based on the plurality of location coordinates.

Figure (<FIG> illustrates one embodiment of a network environment for components of a rescue system. Environment <NUM> includes user device <NUM>, network <NUM>, responder devices <NUM>, and rescue system <NUM>. The user device <NUM> and responder devices <NUM> may be referred to as client devices. Though there is only one user device <NUM> and two responder devices 120a and 120b shown in <FIG>, other embodiments may use a different number of client devices of either type. These various components are now described in additional detail.

User device <NUM> is a client device of a user of a water vessel. A water vessel refers to any vehicle used in water capable of transporting one or more persons. A water vessel may be engine powered (e.g., motorboat), may be propelled partly or entirely by sails (e.g., sailboat), or unpowered or man-powered (e.g., raft, kayak, etc.). Responder device <NUM> is a client device associated with a responder unit. A responder unit refers to an organized group of persons (e.g., first responders trained to respond to an emergency) which services a particular area (e.g., different coast guard stations). The term client device refers to a computing device such as a mobile phone (e.g., cellular phone, smartphone), tablet, laptop, computer, or any other device that can interact with the rescue system <NUM> over network <NUM> consistent with the interactions described herein for the type of the client device.

Network <NUM> may be any suitable communications network for data transmission. In an embodiment such as that illustrated in <FIG>, network <NUM> uses standard communications technologies and/or protocols and can include the Internet. In another embodiment, the entities use custom and/or dedicated data communications technologies. Network <NUM> connects user device <NUM> and responder devices <NUM> (or any number of client devices, in other embodiments) to the rescue system <NUM> such that the user device <NUM>, the responder devices <NUM>, and rescue system <NUM> can transmit data back and forth. Although not shown, the network <NUM> may also connect any other third party device that may transmit information to the rescue system <NUM> which could be used by the rescue system <NUM> in relation to the user device <NUM> and the responder device <NUM>. For example, a third party device may transmit user information (e.g., phone number, etc.) associated with the user of the user device <NUM>, or additional information about the current environmental conditions surrounding the user device <NUM> or about location information of the user device <NUM> to help location estimation.

Rescue system <NUM> facilitates activity relating to accurately estimating a location of the user device <NUM> on the water vessel and assigning a responder unit of a responder device to the user of the user device. Further details relating to such activities are described throughout with reference to <FIG> below.

<FIG> illustrates one embodiment of modules and a database used by a rescue system. Rescue system <NUM> includes I/O interface module <NUM>, the user interface manager module <NUM>, scheduler module <NUM>, location estimator module <NUM>, machine learning module <NUM>, drone manager module <NUM>, assignment manager module <NUM>, and data store <NUM>. The modules and databases depicted with respect to rescue system <NUM> are merely exemplary; fewer or more modules or databases may be used to effect the processes described herein.

The I/O (input/output) interface module <NUM> interfaces with the network to communicate with the user device <NUM> and the responder devices <NUM>. The I/O interface <NUM> module transmits information to and receives information from the client devices. The information may be a Short Message Service (SMS) message, a plurality of location coordinates from client devices, a web page from the rescue system <NUM>, or instructions for a drone.

The user interface manager module <NUM> generates information for display on a client device. The information may be information in an SMS message (e.g., <FIG>) or a web page (e.g., <FIG>) for display on a user device <NUM>. The information may be information in a web page for display on a responder device <NUM> (e.g., <FIG>).

The scheduler module <NUM> schedules when an estimated location should be computed. For example, where a location of a water vessel is received due to a user sharing a location of their mobile device, there is no need to estimate a location because an actual location is received. However, if the data connection lapses for some time, the location of the water vessel may need to be estimated. The scheduler module <NUM> may compute an elapsed time between a current time and a time at which a last-received location coordinate was received by the rescue system <NUM>. If the elapsed time exceeds a threshold amount of time, the scheduler module <NUM> may trigger the location estimator module <NUM> to estimate a location of the user device <NUM>. The threshold time indicates when an updated estimated location of the water vessel should be computed. The threshold time may be a predetermined setting. For example, it may be a typical situation that a user device <NUM> begins transmitting its location information in real-time or substantially real-time (e.g., every few seconds), and the threshold time may be set to a small interval (e.g., couple of seconds, a minute) as a default setting.

In some examples, the scheduler module <NUM> may determine a threshold time based on a frequency of receiving the location coordinates. For example, the rescue system <NUM> may be programmed to estimate and provide an updated location responsive to determining that the user device <NUM> has stopped transmitting location information. In one scenario, a mobile device of a user may be programmed to share its location information responsive to detecting a movement or change in location of a boat. The boat may be disabled and in an area without much current or wind so the boat location does not change frequently. In this scenario, the mobile device would be sharing its location less frequently, and the scheduler module <NUM> may determine a threshold time based on the frequency that location information is received (e.g., if receiving location information once every ten minutes, set threshold time to a time greater than ten minutes). However, if wind or current has picked up and causes the boat to move at a moderate pace, the mobile device begins transmitting location information more frequently, but less than real-time. In this scenario, the scheduler <NUM> may adjust the threshold time according to the updated frequency of receiving location information (e.g., if receiving location information once a minute, set threshold time to be greater or equal to one minute). Continuing with this example, a determined threshold time may be one minute. The rescue system <NUM> may receive location coordinates at <NUM>:<NUM> pm, <NUM>:<NUM> pm,. to <NUM>:<NUM> pm, and then not receive additional location coordinates. At <NUM>:<NUM> pm, the scheduler module <NUM> determines an elapsed time as being <NUM> minutes (current time <NUM>:<NUM> pm minus the last received message at <NUM>:<NUM> pm) and triggers the location estimator module <NUM> to compute an estimated location of the user device <NUM> as the elapsed time is greater than the one minute threshold time.

In some examples, the scheduler module <NUM> may compute a threshold time based on a determined speed of the water vessel or environmental factors. Environmental factors may include measured data of the environment surrounding the user device <NUM> such as wind or current speed and direction which could affect the motion of a water vessel. In one example, the mobile device of a user on a boat may be transmitting its location coordinates in real-time and suddenly go dark (e.g., stop transmitting its location coordinates). If the boat is disabled (e.g., speed is slow or nonexistent) and there is little wind or current, there may not be a need to immediately estimate an updated location of the boat. The threshold time may be set to a higher value than a few seconds or minutes (e.g., default setting or based on frequency of received location information). The scheduler module <NUM> may determine or adjust the threshold value accordingly. The scheduler module <NUM> may set a threshold time to a higher value for a user device <NUM> on a water vessel with a slower speed than one with a faster speed. Continuing with the example of the disabled boat, if the rescue system <NUM> receives information about environmental factors that a wind or a current speed has increased, there may be a need to estimate a location of the boat sooner than later as it is likely the boat's position has changed. The scheduler module <NUM> may determine or adjust the threshold value accordingly. The scheduler module <NUM> may set a threshold time to a lower value for a user device <NUM> on a water vessel with a higher current or wind speed than one with a lower current or wind speed.

The location estimator module <NUM> estimates a location of the water vessel based on the plurality of location coordinates from the user device <NUM>. The location estimator module <NUM> may determine a speed and a direction of the water vessel from the location coordinates and compute an estimated distance traveled (speed x elapsed time from last-received location coordinate) in the determined direction. The speed and the direction of the water vessel may also be based on one or more environmental factors such as a current (water) speed and direction measurement or a wind speed and direction measurement. For example, the water vessel may drift due to the water current and wind, and an estimated speed of the water vessel may be based on measured current speed/direction and a measured wind speed/direction. The location estimator module <NUM> may input the plurality of location coordinates and/or the one or more environmental factors into a machine learning model <NUM> and receive an estimated location of the water vessel as an output from the machine learning module <NUM>. The location estimator module <NUM> may estimate the location of the water vessel at a current time or at a future time.

In some examples, the location may be estimated by using machine learning. The rescue system <NUM> optionally includes a machine learning model <NUM>. The machine learning model <NUM> may be trained using historical data collected by the rescue system <NUM>. For example, the rescue system <NUM> may have access to historical data due to previous rescue efforts, of received location information from user devices, additional location information, environmental factors, and actual location of user devices after a responder has reached the water vessel. This information can be used to train the machine learning model <NUM> to output a probability that the user device <NUM> is at each of a set of several coordinates (or within a range or radius of a given coordinate). The machine learning module <NUM> may be used by the location estimator module <NUM> to generate a projected location based on inputs such as a plurality of location coordinates from the user device <NUM>, other additional location information, and one or more environmental factors. For example, the output of the machine learning module <NUM> may be a probability that the user device <NUM> is at each of a set of several location coordinates, and the location estimator module <NUM> may use this output to determine an estimated location and an uncertainty radius which indicates a field that the mariner is likely within. The location estimator module <NUM> may select an estimated location coordinate from the set of several location coordinates, the estimated location coordinate having the highest probability among the set, and determine an uncertainty radius based on the corresponding probability (e.g., lower probability would correspond to a higher uncertainty radius).

In some examples, unmanned vehicles (e.g., unmanned aerial or water vehicles, collectively referred to as "drones") may be used to aid rescue efforts, where drones are sent ahead of manned rescue vehicles to confirm a location of a distressed mariner. For example, a drone can go over the scene a broadcast captured images or video from the scene so the responder has more information about the scene. A drone may have infrared sensing capabilities to pick up heat signature of a user in a water vessel to locate the user device <NUM>. The drone can fly by a certain perimeter of the scene to look for an infrared signal, and the drone can transmit a message responsive to finding an infrared signal to indicate the user device <NUM> has been located. The drone manager module <NUM> generates instructions for a drone. The instructions may include to launch a drone to a target destination and to scan a radius from the target destination. The target destination may be an estimated location of the user device <NUM> at a future projected time. For example, the location of the user device <NUM> on a water vessel may change from the time a drone is launched to the time it reaches its target destination. the drone manager module <NUM> may request from the location estimator module <NUM> to estimate a location of the user device <NUM> at a future projected time based on the travel time for a drone to travel to a target destination. The location estimator module <NUM> may predict the location of the user device <NUM> at a future time based on the expected travel time of the drone (e.g., determined by speed, flight path) to reach its destination. The target destination may be a last-received location coordinate of the user device <NUM> or an estimated location of the user device <NUM>. The drone manager module <NUM> may generate additional instructions for a drone to update the target destination as a location of the user device <NUM> as the location changes with time.

In one example, the rescue system <NUM> may receive additional data that indicating the user device <NUM> is within a threshold distance of a mobile cell tower. For example, the mobile cell tower may be a created cell tower on a responder water vessel. The created cell tower may indicate to the rescue system <NUM> that the responder water vessel received a ping from a mobile device of the user, and the rescue system <NUM> may determine that the mobile device is within a threshold distance that is the reach of the created cell tower. The created cell tower may have additional information, such as a signal strength of the mobile device to the created cell tower. In this scenario, the rescue system <NUM> may determine the mobile device to be within a threshold distance based on the signal strength (e.g., stronger signal strength indicates mobile device is closer to created cell tower). The drone manager module <NUM> may generate instructions to launch a drone to the location of the mobile cell tower and for the drone to scan an area within the threshold distance of the mobile cell tower.

The assignment manager module <NUM> assigns a responder unit of a responder device <NUM> to a user of the user device <NUM>. The assignment manager module <NUM> selects the responder unit to assign to the user based on the plurality of location coordinates from the user device <NUM> and a location of each of a plurality of candidate responder unit. The location of the candidate responder unit may be based on a fixed address of a corresponding headquarters of the responder unit. The location of the candidate responder unit may be based on received location coordinates from a corresponding responder device <NUM> of the candidate responder unit. For example, the assignment manager module <NUM> may select the responder unit closest to the location coordinates of the user device <NUM> based either on the location of the responder unit's headquarters or a received location from a responder device <NUM> (e.g., mobile phone of a first responder on duty) of the responder unit. The assignment manager module <NUM> may store an association of the user device <NUM> and the assigned responder device <NUM> in the data store <NUM>. The assignment manager module <NUM> may establish a communication channel between the responder device to the user device. Responsive to the rescue system <NUM> receiving future communications from the user device <NUM>, the assignment manager module <NUM> may reestablish the communication channel to the responder device <NUM> based on the association. In one embodiment, the assignment manager module <NUM> may assign a responder unit to a user based on location information (e.g., entered location coordinates, city and/or state, proximity to a known location, etc.) provided from a user of the user device <NUM> from SMS messages, text input in a textbox on a mobile browser, or from oral responses of a user from a phone call, etc..

The data store <NUM> stores information used by the rescue system <NUM>. The information may include a plurality of responder units, corresponding addresses, and corresponding phone numbers or virtual addresses for communicating with devices or accounts of responders and/or responder units. The information may include an association between the user device <NUM> and a responder device <NUM> of a selected responder unit.

<FIG> illustrates one embodiment of modules and database used by a user device. User device <NUM> includes I/O interface module <NUM>, the user interface manager module <NUM>, settings manager module <NUM>, sensors <NUM>, location manager module <NUM>, and data store <NUM>. The modules and databases depicted with respect to user device <NUM> are merely exemplary; fewer or more modules or databases may be used to effect the processes described herein.

The I/O interface module <NUM> interfaces with the network <NUM> to communicate with the rescue system <NUM> and optionally the responder device <NUM>. The I/O interface module <NUM> can transmit information to and receive information from the rescue system <NUM> and the responder device <NUM>. The information may be a Short Message Service (SMS) message, a plurality of location coordinates from the user device <NUM>, or a web page from the rescue system <NUM>.

The user interface manager module <NUM> presents information on the user device <NUM>. In some embodiments, the user interface manager module <NUM> presents on a user device <NUM> an SMS message from the rescue system <NUM> with a selectable option requesting the user to share a location of the user device <NUM>. For example, a mariner is in distress and texts a message "SOS" on his mobile device to a number (e.g., "<NUM>"), and the rescue system <NUM> transmits the SMS to the mobile phone of the mariner. In some embodiments, the user interface module <NUM> presents an interface of a pre-installed application which includes a selectable option to share a location of the user. For example, prior to a mariner embarking on a water journey, the mariner installed an application his mobile device to use in the event he needs help on the water. The mariner launches the pre-installed an application once he is in distress, and the application interface includes a location share or distress button for the mariner to share his location. The user interface manager module <NUM> may present on a user device <NUM> a website of the rescue system <NUM>. The website may include a graphical representation of the coast guard emblem.

The settings manager module <NUM> manages the settings for the user device <NUM>. The settings manager module <NUM> may update a setting for the user device <NUM> to share location information responsive to a user selecting an option to share a location of the user device <NUM>. The settings manager module <NUM> may enable a setting for the user device <NUM> to continually transmit location information, regardless of whether a confirmation response is received. The settings manager module <NUM> may enable a setting for the user device <NUM> to transmit location information responsive to the user device <NUM> determining a location of the user device <NUM> has changed (e.g., via the location manager <NUM>). The settings manager module <NUM> may update a setting for the user device <NUM> to stop sharing location information responsive to a user selecting an option to stop sharing a location of the user device <NUM>.

The sensors <NUM> detect at least one of motion, an environmental condition, position, or some combination thereof. The sensors <NUM> may include a motion sensor to detect motion, rotation, or acceleration. Examples of a motion sensor are an accelerometer, gravity sensor, gyroscope, or rotational vector sensors. The sensors <NUM> may include an environmental sensor to measure air pressure changes, humidity, temperature, etc. Examples of an environmental sensor are a barometer, photometer, or thermometer. The sensors <NUM> may include a position sensor such as a magnetometer to measure orientation of the device (e.g., true North). The user device <NUM> may transmit data captured by the sensors <NUM> (in addition to its location information) to the rescue system <NUM> when a share location option is selected by the user on the user device <NUM>. The transmitted data captured from the sensors <NUM> can be used by the rescue system <NUM> as environmental factors (e.g., input to machine learning model, scheduling estimated location updates, estimating location).

The location manager module <NUM> determines a location of the user device <NUM>. The location manager may determine a location of the user device using any location mechanisms available to the user device <NUM> such as GPS, Assisted GPS (AGPS), Wi-Fi, and cellular location. The location manager module <NUM> may use a network infrastructure of the user device <NUM> to determine the location of the user device <NUM>. For example, the user device <NUM> may be a mobile phone which sends signals to nearby cell towers that can be used to triangulate the location of the mobile phone. The location manager module <NUM> may use GPS to determine the location of the user device <NUM>. For example, if a mobile phone is equipped with GPS it can connect with GPS satellites to determine its location. The location manager module <NUM> may also determine the location using information from the sensors <NUM>.

The data store <NUM> stores information for the user device <NUM>. This information may include device settings of the user device <NUM>.

<FIG> illustrates one embodiment of modules and database used by a responder device. Responder device <NUM> includes I/O interface module <NUM>, the user interface manager module <NUM>, location manager module <NUM>, sensors <NUM>, and data store <NUM>. The data store <NUM> stores information used by the responder device <NUM>. The modules and databases depicted with respect to responder device <NUM> are merely exemplary; fewer or more modules or databases may be used to effect the processes described herein.

The I/O interface module <NUM> interfaces with the network <NUM> to communicate with the rescue system <NUM> and optionally the user device <NUM>. The I/O interface module <NUM> can transmit information to and receive information from the rescue system <NUM> and the user device <NUM>. The information may be a Short Message Service (SMS) message, a plurality of location coordinates from the user device <NUM>, a plurality of location coordinates from the responder device <NUM>, a web page from the rescue system <NUM>, or instructions for a drone.

The user interface manager module <NUM> presents information on the responder device <NUM>. The user interface module <NUM> may be similar to the user interface module <NUM> except it is for a responder device <NUM>.

The location manager module <NUM> determines a location of the responder device <NUM>. The location manager module <NUM> may be similar to the location manager module <NUM> of the user device <NUM> except it is for the responder device <NUM>.

The responder device <NUM> may include sensors <NUM>. In one example, the responder device <NUM> is a mobile phone, the sensors <NUM> are similar to the sensors <NUM> of the user device <NUM> except they are for the responder device <NUM>.

<FIG> is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller). Specifically, <FIG> shows a diagrammatic representation of a machine in the example form of a computer system <NUM> within which program code (e.g., software) for causing the machine to perform any one or more of the methodologies discussed herein may be executed. The program code may be comprised of instructions <NUM> executable by one or more processors <NUM>. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions <NUM> (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute instructions <NUM> to perform any one or more of the methodologies discussed herein.

The example computer system <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these), a main memory <NUM>, and a static memory <NUM>, which are configured to communicate with each other via a bus <NUM>. The computer system <NUM> may further include visual display interface <NUM>. The visual interface may include a software driver that enables displaying user interfaces on a screen (or display). The visual interface may display user interfaces directly (e.g., on the screen) or indirectly on a surface, window, or the like (e.g., via a visual projection unit). For ease of discussion the visual interface may be described as a screen. The visual interface <NUM> may include or may interface with a touch enabled screen. The computer system <NUM> may also include alphanumeric input device <NUM> (e.g., a keyboard or touch screen keyboard), a cursor control device <NUM> (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit <NUM>, a signal generation device <NUM> (e.g., a speaker), and a network interface device <NUM>, which also are configured to communicate via the bus <NUM>.

The storage unit <NUM> includes a machine-readable medium <NUM> on which is stored instructions <NUM> (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions <NUM> (e.g., software) may also reside, completely or at least partially, within the main memory <NUM> or within the processor <NUM> (e.g., within a processor's cache memory) during execution thereof by the computer system <NUM>, the main memory <NUM> and the processor <NUM> also constituting machine-readable media. The instructions <NUM> (e.g., software) may be transmitted or received over a network <NUM> via the network interface device <NUM>.

While machine-readable medium <NUM> is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions (e.g., instructions <NUM>). The term "machine-readable medium" shall also be taken to include any medium that is capable of storing instructions (e.g., instructions <NUM>) for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term "machine-readable medium" includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

The above-described components of the rescue system <NUM> enable a system to accurately estimate a location of a water vessel. In one example, the responder is made aware that a water vessel is in distress and obtains a phone number of a person on the water vessel. For example, a responder receives a notification that a person (e.g., user associated with a user device) on a water vessel is in distress (e.g., phone call from the user or from friends or family of the user). The responder navigates to a website of the rescue system <NUM> via a responder device <NUM> and logs in to the website of the rescue system <NUM> with credentials (e.g., email and password). The rescue system <NUM> transmits, to the responder device <NUM>, instructions to display a request for a phone number of the user in distress along with a selectable option to locate the device associated with the phone number of the user. The responder device <NUM> may present the request in a web browser as a web page including a single input field for a mobile phone number along with a locate button in a user interface. The responder can enter the user's phone number into the field and press the locate button on the user interface of the responder device <NUM>. Responsive to the rescue system <NUM> receiving the user's phone number from the responder device <NUM>, the rescue system <NUM> transmits an SMS message for display on the user device <NUM> of the user from a <NUM>-digit short code or <NUM>-digit long code. In a different example, the SMS message may be transmitted responsive to a user's direct request for help to the rescue system <NUM> (e.g., user texts "SOS" to a rescue number such as "<NUM>"). For example, the water vessel may have a reflective sticker by the steering wheel on the water vessel indicating that in case of an emergency, tune to a particular VHF channel or text <NUM>. In another example, the SMS message may be transmitted responsive to the rescue system <NUM> determining the user may need assistance based on earlier received information about the user. For example, the user pre-registers his phone number with a rental boat company for a scheduled time, and the information is received by the rescue system <NUM> (e.g., information is sent by the boat company or user device <NUM>). The rescue system <NUM> may determine that the user does not return the rental boat on time and automatically transmit the SMS message to the user's mobile device to ask if the user is ok, and if not, to select a link (e.g., launch web page, to share location). The use of an SMS message is non-limiting, and the rescue system <NUM> may communicate this information with the user device <NUM> by other means, such as email, data messaging systems, or other applications, etc..

<FIG> depicts a process for enabling accurate estimation of a location of a water vessel, in accordance with an embodiment. Process <NUM> begins with rescue system <NUM> transmitting <NUM> an SMS message to a user device <NUM> on a water vessel, the SMS message comprising a selectable option that, when selected, causes a location of the user device <NUM> to be shared. For example, the user device <NUM> is a mobile phone, and the SMS message includes a link to launch a URL in a mobile browser. After tapping the link, the user may be presented with an additional prompt by a mobile browser of the user device <NUM> to consent to share device location. In some instances, the user may have disabled GPS or Location Services on their mobile device. The rescue system <NUM> detects the operating system (such as iOS or Android) via the website and transmits tailored instructions on how to enable location services on their particular user device <NUM>. In some embodiments, GPS cannot be obtained from the phone (e.g., because the user does not enable location services), and the rescue system <NUM> may transmit instructions to the user device <NUM> for the user on how to enable GPS.

Based on a selection by a user of the user device <NUM> of the selectable option, the rescue system <NUM> receives <NUM> a plurality of location coordinates from the user device <NUM> at a plurality of respective times, each respective location coordinate describing a respective location of the user device <NUM> at its respective time. For example, after the user selects an option on the mobile browser of the user device <NUM> to allow the rescue system <NUM> to access the current location of the user device <NUM>, the user device <NUM> transmits the location coordinates to the rescue system <NUM>. The user device <NUM> may utilize all available location mechanisms available to it, such as GPS, AGPS, Wi-Fi, and cellular location to determine the location coordinates. The user device <NUM> may establish a web socket connection between the user's mobile browser of the user device <NUM> and the rescue system <NUM>. The user device <NUM> may transmit location information in real-time (or near real-time) to the rescue system <NUM>, or the user device <NUM> may transmit location coordinates when the user device <NUM> detects a change in position (e.g., multiple times per second, every few seconds, minutes, etc. when movement is detected by user device <NUM>). The rescue system <NUM> receives the location coordinates from the user device <NUM> and may transmit the location coordinates to the responder device <NUM> to allow the responder to observe the real-time movement of the water vessel.

The rescue system <NUM> computes <NUM>, an estimated location of the water vessel based on the plurality of location coordinates and an elapsed time between a current time and a time at which a last-received location coordinate was received. The rescue system <NUM> may determine the user device <NUM> has stopped transmitting location coordinates for more than a threshold period of time, and estimate a location of the user device <NUM> at a current time.

The rescue system <NUM> transmits <NUM> the estimated location to a responder device <NUM>. The rescue system <NUM> may include instructions for displaying the estimated location on a map of a user interface on a responder device <NUM>.

The above-described components of the rescue system <NUM> enable assignment of a water vessel to a responder unit. In one example, the user device <NUM> may have transmitted a distress SMS message (e.g., text to "<NUM>") comprising a payload including a symbol predefined as corresponding to a request for help (e.g., "SOS"). Responsive to receiving the distress SMS message from the user device <NUM>, the rescue system <NUM> transmits an SMS for display on the user device <NUM> of the user from a <NUM>-digit short code (e.g., "<NUM>") or <NUM>-digit long code. In some embodiments, the rescue system <NUM> may give the user an input option (e.g., launch text box in a mobile browser, or in SMS text) so that the user can input their location information and/or other information. The user may describe their location, for example, in the text box and submit the location information (e.g., hit send) to the responder device. The location information input from the user can be a latitude and longitude from the boat (e.g., user may enter in location coordinates from another GPS device on the water vessel), a descriptive indicator (e.g., ten miles west from a particular known geographical location). The user device <NUM> may be presented with a two way chat option to call a responder device <NUM> (e.g., a particular coast guard station, or a responder of a responder device <NUM>), the two-way chat option including a text box for free-form typing. The responder device <NUM> may reply to the user device <NUM> that they received the location of the user, and that they are responding to the call or will be there in an estimated time. In some embodiments, the user may call or text a phone number to request help. The user may be presented by the rescue system <NUM> with a series of prompts or questions from a phone call or through text messaging, such as requesting the state that the user is closest to on the water vessel, and subsequently requesting the city that the user is closest to on his water vessel. These series of prompts/questions may provide information to narrow down which responder unit the user is closest to, and match the user device <NUM> to a responder unit (e.g., particular coast guard station, responder of a responder device). For example, the United States Coast Guard has different sector commands that covers different territories. The information provided by the user, such as a state and/or a city, may be enough information to locate the closest United States Coast Guard sector, to connect the user to the appropriate responder unit. In an embodiment, where the user device <NUM> calls a responder device <NUM>, the responder device <NUM> may automatically detect an address (e.g., phone number) of user device <NUM> and may transmit an SMS message to the user device <NUM> that includes a prompt to share location with the responder device <NUM>.

<FIG> depicts a process for enabling assignment of a responder unit to a user on a water vessel, in accordance with an embodiment. Process <NUM> begins with rescue system <NUM> transmitting <NUM> an SMS message to a user device <NUM> on a water vessel, the SMS message comprising a selectable option that, when selected, causes a location of the user device <NUM> to be shared. Based on a selection by a user of the user device <NUM> of the selectable option, the rescue system <NUM> receives <NUM> a plurality of location coordinates from the user device at a plurality of respective times, each respective location coordinate describing a respective location of the user device at its respective time. The rescue system <NUM> selects <NUM>, a responder unit to assign to the user based on the plurality of location coordinates and a location of each of a plurality of candidate responder units. The rescue system <NUM> transmits <NUM> location information to a responder device <NUM> of the selected responder unit, the location information based on the plurality of location coordinates. The location information may be the plurality of location coordinates from the user device <NUM> or at least one of the plurality of location coordinates from the user device <NUM> (e.g., a last received location coordinate). The location information may be an estimated location of the user device <NUM>. The rescue system <NUM> may determine the user device <NUM> has stopped transmitting location coordinates for more than a threshold period of time, and estimate a location of the user device <NUM> at a current time.

Responsive to the responder unit being assigned, the rescue system <NUM> may send a predetermined message to the user on behalf of the responder unit (e.g., "We've received your location. Help is on the way. " or "Turn your VHF radio to Channel _. ") The rescue system <NUM> may provide a two-way chat interface to the responder over SMS and the user over SMS so the user device <NUM> and the responder device <NUM> can communicate over text. If a cellular voice connection is available, the rescue system <NUM> may provide the user with a link on a web page to dial the assigned responder via phone. The rescue system <NUM> may provide the responder device <NUM> with capability to receive the call via the web browser of the rescue system <NUM> on the responder device <NUM>.

<FIG> depicts a message user interface on a user device, in accordance with an embodiment. The message user interface displays an SMS message on a user device <NUM> which is a mobile phone. The SMS message is from the rescue system <NUM> and includes a selectable option that, when selected, causes a location of the user device <NUM> to be shared. In this example, the selectable option is to open a link to share the user's location. The SMS message may include information such as a report was received that the user may be in distress, and instructions that if the user has a VHF Marine Radio, to tune it to a particular channel.

<FIG> depicts a mobile browser user interface on a user device, in accordance with an embodiment. The mobile browser interface displays a web page of the rescue system <NUM> to the user of the user device <NUM> which is a mobile phone. Continuing with the example of <FIG>, after the user selects (e.g., taps) the link, the user device <NUM> opens a mobile browser and navigates to a web page of the rescue system <NUM>. The mobile browser includes a selectable option to share the user's location (e.g., "Share My Location" button).

<FIG> depicts a pop up user interface on the user device, in accordance with an embodiment. Continuing with the example of <FIG>, after the mobile browser navigates to the web page of the rescue system <NUM> and a user selects the selectable option on the web page, the user device <NUM> may launch a pop up user interface to indicate that the rescue system <NUM> would like access to the current location of the user device <NUM>. In some embodiments, the pop up user interface may automatically launch after the mobile browser navigates to the web page without the user selecting the selectable option on the web page.

<FIG> depicts a user interface on the responder device, in accordance with an embodiment. The user interface may be a web browser of the responder device <NUM> which displays a web page of the rescue system <NUM>. The user interface on the responder device <NUM> includes a map with the estimated location of the user device <NUM> marked on the map. The user interface may also include information on the latest location of the user device <NUM> in a format of Latitude/Longitude, Degrees/Minutes/Seconds (DMS), Decimal Degree Minutes (DDM), an uncertainty radius, information regarding a Date/Time stamp indicating locations as they are received by the rescue system <NUM>, a phone status of the user (e.g., did user tap link to share location, is the user's mobile browser open, etc.), and an estimated location of the user device <NUM>.

The rescue system <NUM> may transmit location coordinates from the user device <NUM> as they are received to the responder device <NUM> to allow real-time update of the location of the user device <NUM> on its user interface. The rescue system <NUM> may enable the responder device <NUM> to display multiple previously transmitted location coordinates from the user device <NUM> (e.g., collected location data), along with an estimated current location of the user device <NUM>.

<FIG> depicts an assignment of a responder unit to a user on a water vessel, in accordance with an embodiment. A boat <NUM> has a passenger that is a user with a user device <NUM>. A user device <NUM> transmits its location coordinates to a rescue system <NUM>. The rescue system <NUM> determines that the location of the user device <NUM> is closer to an address of a responder unit <NUM> than the responder unit <NUM>. The rescue system <NUM> assigns the user to the responder unit <NUM>. The responder unit <NUM> has a corresponding phone number, and the rescue system <NUM> may connect the user directly with a dispatcher of the responder unit <NUM>. In another example, responder devices <NUM> (e.g., mobile phones) are associated respectively with responder units <NUM> and <NUM>. The responder devices <NUM> may transmit location coordinates that are received by the rescue system <NUM> which are used to assign the user in the boat <NUM> to a responder unit based on the received location coordinates of the responder device <NUM> that is closest to the boat <NUM>.

The rescue system <NUM> may enable the responder <NUM> to launch a drone to a location or estimated location of the user device. For example, the rescue system <NUM> may transmit information to a responder device <NUM> to enable a responder to launch a drone. The information may be instructions for a user interface of a responder unit <NUM> to display a selectable option to launch a drone. The drone may be launched from a water vessel (e.g., boat of responder, other water vessel, etc.) or from shore. A technical advantage of being launched from a water vessel is that the drone may have a limited fly time because of battery constraints, and the water vessel may be closer to a location or estimated location of the user device. Moreover, resources in powering the drone are conserved where the responder unit <NUM> does not need to launch the drone (e.g., where the estimated location of the user device is accurate, and where the responder <NUM> thus found the boat <NUM> and did not need to launch the drone).

<FIG> also depicts an example use of a drone. A user device <NUM> in the boat <NUM> (e.g., water vessel) is within a threshold distance of the cell tower <NUM> (e.g., within cell tower range <NUM>). In this example, the user device <NUM> cannot determine its own location coordinates to transmit to the cell tower <NUM>, but the rescue system <NUM> determines that the user device <NUM> is within the threshold distance of the cell tower <NUM>. The rescue system <NUM> may generate drone instructions for a drone to scan a target area (e.g., cell tower range <NUM>, or a radius from the location of the cell tower <NUM>) to locate the user device <NUM>. Since a portion of the cell tower range <NUM> is in a water region <NUM> and the boat is in the water region <NUM>, the rescue system <NUM> may further limit the scan area to be an area of the cell tower range <NUM> that overlaps with a water region <NUM>.

In another example, a user device <NUM> in the boat <NUM> may be able to determine its location coordinates and transmit its location coordinates to be received by the rescue system <NUM>. However, the boat <NUM> may later drift out of range of the cell tower <NUM> (e.g., outside cell tower range <NUM>) and the rescue system <NUM> may no longer receive location coordinates transmitted from the user device <NUM>. If the boat <NUM> drifts within a range of a mobile cell tower (e.g., created cell tower of a responder water vessel), the rescue system <NUM> may receive additional data associated with a location of the user device <NUM>. The rescue system <NUM> may determine whether the additional data indicates the location of the user device <NUM> is within a threshold distance of a mobile cell tower of a responder water vessel. Responsive to determining the additional location data is within the threshold distance to the mobile cell tower of the responder water vessel, the rescue system <NUM> may transmit to the responder device <NUM> updated location information. The updated location information may be based on the received additional data which may comprise transmitted location coordinates of the user device <NUM>. The updated location information may be an estimated location based on the received location coordinates of the user device <NUM> and may be additionally based on environmental factors.

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

Accordingly, the term "hardware module" should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented hardware modules. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).

For example, some embodiments may be described using the term "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact.

In addition, use of the "a" or "an" are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

Claim 1:
A method for enabling assignment of a responder unit to a user on a water vessel, the method comprising:
transmitting a Short Message Service, SMS, message to a user device (<NUM>) on the water vessel, the SMS message comprising a selectable option that, when selected, causes a location of the user device to be shared;
based on a selection by a user of the user device of the selectable option, receiving a plurality of location coordinates from the user device at a plurality of respective times, each respective location coordinate describing a respective location of the user device at its respective time;
selecting a responder unit to assign to the user based on the plurality of location coordinates and a location of each of a plurality of candidate responder units; and
transmitting location information to a responder device (<NUM>) of the selected responder unit, the location information based on the plurality of location coordinates.