Edge and private cloud communication for physiological monitoring data

Abstract

Systems and methods for receiving monitoring data are described. An example system includes one or more edge computing resources in communication with at least one gateway via a network in communication with one or more user devices. The one or more edge computing resources include one or more processors configured by computer-executable instructions to receive, via the at least one gateway, monitoring data from the one or more user devices; store the monitoring data in a local memory of the one or more edge computing resources; determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmit a notification associated with the status.

Description

EDGE AND PRIVATE CLOUD COMMUNICATION FOR PHYSIOLOGICAL MONITORING DATACROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 645,419. filed May 10, 2024, which is incorporated by reference herein in its entirety.FIELD

[0002] The disclosed technology generally relates to secure data analysis of data communicated by a user device.BACKGROUND

[0003] User devices may be used to obtain and / or store data associated with one or more users. Examples of such user devices may illustratively include wearable devices such as health tracking wristbands that may collect data associated with a wearer. This data must be handled securely in order to avoid privacy issues with respect to user data. However, it is often helpful to compare this data against existing health data or health data from other users in order to determine insights relating to the user device or insights relating to the wearer.SUMMARY

[0004] Various examples of systems, methods, and devices within the scope of the appended claims each have several aspects, no single one of which is solely responsible for the desirable attributes described herein. Without limiting the scope of the appended claims, some prominent features are described herein.

[0005] Disclosed herein is a system for secure determination of health status, the system comprising: one or more edge computing resources in communication with at least one gateway via a network in communication with one or more user devices, the one or more edge computing resources comprising one or more processors configured by computer-executable instructions to: receive, via the at least one gateway, monitoring data from the one or more user devices; store the monitoring data in a local memory of the one or more edge computing resources; determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmit a notification associated with the status.

[0006] In certain preferred embodiments, the status is a health status corresponding to a patient wearing the user device.

[0007] In certain preferred embodiments, the monitoring data comprises heat flux measurements.

[0008] In certain preferred embodiments, one or more processors are configured by computer-executable instructions to determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices, at least by determining the health status based on the heat flux measurements.

[0009] In certain preferred embodiments, the health status comprises an indicator of exhaustion, fatigue, alertness, infection, or physical performance.

[0010] In certain preferred embodiments, the status is an operational status of the user device.

[0011] In certain preferred embodiments, the operational status includes at least one of a hardware status of the user device; an indication that the user device is not being worn, or an indication that the user device is being worn incorrectly.

[0012] In certain preferred embodiments, the one or more edge computing resources are located in a first facility that remains stationary with respect to a geographic location, and wherein the at least one gateway is located in one or more mobile facilities.

[0013] In certain preferred embodiments, at least one of the one or more mobile facilities comprises a vehicle.

[0014] In certain preferred embodiments, the one or more edge computing resources and the at least one gateway are located in a stationary facility.

[0015] In certain preferred embodiments, the stationary facility comprises a residence or a healthcare facility.

[0016] In certain preferred embodiments, the one or more processors are further configured to update data within the one or more edge computing resources based on data received from one or more remote computing resources, the data comprising one or more updated algorithms for analyzing received monitoring data.

[0017] In certain preferred embodiments, the one or more processors are further configured to deidentify at least a portion of the stored monitoring data for provision to one or more remote computing resources in communication with the one or more edge computing resources via a wide area network.

[0018] In certain preferred embodiments, the one or more processors are configured to receive the monitoring data utilizing a thread network protocol, and wherein the user device utilizes a matter interoperability protocol.

[0019] Also disclosed is a computer-implemented method for secure determination of health status, the method comprising: receiving, at one or more edge computing resources from at least one gateway in communication with one or more user devices, monitoring data from the one or more user devices via a network; storing the monitoring data in a local memory of the one or more edge computing resources; determining, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmitting a notification associated with the status.

[0020] In certain preferred embodiments of this method, the status is a health status for a patient wearing the user device.

[0021] In certain preferred embodiments of this method, the monitoring data comprises heat flux measurements.

[0022] Certain preferred embodiments of this method, include a step of determining, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices, comprises determining the health status based on the heat flux measurements.

[0023] In certain preferred embodiments of this method, the health status comprises an indicator of exhaustion, fatigue, alertness, infection, or physical performance.

[0024] In certain preferred embodiments of this method, the status is an operational status of the user device.

[0025] In certain preferred embodiments of this method, the operational status includes at least one of a hardware status of the user device; an indication that the user device is not being worn, or an indication that the user device is being worn incorrectly.

[0026] In certain preferred embodiments of this method, the one or more edge computing resources are located in a first facility that remains stationary with respect to a geographic location, and wherein the at least one gateway is located in one or more mobile facilities.

[0027] In certain preferred embodiments of this method, at least one of the one or more mobile facilities comprises a vehicle.

[0028] In certain preferred embodiments of this method, the one or more edge computing resources and the at least one gateway are located in a stationary facility.

[0029] In certain preferred embodiments of this method, the stationary facility comprises a residence or a healthcare facility.

[0030] Certain preferred embodiments of this method further comprise deidentifying at least a portion of the stored monitoring data for provision to one or more remote computing resources in communication with the one or more edge computing resources via a wide area network.

[0031] In certain preferred embodiments of this method, further comprise updating data within the one or more edge computing resources based on data received from one or more remote computing resources, the data comprising one or more updated algorithms for analyzing received monitoring data.

[0032] In certain preferred embodiments of this method, the monitoring data is received utilizing a thread network protocol, and wherein the user device utilizes a matter interoperability protocol.BRIEF DESCRIPTION OF DRAWINGS

[0033] Various examples will be described hereinafter with reference to the accompanying drawings. These examples are illustrated and described by example only and are not intended to limit the scope of the disclosure. In the drawings, similar elements may have similar reference numerals.

[0034] FIG. 1 illustrates an example system configured for communication of monitoring data between user device(s) and gateway(s).

[0035] FIG. 2 illustrates an example system for receiving monitoring data from user device(s).

[0036] FIG. 3 illustrates an example system for receiving monitoring data from user device(s) with an analytics system.

[0037] FIG. 4 illustrates an example method for issuing alerts based on monitoring data.

[0038] FIG. 5 illustrates an example method to generate alertness warnings based on monitoring data.

[0039] FIG. 6 illustrates an example method to detect or predict maintenance issues based on monitoring data.

[0040] FIG. 7 illustrates an example analytics system in accordance with some aspects of the present disclosure.DETAILED DESCRIPTION

[0041] The present disclosure will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The following description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. It should be understood that steps within a method may be executed in different order without altering the principles of the present disclosure. Furthermore, the devices, systems, and / or methods disclosed herein can include several novel features, no single one of which is solely responsible for its desirable attributes, or which is essential to practicing the devices, systems, and / or methods disclosed herein.

[0042] Generally described, the present technology relates to secure monitoring and determination related to health status. More specifically, aspects of the present disclosure correspond to systems and methods for analysis of monitoring data from a device by one or more edge computing devices, where edge computing devices are devices at the edge of a network (e.g., a local network, a wide area network, etc.) and use local computing resources to perform tasks.

[0043] Traditional systems record measurements from devices, such as wearable devices, while processing the monitoring data using remote computing resources. Remote computing resources include or are able to access tools (e.g., services, software applications, and the like) to process data and glean insights relating to the health of the patient. Remote computing resources may then make this information available to the user, such as through a browser application. Remote computing resources may also be used to generate tools based on user data.

[0044] Accordingly, traditional approaches introduce issues with latency and security. As an example of introduced security issues, since remote computing resources also process the data to generate user-specific results, deidentification of user specific data for development of new tools may be less effective. These difficulties are increased with respect to mobile implementations (e.g., planes, trains, automobiles, ships, etc.), where the device, such as a wearable device, may have unstable connection to remote computing resources.

[0045] The present disclosure improves on the prior approaches at least by providing for processing monitoring data from devices, such as wearable devices, at edge computing resources able to access monitoring data stored in local memory. The edge computing resources may be loaded with tools for analysis of the monitoring data to determine a status for the user device or for the user. Since the monitoring data is processed based on local memory, there is less latency in generating insights from monitoring data of the user.

[0046] Additionally, use of edge computing resources has numerous security benefits. For example, edge computing may reduce attack surface by reducing the amount of data that needs to pass through remote computing resources, such as servers. Moreover, the decentralized nature of edge computing, where processing and storage is spread across multiple devices, may reduce the effect of a breach to one device of the system. Use of edge computing resources also may reduction of unauthorized access at least by facilitation of physical security measures (e.g., tamper-resistant enclosures, secure boot processes, etc.), local access controls to specific devices, the like, or some combination thereof. Further security benefits of edge computing include, but are not limited to, improved threat detection and response through facilitation of real-time monitoring, facilitation of encryption to improve the security of data in transit, facilitation of firmware and software updates to edge computing devices, and facilitating improved data sovereignty at least by allowing sensitive data to be kept within specified geographic boundaries.

[0047] Moreover, the security of the data is improved due to local storage of the data for user-specific analysis. By way of illustration, data stored locally may include unique identifiers, such as user-specific identifiers. Local storage helps limit access to monitoring data including unique identifiers. For example, only certain devices or only devices authorized by certain entities may access the local network. Moreover, their access may be limited to monitoring data for particular unique identifiers.

[0048] To continue to allow for additional analysis and / or development of new tools based on data from the user devices, aspects of the present disclosure provide for deidentifying user data prior to transmission. For example, based on the deidentified data from one or more user devices, remote computing resources may perform additional analysis based on aggregated data and / or generate new tools. In some examples, the edge computing resources may update its tools based on the additional analysis. As another example, the remote computing resources may provide new or updated tools to the edge computing resources for local implementation. Accordingly, the edge computing tools may provide up-to-date analysis of the status of the user device or of the user based on the remote analysis and / or new tools.Example Systems for Data Monitoring

