CN112468972A

CN112468972A - Sensor data for identifying disaster areas

Info

Publication number: CN112468972A
Application number: CN201910844474.7A
Authority: CN
Inventors: 胡月华
Original assignee: Individual
Current assignee: Individual
Priority date: 2019-09-06
Filing date: 2019-09-06
Publication date: 2021-03-09

Abstract

A computer-implemented method of generating an automatic response to a catastrophic event, comprising (1) analyzing a set of data samples generated in connection with the catastrophic event to determine a threshold pattern; (2) receiving home sensor data from the smart home controller by wireless communication or data transmission, the home sensor data including (i) a structural state, in case of customer approval or affirmative approval; (ii) wind speed; (iii) at least one data in power availability; (iv) water is present; (v) (ii) temperature; (vi) pressure; and/or (vii) air and/or water; (3) analyzing the home sensor data according to or through a computer to determine whether the home sensor data matches a threshold pattern; (4) a response is automatically generated if the home sensor data indicates a match to the threshold pattern. Thus, the catastrophic event and its response can be improved by using a remote network of home sensors.

Description

Sensor data for identifying disaster areas

Technical Field

The present invention relates generally to an apparatus and method for identifying disaster areas using sensor data.

Background

Detection and response of catastrophic events has traditionally relied upon public emergency detection and reporting sensor networks, such as integrated public warning and alert systems and emergency alert systems. However, such public infrastructure is specifically designed and may not be optimized for other uses in view of certain needs, namely public safety and alarm notification. Furthermore, the underlying data collected by public systems may not be publicly available in a useful format. Furthermore, the public infrastructure may be low-priced, which may result in incomplete coverage of data related to the geographic area of interest or the type of detectable event. Accordingly, there is a need for an improved system for detecting and responding to catastrophic events.

Disclosure of Invention

Embodiments of the present technology relate to computer-implemented methods, computing devices, and computer-readable media for detecting and responding to catastrophic events. Embodiments provide for receiving data generated by a plurality of sensors located within and around a plurality of houses or other structures, comparing the data to known thresholds or patterns indicative of catastrophic events, and generating responses or operational instructions if, for example, a catastrophic event is displayed. Embodiments may allow for improved event detection and tracking-for example, if the system automatically reconfigures the remote sensor network or data collection mechanism to improve the clarity of data around an event or possibly improve the efficiency and accuracy of event remediation responses.

In a first aspect, a computer-implemented method of tracking a catastrophic event with a remote sensor network is provided. The method may include receiving and comparing a first set of event data to an event threshold to determine that the event threshold has been exceeded. A geographic boundary of an area associated with the first set of event data may also be determined. The boundary may include a plurality of sensors positioned within and around a plurality of structures such as a house. A data reception mode may also be determined based on the first set of event data, and a data file may be initialized to receive a second set of event data containing sensor data from a plurality of sensors based on the reception mode. The sensor data may then be received into a data file. Thus, data collection regarding catastrophic events may be improved, preferably by optimizing the system components and functionality for the event type and using a "private" sensor network to replace or supplement the public emergency notification system. The method may include additional, fewer, or alternative actions, including those discussed elsewhere herein.

In another aspect, a computer-implemented method for detecting and generating an automated response to a catastrophic event may be provided. The method may include setting an event threshold for a first event type and configuring to compare to event data. The event data may be analyzed to determine that the event data has exceeded an event threshold and that a first event type has occurred. Geographic boundaries of the area associated with the event data may be identified and may include a plurality of sensors positioned within and around a plurality of houses. The response may be automatically generated based on the first event type and the geographic boundary. Thus, the efficiency and accuracy of the remedial response to a particular type of event may be improved and/or the impact of the event on personnel or property may be mitigated. The method may include additional, fewer, or alternative actions, including those discussed elsewhere herein.

In another aspect, a computer-implemented method can be provided to generate an automated response to a disaster event. The method may include analyzing a set of data samples generated in association with a catastrophic event to determine a threshold pattern. Home sensor data may also be collected/received from the smart home controller via wireless communication or data transmission. The home sensor data may include at least one of the following: (i) a structural state; (ii) wind speed; (iii) availability of electricity; (i v) the presence of water; (v) (ii) temperature; (vi) pressure; or (vii) the presence of contaminants in the air or water. Home sensor data can be analyzed with reference to threshold patterns to determine if a match exists (indicating that a catastrophic event occurred or is likely to occur). If there is a match, a response is automatically generated. Thus, data collection regarding catastrophic events may be improved, preferably by optimizing event types and using a "private" sensor network to replace or supplement a public emergency notification system. The method may include additional, fewer, or alternative actions, including those discussed elsewhere herein.

The advantages of these and other embodiments will become apparent to those skilled in the art from the following description of the exemplary embodiments, which is illustrated and described by way of illustration. The present embodiments described herein are capable of other and different embodiments, and its details are capable of modification in various respects, as will be apparent. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

Drawings

The figures described below depict various aspects of the devices and methods disclosed therein. It should be understood that each of the figures depicts one embodiment of a particular aspect of the disclosed apparatus and method, and that each of the figures is intended to be consistent with possible embodiments thereof. Furthermore, where possible, the following description refers to reference numerals contained in the following figures, wherein features described in multiple figures are designated with identical reference numerals. The present embodiments are not limited to the precise arrangements and instrumentalities shown in the drawings.

FIG. 1 illustrates an exemplary system constructed in accordance with various embodiments, including a computing device configured to receive data from a plurality of sensors over a communication network;

FIG. 2 illustrates a plurality of exemplary sensors that may be used with the system of FIG. 1;

FIG. 3 illustrates, in block diagram form, various components of a computing device; and

FIG. 4 illustrates at least a portion of the steps of an exemplary computer-implemented method that may provide for generating an automated response to a catastrophic event.

The exemplary embodiments are shown in the drawings for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the systems and methods described herein may be employed without departing from the principles of the invention described herein.

Detailed Description

The present embodiments described in this patent application and other possible embodiments address computer-centric challenges or problems whose solutions must be rooted in computer technology and may be particularly relevant to devices.

And methods of tracking or generating automated responses to disaster events using remote sensor networks. A plurality of sensors may be installed in and around the house of the homeowner. The sensors may include motion or glass break detectors, contact sensors, door lock keypads, thermostats, security systems, anemometers, air pressure sensors, water sensors, air or water pollution detectors, and the like. The sensors may record data about the condition of the premises, such as glass breakage, power outage or other structural accident, or the presence of water/flood or other internal conditions, or physical measurements of external weather conditions and air or water pollution. In some embodiments, the sensors may detect conditions associated with external traffic, such as vehicles in the vicinity.

