Security incident handling

Abstract

According to one disclosed method, a computing system may cause a first computing device to display a first notification of a first event detected at a monitoring location, and may cause a second computing device to display a second notification of a second event detected at the monitoring location. The computing system may further cause the second computing device to cease displaying the second notification in response to a change in the state of the first event.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application No. 63 / 441,960, filed on January 30, 2023, entitled “SECURITY EVENT PROCESSING,” the entire contents of which are incorporated herein by reference. Background Art

[0003] Some security systems enable the use of cameras and other equipment to remotely monitor a location. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Further examples of the present disclosure and features and advantages thereof will become more apparent by reference to the description taken herein in conjunction with the accompanying drawings, which are incorporated in and constitute a part of this disclosure. The accompanying drawings are not necessarily drawn to scale.

[0005] Figure 1 A first example screen is shown that may be displayed by a monitoring device to indicate certain events detected by a security system, according to some embodiments of the present disclosure.

[0006] Figure 2 A second example screen is shown that may be displayed by a monitoring device to present a live video feed from a location monitored by a security system, in accordance with some embodiments of the present disclosure.

[0007] Figure 3 An example system configured to streamline the dispatch of notifications of events to monitoring applications for review by monitoring agents is shown, in accordance with some implementations of the present disclosure.

[0008] Figure 4A shows how a monitoring agent can modify the event when actively reviewing it according to some embodiments of the present disclosure. Figure 3 The information in the table shown is an example of streamlining the dispatch of notifications of events to other monitoring applications for review by other monitoring agents.

[0009] Figure 4B shows how the monitoring agent can change when it determines that an event does or does not present a security issue according to some embodiments of the present disclosure. Figure 4A An example of the information in the table is shown.

[0010] Figure 5 Shown are example screens that may be presented by a monitoring device operated by a monitoring agent when the monitoring agent is actively reviewing events according to some embodiments of the present disclosure.

[0011] Figure 6An example implementation of a security system according to some implementations of the present disclosure is shown.

[0012] Figure 7 Some embodiments of the present disclosure are shown Figure 6 An example implementation of a base station for a security system is shown.

[0013] Figure 8 Some embodiments of the present disclosure are shown Figure 6 An example implementation of a keypad for a security system is shown.

[0014] Figure 9 Some embodiments of the present disclosure are shown Figure 6 An example implementation of a security sensor for a security system is shown.

[0015] Figure 10 Some embodiments of the present disclosure are shown Figure 6 Example implementations of a surveillance center environment and a monitoring center environment for a security system are shown.

[0016] Figure 11 According to some embodiments of the present disclosure, Figure 6 A sequence diagram of the monitoring processes performed by the components of the safety system is shown.

[0017] Figure 12 Some embodiments of the present disclosure are shown. Figure 6 An example process for establishing a peer-to-peer connection between components of a security system to enable streaming of video and / or audio data is shown.

[0018] Figure 13 is a sequence diagram illustrating an example signaling process according to some embodiments of the present disclosure, which may be used to Figure 6 Peer-to-peer connections are established between components of the illustrated security system to enable streaming of video and / or audio data.

[0019] Figure 14A is an illustration of the actions that may be performed by one or more components of the monitoring service described herein based on Figure 3 A flow diagram of an example routine for causing an event to be added to a lookup queue of an available monitoring agent based on the current contents of a state table is shown.

[0020] Figure 14B is an illustration of the actions that may be performed by one or more components of the monitoring service described herein based on Figure 3 A flow chart of an example routine for causing an event to be removed from a monitoring agent's watch queue based on the current contents of a state table is shown.

[0021] Figure 14Cis a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service described herein when a monitoring agent begins actively reviewing an event to identify other events that may be related to the reviewed event and change the status indicators of these potentially related events to "hold."

[0022] Figure 14D is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service described herein to determine which Figure 3 The status indicator of a new event of the status table shown is marked as either "new," thereby allowing it to be assigned to an available monitoring agent, or "held," thereby preventing it from being assigned to a monitoring agent.

[0023] Figure 14E is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service described herein to update an event in response to a change in the status indicator for an actively watched event from "watched" to "new." Figure 3 The status indicators in the status table shown are associated with events that have been actively consulted by the monitoring agent.

[0024] Figure 14F is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service described herein to update an event in response to a change in the status indicator for an actively watched event from "watched" to "cleared." Figure 3 The status indicators in the status table shown are associated with events that have been actively consulted by the monitoring agent.

[0025] Figure 14G is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service described herein to update an event in response to a change in the status indicator for an actively watched event from "watch" to "threat." Figure 3 The status indicators in the status table shown are associated with events that have been actively consulted by the monitoring agent.

[0026] Figure 15 is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service disclosed herein to process commands received from a monitoring application operated by a monitoring agent, according to some embodiments of the present disclosure.

[0027] Figure 16 is a flow chart illustrating an example routine that may be performed by one or more components of the monitoring service disclosed herein to cause devices operated by customers to present information about events detected at monitored locations in a grouped manner.

[0028] Figure 17According to some embodiments of the present disclosure, Figure 6 A schematic diagram of a client device, a monitoring device, and / or one or more service computing devices of a security system is shown.

[0029] Figure 18 Example tokens that may be employed by various components of the system disclosed herein are shown, according to some embodiments of the present disclosure. Summary of the Invention

[0030] In some disclosed embodiments, a method includes causing a first computing device, by a computing system, to display a first notification of a first event detected at a monitoring location; causing a second computing device, by the computing system, to display a second notification of a second event detected at the monitoring location; and causing the second computing device, by the computing system, to cease displaying the second notification in response to a change in a state of the first event.

[0031] In some disclosed embodiments, a system includes at least one processor and at least one computer-readable medium encoded with instructions that, when executed by the at least one processor, cause the system to: cause a first computing device to display a first notification of a first event detected at a monitoring location, cause a second computing device to display a second notification of a second event detected at the monitoring location, and cause the second computing device to cease display of the second notification in response to a change in a state of the first event.

[0032] In some disclosed embodiments, a method includes determining, by a computing system, that a first computing device receives input associated with a first notification indicating a first event detected at a location; and causing, by the computing system, a second computing device to cease displaying a second notification based at least in part on receiving the input, the second notification indicating a second event at the location that is different from the first event. DETAILED DESCRIPTION

[0033] Existing security systems use cameras and other sensors to monitor locations for a variety of reasons. Some such systems are configured to detect the occurrence of certain phenomena (e.g., motion and / or sound) within or around the monitored location, and are also configured to send event notifications and possibly associated image data to a remote location for processing and / or review by a human monitoring agent. The monitoring agent can review the event notifications and their associated images (e.g., still images and / or recorded video clips) and / or recorded audio to determine whether the respective event notifications cause an actual safety concern or are instead generated for harmless reasons (e.g., pets or other animals, visiting neighbors, trees moving in strong winds, delivery personnel, door-to-door salespeople, etc.). As used herein, a "safety concern" may refer to any situation that a customer may consider unacceptable from a safety, security, or well-being perspective, such as a burglary attempt, a package theft attempt, a vandalism attempt, a neighbor's pet defecating on the lawn, a stranger peering through a window, etc.

[0034] A system is provided in which a monitoring agent, upon determining that a notification (e.g., an event notification) raises a potential safety issue, can additionally review live video and / or audio from a location to assess whether the detected event raises a safety issue. For example, in some embodiments, the system can allow a computing device operated by the monitoring agent to establish a peer-to-peer connection with one or more cameras at the location, e.g., to enable streaming of video data and / or audio data between the computing device of the monitoring agent and the camera(s).

[0035] Further, in some embodiments, the system disclosed herein can control the distribution of event notifications to monitoring agents so as to minimize the number of human agents required to properly review the event notifications (and any associated images and / or audio) to determine whether each event notification raises an actual safety concern or is otherwise generated for an innocuous reason.

[0036] For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the examples illustrated in the drawings, and specific language will be used to describe these examples. It will be understood, however, that no limitation of the scope of the examples described herein is intended thereby.

[0037] Figure 1 FIG. 6 illustrates a security system 600 ( FIG. 7 ) that may be configured in accordance with certain aspects of the present disclosure. Figure 6 ) in a computer or other monitoring device 1016 (combined with Figure 1010). As shown, monitoring device 1016 can be operated by monitoring agent 104, and screen 102 can include a set of event windows 106 corresponding to various events currently in the agent's queue for review. In some embodiments, for example, each event window 106 can be configured to play back a recorded video clip corresponding to a corresponding event detected at a respective monitoring location. As used herein, a "monitoring location" can correspond to a specific location that is monitored for security purposes (e.g., a house and associated land parcel, office space, etc.). A given monitoring location can be associated with a specific customer identifier, for example.

[0038] like Figure 1 As shown, in some configurations, the screen 102 can include a queue control interface 108 that includes one or more user interface (UI) elements to allow a monitoring agent 104 to control various aspects of the agent's queue, such as the maximum number of notifications that can be added to the agent's queue for presentation in the corresponding event window 106. In some implementations, event notifications can be distributed to the various monitoring agents 104 included in the pool of available monitoring agents 104 such that all available monitoring agents 104 have approximately the same number of events in their review queues at a given time.

[0039] The camera 604 of the security system 600 (see Figure 6 ) can be triggered by a person entering the field of view (FOV) of camera 604, and a video signal can be recorded for a period of time, such as until the person leaves the camera's FOV. A video clip of such an event can be stored (e.g., in Figure 10 4) and associate it with an event or tag it to an event. Notification of the event can then be added to the monitoring agent 104's review queue, e.g., by Figure 1 A recorded video clip of the detected event is shown presented within one of the event windows 106. In some embodiments, such a recorded video clip can be configured and / or played back at least initially at an increased rate (e.g., twice the standard speed) to increase the rate at which the monitoring agent 104 can review the video clip for potential threats.

[0040] While reviewing one event window 106, for example, by viewing a recorded video clip corresponding to the detected motion, the monitoring agent 104 may determine that there is no potential security threat and provide an input instructing the monitoring device 1016 to remove the event notification from the agent's review queue, thereby freeing the corresponding event window 106 to display another event notification. In some embodiments, the monitoring agent 104 may identify the reason why each notification was removed from the agent's queue, for example, by selecting an option from a drop-down menu presented when providing the input to close the notification. Examples of such reasons include "delivery person," "leaving / arriving home," "no one," "passerby," etc.

[0041] Alternatively, while reviewing an event window 106, for example, by viewing a recorded video clip corresponding to detected motion, the monitoring agent 104 may determine that a potential threat or other safety issue (referred to herein as an "incident") exists and decide to review the incident (to the exclusion of other monitoring agents 104), such as by reviewing live video and / or audio from the monitoring location 602 that recorded the video clip. The monitoring agent 104 may acquire exclusive oversight of the incident, for example, by selecting to play or otherwise display the event window 106 in question with the recorded video. In response to such a selection, the monitoring device 1016 may begin receiving live video and / or audio streamed from one or more cameras at the monitoring location 602, and / or the monitoring agent 104 may be otherwise provided with additional data (e.g., other recorded video and / or audio clips, still images, sensor data, artificial intelligence (AI) assessment results, etc.), thereby enabling the monitoring agent 104 to assess whether the incident presents an actual safety risk. In some embodiments, for example, one or more cameras 604 ( Figure 6 One or more peer connections are established between the camera (shown in FIG) and the monitoring device 1016 to enable streaming of video data and / or audio data between the camera (s) and the monitoring device 1016. Figure 12 and Figure 13 An example process is described for securely establishing a peer-to-peer connection between the monitoring device 1016 and the camera 604 to enable such live streaming.

[0042] Figure 2 The monitoring device 1016 can respond to the Figure 11. The example screen 110 is presented with the selection of one of the event windows 106 shown. In the illustrated example, the screen 110 includes three video feed windows 112 configured to display streaming video from three different cameras 604 at the monitoring location 602 corresponding to the selected event window 106. Figure 2 604 and speak into a microphone so as to cause one or more speakers of such camera(s) 604 to output audio representing the voice of the monitoring agent. In the illustrated example, the screen 110 also includes a larger, main viewer window 114 in which the streaming video of one video feed window 112 can be optionally played, thereby making it easier for the monitoring agent 104 to see the content of the video. In some embodiments, the monitoring agent 104 can cause the streaming video from a particular camera 604 to play in the main viewer window 114 by selecting the video feed window 112 of that camera (e.g., by clicking on it).

[0043] The monitoring agent 104 can take appropriate action based on reviewing the live video and / or audio from the camera(s) 604. If the monitoring agent 104 determines that a threat or other safety issue may exist, the monitoring agent 104 can trigger an alarm, notify the police, verbally communicate with one or more individuals at the monitored location 602, for example, via a speaker on the camera 604, and / or take any of a number of other possible remedial actions. If the monitoring agent 104 determines that a safety issue does not exist, the monitoring agent 104 can instead mark the event notification as cleared, thereby removing it from the agent's queue.

[0044] Reference again Figure 1 The inventors have recognized and appreciated that distributing event notifications to the review queues of monitoring agents 104 in the manner described above may, if not properly controlled, require an excessively large number of monitoring agents 104 to review such event notifications in a timely manner. As described above, the cameras 604 of the security system 600 (see Figure 6 ) can be triggered by a person (e.g., a delivery person, lawn service person, homeowner, burglar, etc.) entering the field of view (FOV) of camera 604, and a video clip from camera 604 can be associated with the event and added to the monitoring agent 104's review queue, e.g., by Figure 1The video clip is presented within one of the event windows 106 shown. If the same person leaves and then re-enters the FOV of the camera 604, the system can record another video clip, associate the video clip with another event, and distribute notification of the additional event to the review queue of the monitoring agent 104. Further, if the monitoring location 602 (see Figure 6 ) has more than one camera 604, different cameras 604 can be triggered by a single person moving around the monitoring location 602, thereby causing even additional events to be detected, and notifications of these additional events also distributed to the review queue of the monitoring agent 104.

[0045] The inventors further recognize and appreciate that when multiple monitoring agents 104 attempt to establish a live video feed simultaneously with the same camera 604, hardware-related issues may arise, such as the camera 604 slowing down or even crashing when attempting or establishing such a simultaneous live video feed.

[0046] Some existing camera solutions use various techniques to reduce the number of event notifications generated for the same incident (e.g., a person moving around the monitored location 602). For example, some systems employ cameras that enter a "cooling-off" period after being triggered, so that even if a person is subsequently detected, the camera will not be triggered again for a short period of time. However, systems employing such techniques still tend to generate a large number of event notifications for the same incident.

[0047] To address the above issues, in some embodiments, the system disclosed herein can control the distribution of event notifications to monitoring agents regardless of the number of event notifications generated (based on triggered cameras or otherwise) so as to minimize the number of human agents required to appropriately review the event notifications (and any associated images and / or audio) to determine whether each event notification raises an actual safety concern or is otherwise generated for an innocuous reason, as well as to minimize the number of simultaneous peer connections established with each camera 604.

[0048] Figure 3 An example system 100 is shown according to some embodiments of the present disclosure, wherein a monitoring service 630 (hereinafter in conjunction with Figure 6 and Figure 10 Description) can use the state table 302 or other data structure to enable notification of events to the monitoring applications 632A to 632M (also described below in conjunction with Figure 6 and Figure 10 Description) is streamlined for review by the monitoring agent 104. Figure 10As explained in further detail, in some embodiments, the monitoring service 630 may include, among other things, the event listening service 1010 and the monitoring service 1040, wherein the monitoring service 1040 maintains a record of events identified by the event listening service 1010. In such embodiments, the state table 302 may be maintained, for example, by the monitoring service 1040. In some embodiments, one or more components of the monitoring service 630 (e.g., the monitoring service 1040) may use the contents of the state table 302 to assign various events to various monitoring agents 104 that are currently online with the monitoring application 632. The monitoring application 632 operated by a given monitoring agent 104 may then add the events assigned to that monitoring agent 104 to, for example, the state table 302. Figure 1 The event queue within the event window 106 is shown for review by the monitoring agent 104.

[0049] like Figure 3 As shown, in some embodiments, the state table 302 can be populated with data representing an event identifier (ID) 304, a timestamp 306, a location ID 308, a camera ID 310, image data 312, other data 314, a state indicator 316, (one or more) associated events 318, and an agent ID 320.

[0050] Event ID 304 may represent different events that monitoring service 630 has detected, and data in the same row as a given event ID 304 may correspond to that same event.

[0051] The timestamp 306 may indicate the date and time when the corresponding event was detected.

[0052] The location ID 308 may identify the monitoring location 602 where the event was detected (see Figure 6 ).

[0053] The camera ID 310 may identify the camera 604 associated with the corresponding detected event.

[0054] Image data 312 may represent one or more images (eg, snapshots or video clips) acquired by camera 604 identified by corresponding camera ID 310 when an event is detected.

[0055] Other data 314 may represent any of a number of other types of potentially useful information associated with the event, such as a description of the event (e.g., "motion detected by backyard camera"), the alarm status of monitoring location 602, one or more recorded audio tracks associated with the event, an indicator of motion detected during the event, an indicator of a detected face corresponding to the event, a threat level assigned to the event (e.g., as determined by the following in conjunction with the preceding text), and a description of the event. Figure 10The AI service 1008 described herein determines), monitors the state change of one or more sensors (e.g., door lock sensor) at the location 602, etc. Figure 5 As described in more detail, in some embodiments, the other data 314 in the status table 302 can be used to populate one or more event data windows 502 that can be displayed by the monitoring device 1016, along with one or more live video feeds within the video feed window(s) 112 and / or the main viewer window 114.

