AND METHODS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Application No. 63/199,062 filed December 4, 2020 and titled “SMART WEARABLE PERSONAL SAFETY SYSTEM AND METHOD,” to U.S. Application No. 63/199,378 filed December 22, 2020 and titled “CLOUD-BASED ARTIFICIAL INTELLIGENCE-DRIVEN SAFETY AND ALERT MECHANISM SYSTEM FOR DETECTING AND/OR PREDICTING POTENTIAL WATER HAZARDS,” to U.S. Application No. 63/201 ,003 filed April 8, 2021 and titled “INTERACTIVE VOICE BASED SAFETY AND ALERT MECHANISM SYSTEM FOR DETECTING AND PREDICTING POTENTIAL HAZARDS DUE TO SIGNIFICANT CHANGES IN AMBIENT TEMPERATURE,” to U.S. Application No. 63/201 ,013 filed April 8, 2021 and titled “INTERACTIVE VOICE BASED SAFETY AND ALERT MECHANISM SYSTEM FOR DETECTING AND PREDICTING POTENTIAL GEO-FENCE BREACH HAZARDS,” and to U.S. Application No. 63/201 ,046 filed April 9, 2021 and titled “INTERACTIVE VOICE BASED SAFETY AND ALERT MECHANISM SYSTEM FOR FALL DETECTION AND REDUCING FALSE-POSITIVE ALERTS.” U.S. Application Nos. 63/199,062, 63/199,378, 63/201 ,003, 63/201 ,013, and 63/201 ,046 are hereby fully incorporated by reference as if set forth fully herein.

FIELD

[0002] The present invention generally relates to smart wearable personal safety devices and related systems and methods. More particularly, such devices, systems and methods can include a wearable artificial intelligence-based system, a smart clothing system, and/or wearables and methods to monitor and potentially prevent unintentional injuries/deaths, track locations, record current physiological conditions, wearer’s vitals in real-time and send timely alerts. Furthermore, such devices, systems, and methods can include a cloud enabled artificial intelligence driven interactive safety and alert mechanism system for detecting and predicting potential hazards due to significant changes in ambient temperature, for fall detection, for detecting and predicting potential geofence breach hazards, and/or for detecting and predicting potential water hazards.

BACKGROUND

[0003] Unintentional causes of injuries and/or deaths of pets, infants, toddlers, kids, and adults are on a rise across the world. There are many causes of these injuries and deaths including accidental drowning, accidental falls, asphyxia (e.g. kid left locked in a car), infant suffocation, hyperthermia, hypothermia, abduction/missing person cases (amber, silver and blue alerts), older aged adults being left alone for prolonged periods of time, kids or pets wandering off unattended, older adults becoming lost because of special medical conditions like dementia. There are at present no current devices, systems, or methods that satisfactorily mitigate these and other potentially dangerous hazards present in the world today.

[0004] For example, in the particular case of known geo-fence devices and systems, these known devices and systems do not keep track of when a wearer has returned to the geo-fenced area or if the wearer is moving towards a known hazardous place such as a road/highway, body of water, ditch, or the like. These known geo-fence devices and systems typically rely solely on a user receiving an alert on their smartphones and/or smart wearable device to inform them that a tracked subject has breached the geo-fence. The user then has to keep the app open at all times to track subject’s whereabouts and there exists no contingency for if the user misses the alert notification, which is highly possible in cases where the user is busy at work, driving, sleeping, the smartphone receiving the alert is not charged, and/or the user does not have the smartphone with them at the time of the alert.

[0005] Furthermore, in the particular case of known wearable devices or systems that track and report a fall, such known devices and systems typically result in a high number of false-positive alerts being transmitted to the authorities if the user is unable to physically touch and respond to a fall alert on the device within a specified interval of time. [0006] Finally, as to the other possible hazards that have led to the increase in unintentionally caused injuries and deaths of pets, infants, toddlers, kids, and adults, either there does not currently exist a corresponding system and method for mitigating the hazard and/or such known systems as may exist suffer from the same or similar defects to those present in the known device and systems for detecting geo-fence breaches and fall hazards.

[0007] In light of the foregoing, there is a clear need for improved hazard detection and mitigation devices, systems, and methods.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1A is a schematic diagram of personal safety alert system according to disclosed embodiments;

[0009] FIG. 1 B is a flow diagram of a method for operating a personal safety alert system according to disclosed embodiments; [0010] FIG. 2 is a perspective view of a smart wearable device according to disclosed embodiments;

[0011] FIG. 3 is a top view of a smart wearable device according to disclosed embodiments;

[0012] FIG. 4 is a bottom view of a smart wearable device according to disclosed embodiments;

[0013] FIGS. 5-7 are side views of a smart wearable device according to disclosed embodiments;

[0014] FIG. 8 shows a smart wearable device integrated into a clothing system according to disclosed embodiments;

[0015] FIG. 9 is a block diagram of personal safety alert system according to disclosed embodiments;

[0016] FIGS. 10-11 are a flow diagram for a water-based hazard detection and alert method according to disclosed embodiments;

[0017] FIGS. 12-13 are a flow diagram for a fall hazard detection and alert method according to disclosed embodiments;

[0018] FIGS. 14-15 are a flow diagram for an ambient temperature hazard detection and alert method according to disclosed embodiments;

[0019] FIGS. 16-18 are a flow diagram for a Geo-fence breach hazard detection and alert method according to disclosed embodiments;

[0020] FIG. 19 is a flow diagram for a Geo-fence Hazard prediction sub-process according to disclosed embodiments; [0021] FIG. 20 is a flow diagram for an artificial intelligence bot sub-process according to disclosed embodiments;

[0022] FIG. 21 is a flow diagram for a wearer condition assessment sub-process; and

[0023] FIGS. 22-24 are renderings of a user interface used in conjunction with a personal safety alert system according to disclosed embodiments.

DETAILED DESCRIPTION OF THE INVENTION

[0024] While this invention is susceptible of an embodiment in many different forms, there are shown in the drawings and will be described herein in detail specific embodiments thereof with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention. It is not intended to limit the invention to the specific illustrated embodiments.

[0025] FIG. 1 A shows a schematic diagram of a hazard detection and mitigation system 100 according to disclosed embodiments. As seen in FIG. 1A, the system 100 can include a wearable device 120 that can detect possible hazards or abnormalities being experienced by a user of the wearable device 120. As seen in FIG. 1A, the wearable device 120 can monitor various hazards or abnormalities including but not limited to a fall hazard, a heart rate hazard, a geo-fence breach, an ambient temperature hazard, an atmospheric pressure hazard, and a water body hazard, among others.