[0049] FIG. 1 illustrates an example system 100 configured for secure communications between one or more user device(s) 102 and one or more gateway(s) 104. The one or more gateway (s) 104 may further communicate with one or more edge computing resources, as will be discussed in more detail below with respect to FIGS. 2-7.

[0050] The user device(s) 102 may be any type of computing device configured for wireless communication. Each individual user device 102 may be configured to be carried, worn, or otherwise transported by a user. In some examples, the user device(s) 102 are configured to generate and store data periodically, constantly, or during predefined periods of time, regardless of whether the individual user device 102 is in communication with any individual gateway 104 at any particular time.

[0051] In some examples, each user device 102 may be configured to be able to communicate with any one of the gateways 104 of the system 100. Similarly, in some examples, each gateway 104 is configured to be able to communicate with any one of the user devices 102 of the system 100. Accordingly, a user’s user device 102 may advantageously be able to send its stored data to a gateway 104, regardless of which gateway 104 the user device 102 is able to connect to at any particular time. Alternatively, in some examples, individual user devices 102 may be configured to communicate with a particular gateway 104.

[0052] In one particular non-limiting example, the user device(s) 102 are physiological tracking devices, such as wristbands or other wearable devices configured to collect monitoring data over time including, but not limited to, user temperature data, ambient temperature data, the like, or some combination thereof. For example, the wristband may include one or more temperature sensors and may be configured to collect temperature data of a wearer, ambient temperature data, and / or heat flux data by recording one or more data points at a consistent periodic interval, such as every 0.5 seconds, every second, every 5 seconds, every 10 seconds, every' 30 seconds, every minute, every 5 minutes, every 10 minutes, or at a longer interval, or at any interval within a range defined between any of the preceding values.

[0053] Gateway(s) 104 may be network-connected devices that are configured to communicate using one or more networks (e.g., local area networks (LANs), wide area network(s) (WANS), cellular communication networks, cloud networks, etc.). The communication between the one or more user devices 102 and the one or more gateway (s) 104 may occur through a wired connection (e.g., fiber-optic cable). Additionally, or alternatively, communication between the one or more user devices 102 and the one or more gateway (s) 104 may utilize any suitable wireless communication protocol, including, but not limited to, Bluetooth Low Energy (BLE), Radio Frequency Identification (RFID), Wi-Fi, IP-based protocols (e.g., IPv4 based protocols, IPv6 based protocols, etc.), protocols compliant with IEEE standards (e.g., the IEEE 802. 15.4 standard), the like, or some combination thereof.

[0054] By way of illustration, Matter and Thread may be used together to generate scalable IOT networks. A person of ordinary' skill in the art would understand that Thread isbased on the IEEE 802.15.4 standard and may serve as a low-power, mesh networking layer for local communication between devices. Matter is an IPv6-based architecture that may use Wi-Fi, Thread, or the like, to support connectivity between devices. Matter is a wireless networking protocol based on IPv6 often used in IOT device networks and may provide a unified application layer that supports interoperability between devices from different manufacturers by providing a large address space that enables direct end-to-end communication between devices. As an example, Matter and Thread may be used to support communication between user device 102 and gateway 104.

[0055] In some examples, gateway(s) 104 may also communicate with edge computing resources through a local network (e.g., a LAN, a virtual private network (VPN), etc.), as will be discussed in more detail with respect to FIGS. 2-6 below. Communication between edge computing resources and gateway (s) 104 may be conducted with any low power wireless standard that provides OSI Layers 1-4. For example, the edge computing resources may analyze monitoring data generated by individual user device(s) 102 and generate userspecific alerts and insights based on this data, as will be discussed in more detail in FIGS. 2-6.

[0056] In some examples, gateway (s) 104 may incorporate watchdog functionality. The watchdog functionality may be used to analyze status(es) of user device(s) 102. Illustratively, the watchdog functionality may detect issues including, but not limited to, a hardware status of a user device 102, an indication that the user device 102 is not being worn, or an indication that the user device 102 is being worn incorrectly.

[0057] The gateway(s) 104 can be located in static locations, mobile locations, or some combination thereof. For example, a gateway 104 may be a stationary device installed in a room or building. In some examples, multiple gateway(s) 104 may be located within a single building, such as in different rooms of a house or building where one or more users associated with user devices 102 live and / or work. In addition, multiple gateway(s) 104 may be located in different geographical locations, such as in multiple houses or other buildings (e.g., workplaces, commercial buildings, healthcare facilities, etc.) spread across a town, city, state, country, or internationally.

[0058] As mentioned above, gateway(s) 104 may also be mobile. For example, a gateway 104 may be installed inside a vehicle (e.g., plane, train, automobile, ship, etc.). In some examples, multiple gateway (s) 104 may be in a vehicle. As one example, a gateway 104 may be located near the driving wheel of an automobile, and another gateway may be located in the back seat. As yet another example, a gateway 104 may be located at different sections of an airplane including, but not limited to, in the cockpit, at specified positions between rows ofseating (e.g., every row, every ‘n’ number of rows, at random intervals, etc.), at the rear of the plane, the like, or some combination thereof. Additionally, multiple gateway(s) 104 may be located in different geographical locations, such as in multiple different vehicles spread across a town, city, state, country, or internationally. In some cases, gateways 104 may be deployed across a fleet of vehicles, such as in emergency vehicles or aircraft operated and / or dispatched by a single entity.

[0059] FIG. 2 illustrates an example system 200 for securely receiving monitoring data from the user devices 102. The user device(s) 102 may collect monitoring data from one or more users and provide this monitoring data to gateway (s) 104. The gateway(s) 104 may then provide the monitoring data to edge computing resource(s) 202. Edge computing resource(s) 202 may further communicate with remote computing resource(s) 204, as will be discussed in more detail below.

[0060] As discussed with respect to FIG. 1, the user device(s) 102 may be any type of computing device configured for wireless communication. Each individual user device 102 may be configured to be carried, worn, or otherwise transported by a user. In a non-limiting example, a user device 102 may be worn by a particular user. The user device 102 may collect physiological data, such as temperature data (e.g., user temperature, ambient temperature, heat flux, etc.). The user device 102 and a gateway 104 may securely establish a communication channel on a private network. The private network may use any acceptable wireless communication protocol for communication (e.g., BLE, Wi-Fi, thread, etc ). Illustratively, in a non-limiting example, user device(s) 102 may comply with the matter connectivity standard. A particular user device 102 worn by a particular user may accordingly communicate directly with any gateway 104 using the thread protocol.

[0061] Once a secure communication channel is established, the user device 102 may transmit monitoring data including physiological data (e.g., user temperature, ambient temperature, heat flux, etc.) for the particular user to gateway (s) 104. The monitoring data may further include indications of the operational status of the particular user device 102. Illustratively, the monitoring data may include indicators of whether the particular user device 102 is being worn, whether the particular user device 102 is being worn correctly, hardware issues relating to the particular user device (e.g., damaged sensor(s), damaged communication component(s), etc.), prediction of future maintenance issues (e.g., a future sensor failure), the like, or some combination thereof.

[0062] In some examples, the gateway (s) 104 may conduct an initial analysis of the user data. As discussed with respect to FIG. 1, gateway(s) 104 may incorporate watchdogfunctionality to detect operational status (e.g., operational malfunctions) of user device(s) 102. For example, the gateway(s) 104 may implement the watchdog functionality by reviewing monitoring data for a user device 102 with respect to an internal system timer of the user device. The internal system timer may expire after a period of time. If the timer expires without being reset, this may indicate a malfunction. The gateway(s) 104 may detect these operational malfunctions within the monitoring data and add an indicator (e.g., a tag) for this malfunction. As another example, to incorporate watchdog functionality, the gateway 104 may review monitoring data for each individual user device 102 and identify areas with unusual signals. Illustratively, with the watchdog functionality, the gateway 104 may classify signals as representative of particular types of operational malfunctions including, but not limited to, sensor failure, potential future sensor failure, communication failure, potential future communication failure, user device 102 not being worn, user device 102 not being worn correctly, or the like, or some combination thereof. The gateway 104 may then tag the monitoring data for the user device 102 to provide indications of the detected operational malfunctions. While the watchdog functionality described above is described as incorporated by gateway(s) 104, this is not intended to be limiting. In some examples, the watchdog functionality may be implemented on edge computing resource(s) 202. Detection of operational malfunctions with the watchdog functionality will be discussed in more detail with respect to FIGS. 4-5.

[0063] Other options are also possible. In some examples, gateway(s) 104 may monitor the data to determine when to trigger transfer of the monitoring data. Gateway (s) 104 may monitor the data to determine when to trigger upload of the monitoring data from a user device 102, for example. Gateway (s) 104 may analyze the monitoring data to determine whether higher priority data is present. The gateway (s) 104 may, for example, review monitoring data for each individual user device 102 and identify areas with unusual signals indicating a health event (e. g. , a sleep apnea event, a heart attack, etc. ) and may trigger transfer of monitoring data in response to identifying signals indicating a health event. In some examples, gateway (s) 104 may trigger transfer monitoring data from an individual user device 102 based on prior monitoring data from the individual user device 102. Gateway (s) 104 may, for example, obtain monitoring data from an individual user device 102 as part of a monitoring cycle. Gateway(s) 104 may, for example, obtain monitoring data from the individual user device 102 at regular intervals. Prior monitoring data may, for example, include areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). Gateway (s) 104 may identify this data in the prior monitoring data. Gateway (s) 104 maysubsequently trigger an out of cycle transfer of monitoring data from the user device 102. Gateway (s) 104 may, for example, cause the user device 102 to transfer monitoring data between the regular intervals for obtaining monitoring data from the user device 102.

[0064] As another example, user device(s) 102 may include a functionality to detect health events. An individual user device 102 may, for example, identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). The individual user device 102 may then trigger transfer of monitoring data in response to identifying signals indicating a health event. The individual user device 102 may then trigger transfer of monitoring data to gateway 104, for example.