[0056] Status indicator 316 may reflect the current status of the event. Figure 3 As shown, when the data of an event is initially written to the state table 302, the state indicator 316 of the event can be configured to indicate that the event has not yet been classified by the monitoring agent 104 as causing a security issue or does not cause such an issue. In the illustrated example, the "new" state indicator 316 identifies such an unclassified event. Figure 4A and Figure 4B As shown, in some embodiments, one or more status indicators 316 can be changed during operation of the system 100 to indicate (A) that the monitoring agent 104 is actively reviewing the event (e.g., via a "reviewing" status indicator 316), (B) that the event is not included in any monitoring agent's review queue (e.g., via a "holding" status indicator), (C) that the monitoring agent 104 has determined that the event does not raise a security issue (e.g., via a "cleared" status indicator 316), or (D) that the monitoring agent 104 has determined that the event raises a security issue (e.g., via a "threat" status indicator 316). As described in more detail below, such status indicators 316 can be used to enable notification of events to monitoring applications 632A through 632M (also described below in conjunction with Figure 6 and Figure 10 Description) is streamlined so that it can be viewed by the monitoring agent 104.

[0057] The correlated event indicator(s) 318 may identify events that have been determined to be potentially related to the same incident as an event that is being or was previously actively reviewed (e.g., by viewing a live video feed of the event) by the monitoring agent 104. Example techniques that may be used to identify such potentially related events and to streamline the distribution of event notifications to the monitoring agents 104 using the correlated event indicator(s) 318 are described in detail below.

[0058] The agent ID 320 may identify the monitoring agent 104 (if any) to which the event has been assigned for review. Figure 3 、 Figure 4A and Figure 4BAs shown, in some embodiments, the agent ID 320 can indicate that the corresponding event has been assigned to one or more monitoring agents 104 for review (e.g., by including an identifier of a particular monitoring agent 104), or that the event is not currently assigned to any monitoring agent 104 for review (e.g., by including a designation of "unassigned").

[0059] As previously mentioned, in some embodiments, when data for an event is initially written to the state table 302, the state indicator 316 for the event may be set to indicate that the event has not yet been classified by the monitoring agent 104 (e.g., via a "new" state indicator 316). In such embodiments, one or more components of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 (shown) can monitor the state table 302 to identify events with a "new" status and assign such events to available monitoring agents 104. For example, such assignment can be made by adding the agent ID 320 of the agent to which the event is assigned to the state table 302. Events with a "new" status indicator 316 and having the agent ID 320 in the state table 302 can be considered to be in the review queue of the identified monitoring agent 104. As explained in more detail below, in some embodiments, only events that occurred less than a threshold amount of time in the past (e.g., within the last thirty minutes) can be added to the monitoring agent's queue, thereby preventing the monitoring agent 104 from receiving notifications about events that have become stale (e.g., because any incident that occurred may no longer occur) and about which the monitoring agent 104 may not be able to intervene in a meaningful way.