[0026] Furthermore, in some embodiments, the system 100 can include a cloud server 122 that is remote from the wearable device 120 and that can confirm or reject the hazard, monitor the hazard for positive or detrimental changes, solicit feedback from the user of the wearable device 120 to confirm or reject the hazard, and initiate various mitigation measures based on the current severity of the hazard. For example, in some embodiments, the cloud server 122 can send different alert levels to various notification devices 124 and, when the alert level is critical, can send a notification to an emergency provider.

[0027] In some embodiments, the various notification devices 124 can include a registered or primary device that serves as the initial delivery device for alert notifications, and various other secondary devices that receive an alert notification based on the severity of the alert and/or whether a user of the registered device acknowledged the alert notification within a predetermined time limit. For example, in some embodiments, the registered device can include a smartphone or similar device of a primary contact of the user of the wearable device 120 such as a parent or guardian, a spouse, friend, sibling, adult child, etc. Furthermore, the various other secondary devices in the notification devices 124 can include other smartphones or similar devices, various smart speakers, smart assistants, and the like. In some embodiments, one or more of the various other secondary devices in the notification devices 124 can be preconfigured in a memory of the wearable device 120 and/or the cloud server 122. Additionally or alternatively, in some embodiments, one or more of the various other secondary devices in the notification devices 124 can be selected from devices known to the registered device. For example, in some embodiments, the one or more of the various other secondary devices in the notification devices 124 can include smartphones or similar devices saved as contacts in a memory of the registered device or smart devices paired with or connected to the registered device via known wired and wireless methods.

[0028] FIG. 1 B is a flow diagram of a method 102 for operating the system 100 according to disclosed embodiments. As seen in FIG. 1 B, the method 102 can include the wearable device 120 monitoring for one or more abnormal conditions, as in 104. In some embodiments, the wearable device 120 can employ one or more on-device trained artificial intelligence (Al) processes to detect the presence of the one or more abnormal conditions based on data from a plurality of sensors 126 (see FIG. 4 and FIG.

9) electrically connected to the wearable device 120. Additionally or alternatively, in some embodiments, the wearable device 120 can detect a particular abnormal condition from a portion of the data from the plurality of sensors 120 when a value of one of the plurality of sensors 120 is outside a preconfigured threshold.

[0029] In some embodiments, the method 102 can include the wearable device 120 detecting the abnormal condition, the wearable device 120 forwarding the data from each of the plurality of sensors 126 to the cloud server 122, and the wearable device 120 or the cloud server 122 transmitting a level one notification (e.g. an information alert) to the registered device of the notification devices 124 documenting the abnormal condition, as in 106. In some embodiments, the method 102 can include the cloud server 122 soliciting the data in response to receiving an indication of the abnormal condition from the wearable device 120.

[0030] Various embodiments for the abnormal condition monitored by the wearable device 120 are contemplated. For example, in some embodiments the abnormal condition can include one or more of a water-based hazard, an ambient temperature hazard, a fall hazard, and/or a geo-fence breach. Furthermore, in some embodiments, the one of the plurality of sensors 126 that detect the abnormal condition can be different depending on the specific abnormal condition. For example, when the abnormal condition includes the water-based hazard, the one of the plurality of sensors 126 can include a water contact sensor, a humidity sensor, and/or an atmospheric pressure sensor; when the abnormal condition includes the ambient temperature hazard, the one of the plurality of sensors 126 can include an ambient temperature sensor; when the abnormal condition includes the fall hazard, the one of the plurality of sensors 126 can include an impact sensor and/or an accelerometer; and, when the abnormal condition includes the geo-fence breach, the one of the plurality of sensors 126 can include a location monitoring module.

[0031] After the wearable device 120 detects the abnormal condition, the method 102 can include activating a prediction subsystem of the cloud server 122, as in 108. In some embodiments, the prediction subsystem can include the cloud server 122 determining a current condition of the user of the wearable device 120 using the data from the plurality of sensors 126 and then monitoring the current condition for a change. In some embodiments, the method 102 can include the cloud server 122 processing the data with an Al model to determine the current condition of the user of the wearable device 120 and/or to monitor the current condition for the change. In these embodiments, the Al model can be trained using historical data from the wearable device 120, historical data from another device, and/or manufactured data which include first known values corresponding to the abnormal condition being experienced and second known values corresponding to the abnormal condition not being experienced. In some embodiments, the method 102 can include the cloud server 122 selecting the Al model from one of a plurality of Al models based on the abnormal condition detected by the wearable device 120. In these embodiments, each of the plurality of artificial intelligence models is trained using historical data from the wearable device 120, historical data from another device, and/or manufactured data which include first known values corresponding to a different respective abnormal condition being experienced and second known values corresponding to the different respective abnormal condition not being experienced.

[0032] Parallel with or independently of activating the prediction subsystem of the cloud server 122, as in 108, the method 102 can include the cloud server 122 activating a protection subsystem or mechanism when the wearable device 120 detects the abnormal condition, as in 110. In some embodiments, activating the prediction subsystem of the cloud server 122 can include the cloud server 122 soliciting feedback from the wearable device 120 and then the cloud server 122 determining the current condition of the user of the wearable device 120 using the data and the feedback. For example, in some embodiments, the method 102 can include the cloud server 122 determining that the current condition indicates that the user is not experiencing the abnormal condition when the feedback is positive and the cloud server 122 receives the feedback within a predefined cutoff time and the cloud server determining that the current condition indicates that the user is experiencing the abnormal condition when the feedback is negative and the cloud server receives the feedback within the predefined cutoff time. Furthermore, in some embodiments, when the cloud server 122 fails to receive the feedback before the predefined cutoff time, the method 102 can include the cloud server 122 including the failure to receive the feedback in the data used by the prediction subsystem for determining the current condition and monitoring the current condition for the change.

[0033] Various embodiments for the feedback solicited by the cloud server 122 are contemplated. For example, in some embodiments, the feedback can include one or more of user input received on the wearable device 120, an audio signal received by the wearable device 120, an audio signal received by a user device located proximate to the wearable device 120, and/or a preconfigured movement of the wearable device 120. Furthermore, as seen in FIG. 1 B, in some embodiments, the method 102 can include the cloud server 122 activating an Al audio bot as described herein to interact with the user of the wearable device 120 to solicit the feedback. In some embodiments, the Al audio bot is executed on the cloud server 120. However, embodiments where the Al audio bot is exclusively or partially executed on the wearable device 120 are also contemplated.