[0065] Turning to edge computing resource(s) 202, the edge computing resource(s) 202 may be implemented on server(s) and / or data store(s) forming part of a local network (e.g., local area network LAN, virtual private network (VPNs), etc.). The local network may communicate via any applicable wired (e.g., ethemet) or wireless protocol (e.g., BLE, Wi-Fi, Thread, Matter, etc.). Edge computing resource(s) 202 may include tools (e.g., software applications, data store(s), thresholds, etc.) for analysis of monitoring data received from gateway(s) 104. In some examples, the monitoring data for each user device 102 may include a unique identifier for the particular user device 102. In some examples, the unique identifier may be added to the monitoring data by the gateway(s) 104. Additionally, or alternatively, the unique identifier may be added to the monitoring data by each user device 102. In further examples, the edge computing resource(s) 202 may isolate monitoring data for analysis by the unique identifier.

[0066] In some examples, the edge computing resource(s) 202 may include tools for identification of operational status for an individual user device 102 that collected the monitoring data. In a non-limiting example, the edge computing resource(s) 202 may analy ze the monitoring data and identify tags relating to operational malfunctions added by the gateway 104. The edge computing resource(s) 202 may then determine an operational status for the user device 102. Edge computing resource(s) 202 may additionally, or alternatively, analyze monitoring data to determine health status for a user corresponding to a particular user device 102. In a particular non-limiting example, a particular user device 102 may be a wearable device worn by a particular user. The particular user device 102 may measure physiological data (e.g., user temperature, ambient temperature, heat flux, etc.). The particular user device 102 may communicate the physiological data as part of monitoring data to a gateway 104. The gateway 104 may then communicate the monitoring data to edge computing resource(s) 202. The edge computing resource(s) 202 may include tools to identify healthconditions from the physiological monitoring data, such as machine learning models, thresholds, and the like. The edge computing resource(s) 202 may use these tools to analy ze the monitoring data. Based on the results of the analysis, the edge computing resource(s) 202 may determine whether the monitoring data indicates that one or more health conditions (e.g., alertness, exhaustion, etc.) are present. The edge computing resource(s) 202 may then determine whether to generate an alert or insight based on these health conditions, as will be discussed in more detail in FIG. 6.

[0067] Turning to geographical relationships between gateway (s) 104 and edge computing resource(s) 202, gateway (s) 104 may be either static or mobile with respect to edge computing resource(s) 202. In some examples, at least some gateway (s) 104 may be static with respect to edge computing resource(s) 202. Illustratively, both gateway (s) 104 and edge computing resource(s) 202 may be located within the same building, such as a hospital, a smart home, an office building, another public building, the like, or some combination thereof.[006S] In a particular non-limiting example, a hospital may include a centralized facility for edge computing resource(s) 202 and position individual gateway (s) 104 in individual rooms, groups of rooms, floors, sections, etc., of the hospital. In further examples, each gateway 104 may receive monitoring data from one or more user device(s) 102 from each room and transmit the monitoring data for analysis by edge computing resource(s) 202 as described above. The edge computing resource(s) 202 may then generate alerts, where alerts may identify detected health status (e.g., health conditions, severity of health conditions, etc.) of the user corresponding to each user device 102 or operational status (e.g., type of operational malfunction, severity of operational malfunction, etc.) of each user device 102.

[0069] In another non-limiting example, a smart home may include edge computing resource(s) 202 at a central location and further include multiple gateway(s) 104. For example, individual gateways 104 may be located in some or all rooms of the smart home. Each gateway 104 may receive monitoring data from one or more user device(s) 102 from the individual gateways 104 and transmit the monitoring data for analysis by edge computing resource(s) 202 as described above. The edge computing resource(s) 202 may then generate alerts, where alerts may identify detected health status (e.g., health conditions, severity of health conditions, etc.) of the user corresponding to each user device 102 or operational status (e.g., type of operational malfunction, severity of operational malfunction, potential future operational malfunctions, etc.) of each user device 102.

[0070] In another non-limiting example, a stadium, arena, or other public facility may include edge computing resource(s) 202 at a central location and multiple gateway(s) 104around the facility. Each gateway 104 may receive monitoring data from one or more user device(s) 102 in and around the facility and transmit the monitoring data for analysis by edge computing resource(s) 202 as described above. The edge computing resource(s) 202 may then generate alerts, where alerts may identify detected health status (e.g., health conditions, severity of health conditions, etc.) of the user corresponding to each user device 102 or operational status (e.g., type of operational malfunction, severity of operational malfunction, etc.) of each user device 102.

[0071] Additionally, or alternatively, the gateway(s) 104 may be mobile with respect to edge computing resource(s) 202. In a particular nondimiting example, the edge computing resource(s) may be included in a single facility, such as a single building, multiple buildings within a geographical area, and the like. In further examples, individual gateway(s) 104 may be located in multiple vehicles (e.g., planes, trains, automobiles, ships, etc.), where at least one gateway 104 is included in each of the multiple vehicles. For example, multiple vehicles operated by a dispatching entity (e.g., a fleet of ambulances, taxis, buses, delivery vehicles, aircraft, etc.) may each have one or more gateways 104 located therein to collect monitoring data from user devices 102 worn by users within the vehicles, and may be in communication with edge computing resource(s) 202 located at a headquarters, a dispatch facility, or other location associated with the dispatching entity. Each gateway 104 may receive monitoring data from one or more user device(s) 102 and transmit the monitoring data for analysis by edge computing resource(s) 202 as described above. The edge computing resource(s) 202 may then generate alerts, where alerts may identify detected health status (e.g., health conditions, severity of health conditions, etc.) of the user corresponding to each user device 102 or operational status (e.g., type of operational malfunction, severity of operational malfunction, potential future operational malfunction, etc.) of each user device 102.

[0072] While the edge computing resource(s) 202 are described as static in the above, this is not intended to be limiting. In some examples, the edge computing resource(s) 202 may be mobile. For example, edge computing resource(s) 202 may be included in a vehicle (e.g., planes, trains, automobiles, ships, etc.). In some examples, the edge computing resource(s) 202 may be included in a vehicle separated from the vehicles including gateway(s) 104. Illustratively, the edge computing resource(s) 202 may be included in a mobile base station. The mobile base station may be a moving vehicle including the edge computing resource(s) 202 but not including gateway (s) 104. In further examples, the mobile base station may be a vehicle from which the operation and movement of other vehicles is managed (e.g., a refueling ship, an aerial command center, etc ).

[0073] In some examples, edge computing resource(s) 202 may be included in the same vehicle as one or more gateway(s) 104. As an example, the edge computing resource(s) 202 may be located in an airplane also including one or more gateway (s) 104 positioned at various sections of the aircraft. Illustratively, the edge computing resource(s) 202 may be positioned in the cockpit of an airplane and gateway(s) 104 may be positioned at various positions throughout the airplane including, but not limited to, every row, every ‘n’ number of rows, at random intervals, and the like.

[0074] In some examples, the edge computing resource(s) 202 may communicate with remote computing resource(s) 204, where remote computing resource(s) 204 may generate updated or new tools based on monitoring data. To preserve user privacy, the edge computing resource(s) 202 may deidentify monitoring data prior to providing the monitoring data to the remote computing resource(s) 202. Illustratively, the edge computing resource(s) 202 may deidentify monitoring data with techniques including, but not limited to, tokenization, hashing, pseudonymization, the like, or some combination thereof.

[0075] After receipt of monitoring data corresponding to a user device 102 from gateway 104, edge computing resource(s) 202 may analyze the monitoring data using any of the methods described herein. Edge computing resource(s) 202 may, for example, monitor the data to determine when to trigger upload of the monitoring data from user device 102, for example.

[0076] Edge computing resource(s) 202 may, analyze monitoring data to determine when to compile and upload the monitoring data, for example, edge computing resource(s) 202 may, for example, analyze the monitoring data to determine whether higher priority data is present. The edge computing resource(s) 202 may review monitoring data for each individual user device 102 and identify areas with unusual signals indicating a health event, for example.

[0077] Higher priority data may include, but is not limited to, health events. Health events may include, but are not limited to, any event which indicates a medical condition of the user. A user associated with a user device 102 may, as one example, have a sleep apnea event. The gateway(s) 104 may detect the sleep apnea event within the monitoring data and add an indicator (e.g., atag) for this health event. Edge computing resource(s) 202 may further trigger upload of monitoring data relating to the health event from the user device 102.

[0078] In some examples, edge computing resource(s) 202 may trigger transfer monitoring data from an individual user device 102 based on prior monitoring data from the individual user device 102. Edge computing resource(s) 202 may, for example, obtain monitoring data from an individual user device 102 as part of a monitoring cycle. Edgecomputing resource(s) 202 may, for example, obtain monitoring data from the individual user device 102 at regular intervals. Prior monitoring data may, for example, include areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). Edge computing resource(s) 202 may identify this data in the prior monitoring data. Edge computing resource(s) 202 may subsequently trigger an out of cycle transfer of monitoring data from the user device 102. Edge computing resource(s) 202 may, for example, cause the user device 102 to transfer monitoring data between the regular intervals for obtaining monitoring data from the user device 102.

[0079] As another example, user device(s) 102 may include a functionality to detect health events. An individual user device 102 may, for example, identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). The individual user device 102 may then trigger transfer of monitoring data in response to identifying signals indicating a health event. The individual user device 102 may then trigger transfer of monitoring data to edge computing resource(s) 202, for example.

[0080] The edge computing resource(s) 202 may further deidentify the monitoring data by removing any unique identifiers for the user device 102 or for the user corresponding to the user device 102. In some examples, the edge computing resource(s) 202 may provide the deidentified monitoring data to the remote computing resource(s) 204 in batches including monitoring data for more than one user device. In some examples, the deidentified monitoring data may be provided at scheduled intervals, such as intervals specified by an administrator for the remote computing resource(s) 204 or intervals specified by an administrator for the edge computing resource(s) 202.