[0060] Figure 3 One or more components of the monitoring service 630 shown (e.g., in conjunction with Figure 10 The monitoring service 1040 described herein may monitor the status indicators 316 and agent IDs 320 in the table to determine the events currently in the lookup queue of each monitoring agent and, as appropriate, Figure 3 As indicated by arrows 322a, 322b in FIG. 1 , “event data” (e.g., image data 312 and / or other data 314) regarding these events may be sent to a monitoring application 632 operated by the indicated monitoring agent 104. Thus, the monitoring devices 1016 of the respective monitoring agents 104 may present information (e.g., video clips) regarding the events assigned to these monitoring agents 104 within the respective event windows 106, such as Figure 1 Example.

[0061] As an example, when Figure 3When the state table 302 is populated as shown, the monitoring service 630 can determine that: (1) event "E1" is currently in the lookup queue of agent "A1", (2) event "E2" is currently in the lookup queue of agent "A2", (3) event "E3" is currently in the lookup queue of agent "A3", and (4) event "E4" is currently in the lookup queue of agent "A4". Figure 3 The version of the state table 302 shown also indicates that events "E1," "E2," and "E4" all occurred at one monitoring location 602, location "L1," while event "E3" occurred at a different monitoring location 602, location "L2." Further, with respect to events at monitoring location "L1," Figure 3 The version of table 302 shown in additionally indicates that two of the events (i.e., events “E1” and “E4”) were detected by one camera (i.e., camera “C1”), while the other event (i.e., event “E2”) was detected by another camera (i.e., camera “C2”).

[0062] Continuing with the previous example, if monitoring agent "A1" is, for example, viewing the events in one or more event windows 106 (see Figure 1 ) to review the events in the monitoring agent's review queue, and determines that event "E1" raises a potential safety issue, monitoring agent "A1" may provide input that is exclusively responsible for evaluating the incident involving event "E1" (such as by reviewing one or more live video feeds from monitoring location "L1"). In some embodiments, for example, monitoring agent "A1" may obtain exclusive supervision of the incident by clicking or otherwise selecting the event window 106 playing the video clip corresponding to event "E1".

[0063] As mentioned above, and as Figure 3 As indicated by arrow 324 in FIG, providing such input may cause the monitoring application 632 of the monitoring agent “E1” to establish a peer-to-peer connection with one or more cameras 604 (e.g., cameras “C1” and “C2”) at the monitoring location “L1” and present live video feeds from these cameras 604 within one or more video feed windows 112 and / or the main viewer window 114 of the monitoring device 1016 of the monitoring agent. For example, Figure 3 Providing such input may cause the monitoring application 632 to send one or more commands to a component of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 shown in FIG. 1040 is used to establish such a peer-to-peer connection. Figure 12 and Figure 13 Describes an example process for establishing a peer-to-peer connection between the monitoring application 632 and the camera 604, wherein Figure 12Arrow 1202 in the transmission of the camera access request and user token corresponds to the Figure 3 One or more commands indicated by arrow 326 in FIG.

[0064] like Figure 4A As shown in the version of the state table 302 shown, when processing such a request from the monitoring application 632 of monitoring agent "A1" to obtain exclusive supervision of an incident, the monitoring service 630 can make several changes to the state indicator 316 for various events detected at monitoring location "L1" (i.e., the location from which monitoring agent "A1" is now viewing the live video feed). As described below, these changes can be used to group together various events that may be related to the same incident (e.g., a person moving around monitoring location "L1") and allow a single monitoring agent (e.g., monitoring agent "A1") to process all of these potentially related events as a group.

[0065] like Figure 4A, one such change that the monitoring service 630 can make to the state table 302 is to change the state indicator 316 of the event selected by the monitoring agent "A1" (i.e., event "E1") to indicate that the event is currently under active review. In the illustrated example, the monitoring service 630 has set the state indicator 316 of event "E1" to "review" for this purpose. In addition, the monitoring service 630 can identify one or more other events represented in the state table 302 that correspond to the same position as the under-review event "E1", i.e., position "L1", and the monitoring service can change the state indicator 316 of these events to indicate that they are not included in the review queue of any monitoring agent. In the illustrated example, the monitoring service 630 has set the state indicator 316 of events "E2" and "E4" to "hold" for this purpose. In some embodiments, in addition to identifying one or more events corresponding to the same location as the event under review (e.g., location "L1" of event "E1"), the monitoring service 630 may also determine whether such events meet one or more additional criteria related to the event under review, and may change the status indicator 316 to "hold" only for events that meet such criteria. For example, in some embodiments, the monitoring service 630 may mark as "hold" only those events detected at location "L1" that have timestamps within a time window of the control input data having timestamp "T1" of event "E1". Such a time window may, for example, extend from a time five minutes before the time indicated by timestamp "T1" to a time five minutes after the time indicated by timestamp "T1". Further, in some embodiments, whenever the monitoring service 630 adds a newly detected event to the state table 302, the monitoring service 630 may check to see if the new event originates from the same monitoring location 602 as any event currently in active review, e.g., by determining if any event with the same location ID 308 has a state indicator already set to "review," and the monitoring service may also check to see if such a newly added event satisfies one or more of the additional criteria described above, e.g., by determining if the newly added event occurs within a time window controlled by the timestamps of events from the same monitoring location 602 in active review. When the monitoring service 630 determines that the newly added event originates from the same monitoring location 602 as an existing event currently in active review and satisfies one or more of the additional criteria (if applicable), the monitoring service 630 may set the state indicator 316 of the newly added event to "keep."

[0066] Likewise Figure 4AFor example, for events marked as "held", the monitoring service 630 can additionally change the agent ID 320 of these events to indicate that they are not currently assigned to any monitoring agent 104, and / or can refrain from assigning these events to any monitoring agent 104 as long as the status indicator 316 of these events remains in the "held" state. In the illustrated example, the monitoring service 630 has set the agent ID 320 of events "E2" and "E4" to "unassigned" for this purpose.

[0067] Importantly, when the monitoring service 630 makes this change to the agent ID 320, the corresponding events previously included in the review queues of other monitoring agents can be removed from these queues. Thus, these other monitoring agents 104 can be relieved of the responsibility of reviewing these events, and space can be left in the review queues of these monitoring agents 104 to receive events from other monitoring locations 602. Furthermore, as previously described, as long as the status indicator 316 remains set to "hold" for any event, the monitoring service 630 can refrain from assigning that event to any monitoring agent 104, thereby preventing the review queues of individual monitoring agents 104 from becoming clogged with events related to incidents that are being actively reviewed by other monitoring agents 104. Grouping events in this manner can also provide significant benefits from a hardware perspective, at least because it reduces the likelihood that multiple monitoring agents 104 will attempt to establish live feeds with a camera 604 at the same time, thereby eliminating potential problems (e.g., video signal delays, camera crashes, etc.) that can occur when attempting or establishing such simultaneous live camera feeds.

[0068] As previously described, in response to the monitoring agent 104 providing input selecting events to be actively reviewed (e.g., by selecting Figure 1 106), a peer-to-peer connection can be established between the monitoring application 632 of the monitoring agent 104 and one or more cameras 604 at the monitoring location 602 where the selected event occurred, and live video feeds from these cameras 604 can be presented in one or more video feed windows 112 and / or the main viewer window 114 of the monitoring device 1016 of the monitoring agent. Figure 5 By way of example, in some embodiments, the data in the state table 302 may additionally or alternatively be used to present to the monitoring agent 104 other information about events at the monitoring location 602 (e.g., within the event data window 502 or otherwise) that may potentially be used to determine whether a selected event involves an actual security threat or can instead be “cleared.”

[0069] In some embodiments, other data 314 in the same row as the selected event of the above type (eg, event "E1" according to the above example scenario) may be used to populate Figure 5One or more event data windows 502 are shown, or may be used in other ways to present supplemental information on screen 504. Such other data 314 may be sent from monitoring service 630 to monitoring application 632, for example, as a Figure 3 As an example, the other data 314 may represent a description of the event in the active review (e.g., "motion detected by the backyard camera"), the alarm status of the monitoring location 602, and / or the threat level assigned to the event (e.g., as described below in conjunction with Figure 10 The other data 314 may be used by the monitoring application 632 to cause text or other indicators reflecting such information to be prominently presented on the display 504, for example, directly below the video feed window 112. As another example, the other data 314 may represent one or more recorded audio tracks associated with the event in active viewing, an indicator of motion detected during the event in active viewing, and / or an indicator of a detected face corresponding to the event in active viewing. Such information may also be presented within one or more event data windows 502 or elsewhere on the display 504.

[0070] Further, in some embodiments, image data 312 and / or other data 314 in rows other than the row for the selected event (e.g., data for events that have been marked as "keep" in the status table 302 because they are from the same monitoring location 602 as the selected event) can be used to populate Figure 5 One or more event data windows 502 are shown, or may be used in other ways to present supplemental information on screen 504. Such data may also be sent from monitoring service 630 to monitoring application 632, for example, as a Figure 3 322a in the display 504. As an example, the monitoring application 632 may cause the monitoring device 1016 of the monitoring agent 104 to present image data 312 (e.g., video clips) for events marked as "held" in the state table 302 (e.g., because they are from the same monitoring location 602 as the selected event) within the corresponding event data window 502 of the display 504. Providing such image data 312 of events that have been grouped with the selected event along with the live video stream from the monitoring location 602 may allow the monitoring agent 104 to determine the context in which the selected event occurred, such as by presenting video clips of events that occurred before or after the selected event.

[0071] As another example, the monitoring application 632 may additionally or alternatively populate and / or annotate the selected event with other data 314 for events marked as "keep" in the state table 302 (e.g., because they are from the same monitoring location 602 as the selected event). Figure 5 One or more event data windows 502 are shown, or supplemental information is otherwise presented on screen 504, such as by providing a textual description of the other event (e.g., "motion detected by the living room camera") and / or a threat level assigned to such event (e.g., as described below in conjunction with Figure 10 8, by presenting a user interface to access one or more recorded audio tracks associated with such an event, by presenting an indicator of motion detected during such an event, and / or by presenting an indicator of a detected face corresponding to such an event. Further, in some embodiments, the monitoring application 632 can additionally or alternatively use other data 314 for events marked as "keep" in the state table 302 (e.g., because they are from the same monitoring location 602 as the selected event) to generate and display a list of events in chronological order (e.g., as a timeline).

[0072] like Figure 5 As shown, in some embodiments, the monitoring application 632 can cause the screen 504 of the monitoring device 1016 to present a scroll bar 506 that the monitoring agent 104 can manipulate, for example, to access and view additional event data windows 502 that cannot fit within the display area of the monitoring device 1016.

[0073] While presenting and reviewing a live video feed and / or other information relating to a selected event using the display 504, the monitoring agent 104 may (A) provide input indicating that the selected event does not present a security threat, thereby causing the monitoring service 630 to set the status indicator 316 of the selected event to "clear," (B) provide input indicating that the selected event does present a security threat, thereby causing the monitoring service 630 to set the status indicator 316 of the selected event to "threat," or (C) cease reviewing the event for any of a number of reasons, thereby causing the monitoring service 630 to again set the status indicator 316 of the selected event to "new." Indicators of such input / actions taken by the monitoring agent 104 regarding the monitoring application 632 may be sent from the monitoring application 632 to the monitoring service 630, e.g., as a Figure 3 In some embodiments, regardless of the action taken by the monitoring agent 104, the resulting change to the status indicator 316 of the selected event may also be applied to the status indicators 316 of other events that were previously changed to "keep" when the event was selected. Figure 4A In the example shown, for example, if monitoring agent "A1" stops actively checking for event "E1", then monitoring service 630 can change the status indicators 316 of events "E1", "E2", and "E4" to "new". Similarly, Figure 4BFor example, if monitoring agent "A1" provides input indicating that event "E1" does not involve an actual security threat, monitoring service 630 may change the status indicators 316 of events "E1," "E2," and "E4" to "clear." As yet another example, and also as Figure 4B For example, if monitoring agent "A3" provides input indicating that event "E3" does involve an actual security threat, monitoring service 630 may change the status indicator 316 of event "E3" to "Threat."

[0074] Thus, the monitoring service 630 enables events to be grouped based on location and / or time considerations, and a single monitoring agent 104 can review and categorize multiple events as a group. Thus, this configuration can significantly reduce the number of human monitoring agents 104 required to effectively review and categorize events distributed to them for review, and can also minimize the number of simultaneous peer-to-peer connections established with individual cameras 604.

[0075] Reference again Figure 3 , further illustrating that one or more components of the monitoring service 630 (e.g., Figure 10 Example routine 328 executed by the monitoring service 1040 shown in FIG. Figure 3 As shown, routine 328 may begin at step 330 where monitoring service 630 may cause a first computing device (e.g., Figure 1 1 ) displays a first notification of a first event (e.g., event "E1" reflected in state table 302) detected at a monitoring location (e.g., location "L1"). In some embodiments, for example, monitoring service 630 can send event data to monitoring device 1016, which is operated by monitoring agent "A1," to cause the device to display a video clip of event "E1" within event window 106 of display 102.

[0076] At step 332 of routine 328, the monitoring service 630 can cause a second computing device (e.g., another monitoring device 1016) to display a second notification of a second event (e.g., event "E2" reflected in the state table 302) detected at the monitoring location (e.g., location "L1"). In some embodiments, for example, the monitoring service 630 can send event data to the other monitoring device 1016 operated by monitoring agent "A2" to cause the device to display a video clip of event "E2" within the event window 106 of the display 102.

[0077] At step 334 of routine 328, the monitoring service 630 may cause the second computing device (e.g., the monitoring device 1016 operated by the monitoring agent "A2") to stop displaying the second notification in response to the change in state of the first event. Figure 4A In some embodiments, in response to the monitoring service 630 determining that the status indicator 316 of event “E1” has been set to a value indicating that the event is actively being reviewed by monitoring agent “A1” (e.g., “reviewed”), the monitoring service 630 may change the agent ID 320 of event “E2” in the status table 302 to a value indicating that the event is no longer assigned to monitoring agent “A2” (e.g., “unassigned”), thereby relieving monitoring agent “A2” of the responsibility for reviewing event “E2”.

[0078] The following also combines Figure 14A 、 Figure 14B 、 Figure 14C 、 Figure 14D 、 Figure 14E 、 Figure 14F 、 Figure 14G 、 Figure 15 Describes the functionality that may be provided by one or more components of the monitoring service 630 (e.g., Figure 10 Additional example routines 1400, 1410, 1420, 1440, 1460, 1470, 1480, 1500, and 1600 that the monitoring service 1040 (shown) executes to implement various aspects of the functionality described herein.

[0079] Figure 6 is a schematic diagram of an example security system 600 that can be employed with various aspects of the present disclosure. As shown, in some embodiments, the security system 600 may include multiple monitoring locations 602 (in Figure 6 ), Monitoring Center Environment 622, Surveillance Center Environment 626, one or more client devices 624, and one or more communication networks 620. Monitoring location 602, Monitoring Center Environment 622, Surveillance Center Environment 626, one or more client devices 624, and one or more communication networks 620 may each include one or more computing devices (e.g., as described below with reference to Figure 17104). The client device(s) 624 may include one or more client applications 634, e.g., as applications hosted on or otherwise accessible by the client device(s) 624. In some embodiments, the client applications 634 may be embodied as web applications accessible via a browser of the client device(s) 624. The monitoring center environment 622 may include one or more monitoring applications 632, e.g., as applications hosted on or otherwise accessible by a computing device within the monitoring center environment 622. In some embodiments, the monitoring applications 632 may be embodied as web applications accessible via a browser of a computing device operated by a monitoring agent 104 within the monitoring center environment 622. The monitoring center environment 626 may include a monitoring service 630 and one or more transport services 628.

[0080] like Figure 6 As shown, monitoring location 602 may include one or more image capture devices (e.g., cameras 604A and 604B), one or more contact sensor components (e.g., contact sensor component 606), one or more keypads (e.g., keypad 608), one or more motion sensor components (e.g., motion sensor component 610), base station 612, and router 614. As shown, base station 612 may host monitoring client 616.

[0081] In some embodiments, router 614 may be a wireless router configured to communicate with devices disposed at monitoring location 602 (e.g., devices 604A, 604B, 606, 608, 610, and 612) via communications consistent with a communication standard such as any of the various Institute of Electrical and Electronics Engineers (IEEE) 108.11 standards. Figure 6 6. As an example, the router 614 can also be configured to communicate with the network(s) 620. In some embodiments, the router 614 can implement a local area network (LAN) within or near the monitoring location 602. In other embodiments, other types of networking technologies can additionally or alternatively be used within the monitoring location 602. For example, in some embodiments, the base station 612 can receive and forward communication packets sent by one or both of the cameras 604A, 604B via a point-to-point personal area network (PAN) protocol such as Bluetooth. Other suitable wired, wireless, and mesh network technologies and topologies will be apparent with the benefit of this disclosure and are intended to fall within the scope of the examples disclosed herein.

[0082] The network(s) 620 may include one or more public and / or private networks that support, for example, Internet Protocol (IP) communications. The network(s) 620 may include, for example, one or more LANs, one or more PANs, and / or one or more wide area networks (WANs). LANs that may be employed include wired or wireless networks that support various LAN standards (such as IEEE 108.11 version, etc.). PANs that may be employed include wired or wireless networks that support various PAN standards (such as Bluetooth, ZIGBEE, etc.). WANs that may be employed include wired or wireless networks that support various WAN standards (such as Code Division Multiple Access (CDMA), Global System for Mobile (GSM), etc.). Regardless of the specific networking technology employed, the network(s) 620 may connect components within the monitoring location 602, the monitoring center environment 622, the monitoring center environment 626, and the client device(s) 624 and enable data communication therebetween. In at least some embodiments, both the monitoring center environment 622 and the monitoring center environment 626 may include networking components (e.g., similar to the router 614) configured to communicate with the network(s) 620 and the various computing devices within these environments.

[0083] The monitoring center environment 626 may include physical space, communications, cooling, and power infrastructure to support networked operations of a large number of computing devices. For example, the infrastructure of the monitoring center environment 626 may include rack space into which computing devices may be installed, uninterruptible power supplies, cooling plenums and equipment, and networking equipment. The monitoring center environment 626 may be dedicated to the security system 600, may be a non-dedicated, commercially available cloud computing service (e.g., MICROSOFT AZURE, AMAZON WEB SERVICES, GOOGLE CLOUD, etc.), or may include a hybrid configuration consisting of dedicated and non-dedicated resources. Regardless of its physical or logical configuration, such as Figure 6 As shown, monitoring center environment 626 may be configured to host monitoring service 630 and transmission service(s) 628 .

[0084] The monitoring center environment 622 may include a plurality of computing devices (e.g., desktop computers) and network equipment (e.g., one or more routers) that enable communication between the computing devices and the network(s) 620. The client device(s) 624 may each include a personal computing device (e.g., desktop computer, laptop, tablet, smartphone, etc.) and network equipment (e.g., router, cellular modem, cellular radio transceiver, etc.). Figure 6By way of example, the monitoring center environment 622 may be configured to host monitoring application(s) 632 , and the client device(s) 624 may be configured to host client application(s) 634 .

[0085] Devices 604A, 604B, 606, and 610 may be configured to acquire analog signals via sensors incorporated into the devices, generate digital sensor data based on the acquired signals, and transmit the sensor data to (e.g., via a wireless link with router 614) base station 612. The type of sensor data generated and transmitted by these devices may vary depending on the characteristics of the sensors they include. For example, image capture devices or cameras 604A and 604B may acquire ambient light, generate one or more frames of image data based on the acquired light, and transmit the frame(s) to base station 612, although the pixel resolution and frame rate may vary depending on the capabilities of the devices. In some embodiments, cameras 604A and 604B may also receive and store filter zone configuration data and filter the frame(s) using one or more filter zones (e.g., areas within the camera's FOV from which image data is edited for various reasons, such as to exclude trees that may generate false positive motion detection results on a windy day) before transmitting the frame(s) to base station 612. Figure 6 In the example shown, camera 604A has a field of view (FOV) that originates near the front door of monitoring location 602 and can capture images of sidewalk 636, road 638, and the space between monitoring location 602 and road 64A0. On the other hand, camera 604B has a FOV that originates near the bathroom of monitoring location 602 and can capture images of the living room and dining area of monitoring location 602. Camera 604B can also capture images of the outdoor area outside of monitoring location 602, for example, through windows 618A and 618B on the right-hand side of monitoring location 602.

[0086] The various sensor components (eg Figure 6 The contact sensor assembly 606 shown may include, for example, a sensor that can detect the presence of a magnetic field generated by a magnet when the magnet is in proximity to the sensor. When the magnetic field is present, the contact sensor assembly 606 can generate Boolean sensor data specifying the closed state of a window, door, etc. When the magnetic field is not present, the contact sensor assembly 606 can instead generate Boolean sensor data specifying the open state of a window, door, etc. In either case, Figure 6 The illustrated contact sensor assembly 606 may transmit sensor data to the base station 612 indicating whether the front door of the monitored location 602 is open or closed.

[0087] The various motion sensor components (eg Figure 6 The motion sensor assembly 610 shown may include, for example, a component that can emit high-frequency pressure waves (e.g., ultrasonic waves) and a sensor that can obtain reflections of the emitted waves. When the sensor detects a change in the reflected pressure waves, for example because one or more objects move within the space monitored by the sensor, the motion sensor assembly 610 can generate Boolean sensor data specifying an alarm state. When the sensor does not detect a change in the reflected pressure waves, for example because no objects move within the monitored space, the motion sensor assembly 610 can instead generate Boolean sensor data specifying a stationary state. In either case, the motion sensor assembly 610 can transmit the sensor data to the base station 612. It should be noted that the specific sensing modalities described above are not limited to the present disclosure. For example, as just one example of an alternative embodiment, the motion sensor assembly 610 can instead (or additionally) base its operation on the detection of changes in reflected electromagnetic waves.

[0088] While specific types of sensors are described above, it should be understood that other types of sensors may additionally or alternatively be employed within monitoring location 602 to detect the presence and / or movement of people, or other conditions of interest, such as smoke, elevated carbon dioxide levels, water accumulation, etc., and transmit data indicative of these conditions to base station 612. For example, while Figure 6 Not illustrated, but in some embodiments, one or more sensors may be employed to detect sudden changes in measured temperature, sudden changes in incident infrared radiation, sudden changes in incident pressure waves (e.g., sound waves), etc. Still further, in some embodiments, some such sensors and / or base station 612 may additionally or alternatively be configured to recognize specific signal patterns indicative of specific conditions, such as sound patterns indicative of breaking glass, footsteps, coughing, etc.

[0089] Figure 6The illustrated keypad 608 can be configured to interact with a user and, in response to such interaction, interoperate with other devices disposed in the monitoring location 602. For example, in some examples, the keypad 608 can be configured to receive input from a user specifying one or more commands and transmit the specified commands to one or more addressed devices and / or processes, such as one or more devices disposed in the monitoring location 602, monitoring application(s) 632, and / or monitoring service 630. The transmitted commands can include, for example, a code authenticating the user as a resident of the monitoring location 602 and / or a code requesting activation or deactivation of one or more devices disposed in the monitoring location 602. In some embodiments, the keypad 608 can include a user interface (e.g., a tactile interface, such as a set of physical buttons or a set of "soft" buttons on a touchscreen) configured to interact with the user (e.g., receive input from the user and / or present output to the user). Further, in some embodiments, the keypad 608 can receive responses to the transmitted commands and present such responses as visual or audio output via the user interface.

[0090] Figure 6 The illustrated base station 612 can be configured to interoperate with other security system devices disposed at the monitoring location 602 to provide local command and control and / or store-and-forward functionality via the execution of a monitoring client 616. To implement the local command and control functionality, the base station 612 can perform various programmed operations via the execution of the monitoring client 616 in response to various events. Examples of such events include receiving a command from the keypad 608, receiving a command from one of the monitoring application(s) 632 or client application(s) 634 via the network(s) 620, and detecting the occurrence of a scheduled event. The programmed operations performed by the base station 612 in response to an event via the execution of the monitoring client 616 can include, for example, activating or deactivating one or more of the devices 604A, 604B, 606, 608, and 610; sounding an alarm; reporting an event to the monitoring service 630; and / or transmitting "location data" to one or more of the transmission services 628. Such location data may include, for example, data specifying sensor readings (sensor data), image data acquired by one or more cameras 604, configuration data for one or more devices disposed at the monitoring location 602, commands input and received from a user (e.g., via the keypad 608 or client application 634), or data derived from one or more of the aforementioned data types (e.g., filtered sensor data, filtered image data, summaries of sensor data, event data specifying events detected at the monitoring location 602 via sensor data, etc.).

[0091] In some embodiments, to implement store-and-forward functionality, the base station 612, through execution of the monitoring client 616, can receive sensor data, package the data for transmission, and store the packaged sensor data in local memory for subsequent transmission. This communication of packaged sensor data can include, for example, transmitting the packaged sensor data as a payload of a message to one or more of the transport service(s) 628 when a communication link to the transport service(s) 628 via the network(s) 620 is operable. In some embodiments, this packaging of sensor data can include filtering the sensor data using one or more filter fields and / or generating one or more summaries of multiple sensor readings (maximum, average, change in value since a previously transmitted value, etc.).

[0092] The transport service(s) 628 of the monitoring center environment 626 may be configured to receive messages from monitoring locations (e.g., monitoring location 602), parse the messages to extract payloads included therein, and store the payloads and / or data derived therefrom in one or more data stores hosted in the monitoring center environment 626. Figure 10 An example of such a data store is described. In some embodiments, the transport service(s) 628 can expose and implement one or more application programming interfaces (APIs) configured to receive, process, and respond to calls from base stations (e.g., base station 612) via the network(s) 620. Individual instances of the transport service(s) 628 can be associated with and specific to certain manufacturers and / or models of location-based monitoring devices (e.g., SIMPLISAFE devices, RING devices, etc.).

[0093] The (one or more) APIs of (one or more) transport services 628 can be implemented using various architectural styles and interoperability standards. For example, in certain embodiments, one or more such APIs may include a web service interface implemented using a representational state transfer (REST) architectural style. In such embodiments, the Hypertext Transfer Protocol (HTTP) can be used together with JavaScript Object Notation (JSON) and / or Extensible Markup Language to encode API calls. Such API calls can be addressed to one or more uniform resource locators (URLs) corresponding to the API endpoints monitored by (one or more) transport services 628. In some embodiments, portions of the HTTP communication can be encrypted to increase security. Alternatively (or additionally), in some embodiments, the one or more APIs of (one or more) transport services 628 can be implemented as .NET network APIs that respond to HTTP data submissions (POSTs) to specific URLs. Alternatively (or additionally), in some embodiments, the one or more APIs of (one or more) transport services 628 can be implemented using simple file transfer protocol commands. Thus, the (one or more) APIs of (one or more) transport services 628 are not limited to any particular embodiment.

[0094] The monitoring service 630 in the monitoring center environment 626 can be configured to control the overall logical setup and operation of the security system 600. As can be seen, the monitoring service 630 can communicate and interoperate with the transport service(s) 628, the monitoring application(s) 632, the client application(s) 634, and various devices disposed at the monitoring location 602 via the network(s) 620. In some embodiments, the monitoring service 630 can be configured to monitor data from various sources for events (e.g., break-in events) and, when an event is detected, notify one or more of the monitoring application 632 and / or the client application(s) 634 of the event.

[0095] In some embodiments, the monitoring service 630 can additionally be configured to maintain status information about the monitoring location 602. Such status information can indicate, for example, whether the monitoring location 602 is secure or threatened. In some embodiments, the monitoring service 630 can be configured to change the status information to indicate that the monitoring location 602 is secure only upon receiving a communication indicating a clear event (e.g., rather than making such a change solely due to the absence of additional events being detected). This feature can prevent "bump and smash" thefts (e.g., where an intruder quickly destroys a monitoring device or disables the monitoring device) from being successfully executed. Additionally, in some embodiments, the monitoring service 630 can be configured to monitor one or more specific areas within the monitoring location 602, such as one or more specific rooms or other distinct areas within and / or surrounding the monitoring location 602 and / or corresponding image capture devices deployed in the monitoring location (e.g., Figure 6 One or more defined areas within the FOV of cameras 604A and 604B shown.

[0096] The (one or more) separate monitoring applications 632 of the monitoring center environment 622 can be configured to enable monitoring personnel to interact with corresponding computing devices to provide monitoring services for corresponding locations (e.g., monitoring location 602), and to perform various programmed operations in response to such interactions. For example, in some embodiments, the monitoring application 632 can control its host computing device to provide information about events detected at a monitoring location such as monitoring location 602 to the person operating the computing device. Such events can include, for example, detected movement within a specific area of the monitoring location 602. As described above in conjunction with Figure 1 and Figure 2 As described, in some embodiments, the monitoring application 632 can enable the monitoring device 1016 to present video clips of events within respective event windows 106 of the screen 102, and can also establish a streaming connection with one or more cameras 604 at the monitoring location, and enable the monitoring device 1016 to provide streaming video from such (one or more) cameras 604 within the video feed window 112 and / or the main viewer window 114 of the screen 110, and allow audio communication between the monitoring device 1016 and the (one or more) cameras 604.

[0097] The client application(s) 634 of the client device(s) 624 can be configured to enable a client to interact with their computing device (e.g., their smartphone or personal computer) to access various services provided by the security system 600 for their individual home or other location (e.g., monitoring location 602), and to perform various programmed operations in response to such interactions. For example, in some embodiments, the client application 634 can control the client device 624 (e.g., smartphone or personal computer) to provide information about events detected at a monitoring location, such as monitoring location 602, to the client operating the client device 624. Such events can include, for example, detected movement within a particular area of the monitoring location 602. In some embodiments, the client application 634 can additionally or alternatively be configured to process input received from the client to enable or disable one or more devices disposed within the monitoring location 602. Further, as described above in conjunction with Figure 3 As described, the client application 634 may additionally or alternatively be configured to establish a streaming connection with one or more cameras 604 at the monitored location and cause the client device 624 to display streaming video from such (one or more) cameras 604, as well as to allow audio communication between the client device 624 and the (one or more) cameras 604.

[0098] Now turn Figure 7 , schematically illustrating an example base station 612. Figure 7 As shown, base station 612 may include at least one processor 702, volatile memory 704, non-volatile memory 708, at least one network interface 706, a user interface 714, a battery assembly 716, and an interconnect mechanism 718. Non-volatile memory 708 may store executable code 710 and, as illustrated, may also include data storage 712. In some embodiments, the features of base station 612 listed above may be incorporated into housing 720 or otherwise supported thereby. In some embodiments, user interface 714 of base station 612 may simply include: one or more speakers that provide audio output to the user regarding changes in the operational state of security system 600, detected threats, etc.; and / or one or more visual indicators (e.g., light emitting diode (LED) indicators) that indicate when base station 612 is operational in response to user input (e.g., via keypad 608). In other embodiments, the user interface may additionally or alternatively include more complex output components (e.g., a display screen) and / or may include one or more user input components, such as one or more microphones (e.g., to receive voice commands) and / or a keypad (e.g., to receive tactile input).

[0099] In some embodiments, the non-volatile (non-transitory) memory 708 may include one or more read-only memory (ROM) chips; one or more hard disk drives or other magnetic or optical storage media; one or more solid-state drives (SSDs), such as flash drives or other solid-state storage media; and / or one or more hybrid magnetic and SSDs. In some embodiments, the code 710 stored in the non-volatile memory may include an operating system and one or more applications or programs configured to execute under the control of the operating system. In some embodiments, the code 710 may additionally or alternatively include specialized firmware and embedded software that is executable without reliance on a commercially available operating system. In any case, regardless of how the code 710 is specifically implemented, execution of the code 710 may implement Figure 6 The monitoring client 616 is shown and enables storage and manipulation of data of the monitoring client 616 within the data storage 712.

[0100] The processor 702 of the base station 612 may include one or more processors configured to execute instructions encoded in a computer-readable medium (such as a computer program specifically implemented by the code 710) to control the operation of the base station 612. As used herein, the term "processor" describes a circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard-coded into the circuit or soft-coded by instructions maintained in a memory device (e.g., volatile memory 704) and executed by the circuit. In some embodiments, the processor 702 may be specifically implemented by one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), neural processing units (NPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), and / or multi-core processors.

[0101] Before executing code 710, processor 702 may copy at least a portion of code 710 from non-volatile memory 708 to volatile memory 704. In some embodiments, volatile memory 704 may include one or more static or dynamic random access memory (RAM) chips and / or cache memory (e.g., memory disposed on the silicon die of processor 702). Volatile memory 704 may provide faster response times than main memory (such as non-volatile memory 708).

[0102] By executing code 710, processor 702 can control the operation of network interface 706. For example, in some embodiments, network interface 706 may include one or more physical interfaces (e.g., a radio transceiver, an Ethernet port, a universal serial bus (USB) port, etc.) and a software stack including drivers and / or other code 710 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. Such communication protocols may include, for example, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Thus, network interface 706 can enable base station 612 to communicate via a computer network (e.g., a computer network provided by Figure 6 The LAN established by router 614, Figure 6 (one or more) network 620 and / or point-to-point connection) to access other computing devices (e.g., arranged in Figure 6 For example, in some embodiments, the network interface 706 can utilize sub-GHz wireless networking to send a wake-up message to the other computing device to request a sensor data stream.

[0103] By executing code 710, processor 702 can additionally control the operation of a hardware and software stack, which includes drivers and / or other code 710 configured to communicate with other system devices. Thus, base station 612 can interact with other system components in response to received input. Such input can specify, for example, a value to be stored in data memory 712. Base station 612 can also provide an output representing the value stored in data memory 712. In some embodiments, base station 612 can additionally include one or more light emitting diodes (LEDs) or other visual indicators that visually convey information, such as system status or alarm events. Further, in some embodiments, base station 612 can additionally or alternatively include a whistle (e.g., a 95 decibel (dB) whistle) or other audio output device that can be controlled by processor 702 to output an audio indication that an intrusion event has been detected.

[0104] The various components of the base station 612 described above can communicate with each other via an interconnect mechanism 718. In some embodiments, the interconnect mechanism 718 may include a communication bus. Further, in some embodiments, the battery assembly 716 may be configured to supply operating power to the various features of the base station 612 described above. In some embodiments, the battery assembly 716 may include at least one rechargeable battery (e.g., one or more nickel metal hydride (NiMH) or lithium batteries). In some embodiments, such a rechargeable battery (or multiple rechargeable batteries) may have a runtime capacity sufficient to operate the base station 612 for twenty-four hours or longer when the base station 612 is disconnected from line power or otherwise not receiving line power. In some embodiments, the battery assembly 716 may additionally or alternatively include a power supply circuit that receives, regulates, and distributes line power to operate the base station 612 and / or recharge one or more rechargeable batteries. Such a power supply circuit may include, for example, a transformer and rectifier, as well as other circuitry, that converts AC line power to DC equipment and / or recharging power.

[0105] Now turn Figure 8 , schematically illustrates an example keypad 608. Figure 8 As shown, the keypad 608 may include at least one processor 802, volatile memory 804, non-volatile memory 808, at least one network interface 806, a user interface 814, a battery assembly 816, and an interconnect mechanism 818. The non-volatile memory 808 may store executable code 810 and, as illustrated, may also include data storage 812. In some embodiments, the features of the keypad 608 listed above may be incorporated into the housing 820 or may be otherwise supported thereby.

[0106] In some embodiments, the corresponding descriptions of the processor 702, volatile memory 704, non-volatile memory 708, interconnection mechanism 718, and battery assembly 716 with reference to the base station 612 apply to the corresponding descriptions of the processor 802, volatile memory 804, non-volatile memory 808, interconnection mechanism 818, and battery assembly 816 with reference to the keypad 608. Therefore, these descriptions will not be repeated here.

[0107] By executing code 810, the processor 802 of the keypad 608 can control the operation of the network interface 806. In some embodiments, the network interface 806 may include one or more physical interfaces (e.g., a radio transceiver, an Ethernet port, a USB port, etc.) and a software stack that includes drivers and / or other code 810 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. Such communication protocols may include, for example, TCP and UDP. Thus, the network interface 806 can enable the keypad 608 to access other computing devices (e.g., a network device arranged in a computer network) via a computer network (e.g., a LAN established by a router 614). Figure 6 other devices in the monitoring location 602) and communicate with them.

[0108] By executing the code 810, the processor 802 can further control the operation of the user interface 814. In some embodiments, the user interface 814 can include user input and / or output devices (e.g., physical keys arranged as a keypad, a touch screen, a display, a speaker, a camera, a biometric scanner, an environmental sensor, etc.) and a software stack that includes a driver and / or other code 810 configured to communicate with the user input and / or output devices. As can be seen, the user interface 814 can enable the keypad 608 to interact with the user to receive input and / or present output. Examples of outputs that can be presented by the user interface 814 include one or more GUIs that include one or more controls configured to display output and / or receive input. The input received by the user interface 814 can specify, for example, a value to be stored in the data memory 812. The output provided by the user interface 814 can also indicate the value stored in the data memory 812. In some embodiments, portions of the user interface 814 (e.g., one or more LEDs) can be accessible and / or visible as part of the housing 820 or through it.

[0109] Now turn Figure 9 , schematically illustrating an example sensor assembly 924. Several example implementations of the sensor assembly 924 (e.g., cameras 604 and 604B, motion sensor assembly 610, and contact sensor assembly 606) are shown in FIG. Figure 6 As exemplified in and described above. Figure 9As shown, sensor assembly 924 may include at least one processor 902, volatile memory 904, non-volatile memory 908, at least one network interface 906, a battery assembly 916, an interconnect mechanism 918, and at least one sensor 922. Non-volatile memory 908 may store executable code 910 and, as shown, may also include data storage 912. In some embodiments, the features of sensor assembly 924 listed above may be incorporated into or included as part of housing 920. Further, in some embodiments, sensor assembly 924 may additionally include a user interface 914.

[0110] In some embodiments, the corresponding descriptions of the processor 702, volatile memory 704, non-volatile memory 708, interconnect mechanism 718, and battery assembly 716 with reference to the base station 612 apply to the corresponding descriptions of the processor 902, volatile memory 904, non-volatile memory 908, interconnect mechanism 918, and battery assembly 916 with reference to the sensor assembly 924. Therefore, these descriptions will not be repeated here.

[0111] By executing code 910, processor 902 can control the operation of network interface 906 and user interface 914 (if present). In some embodiments, network interface 906 may include one or more physical interfaces (e.g., radio transceiver, Ethernet port, USB port, etc.) and a software stack including drivers and / or other code 910 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN and / or WAN standard communication protocols. Such communication protocols may include, for example, TCP and UDP. Thus, network interface 906 can enable sensor component 924 to access other computing devices (e.g., devices arranged in a computer network) via a computer network (e.g., a LAN established by router 614). Figure 6 602). For example, in some embodiments, upon executing code 910, processor 902 may control the network interface to stream (e.g., via UDP) sensor data acquired from sensor assembly 922 to base station 612. Further, in some embodiments, upon executing code 910, processor 902 may additionally or alternatively control network interface 906 to enter a power saving mode, such as by powering off a 2.4 GHz radio and powering on a sub-GHz radio, both included in network interface 906. In such embodiments, upon executing code 910, processor 902 may additionally control network interface 906 to enter a streaming mode, such as by powering on the 2.4 GHz radio and powering off the sub-GHz radio, for example, in response to receiving a wake-up signal from a base station via the sub-GHz radio.

[0112] By executing code 910, processor 902 can additionally or alternatively control other operations of sensor assembly 924. In some embodiments, for example, user interface 914 of sensor assembly 924 can include user input and / or output devices (e.g., physical buttons, a touch screen, a display, a speaker, a camera, an accelerometer, a biometric scanner, an environmental sensor, one or more LEDs, etc.) and a software stack that includes drivers and / or other code 910 configured to communicate with the user input and / or output devices. Thus, sensor assembly 924 can enable user interface 914 to interact with a user to receive input and / or present output. The output presented by user interface 914 can include, for example, one or more GUIs that include one or more controls configured to display output and / or receive input. The input received by user interface 914 can, for example, specify a value to be stored in data storage 912. The output provided by user interface 914 can also indicate the value stored in data storage 912. In some embodiments, portions of sensor assembly 924 can be accessible and / or visible as part of housing 920 or through it.

[0113] like Figure 9 As shown, the sensor assembly 924 may include one or more types of sensors 922, such as those described above with reference to FIG. Figure 6 604 and 604B, motion sensor assembly 610, and contact sensor assembly 606, or other types of sensors. In some embodiments, for example, sensor(s) 922 may include a camera and a temperature sensor. Regardless of the type(s) of sensor(s) XD22 employed, processor 902 may (e.g., via execution of code 910) acquire sensor data from sensor(s) 922 and stream the acquired sensor data to processor 902 for transmission to base station 612.

[0114] It should be noted that in some implementations of devices 802 and 902, operations performed by processors 802 and 902 under the control of respective controls of code 810 and 910 may be hard-coded and / or implemented using hardware rather than as a combination of hardware and software.

[0115] Now turn Figure 10 , schematically illustrated Figure 6 Aspects of monitoring center environment 626, monitoring center environment 622, one of the client devices 624, network(s) 620, and a plurality of monitoring locations 602A through 602N (collectively, monitoring locations 602) are shown. Figure 10As shown, in some embodiments, the monitoring service 630 may include a location data storage 1002, an image data storage 1004, an artificial intelligence (AI) service 1008, an event listening service 1010, an identity provider service 1012, a customer service 1038, a monitoring service 1040, and a camera streaming service 1042. Figure 10 As shown, the monitoring center environment 622 may include a plurality of monitoring devices 1016A to 1016M (collectively, monitoring devices 1016) that host or are otherwise configured to access corresponding monitoring applications 632A to 632M, and each monitoring location 602A to 602N may include a corresponding monitoring client 616A to 616N (collectively, monitoring client 616), e.g., at a base station 612 ( Figure 10 At each monitoring position 602A to 602N in the (not shown) Figure 1 and Figure 2 As described, in some embodiments, the monitoring application 632 can be configured to cause the monitoring device 1016 to display screens 102, 110 that enable the monitoring agent 104 to visually monitor activity at one or more monitoring locations 602 and to conduct audio conversations with one or more individuals at such locations (e.g., via a microphone and speaker of a camera 604 at the monitoring location 602). Figure 10 As further shown in FIG, in some embodiments, the transport service(s) 628 may include a plurality of different transport services 628A through 628D configured to receive location data packets, such as location data packets 1014A through 1014D, from monitoring clients 616A through 616N deployed at respective monitoring locations 602A through 602N.

[0116] The location data storage 1002 of the monitoring service 630 can be configured to store the location data in association with an identifier of the customer whose monitoring location 602 is being monitored within a plurality of records. For example, the location data can be stored in a record along with an identifier of the customer and / or an identifier of the monitoring location 602 to associate the location data with the customer and the monitoring location 602. The image data storage 1004 of the monitoring service 630 can be configured to store one or more frames of image data in association with an identifier of the location and a timestamp at which the image data was acquired within a plurality of records.

[0117] The AI service 1008 of the monitoring service 630 can be configured to process images and / or image sequences to identify semantic regions, movements, faces, and other features within the images or image sequences. The event monitoring service 1010 of the monitoring service 630 can be configured to scan the received location data to find events, and execute one or more event handlers to process the events when an event is identified. In some embodiments, such event handlers can be configured to identify events and transmit messages about these events to one or more recipient services (e.g., customer service 1038 and / or monitoring service 1040). The operations that can be performed by customer service 1038 and / or monitoring service 1040 based on the events identified by the event monitoring service 1010 are further described below. In some embodiments, the event monitoring service 1010 can interoperate with the AI service 1008 to identify events within the image data.

[0118] The identity provider service 1012 can be configured to receive an authentication request including security credentials from the monitoring client 616. When the identity provider 1012 can authenticate the security credentials in the request (e.g., via a validation function, a cross-reference lookup, or some other authentication process), the identity provider 1012 can transmit a security token in response to the request. The monitoring client 616 can receive, store, and include the security token in a subsequent location data (e.g., location data 1014A) packet so that a receiving transport service (e.g., transport service 628A) can securely process (e.g., unpack / parse) the packet to extract the location data before passing it to the monitoring service 630. In some embodiments, for example, the security token can be a JSON Web Token (JWT), such as the following in conjunction with Figure 18 Token 1802 is described.

[0119] The transport service(s) 628 of the monitoring center environment 626 may be configured to receive the location data packet 1014, verify the authenticity of the packet 1014, parse the packet 1014, and extract the location data encoded therein before passing the location data to the monitoring service 630 for processing. The location data so processed may include the location data described above with reference to FIG. Figure 6 In some embodiments, each transmission service 628 can be configured to process location data packets 1014 generated by location-based monitoring devices of a particular manufacturer and / or model. The monitoring client 616 can be configured to generate location data packets (e.g., location data packets 1014) based on sensor information received at the monitoring location 602 and transmit them to the monitoring service 630, for example, via the network(s) 620.

[0120] The monitoring service 1040 can maintain a record of events identified by the event listening service 1010 and can assign each event to each monitoring agent 104 currently online with the monitoring application 632. The monitoring application 632 operated by a given monitoring agent can then add the events assigned to that monitoring agent 104 to, for example, Figure 1 106 for review by the monitoring agent 104. In some embodiments, a given monitoring application 632 can use the data describing the events in its queue to retrieve location data and / or image data (from the location data store 1002 and / or image data store 1004, respectively) for presentation within or in association with the event window 106.

[0121] In response to the monitoring agent 104 identifying a particular event to be reviewed (e.g., by clicking on one of the event windows 106), the monitoring service 1040 may interact with the camera streaming service 1042 to obtain access credentials, thereby enabling a peer connection to be established with one or more cameras 604 at the monitoring location 602 corresponding to the event, and reviewing, for example, the camera streaming service 1042. Figure 2 Live video and / or audio streamed from these cameras within the video feed window 112 and / or main viewer window 114 are shown, as well as real-time verbal communication with one or more individuals near the camera(s) 604. Figure 12 Example interactions between components of the security system 600 are described that enable streaming of video and / or audio data between camera(s) 604 at a monitoring location 602 and a monitoring application 632 operated by a monitoring agent 104 .

[0122] Now turn Figure 11 , an example monitoring process 1100 that may be employed by the security system 600 is illustrated as a sequence diagram. Specifically, in some embodiments, various portions of the process 1100 may be executed by (A) executing a program executed by at least one processor (e.g., Figure 8 or Figure 9 One or more location-based devices (e.g., Figure 6 (B) monitoring the client (e.g., Figure 6 A base station (e.g., Figure 6 (C) in monitoring applications (e.g., Figure 6 A monitoring center environment (e.g., Figure 6 monitoring center environment 622); (D) in monitoring services (e.g., Figure 6Monitoring center environment (e.g., Figure 6 monitoring center environment 626); and (E) in a client application (e.g., Figure 6 634) under the control of a client device (e.g., Figure 6 624) for execution.

[0123] like Figure 11 As shown, process 1100 may begin with monitoring client 616 authenticating with monitoring service 630 by exchanging one or more authentication requests and responses 1104 with monitoring service 630. More specifically, in some embodiments, monitoring client 616 may transmit the authentication request to monitoring service 630 via one or more API calls to monitoring service 630. In such embodiments, monitoring service 630 may parse the authentication request to extract security credentials therefrom and pass such security credentials to an identity provider (e.g., Figure 10 , the identity provider service 1012) for authentication. In some embodiments, when the identity provider authenticates the security credentials, the monitoring service 630 may generate a security token and communicate the security token as a payload within the authentication response to the authentication request. In such embodiments, if the identity provider cannot authenticate the security credentials, the monitoring service 630 may instead generate an error (e.g., an error code) and communicate the error as a payload within the authentication response to the authentication request. Upon receiving the authentication response, the monitoring client 616 may parse the authentication response to extract the payload. If the payload includes an error code, the monitoring client 616 may retry the authentication and / or interact with the user of its host device (e.g., Figure 7 The user interface 714 of the base station 612) interacts with the monitoring client 616 to present an output indicating that the authentication failed. If the payload includes a security token, the monitoring client 616 may store the security token for subsequent use in the transmission of location data. It should be noted that in some embodiments, the security token may have a limited lifespan (e.g., one hour, one day, one week, one month, etc.), after which the monitoring client 616 may be required to re-authenticate with the monitoring service 630. In some embodiments, for example, the security token (e.g., Figure 18 The lifespan of a token 1802 of the described type may be defined in a header 1804 and / or payload 1806 of the token 1802 (eg, as one or more claims).

[0124] Continuing with process 1100, one or more device control systems 1102 hosted by one or more location-based devices may obtain (1106) a message describing a location (e.g., Figure 6The sensor data thus obtained may be of any of various types, as described above with reference to Figures 6 to 10 discussed. In some embodiments, the one or more device control systems 1102 may acquire sensor data continuously. In other embodiments, the one or more DCSs 1102 may additionally or alternatively acquire sensor data in response to an event, such as the expiration of a timer (push event) or the receipt of an acquisition polling signal transmitted by the monitoring client 616 (polling event). In some embodiments, the one or more device control systems 1102 may stream the sensor data to the monitoring client 616 with minimal processing other than acquisition and digitization. In such embodiments, the sensor data may constitute a sequence of vectors having separate vector members, including, for example, sensor readings and timestamps. In some embodiments, the one or more device control systems 1102 may perform additional processing of the sensor data, such as generating one or more summaries of multiple sensor readings. Still further, in some embodiments, the one or more device control systems 1102 may perform complex processing of the sensor data. For example, if the sensor component 924 ( Figure 9 If the sensor(s) 922 (shown in ) include an image capture device, the device control system 1102 may perform image processing routines such as edge detection, motion detection, facial recognition, threat assessment, event generation, and the like.

[0125] Continuing with process 1100, the device control component(s) 1102 can transmit sensor data 1108 to the monitoring client 616. Similar to sensor data acquisition, the device control system(s) 1102 can transmit sensor data 1108 continuously or in response to events, such as push events (originating from the device control system(s) 1102) or polling events (originating from the monitoring client 616).

[0126] Continuing with process 1100, monitoring client 616 may monitor (1110) monitoring location 602 by processing received sensor data 1108. In some embodiments, for example, monitoring client 616 may execute one or more image processing routines. Such image processing routines may include any of the image processing routines described above with reference to operation 1106. By distributing at least some image processing routines between device control system(s) 1102 and monitoring client 616, the amount of power consumed by battery-powered devices may be reduced by offloading processing to line-powered devices. Furthermore, in some embodiments, monitoring client 616 may perform an overall threat detection process that utilizes sensor data 1108 from multiple different device control systems 1102 as input. For example, in some embodiments, monitoring client 616 may attempt to corroborate an open state received from a contact sensor using motion and facial recognition processing of an image of a scene including a window or door to which the contact sensor is attached. If two or more of the three processes indicate the presence of an intruder, a score (e.g., a threat score) may be increased and / or a break-in event may be declared, locally recorded, and transmitted. Other processing that may be performed by the monitoring client 616 includes outputting local alerts (e.g., in response to detecting certain events and / or satisfying other criteria) and detecting maintenance conditions for location-based devices, such as the need to replace or recharge low batteries and / or replace / maintain devices hosting the device control system(s) 1102. Any of the above processes within operation 1110 may result in the creation of location data specifying the results of those processes.

[0127] Continuing with process 1100, monitoring client 616 can transmit location data 1112 to monitoring service 630 (via transport service(s) 628). Similar to the transmission of sensor data 1108, monitoring client 616 can transmit location data 1112 continuously or in response to an event, such as a push event (originating from monitoring client 616) or a polling event (originating from monitoring service 630).

[0128] Continuing with process 1100, the monitoring service 630 can process (1114) the received location data. In some embodiments, for example, the monitoring service 630 can perform one or more of the processes described above with reference to operations 1106 and / or 1110. In some embodiments, the monitoring service 630 can additionally or alternatively calculate a score (e.g., a threat score) or further refine an existing score using historical information associated with the monitored location 602 identified in the location data and / or other locations that are geographically proximate to the monitored location 602 (e.g., within the same Zone Improvement Program (ZIP) code). For example, in some embodiments, if multiple break-ins have been recorded for the monitored location 602 and / or other locations within the same ZIP code, the monitoring service 630 can increase the score calculated by the device control system 1102 and / or the monitoring client 616.

[0129] In some embodiments, the monitoring service 630 can apply a set of rules and criteria to the location data 1112 to determine whether the location data 1112 includes any events, and if so, transmit event reports 1116A and / or 1116B to the monitoring application 632 and / or the client application 634. In some embodiments, for example, the monitoring service 1040 can assign one or more events to a particular monitoring agent 104 so that the events will be forwarded to the monitoring application 632 operating on the monitoring agent 104, e.g., for reporting within the corresponding event window 106 ( Figure 1 116B). An event can be, for example, a specific type of event (e.g., a break-in) or a specific type of event that meets additional criteria (e.g., movement within a specific area combined with a threat score exceeding a threshold). Event reports 1116A and / or 1116B can have a priority based on the same criteria used to determine whether an event reported therein is reportable, or can have a priority based on a different set of criteria or rules.

[0130] Continuing with process 1100, the monitoring application 630 in the monitoring center environment 622 may be accessed through, for example, one or more GUIs such as Figure 1 and Figure 2 The GUI (shown as screens 102 and 110) interacts 1118 with the monitoring agent 104. Such a GUI can provide details and context about one or more events.

[0131] like Figure 11 As shown, a client application 634 of a client device 624 (e.g., a smartphone, personal computer, or other endpoint device) can also interact with at least one client through, for example, one or more GUIs (1120). Such GUIs can provide details and context about one or more events.

[0132] It should be noted that the processing of sensor data and / or location data as described above with reference to operations 1106, 1110, and 1114 can be performed by processors disposed within various portions of the security system 600. In some embodiments, the device control system(s) 1102 can perform minimal processing of the sensor data (e.g., only acquiring and streaming), and the remainder of the processing described above can be performed by the monitoring client 616 and / or monitoring service 630. This approach can help extend the battery runtime of location-based devices. In other embodiments, the device control system(s) 1102 can perform as much sensor data processing as possible, allowing the monitoring client 616 and monitoring service 630 to perform only the processing required for the sensor data across location-based devices and / or locations. This approach can help improve the scalability of the security system 600 in terms of adding new locations.

[0133] Figure 12 and Figure 13 Example techniques are illustrated for establishing a peer-to-peer connection (e.g., for video and / or audio streaming) between a camera 604 at a monitoring location 602 and either or both of (A) a monitoring application 632 hosted on or otherwise accessible by a monitoring device 1016 and (B) a client application 634 hosted on or otherwise accessible by a client device 624. In some embodiments, the monitoring application 632 and the client application 634 can be web applications accessed using browsers hosted on the monitoring device 1016 and the client device 624, respectively, and the WebRTC functionality of these browsers can be used to establish a peer-to-peer connection with the camera 604. As described below in conjunction with Figure 13 As described above, the camera streaming service 1042 can provide a signaling channel for establishing a peer-to-peer connection between the camera 604 and the corresponding browser. As an example, the camera streaming service 1042 can be implemented using the Amazon Kinesis video streaming service provided by Amazon Web Services (AWS).

[0134] like Figure 12 As shown by arrow 1202 in FIG. 1 , the monitoring application 632 can provide a user token to the monitoring service 1040. The user token can correspond to a monitoring agent 104 that has authenticated to the monitoring application 632 and can be included in a request for live streaming access to the camera(s) 604 at the monitoring location 602. In some embodiments, such a camera access request can be sent from the monitoring application 632 to the monitoring service 1040, for example, in response to the monitoring agent 104 selecting an event window 106 corresponding to a particular camera 604, as described above in conjunction with Figure 1 and Figure 2In some embodiments, the user token can be a JWT, such as the following combined Figure 18 Token 1802 is described.

[0135] The monitoring service 1040 may evaluate the user token received from the monitoring application 632 (e.g., by verifying the token's signature 1808, as described below in conjunction with Figure 18 The camera streaming service 1042 may communicate with the camera streaming service 1042 to obtain an access token that the monitoring application 632 may then use to access the signaling channel of the camera streaming service 1042. Figure 13 An example process is described by which signaling information can be exchanged between the monitoring application 632 and the camera 604 via a signaling channel established by the camera streaming service 1042 to determine configuration information for a peer-to-peer connection between the monitoring application 632 and the camera 604. In some embodiments, the access token obtained from the camera streaming service 1042 can be a JWT, such as the following in conjunction with Figure 18 Token 1802 is described.

[0136] like Figure 12 , in some embodiments, the monitoring service 1040 can authenticate to the camera streaming service 1042 on behalf of the monitoring application 632 providing the user token and request access to the camera streaming service 1042 (per arrow 1202). In some embodiments, the access request sent by the monitoring service 1040 to the camera streaming service 1042 can specify one or more parameters that identify the specific monitoring location 602 in question, the specific camera(s) 604 to which access is to be granted, a specific time window during which access to such cameras 604 is to be granted, and / or any of a number of other restrictions or constraints regarding whether and / or how access to the camera(s) 604 is to be granted. Using these parameters can help ensure that the camera(s) 604 are only accessed by authorized personnel and only when needed to assess a specific event.

[0137] Upon authenticating the access request received from the monitoring service 1040, the camera streaming service 1042 may establish a signaling channel between the monitoring application 632 and the camera 604 and generate an access token (e.g., as described below in conjunction with Figure 18The monitoring application 632 may then use the access token to access the signaling channel (e.g., by making a network API call to an API endpoint of the camera streaming service 1042). In some embodiments, the monitoring service 1040 may configure the access token to include one or more parameters specified in the access request. For example, in some embodiments, such parameters may be defined in the header 1804 and / or payload 1806 of the access token (e.g., as one or more claims).

[0138] like Figure 12 , the camera streaming service 1042 can send the generated access token to the monitoring service 1040, which can then pass the access token to the monitoring application 632. In some embodiments, the camera streaming service 1042 can also send additional information along with the access token, such as the network address of the signaling channel established by the camera streaming service 1042 (e.g., a network API endpoint), thereby allowing the monitoring application 632 to make network API calls to the camera streaming service 1042 for signaling purposes. As previously described, the access token generated by the camera streaming service 1042 can be configured based on parameters included in the access request sent by the monitoring service 1040 to the camera streaming service 1042 to limit the ability of the receiving monitoring application 632 to access the established signaling channel in the manner defined by these parameters. For example, the access token generated by the camera streaming service 1042 can be set to expire after a specific period of time based on a time limit parameter included in the access request.

[0139] As shown below Figure 13 As described above, upon receiving the access token from the monitoring service 1040, the monitoring application 632 may send a Session Description Protocol (SDP) proposal to the network address of the signaling channel, and the signaling channel may forward the SDP proposal to the camera 604, thereby initiating a signaling process to establish a peer-to-peer connection between the monitoring application 632 and the identified camera 604. Finally, as also described below in conjunction with Figure 13 As stated, Figure 12 As indicated by arrows 1210 and 1212 in , upon identification of suitable interactive connection establishment (ICE) candidates, one or more peer connections may be established between the monitoring application 632 and the camera 604, thereby enabling video data to be streamed from the camera 604 to the monitoring application 632 and / or audio data to be exchanged between the monitoring application 632 and the camera 604.

[0140] A similar process can be employed to establish one or more peer-to-peer connections between a client application 634 and one or more cameras 604 at a monitored location, thereby enabling video data to be streamed from the camera(s) 604 to the client application 634 and / or audio data to be exchanged between the client application 634 and the cameras 604. Accordingly, that process will not be described further herein. However, it should be understood that the permitted scope provided in the access request sent from the client service 1038 to the camera streaming service 1042 can be different (e.g., less restrictive) than the permitted scope provided by the access request sent from the monitoring service 1040 to the camera streaming service 1042, as it may not be desirable to restrict the client's ability to live stream using the cameras in the same manner as the monitoring agent 104.

[0141] Figure 13 is a sequence diagram 1300 illustrating how signaling information (e.g., WebRTC signaling information) may be exchanged between the monitoring application 632 (or alternatively, the client application 634) and the camera 604 via the camera streaming service 1042 to establish a peer-to-peer connection between the monitoring application 632 (or alternatively, the client application 634) and the camera 604. Figure 13 The exchange of signaling information between the monitoring application 632 and the camera 604 is depicted, and the following section describes the exchange of signaling information between these two components, but it should be understood that the same process can also be used to exchange signaling information between the client application 634 and the camera 604.

[0142] As described above, in some embodiments, in response to providing a user token to the monitoring service 1040 (see Figure 12 1202 in FIG), the monitoring application 632 may have received an access token for the camera streaming service 1042 from the monitoring service 1040 (see FIG. Figure 12 1208 in the image), and such an access token can enable the monitoring application 632 to access the signaling channel established by the camera streaming service 1042, thereby allowing the monitoring application 632 to make network API calls to the camera streaming service 1042 for signaling purposes.

[0143] like Figure 13As shown, the signaling process can begin with the monitoring application 632 using the received access token to send (1302A, 1302B) an SDP offer to the camera 604 (via the camera streaming service 1042). The monitoring application 632 can create the SDP offer, for example, by calling the CreateOffer() function of the WebRTC application programming interface (API) of the browser or other WebRTC-enabled component of the monitoring device 1016. The SDP offer can include information about the type of media to be sent by the monitoring device 1016, its format, the transport protocol to be used, the Internet Protocol (IP) address and port of the monitoring device 1016, and / or other information describing the media to be transmitted and / or required by the monitoring device 1016.

[0144] Upon receiving the SDP offer from the monitoring application 632, the camera 604 may send (1304A, 1304B) an SDP answer to the monitoring application 632 via the camera streaming service 1042. The camera 604 may create the SDP answer, for example, by calling the CreateAnswer() function of the WebRTC API of the browser or other WebRTC-enabled component of the camera 604. The SDP answer may include information about the kind of media to be sent by the camera 604, its format, the transport protocol used, the Internet Protocol (IP) address and port of the camera 604, and / or other information describing the media to be transmitted and / or required by the camera 604.

[0145] In addition to sharing information about the media to be exchanged and the corresponding devices that will exchange it, the monitoring application 632 and the camera 604 can share information about the network connections they can use to exchange the media. Specifically, the monitoring application 632 can share one or more ICE candidates with the camera 604, and vice versa, where each ICE candidate is sent by a device that describes available methods that the device can use to communicate (directly or using a relay through NAT (TURN) server). The monitoring application 632 and the camera 604 can collect ICE candidates, for example, by creating an ICE candidate event listener using the WebRTC API (e.g., by calling the function peerConnection.addEventListener('icecandidate', event=>{...}).

[0146] In some implementations, the respective devices can propose their best ICE candidates first, moving them in the direction of their worse candidates. Ideally, ICE candidates use User Datagram Protocol (UDP) (because it is faster and the media stream can recover relatively easily from interruptions), but the ICE standard also allows for Transmission Control Protocol (TCP) candidates.

[0147] Possible UDP candidate types include host, peer reflexive (prflx), server reflexive (srflx), and relay. A "host" candidate is a candidate whose IP address is the actual direct IP address of the remote peer. A "peer reflexive" candidate is a candidate whose IP address comes from a symmetric network address translation (NAT) between the two peers. A "server reflexive" candidate is generated by a UDP Session Traversal of NAT (STUN) server. A relay candidate is generated by a TURN server. Possible TCP candidate types include active, passive, and so. An "active" transport will attempt to open an off-port connection, but will not receive incoming connection requests. A "passive" transport will receive incoming connection attempts, but will not attempt to connect itself. A "so" transport will attempt to open a connection to its peer simultaneously.

[0148] As an example, Figure 13 Illustrated is how monitoring application 632 may send 1306A, 1306B ICE candidate "A" to camera 604 and how camera 604 may send 1308A, 1308B ICE candidate "B" to monitoring application 632. Different pairs of identified ICE candidates may be tested, and an endpoint that has been designated as a "control agent" may select one of the identified ICE candidate pairs for establishing 1310 a peer-to-peer connection between monitoring application 632 and camera 604.

[0149] Additional information about using WebRTC to establish peer connections can be found on the webpage accessible via the Uniform Resource Locator (URL) "webrtc.org", the entire contents of which are incorporated herein by reference.

[0150] Figures 14A to 14G 1400, 1410, 1420, 1440, 1460, 1470, and 1480 are illustrated, which may be performed by one or more components of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 shown is used to monitor and maintain the state table 302 (combined with the above Figure 3 、 Figure 4A and Figure 4B to achieve certain functions described in this article. Figure 15 The example routine 1500 shown describes an example of how the monitoring service 630 can modify the contents of the state table 302 based on actions taken by the monitoring agent 104 (e.g., by interacting with the monitoring application 632 using the monitoring device 1016). Figure 16 The example routine 1600 shown describes monitoring services 630 (e.g., Figure 10The monitoring service 1040 shown is an example of the manner in which the contents of the state table 302 may be used to cause a device operated by a customer to present information in a grouped manner regarding events detected at the monitoring location 602. Each of the above-described example routines will now be described in detail.

[0151] Figure 14A An example routine 1400 is illustrated that the monitoring service 630 may execute to cause an event to be added to a lookup queue of available monitoring agents 104 based on the current contents of the state table 302 .

[0152] like Figure 14A As shown, in step 1402 of routine 1400, the monitoring service 630 can determine (e.g., by evaluating the current contents of the state table 302) that the state table 302 includes data for an event (e.g., identified by event ID 304) that has a "new" state identifier 316 and is not currently assigned to the monitoring agent 104 for review, e.g., for which the agent ID 320 is set to "unassigned."

[0153] At step 1404 of routine 1400, monitoring service 630 may determine (e.g., by evaluating the current contents of state table 302) that the event identified at step 1402 has image data 312 (e.g., a video clip) associated therewith. In some implementations, monitoring service 630 may be configured to identify events (e.g., a door lock state change) that do not have image data 630 associated therewith, and may, in at least some circumstances (e.g., in Figure 5 502) to present data about such events to the monitoring agent, but may also be configured to display data about such events, for example, by Figure 1 The video clip is presented within the event window 106 shown to initially present notifications of those events having only image data associated therewith to the monitoring agent.Step 1404 may thereby enable identification of events suitable for presentation (eg, as a video clip) within the event window 106.

[0154] At step 1406 of routine 1400, the monitoring service 630 can determine that the unassigned events identified in step 1402 have occurred less than a threshold time period in the past (e.g., within the previous thirty minutes). Step 1406 can be useful, for example, in systems where the primary focus is accident avoidance, because it can allow the monitoring service 630 to filter out data that may be too old to allow monitoring agents to take steps to intervene and stop a crime or other incident before it begins or while it is still in progress. Thus, filtering out such "old" event-related data can free up monitoring agents 104 to focus on more contemporary data that is more likely to allow them to intervene in an incident in a meaningful way.

[0155] At step 1408 of routine 1400, the monitoring service 630 may assign the event identified at step 1402 (assuming it meets the criteria determined at steps 1404 and 1406, if those steps are performed) to an available monitoring agent 104, for example, by writing the agent ID of a particular monitoring agent 104 into the row for that event. In some embodiments, once the agent ID 320 of a monitoring agent 104 has been written to the state table 302 for an event, the event may be considered to have been placed in the review queue for that monitoring agent 104. Notification of any such event may thereafter be dispatched to a monitoring device 1016 operated by that monitoring agent 104, for example, to Figure 1 The event window 106 of the screen 102 is shown.

[0156] Figure 14B An example routine 1410 is illustrated that the monitoring service 630 may execute to cause an event to be removed from the watch queue of the monitoring agent 104 based on the current contents of the state table 302 .

[0157] like Figure 14B As shown, at step 1412 of routine 1410, monitoring service 630 may determine that the state identifier 316 of the event represented in state table 302 (e.g., identified by event ID 304) has been changed to "hold." Figure 14C For example, when the monitoring agent 104 begins to review another event (e.g., by selecting Figure 1 Such a status change may occur in response to another event from the same monitoring location 602 changing its status from "new" to "review" (see one event window 106 of the screen 102 shown).

[0158] At step 1414 of routine 1410 , the monitoring service 630 may cause the event to be removed from the lookup queue of the monitoring agent 104 to which the event is currently assigned, such as by removing the agent ID 320 of the monitoring agent from the event row in the state table 302 .

[0159] Figure 14C An example routine 1420 is illustrated that is executed when the monitoring agent 104 begins actively reviewing events (e.g., by selecting Figure 1 106 of the screen 102 shown), can be monitored by one or more components of the service 630 (e.g., Figure 10The monitoring service 1040 shown in FIG. 104 is executed to identify other events that may be related to the event being reviewed and to change the status indicators 316 of these potentially related events to "held." As described elsewhere herein, marking events as "held" in this manner may remove these events from the review queues of other monitoring agents 104 and / or may prevent these events from being subsequently added to the review queues of other monitoring agents 104.

[0160] like Figure 14C As shown, routine 1420 may begin at step 1422, where monitoring service 630 may determine (e.g., by detecting a state change in the contents of state table 302) that the state indicator 316 of the event represented in state table 302 has changed to "viewing." Figure 15 As described in step 1506 of the illustrated routine 1500, such a state change may occur in response to the monitoring agent 104 beginning to actively monitor the event (e.g., by selecting Figure 1 An event window 106 of the screen 102 shown in FIG. Figure 4A In the example scenario shown, for example, when the monitoring agent 104 begins actively reviewing event "E1," the status indicator 316 of event "E1" has changed from "new" to "review."

[0161] At step 1424 of routine 1420, the monitoring service 630 can identify one or more other events reflected in the state table 302 that (A) were detected at the same monitoring location 602 as the event under review, and (B) have a "new" state indicator 316. In some implementations, the monitoring service 630 can determine that two events were detected at the same monitoring location 602 by determining that the two events have the same location ID 308 (or possibly the same camera ID 310) in the state table 302.

[0162] In some embodiments, following decision 1426 and selection step 1428, the monitoring service 630 may loop through the events identified in step 1424 (or alternatively, may evaluate these identified events in parallel) to determine, according to decision 1430, whether these identified events meet one or more additional criteria for determining whether these events may be related to the same incident as the event being reviewed. In other embodiments, the monitoring service 630 may omit decision 1430 and instead simply consider all identified events from the same monitoring location 602 to be related to the event being reviewed. When employed, decision 1430 may involve determining whether the event under consideration occurred within a time window using the timestamp 306 of the event actively reviewed by the agent 104 as the control input data. For example, in some embodiments, the monitoring service 630 may determine whether the timestamp 306 of the event under consideration indicates that the event occurred within a time window starting five minutes before and ending five minutes after the time indicated by the timestamp 306 of the event actively reviewed by the monitoring agent 104. Time windows of other measurements and / or durations may alternatively be used in conjunction with decision 1430 to optimize system performance. Further, in some embodiments, different or additional relevance criteria may be employed in conjunction with decision 1430 for optimization purposes.

[0163] When, at decision 1430, the monitoring service 630 determines that the selected event satisfies additional criteria for determining whether it may be associated with the same incident as the event under review, the routine 1420 may proceed to step 1432 where the monitoring service 630 may change the status indicator 316 in the status table 302 for the event under consideration (e.g., the event selected at step 1428) from "new" to "held." Figure 4A In the example scenario shown, for example, the status indicators 316 for events "E2" and "E4" reflected in the status table 302 have changed from "new" to "held." As previously described, marking events as "held" in this manner may cause these events to be removed from the review queues of other monitoring agents 104 and / or may prevent these events from being subsequently added to the review queues of other monitoring agents 104.

[0164] At step 1434 of routine 1420, monitoring service 630 may associate the event under consideration (e.g., the event selected at step 1428) with the event whose status indicator 316 was changed to "reviewed" (per step 1422). In some embodiments, such association may be accomplished by adding the actively reviewed event ID 304 to state table 302 as an associated event 318 for the event under consideration. Figure 4A In the example scenario shown, for example, event ID "E1" has been added as an associated event 318 for each of events "E2" and "E4". Figure 14E 、 Figure 14F and Figure 14G As described in more detail, associating "related" events to events that are actively reviewed by the monitoring agent 104 can allow these events to be treated as a group so that a revised status (e.g., "new," "cleared," or "threat") can be assigned to all of these events after the initial review by the monitoring agent 104. Further, as described below in conjunction with Figure 16 Described in more detail, associating "related" events to events that have been actively reviewed by the monitoring agent 104 can allow the events to be treated as a group when reporting the reviewed incidents to a client or when presenting notifications of the events to a client (e.g., as a timeline of incidents that each include a set of grouped events).

[0165] Figure 14D An example routine 1440 is illustrated that may be used by one or more components of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 shown executes to determine whether the status indicator 316 of a new event added to the status table 302 should be marked as "new", thereby allowing it to be assigned to an available monitoring agent 104, or marked as "held", thereby preventing it from being assigned to a monitoring agent 104.

[0166] like Figure 14D As shown, the routine 1440 can begin at step 1442 , where the monitoring service 630 can determine that a new event has been added to the state table 302 , such as by detecting a new event ID 304 added to the state table 302 .

[0167] At decision 1444, the monitoring service 630 can determine whether the state table 302 includes (A) another event detected at the same monitoring location 602 (e.g., by determining that it includes the same location ID 308 as the newly detected event), and (B) has a state indicator 316 set to "looking up," thereby determining whether the monitoring agent 104 is actively looking up another event at the same monitoring location 602 as the newly detected event.

[0168] When, at decision 1444, the monitoring service 630 determines that the monitoring agent 104 is actively reviewing another event at the same monitoring location 602 as the newly detected event, the routine 1440 may proceed to decision 1446, where the monitoring service 630 may determine whether the added event satisfies one or more additional criteria for determining whether it is likely related to the same incident as the event being reviewed. In other embodiments, the monitoring service 630 may omit decision 1446 and instead simply consider added events from the same monitoring location 602 to be related to the event being reviewed. When employed, decision 1446 may involve determining whether the added event occurred within a time window that uses the timestamp 306 of the event being actively reviewed by the agent 104 as control input data. For example, in some embodiments, the monitoring service 630 may determine whether the timestamp 306 of the added event indicates that the event occurred within a time window that begins five minutes before and ends five minutes after the time indicated by the timestamp 306 of the event being actively reviewed by the monitoring agent 104. Time windows measured in other ways and / or of other durations may alternatively be used in conjunction with decision 1446 to optimize system performance. Further, in some embodiments, different or additional correlation criteria may be employed in conjunction with decision 1446 for optimization purposes.

[0169] When, at decision 1446, the monitoring service 630 determines that the added event satisfies additional criteria for determining whether it may be related to the same incident as the event under review, the routine 1440 may proceed to step 1448, in which the monitoring service 630 may set the status indicator 316 of the added event in the status table 302 to "hold."

[0170] At step 1450 of routine 1440, monitoring service 630 may associate the newly added event with the event having the "lookup" status indicator 316. In some embodiments, this association may be performed in a similar manner as described above in connection with step 1434 of routine 1420 ( Figure 14C ) is completed by adding the event ID 304 of the actively viewed event as an associated event 318 of the newly added event.

[0171] When, at decision 1446, the monitoring service 630 determines that the added event does not meet the additional criteria for determining whether it may be related to the same incident as the event under review, the routine 1440 may proceed to step 1452, in which the monitoring service 630 may set the status indicator 316 of the newly added event to "new."

[0172] When, at decision 1444 (described above), the monitoring service 630 determines that the monitoring agent 104 is not actively consulting another event at the same location as the newly detected event, the routine 1440 may proceed to step 1452, in which the monitoring service 630 may set the status indicator 316 of the newly added event to "new."

[0173] Figure 14E 、 Figure 14F and Figure 14G Example routines 1460, 1470, and 1480 are shown, respectively, that can be executed by the monitoring service 630 to update the status indicator 316 associated with an event that has been actively viewed by the monitoring agent 104 in the state table 302 of events in response to a change in the status indicator 316 for the actively viewed event. For example, such a change to the status indicator 316 of the actively viewed event can occur in response to "state change" decisions 1514, 1518, and 1520 that the monitoring service 630 can make, as described below in conjunction with Figure 15 As stated.

[0174] like Figure 14E As shown, routine 1460 can begin at step 1462, at which step, monitoring service 630 can determine (e.g., by detecting a change in the state of status indicator 316 in state table 302) that the state of the event reflected in state table 302 has changed from "lookup" to "new."

[0175] In step 1464 of routine 1460, the monitoring service 630 can identify (e.g., by evaluating the current contents of the state table 302) one or more events in the state table 302 that (A) have a "keep" state indicator 316 and (B) are associated with an event that has undergone a state change from "lookup" to "new".

[0176] At step 1466 of routine 1460, the monitoring service 630 may change the status indicator 316 of the event identified at step 1464 from "hold" to "new."

[0177] In step 1468 of routine 1460, the monitoring service 630 may disassociate the event identified in step 1464 from the event whose status changed from "reviewed" to "new," for example, by removing the event ID of the reviewed event from the associated event field(s) of the identified event.

[0178] like Figure 14FAs shown, routine 1470 may begin at step 1472, where monitoring service 630 may determine (e.g., by detecting a change in the state of status indicator 316 in state table 302) that the state of the event reflected in state table 302 has changed from "lookup" to "cleared." For example, comparing Figure 4A and Figure 4B In the version of state table 302 shown, the state indicator 316 for event "E1" has changed from "lookup" to "clear."

[0179] In step 1474 of routine 1470, the monitoring service 630 can identify (e.g., by evaluating the current contents of the state table 302) one or more events in the state table 302 that (A) have a "keep" state indicator 316 and (B) are associated with an event that has undergone a state change from "check" to "clear."

[0180] At step 1476 of routine 1470, the monitoring service 630 may change the status indicator 316 of the event identified at step 1474 from "hold" to "clear." Figure 4B In the example scenario shown, for example, the status indicators 316 for events "E2" and "E4" have changed to "cleared."

[0181] At step 1478 of routine 1470, the monitoring service 630 may deallocate the event from the monitoring agent 104 whose active viewing state has changed from "viewing" to "cleared," e.g., by changing the agent ID field of the event to "unassigned." Figure 4B In the example scenario shown, the Agent ID field of event "E1" has been changed to "Unassigned".

[0182] like Figure 14G As shown, routine 1480 may begin at step 1482, where monitoring service 630 may determine (e.g., by detecting a change in state of status indicator 316 in state table 302) that the state of an event reflected in state table 302 has changed from "check" to "threat." Figure 4B In the version of status table 302 shown, for example, status indicator 316 for event "E3" has been changed to "Threat."

[0183] At step 1484 of routine 1480, the monitoring service 630 may identify (e.g., by evaluating the current contents of the state table 302) one or more events in the state table 302 that (A) have a "hold" state indicator 316 and (B) are associated with an event that has undergone a state change from "review" to "threat."

[0184] At step 1486 of routine 1480, the monitoring service 630 may change the status indicator 316 of the event identified at step 1484 from "hold" to "threat."

[0185] At step 1488 of routine 1480, the monitoring service 630 may deallocate the event from the monitoring agent 104 that is actively watching for the event whose status has changed from "watch" to "threat," e.g., by changing the Agent ID field of the event to "unassigned." Figure 4B In the example scenario shown, the Agent ID field for event "E3" has been changed to "Unassigned".

[0186] Figure 15 is a flow chart illustrating an example routine 1500 that may be used by one or more components of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 shown in FIG. 104 is executed to process commands received from the monitoring application 632 operated by the monitoring agent 104 (e.g., in accordance with Figure 3 (as indicated by arrow 326).

[0187] like Figure 15 As shown, the routine 1500 may begin at step 1502, where the monitoring service 630 may determine (e.g., based on an evaluation of received input) that it has received a command from the monitoring application 632 corresponding to a request by the monitoring agent 104 to proactively review events (e.g., by selecting Figure 1 An event window 106 is presented on the screen 102 shown.

[0188] At step 1504 of the routine 1500, the monitoring service 630 may cause the monitoring device 1016 associated with the monitoring application 632 to receive and present (e.g., at Figure 5 10 and / or one or more of the main viewer window 114 and / or the video feed window 112 of the screen 110 shown in the figure) from the live stream of one or more cameras 604 at the monitoring location 602. An example process for establishing a peer-to-peer connection between the monitoring application 632 and the one or more cameras 604 at the monitoring location 602 for this purpose is described above in conjunction with Figure 12 and Figure 13 Described.

[0189] At step 1506 of routine 1500, monitoring service 630 may modify the contents of state table 302 to change the state indicator 316 of the under-view event (i.e., the event for which a view request was received at step 1502) to "viewing." For example, Figure 4A In the version of state table 302 shown, monitoring service 630 has set the state indicator 316 for event "E1" to "viewing".

[0190] At step 1508 of routine 1500, monitoring service 630 may store event data (e.g., as per Figure 3 The arrow 322a) is sent to the monitoring application 632 in operation of the request monitoring agent 104. Figure 5 As mentioned, in some embodiments, such event data can be used to populate Figure 5 One or more event data windows 502 of the illustrated screen 504 , or information is otherwise presented on the screen 504 , to facilitate review of events by a monitoring agent.

[0191] At step 1510 of routine 1500, monitoring service 630 may identify (e.g., by evaluating the current contents of state table 302) event data for events that (A) have a "hold" status indicator 316 in state table 302, (B) are associated with the event under review (e.g., by listing the event ID of the event under review as associated event 318), and (C) have not yet been sent to monitoring application 632. When step 1510 is initially reached during routine 1500, such event data may include one or more events that (A) have a "hold" status indicator 316 in state table 302, (B) are associated with the event under review (e.g., by listing the event ID of the event under review as associated event 318), and (C) have not yet been sent to monitoring application 632. Figure 14C Step 1432 of the routine 1420 shown changes its state to "hold", and (B) Figure 14C Step 1434 of the illustrated routine 1420 is associated with the event being reviewed. When step 1510 is reached at a subsequent opportunity (e.g., after a "no" determination at decision 1522), such event data may include data for newly added events that are (A) Figure 14D Step 1448 of the routine 1440 shown causes its status to be marked as "hold", and (B) in accordance with Figure 14D Step 1450 of routine 1440 is shown as being associated with the event under review.

[0192] At step 1512 of routine 1500, the monitoring service 630 may send the event data identified at step 1510 to the monitoring application 632, e.g., according to Figure 3 As shown in the arrow 322a. Figure 5 As mentioned, in some embodiments, such event data of related events can also be used to populate Figure 5 One or more event data windows 502 of the illustrated screen 504 , or information is otherwise presented on the screen 504 , to facilitate review of events by a monitoring agent.

[0193] At decision 1514 of routine 1500, the monitoring service 630 may determine (e.g., based on an evaluation of the received input) whether the monitoring application 632 (e.g., according to Figure 3326) or otherwise receives a command indicating that the monitoring agent 104 has stopped reviewing events. Such a command may be generated for any of a number of reasons, such as in response to the monitoring agent 104 shutting down the monitoring application 632, in response to a loss of network connectivity between the monitoring application 632 and the monitoring service 630, in response to detecting a lack of interaction with the monitoring application 632 by the monitoring agent 104 for an excessive amount of time, in response to input provided to the monitoring application 632 by the monitoring agent 104, etc.

[0194] When the monitoring service 630 determines (e.g., based on an evaluation of the received input) at decision 1514 that a command to stop reviewing events has been received, the routine 1500 can proceed to step 1516 where the monitoring service 630 can change the state indicator 316 (in the state table 302) of the event being reviewed to "new." Figure 14E As described in the illustrated routine 1460, changing the status indicator 316 of an event under review in this manner can trigger the monitoring service 630 to also change the status indicator of any associated events to "new" and also disassociate these other events from the events that the monitoring agent 104 stopped reviewing.

[0195] Following step 1516, the routine 1500 may proceed to step 1528, where the monitoring service 630 may de-establish the live streaming video connection established at step 1504, and the routine 1500 may thereafter terminate.

[0196] When the monitoring service 630 determines (e.g., based on an evaluation of the received input) at decision 1514 that a command to stop reviewing events has not been received, the routine 1500 may instead proceed to decision 1518, where the monitoring service 630 may determine whether a command has been received from the monitoring application 632 (e.g., according to Figure 3 326) or otherwise receives a command indicating that the monitoring agent 104 has provided input to change the status indicator 316 of the event being reviewed to "clear." For example, while reviewing the event on screen 504 ( Figure 5 After presenting the live video feed(s) in the video feed window 112 (as shown) and / or the main viewer window 114 and any event data for the event under review and / or related events presented in the event data window 502 or otherwise, the monitoring agent 104 may have determined that there is no security issue with the monitoring location 602 and thereby provided input to the monitoring application 632 indicating that the event under review can be cleared.

[0197] When the monitoring service 630 determines (e.g., based on an evaluation of the received input) at decision 1518 that a command to clear the event under review has been received, the routine 1500 can proceed to step 1520 where the monitoring service 630 can change the state indicator 316 of the event under review (in the state table 302) to "clear." Figure 14F As described in the illustrated routine 1470, changing the status indicator 316 of an event under review in this manner can trigger the monitoring service 630 to also change the status indicator of any associated events to "cleared" and also deallocate the event under review from the monitoring agent 104 that cleared the event under review, thereby making room in the monitoring agent's review queue for notifications of other events.

[0198] Following step 1520, the routine 1500 may proceed to step 1528, where the monitoring service 630 may de-establish the live streaming video connection established at step 1504, and the routine 1500 may thereafter terminate.

[0199] When the monitoring service 630 determines (e.g., based on an evaluation of the received input) at decision 1518 that a command to clear the event has not been received, the routine 1500 may instead proceed to decision 1522, where the monitoring service 630 may determine whether a command has been received from the monitoring application 632 (e.g., in accordance with Figure 3 326 ) or otherwise receives a command indicating that the monitoring agent 104 has provided input to change the status indicator 316 of the event under review to “threat.”

[0200] When, at decision 1522 , the monitoring service 630 determines (eg, based on an evaluation of received input) that a command has not been received to classify the event under review as a threat, the routine 1500 can return to step 1510 (described above).

[0201] When, on the other hand, the monitoring service 630 determines (per decision 1522) that a command has been received to classify the event as a threat, the routine 1500 may proceed instead to step 1524, at which the monitoring service 630 may change the status indicator 316 (in the status table 302) of the event under review to "threat."

[0202] At step 1526 of routine 1500 , the monitoring service 630 may take any of a number of possible actions to address the identified threat at the monitoring location 602 , such as triggering an alarm at the monitoring location 602 , notifying the police, notifying a customer, and the like.

[0203] Following step 1526, the routine 1500 may proceed to step 1528, where the monitoring service 630 may de-establish the live streaming video connection established at step 1504, and the routine 1500 may thereafter terminate.

[0204] Figure 16 is a flow chart illustrating an example routine 1600 that may be used by one or more components of the monitoring service 630 (e.g., Figure 10 The monitoring service 1040 shown is executed to cause a customer-operated device to present information about events detected at the monitoring location 602 in a grouped manner, such as based on identifiers of associated events 318 added to the state table 302 in response to the monitoring agent 104 actively reviewing certain events.

[0205] like Figure 16 As shown, routine 1600 may begin at step 1602, where monitoring service 630 may determine to notify a client regarding a particular event. In some cases, for example, after monitoring agent 104 proactively reviews and categorizes an event (e.g., categorizes the event as a threat), monitoring agent 104 may provide input to monitoring application 632 requesting that an event notification be pushed to the client. In other cases, step 1602 may correspond to a client operating a smartphone or other computing device to request information about a particular event and / or notification of a recent incident detected at monitoring location 602.

[0206] At step 1604 of routine 1600, the monitoring service 630 can identify other events, if any, that are related to the event for which notification is to be provided. In some embodiments, for example, the monitoring service 630 can identify any other events reflected in the state table that include the event ID of the event for which notification is to be provided as a related event 318 entry.

[0207] At step 1606 of routine 1600, monitoring service 630 may cause the client's device (e.g., a smartphone or other computing device) to present information about a particular event and the associated events identified at step 1604. For example, where the monitoring agent requests that a notification regarding a particular event be pushed to the client, monitoring service 630 may instruct the client device to display the notification regarding the particular event and its classification, as well as information describing the associated events identified at step 1604, e.g., in an event timeline format. Where the client requests information regarding a particular event, monitoring service 630 may similarly instruct the client device to display information regarding the particular event and its classification, as well as information describing the associated events identified at step 1604, e.g., in an event timeline format. Where the client requests information regarding a recent incident detected at monitoring location 602, monitoring service 630 may instead instruct the client device to display, for example, a timeline of incidents, where one or more such incidents may comprise a set of events that have been grouped based on the associated events identified at step 1604.

[0208] Now turn Figure 17 , schematically illustrates a computing device 1700. Figure 17 As shown, computing device 1700 may include at least one processor 1702, volatile memory 1704, one or more interfaces 1706, non-volatile memory 1708, and an interconnect mechanism 1714. Non-volatile memory 1708 may include executable code 1710 and, as illustrated, may additionally include at least one data store 1712.

[0209] In some embodiments, non-volatile (non-transitory) memory 1708 may include one or more read-only memory (ROM) chips; one or more hard drives or other magnetic or optical storage media; one or more solid-state drives (SSDs), such as flash drives or other solid-state storage media; and / or one or more hybrid magnetic and SSDs. Furthermore, in some embodiments, code 1710 stored in non-volatile memory may include an operating system and one or more applications or programs configured to execute under the control of the operating system. In some embodiments, code 1710 may additionally or alternatively include specialized firmware and embedded software that is executable without relying on a commercially available operating system. Regardless of its configuration, execution of code 1710 may generate manipulated data that may be stored in data storage 1712 as one or more data structures. Data structures may have fields that are related by location within the data structure. This association may also be achieved by allocating storage for the fields in locations within the memory that convey the association between the fields. However, other mechanisms may be used to establish associations between information in fields of a data structure, including through the use of pointers, tags, or other mechanisms.

[0210] The processor 1702 of the computing device 1700 may be specifically implemented by one or more processors configured to execute one or more executable instructions, such as a computer program specified by code 1710, to control the operation of the computing device 1700. Functions, operations, or sequences of operations may be hard-coded into the circuit or soft-coded by instructions stored in a memory device (e.g., volatile memory 1704) and executed by the circuit. In some embodiments, the processor 1702 may be specifically implemented by one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), neural processing units (NPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), or multi-core processors.

[0211] Before executing code 1710, processor 1702 may copy code 1710 from non-volatile memory 1708 to volatile memory 1704. In some embodiments, volatile memory 1704 may include one or more static or dynamic random access memory (RAM) chips and / or cache memory (e.g., memory disposed on the silicon die of processor 1702). Volatile memory 1704 may provide faster response times than main memory (such as non-volatile memory 1708).

[0212] By executing code 1710, processor 1702 can control the operation of interface 1706. Interface 1706 may include a network interface. Such a network interface may include one or more physical interfaces (e.g., a radio transceiver, an Ethernet port, a USB port, etc.) and a software stack, which includes drivers and / or other code 1710, which is configured to communicate with the one or more physical interfaces to support one or more LAN, PAN and / or WAN standard communication protocols. Such communication protocols may include, for example, TCP and UDP. As can be seen, the network interface can enable computing device 1700 to access and communicate with other computing devices via a computer network.

[0213] (One or more) interfaces 1706 may include one or more user interfaces. For example, in some embodiments, (one or more) user interfaces 1706 may include user input and / or output devices (e.g., keyboard, mouse, touch screen, display, speaker, camera, accelerometer, biometric scanner, environmental sensor, etc.) and a software stack, which includes a driver and / or other code 1710, which is configured to communicate with the user input and / or output device. It can be seen that (one or more) user interfaces 1706 can enable the computing device 1700 to interact with the user to receive input and / or present output. The presented output may include, for example, one or more GUIs, which include one or more controls configured to display output and / or receive input. The received input may specify a value to be stored in a data memory 1712. The displayed output may indicate a value stored in a data memory 1712.

[0214] The various features of computing device 1700 described above can communicate with each other via an interconnect mechanism 1714. In some implementations, interconnect mechanism 1714 can include a communication bus.

[0215] Figure 18 Shown is an example token 1802, such as a JSON web token (JWT), which can be adopted by various system components as described above. As illustrated, token 1802 may include a header 1804, a payload 1806, and a signature 1808. In some embodiments, header 1804 may specify a signing technique for generating signature 1808 based on the content of header 1804 and / or payload 1806 and a private key. In some embodiments, for example, the signing technique specified may involve (A) combining a header and a payload of base64url encoding, (B) hashing the combined base64url value using a hashing technique (such as SHA256), and (C) encrypting a hash determined using a private key. Thus, by verifying signature 1808 using a private key and a specified signing technique, a recipient device can confirm that the content of a token 1802 received from another device has not been altered or otherwise compromised. In some embodiments, the header 1804 or payload 1806 of the token 1802 may additionally include an identifier of the device for which it was generated, thereby enabling a receiving device to confirm that the received token 1802 is from the same device for which the token 1802 was originally generated, thereby limiting the use of the token 1802 by other devices to which it may have been transmitted.

[0216] The following paragraphs (M1) to (M13) describe examples of methods that can be performed according to the present disclosure.

[0217] (M1) A method may include: causing a computing system to cause a first computing device to display a first notification of a first event detected at a monitoring location; causing a second computing device to display a second notification of a second event detected at the monitoring location; and causing the second computing device to stop displaying the second notification in response to a change in the state of the first event.

[0218] (M2) The method described in paragraph (M1) may be performed, wherein the first computing device may be caused to display the first notification at least in part by adding the first notification to a first queue of event notifications without also adding the first notification to a second queue of event notifications; the second computing device may be caused to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications; and the second computing device may be caused to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0219] (M3) The method described in paragraph (M1) or paragraph (M2) may be performed, and the method may also include: receiving, by the computing system, an input to review a first event; and in response to the input, causing the computing system to establish a connection between the first computing device and at least one camera at the monitoring location to receive a live video feed from the monitoring location.

[0220] (M4) The method of paragraph (M3) may be performed, and the method may further include causing the computing system to cause the first computing device to display information about the second event and a live video feed from the monitored location.

[0221] (M5) A method as described in any one of paragraphs (M1) to (M4) may be performed, and the method may further include: determining, by the computing system, that a first event is associated with a monitoring location; and determining, by the computing system, that a second event is associated with the monitoring location; wherein, the second computing device may stop displaying the second notification based further, at least in part, on the first event being associated with the monitoring location and the second event being associated with the monitoring location.

[0222] (M6) A method as described in any of paragraphs (M1) to (M5) may be performed, and the method may also include: causing the first computing device to display a first notification at least in part by sending a first video clip corresponding to the first event from the computing system to the first computing device; and causing the second computing device to display a second notification at least in part by sending a second video clip corresponding to the second event from the computing system to the second computing device.

[0223] (M7) A method as described in any one of paragraphs (M1) to (M6) may be performed, and the method may also include: after causing the second computing device to stop displaying the second notification, determining by the computing system that a third event is detected at the monitoring location; and avoiding, by the computing system, causing the second computing device to display a third notification of the third event based at least in part on a change in the state of the first event.

[0224] (M8) A method may include: determining, by a computing system, that a first computing device receives input associated with a first notification, the first notification indicating a first event detected at a location; and causing, by the computing system, a second computing device to stop displaying a second notification based at least in part on receiving the input, the second notification indicating a second event at the location that is different from the first event.

[0225] (M9) The method described in paragraph (M8) may be performed, wherein the first computing device may be caused to display the first notification at least in part by adding the first notification to a first queue of event notifications without also adding the first notification to a second queue of event notifications; the second computing device may be caused to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications; and the second computing device may be caused to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0226] (M10) The method of paragraph (M8) or paragraph (M9) may be performed, wherein the first computing device may be caused to receive a live video feed from the location based at least in part on the input.

[0227] (M11) A method as described in any one of paragraphs (M8) to (M10) may be performed, and the method may further include: determining, by the computing system, that the first event is associated with a location; and determining, by the computing system, that the second event is associated with the location; and wherein, the second computing device may stop displaying the second notification based further, at least in part, on the first event being associated with the location and the second event being associated with the location.

[0228] (M12) A method as described in any one of paragraphs (M8) to (M11) may be performed, and the method may also include: causing the first computing device to display a first notification at least in part by sending a first video clip corresponding to the first event from the computing system to the first computing device; and causing the second computing device to display a second notification at least in part by sending a second video clip corresponding to the second event from the computing system to the second computing device.

[0229] (M13) A method as described in any of paragraphs (M8) to (M12) may be performed, and the method may also include: after causing the second computing device to stop displaying the second notification, determining, by the computing system, that a third event is detected at the location; and avoiding, by the computing system, causing the second computing device to display a third notification of the third event based at least in part on receipt of the input.

[0230] The following paragraphs (S1) to (S13) describe examples of devices and / or systems that may be configured according to the present disclosure.

[0231] (S1) A system may include at least one processor and at least one computer-readable medium encoded with instructions that, when executed by the at least one processor, cause the system to: cause a first computing device to display a first notification of a first event detected at a monitoring location, cause a second computing device to display a second notification of a second event detected at the monitoring location, and cause the second computing device to cease displaying the second notification based at least in part on a determination that the first computing device is receiving a live video feed from the monitoring location.

[0232] (S2) The system as described in paragraph (S1) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, further cause the system to: cause the first computing device to display the first notification at least in part by adding the first notification to a first queue of event notifications without also adding the first notification to a second queue of event notifications, cause the second computing device to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications, and cause the second computing device to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0233] (S3) The system as described in paragraph (S1) or paragraph (S2) may be configured, wherein the at least one computer-readable medium may also be encoded with additional instructions that, when executed by the at least one processor, further cause the system to: receive input to review a first event, and in response to the input, cause the first computing device to establish a connection with at least one camera at the monitored location to receive a live video feed from the monitored location.

[0234] (S4) The system as described in paragraph (S3) may be configured, wherein the at least one computer-readable medium may also be encoded with additional instructions that, when executed by the at least one processor, further cause the system to: cause the first computing device to display information about the second event and a live video feed from the monitored location.

[0235] (S5) A system as described in any one of paragraphs (S1) to (S4) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that the first event is associated with the monitored location, determine that the second event is associated with the monitored location, and cause the second computing device to stop displaying the second notification based at least in part on the first event being associated with the monitored location and the second event being associated with the monitored location.

[0236] (S6) A system as described in any of paragraphs (S1) to (S5) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: cause the first computing device to display a first notification, at least in part, by sending a first video clip corresponding to the first event to the first computing device, and cause the second computing device to display a second notification, at least in part, by sending a second video clip corresponding to the second event to the second computing device.

[0237] (S7) A system as described in any one of paragraphs (S1) to (S6) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that a third event is detected at the monitoring location after causing the second computing device to stop displaying the second notification, and avoid causing the second computing device to display a third notification of the third event based at least in part on a change in state of the first event.

[0238] (S8) A system may include at least one processor and at least one computer-readable medium encoded with instructions that, when executed by the at least one processor, cause the system to: determine that a first computing device receives input associated with a first notification, the first notification indicating a first event detected at a location; and cause a second computing device to stop displaying a second notification based at least in part on receiving the input, the second notification indicating a second event at the location that is different from the first event.

[0239] (S9) The system described in paragraph (S8) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, further cause the system to: cause the first computing device to display the first notification at least in part by adding the first notification to a first queue of event notifications without also adding the first notification to a second queue of event notifications, cause the second computing device to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications, and cause the second computing device to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0240] (S10) The system of paragraph (S8) or paragraph (S9) may be configured, wherein the at least one computer-readable medium may also be encoded with additional instructions that, when executed by the at least one processor, further cause the system to: cause the first computing device to receive a live video feed from the location based at least in part on the input.

[0241] (S11) A system as described in any one of paragraphs (S8) to (S10) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that the first event is associated with a location, determine that the second event is associated with the location, and cause the second computing device to stop displaying the second notification based at least in part on the first event being associated with the location and the second event being associated with the location.

[0242] (S12) A system as described in any one of paragraphs (S8) to (S11) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: cause the first computing device to display a first notification, at least in part, by sending a first video clip corresponding to the first event from the computing system to the first computing device, and cause the second computing device to display a second notification, at least in part, by sending a second video clip corresponding to the second event from the computing system to the second computing device.

[0243] (S13) A system as described in any one of paragraphs (S8) to (S12) may be configured, wherein at least one computer-readable medium may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that a third event is detected at the location after causing the second computing device to stop displaying the second notification, and avoid causing the second computing device to display a third notification of the third event based at least in part on receiving the input.

[0244] The following paragraphs (CRM1) through (CRM13) describe examples of computer-readable media that can be configured according to the present disclosure.

[0245] (CRM1) At least one non-transitory computer-readable medium may be encoded with instructions that, when executed by at least one processor of the system, cause the system to: cause a first computing device to display a first notification of a first event detected at a monitoring location, cause a second computing device to display a second notification of a second event detected at the monitoring location, and cause the second computing device to cease display of the second notification in response to a change in the state of the first event.

[0246] (CRM2) can be configured with at least one non-transitory computer-readable medium as described in paragraph (CRM1), and it can also be encoded with additional instructions, which, when executed by at least one processor, further cause the system to: cause the first computing device to display the first notification at least in part by adding the first notification to the first queue of event notifications without also adding the first notification to the second queue of event notifications, cause the second computing device to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications, and cause the second computing device to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0247] (CRM3) may be configured with at least one non-transitory computer-readable medium as described in paragraph (CRM1) or paragraph (CRM2), and may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: receive input to review a first event, and in response to the input, cause the first computing device to establish a connection with at least one camera at the monitored location to receive a live video feed from the monitored location.

[0248] (CRM4) may be configured with at least one non-transitory computer-readable medium as described in paragraph (CRM3), and may also be encoded with additional instructions that, when executed by at least one processor, further cause the system to: cause the first computing device to display information about the second event and a live video feed from the monitored location.

[0249] (CRM5) can be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM1) to (CRM4), and it can also be encoded with additional instructions, which, when executed by at least one processor, cause the system to: determine that the first event is associated with the monitored location, determine that the second event is associated with the monitored location, and also cause the second computing device to stop displaying the second notification based at least in part on the first event being associated with the monitored location and the second event being associated with the monitored location.

[0250] (CRM6) may be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM1) to (CRM5), and may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: cause the first computing device to display a first notification, at least in part, by sending a first video clip corresponding to a first event to the first computing device, and cause the second computing device to display a second notification, at least in part, by sending a second video clip corresponding to a second event to the second computing device.

[0251] (CRM7) can be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM1) to (CRM6), and it can also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that a third event is detected at the monitoring location after causing the second computing device to stop displaying the second notification, and avoid causing the second computing device to display a third notification of the third event based at least in part on the change in state of the first event.

[0252] (CRM8) At least one non-transitory computer-readable medium may be encoded with instructions that, when executed by at least one processor of the system, cause the system to: determine that a first computing device receives input associated with a first notification, the first notification indicating a first event detected at a location; and cause a second computing device to cease displaying a second notification based at least in part on receiving the input, the second notification indicating a second event at the location that is different from the first event.

[0253] (CRM9) can be configured with at least one non-transitory computer-readable medium as described in paragraph (CRM8), and it can also be encoded with additional instructions, which, when executed by at least one processor, further cause the system to: cause the first computing device to display the first notification at least in part by adding the first notification to the first queue of event notifications without also adding the first notification to the second queue of event notifications, cause the second computing device to display the second notification at least in part by adding the second notification to the second queue of event notifications without also adding the second notification to the first queue of event notifications, and cause the second computing device to stop displaying the second notification at least in part by removing the second notification from the second queue of event notifications.

[0254] (CRM10) may be configured with at least one non-transitory computer-readable medium as described in paragraph (CRM8) or paragraph (CRM9), and may also be encoded with additional instructions that, when executed by at least one processor, further cause the system to: cause the first computing device to receive a live video feed from the location based at least in part on the input.

[0255] (CRM11) can be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM8) to (CRM10), and it can also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that the first event is associated with the location, determine that the second event is associated with the location, and also cause the second computing device to stop displaying the second notification based at least in part on the first event being associated with the location and the second event being associated with the location.

[0256] (CRM12) may be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM8) to (CRM11), and may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: cause the first computing device to display a first notification, at least in part, by sending a first video clip corresponding to the first event from the computing system to the first computing device, and cause the second computing device to display a second notification, at least in part, by sending a second video clip corresponding to the second event from the computing system to the second computing device.

[0257] (CRM13) may be configured with at least one non-transitory computer-readable medium as described in any of paragraphs (CRM8) to (CRM12), and may also be encoded with additional instructions that, when executed by at least one processor, cause the system to: determine that a third event is detected at the location after causing the second computing device to stop displaying the second notification, and avoid causing the second computing device to display a third notification of the third event based at least in part on receiving the input.

[0258] Various inventive concepts can be embodied as one or more methods, examples of which have been provided. The actions performed as part of a method can be ordered in any suitable manner. Thus, examples can be constructed in which actions are performed in an order different from that illustrated, which can include performing some actions simultaneously, even though shown as sequential actions in illustrative examples.

[0259] The use of ordinal terms such as "first," "second," "third," etc. in the claims to modify claim elements does not, by itself, imply any priority, precedence, or sequence of one claim element with respect to another, or a temporal order in which the acts of the method are performed. These terms serve merely as labels to distinguish one claim element having a particular name from another element having the same name (but using an ordinal term).

[0260] The examples of the methods and systems discussed herein are not limited in their application to the details of construction and arrangement of the components set forth in the following description or illustrated in the accompanying drawings. The methods and systems can be implemented in other examples and can be practiced or executed in various ways. The examples of specific embodiments provided herein are for illustrative purposes only and are not intended to be limiting. In particular, the actions, components, elements, and features discussed in conjunction with any one or more examples are not intended to be excluded from similar roles in any other examples.

[0261] Furthermore, the phraseology and terminology used herein are for descriptive purposes and should not be considered limiting. Any reference to an example, component, element, or action of a system or method mentioned herein in the singular may also include examples that include the plural, and any reference to any example, component, element, or action mentioned herein in the plural may also include examples that include only the singular. References in the singular or plural are not intended to limit the systems or methods of the present disclosure, their components, actions, or elements.

[0262] The use of "including," "comprising," "having," "containing," "involving," and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. References to "or" may be construed as inclusive, such that any term described using "or" may refer to any one, more than one, and all of the described terms. Additionally, in the event of inconsistent usage of a term between this document and documents incorporated by reference, the usage of the term in the incorporated reference supplements that of this document; for irreconcilable inconsistencies, the usage of the term in this document controls.

[0263] Having described several examples in detail, those skilled in the art will readily appreciate various modifications and improvements. These modifications and improvements are intended to be within the scope of this disclosure. Therefore, the foregoing description is intended to be illustrative only and not restrictive.

Claims

1. A method for managing the distribution of event notifications to computing devices, comprising: adding, by the computing system, a first notification and a second notification to a first queue and a second queue, respectively, the first notification indicating a first event that is different from a second event indicated by the second notification; causing, by the computing system and based on the first content of the first queue, the first computing device to display the first notification without displaying the second notification; causing, by the computing system and based on second content of the second queue, the second computing device to display the second notification without displaying the first notification; receiving, by the computing system, an indication that the first computing device is being used to review events at a monitoring location; determining, by the computing system, that the second event is associated with the monitored location; as well as In response to the indication and based at least in part on the second event being associated with the monitored location, the computing system causes the second computing device to cease displaying the second notification.

2. The method according to claim 1, wherein Causing the second computing device to stop displaying the second notification also includes removing the second notification from a second queue.

3. The method according to claim 1, further comprising: In response to the indication, the computing system causes the first computing device to establish a connection with at least one camera at a monitoring location to receive a live video feed from the monitoring location.

4. The method according to claim 3, further comprising: The first computing device is caused, by the computing system, to display information about the second event along with the live video feed from the monitoring location.

5. The method according to claim 1, further comprising: determining, by the computing system, that both the first event and the second event are associated with the monitored location; Wherein, causing the second computing device to cease displaying the second notification is further based at least in part on the first event and the second event being associated with the monitored location.

6. The method according to claim 1, wherein causing the first computing device to display the first notification further comprises sending, from the computing system to the first computing device, a first video clip corresponding to the first event; as well as Causing the second computing device to display the second notification also includes sending a second video clip corresponding to the second event from the computing system to the second computing device.

7. The method according to claim 1, further comprising: After causing the second computing device to cease displaying the second notification, determining, by the computing system, that a third event is detected at the monitored location; as well as Adding a third notification of the third event to the second queue is refrained from by the computing system and based at least in part on the indication and the third event having been detected at the monitoring location, thereby causing the second computing device to not display the third notification.

8. A system for managing the distribution of event notifications to computing devices, comprising: at least one processor; and at least one computer-readable medium encoded with instructions that, when executed by the at least one processor, cause the system to: adding a first notification and a second notification to a first queue and a second queue respectively, the first notification indicating a first event that is different from a second event indicated by the second notification; causing the first computing device to display the first notification without displaying the second notification based on the first content of the first queue; causing the second computing device to display the second notification without displaying the first notification based on the second content of the second queue; receiving an indication that the first computing device is being used to review events at a monitoring location; determining that the second event is associated with the monitored location; as well as In response to the indication and based at least in part on the second event being associated with the monitored location, causing the second computing device to cease displaying the second notification.

9. The system according to claim 8, wherein: The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: The second computing device is caused to cease displaying the second notification at least in part by removing the second notification from a second queue.

10. The system according to claim 8, wherein: The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: In response to the indication, the first computing device is caused to establish a connection with at least one camera at a monitoring location to receive a live video feed from the monitoring location.

11. The system according to claim 10, wherein: The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: The first computing device is caused to display information about the second event along with the live video feed from the monitoring location.

12. The system according to claim 8, wherein: The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: determining that both the first event and the second event are associated with a monitored location; The second computing device is also caused to cease displaying the second notification based at least in part on the first event and the second event being associated with the monitored location.

13. The system according to claim 8, wherein: The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: causing the first computing device to display the first notification at least in part by sending a first video clip corresponding to the first event to the first computing device; as well as The second notification is caused to be displayed by the second computing device at least in part by sending a second video clip corresponding to the second event to the second computing device.

14. The system according to claim 8, wherein The at least one computer-readable medium is further encoded with additional instructions that, when executed by the at least one processor, further cause the system to: after causing the second computing device to cease displaying the second notification, determining that a third event is detected at the monitoring location; as well as Based at least in part on the indication and the third event having been detected at the monitoring location, refraining from adding a third notification of the third event to the second queue, thereby causing the second computing device to not display the third notification.

15. A method for managing the distribution of event notifications to computing devices, comprising: adding, by the computing system, a first notification and a second notification to a first queue and a second queue, respectively, the first notification indicating a first event that is different from a second event indicated by the second notification; causing, by the computing system and based on the first content of the first queue, the first computing device to display a first notification; causing, by the computing system and based on the second content of the second queue, the second computing device to display a second notification; determining, by the computing system, that the first computing device received input associated with the first notification; determining, by a computing system, that the first event and the second event are both associated with a location; as well as Based at least in part on receiving the input and both the first event and the second event being associated with the location, the computing system causes the second computing device to cease displaying the second notification.

16. The method according to claim 15, wherein Causing the second computing device to stop displaying the second notification also includes removing the second notification from a second queue.

17. The method according to claim 15, further comprising: Based at least in part on the input, the first computing device is caused to receive a live video feed from a location where the first event was detected.

18. The method according to claim 15, wherein causing the first computing device to display the first notification further comprises sending, from the computing system to the first computing device, a first video clip corresponding to the first event; as well as Causing the second computing device to display the second notification also includes sending a second video clip corresponding to the second event from the computing system to the second computing device.

19. The method according to claim 15, further comprising: After causing the second computing device to cease displaying the second notification, determining, by the computing system, that a third event is detected at the location; as well as Adding a third notification of the third event to the second queue is refrained from by the computing system and based at least in part on receiving the input and the third event having been detected at the location, thereby causing the second computing device to not display the third notification.

Images