Data may be transmitted from the sensors to a central hub, which forwards the data to the computing device. At different time intervals, the computing device may compare the data to a predetermined threshold or pattern to indicate the presence of one or more catastrophic events. The computing device may also receive data from an external database, such as a weather tracking system maintained by a news service or the national weather service, and may also compare it to predetermined thresholds, patterns, or sensor data to improve the assessment of potential catastrophic events. The above results may lead to a reconfiguration of the sensor operation or data acquisition mode to improve the clarity of the data around the sensing event. The results may also or may result in an automated response, such as generating a list of affected people or suggesting that the panel be sent to a particular location.

Exemplary computing System

FIG. 1 depicts an exemplary environment in which embodiments of a computing device 10 for tracking or generating automatic responses to disaster events can be used. The computing device 10 may receive data from a plurality of sensors 12 installed in and around the home of the house. The sensors 12 may transmit data to the central hub 14, which in turn, the central hub 14 transmits the data to the computing device 10 over the communication network 16.

The sensors 12 may be distributed within and around the homeowner's house or may be carried by the homeowner or other inhabitants of the house. An exemplary sensor 12 is shown in FIG. 2, but may include other sensors known for detecting physical conditions, attributes, or changes associated with detection of a catastrophic event. The sensors 12 may include glass break sensors mounted on windows or walls to detect when glass breaks, thermostats to detect and set room temperature, anemometers to detect wind speed, water alarms or levels to detect the presence, current sensors or the like, sensors for detecting available electricity, infrared or other motion on house circuits, sensors for detecting the presence of vehicles, air or water pollution detectors, or other similar sensors to detect structure, weather, electrical or traffic related information.

The sensors 12 each include communication hardware that allows the sensors 12 to communicate by wire or wirelessly with a central hub 14, which is typically located in the premises. In other embodiments, the central hub 14 is not available and each sensor 12 may communicate directly with the communication network 16.

For example, each sensor 12 may record the time at which the activity occurred with a (time) timestamp, such as the time at which a wind condition occurred, the time at which a glass break was detected, the time at which the circuit was powered off, and the like. After the event occurs or at a predetermined time interval, the sensor 12 may send event data, for example in a data packet, including an identification of the sensor 12, a timestamp of the occurrence of the activity, and an indication of the recorded activity and its size, as applicable (e.g., "wind speed" and "12 mph," respectively). This event data may be transmitted to the central hub 14 or computing device 10 (e.g., event data is transmitted to an insurance provider remote server for analysis based on event thresholds to determine if an event has occurred or to establish a data reception mode).

The central hub 14 may include a plurality of ports (wired, wireless, or both) configured to receive data from the sensors 12 and at least one output port configured to transmit data to the communication network 16. The central hub 14 may also include buffering or other temporary data storage functions. Once the central hub 14 receives the data from the sensors 12, or at predetermined intervals, the central hub 14 may transmit the data to the computing device 10 over the communication network 16. In certain embodiments, the central hub 14 includes a smart home controller.

The communication network 16 generally allows communication between the hub 14 and the computing device 10, or directly from the sensors 12 to the computing device 10. The communication network 16 may include a local area network, a metropolitan area network, a wide area network, a cloud network, the internet, etc., or a combination thereof. The communication network 16 may be wired, wireless, or a combination thereof, and may include components such as switches, routers, hubs, access points, and the like. The sensors 12 may be connected to the communication network 16 by wires (e.g., cables or fiber optic cables) or wirelessly.

For example, Radio Frequency (RF) communications using a wireless standard, such as bluetooth, or Institute of Electrical and Electronics Engineers (IEEE) 802.11. In one embodiment, the sensors 12 may be wireless radio frequency communication or other sensors with each other, using a hub 14 or smart home controller, a communication network 16, an external computing device 10 or remote server, a user mobile device (e.g., a smartphone, a smartwatch, a wearable electronic device, etc.), or a smart vehicle via a wireless link, node, or access point.

Computing device 10 may be embodied by a workstation computer, desktop computer, laptop computer, palmtop computer, laptop computer, tablet computer or tablet computer, application server, database server, file server, Web server, or the like, or a combination thereof. As shown in FIG. 3, computing device 10 may generally include a communication element 18, a memory element 20, and a processing element 22.

The communication element 18 generally allows the computing device 10 to receive data from the communication network 16. The communication element 18 may include signal or data transmission and reception circuitry such as antennas, amplifiers, filters, mixers, oscillators, Digital Signal Processors (DSPs), and so forth. The communication element 18 may establish wireless communication using radio frequency signals or data compliant with a communication standard (e.g., cellular 2G, 3G, or 4G), an IEEE 802.11 standard (e.g., WiFi), an IEEE 802.16 standard (e.g., WiMax, bluetooth), or a combination thereof. In addition, communication element 18 may use communication standards such as Ant, Ant +, Bluetooth Low Energy (BLE), Industrial, scientific, and medical (ISM) band (2.4 gigahertz (GHz), or the like. alternatively, or in addition, communication element 18 may establish communication via connectors or couplers that receive metallic wires or cables compatible with network technologies such as Ethernet.

The memory element 20 may include electronic hardware data storage elements such as Read Only Memory (ROM), programmable Read Only Memory (ROM), erasable programmable Read Only Memory (ROM), Random Access Memory (RAM) such as static RAM (sram) or dynamic RAM (dram), cache memory, a hard disk, a floppy disk, an optical disk, flash memory, a thumb drive, a Universal Serial Bus (USB) drive, and the like, or combinations thereof. In some embodiments, the memory element 20 may be embedded or packaged in the same package as the processing element 22. The memory element 20 may include or constitute a "computer-readable medium". Memory element 20 may store instructions, code segments, software, firmware, programs, applications, services, daemons, etc. that are executed by processing element 22. The memory element 20 may also store settings, data, documents, sound files, photographs, movies, images, databases, etc.

The processing elements 22 may include electronic hardware components such as processors, microprocessors (single and multi-core), microcontrollers, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), analog or digital Application Specific Integrated Circuits (ASICs). Or the like or combinations thereof. Processing element 22 may generally execute, process, or execute instructions, code segments, software, firmware, programs, applications, processes, services, daemons, and the like. Processing element 22 may also include hardware components such as finite state machines, sequential logic, and combinational logic, as well as other electronic circuitry capable of performing the functions necessary for operation of the present invention. The processing elements 22 may communicate with other electronic elements over serial or parallel links including address buses, data buses, control lines, etc.

The processing element 22 may be configured or programmed to perform the following functions by hardware, software, firmware, or a combination thereof. The processing element 22 may receive data from the central hub 14 or the sensors 12 through the communication element 18. The processing element 22 may analyze data received from the premises (e.g., data received from a hub containing smart home controllers) at the permission or affirmative consent of the owner or resident.