[0034] As seen in FIG. 1 B, the method 102 can include the cloud server 122 transmitting one or more of a level two notification (e.g. an alert level serious) to the registered device, a level three notification (e.g. an alert level critical) to the registered device and/or the secondary devices, and/or a level four notification (e.g. a high or catastrophic level alert) or to the registered device, the related devices, and an emergency response provider, as in 108, 110, and 112 based on the determinations of the prediction subsystem and/or the protection subsystem. In some embodiments, the method 102 can include the cloud server 122 transmitting a higher level alert to a different one of the notification devices when a response is not received to an earlier alert from, for example, the registered device. In some embodiments, the cloud server 122 can identify the correct emergency response provider to transmit the level four notification to based on a current location of the wearable device 120 and/or the specific abnormal condition being experienced by the user of the wearable device 120. Furthermore, in some embodiments, when the determinations of the prediction subsystem and/or the protection subsystem include situations where the current condition and/or the change in the current condition indicates the user is not experiencing the abnormal condition, the method 102 can include the cloud server 122 transmitting an all-clear notification to the registered device documenting the current condition. It should be noted that additional embodiments are contemplated where one or more of the steps of the method 102 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120 and one or more of the steps of the method 102 described above as being carried out by the wearable device 120 are instead carried out by the cloud server 122.

[0035] Additionally or alternatively, in some embodiments, any of the level one, two, three, or four notifications can include additional information besides the current condition of the user of the wearable device 120. For example, in some embodiments the additional information can include the location of the wearable device 120, key health metrics of the user of the wearable device 120 such as body temperature, heart rate etc., and other useful information as would be known to persons having ordinary skill in the art.

[0036] FIGS. 2-8 show various views of the wearable device 120 according to disclosed embodiments. In particular, FIG. 2 shows a perspective view of the wearable device 120 and FIG. 3 shows a top view of the wearable device 120. As seen in FIGS. 2 and 3, in some embodiments, the wearable device 120 can include a plurality of indicator or status lights 125 that are recessed into a top surface of the wearable device 120. In some embodiments, the indicator or status lights can include light emitting diodes (LEDs) and/or other light sources such as known in the art. FIG. 4 shows a bottom view of the wearable device 120. In some embodiments, some of the plurality of sensors 126 (see FIG. 9) can be positioned on the bottom of the wearable device 120 and can include body contact sensors that measure one or more user metrics of the user of the wearable device 120. In some embodiments the one or more user metrics can include the heart rate, blood oxygen level, and/or body temperature of the user.

[0037] FIGS. 5-7 show side views of the wearable device 120 according to disclosed embodiments. As seen in FIGS. 5-7, the wearable device 120 can include a lever 128 for releasing the wearable device 120 from clothing or another related accessory and a plurality of user interface elements or buttons for controlling the wearable device 120 such as and buttons 130, 134, 136, and 138. Furthermore, as seen in FIG. 6, in some embodiments, the wearable device 120 can include a microphone 132. In some embodiments, the microphone 132 can be used in conjunction with the Al audio bot to solicit the feedback from the user of the wearable device 120 as described herein.

[0038] FIG. 8 shows the wearable device 120 integrated into a clothing system 140 according to disclosed embodiments. In some embodiments, one or more of the plurality of sensors 126 can be integrated into the clothing system 140 and electrically connected to the wearable device 120. Additionally or alternatively, in some embodiments, the wearable device 120 can be worn on the arm, wrist, ring, etc.

[0039] FIG. 9 is a block diagram of the hazard detection and mitigation system 100 and the components thereof according to disclosed embodiments. As seen in FIG. 9, in some embodiments, the plurality of sensors 126 can include at least a heart rate monitor 126A, an ambient temperature sensor 126B, an accelerometer 126C, an air/water pressure sensor 126D, a water culture or humidity sensor 126E, and a location sensor 126F such as a global positioning system (GPS) module. As seen in FIG. 9, in some embodiments, each of the plurality of sensors 126 can be electrically coupled to a programable processor or microcontroller unit 142 of the wearable device 120. In some embodiments, a voice services subsystem 144 that includes the microphone 132; the user interface elements 130, 134, 136, and 138; the indicator lights 125; an audio output subsystem 146; and a communication interface 148 can be electrically coupled to the programable processor 142. Various other sensors known to person having ordinary skill in the art such as an oxygen sensor or a camera can be included among the plurality of sensors 126. In operation, the programable processor 142 can monitor the data from the plurality of sensors 126 to detect the abnormal condition from the at least a portion of the data and, when the programable processor 142 detects the abnormal condition, the programable processor 142 can transmit an indication of the abnormal condition and the data to a cloud server 122 via the communication interface 148.

[0040] As seen in FIG. 9, in some embodiments, the communication interface 148 can include an LTE Cellular data and WiFi modules or chipsets 150 and a Bluetooth module or chipset 152 for communicating with the cloud server 122, the notification devices 124, and/or other devices as would be understood in the art. Various other wired and wireless communication channels as understood in the art are also contemplated. For example, in some embodiments, the communication interface 148 can include a LoRaWAN module or chipset.

[0041] As seen in FIG. 9, in some embodiments, the cloud server 122 can include a second communication interface 156 for interfacing with the communication interface 148 of the wearable device 120 and the notification devices 124. In some embodiments, the cloud server 122 can include second programable processor 154 coupled to the second communication interface 156 and configured to carry out one or more of the methods described herein. Furthermore, in some embodiments, the cloud server 158 can include a memory device 158 for storing the Al audio bot, the plurality of Al modules, and/or other data and executable codes used by the cloud server 122 to carry out one or more of the methods described herein.

[0042] Various embodiments for the construction of the wearable device 120 are contemplated. For example, various printed circuit board (PCB) configurations with one or more layers for interconnecting the components of the wearable device 120 are contemplated. In some embodiments, some of the components of the wearable device 120 can be interconnected on a multi-layer rigid PCB that is coupled via a flex connector to a second sensor board housing one or more of the plurality of sensors 126. In some embodiments the second sensor board can be flexible. For example, in some embodiments, the communication interface 148, location sensor 126F, the accelerometer 126C, the air/water pressure sensor 126D, the water culture or humidity sensor 126E, and the ambient temperature sensor 126B, can be interconnected on the multi-layer rigid PCB and the heart rate monitor 126A and an oxygen sensor can be disposed on the sensor board coupled to the multi-layer rigid PCB by the flex cable. In some embodiments, the programable processor or microcontroller unit 142 can also be integrated into the multi-layer rigid PCB. Additional and alternative interconnection options known to persons of ordinary skill in the art are also contemplated. In some embodiments, the sensor board and the multi-layer PCB can be enclosed in a housing. Electronic circuitries are programmed with machine learning and artificial intelligence algorithms to provide contextual, intelligent, and timely alerts.