[0081] The edge computing resource(s) 202 may additionally, or alternatively, communicate with remote computing resource(s) 204 to update its tools. Illustratively, the edge computing resource(s) 202 may check for updated or new tools in the remote computing resource(s) 204 at intervals. If updated or new tools are present, the edge computing resource(s) 202 may update or add tools corresponding with updates or additional tools present in remote computing resource(s) 204. As another example, the remote computing resource(s) 204 may notify the edge computing resource(s) 202 when updated tool(s) or new tool(s) are present. The edge computing resource(s) 202 may then download the updated or new tool(s) for use in analysis of existing or subsequently collected monitoring data.

[0082] FIG. 3 illustrates an example system 300 for receiving monitoring data from user device(s) 102 with an analytics system 302. The user device 102 may communicate the monitoring data relating to the user device 102 or a user corresponding to the user device 102to analytics system 302. The analytics system 302 may also receive monitoring data from third- party device(s) 304, where each third-party device 304 may correspond to a particular user. The analytics system 302 may include both gateway(s) 104 and edge computing resource(s) 202. As discussed with respect to FIG. 2, the gateway (s) 104 and edge computing resource(s) 202 may work together to generate user-specific insights and alerts based on the monitoring data. The analytics system 302 may then communicate user-specific insights and alerts based on the monitoring data to the third-party device(s) 304. In some examples, the analytics system 302 may communicate the user-specific insights and alerts to computing device(s) authorized to view monitoring data for users corresponding to user device(s) 102, computing device(s) authorized to view monitoring data for users corresponding to user device(s) 102, the like, or some combination thereof. The analytics system 302 may further be enabled to deidentify the monitoring data for provision to the remote computing resource(s) 204, as discussed with respect to FIG. 2.

[0083] As illustrated in FIG. 3, the analytics system 302 includes gateway(s) 104 and edge computing resource(s) 202. Gateway (s) 104 and edge computing resource(s) 202 may incorporate any of the functionalities described above with respect to FIGS. 1-2. In some examples, gateway(s) 104 may communicate with edge computing resource(s) 202 through a local network (e.g., LAN, VPN, etc.), as will be discussed in more detail in FIGS. 2-6. For example, the edge computing resource(s) 202 may analyze monitoring data generated by individual user device(s) 102 and generate user-specific alerts and insights based on this data.

[0084] Communication between edge computing resource(s) 202 and gateway(s) 104 may be conducted with any acceptable wired or wireless protocol (e.g., ethemet, BLE, WiFi, etc.). Communication between edge computing resource(s) 202 and gateway(s) 104 may, in some examples, also employ VPN to improve security of the communications. Illustratively, Communication between edge computing resource(s) 202 and gateway (s) 104 may employ VPN over Wi-Fi, VPN over ethemet, the like, or some combination thereof.

[0085] In some examples, the analytics system 302 may represent physical hardware. Illustratively, the analytics system 302 may include a chassis within which various electronic components (e.g., processors, data storage, etc.) reside. In further examples, a portion of the electronic components may correspond to gateway (s) 104 and a distinct portion of the electronic components may correspond to the edge computing resource(s) 202. In other words, the chassis for analytics system 302 may include some electronic components specific to the gateway(s) 104 and some electronic components specific to the edge computing resource(s) 202.

[0086] Alternatively, the analytics system 302 may be a logical system implemented with physical hardware. For example, an on-premises network may include physical hardware (e.g., servers, data storage, etc.). This hardware may be used to implement the analytics system 302. Gateway(s) 104 and edge computing resource(s) 202 may run as containerized applications within the analytics sy stem 302.

[0087] As discussed with respect to FIG. 2, the user device(s) 102 may be any type of computing device configured for wireless communication. Each individual user device 102 may be configured to be carried, worn, or otherwise transported by a user. The user device 102 may collect monitoring data. Monitoring data may include indications of operational status of a user device 102 and / or health status of a user corresponding to the user device 102. Illustratively, monitoring data may include, but is not limited to physiological data (e.g., user temperature, ambient temperature, heat flux, etc.). Patterns in the physiological data may provide indications of health conditions or of operational malfunctions. Health events (e.g., sleep apnea events, heart attacks, etc.) may, for example, be reflected in patterns in the physiological data.

[0088] The user device 102 may also generate monitoring data specifically related to operational malfunctions. If the user device 102 is unable to communicate with a sensor collecting the physiological data, the user device 102 may generate log data including a message that the user device 102 is unable to communicate with a sensor. By way of illustration, the user device 102 may record events and errors as log data in local storage, such as EEPROM. The log data may be transferred to gateway 104 on establishing a connection with the user device 102. The log data may later be retrieved for diagnosis in the event of at least one failure (e.g., battery failure, communication failure, etc.) of the user device 102. The user device(s) 102 may provide monitoring data to analytics system 302, as will be discussed in more detail below.

[0089] Third-party device(s) 304 may be devices authorized to communicate with analytics system 302. Illustratively, the third-party device(s) 304 may include identifiers which the analytics system 302 recognizes as authorized to access services provided by analytics system 302, such as generation of insights and alerts based on monitoring data collected by the third-part}7device(s) 304. The monitoring data collected by third party device(s) 304 may also include data indicative of operational status of the third-party device(s) 304 and health status of individual users corresponding to third-party device(s) 304. For example, the monitoring data collected by third-party devices 304 may also include, but is not limited to, physiological data. The physiological data collected by the third-party device(s) 304 may relate to differentor fewer physiological parameters than the data collected by user device(s). In a non-limiting example, the physiological parameters collected by third-party' device(s) 304 may not include temperature data.

[0090] As another example, the third-party device(s) 304 may include different hardware (e.g., sensors, communication components, etc.) than the user device(s) 102. This may impact insights and alerts generated by the analytics system 302 with respect to operational status of the third-party device(s) 304. Illustratively, a third-party corresponding to a particular third-party device 304 might not provide hardware details for the particular third- party device 304. This may limit what insights the analytics system 302 can glean based on monitoring data for the particular third-party device 304.

[0091] In a non-limiting example, if the analytics system 302 is not aware of a sensor included in a third-party device 304, the analytics system 302 may not determine whether the sensor is malfunctioning. As another example, a user corresponding to the third- party device(s) 304, such as a patient, administrator, or other authorized party, might opt out of receiving insights and alerts relating to operational status. As yet another example, user corresponding to the third-party device(s) 304, such as a patient, administrator, or other authorized party, might only opt to receive specified insights on operational status, and the like. By way of illustration, the user for a particular third-party device 304 may specify to only receive alerts or insights relating to the operation of communication components used to facilitate communication between the particular third-party device 304 and analytics system 302.

[0092] As referenced above, the user device(s) 102 and or third-party device(s) 304 may provide monitoring data to the analytics system 302. The analytics system 302 includes gateway(s) 104 and edge computing resource(s) 202. Illustratively, a particular user device 102 or particular third-party device 304 and analytics system 302 may securely establish a communication channel on a private network. The communication channel may correspond with a unique identifier for the user device 102 or third-part}' device 304. The particular third- party device 304 may conduct more or different communications with analytics system 302 to establish the communication channel on the private network. For example, the third-party device 304 may include a key specific to a corresponding third party which it shares with the analytics system 302 to establish the communication channel. The analytics system 302 may handle establishment of the communication channels with gateway (s) 104, as described above with respect to FIG. 2. The private network may use any acceptable wireless communication protocol for communication (e.g., BLE, Wi-Fi, Thread, Matter, etc.).

[0093] In some examples, analytics system 302 may trigger upload of monitoring data from a user device 102, a third-party device 304, and the like, or some combination thereof. Analytics system 302 may analyze the monitoring data to determine when to trigger upload of the monitoring data from a user device 102, for example. Analytics system 302 may analyze the monitoring data to determine whether higher priority data is present. Analytics system 302 may, for example, review monitoring data for each individual user device 102, each individual third-part}' device 304, and the like, or some combination thereof. Analytics system 302 may, in further examples, identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.) as higher priority data. If the higher priority data is present, analytics system 302 may cause upload of monitoring data from an individual user device 102. However, if the higher priority data is not present, analytics system 302 may continue to upload monitoring data at regular intervals from the individual user device 102, as one example.

[0094] In some examples, analytics system 302 may trigger transfer monitoring data from an individual user device 102, third-party device 304, and the like, or some combination thereof, based on prior monitoring data from the individual user device 102. Analytics system 302 may, for example, obtain monitoring data from an individual user device 102 as part of a monitoring cycle. Analytics system 302 may, for example, obtain monitoring data from the individual user device 102 at regular intervals. Prior monitoring data may, for example, include areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). Analytics system 302 may identify this data in the prior monitoring data. Analytics system 302 may subsequently trigger an out of cycle transfer of monitoring data from the user device 102. Analytics system 302 may, for example, cause the user device 102 to transfer monitoring data between the regular intervals for obtaining monitoring data from the user device 102.

[0095] As another example, user device 102, third-party device 304, and the like, or some combination thereof, may include a functionality to detect health events. An individual user device 102 may, for example, identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). The individual user device 102 may then trigger transfer of monitoring data in response to identifying signals indicating a health event. The individual user device 102 may then trigger transfer of monitoring data to analytics system 302, for example.

[0096] In some examples, analytics system 302 may communicate with remote computing resource(s) 204, where remote computing resource(s) 204 may generate updated ornew tools based on monitoring data. To preserve user privacy, the analytics system 302 may deidentify monitoring data prior to providing the monitoring data to the remote computing resource(s). Illustratively, after receipt of monitoring data corresponding to a user device 102 or third-party device 304, the analytics system 302 may deidentify the monitoring data by removing any unique identifiers for the user device 102 or third-party device 304. The analytics system 302 may additionally, or alternatively, deidentify the monitoring data by adding noise when conducting analytics, where the noise may be created by a random number generator (e.g., a hardware-based random number generator, a pseudorandom number generator, etc.). The noise may alternatively be padding values, such as ones or zeros. The analytics system 302 may be add the noise in a way that preserves the overall statistical properties of the data but obscures the contributions of individual records.