At predetermined time intervals or upon receipt, the processing element 22 may parse, organize, analyze, or aggregate the event data. For example, every minute, hour, day, week, or month, the processing element 22 may analyze event data relating to the changing conditions and events therein and compare it to an event threshold to determine whether the data indicates that a catastrophic event is likely to occur or is likely to occur. The processing element 22 may also analyze the event data or analyze the event data to determine whether additional clarification of the event or possible event is needed, for example, additional or different event data may be needed at the sensor 12 to track or confirm the occurrence of the event.

If further clarification is required, the processing element 22 may determine a data reception pattern from the optimized event data to improve the tracking and evaluation of events or possible events. For example, the processing element 22 may determine the most likely or most likely type of event to occur by analyzing the event data and then determine a data profile or data reception pattern based on the most likely useful information in the event analysis process. In one embodiment, the event data may indicate the occurrence or likely occurrence of a first event type, which in turn may result in more frequent data collection/transmission. Or to prioritize one type of data over another, the optimized set of parameters for a given event type is referred to as a "data reception mode". This data reception mode may then result in initializing a data file for receiving such data and receiving such data in the file. The data received according to the data reception mode, or for clarity referred to herein as a "second set" of event data, is preferably sensor data received from a plurality of sensors located within and around a plurality of structures (e.g., premises).

In addition to initializing data files and receiving data according to a data reception mode, the processing element 22 may also generate operational instructions for the sensor 12 based on the analysis of the event data. For example, the sensors 12 may be instructed to make new configurations or parameters/settings to enable collection of data required for the data reception mode. The operating instructions may be formatted for direct transmission to the sensors 12 over the communication network 16. The operating instructions may also be formatted as a request to the operator of the sensor 12, for example, in a request format that specifies time, frequency, data type, and other parameters that the operator (e.g., a home alarm company) may use to adjust the sensor 12 or data collection method accordingly. Also, event data from the sensors 12 may be provided by an operator (e.g., a home alarm company) without departing from the spirit of the inventive concept. Preferably, the operator of the sensor 12 also provides metadata about certain types of event data, such as data about the placement of the building construction or its layout, to provide context for interpretation of the event data.

The event threshold may be set by processing element 22 by associating one or more attributes of the event data (preferably derived from a set of example data) with one or more event types. For example, a first event type may have one or more thresholds indicating its occurrence. The hurricane event type may be represented by a wind speed event threshold and a gas pressure event threshold. Alternatively, the hurricane event type may be represented by a single event threshold that contains a combination of these two attributes. The power outage event type may be represented by a single event threshold based on a single attribute of the event data (e.g., an availability metric in the premises). In this manner, the event threshold may be set with reference to one or more event types, and may be preset for periodic comparison with event data to determine whether such events are occurring or are likely to occur.

The event threshold may also be fine tuned by the processing element 22 to a threshold mode based on the particular set of sensors 12. For example, if a network of sensors 12 of known type and location is included in the sensor network, previous data collected from the area during the occurrence of a previous event may be analyzed to determine a more customized threshold pattern for that event type. Of course, the threshold pattern should allow for errors and natural variations, but should be fine tuned to identify a range and set of conditions that will typically occur during the occurrence of a particular event type in the area.

The processing element 22 may also access weather data, such as average wind speed data in tornado conditions, from a database configured to store such data. The processing element 22 may use the weather data in developing event thresholds or threshold patterns, which may be used as event data for comparison to the set event thresholds. Or may use weather data to confirm or deny the conclusion that the home sensor event data indicates that a catastrophic event occurred or is likely to occur in the future.

Preferably, the processing element 22 will also improve data collection and analysis by identifying geographic boundaries of areas associated with event data that trigger one or more event thresholds. The boundary may include areas that appear to be or may be affected by the type of event indicated by the threshold, and may include additional space along its boundary to allow for prediction errors, such as errors in predicting wind direction and storm motion direction. Identifying boundaries helps develop data reception patterns, threshold patterns, or operational specifications for the sensor 12. Identifying boundaries may also or alternatively inform the content of the automated response, such as by identifying areas that are expected to be affected by the event or suggesting areas that the responding person should go to. In addition, identifying boundaries may allow for identification of individual residents within the area, such as customers holding insurance policies, who may need to be contacted for potential damage or insurance claims, etc. In addition, the processing element 22 may receive data regarding insurance claims that the customer has filed in the area, and may cross-reference the event data with such claims to detect fraud or determine priority of responses.

The processing element 22 may further receive metadata about the house, such as metadata from other databases. For example, processing element 22 may receive such information from databases that store input information related to a premise owner insurance or similar application. The processing element 22 may receive information about the characteristics of the house, such as the address of the house, the age of the house, the building materials of the house, the layout of the house, the number of bedrooms and bathrooms, etc. This information may be helpful in providing context for interpretation of home sensor-derived event data. The processing element 22 may also receive information about the home or determine characteristics of the home by analyzing data (e.g., image, audio, infrared, motion, and sensor data) received from the home (e.g., from the hub 14 or other intelligent home controller).

Although the preferred embodiment relates to the generation, collection and analysis of home sensor data at the processor element 22, other types of data may be received and analyzed by the processor element 22. For example, sensor data (e.g., telematics data) may be generated by onboard sensors and collected by the intelligent vehicle controller/processor, received remotely over one or more radio frequency radio links on the external computing device 10 over the communications network 16. Further, sensor data (including but not limited to sensor data) may be generated by sensors installed on the mobile device (e.g., sensors or cameras within a smartphone) and received or collected remotely over one or more radio frequency radio links on the external computing device 10 over the communications network 16.