[0043] In some embodiments, the wearable device 120 can include one or more custom-designed antennas electrically coupled to the communication interface 148, the location sensor 126F, and/or other components of the wearable device 120. Various configurations for the antennas are contemplated including, but not limited to, having the antennas being embedded into the housing or an enclosure shell or a wristband.

[0044] FIGS. 10-21 show flow diagrams for various methods and sub-processes executed by the wearable device 120 and/or the cloud server 122 to detect and mitigate one or more hazards potentially experienceable by the user of the wearable device 120.

[0045] FIGS. 10-11 show a flow diagram for a water based hazard detection method 200 according to disclosed embodiments. In particular, FIG. 10 shows portions of the method 200 carried out by the wearable device 120 and includes starting the method 200 by having the wearable device 120 monitor the plurality of sensors 126 for an abnormal condition such as a water/pressure base anomaly, as in 202 and 204. Then, the method 200 can include the wearable device 120 detecting water contact or a hum idity increase using for example the water culture or humidity sensor 126E, as in 206. Next, the wearable device 120 can check a value of the air water pressure sensor 126D and determine whether the value is outside a preconfigured range, as in 208 and 210. When, the value fails to be outside the preconfigured range, the method 200 can include the cloud server 122 continuing to perform steps 204 through 210. However, when the value is outside the preconfigured range, the method 200 can include the wearable device 120 processing the values from at least the water culture or humidity sensor 126E and the air water pressure sensor 126D with an onboard Al process to determine whether a water/pressure based anomaly is likely occurring to the user of the wearable device 120. When, the water/pressure based anomaly is unlikely to be occurring, the method 200 can include the cloud server 122 continuing to perform steps 204 through 210. However, when the water/pressure based anomaly is likely to be occurring, the method 200 can include the cloud server 122 transmitting an indication of the water/pressure based anomaly to the cloud server 122.

[0046] Turning now to FIG. 11 the portions of the method 200 carried out by the cloud server 122 are shown. As seen in FIG. 11 , after receiving the indication of the water/pressure based anomaly from the wearable device 120, the method 200 can include the cloud server 122 transmitting a level one or informational alert to the registered device in the notification devices 124 to inform the notification devices 124 of the water/pressure based anomaly, as in 214. In parallel with step 214, the method 200 can include the cloud server 122 invoking the Al bot process and using its output to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing a water/pressure based hazard), as in

218 and 220. When the output of the Al bot process indicates that the user of the wearable device 120 is ok, the method 200 can include the cloud server 122 transmitting an all- clear alert or notification to the notification devices 124 and then ending the method 200, as in 222 and 223.

[0047] Furthermore, in parallel with steps 214 and 218, the method 200 can include the cloud server 122 receiving, from the wearable device 120, all the data from the plurality of sensors 126, as in 224. In some embodiments, the method 200 can include the cloud server 122 soliciting or requesting all of the data from the plurality of sensors 126. After receiving all of the data from the plurality of sensors 126, the method 200 can include the cloud server 122 invoking a wearer condition assessment sub-process to parse the data from the plurality of sensors 126, as in 226. In some embodiments, the method 200 can include the cloud server 122 including a negative output from the Al bot process in the data parsed by the wearer condition assessment sub-process. Next, the method 200 can use the output of the wearer condition assessment sub-process to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the water/pressure based hazard). When the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is ok, the method 200 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 200, as in 222 and 223.

[0048] However, when the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is not ok (e.g. the user of the wearable device 120 is likely experiencing the water/pressure based hazard), the method 200 can include the cloud server 122 running the wearer condition assessment sub-process to monitor the current condition of the user of the wearable device 120 for any change based on changes in the data from the plurality of sensors 126 (e.g. to determine whether the water/pressure based hazard becomes more or less severe), as in 230 and 232. When the wearer condition assessment sub-process indicates that the current condition of the user of the wearable device 120 is going down or deteriorating, the method 200 can include the cloud server 122 transm itting a level four alert or notification to the notification devices 124 and/or the relevant emergency services provider informing both of the deteriorating water/pressure based hazard being experienced by the user of the wearable device 120 and then ending the method 200, as in 234 and 223. In some embodiments, the method 200 can include the cloud server 122 invoking the Al bot process to contact the relevant emergency service providers.

[0049] Additionally, when the output of the wearer condition assessment subprocess from step 228 indicates that the user of the wearable device 120 is not ok, the method 200 can include the cloud server 122 sending a level 3 or critical alert to the notification devices 124 documenting the current state of the water/pressure based hazard being experienced by the user of the wearable device 120 and determining whether an acknowledgment was received from one or more of the notification devices 124, as in 238 and 240. When no acknowledgment is received from the notification devices 124, the method 200 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider and ending the method 200, as in 234 and 223. In some embodiments, when an acknowledgment is received from the notification devices 124, the method 200 can include the cloud server 122 ending the method 200, as in 223. In some embodiments, the method 200 can include the cloud server 122 continuing to monitor the current condition of the user of wearable device 120 for a change in the severity of the water/pressure based hazard as in steps 230-234 even after the cloud server 122 receives an acknowledgment from one of the notification devices 124. For example, in some embodiments, the method 200 can include the cloud server 122 monitoring the current condition of the user of wearable device for a change in the severity of the water/pressure based hazard as in steps 230-234 until the current values of the plurality of sensors 126 as parsed by the wearer condition assessment sub-process indicate that the user of the wearable device 120 is no longer experiencing the water/pressure based hazard.

[0050] It should be noted that additional embodiments are contemplated where one or more of the steps of the method 200 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120 and one or more of the steps of the method 200 described above as being carried out by the wearable device 120 are instead carried out by the cloud server 122. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 10 can be carried out by the cloud server 122 rather than the wearable device 120 and one or more of the steps shown in and described with respect to FIG. 11 can be carried out on the wearable device 120 rather than the cloud server 122.