[0097] In some examples, the analytics system 302 may deidentify the monitoring data for the user corresponding to the user device 102 or for the user corresponding to the third- party device 304. In some examples, analytics system 302 may provide the deidentified monitoring data to the remote computing resource(s) 204 in batches including monitoring data for more than one user device 102 or third-party device 304. In some examples, the deidentified monitoring data may be provided at scheduled intervals, such as intervals specified by an administrator for the remote computing resource(s) 204 or intervals specified by an administrator for the analytics system 302.

[0098] The analytics system 302 may additionally, or alternatively, communicate with remote computing resource(s) 204 to update its tools. Illustratively, the analytics system 302 may check for updated or new tools in the remote computing resource(s) 204 at intervals. If updated or new tools are present, the analytics system 302 may update or add tools corresponding with updates or additional tools present in remote computing resource(s) 204. As another example, the remote computing resource(s) 204 may notify the analytics system 302 when updated tool(s) or new tool(s) are present. The analytics system 302 may then download the updated or new tool(s) for use in analysis. In some examples, the analytics system 302 may handle communications with the remote computing resource(s) 204 with edge computing resource(s) 202, as described above with respect to FIG. 2.

[0099] Analytics system 302 may be mobile or static with respect to user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204. In some examples, analytics system 302 may be static with respect to any of user device(s) 102, third- party device(s) 304, and remote computing resource(s) 204. In further examples, the analytics system 302 may be included in a single area of a facility, such as a room in a building (e.g.,smart home, hospital, etc ), a set of rooms in a building (e.g., a smart home, hospital, etc.), a set of buildings, or the like. The user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may move in relation to this single area and continue to communicate with analytics system 302 as discussed above and as will be discussed in FIGS.4- 6 below. Additionally, or alternatively, the user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may be included within the same area as the analytics system 302. Illustratively, a user device 102 may be in the same building as analytics system 302. However, user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may still move in relation to this analytics system 302 and continue to communicate with analytics system 302. With continued reference to the illustrative example, the user device 102 may move around the rooms of the building that also houses analytics system 302.

[0100] In some examples, analytics system 302 may be mobile with respect to any of user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204. In a particular non-limiting example, the analytics system 302 may be included in a vehicle (e.g., plane, train, automobile, ship, etc.). The user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may move in relation to this vehicle and continue to communicate with analytics system 302 as discussed above and as will be discussed in FIGS. 4-6 below. Additionally, or alternatively, the user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may be included in the same vehicle as the analytics system 302. However, user device(s) 102, third-party device(s) 304, and remote computing resource(s) 204 may still move in relation to this analytics system 302 and continue to communicate with analytics system 302.Analysis of Monitoring Data

[0101] FIG. 4 illustrates an example method 400 for issuing alerts based on monitoring data. As discussed with respect to FIGS. 2-3, the monitoring data may be communicated through a local network utilizing any applicable protocol, such as BLE, Thread, Matter, or the like, or some combination thereof. Analyzing monitoring data within a local network may reduce latency in receipt and analysis of the monitoring data. Reduction of latency may advantageously improve determination of status (e.g., operational status, health status, etc.) relating to a device (e.g., user device 102, third-party device 304, etc.). Moreover, if a local network is a private network, where a private network is not open to the public, then privacy of user-specific monitoring data is also improved. Accordingly, the method 400 mayimprove determination of status (e.g., operational status, health status, etc.) relating to a device (e.g., user device 102, third-party device 304, etc.) in situations including, but not limited to, time-critical trauma situations (e.g., an ambulance, a battlefield, natural disaster rescue, firefighter rescue, etc.), high security situations (e.g., chemical, biological, radiological, nuclear, and explosive (CBRNE) threat detection), assessing disease vector risk (e.g., flight disease vector risk), in privacy-assured home health monitoring, in crowd / audience engagement (e.g., in a stadium), in bio-feedback for virtual interactive games and applications, the like, or some combination thereof. Other situations are also possible. For example, the method 400 may be used to assess alertness and / or exhaustion. Assessment of alertness will be discussed in more detail below with respect to FIG. 5. The method begins at block 402. In some examples, the method 400 may be implemented by analytics system 302.

[0102] At block 404, the analytics system 302 may receive monitoring data through a local network (e.g., LAN). Communications through the local network may utilize any applicable wired or wireless protocol including, but not limited to, ethemet, BLE, Wi-Fi, Thread, Matter, or the like, or some combination thereof. Monitoring data may be provided to the analytics system 302 by user device(s) 102 and / or third-party device(s) 304, as discussed above with respect to FIGS. 2-3. As a reminder, monitoring data may include indications of health status or operational status, as will be discussed in more detail at block 406 below.

[0103] Turning back to establishing communications with the analytics system 302, the analytics system 302 may set up separate communication channels to receive communication from each user device 102 and each third-party device 304. The communication channels may be established after authorization of each device (e.g., user device(s) 102, third-party device(s) 304, etc.) based on one or more unique identifiers. By way of illustration, each user device 102 may correspond to a unique identifier. Each third-party device 304 may also correspond to at least one unique identifier. The unique identifier may indicate the party associated with the device (e.g., user device(s) 102, third-party device(s) 304, etc.) For example, the unique identifier for a particular third-party device 304 may include an indication of the third-party corresponding to the particular third-party device 304. The unique identifier may further serve to identify the particular third-party device 304 itself. As another example, third-party device(s) 304 may correspond to a first unique identifier to identify the particular third-party device 304 and a second unique identifier to identify the third party corresponding to the third-party device 304.

[0104] Once established, the communication channels may be isolated with respect to each other. Illustratively, the communications for a user device 102 corresponding to a firstunique identifier may not come into contact with communications for a user device 102 corresponding to a second unique identifier. As another example, the communications for a user device 102 corresponding to a first unique identifier may not come into contact with communications for a third party device 304 corresponding to a second unique identifier. As yet another example, the communications for a third party device 304 corresponding to a first unique identifier may not come into contact with communications for a third party device 304 corresponding to a second unique identifier. The isolation between communication channels may advantageously allow for improved security of user-specific data. In some examples, analytics system 302 may handle receipt of monitoring data with gateway(s) 104, as discussed above with respect to FIGS. 2-3. However, other components may also be used. Illustratively, the edge computing resource(s) 202 may handle receipt of monitoring data. In a non-limiting example, the edge computing resource(s) 202 may directly receive monitoring data from user device(s) 102 and / or third-part ' device(s) 304. The edge computing resource(s) 202 may then analyze the monitoring data. The edge computing resource(s) 202 may then analyze the monitoring data using any of the methods described herein, at least with respect to FIG. 2-3. Illustratively, the edge computing resource(s) 202 may determine whether alerts relating to operational status of the device transmitting the monitoring data (e.g., user device(s) 102, third- party device(s) 304, etc.) or user corresponding to the device should be issued.

[0105] As another example, edge computing resource(s) 202 may analyze the monitoring data to determine a priority of data present within the monitoring data. Data may be higher priority, for example, if it includes sensitive data. Sensitive data may, for example, include a health status. If a user associated with a user device 102 has a health event (e.g., a sleep apnea event, a heart attack, etc.), this may be considered sensitive data. Edge computing resource(s) may, for example, trigger an upload from a user device 102 when a health effect is detected using any of the methods described herein, at least with respect to FIGS. 2-3. As one example, edge computing resource(s) 202 may trigger transfer monitoring data from an individual user device 102, third-party device 304, and the like, or some combination thereof, based on prior monitoring data from the individual user device 102. Edge computing resource(s) 202 may, for example, obtain monitoring data from an individual user device 102 as part of a monitoring cycle. Edge computing resource(s) 202 may, for example, obtain monitoring data from the individual user device 102 at regular intervals. Prior monitoring data may, for example, include areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). Edge computing resource(s) 202 may identify this data in the prior monitoring data. Edge computing resource(s) 202 may subsequently trigger an out ofcycle transfer of monitoring data from the user device 102. Edge computing resource(s) 202 may, for example, cause the user device 102 to transfer monitoring data between the regular intervals for obtaining monitoring data from the user device 102.

[0106] As another example, user device 102, third-party device 304, and the like, or some combination thereof, may include a functionality to detect health events. An individual user device 102 may, for example, identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.). The individual user device 102 may then trigger transfer of monitoring data in response to identifying signals indicating a health event. The individual user device 102 may then trigger transfer of monitoring data to edge computing resource(s) 202, for example.

[0107] At block 406, the analytics system 302 may determine whether to issue an alert based on the monitoring data. As discussed at least in block 404, monitoring data may be received from user device(s) 102 or third-party device(s) 304. The analytics system 302 may access tools to facilitate analysis of the monitoring data, such as AWS Grafana. Illustratively, the analytics system 302 may access classification models trained to identify health status from physiological data included in the monitoring data. As another example, the analytics system 302 may access classification models trained to identify operational status from the monitoring data. Other tools may also be used. For example, the analytics system 302 may implement a watchdog functionality, as described above with respect to FIGS. 2-3.

[0108] As another example, the analytics system 302 may compare monitoring data against one or more thresholds. In further examples, the thresholds may be based on physiological parameters (e.g., user temperature, ambient temperature, heat flux, etc.) Based on the comparison, the analytics system 302 may determine at least one of an operational status corresponding to the device (e.g., user device(s) 102, third-party device(s) 304, etc.) In a nonlimiting example, the analytics system 302 may compare the ambient temperature over a period of time to user temperature. If user temperature and ambient temperature are substantially similar over the period of time, then the analytics system 302 may determine that the operational status of the device (e.g., user device(s) 102, third-party device(s) 304, etc.) corresponding to the monitoring data is that the device is not being worn.