In addition to the above, once locally installed sensor data, in-vehicle sensor data, mobile device sensor data, or other data (e.g., weather forecast or weather data) is received at the external computing device 10 over one or more wireless links and the communication network 16, the external computing device 10 may apply one or more machine learning, object recognition, or optical character recognition techniques to the data to determine that (1) the sensor or other event data indicates that an event threshold has been exceeded or an event exists; (2) geographic boundaries of the area affected by the event (possibly based on GPS (global positioning system) data or coordinates); or (3) corrective measures or responses to the event, or an estimated or actual range of the event. For example, a machine learning program (or object recognition program) residing on a memory associated with computing device 10 may be trained on historical images and sensor data to determine an actual or estimated extent of a hurricane or other weather event or other disaster (e.g., previous or historical home, mobile device, or vehicle sensor data received before, during, and after the event). Thereafter, the computer device 10 may input the newly received home, mobile device, or vehicle sensor data into a trained machine learning program to determine (1) that an event threshold has been exceeded or that an event exists; (2) a geographic boundary of an area affected by the event; (3) corrective action or response to the event (e.g., generating and sending a notification to the user's mobile device (i) advising them to seek shelter, leave the path of the event (for mobile events, whether it be events), or take an alternate route, avoiding the area affected by the event (if driven by a vehicle), or (ii) determining an estimated loss amount of the insured asset within the area affected by the event and preparing a proposed insurance claim for review and approval by the insured.)

Example computer implementation method

Fig. 4 depicts a listing of steps of an exemplary computer-implemented method 100 for generating an automated response to a disaster event. The steps may be performed in the order shown in fig. 4, or may be performed in a different order. Further, some steps may be performed simultaneously, in reverse order. In addition, some steps may be optional. The steps of the computer-implemented method 100 may be performed by the computing device 10.

Referring to step 101, an event threshold or threshold pattern may be determined and set by processing element 22 in association with one or more event types. The event threshold may be set by associating one or more attributes of the event data with one or more event types, preferably derived from a set of example data. The sample data set may include data generated by a plurality of sensors 12. Alternatively, the sample data set may be received from an external database, such as a database storing weather-related data for previous catastrophic events. For example, a first event type may have one or more thresholds indicating its occurrence. The hurricane event type may be represented by a wind speed event threshold and a gas pressure event threshold. Alternatively, the hurricane event type may be represented by a single event threshold that contains a combination of these two attributes, such as a weighted sum of the two attributes. Volcanic events may be represented by air or water contaminant event thresholds. The power outage event type may be represented by a single event threshold based on a single attribute of the event data, such as an electrical availability metric in the house circuit. In this manner, event thresholds may be set for one or more event types, and may be preset for comparison with event data to determine whether such events are occurring or are likely to occur.

The event threshold may also be fine tuned by the processing element 22 to a threshold mode based on the particular set of sensors 12. For example, if a sensor network of known type and location is included in the sensor network, previous data collected from the area during the occurrence of a previous event type may be analyzed to determine a threshold pattern of event data. Of course, the threshold pattern should allow for errors and natural variations, but should be fine tuned to identify a range and set of conditions that will typically occur during the occurrence of a particular event type in the area.

Meteorological data collected from other sources may also be used, such as average wind speed data in tornado conditions published by the national weather service or other data obtained from databases configured to store such data. The weather data may be used to formulate event thresholds or threshold patterns, which may be used as event data for comparison with set event thresholds. Or may be used to confirm or deny the conclusion that the home sensor event data indicates that a catastrophic event occurred or is likely to occur in the future.

Referring to step 102, event data may be received from a network of sensors 12 or an external source (e.g., a database for storing weather-related data). The sensors 12 may be distributed within and around the premises of the homeowner. For example, each sensor 12 may record the time at which the activity occurred with a (time) timestamp, such as the time at which a wind condition occurred, the time at which a glass break was detected, the time at which the circuit was powered off, and the like. After the event occurs or at a predetermined time interval, the sensor 12 may send event data, for example in a data packet, including an identification of the sensor 12, a timestamp of the occurrence of the activity, and an indication of the recorded activity and its size, as applicable (e.g., "wind speed" and "12 mph," respectively). This event data may be transmitted to the central hub 14 or computing device 10 (e.g., transmitting the event data to an insurance provider remote server).

The sensors 12 each include communication hardware that allows the sensors 12 to communicate by wire or wirelessly with a central hub 14, which is typically located in the premises. In other embodiments, where a central hub 14 is not available, each sensor 12 may communicate directly with the communication network 16 via one or more radio links. The central hub 14 may include a plurality of ports (wired ports, wireless ports, or both) configured to receive data from the sensors 12, and at least one output port configured to transmit data to the communication network 16 (via one or more wireless links). The central hub 14 may also include buffering or other temporary data storage functions. Once the central hub 14 receives the data from the sensors 12, or at predetermined intervals, the central hub 14 may transmit the data to the computing device 10 over the communication network 16 via one or more wireless links. In certain embodiments, the central hub 14 includes a smart home controller. The communication network 16 generally allows communication between the hub 14 and the computing device 10, or directly from the sensors 12 to the computing device 10 over one or more radio links. The sensors 12 may be connected to the communication network 16 by wires (e.g., electrical or fiber optic cables) or wirelessly (by one or more wireless links). Event data from the sensor 12 may also be provided by an operator, such as a home alarm company, or by an operator, without departing from the spirit of the inventive concept.

Referring to step 103, the event data may be analyzed with reference to an event threshold or threshold pattern to determine that a threshold has been exceeded. For example, event data from the sensors 12 or weather-related databases may indicate that a particular wind speed was recorded at a specified location. The wind speed event data may be compared periodically, or when computing device 10 receives an event threshold (including a wind speed attribute) that indicates at least one event type, alone or in combination with other attributes. If the wind speed of the event data record meets or exceeds the event threshold, computing device 10 may determine that a receiving mode, an operational specification of sensor 12 or an automatic response should be generated,

or it may seek to confirm the decision using "supplemental information", described in further detail below, preferably an independent source of information.

Preferably, metadata about certain types of event data, such as data about building construction or sensor placement, is also collected, with reference to the layout thereof. This may help to provide context for interpretation of event data. For example, based on a gust, knowing the direction in which the window is facing, the type of window installed, and the age of the structure, it may be possible to inform the event data of a comparison to an event threshold, for example, by providing context for analyzing the event data to indicate glass breakage associated with the gust. These metadata may be collected from external databases, such as databases managed by service or material providers, home alarm companies, construction providers, and others.

Referring to step 104, data collection and analysis is preferably also improved by identifying geographic boundaries of areas associated with event data that exceed one or more event thresholds. The boundary may include areas that appear to be affected or likely to be affected by the type of event indicated by the threshold, and may include additional space along the boundary to allow for prediction errors, such as errors in predicting the wind type and direction of storm motion. Identifying boundaries helps to formulate a data reception pattern or operational specifications for the sensor 12. Identifying boundaries may also or alternatively inform the content of the automated response, such as by identifying areas that are expected to be affected by the event or suggesting areas that the responding person should go to. In addition, identifying boundaries may allow for identification of individual residents within the area, such as customers holding insurance policies, who may need to be contacted for potential damage or insurance claims, etc. In addition, data relating to insurance claims filed by customers in the area may be received and cross-referenced with event data to detect fraud or determine response priority.

Referring to step 105, the event data may be used to determine a data reception pattern, such determination preferably taking into account the geographic boundaries determined in step 104 and the network of sensors 12 enclosed thereby. The data reception pattern may be determined based on event data and may represent an optimal data collection method for improving tracking and evaluation of detected events or possible events. For example, the most likely occurrence or most likely occurrence of an event type may be determined by analyzing event data, and a data profile or data reception pattern may be determined based on information that is most likely to be useful in the event analysis of such event types. In one embodiment, event data may indicate the occurrence or likely occurrence of a first event type, which in turn may result in more frequent data collection/transmission or prioritizing one type of data over another type of data, or one type of sensor over another type, the optimized parameter set for a given event type being its preferred data reception mode.

The data reception mode may then result in initializing a data file for receiving the data and receiving the data in the file in step 106. Alternatively, in step 106, operational specifications for the sensor 12 may be generated based on the event data analysis. For example, sensors 12 within the geographic boundary determined in step 104 may indicate a new configuration or parameters/settings to enable collection of data required for the data reception mode. The operating instructions may be formatted for direct transmission to the sensors 12 over the communication network 16. The operating instructions may also be formatted as a request to the operator of the sensor 12, for example, in a request format that specifies time, frequency, data type, and other parameters that the operator (e.g., a home alarm company) may use to adjust the sensor 12 or data collection method accordingly.

Referring to step 107, a response to the catastrophic event may be automatically generated and may be included in a digital or printed report detailing the response. The response may take the following form: a set of investigators is proposed to be deployed to an area within the geographic boundary determined in step 104, a list of proposed customers or insurance claims within the geographic boundary, or a list of customer contact information that may be affected by the event.

One or more of the steps described above may optionally be implemented in conjunction with or by executing a machine learning program. The machine learning procedure may include curve fitting, a regression model builder, a convolutional or deep learning neural network, bayesian machine learning techniques, and the like. The machine learning program may associate patterns from the home sensor data with known events to inform the generation of data reception patterns or event thresholds. The form and content of the response or operational instructions to the sensor is iteratively improved by analyzing data regarding the effectiveness of these measures in terms of events and the like.

Other types of algorithms may also be applied to sensors, weather, and other data received, such as object recognition or optical character recognition techniques. In addition to home sensor data, vehicle sensor data and mobile device generated data may be collected and input into trained or other machine learning, object recognition or optical character recognition programs and techniques to identify events, geographic boundaries of events, and suggestions or responses to suggestions of events.

Example computer-implemented method for automatic response to catastrophic events

For example, automated responses may rely on event data and the resulting geographic boundaries to publish a deployment plan for a set of investigators responsible for formulating actual or potential insurance claim facts. The team may be advised to start from an area within the boundary that reports the most severe home sensor data for a particular disaster event. The team may then be directed to work backwards to the less affected area.

Plans or other responses may also be notified or adjusted by consideration of supplemental data sets, such as reports or data from a weather tracking database, which may be helpful in confirming the occurrence of an event or providing additional support for planning a deployment plan. The schedule may also be informed by the results of previous deployments. For example, a previous severity analysis and response within a geographic boundary may result in a first deployment plan. However, once a deployed team enters its survey results from its survey, the severity analysis may take these results into account in order to develop a better configured deployment plan for future events.

In another example, the automated response may include generating a list of people living within a geographic boundary and associated contact information, an insurance claim for damage within the geographic boundary, or suggesting people to contact for further remote investigation.

In embodiments where home sensor data is used to identify air or water pollution of one or more homes, the sensor data indicative of pollution may be indicative of the extent of an event, such as the extent of a chemical or oil spill. For example, trains carrying chemicals or oil may derail and leak the chemicals or oil into a water source, such as a river or creek. Sensors installed in the home may eventually detect the infiltration or leakage of chemicals or oil into the water supply. Unknown long-term events or pollution and its geographical extent can also be detected. For example, a chemical leak or a smoke/air emission of a plant may contaminate air or water in or near a particular area. Home sensor data, which indicates air or water pollution from multiple homes, may be used to determine the extent or extent of a polluted or affected area. Thereafter, a notification may be sent to these homeowners, or emergency response personnel may be sent to the affected area for cleaning.

Exemplary computing device for tracking catastrophic events using remote sensing networks

In another aspect, a network computing device for tracking catastrophic events using a remote sensor network may be provided. The network computing device may include a communication element, a memory element, or a processing element. The communication element may receive data generated by a plurality of sensors located inside and around the premises. The memory element may be electronically coupled to the communication element and may store data and executable instructions. The processing element may be electronically coupled to the communication element and the memory element. The processing element may be configured to determine that an event threshold has been exceeded, the event threshold being configured to be compared to the event data. The processing element may also be configured to determine a data reception pattern based on the event data, initialize the data file to receive additional sensor data from the plurality of sensors based on the data reception pattern, and receive the additional sensor data into the data file. The network computing device may include additional, fewer, or alternative components or functionality, including those discussed elsewhere herein.

The processing element may be further configured to issue operational instructions to at least a portion of the plurality of sensors based on the data reception pattern and through the communication element. The processing element may be further configured to format the operational instructions for transmission to the plurality of sensors over the communication network. The processing element may also or further be configured to format the operating instructions for routing to an operator of the plurality of sensors.

Example of computer-readable media for tracking catastrophic events using a remote sensor network

In another aspect, a computer-readable medium may be provided for tracking a catastrophic event using a remote sensor network. The computer readable medium may include an executable program stored thereon, wherein the program instructs a processing element of a network computing device to: (1) determining that an event threshold has been exceeded, the event threshold configured to be compared to event data; (2) determining a geographic boundary of an area associated with the event data, the boundary comprising a plurality of sensors located in and around a plurality of premises; (3) determining a data reception mode based on the event data; initializing a data file based on a data reception mode, receiving sensor data from a plurality of sensors; or (4) receiving sensor data into a data file. A program stored on a computer-readable medium may instruct a processing element to perform additional, fewer, or alternative operations, including those discussed elsewhere herein.

For example, the program may instruct the processing element to issue operational instructions to at least a portion of the plurality of sensors according to the data reception mode and through the communication element. The program may also instruct the processing element to format the operating instructions for transmission to the plurality of sensors over the communication network. The program may also or additionally instruct the processing element to format operational instructions for an operator routed to the plurality of sensors.

Exemplary functionality

The present embodiments may relate to smart home technology or smart home controllers to collect and analyze data collected from home installations and other sensors. The data may be analyzed locally or remotely (by one or more local or remote processors) as a sample data set to determine or adjust one or more event thresholds or threshold patterns. These event data may also be analyzed, or may be analyzed, to determine whether an event threshold or threshold pattern is met, indicating the occurrence or likely occurrence of a catastrophic event.

The intelligent home controller may transmit the collected data to an insurance provider remote server for analysis on a periodic basis or on demand. For example, the smart home controller may wirelessly communicate sensors or other data collected every twelve (12) to twenty-four (24) hours.

One embodiment may use data from home security systems, smart homes, and other connected devices. Such information may be collected from window or wall mounted sensors and systems (e.g., glass break sensors) to detect when glass is broken, thermostats to detect and set room temperature, anemometers to detect wind speed, water alarms to detect the presence or level of water, current sensors or the like to detect electricity available to house electrical circuits, infrared or other motion sensors, sensors to detect the presence of vehicles, air or water contaminant detectors, or other like sensors to detect structure, weather, electrical or traffic related information. Through continued collection and analysis, a model can be created to guide the tracking and response to disaster events. This can be done using supervised or unsupervised machine learning.

The solution may include: (1) setting an event threshold for the first event type and configured to compare with event data; (2) analyzing the event data to determine that the event data has exceeded an event threshold and that a first event type has occurred; (3) identifying a geographic boundary of an area associated with the event data, the boundary comprising a plurality of sensors positioned within and about a plurality of premises; or (4) automatically generate a response based on the first event type and the geographic boundary. The solution may also include comparing a set of insurance claims to a list of people living within the geographic boundary. The solution may also include confirming the occurrence of the first event type by comparing the event data or event threshold to a supplemental data set, the supplemental data set including weather-related data received from an external database configured for weather tracking.

In another aspect, a non-transitory computer-readable medium having an executable program stored thereon can be provided for detecting and generating an automated response to a disaster event. The program may instruct a processing element of the computing device to: (1) setting an event threshold for the first event type, the threshold configured to be compared to event data; (2) analyzing the event data to determine that the event data has exceeded an event threshold and that a first event type has occurred; (3) identifying a geographic boundary of an area associated with the event data, the boundary comprising a plurality of sensors positioned within and about a plurality of premises; or (4) automatically generate a response based on the first event type and the geographic boundary.

In another aspect, a computing device can be provided for detecting and generating an automated response to a catastrophic event. The computing device may include a communication element configured to receive event data generated by a plurality of sensors located inside and around a premises. The computing device may also include a memory element electronically coupled to the communication element, a memory element configured to store data, and executable instructions. The computing device may also include a processing element electronically coupled to the communication element and the memory element. The processing element may be configured to: (1) setting an event threshold for the first event type and configured to compare with the event data; (2) analyzing the event data to determine that the event data has exceeded an event threshold and that a first event type has occurred; (3) identifying a geographic boundary for an area associated with event data, the boundary comprising a plurality of sensors; (4) a response is automatically generated based on the first event type and the geographic boundary. The computing device may include additional, fewer, or alternative functionality, including the functionality discussed elsewhere herein.

For example, the response may include the computing device (i) determining the customer's GPS location from the vehicle or mobile device GPS location; (ii) determining that the customer's GPS location is within a geographic boundary of an event-related area; (iii) if so, a backup route is generated for the customer's vehicle to take and transmit the backup route to their vehicle to mitigate the impact of the event on the customer or their vehicle. Additionally or alternatively, the response may include the external computing device or associated transceiver: (i) determining that the customer vehicle is analyzing movement through sensor data received over the wireless communication over the radio link; (ii) the GPS location of the customer is determined. E.g., based on customer vehicle or mobile device GPS location); (iii) determining that the GPS location of the customer vehicle is within a geographic boundary of an area associated with the event; (iv) if so, generating a backup route for the customer vehicle to minimize the impact of the event on the customer or the customer vehicle; (v) the alternate route is sent so that the customer can drive the vehicle according to the alternate route, or the vehicle can automatically turn to the alternate route if permitted by the customer (e.g., an autonomous vehicle or an autonomous vehicle). The computing device may generate other types of responses, including those discussed elsewhere herein.

In another aspect, a computer system for generating automatic responses to catastrophic events may be provided. The computer system may include one or more processors or transceivers configured to: (1) analyzing the generated set of data samples related to the catastrophic event to determine a threshold pattern; (2) receiving home sensor data from the smart home controller via wireless communication or data transmission, the home sensor data including one of: (i) a structural state; (ii) wind speed; (iii) availability of electricity; (i v) the presence of water; (v) (ii) temperature; (vi) pressure; or (vii) the presence of contaminants in the air or water; (3) determining whether the home sensor data matches a threshold pattern based on or by computer analysis of the home sensor data; (4) a response is automatically generated if the home sensor data indicates a match to the threshold pattern.

The one or more processors and transceivers may be further configured to: an operational specification is issued to the smart home controller for reconfiguration to collect additional home sensor data. The one or more processors and transceivers may also or alternatively be configured to confirm the occurrence of the disaster event by analyzing a supplemental data set that includes weather-related data received from an external database configured for weather tracking. The system may include additional, fewer, or alternative functionality, including that discussed elsewhere herein.

Exemplary embodiments

The present embodiments may relate to using real-time regional home sensor data to better identify areas affected by disaster or non-disaster losses. This solution assumes that real-time home sensor data is available. By monitoring the real-time home sensor data (subject to customer approval) or receiving reports from the supplier based on the real-time home sensor data, the insurance supplier can identify the region/applicant where unstable home sensor data is reported and where reporting of data may cease (in this case, it should be confirmed that this is not simply a power outage). Such data can be used to prioritize which applicant(s) are contacted first and where the disaster team is sent and to validate reporting claims against family telematics data or other data (e.g., sensors, images, and audio data).

The present embodiment can (1) collect sensor data from a geographic area (door/window/glass sensors, water sensors, temperature, air or water pollution, etc.); (2) matching (home or vehicle) telematics data to known disasters (hurricanes, wind/hail, earthquakes, and fire) and non-cat losses (theft); (3) identifying a sensor reporting mode based on the loss event type and setting a threshold based on the mode (e.g., sensor data may come from hundreds of households, if all or most of the household sensors report an abnormal or dangerous condition, or if the sensor data peaks for multiple households indicate an abnormal or dangerous condition, it may be assumed that an actual event occurred); (4) an event may be triggered when the real-time sensor reporting pattern matches a predetermined threshold. At this point, cross-checking of weather data may be required. According to this embodiment, (5) the triggering event may entail contacting the applicant for the affected area, providing additional information to the CAT response team, or notifying the applicant of the most recent event that occurred in the area.

After the event passes, sensor data relating to or obtained before, during, and after the event may be collected and analyzed by machine learning or object recognition techniques to determine the extent of damage to the insurance asset, such as a home, car, or personal item. Based on the determined or estimated damage level, a proposed insurance claim can be made and transmitted over one or more radio links to the insured's mobile device for review or approval thereby.

In one aspect, a computer-implemented method may be provided to generate a suggested corrective action for an insurance-related event. The method can comprise the following steps: (1) receiving a first set of data (e.g., weather data or sensor data (e.g., home-mounted, vehicle-mounted, or mobile device-mounted sensor (or image) data or home or vehicle telematics data) over one or more radio links over wireless communication or data transmission at one or more processors or transceivers, (2) entering, at one or more processors, a machine learning or object recognition program (or data pattern recognition technique or program) to determine or identify insurance-related events or a first set of data otherwise determined or recognized, (3) at one or more processors, generating, at one or more processors, a geographic boundary of an area associated with an insurance-related event, or entering, by a computer, a first set of data into a machine learning or object recognition program (or data pattern recognition) A technique or procedure) to determine an actual or predicted range of event geographic boundaries; (4) receiving a second set of data (e.g., customer specific data, including GPS or sensor data) on one or more processors or transceivers (e.g., home-installed, vehicle-mounted or mobile device-mounted sensor (or image) data or home or vehicle telematics data) via wireless communication or data transmission; (5) determining, on the one or more processors, that the customer's GPS location is at or potentially near a geographic boundary or event, the GPS location based on GPS coordinates within the second set of data (e.g., the GPS location of the smart home controller, the smart vehicle, or the mobile device); (6) if so, generating a response or corrective action on the one or more processors; (7) the response to the smart home controller is sent from one or more processors or associated transceivers, and the vehicle controller or the client's mobile device using wireless communication and one or more wireless links, to mitigate the impact of insurance-related events on the insured or insured asset (e.g., vehicle or home).

The method may be implemented by one or more local or remote processors and transceivers or by computer-executable instructions stored on a computer-readable medium or media. The method may include additional, fewer, or alternative actions, including those discussed elsewhere herein.

For example, the response or corrective action may be an electronic message sent to the customer's mobile device alerting them of the upcoming insurance-related path, and estimated strength at the current GPS location. The response or corrective action may be to determine or estimate, on one or more processors, a degree of damage caused to the customer or insurance asset (e.g., personal item, home, or vehicle) by an insurance-related event based on the first or second sets of data, for example, by inputting the received first or second sets of data into a machine learning, object recognition, or pattern recognition program that identifies damage or a degree of damage using historical images. The one or more processors may be further configured to generate a proposed virtual insurance claim for the customer using the estimated damage level of the first or second set of data, or to transmit the proposed virtual insurance claim to the customer's mobile device for review, approval, or modification thereof.

The response or corrective action may generate a request on one or more processors to send emergency or EMS personnel to the customer's GPS location (e.g., the current GPS location of the mobile device, home or vehicle controller contained in the second set of sensor data); or by wireless communication or data transfer, from one or more processors or associated transceivers to a computing device or remote server associated with the police or fire department or hospital over one or more radio links.

The responsive or corrective action may include (i) determining a GPS location of the customer based on the vehicle or mobile device GPS location; (ii) determining that the customer's GPS location is within a geographic boundary of an area associated with the event; (iii) if so, a backup route is generated for the customer's vehicle to take and transmit the backup route to their vehicle to mitigate the impact of the event on the customer or their vehicle. Additionally or alternatively, the responding or corrective action may include, on the external computing device or an associated transceiver: (i) determining that the customer vehicle is moving through sensor data analysis received over a wireless link through wireless communication; (ii) determining a GPS location of the customer for the received sensor data (e.g., based on the customer vehicle or mobile device GPS location); (iii) determining that the GPS location of the customer vehicle is within a geographic boundary of an area associated with the event; (iv) if so, generating a backup route for the customer vehicle to minimize the impact of the event on the customer or the customer vehicle; (v) the alternate route is sent over one or more wireless links so that the customer can drive the vehicle according to the alternate route, or the vehicle can automatically turn to the alternate route (e.g., an autonomous vehicle or an autonomous vehicle) if permitted by the customer.

In another aspect, a computer system may be provided for generating suggested corrective actions for insurance-related events. The computer system may include one or more processors or transceivers configured to: (1) receiving a first set of data (e.g., weather data or sensor data) over one or more radio links (e.g., home-installed, vehicle-mounted or mobile device-installed sensor (or image) data or home or vehicle telematics data) via wireless communication or data transmission; (2) inputting the first set of data into a machine learning or object recognition program (or data pattern recognition technique or program) to determine or recognize, or otherwise determine or recognize, insurance-related events on one or more processors, the insurance-related events being analyzed by a computer to obtain a first set of data; (3) generating a geographic boundary of an area associated with an insurance-related event, or analyzing, by a computer, or inputting a first set of data into a machine learning or object recognition program (or data pattern recognition technique or program) to determine an actual or predicted range of the geographic boundary of the event; (4) receiving a second set of data (e.g., customer specific data, including GPS or sensor data (e.g., home-installed, vehicle-mounted, or mobile device-installed sensor (or image) data) over one or more wireless links via wireless communication or data transfer; or home or vehicle telematics data; (5) determining that the customer's GPS location is or may be near a geographic boundary or event, the GPS location being determined by GPS coordinates within the second set of data (e.g., the GPS location of the smart home controller, smart vehicle, or mobile device); (6) if so, generating a response or corrective action; (7) a smart home controller, vehicle controller or mobile device that sends a response to the customer via wireless communication and one or more wireless links, to mitigate the effects of insurance-related events on an insured person or insured asset (e.g., vehicle or home).

The computer system may include additional, fewer, or alternative functionality. For example, the response or corrective action may be an electronic message sent to the customer's mobile device alerting them of the upcoming insurance-related path, and estimated strength at the current GPS location. The response or corrective action may be to determine or estimate, on one or more processors, a degree of damage caused to the customer or insurance asset (e.g., personal item, home, or vehicle) by an insurance-related event based on the first or second sets of data, for example, by inputting the received first or second sets of data into a machine learning, object recognition, or pattern recognition program that identifies damage or a degree of damage using historical images. The one or more processors may be further configured to generate a proposed virtual insurance claim for the customer using the estimated damage level of the first or second set of data, or to transmit the proposed virtual insurance claim to the customer's mobile device for review, approval, or modification thereof.

The response or corrective action may include generating a request on one or more processors to send emergency or EMS personnel to the customer's GPS location (e.g., the current GPS location of the mobile device, home or vehicle controller contained in the second set of sensor data); or by wireless communication or data transfer, from one or more processors or associated transceivers to a computing device or remote server associated with the police or fire department or hospital over one or more radio links.

The responsive or corrective action may include one or more processors configured to (i) determine a GPS location of the customer based on the vehicle or mobile device GPS location; (ii) determining that the customer's GPS location is within a geographic boundary of an event-related area; (iii) if so, an alternate route is generated for the automated vehicle or customer to take and transmit the alternate route to its automated or other vehicle to mitigate the impact of the event on the customer or its automated or other vehicle. Additionally or alternatively, the responding or corrective action may include, on the external computing device or an associated transceiver: (i) determining that the customer vehicle is moving through sensor data analysis received over a wireless link through wireless communication; (ii) determining a GPS location of the customer for the received sensor data (e.g., based on the customer vehicle or mobile device GPS location); (iii) determining that the GPS location of the customer vehicle is within a geographic boundary of an area associated with the event; (iv) if so, generating a backup route for the customer vehicle to minimize the impact of the event on the customer or the customer vehicle; (v) the alternate route is sent over one or more wireless links so that the customer can drive the vehicle according to the alternate route, or the vehicle can automatically turn to the alternate route (e.g., an autonomous vehicle or an autonomous vehicle) if permitted by the customer.

Other considerations

The insured customer may select a reward, insurance discount or other type of program according to the above provisions. After the insurance client provides positive consent, the insurance provider telecommunication application or remote server may collect smart home, mobile, vehicle, telecommunication or other data. (including image or audio data) are associated with the insurance asset, including before, during, or after the insurance-related event. In return, risk-evading homes or owners may obtain discounts or insurance cost savings from insurance providers related to automobiles, homes, lives, rentals, pets, and other types of insurance.

In one aspect, the sensor data may be collected or received by the insured's smart home, mobile device or smart vehicle or remote server of the insurance provider, for example, by direct or indirect wireless communication or data transmission of an application running on the insured's smart home controller, mobile device or vehicle after the insured or client has specifically agreed to or otherwise selected an insurance discount, reward or other program. The insurance provider may then analyze the data received under the customer's license to provide benefits to the customer. Thus, a risk-averted client may receive an insurance discount or other insurance cost savings according to the functions or techniques discussed herein, which may mitigate or prevent (i) the risk of an insurance asset, such as a vehicle or family, or (ii) insured and family members caused by insurance-related events.

In this specification, a reference to "one embodiment," "an embodiment," or "an embodiment" means that the feature or features referred to is included in at least one embodiment of the technology. Separate references to "one embodiment," "an embodiment," or "embodiments" in this specification do not necessarily refer to the same embodiment, nor are they mutually exclusive, unless so stated or unless otherwise apparent to those of skill in the art from the specification. For example, features, structures, acts, etc. described in one embodiment may be included in other embodiments, but are not necessarily included. Accordingly, the present technology may include various combinations or integrations of the embodiments described herein.

Although this application describes in detail a number of different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims set forth at the end of this patent and their equivalents. The detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.

In this specification, multiple instances may implement a component, an operation, or a structure described as a single instance. Although individual operations of one or more methods are described as separate operations, one or more of the individual operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Also, structures and functionality presented as a single component may be implemented as separate components. Such alterations, modifications, additions, and improvements are intended to be within the scope of the subject matter herein.

Certain embodiments are described herein as comprising logic or a plurality of routines, subroutines, applications, or instructions. These may constitute software (e.g., code embodied in a machine-readable medium or transmission signal) or hardware. In hardware, a routine or the like is a tangible unit capable of performing certain operations, and may be configured or arranged in a certain manner. In an embodiment, one or more computer systems (e.g., a stand-alone, client, or server computer system) or one or more hardware modules (e.g., a processor or a set of processors) (e.g., an application or application portion) of a computer system may be configured by software as computer hardware for performing certain operations described herein.

In various embodiments, computer hardware, such as processing elements, may be implemented as a special purpose or general purpose. For example, a processing element may comprise permanently configured application specific circuitry or logic, such as an Application Specific Integrated Circuit (ASIC), or indefinitely configured (e.g., FPGA) to perform certain operations. A processing element may also comprise programmable logic or circuitry (e.g., embodied within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a processing element as a special purpose, in dedicated and permanently configured circuitry, or as a general purpose (e.g., configured by software) may be driven by cost and time factors.

Thus, the term "processing element" or equivalent shall be understood to encompass a tangible entity, i.e., an entity of physical construction, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner or to perform a certain operation described herein. In view of the embodiments (e.g., programming) in which processing elements are temporarily configured, each processing element need not be configured or instantiated in time at any one instance. For example, when the processing elements include a general-purpose processor configured using software, the general-purpose processor may be configured as respective different processing elements at different times. Software may configure the processing elements accordingly to form a particular hardware configuration on one instance and a different hardware configuration on a different instance.

Computer hardware components, such as communication elements, memory elements, processing elements, and the like, may provide information to and receive information from other computer hardware components. Thus, the computer hardware components may be considered to be communicatively coupled. If there are a plurality of such computer hardware components at the same time, communication may be achieved by signal transmission (e.g., through appropriate circuits and buses) connecting the computer hardware components. In embodiments where multiple computer hardware components are configured or instantiated at different times, communication between the computer hardware components may be achieved, for example, by storing and retrieving information in memory structures accessible to the multiple computer hardware components. For example, a computer hardware component may perform an operation and store the output of the operation in a memory device communicatively coupled thereto. Another computer hardware component may then later access the storage device to retrieve and process the stored output. The computer hardware components may also initiate communication with input or output devices and may operate on resources (e.g., sets of information).

Claims

1. A computer-implemented method of generating an automatic response to a catastrophic event, the method comprising: analyzing, by one or more processors, a set of data samples generated in association with instances of a catastrophic event type to determine a threshold pattern, the set of data samples generated by a plurality of sensors installed on a plurality of geographically distributed structures and respectively affected by the instances of the catastrophic event type; receiving, by one or more processors, home sensor data from a smart home controller via wireless communication or data transmission, the home sensor data including (i) a structural state; (ii) wind speed; (iii) availability of electricity; (iv) the presence of water; (v) (ii) temperature; (vi) pressure; or (vii) the presence of contaminants in the air or water; determining, by the one or more processors, based on or through computer analysis of the home sensor data, whether the home sensor data exhibits a threshold pattern match associated with a type of disaster event; automatically generating, by the one or more processors, a response that includes a list of people that are or may be affected by the disaster event type if the home sensor data indicates a threshold pattern match associated with the disaster event type; and comparing a set of insurance claims to the list of people.

2. The computer-implemented method of claim 1, further comprising issuing, by the one or more processors, operational instructions to the smart home controller to reconfigure to collect additional home sensor data.

3. The computer-implemented method of claim 1, wherein the generating of the response is further dependent on analyzing, by the one or more processors, a supplemental dataset to confirm the match to the threshold pattern, the supplemental dataset comprising weather-related data received from an external database configured for weather tracking.

4. The computer-implemented method of claim 1, wherein the response includes an indication that personnel should be deployed to an area near home.

5. A computer system for generating an automated response to a catastrophic event, the computer system comprising one or more processors and a transceiver configured to: analyzing a set of data samples generated in association with instances of a catastrophic event type to determine a threshold pattern, the set of data samples generated by a plurality of sensors installed on a plurality of geographically distributed structures and respectively affected by instances of the catastrophic event type; home sensor data is received from the smart home controller via wireless communication or data.

6. Transmitting, home sensor data, including (i) structural status; (ii) wind speed; (iii) availability of electricity; (i v) having water; (v) (ii) temperature; (vi) pressure; or (vii) data on contaminants in the air or water; determining, from or by computer analysis of the home sensor data, whether the home sensor data matches a threshold pattern associated with a type of catastrophic event; automatically generating a response if the home sensor data indicates a threshold pattern match associated with the disaster event type, the response including a list of people affected or likely to be affected by the disaster event type; and comparing a set of insurance claims to the list of people.

7. The computer system of claim 5, wherein the one or more processors and transceiver are further configured to issue operational instructions to the smart home controller to reconfigure to collect additional home sensor data.

8. The computer system of claim 5, wherein the one or more processors and transceivers are further configured to confirm the match to the threshold pattern by analyzing a supplemental data set comprising weather-related data received from an external database configured for weather tracking.

9. The computer system of claim 5, wherein the one or more processors and transceiver are further configured to issue a response to include an indication that personnel should be deployed to an area near home.