[0051] FIGS. 12-13 show a flow diagram for a fall based hazard detection method 300 according to disclosed embodiments. In particular, FIG. 12 shows portions of the method 300 carried out by the wearable device 120 and includes starting the method 300 by having the wearable device 120 monitor the plurality of sensors 126 for an abnormal condition such as a fall based anomaly, as in 302 and 304. Then, the method 300 can include the wearable device 120 detecting a fall by for example detecting a sudden change in the value of the accelerometer sensor 126C, as in 306. Next, the method 300 can include the wearable device 120 processing the values from at least the accelerometer sensor 126C with the onboard Al process to determine whether a fall based anomaly is likely occurring to the user of the wearable device 120. When, the fall based anomaly is unlikely to be occurring, the method 300 can include the cloud server 122 continuing to perform steps 304 through 308. However, when the fall based anomaly is likely to be occurring, the method 300 can include the cloud server 122 transmitting an indication of the fall based anomaly to the cloud server 122.

[0052] Turning now to FIG. 13 the portions of the method 300 carried out by the cloud server 122 are shown. As seen in FIG. 13, after receiving the indication of the fall based anomaly from the wearable device 120, the method 300 can include the cloud server 122 transmitting a level one or informational alert to the registered device in the notification devices 124 to inform the notification devices 124 of the fall based anomaly, as in 310. In parallel with step 310, the method 300 can include the cloud server 122 invoking the Al bot process and using its output to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing a fall based hazard), as in 312 and 314. When the output of the Al bot process indicates that the user of the wearable device 120 is ok, the method 300 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 300, as in 316 and 318. [0053] Furthermore, in parallel with steps 310 and 312, the method 300 can include the cloud server 122 receiving, from the wearable device 120, all the data from the plurality of sensors 126, as in 320. In some embodiments, the method 300 can include the cloud server 122 soliciting or requesting all of the data from the plurality of sensors 126. After receiving all of the data from the plurality of sensors 126, the method 300 can include the cloud server 122 invoking the wearer condition assessment sub-process to parse the data from the plurality of sensors 126, as in 322. In some embodiments, the method 300 can include the cloud server 122 including a negative output from the Al bot process in the data parsed by the wearer condition assessment sub-process. Next, the method 300 can use the output of the wearer condition assessment sub-process to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the fall based hazard). When the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is ok, the method 300 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 300, as in 316 and 318.

[0054] However, when the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is not ok (e.g. the user of the wearable device 120 is likely experiencing the fall based hazard), the method 300 can include the cloud server 122 running the wearer condition assessment sub-process to monitor the current condition of the user of the wearable device 120 for any change based on changes in the data from the plurality of sensors 126 (e.g. to determine whether the fall based hazard becomes more or less severe), as in 326 and 328. When the wearer condition assessment sub-process indicates that the current condition of the user of the wearable device 120 is going down or deteriorating, the method 300 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider informing both of the deteriorating fall based hazard being experienced by the user of the wearable device 120 and then ending the method 300, as in 330 and 318. In some embodiments, the method 300 can include the cloud server 122 invoking the Al bot process to contact the relevant emergency service providers.

[0055] Additionally, when the output of the wearer condition assessment subprocess from step 324 indicates that the user of the wearable device 120 is not ok, the method 300 can include the cloud server 122 sending the level 3 alert to the notification devices 124 documenting the current state of the fall based hazard being experienced by the user of the wearable device 120 and determining whether an acknowledgment was received from one or more of the notification devices 124, as in 332 and 334. When no acknowledgment is received from the notification devices 124, the method 300 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider and then ending the method 300, as in 330 and 318. In some embodiments, when an acknowledgment is received from the notification devices 124, the method 300 can include the cloud server 122 ending the method 300, as in 318. In some embodiments, the method 300 can include the cloud server 122 continuing to monitor the current condition of the user of wearable device for a change in the severity of the fall based hazard as in steps 326-330 even after the cloud server 122 receives an acknowledgment from one of the notification devices 124. For example, in some embodiments, the method 300 can include the cloud server 122 monitoring the current condition of the user of wearable device for a change in the severity of the fall based hazard as in steps 326-330 until the current values of the plurality of sensors 126 as parsed by the wearer condition assessment sub-process indicating that the user of the wearable device 120 is no longer experiencing the fall based hazard.

[0056] It should be noted that additional embodiments are contemplated where one or more of the steps of the method 300 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120 and one or more of the steps of the method 300 described above as being carried out by the wearable device 120 are instead carried out by the cloud server 122. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 12 can be carried out by the cloud server 122 rather than the wearable device 120 and one or more of the steps shown in and described with respect to FIG. 13 can be carried out on the wearable device 120 rather than the cloud server 122.

[0057] FIGS. 14-15 show a flow diagram for an ambient temperature based hazard detection method 400 according to disclosed embodiments. In particular, FIG. 14 shows portions of the method 400 carried out by the wearable device 120 and includes starting the method 400 by having the wearable device 120 monitor the plurality of sensors 126 for an abnormal condition such as an ambient temperature based anomaly, as in 402 and 404. Then, the method 400 can include the wearable device 120 detecting an ambient temperature issue by for example detecting a sudden change in the value of the ambient temperature sensor 126B, as in 406. Next, the method 400 can include the wearable device 120 processing the values from at least the ambient temperature sensor 126B with the onboard Al process to determine whether an ambient temperature based anomaly is likely occurring to the user of the wearable device 120, as in 408. When, the ambient temperature based anomaly is unlikely to be occurring, the method 400 can include the cloud server 122 continuing to perform steps 404 through 408. However, when the ambient temperature based anomaly is likely to be occurring, the method 400 can include the cloud server 122 transmitting an indication of the ambient temperature based anomaly to the cloud server 122.

[0058] Turning now to FIG. 15 the portions of the method 400 carried out by the cloud server 122 are shown. As seen in FIG. 15, after receiving the indication of the ambient temperature based anomaly from the wearable device 120, the method 400 can include the cloud server 122 transmitting the level one or informational alert to the registered device in the notification devices 124 to inform the notification devices 124 of the ambient temperature based anomaly, as in 410. In parallel with step 410, the method 400 can include the cloud server 122 invoking the Al bot process and using its output to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the ambient temperature based hazard), as in 412 and 414. When the output of the Al bot process indicates that the user of the wearable device 120 is ok, the method 400 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 400, as in 416 and 418.