[0109] In some examples, the analytics system 302 may handle the analysis of monitoring data with edge computing resource(s) 202. For example, edge computing resource(s) 202 may have access to physical or virtual computing resource(s) to implement analysis of the monitoring data. Illustratively, the edge computing resource(s) 204 may be able to implement specific tools for analysis of the monitoring data, such as classification modelstrained to identify health status from physiological data, classification models trained to identify health status from physiological data included in the monitoring data, threshold comparison tools, the like, or some combination thereof. However, other components may also be used. As discussed above with respect to FIGS. 2-3, gateway(s) 104 may implement watchdog functionality. Accordingly, the gateway(s) 104 may also determine an operational status for a device (e.g., user device(s) 102, third-party device(s) 304, etc.) corresponding to monitoring data under analysis.

[0110] Based on any determined operational status or health status, the analytics system 302 may determine to generate alerts and / or insights. The alert may include an indication of the status (e.g., the device is not being worn). Insights may include a recommendation to resolve issues relating to the status (e.g., put the device on). However, in some examples, the alert may include both an indication of the status and a recommendation to resolve issues relating to the status.[OlH] At block 408, the analytics system 302 may issue alerts. As discussed with respect to block 406, the alerts may include an indication of status, such as an indication of operational status of a device (e.g., user device(s) 102, third-party device(s) 304, etc.). The analytics system 302 may generate the alert in a format configured to alert the user on any authorized computing resource, such as user device(s) 102, third-party device(s) 304, speaker systems, phones, laptops, other computing devices, the like, or some combination thereof. The computing device may become authorized through any applicable authentication mechanism (e.g., a key exchange).

[0112] For example, the analytics system 302 may generate the alert as sound information (e.g., beep(s), song(s), etc.) to be played on the computing resource. The sound may be unique to a particular type of status (e.g., health status, operational status, etc.) As a non-limiting example, two beeps may be the sound corresponding to an alert indicating that that a user device 102 is not being worn. In further examples, one beep may be the sound corresponding to an alert indicating that a user device 102 is being worn incorrectly.

[0113] Additionally, or alternatively, the analytics system 302 may generate the alert as display information. Illustratively, each alert may be a pop-up message including the status relating to the alert. In a non-limiting example, an alert relating to a user device not being worn may be a pop-up box with the language “Device not being worn.” The display of the alert may use various colors, fonts, and the like. With reference to the previous example, the popup box may have a red interior, and the language may appear as bolded white text in the interior of the pop-up box.

[0114] In some examples, the analytics system 302 may issue insights in addition to, or in the alternative to, alerts. As a reminder, the insights may include recommendations on how to resolve the status corresponding to the alert. The insights may be generated in substantially the same format as the alerts. As a non-limiting example, the alert may be a popup box with language indicating the operational status of “Device is being worn incorrectly.” The pop-up box may further include a link for more information. Clicking on the link may open another pop-up with the insight of “Try tightening the strap.”

[0115] However, the insights may also be substantially different in format to the alerts. In a non-limiting example, the alert may be in the form of a sound configured to issue on a third-party device 304. In further examples, the insight may be in the form of display information configured to appear on a user interface (e.g., a browser, a software application, etc.) on another computing resource, such as a phone, laptop, the like, or some combination thereof.

[0116] The method 400 ends block 410. The method 400 may repeat. Illustratively, in some examples, the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc.). The analytics system 302 may accordingly repeat method 400 for each device as new data is received. As another example, the analytics system 302 may repeat method 400 at intervals (e.g., every 30 seconds, every minute, every 5 minutes, every 10 minutes, etc.).

[0117] While the example above indicated that the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third- party device(s) 304, etc.), this is not intended to be limiting. The analytics system 302 may also receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc.) at intervals. For example, each device (e.g., user device(s) 102, third-party device(s) 304, etc.) may establish a communication channel with the analytics system 302 at intervals to provide monitoring data in batches, where the batches include monitoring data for a period of time. The intervals may be separated by equal time periods. Alternatively, the intervals may be scheduled, such as by the user(s) corresponding to individual device(s) or by the analytics system 302. As another example, the intervals may be random.

[0118] While the description above references that the method 400 may be implemented by the analytics system 302, this is not intended to be limiting. Other components may also carry out the method 400. For example, as discussed with respect to FIG. 2, the analytics system 302 may not be used. Instead, the gateway(s) 104 and edge computingresource(s) 202 may be separated, as discussed in more detail in FIG. 2. In further examples, the edge computing resource(s) 202 may be used to implement the method 400.

[0119] As another example, the edge computing resource(s) 204 and gateway(s) 104 may each carry out different blocks of method 400. In further examples, the edge computing resource(s) 202 may analyze monitoring data and conduct method 400 with respect to determining health status for a user corresponding to a user device 102 or a third - party device 304. The gateway(s) 104 may concurrently, implement blocks 404 and 406 to determine whether to issue alerts with respect to operational status, and inform the edge computing resource(s) 202 of the determination. The edge computing resource(s) 202 may then implement block 408 and issue the alerts. Other components may also implement blocks of method 400. For example, the analytics system 302 may use a graphic user interface system generate the alerts.

[0120] FIG. 5 illustrates an example method 500 to generate alertness warnings based on monitoring data. As discussed with respect to FIGS. 2-4, the monitoring data may be communicated through a local network utilizing any applicable protocol, such as BLE, Thread, Matter, the like, or some combination thereof. Monitoring alertness within local network(s) may reduce latency in receipt and analysis of the monitoring data. Reduction of latency may advantageously improve assessment of the health status of a user corresponding to a device (e.g., user device(s) 102, third-party device(s) 304, etc.) in time-sensitive situations and / or situations where alertness is desired. Illustratively, the method 500 may be implemented in situations including, but not limited to hospitals (e.g., with respect to doctors, surgeons, etc.), in war zones (e.g., with respect to field medics, etc.), and vehicles (e.g., with respect to pilots, conductors, drivers, captains, etc.).

[0121] The method 500 begins at block 502. In some examples, the method 500 may be implemented by the analytics system 302. However, other resources may also be used to implement the method 500, as discussed with respect to block 410 of FIG. 4.

[0122] At block 504, the analytics system 302 may receive monitoring data from a device (e.g., user device 102, third-party device 304, etc.) in communication with a user (e.g., worn by the user, near the user, etc.), wherein the monitoring data includes at least some data indicative of alertness or from which an alertness determination can be made. The indication of alertness may be based on physiological data (e.g., user temperature, ambient temperature, heat flux, etc.). The monitoring data may further include a unique identifier associated with the device. The analytics system 302 may receive monitoring data with any of the methods described above with respect to FIG. 4 at block 404.

[0123] For example, the analytics system 302 may receive this data through a local network utilizing any applicable protocol, such as BLE, Thread, Matter, the like, or some combination thereof, where the local network may be a private network (e.g., not open to the public). Individual communication channels may be used for each device, which may serve to isolate communication channels with respect to each other. Illustratively, data flowing through a communication channel for a first device may not interact with data flowing through a communication channel for a second device. Use of local network(s) and / or individual communication channel(s) may serve to improve security of user-specific monitoring data thereby helping to ensure the user-specific monitoring data remains private. In some examples, analytics system 302 may trigger upload of monitoring data from a user device 102, a third- party device 304, and the like, or some combination thereof, using any of the methods described herein, at least with respect to FIGS. 2-4. Illustratively, analytics system 302 may identify areas with unusual signals indicating a health event (e.g., a sleep apnea event, a heart attack, etc.) as higher priority data. Analytics system 302 may identify areas with unusual signals indicating a health event based on prior monitoring data, for example. If the higher priority data is present, analytics system 302 may cause upload of monitoring data from an individual user device 102. However, if the higher priority data is not present, analytics system 302 may continue to upload monitoring data at regular intervals from the individual user device 102, as one example.

[0124] At block 506, the analytics system 302 may determine a level of alertness based on monitoring data and / or locally stored data. As discussed above, use of locally stored data may advantageously improve security of the monitoring data and latency with respect to determination of a level of alertness. To determine a level of alertness, the analytics system 302 may extract indications of alertness from the monitoring data with edge computing resources 202, as described above with respect to FIGS. 1-4. The edge computing resource(s) 202 may have access to locally stored data, such as data store(s) accessible through the local network. The data may be used to facilitate determination of a level of alertness from monitoring data. For example, the edge computing resource(s) 202 may include classification models trained to extract indications of alertness from the monitoring data. Based on these indications, the edge computing resource(s) 202 may determine a level of alertness.

[0125] Other methods are also possible. Illustratively, instead of extracting indications of alertness, the analytics system 302 may utilize edge computing resource(s) 202 to directly determine a level of alertness from the monitoring data. For example, the edge computing resource(s) 202 may include classification models trained to directly determine alevel of alertness from the monitoring data. Application of these models to received monitoring data may generate a level of alertness for the monitoring data.

[0126] At block 508, the analytics system 302 may determine whether to issue an alertness warning based on the level of alertness. In some examples, the analytics system 302 may handle this determination with edge computing resource(s) 202. Edge computing resource(s) 202 may have access to locally-stored data, as discussed above with respect to block 506. The locally -stored data may include one or more threshold(s) relating to the level of alertness. The threshold(s) may define an acceptable range for levels of alertness. The edge computing resource(s) 202 may compare the determined level of alertness to this range. If the comparison provides that the determined level of alertness is outside the acceptable range defined by the threshold(s), then the edge computing resource(s) 202 may determine that an alertness warning should be issued.

[0127] At block 510, the analytics system 302 may issue the alertness warning. The analytics system 302 may generate the warning in a format configured for any authorized computing resource, such as user device(s) 102, third-part ' device(s) 304, speaker systems, phones, laptops, other computing devices, the like, or some combination thereof. The analytics system 302 may generate and issue the alertness warning using any of the methods described above with respect to FIG. 4 at block 408.

[0128] The method 500 ends at block 512. The method 500 may repeat. Illustratively, in some examples, the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc.). The analytics system 302 may accordingly repeat method 500 for each device as new data is received. As another example, the analytics system 302 may repeat method 500 at intervals (e.g., every 30 seconds, every minute, every 5 minutes, every 10 minutes, etc.).