[0059] Furthermore, in parallel with steps 410 and 412, the method 400 can include the cloud server 122 receiving, from the wearable device 120, all the data from the plurality of sensors 126, as in 420. In some embodiments, the method 400 can include the cloud server 122 soliciting or requesting all of the data from the plurality of sensors 126. After receiving all of the data from the plurality of sensors 126, the method 400 can include the cloud server 122 invoking the wearer condition assessment sub-process to parse the data from the plurality of sensors 126, as in 422. In some embodiments, the method 400 can include the cloud server 122 including a negative output from the Al bot process in the data parsed by the wearer condition assessment sub-process. Next, the method 400 can use the output of the wearer condition assessment sub-process to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the ambient temperature based hazard), as in 424. When the output of the wearer condition assessment subprocess indicates that the user of the wearable device 120 is ok, the method 400 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 400, as in 416 and 418.

[0060] However, when the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is not ok (e.g. the user of the wearable device 120 is likely experiencing the ambient temperature based hazard), the method 400 can include the cloud server 122 running the wearer condition assessment sub-process to monitor the current condition of the user of the wearable device 120 for any change based on changes in the data from the plurality of sensors 126 (e.g. to determine whether the ambient temperature based hazard becomes more or less severe), as in 426 and 428. When the wearer condition assessment sub-process indicates that the current condition of the user of the wearable device 120 is going down or deteriorating, the method 400 can include transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider informing both of the deteriorating ambient temperature based hazard being experienced by the user of the wearable device 120 and then ending the method 400, as in 430 and 418. In some embodiments, the method 400 can include invoking the Al bot process to contact the relevant emergency service providers.

[0061] Additionally, when the output of the wearer condition assessment subprocess from step 424 indicates that the user of the wearable device 120 is not ok, the method 400 can include the cloud server 122 sending the level 3 alert to the notification devices 124 documenting the current state of the ambient temperature based hazard being experienced by the user of the wearable device 120 and determining whether an acknowledgment was received from one or more of the notification devices 124, as in 432 and 434. When no acknowledgment is received from the notification devices 124, the method 400 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider and the ending the method 400, as in 430 and 418. In some embodiments, when an acknowledgment is received from the notification devices 124, the method 400 can include the cloud server 122 ending the method 400 as in 418. In some embodiments, the method 400 can include the cloud server 122 continuing to monitor the current condition of the user of wearable device for a change in the severity of the ambient temperature based hazard as in steps 426-430 even after the cloud server 122 receives an acknowledgment from one of the notification devices 124. For example, in some embodiments, the method 400 can include the cloud server 122 monitoring the current condition of the user of wearable device 120 for a change in the severity of the ambient temperature based hazard as in steps 426-430 until the current values of the plurality of sensors 126 as parsed by the wearer condition assessment sub-process indicate that the user of the wearable device 120 is no longer experiencing the ambient temperature based hazard.

[0062] In some embodiments, when the output of the wearer condition assessment sub-process from step 424 indicates that the user of the wearable device 120 is not ok, the method 400 can include the cloud server 122 initiating a temperature hazard mediation process, as in 436. In some embodiments the temperature hazard mediation process can include the cloud server 122 determining whether a temperature control integration module is enabled, as in 438. When the temperature control integration module fails to be enabled, the temperature hazard mediation process can include the cloud server 122 ending the temperature hazard mediation process and the method 400, as in 418. When the temperature control integration module is enabled, the temperature hazard mediation process can include the cloud server 122 comparing a location of the wearable device 120 to a location of a heating and/or cooling system controlled via the temperature control integration module, as in 442. Furthermore, when the location of the wearable device 120 is within a predetermined range of the location of the heating and/or cooling system controlled via the temperature control integration module, the temperature hazard mediation process can include the cloud server 122 activating the heating and/or cooling system via the temperature control integration module to raise or lower an ambient temperature at the location of the wearable device 120, as in 444. As seen in FIG. 15, in some embodiments, temperature control integration module can include a smart car integration module and the heating and/or cooling system can include the 1 ventilation system of the smart car. Various other embodiments for the temperature control integration module the heating and/or cooling system are also contemplated such as a smart home heating and/or cooling system.

[0063] It should be noted that additional embodiments are contemplated where one or more of the steps of the method 400 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120 and one or more of the steps of the method 400 described above as being carried out by the wearable device 120 are instead carried out by the cloud server 122. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 14 can be carried out by the cloud server 122 rather than the wearable device 120 and one or more of the steps shown in and described with respect to FIG. 15 can be carried out on the wearable device 120 rather than the cloud server 122.

[0064] FIGS. 16-18 show a flow diagram for a geo-fence breach based hazard detection method 500 according to disclosed embodiments. In particular, FIG. 16 shows portions of the method 500 carried out by the wearable device 120 and includes starting the method 500 by having the wearable device 120 monitor location information from the location sensor 126F and processing the location information from the location sensor 126F with the onboard Al process to determine whether a geo-fence breach based anomaly is likely occurring to the user of the wearable device 120, as in 504 and 506. In some embodiments, the method 500 can include the wearable device 120 forgoing use of the onboard Al process and determining whether the geo-fence breach based anomaly is likely occurring to the user of the wearable device 120 by determining whether the location information indicates the wearable device 120 is inside or outside of to a preconfigured geo-fence location. In some embodiments, when, the geo-fence breach based anomaly is unlikely to be occurring, the method 500 can include the cloud server 122 continuing to perform steps 504 and 506. However, when the geo-fence breach based anomaly is likely to be occurring, the method 500 can include the cloud server 122 transmitting an indication of the geo-fence breach based anomaly to the cloud server 122. [0065] Turning now to FIG. 17-18, the portions of the method 500 carried out by the cloud server 122 are shown. As seen in FIG. 17, after receiving the indication of the geo-fence breach based anomaly from the wearable device 120, the method 500 can include the cloud server 122 receiving the location information for the wearable device 120 from the location sensor 126F, the other data from the plurality of sensor 126, and location data for the registered device of the notification devices 24, as in 508 and 510. In some embodiments, the registered device can belong to guardians of the user of the wearable device 120. Furthermore, in some embodiments, the cloud server 122 can solicit or request, from the wearable device 120, the location information for the wearable device 120 from the location sensor 126F and the other data from the plurality of sensor 126. Similarly, in some embodiments, the cloud server 122 can solicit or request the location data for the registered device from the registered device.

[0066] After receiving the data from the wearable device 120 and the registered device, the method 500 can include the cloud server 122 determining whether the registered device is also outside of the geo-fence location, as in 512. When the registered device fails to be outside of the geo-fence location, the method 500 can include the cloud server 122 transmitting the level one or informational alert to the registered device in the notification devices 124 to inform the notification devices 124 of the geo-fence breach based anomaly, as in 514. In parallel with steps 512 and 514, the method 500 can include the cloud server 122 invoking a geo-fence hazard prediction sub-process and using the output thereof to predict and/or determine whether the user of the wearable device 120 is in danger, as in 516 and 518. As seen in FIG. 18, when the output of the geo-fence hazard prediction sub-process indicates that the user of the wearable device 120 is not in danger, the method 500 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 including the registered device and then ending the method 500, as in 520 and 521.

[0067] As seen in FIG. 18, when the output of the geo-fence hazard prediction subprocess indicates that the user of the wearable device 120 is in danger, the method 500 can include the cloud server 122 transmitting a level two or warning alert to the primary and secondary devices in the notification devices 124 to inform the notification devices 124 of the present location based danger of the user of the wearable device 120, as in 522. In parallel with step 522, the method 500 can include the cloud server 122 invoking the Al bot process and using its output to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the geo-fence breach based hazard), as in 524 and 526. When the output of the Al bot process indicates that the user of the wearable device 120 is ok, the method 500 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 500, as in 520 and 521 .

[0068] Furthermore, in parallel with steps 522 and 524, the method 500 can include the cloud server 122 invoking the wearer condition assessment sub-process to parse the data from the plurality of sensors 126, as in 530. In some embodiments, the method 500 can include the cloud server 122 including a negative output from the Al bot process in the data parsed by the wearer condition assessment sub-process. However, in some embodiments such as shown in FIG. 18, the method 500 can include failing to include the negative output from the Al bot process in the data parsed by the wearer condition assessment sub-process and simply moving on to the steps 534 and 540 described herein when the Al bot process produces the negative output. Next, the method 500 can use the output of the wearer condition assessment sub-process to determine whether the user of the wearable device 120 is ok or not (e.g. to determine whether the user of the wearable device 120 is experiencing the geo-fence breach based hazard), as in 532. When the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is ok, the method 500 can include the cloud server 122 transmitting the all-clear alert or notification to the notification devices 124 and then ending the method 500, as in 520 and 521.

[0069] However, when the output of the wearer condition assessment sub-process indicates that the user of the wearable device 120 is not ok (e.g. the user of the wearable device 120 is likely experiencing the geo-fence breach based hazard), the method 500 can include the cloud server 122 running the wearer condition assessment sub-process to monitor the current condition of the user of the wearable device 120 for any change based on changes in the data from the plurality of sensors 126 (e.g. to determine whether the geo-fence breach based hazard becomes more or less severe), as in 534 and 536. When the wearer condition assessment sub-process indicates that the current condition of the user of the wearable device 120 is going down or deteriorating, the method 500 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider informing both of the deteriorating geo-fence breach based hazard being experienced by the user of the wearable device 120 and then ending the method 500, as in 538 and 521. In some embodiments, the method 500 can include the cloud server 122 invoking the Al bot process to contact the relevant emergency service providers.

[0070] Additionally, when the output of the wearer condition assessment subprocess from step 530 indicates that the user of the wearable device 120 is not ok, the method 500 can include the cloud server 122 sending the level 3 alert to the notification devices 124 documenting the current state of the geo-fence breach based hazard being experienced by the user of the wearable device 120 and determining whether an acknowledgment was received from one or more of the notification devices 124, as in 540 and 542. When no acknowledgment is received from the notification devices 124, the method 500 can include the cloud server 122 transmitting the level four alert or notification to the notification devices 124 and/or the relevant emergency services provider and the ending the method 500, as in 538 and 521. In some embodiments, when an acknowledgment is received from the notification devices 124, the method 500 can include the cloud server 122 ending the method 500 as in 521. In some embodiments, the method 500 can include the cloud server 122 continuing to monitor the current condition of the user of wearable device for a change in the severity of the geo-fence breach based hazard as in steps 426-430 even after the cloud server 122 receives an acknowledgment from one of the notification devices 124. For example, in some embodiments, the method 500 can include the cloud server 122 monitoring the current condition of the user of wearable device 120 for a change in the severity of the geo-fence breach based hazard as in steps 426-430 until the current values of the plurality of sensors 126 as parsed by the wearer condition assessment sub-process indicate that the user of the wearable device 120 is no longer experiencing the geo-fence breach based hazard.

[0071] It should be noted that additional embodiments are contemplated where one or more of the steps of the method 500 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120 and one or more of the steps of the method 500 described above as being carried out by the wearable device 120 are instead carried out by the cloud server 122. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 16 can be carried out by the cloud server 122 rather than the wearable device 120 and one or more of the steps shown in and described with respect to FIGS. 17-18 can be carried out on the wearable device 120 rather than the cloud server 122.

[0072] FIG. 19 shows the geo-fence hazard detection sub-process 600 of the geofence breach based hazard detection method 500 according to disclosed embodiments. As seen in FIG. 19, the geo-fence hazard detection sub-process 600 can include the cloud server 122 starting the process and retrieving the current location of the wearable device 120, as in 602 and 604. In some embodiments, retrieving the current location of the wearable device 120 can include the cloud server retrieving global positioning system coordinates from the location sensor 126F. Next, the geo-fence hazard detection subprocess 600 can include the cloud server 122 retrieving the location data for the registered device of the notification device 124 (e.g. the device associated with the guardian of the user of the wearable device 120), as in 606. [0073] After retrieving the relevant location information, the geo-fence hazard detection sub-process 600 can include the cloud server 122 identifying a closest safe location to the current location of the wearable device 120, as in 607. For example, in some embodiments, the closest safe location can include one of a home associated with the user of the wearable device 120 or the location of the guardian of the user of the wearable device 120 (e.g. the location of the registered device of the notification devices 124), Next, the geo-fence hazard detection sub-process 600 can include the cloud server 122 identifying a distance between the current location of the wearable device 120 and the closest safe location, as in 608 and 610, and retrieving from a memory device any previously marked hazard locations proximate to the location of the wearable device or the closest safe location, as in 612 and 614. In some embodiments, the previously marked hazard locations can include a road/highway, a body of water, ditch, or other unsafe locations such as would be known in the art.