[0129] While the example above indicated that the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third- party device(s) 304, etc.), this is not intended to be limiting. The analytics system 302 may also receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc.) at intervals. For example, each device (e.g., user device(s) 102, third-party device(s) 304, etc.) may establish a communication channel with the analytics system 302 at intervals to provide monitoring data in batches, where the batches include monitoring data for a period of time. The intervals may be separated by equal time periods. Alternatively, the intervals may be scheduled, such as by the user(s) corresponding to individual device(s) or by the analytics system 302. As another example, the intervals may be random.

[0130] While the description above references that the method 500 is implemented by the analytics system 302, this is not intended to be limiting. Other components may also carry out the method 400. For example, as discussed with respect to FIG. 2, the analytics system 302 may not be used. Instead, the gateway(s) 104 and edge computing resource(s) 202 may be separated, as discussed in more detail in FIG. 2. In further examples, the edge computing resource(s) 202 may be used to implement the method 500. As another example, the edge computing resource(s) 204 and gateway (s) 104 may each carry out different blocks of method 500. Other components, such as a graphic user interface system may be used to carry out at least some blocks of method 500.

[0131] FIG. 6 illustrates an example method 600 to predict maintenance issues based on monitoring data. As discussed with respect to FIGS. 2-5, the monitoring data may be communicated through a local network utilizing any applicable protocol, such as BLE, Thread, Matter, the like, or some combination thereof. Monitoring operational status relating to individual devices (e.g., user device(s) 102, third-party device(s) 304, etc.) within local network(s) may reduce latency in receipt and analysis of the monitoring data. Reduction of latency may advantageously improve determination of maintenance issues of a device (e.g., user device(s) 102, third-party device(s) 304, etc.). Additionally, faster notification of a maintenance issue may lead to faster resolution of the maintenance issue. This may improve accuracy in determination of other types of statuses relating to monitoring data of a device (e.g., user device(s) 102, third-party device(s) 304, etc.), such as health status. Method 600 may be used in any of the situations described above with respect to FIGS. 4-5. Illustratively, in some examples, methods 500 and 600 may be concurrently implemented by analytics system 302. The method 600 begins at block 602.

[0132] At block 604, the analytics system 302 may receive monitoring data. At block 504, the analytics system 302 may receive monitoring data from a device (e.g., user device 102, third-party device 304, etc.) in communication with a user (e.g., worn by the user, near the user, etc.). As discussed with respect to FIGS. 2-4, the monitoring data may include indications of operational status, where operational status may include maintenance issues. The analytics system 302 may receive monitoring data with any of the methods described above with respect to FIG. 4 at block 404 and FIG. 5 at block 504. Illustratively, the analytics system 302 may utilize local network(s) and / or individual communication channels to access the monitoring data for one or more device(s) (e.g., user device(s) 102, third-party device(s) 304, etc.). As a reminder, use of local network(s) and / or individual communication channel(s) mayserve to improve security of user-specific monitoring data thereby helping to ensure the userspecific monitoring data remains private.

[0133] At block 606, the analytics system 302 may analyze monitoring data. For example, the analytics system 302 may analyze the monitoring data with a watchdog functionality, as described above with respect to FIGS. 1-3. After analysis with the watchdog functionality, the analytics system 302 may determine one or more operational status(es) for the device (e.g., user device 102, third-party device 304, etc.). In some examples, the analytics system 302 may handle analysis of the monitoring data with gateway(s) 104. Additionally, or alternatively, the analytics system 302 may handle analysis of the monitoring data with edge computing resource(s) 202.

[0134] At block 608, the analytics system 302 may predict maintenance issues based on at least one of the received monitoring data or analyzed monitonng data. The analytics system 302 may additionally utilize locally-stored data to predict maintenance issues. As discussed above, use of locally stored data may advantageously improve security of the monitoring data and latency with respect to determination of an operational status. To predict maintenance issues, the analytics system 302 may extract the indications of operational status relating to various maintenance issues from the monitoring data, as described above with respect to FIGS. 1-4. For example, the analytics system 302 may use edge computing resource(s) 202 to implement extraction of indications of operational status. As another example, the analytics system 302 may utilize edge computing resource(s) 202 to directly determine operational status from the monitoring data.

[0135] The operational status may correlate to one or more potential current or future maintenance issues. Illustratively, operational status indicating unusual sensor readings may predict a sensor failure in future. In further examples, the edge computing resource(s) 202 may predict that a maintenance issue of a failed sensor may occur in future.

[0136] At block 610, the analytics system 302 may determine steps to mitigate maintenance issues. In some examples, the analytics system 302 may use the edge computing resource(s) 202 to determine steps to mitigate predicted maintenance issues. With continued reference to the illustrative example described with reference to block 608, the edge computing resource(s) 202 may determine steps to replace the sensor corresponding to the unusual readings.

[0137] At block 612, the analytics system 302 may output steps to mitigate maintenance issues. The analytics system 302 may output the steps in a format configured for any authorized computing resource, such as user device(s) 102, third-party device(s) 304,speaker systems, phones, laptops, other computing devices, the like, or some combination thereof. The analytics system 302 may generate and issue the output using any of the methods described above with respect to FIG. 4 at block 408.

[0138] The method 600 ends at block 614. Illustratively, in some examples, the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc ). The analytics system 302 may accordingly repeat method 600 for each device as new data is received. As another example, the analytics system 302 may repeat method 600 at intervals (e.g., every 30 seconds, every minute, every 5 minutes, every 10 minutes, etc.).

[0139] While the example above indicated that the analytics system 302 may continuously receive monitoring data from one or more devices (e.g., user device(s) 102, third- party device(s) 304, etc.), this is not intended to be limiting. The analytics system 302 may also receive monitoring data from one or more devices (e.g., user device(s) 102, third-party device(s) 304, etc.) at intervals. For example, each device (e.g., user device(s) 102, third-party device(s) 304, etc.) may establish a communication channel with the analytics system 302 at intervals to provide monitoring data in batches, where the batches include monitoring data for a period of time. The intervals may be separated by equal time periods. Alternatively, the intervals may be scheduled, such as by the user(s) corresponding to individual device(s) or by the analytics system 302. As another example, the intervals may be random.

[0140] While the description above references that the method 600 is implemented by the analytics system 302, this is not intended to be limiting. Other components may also carry out the method 600. For example, as discussed with respect to FIG. 2, the analytics system 302 may not be used. Instead, the gateway(s) 104 and edge computing resource(s) 202 may be separated, as discussed in more detail in FIG. 2. In further examples, the edge computing resource(s) 202 may be used to implement the method 600. As another example, the edge computing resource(s) 204 and gateway (s) 104 may each carry out different blocks of method 600. Other components, such as a graphic user interface system may be used to carry out at least some blocks of method 600.Example Hardware

[0141] FIG. 7 schematically depicts an example analytics system 302. The general architecture of the analytics system 302 depicted in FIG. 7 includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. It will be understood that analytics system 302 may include more, fewer,and / or different components than those depicted in FIG. 7. Additionally, analytics system 302 may be implemented on more than one device. Illustratively, the analytics system 302 may be implemented on multiple physical hardware devices included in an on-premises network.

[0142] As illustrated, the analytics system 302 includes an internal system timer 704, a communication interface 706, processing system 708, a computer readable medium drive 710, and memory 712, all of which may communicate with each other by way of a communication bus. For example, the analytics system 302 may include more than one processing system. Illustratively, in a non-limiting example, the analytics system 302 may include a first processing system for analysis of monitoring data from a user device 102 for a user’s health status and a second processing system for analysis of the operational status of the user device 102. For example, the second processing system may determine a hardware status of the user device 102, an indication that the user device 102 is not being worn, or an indication that the user device 102 is being worn incorrectly, as discussed above.

[0143] The analytics system 302 may also include an internal system timer 704, such as an interval timer or oscillator. The internal system timer 704 may keep track of a true time (e.g., a time relative to a particular time zone), or may count seconds or other units of time that have passed since an event such as the last reset of an individual user device 102. In some examples, the internal system timer 704 may not be associated with any particular time zone (e.g., Coordinate Universal Time (UTC), Pacific Standard Time (PST), Eastern Standard Time (EST), Central Standard Time (CST)). In addition, the analytics system 302 may or may not have location sensing units (e.g., GPS).

[0144] Furthermore, the analytics system 302 may include a communication interface 706 and a processing system 708. The communication interface 706 may provide connectivity to one or more networks or computing systems, such as the user device(s) 102 or third party device(s) 304. The communication interface 706 may comprise a wireless communication device configured to send and receive signals in accordance with any suitable communication protocol, such as ethemet, Wi-Fi, BLE, Message Queuing Telemetry Transport (MQTT), Hypertext Transfer Protocol (HTTP), or the like. The processing system 708 may comprise one or more processors and receive information and instructions from other computing systems or services via a network. The processing system 708 may also communicate to and from a memory 712.

[0145] The connectivity' provided by the communication interface 706 may allow for internal communication between the gateways 104 and the edge computing resources 202. Connectivity provided by the communication interface 706 may allow for externalcommunication between edge computing resource(s) 202 and remote computing resource(s) 204. Connectivity provided by the communication interface 706 may further allow for external communication between user device(s) 102 or third-party device(s) 304 and the analytics system 302. Communication from the user device(s) 102 or third-party device(s) 304 may include physiological measurements taken by the wearable device in a processed format and / or in a raw data format. Communication from the analytics system 302 may include insights and alerts relating to the operational status of a particular user device 102 or the health status of a user in communication with the particular user device 102. The analytics system 302 may handle communications from user device(s) 102 or third-party device(s) 304 with gateway (s) 104, as described above.

[0146] The computer-readable medium drive 710 can be used to provide a direct connection to the analytics system 302. This connection can be used to communicate with the analytics system 302 and / or provide maintenance for the analytics system 302.

[0147] The memory 712 may include computer program instructions that are executed by a processing system 708 in order to implement one or more examples. The memory 712 generally includes RAM, ROM or other persistent or non-transitory memory. The memory 712 may store an operating system 718 that provides computer program instructions for use by the processing system 708 in the general administration and operation of the user device 102. The memory 712 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one example, the memory 712 includes instructions regarding the amount of storage to be used over a period of time.

[0148] In some examples, the memory 712 may include a storage for interface software 716. This may include information necessary for communication with one or more network devices by the communication interface 706. For example, the storage for interface software 716 may include identification information for gateway(s) 104, user device(s) 102, or third-party device(s) 304. The analytics system 302 can further include a data store 714 for physiological data and device timestamps, where the device timestamps may be generated by each individual user device(s) 102, or third-party device(s) 304.

[0149] Still further, the user device 102 can include a security component 720 for facilitating the validation and processing of security credentials of one or more gateway (s) 104, user device(s) 102 or third-party device(s) 304 themselves. The security component 720 may communicate with other components of the analytics system 302 to fulfill this functionality. For example, in some examples, the security component 720 may utilize software and data from the storage for interface software 716.Terminology and Other Considerations

[0150] All of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non- transitory computer-readable storage medium or device (e.g., solid state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions or may be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid-state memory chips or magnetic disks, into a different state. In some examples, the computer system may be a cloud-based computing system whose processing resources are shared by multiple distinct business entities or other users.

[0151] Depending on the example, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain examples, operations or events can be performed concurrently, e.g., through multi -threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.

[0152] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the examples disclosed herein can be implemented as electronic hardware, or combinations of electronic hardware and computer software. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, or as software that runs on hardware, depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[0153] Moreover, the various illustrative logical blocks and modules described in connection with the examples disclosed herein can be implemented or performed by a machine,such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another example, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. For example, some or all of the algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

[0154] The elements of a method, process, routine, or algorithm described in connection with the examples disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.

[0155] Conditional language used herein, such as, among others, "can," "could," "might," "may," “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain examples include, while other examples do not include, certain features, elements and / or steps. Thus, such conditional language is not generally intended to imply that features, elements and / orsteps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and / or steps are included or are to be performed in any particular example. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.

[0156] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain examples require at least one of X, at least one of Y, or at least one ofZ to each be present.

[0157] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C. Unless otherwise explicitly stated, the terms “set” and “collection” should generally be interpreted to include one or more described items throughout this application. Accordingly, phrases such as “a set of devices configured to” or “a collection of devices configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a set of servers configured to carry out recitations A, B and C” can include a first server configured to carry out recitation A working in conjunction with a second server configured to carry out recitations B and C.

[0158] While the above detailed description has shown, described, and pointed out novel features as applied to various examples, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain examples described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately fromothers. The scope of certain examples disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

WHAT IS CLAIMED IS:

1. A system for secure determination of health status, the system comprising: one or more edge computing resources in communication with at least one gateway via a network in communication with one or more user devices, the one or more edge computing resources comprising one or more processors configured by computer-executable instructions to: receive, via the at least one gateway, monitoring data from the one or more user devices; store the monitoring data in a local memory of the one or more edge computing resources; determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmit a notification associated with the status.

2. The system of Claim 1, wherein the status is a health status corresponding to a patient wearing the user device.

3. The system of Claim 2, wherein the monitoring data comprises heat flux measurements.

4. The system of Claim 3, wherein the one or more processors are configured by computer-executable instructions to determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices, at least by determining the health status based on the heat flux measurements.

5. The system of Claim 4, wherein the health status comprises an indicator of exhaustion, fatigue, alertness, infection, or physical performance.

6. The system of Claim 3, wherein the status is an operational status of the user device.

7. The system of Claim 6, wherein the operational status includes at least one of a hardware status of the user device; an indication that the user device is not being worn, or an indication that the user device is being worn incorrectly.

8. The system of Claim 3, wherein the one or more edge computing resources are located in a first facility that remains stationary with respect to a geographic location, and wherein the at least one gateway is located in one or more mobile facilities.

9. The system of Claim 8, wherein at least one of the one or more mobile facilities comprises a vehicle.

10. The system of Claim 3, wherein the one or more edge computing resources and the at least one gateway are located in a stationary facility.

11. The system of Claim 10, wherein the stationary facility comprises a residence or a healthcare facility.

12. The system of Claim 3, wherein the one or more processors are further configured to update data within the one or more edge computing resources based on data received from one or more remote computing resources, the data comprising one or more updated algorithms for analyzing received monitoring data.

13. The system of Claim 3, wherein the one or more processors are further configured to deidentify at least a portion of the stored monitoring data for provision to one or more remote computing resources in communication with the one or more edge computing resources via a wide area network.

14. The system of Claim 3, wherein the one or more processors are configured to receive the monitoring data utilizing Thread, and wherein the user device utilizes Matter.

15. The system of Claim 1, wherein the one or more processors are configured to trigger transfer of the monitoring data from the user device based on identification of a health event within prior monitoring data.

16. The system of Claim 1, wherein prior to receiving, via the at least one gateway, monitoring data, the user device identifies a health event within the monitoring data, and wherein the user device triggers transfer of the monitoring data to the gateway based on identification of the health event.

17. A computer-implemented method for secure determination of health status, the method comprising: receiving, at one or more edge computing resources from at least one gateway in communication with one or more user devices, monitoring data from the one or more user devices via a network; storing the monitoring data in a local memory of the one or more edge computing resources; determining, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmitting a notification associated with the status.

18. The computer-implemented method of Claim 17, wherein the status is a health status for a patient wearing the user device.

19. The computer-implemented method of Claim 17, wherein the monitoring data comprises heat flux measurements.

20. The computer-implemented method of Claim 19, wherein determining, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices, comprises determining the health status based on the heat flux measurements.

21. The computer-implemented method of Claim 20, wherein the health status comprises an indicator of exhaustion, fatigue, alertness, infection, or physical performance.

22. The computer-implemented method of Claim 17, wherein the status is an operational status of the user device.

23. The computer-implemented method of Claim 22, wherein the operational status includes at least one of a hardware status of the user device; an indication that the user device is not being worn, or an indication that the user device is being worn incorrectly.

24. The computer-implemented method of Claim 17, wherein the one or more edge computing resources are located in a first facility that remains stationary with respect to a geographic location, and wherein the at least one gateway is located in one or more mobile facilities.

25. The computer-implemented method of Claim 25, wherein at least one of the one or more mobile facilities comprises a vehicle.

26. The computer-implemented method of Claim 17, wherein the one or more edge computing resources and the at least one gateway are located in a stationary facility.

27. The computer-implemented method of Claim 26, wherein the stationary facility comprises a residence or a healthcare facility.

28. The computer-implemented method of Claim 17, further comprising deidentifying at least a portion of the stored monitoring data for provision to one or more remote computing resources in communication with the one or more edge computing resources via a wide area network.

29. The computer-implemented method of Claim 17, further comprising updating data within the one or more edge computing resources based on data received from one or more remote computing resources, the data comprising one or more updated algorithms for analyzing received monitoring data.

30. The computer-implemented method of Claim 17, wherein the monitoring data is received utilizing Thread, and wherein the user device utilizes Matter.

31. The computer-implemented method of Claim 17, further comprising triggering transfer of the monitoring data from the user device based on identification of a health event within prior monitoring data for the user device.

32. The computer-implemented method of Claim 17, wherein prior to receiving, via the at least one gateway, monitoring data, the user device identifies a health event within the monitoring data, and wherein the user device triggers transfer of the monitoring data to the gateway based on identification of the health event.

33. A non-transitory computer-readable medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by one or more processors, cause the one or more processors to: receive, at one or more edge computing resources from at least one gateway in communication with one or more user devices, monitoring data from the one or more user devices via a network; store the monitoring data in a local memory of the one or more edge computing resources; determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices; and transmit a notification associated with the status.

34. The computer-readable medium of Claim 33, wherein the status is a health status for a patient wearing the user device.

35. The computer-readable medium of Claim 34, wherein the monitoring data comprises heat flux measurements.

36. The computer-readable medium of Claim 35, wherein the computer executable instructions, when executed by the one or more processors, cause the one or more processors to determine, based on analyzing the stored monitoring data, a status corresponding to a user device of the one or more user devices, at least by determining the health status based on the heat flux measurements.

37. The computer-readable medium of Claim 36, wherein the health status comprises an indicator of exhaustion, fatigue, alertness, infection, or physical performance.

38. The computer-readable medium of Claim 31, wherein the status is an operational status of the user device.

39. The computer-readable medium of Claim 36, wherein the operational status includes at least one of a hardware status of the user device; an indication that the user device is not being worn, or an indication that the user device is being worn incorrectly.

40. The computer-readable medium of Claim 33, wherein the one or more edge computing resources are located in a first facility that remains stationary with respect to a geographic location, and wherein the at least one gateway is located in one or more mobile facilities.

41. The computer-readable medium of Claim 40, wherein at least one of the one or more mobile facilities comprises a vehicle.

42. The computer-readable medium of Claim 33, wherein the one or more edge computing resources and the at least one gateway are located in a stationary facility.

43. The computer-readable medium of Claim 42, wherein the stationary facility comprises a residence or a healthcare facility.

44. The computer-readable medium of Claim 33, wherein the instructions further cause the one or more processors to deidentify at least a portion of the stored monitoring data for provision to one or more remote computing resources in communication with the one or more edge computing resources via a wide area network.

45. The computer-readable medium of Claim 33, wherein the instructions further cause the one or more processors to update data within the one or more edge computing resources based on data received from one or more remote computing resources, the data comprising one or more updated algorithms for analyzing received monitoring data.

46. The computer-readable medium of Claim 33, wherein the instructions further cause the one or more processors to trigger transfer of the monitoring data from the user device based on identification of a health event within the monitoring data the user device.

47. The computer-readable medium of Claim 33, wherein prior to receiving, via the at least one gateway, monitoring data, the user device identifies a health event within the monitoring data, and wherein the user device triggers transfer of the monitoring data to the gateway based on identification of the health event.

Images