[0074] Next, the geo-fence hazard detection sub-process 600 can include the cloud server 122 determining whether the user of the wearable device 120 is moving and whether the user of the wearable device 120 is moving away from the closest safe location, as in 616, 618, 620, and 622. When the user of the wearable device 120 is not moving and/or is not moving away from the closest safe location, the geo-fence hazard detection sub-process 600 can include the cloud server 122 continuing to perform the steps 604-622. However, when the user of the wearable device 120 is not moving and/or is not moving away from the closest safe location, the geo-fence hazard detection subprocess 600 can include the cloud server 122 determining whether the user of the wearable device 120 is moving towards any of the previously marked hazard locations, as in 624. In some embodiments, the geo-fence hazard detection sub-process 600 can include the cloud server 122 predicting an approximate length of time it will take the user of the wearable device 120 to reach one or more of the previously marked hazard locations and including the approximate length of time in any of the notifications sent to the notification devices 124. Finally, the geo-fence hazard detection sub-process 600 can include the cloud server 122 ending the sub-process 600, as in 626, and using the output thereof to predict and/or determine whether the user of the wearable device 120 is in danger, as in steps 516 and 518 of the method 500 shown in FIGS. 16-18.

[0075] In some embodiments, the geo-fence hazard detection sub-process 600 can include the cloud server 122 can use a real-time video feed from a camera on the wearable device 120 or a drone associated therewith to predict movements of the user of the wearable device 120 in relation to the previously marked hazard locations and/or the closest safe location. Furthermore, in some embodiments, the geo-fence hazard detection sub-process 600, can include the cloud server 122 learning routine activities and locations for the user of the wearable device and considering those learned activities and locations when assessing whether the geo-fence breach hazard is occurring or not.

[0076] It should be noted that additional embodiments are contemplated where one or more of the steps of the geo-fence hazard detection sub-process 600 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 19 can be carried out by the wearable device 120 rather than the cloud server 122. [0077] FIG. 20 shows an embodiment of the Al bot process 700 used in the methods 200-500 to determine whether the user of the wearable device 120 is ok or not after the cloud server 122 receives the indication of one of the abnormal conditions from the wearable device 120. As seen in FIG. 20, in some embodiments, the Al bot process 700 can include the cloud server 122 starting the Al bot process 700 and accessing the voice services subsystem 144 including the microphone 132 and the audio output sub system 146 on the wearable device 120 to initiate an audio dialog session with the user of the wearable device 120, as in 704. In some embodiments the voice connection between the cloud server 122 and the wearable device 120 can include a direct communication channel. Then, the Al bot process 700 can include the cloud server 122 determining whether a response was received for the user of the wearable device 120, as in 706. When no response has been received, the Al bot process 700 can include the cloud serer 122 determining whether a cutoff time has been reached, as in 708 and 710. In some embodiments, the Al bot process 700 can include the cloud server 122 recording any response received from the user of the wearable device120 before expiration of the cutoff time. When the cutoff time has not been reached, the Al bot process 700 can include the cloud server 120 continuing to perform the steps 706-710.

[0078] However, when the cutoff time has been reached and/or a response has been received by the user within the cutoff time, the Al bot process 700 can include the cloud server 122 ending the Al bot process 700, as in 712, and using the output thereof to determine whether the user of the wearable device 120 is ok or not as described in connection with the methods 200-500. For example, in some embodiments, the cloud server 122 can (1 ) conclude that the user of the wearable device 120 is ok when a positive response is received within the cutoff time; (2) conclude that the user of the wearable device 120 is not ok when a negative response is received within the cutoff time; and (3) incorporate that fact that no response was received within the cutoff time into the data parsed by the wearer condition assessment sub-process. In some embodiments, the Al bot process 700 can include the cloud server 122 recording any response received from the user of the wearable device120 before expiration of the cutoff time. It should also be noted that, in some embodiments, the methods 200-500 can include the cloud server 122 invoking the Al bot process 700 to confirm that the user of the wearable device 120 is in a stable condition when the cloud server determines as much through one or more other processes such as using the wearer condition assessment sub-process described herein. [0079] It should be noted that additional embodiments are contemplated where one or more of the steps of the Al bot process 700 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 20 can be carried out by the wearable device 120 rather than the cloud server 122.

[0080] FIG. 21 shows an embodiment of the wearer condition assessment subprocess 800 used in connection with the methods 200-500 to determine whether the user of the wearable device 120 is ok or not and/or whether the current condition of the user of the wearable device 120 is deteriorating. As seen in FIG. 21 , the wearer condition assessment sub-process 800 can include the cloud server 122 retrieving the data from the plurality of sensors 126 and parsing the data with the appropriate Al model to assess the current condition of the user of the wearable device 120, as in 804 and 806. Then, the wearer condition assessment sub-process 800 can include the cloud server 122 deciding whether to check the current condition again, as in 808. When the cloud server decides not to check the current condition again, the wearer condition assessment subprocess 800 can include the cloud server 122 determining whether the current condition is good, bad, improved since the last check, or deteriorating from the last check and then ending the wearer condition assessment sub-process 800, as in 810 and 812. As described herein in connection with the methods 200-500, the cloud server 122 can use the determination of whether the current condition is good, bad, improved since the last check, or deteriorating from the last check to determine whether the user of the wearable device 120 is ok or not and/or whether the current condition of the user of the wearable device 120 is deteriorating.

[0081] It should be noted that additional embodiments are contemplated where one or more of the steps of the wearer condition assessment sub-process 800 described above as being carried out by the cloud server 122 are instead carried out by the wearable device 120. For example, in some embodiments one or more of the steps shown in and described with respect to FIG. 21 can be carried out by the wearable device 120 rather than the cloud server 122.

[0082] In some embodiments, the various preconfigured settings and processes described herein can be modified by through a user interface coupled to the cloud server 122 and/or the wearable device 120. In some embodiments, the user interface can be a mobile application displayed on one of the notification devices 124 such as the registered device. Furthermore, in some embodiments, the user interface can include one or more pages for documenting information about the wearable device 120 such as shown in

FIGS. 22-24. For example, FIG. 22 shows a user interface screen documenting a history of alert notifications sent by the cloud server 122. Furthermore, FIGS. 22-23 show user interface screens used in connection with the detecting the geo-fence breach based hazard as described herein. In particular, FIG. 22 show a dashboard user interface screen and FIG. 23 shows a screen for a critical or level four alert notification. It should be understood that similar user interface screens are contemplated for use in connection with the other abnormal conditions or hazards monitored by the wearable device 120 and the cloud server 122.

[0083] Although a few embodiments have been described in detail above, other modifications are possible. For example, other components may be added to or removed from the described systems, and other embodiments may be within the scope of the invention.

[0084] From the foregoing, it will be observed that numerous variations and modifications may be affected without departing from the spirit and scope of the invention. It is to be understood that no limitation with respect to the specific system or method described herein is intended or should be inferred. It is, of course, intended to cover all such modifications as fall within the spirit and scope of the invention.