Communication session with autonomous security device provisioning

Abstract

A method is provided. The method includes receiving, by a first device from a second device, a request to participate in a session, the request being a message conforming to a WebRTC framework and including an identifier of a process hosted by the second device; validating, by the first device, a type of the process hosted by the second device based on the identifier; initiating, by the first device, one or more actions on the first device in response to validation of the type of the process, the actions being different from an action to communicate data between the first device and the second device; and establishing, by the first device, the session with the second device after initialization of the action on the first device.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Patent Application 18 / 338,761 (filed June 21, 2023), which claims the benefit of U.S. Provisional Patent Application 63 / 482,137 (filed January 30, 2023), both of which are hereby incorporated by reference in their entireties. TECHNICAL FIELD

[0003] Aspects of the technology described herein relate to security systems and methods. BACKGROUND

[0004] Some monitoring systems use one or more cameras to capture images of an area surrounding or within a residential or commercial premises. Such monitoring systems can process the images locally and transmit the captured images to a remote service. If motion is detected, the monitoring system can send an alert to one or more user devices. SUMMARY

[0005] In at least one example, a method is provided. The method includes receiving, by a first device from a second device, a request to participate in a session, the request being a message conforming to a WebRTC framework and including an identifier of a process hosted by the second device; verifying, by the first device based on the identifier, a type of the process hosted by the second device; responsive to the verification of the type of the process, initiating, by the first device, one or more actions on the first device, the action being different from an action of communicating data between the first device and the second device; and establishing, by the first device, the session with the second device after the initiation of the action on the first device.

[0006] Examples of the method can incorporate one or more of the following features.

[0007] In the method, one or more actions can configure the first device for the session, and can include actions defined outside of a WebRTC framework. In the method, initiating the one or more actions can include initiating a process that controls a user interface of the first device to output an indication of a type of the process, initiating a process that records the session, or initiating a process that aborts the session. The process that controls the user interface can control a light emitting diode to illuminate in a color or pattern associated with the type of the process. The process that records the session can determine that the process is a monitor interface. The process that aborts the session can determine that the process is a monitor interface, and can determine that an event associated with the session is cancelled. Receiving, by the first device, the request that includes the identifier of the process can include receiving, by a location-based device, an identifier of a client interface or a monitor interface. Receiving the identifier of the client interface or the monitor interface can include receiving, by an image capture device, the identifier of the client interface or the monitor interface. Receiving the identifier of the client interface or the monitor interface can include receiving an identifier that specifies the type of the process, a timestamp, and an identifier of the first device. The method can further include determining an actual identifier of the first device, and comparing the identifier of the first device to the actual identifier of the first device as part of a process to validate the identifier of the process. The method can further include encoding, by the process, the identifier to specify the type of the process, a timestamp, and the identifier of the first device. In the method, establishing the session can include establishing a session that conforms to the WebRTC framework.

[0008] In another example, a first device is provided. The first device includes a memory, a network interface, and at least one processor coupled to the memory and the network interface. The at least one processor is configured to receive, via the network interface from a second device, a request to participate in a session, the request including a message that conforms to a WebRTC framework and including an identifier of a process hosted by the second device, to authenticate, based on the identifier, a type of the process hosted by the second device, to initiate, in response to the authentication of the type of the process, one or more actions that are different from actions to communicate data between the first device and the second device, and to establish the session with the second device after the initiation of the actions on the first device.

[0009] Examples of the first device can incorporate one or more of the following features.

[0010] In the first device, the one or more actions can configure the first device for the session, and can include actions that are not specified within a WebRTC framework or natively supported by a WebRTC framework. In the first device, initiating the one or more actions can include initiating a process that controls a user interface of the first device to output an indication of a type of the process, initiating a process that records the session, or initiating a process that selectively aborts the session. Controlling the user interface can include controlling a light emitting diode to illuminate in a color or pattern associated with the type of the process. Recording the session can include determining that the process is a monitor interface. Selectively aborting the session can include determining that the process is a monitor interface and determining that an event associated with the session is cancelled. The first device can be a location-based device. Receiving the request that includes the identifier of the process can include receiving an identifier of a client interface or a monitor interface. The location-based device can include a camera. Receiving the identifier of the client interface or the monitor interface can include receiving the identifier of the client interface or the monitor interface. Receiving the identifier of the client interface or the monitor interface can include receiving an identifier that specifies the type of the process, a timestamp, and an identifier of the first device. The at least one processor can be further configured to determine an actual identifier of the first device, and compare the identifier of the first device to the actual identifier of the first device as part of a process to validate the identifier of the process. The at least one processor can be further configured to decode the identifier to determine the type of the process, a timestamp, and the identifier of the first device. In the first device, establishing the session can include establishing a session that conforms to the WebRTC framework.

[0011] In another example, a security system is provided. The security system includes a first device hosting a first process configured to: receive an identifier of a second process requesting to participate in a real-time communication session with the first process; determine a type of the second process based on the identifier; configure the first device for the real-time communication session based on the type of the second process, where configuring includes initiating one or more processes on the first device, or setting one or more operational parameters of the first device other than communication session parameters; and establish the real-time communication session with the second process after the configuration of the first device.

[0012] Examples of the security system can incorporate one or more of the following features.

[0013] In a security system, initiating the one or more processes can include: initiating a process that controls a user interface of the first device to output an indication of the type of the second process; initiating a process that records the real-time communication session; or initiating a process that aborts the real-time communication session. Initiating the process that controls the user interface can include initiating a process that controls a light emitting diode to illuminate in a color or pattern associated with the type of the second process. Initiating the process that records the real-time communication session can include determining that the type of the second process is a monitor interface. Initiating the process that aborts the real-time communication session can include determining that the type of the second process is a monitor interface and determining that an event associated with the real-time communication session is cancelled. Receiving the identifier of the second process can include receiving an identifier of a client interface or a monitor interface by a first process hosted by a location-based device. Receiving the identifier of the client interface or the monitor interface can include receiving the identifier of the client interface or the monitor interface by a camera agent hosted on an image capture device. Receiving the identifier of the client interface or the monitor interface can include receiving an identifier that specifies the type of the second process, a timestamp, and an identifier of the first device. The first process can be further configured to determine an actual identifier of the first device and compare the identifier of the first device to the actual identifier of the first device as part of a process to validate the identifier of the second process. The security system can further include a second device that hosts the second process. The second process can be further configured to encode the identifier to specify the type of the second process, a timestamp, and the identifier of the first device.

[0014] In another example, a method is provided. The method includes: receiving, by a first device from a second device, a request to participate in a session, the request including an indication that a user is accessing the second device and the session is configured such that input received by the first device from the user is made available for output via the second device less than 600 milliseconds after being received; identifying, by the first device based on the indication, a type of the user; responsive to identifying the type of the user, initiating, by the first device on the first device, one or more actions that are different from actions used to communicate data between the first device and second device; and establishing, by the first device, the session with the second device after initiation of the one or more actions on the first device.

[0015] Examples of the method can incorporate one or more of the following features.

[0016] In the method, the indication of the user includes an identifier of a process hosted by the second device, where identifying the type of the user includes identifying a type of the process. Initiating the one or more actions can include: initiating a process that controls a user interface of the first device to output an indication of the type of the process; initiating a process that records the session; or initiating a process that aborts the session. The process that controls the user interface can control a light emitting diode to illuminate in a color or pattern associated with the type of the process. The process that records the session can determine that the type of the user is a monitoring professional. The indication of the user includes an identifier of a process hosted by the second device. The process that records the session can determine that the type of the user is a monitoring professional by determining, based on the identifier, that the process hosted by the second device is a monitor interface. The process that aborts the session can determine that the process hosted by the second device is a monitor interface; and can determine that an event associated with the session is cancelled. Receiving, by a first device, the request including the indication of the user can include receiving, by a location-based device, an indication of a client or a monitoring professional. Receiving the indication of a client or a monitoring professional can include receiving, by an image capture device, the indication of a client or a monitoring professional. Receiving the indication of a client or a monitoring professional can include receiving an identifier that specifies a type of a process hosted by the second device, a timestamp, and an identifier of the first device. The method can further include determining an actual identifier of the first device, and comparing the identifier of the first device to the actual identifier of the first device as part of a process to validate the indication of the user. The method can further include encoding, by the process, an indication that specifies the type of the user, a timestamp, and the identifier of the first device.

[0017] In another example, a method is provided. The method includes receiving, by a first device that includes an active alert, a request from a second device that a remote intervention is being prepared, the first device participating with the second device within a session established via a WebRTC framework; in response to receiving the request, muting, by the first device, the active alert; transmitting, by the first device to the second device, a response that specifies that the active alert was successfully muted; receiving, by the first device from the second device via the session, audio content; and outputting, by the first device, the audio content.

[0018] Examples of the method can incorporate one or more of the following features.

[0019] The method can further include transmitting, by the first device, a message to at least one other device located at the same location as the first device, the message specifying a request to lower a volume of a siren controlled by the at least one other device. The method can further include transmitting, by the at least one other device, a message to one or more other devices located at the same location as the at least one other device, the message requesting a lowering of a volume of a siren controlled by the one or more other devices. In the method, receiving the request that remote intervention is being prepared can include receiving the request via a data channel of the session. The method can further include outputting a first prompt prior to outputting the audio content. The method can further include outputting a second prompt after outputting the audio content. The method can further include resuming the active siren after outputting the second prompt. The method can further include transmitting, by the first device, a message to at least one other device located at the same location as the first device, the message specifying a request to resume a volume of a siren controlled by the at least one other device. The method can further include transmitting, by the at least one other device, a message to one or more other devices located at the same location as the at least one other device, the message requesting a resumption of a volume of a siren controlled by the one or more other devices. The method can further include rendering, by a user interface of the second device, an indication that the active siren was successfully muted.

[0020] In another example, a security system is provided. The security system includes a first device that participates with a second device within a session established via a WebRTC framework and includes an active siren. The first device is configured to: receive, from the second device, a request that remote intervention is being prepared; in response to receiving the request, mute the active siren; transmit a response to the second device, the response specifying that the active siren was successfully muted; receive, from the second device via the session, one or more messages specifying audio content; and output the audio content.

[0021] Examples of the security system can incorporate one or more of the following features.

[0022] In the system, the first device can be further configured to transmit a message to at least one other device located at the same location as the first device, the message specifying a request to lower a volume of an alarm controlled by the at least one other device. The system can further include the at least one other device. The at least one other device can be configured to transmit one or more messages to one or more other devices located at the same location as the at least one other device, the one or more messages specifying one or more requests to lower one or more volumes of one or more alarms controlled by the one or more other devices. In the system, receiving the request that remote intervention is ready to proceed can include receiving the request via a data channel of the session. The first device can be further configured to output a first prompt prior to the audio content. The first device can be further configured to output a second prompt after the audio content. The first device can be further configured to resume an active alarm after output of the second prompt. The first device can be further configured to transmit a message to at least one other device located at the same location as the first device, the message specifying a request to resume a volume of an alarm controlled by the at least one other device. The system can further include the at least one other device. The at least one other device can be configured to transmit one or more messages to one or more other devices located at the same location as the at least one other device, the one or more messages specifying one or more requests to resume one or more volumes of one or more alarms controlled by the one or more other devices. The system can further include the second device. The second device can be configured to render, by a user interface, an indication that an active alarm was successfully silenced. BRIEF DESCRIPTION OF DRAWINGS

[0023] Additional examples of the present disclosure, along with its features and advantages, will become apparent to those of ordinary skill in the art through consideration of the following description, taken in conjunction with the accompanying drawings. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the present disclosure.

[0024] Figure 1 is a schematic diagram of a security system in accordance with some examples described herein.

[0025] Figure 2 is a schematic diagram of a base station in accordance with some examples described herein.

[0026] Figure 3 is a schematic diagram of a keypad in accordance with some examples described herein.

[0027] Figure 4A is a schematic diagram of a security sensor in accordance with some examples described herein.

[0028] Figure 4B is a schematic diagram of a security sensor in accordance with some examples described herein.

[0029] Figure 5 is a schematic diagram of a data center environment, a monitoring center environment, and a client device according to some examples described herein.

[0030] Figure 6 is a sequence diagram of a monitoring process according to some examples described herein.

[0031] Figure 7 is a schematic diagram of processes involved in establishing and conducting a communication session with autonomous security device preparation according to some examples described herein.

[0032] Figures 8A-8D is a sequence diagram of processes establishing and conducting a communication session supporting remote intervention and including autonomous security device preparation according to some examples described herein.

[0033] Figure 9 is a flowchart of a process autonomously preparing a security device for a communication session with a particular type of requestor according to some examples disclosed herein.

[0034] Figure 10 is a flowchart of a session requestor indication process that can be executed during autonomous preparation of a security device for a communication session with a particular type of requestor according to some examples disclosed herein.

[0035] Figure 11 is a flowchart of a session monitoring process that can be executed during autonomous preparation of a security device for a communication session with a particular type of requestor according to some examples disclosed herein.

[0036] Figure 12 is a flowchart of a session logging process that can be executed during autonomous preparation of a security device for a communication session with a particular type of requestor according to some examples disclosed herein.

[0037] Figure 13 is a schematic diagram of a computing device according to some examples described herein. DETAILED DESCRIPTION

[0038] As summarized above, at least some examples disclosed herein relate to systems and processes that establish a communication session between one or more security devices located at a monitored location and a computing device located remotely from the monitored location. These sessions enable a remotely located user (e.g., a monitoring professional or a client of a security service) to intervene at the monitored location when a reportable event, such as a break-in, occurs. The intervention can include, for example, interacting with one or more security devices at the monitored location to adjust their operation, and / or interacting with a person at the monitored location. Such remote intervention can quickly clear false alarms, or in some cases, deter, prevent, or delay theft or other types of harm. Moreover, by allowing a remotely located user to view, listen to, and possibly interact with a person at the monitored location, remote intervention supported by the communication session can help the remotely located user determine whether to authorize dispatch of emergency services and / or law enforcement personnel to the monitored location. In some examples, the communication sessions described herein enable real-time communication between a person at the monitored location and a remotely located user. For example, in particular examples, the communication sessions enable the person at the monitored location and the remotely located user to have a conversation with minimal perceptible delay (e.g., a delay of less than 600 milliseconds).

[0039] However, there are some concerns with implementing remote intervention and the communication sessions that underlie them. For example, the environment within which remote intervention occurs can be chaotic. For example, where a reportable event has been detected by one or more security devices at the monitored location, an alarm can be active and emitting a high volume of sound. Moreover, if multiple alarms or other security devices capable of emitting sound are installed at the monitored location, such sound can come from multiple sources. If the individual at the monitored location is a client of a security service or another person with permission to enter the monitored location, this environment can be distracting and even disconcerting. If the individual at the monitored location is an intruder, this environment can be expected, but it can still be distracting to the intruder, or cause the intruder to focus on the target of the break-in rather than potential interactions with others. Regardless, some environments within which remote intervention can occur are not conducive to interaction between a remotely located user and an individual at the monitored location.

[0040] There are also concerns regarding customer privacy and resource protection related to establishing and maintaining communication sessions that support remote intervention. Some customers may seek documented administrative controls and other assurances that security devices within their property are not used for purposes other than providing security services. Privacy concerns are particularly pronounced when the security devices involved in remote intervention reside in the customer's home. Furthermore, establishing and maintaining communication sessions consumes power and network resources at the monitored location due to increased use of processors, cameras, speakers, microphones, and (in the case of security devices with wireless network connectivity) radios. Power usage concerns are particularly prominent if any of the security devices at the monitored location are battery powered.

[0041] To address the concerns described above, as well as others, the systems and processes described herein autonomously prepare security devices for effective and controlled remote interventions and the communication sessions that support them. This autonomous preparation may include an initiation procedure that attracts the attention of an individual within the monitored location by adjusting the security device installed at the location and its output. In some examples, the output from the security device is rendered by one or more user interfaces incorporated into the security device. Adjustments may include, for example, muting and / or reducing the volume of an activity alarm at the monitored location to minimize distraction. Device outputs used to attract an individual's attention may include visual indicators and audio cues. Autonomous preparation may further include initiating procedures for monitoring, recording, and restricting remote interventions to be released to the customer so that actions taken during the remote intervention are performed with complete transparency. In some examples, autonomous preparation begins before the communication session (e.g., a real-time communication session) that forms the basis of the remote intervention is established. Therefore, in at least some examples, the benefits of the autonomous preparation described herein are realized very early within the remote intervention (e.g., before the remote user even has access to the security device at the monitored location).

[0042] While this article describes various examples, it will be apparent to those skilled in the art that many more examples and implementations are possible. Therefore, the examples described herein are not the only possible examples and implementations. Furthermore, the advantages described above are not necessarily the only advantages, and it is not necessarily expected that all described advantages will be achieved through every example.

[0043] To facilitate understanding of the principles of this disclosure, reference will now be made to the examples shown in the accompanying drawings, and these examples will be described using specific language. However, it should be understood that this is not intended to limit the scope of the examples described herein.

[0044] Figure 1 This is a schematic diagram of a security system 100 configured to monitor different geographical locations, based on some examples. For example...Figure 1 As shown, system 100 includes a monitored location 102A, a monitoring center environment 120, a data center environment 124, one or more client devices 122, and a communication network 118. Each of monitored location 102A, monitoring center 120, data center 124, one or more client devices 122, and communication network 118 includes one or more computing devices (e.g., as described below with reference to Figure 13 described). One or more client devices 122 are configured to host one or more client interface applications 132. Monitoring center environment 120 is configured to host one or more monitor interface applications 130. Data center environment 124 is configured to host a supervisory service 128 and one or more transport services 126. Location 102A includes image capture devices 104 and 110, a touch sensor assembly 106, a keypad 108, a motion sensor assembly 112, a base station 114, and a router 116. Base station 114 hosts a supervisory client 136. Image capture device 110 hosts a camera agent 138. Security devices (e.g., devices 104, 106, 108, 110, 112, and 114) disposed at location 102A can be referred to herein as location-based devices.

[0045] In some examples, router 116 is a wireless router configured to communicate with location-based devices via communications compliant with a communications standard, such as any of the various Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards. As Figure 1 As shown, router 116 is also configured to communicate with network 118. It should be noted that router 116 is implemented within and near location 102A to enable a local area network (LAN) by way of example only. Other networking technologies involving other computing devices are suitable for use at location 102A. For example, in some examples, base station 114 can receive and forward communication packets emitted by image capture device 110 via a point-to-point personal area network (PAN) protocol, such as Bluetooth. Other wired, wireless, and mesh network technologies and topologies will be apparent to benefit from the present disclosure and are intended to fall within the scope of the examples disclosed herein.

[0046] Continuing Figure 1In examples, network 118 can include one or more public and / or private networks that support, for example, IP. Network 118 can include, for example, one or more LANs, one or more PANs, and / or one or more wide area networks (WANs). A LAN can include a wired or wireless network that supports various LAN standards, such as versions of IEEE 802.11, etc. A PAN can include a wired or wireless network that supports various PAN standards, such as Bluetooth, ZIGBEE, etc. A WAN can include a wired or wireless network that supports various WAN standards, such as a code division multiple access (CDMA) radio standard, a global system for mobile communications (GSM) radio standard, etc. Network 118 connects computing devices within location 102A, monitoring center environment 120, data center environment 124, and customer device 122, and enables data communication therebetween. In at least some examples, both monitoring center environment 120 and data center environment 124 include network equipment (e.g., similar to router 116) configured to communicate with network 118, as well as computing devices co-located with or in proximity to the network equipment. It should be noted that, in some examples, network 118 and existing networks within location 102A support other communication protocols, such as MQTT or other IoT protocols.

[0047] Continuing Figure 1 In examples, data center environment 124 can include physical space, communication, cooling, and power infrastructure to support networked operation of computing devices. For example, the infrastructure can include rack space to mount computing devices, uninterruptible power supplies, cooling rooms and equipment, and network equipment. Data center environment 124 can be dedicated to security system 100, can be non-dedicated, a commercially available cloud computing service (e.g., MICROSOFT AZURE, AMAZON WEB SERVICES, GOOGLE CLOUD, etc.), or can include a hybrid configuration composed of dedicated and non-dedicated resources. Regardless of its physical or logical configuration, as shown, data center environment 124 is configured to host supervisory service 128 and transport service 126. Figure 1

[0048] Continuing Figure 1 In examples, monitoring center environment 120 can include multiple computing devices (e.g., desktop computers) and network equipment (e.g., one or more routers) connected to the computing devices and network 118. Customer device 122 can include a personal computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.) and network equipment (e.g., a router, a cellular modem, a cellular radio, etc.). As shown, monitoring center environment 120 is configured to host monitor interface 130, while customer device 122 is configured to host customer interface 132. Figure 1 ​​

[0049] continue Figure 1 For example, devices 104, 106, 110, and 112 are configured to acquire analog signals via sensors incorporated in the device, generate digital sensor data based on the acquired signals, and transmit the sensor data (e.g., via a wireless link with router 116) to base station 114. The type of sensor data generated and transmitted by these devices varies depending on the type of sensors included in the device. For example, image capture devices 104 and 110 may acquire ambient light, generate image data frames based on the acquired light, and transmit these frames to base station 114, monitor interface 130, and / or client interface 132, but the pixel resolution and frame rate may vary depending on the device capabilities. Figure 1 As shown, image capture device 104 has a field of view (FOV) starting near the front door of location 102A and can acquire images of the sidewalk, the highway, and the space between location 102A and the highway. Image capture device 110 has an FOV starting near the bathroom of location 102A and can acquire images of the living room and dining room of location 102A. Image capture device 110 can further acquire images of outdoor areas outside location 102A through windows 117A and 117B on the right side of location 102A.

[0050] Furthermore, such as Figure 1 As shown, in some examples, image capture device 110 is configured to communicate separately with supervision service 128, monitor interface 130, and client interface 132 via execution and supervision client 136 of camera agent 138. These communications may include sensor data generated by image capture device 110 and / or commands executed by image capture device 110 sent by supervision service 128, monitor interface 130, and / or client interface 132. These commands may include, for example, requests for interactive communication sessions in which monitoring personnel and / or clients may interact with image capture device 110 via monitor interface 130 and client interface 132. These interactions may include requests for image capture device 110 to transmit additional sensor data and / or requests for image capture device 110 via user interface (e.g., ...). Figure 4B The user interface 412) requests the rendering output. This output may include audio and / or video output.

[0051] continue Figure 1For the example of contact sensor assembly 106, the contact sensor assembly 106 includes a sensor that can detect the presence or absence 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 106 generates Boolean sensor data specifying a closed state. When the magnetic field is not present, the contact sensor assembly 106 generates Boolean sensor data specifying an open state. In either case, the contact sensor assembly 106 can transmit sensor data to base station 114 indicating whether the front door of location 102A is open or closed. Motion sensor assembly 112 can include an audio-emitting device that can radiate sound waves (e.g., ultrasonic sound waves) and an audio sensor that can acquire reflections of the waves. When the audio sensor detects a reflection, motion sensor assembly 112 generates Boolean sensor data specifying a still state because there are no objects in motion within the space monitored by the audio sensor. When the audio sensor does not detect a reflection, motion sensor assembly 112 generates Boolean sensor data specifying an alert state because there are objects in motion within the space being monitored. In either case, motion sensor assembly 112 can transmit sensor data to base station 114. It should be noted that the particular sensing modalities described above are not limiting to the present disclosure. For example, as one of many potential examples, motion sensor assembly 112 can base its operation on acquisition of changes in temperature rather than acquisition of changes in reflected sound waves.

[0052] Continuing Figure 1 For the example of keypad 108, the keypad 108 is configured to interact with a user and to interoperate with other location-based devices in response to the interaction with the user. For example, in some examples, the keypad 108 is configured to receive input from a user specifying one or more commands and to transmit the specified commands to one or more addressed processes. These addressed processes can include processes implemented by one or more of the location-based devices and / or one or more of the monitor interfaces 130 or the supervisory service 128. These commands can include, for example, a code authenticating the user as an occupant of location 102A and / or a code requesting activation or deactivation of one or more of the location-based devices. Alternatively or additionally, in some examples, the keypad 108 includes a user interface (e.g., a tactile interface such as a set of physical buttons or a set of virtual buttons on a touch screen) configured to interact with a user (e.g., to receive input from the user and / or to render output to the user). Still further, in some examples, the keypad 108 can receive and respond to transmitted commands and render the response as visual or audio output via the user interface.

[0053] Continuing Figure 1In the example of base station 114, the base station 114 is configured to interoperate with other location-based devices to provide local command and control and store-and-forward functionality via execution of a supervisor client 136. In some examples, to implement the store-and-forward functionality, the base station 114 receives sensor data through execution of the supervisor client 136, packages the data for transmission, and stores the packaged sensor data in local memory for subsequent communication. Such communication of the packaged sensor data can include, for example, transmitting the packaged sensor data as a payload of a message to one or more transport services 126 when a communication link to the transport services 126 via the network 118 is functioning properly. In some examples, the packaged sensor data can include filtered sensor data and / or one or more summaries (maximum value, minimum value, average value, change in value since a previous communication thereof, etc.) of a plurality of sensor readings. To implement the local command and control functionality, the base station 114 performs various programmed operations in response to various events under control of the supervisor client 136. Examples of these events can include receiving a command from the keypad 108 or the client interface application 132, receiving a command from the monitor interface 130 or the client interface application 132 via the network 118, or detecting the occurrence of a scheduled event. Programmed operations performed by the base station 114 under control of the supervisor client 136 can include activating or deactivating one or more of the devices 104, 106, 108, 110, and 112, sounding an alarm, reporting an event to the supervisor service 128, and communicating location data to one or more of the transport services 126, to name a few operations. The location data can include data specifying sensor readings (sensor data), configuration data of any of the location-based devices, commands received from user input and commands (e.g., via the keypad 108 or the client interface 132), or data derived from one or more of these data types (e.g., filtered sensor data, summaries of sensor data, event data specifying events detected at the location via sensor data, etc.).

[0054] Continuing Figure 1 In the example of the transport services 126, the transport services 126 are configured to securely, reliably, and efficiently exchange messages between processes implemented by the location-based devices and processes implemented by other devices in the system 100. These other devices can include the client devices 122, devices disposed in the data center environment 124, and / or devices disposed in the monitoring center environment 120. In some examples, the transport services 126 are also configured to parse messages from the location-based devices to extract payloads included therein and store the payloads and / or data derived from the payloads in one or more data stores hosted in the data center environment 124. The data housed in these data stores can be subsequently accessed by, for example, the supervisor service 128, the monitor interface 130, and the client interface 132.

[0055] In particular examples, the transport service 126 exposes and implements one or more application programming interfaces (APIs) configured to receive, process, and respond to invocations from processes (e.g., supervisory client 136) implemented by base stations (e.g., base station 114) and / or processes (e.g., camera agent 138) implemented by other devices (e.g., image capture device 110). Individual instances of the transport service within the transport service 126 can be associated with and specific to particular manufacturers and models of location-based monitoring equipment (e.g., SIMPLISAFE equipment, RING equipment, etc.). The APIs can be implemented using a variety of architectural styles and interoperability standards. For example, in one example, the APIs are web service interfaces implemented using a representational state transfer (REST) architectural style. In this example, the API invocations are encoded using hypertext transfer protocol (HTTP) along with JavaScript Object Notation (JSON) and / or extensible markup language (XML). These API invocations are addressed to one or more uniform resource locators (URLs) that are API endpoints monitored by the transport service 126. In some examples, portions of the HTTP communications are encrypted to improve security. Alternatively or additionally, in some examples, the APIs are implemented as MQTT brokers that receive messages and emit responsive messages to MQTT clients hosted by the base stations and / or other devices. Alternatively or additionally, in some examples, the APIs are implemented using simple file transfer protocol commands. Thus, the transport service 126 is not limited to a particular protocol or architectural style. It should be noted that, in at least some examples, the transport service 126 can emit one or more API invocations to a location-based device to request data from the location-based device or to conduct an interactive communication session with it. Reference is made to Figures 7-12 One example of the transport service 126 including processes that implement communication sessions between location-based devices and devices located remote from the location 102A is further described.

[0056] Continuing Figure 1In examples, the supervisory service 128 is configured to control the overall logical setup and operation of the system 100. Thus, the supervisory service 128 can interoperate with the transport service 126, the monitor interface 130, the customer interface 132, and any of the location-based devices. In some examples, the supervisory service 128 is configured to monitor data from various sources for reportable events (e.g., break-in events) and, upon detecting a reportable event, notify one or more of the monitor interface 130 and / or the customer interface 132. In some examples, the supervisory service 128 is also configured to maintain state information regarding the location 102A. For example, the state information can indicate whether the location 102A is secure or threatened. In particular examples, the supervisory service 128 is configured to change the state information to indicate that the location 102A is secure only upon receiving a communication that indicates an explicit event (e.g., rather than making such a change in response to interrupting receipt of a break-in event). This feature can prevent "bump and rob" successful execution. Additional example processes that the supervisory service 128 is configured to perform are described below with reference to Figure 5 and Figure 6 In examples, the supervisory service 128 is configured to control the overall logical setup and operation of the system 100. Thus, the supervisory service 128 can interoperate with the transport service 126, the monitor interface 130, the customer interface 132, and any of the location-based devices. In some examples, the supervisory service 128 is configured to monitor data from various sources for reportable events (e.g., break-in events) and, upon detecting a reportable event, notify one or more of the monitor interface 130 and / or the customer interface 132. In some examples, the supervisory service 128 is also configured to maintain state information regarding the location 102A. For example, the state information can indicate whether the location 102A is secure or threatened. In particular examples, the supervisory service 128 is configured to change the state information to indicate that the location 102A is secure only upon receiving a communication that indicates an explicit event (e.g., rather than making such a change in response to interrupting receipt of a break-in event). This feature can prevent "bump and rob" successful execution. Additional example processes that the supervisory service 128 is configured to perform are described below with reference to

[0057] Continuing Figure 1 In examples, the personal monitor interface 130 is configured to control the interaction of a computing device with a monitor and to perform various programmed operations in response to these interactions. For example, in some examples, the monitor interface 130 controls its host device to provide information to the monitor regarding reportable events detected at a monitored location, such as the location 102A. Such events can include, for example, movement or alarm conditions generated by one or more of the location-based devices. Alternatively or additionally, in some examples, the monitor interface 130 controls its host device to interact with the user to configure features of the system 100. Additional example processes that the monitor interface 130 is configured to perform are described below with reference to Figure 6 In examples, the personal monitor interface 130 is configured to control the interaction of a computing device with a monitor and to perform various programmed operations in response to these interactions. For example, in some examples, the monitor interface 130 controls its host device to provide information to the monitor regarding reportable events detected at a monitored location, such as the location 102A. Such events can include, for example, movement or alarm conditions generated by one or more of the location-based devices. Alternatively or additionally, in some examples, the monitor interface 130 controls its host device to interact with the user to configure features of the system 100. Additional example processes that the monitor interface 130 is configured to perform are described below with reference to

[0058] Continuing Figure 1 In examples, the personal customer interface 132 is configured to control the interaction of a computing device with a customer and to perform various programmed operations in response to these interactions. For example, in some examples, the customer interface 132 controls its host device to provide information to the customer regarding reportable events detected at a monitored location, such as the location 102A. Such events can include, for example, alarm conditions generated by one or more of the location-based devices. Alternatively or additionally, in some examples, the customer interface 132 is configured to process input received from the customer to activate or deactivate one or more of the location-based devices. Still further, in some examples, the customer interface 132 configures features of the system 100 in response to input from the user. Additional example processes that the customer interface 132 is configured to perform are described below with reference toFigure 6 Another example process that the customer interface 132 is configured to perform is described.

[0059] Turning now to Figure 2 , an example base station 114 is schematically illustrated. As Figure 2 shown, the base station 114 includes at least one processor 200, volatile memory 202, non-volatile memory 206, at least one network interface 204, a user interface 212, a battery component 214, and an interconnection mechanism 216. The non-volatile memory 206 stores executable code 208 and includes a data store 210. In Figure 2 some examples, the above-listed features of the base station 114 are incorporated within or as part of a housing 218.

[0060] In some examples, the non-volatile (non-transitory) memory 206 includes 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 SSD. In a particular example, the code 208 stored in the non-volatile memory can include an operating system as well as one or more application programs or procedures configured to execute under the operating system. Alternatively or additionally, the code 208 can include special-purpose firmware and embedded software that can be executed without reliance on a commercially available operating system. Regardless, execution of the code 208 can implement the supervisory client 136 of Figure 1 and can produce manipulated data as part of the data store 210.

[0061] Continuing Figure 2In examples of the base station 114, the processor 200 can include one or more programmable processors to execute one or more executable instructions (such as a computer program specified by the code 208) to control operation of the base station 114. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations can be hard coded into the circuitry, or soft coded by way of instructions held in a memory device (e.g., the volatile memory 202) and executed by the circuitry. In some examples, the processor 200 is a digital processor, but the processor 200 can be an analog processor, a digital processor, or a hybrid processor. Thus, the processor 200 can perform a function, operation, or sequence of operations using digital values and / or using analog signals. In some examples, the processor 200 can be embodied in 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. Examples of multi-core processors 200 can provide functionality for parallel, simultaneous execution of instructions, or for parallel, simultaneous execution of one instruction over more than one piece of data.

[0062] Continuing Figure 2 In examples of the base station 114, prior to executing the code 208, the processor 200 can copy the code 208 from the non-volatile memory 206 to the volatile memory 202. In some examples, the volatile memory 202 includes one or more static or dynamic random access memory (RAM) chips and / or cache memory (e.g., memory provided on a silicon die of the processor 200). The volatile memory 202 can provide faster response times than the primary memory, such as the non-volatile memory 206.

[0063] By executing the code 208, the processor 200 can control operation of the network interface 204. For example, in some examples, the network interface 204 includes one or more physical interfaces (e.g., radios, Ethernet ports, universal serial bus (USB) ports, etc.) and a software stack including drivers and / or other code 208 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. The communication protocols can include, for example, transmission control protocol (TCP), user datagram protocol (UDP), HTTP, and MQTT, among others. Thus, the network interface 204 enables the base station 114 to communicate via computer networks (e.g., by the router 116, Figure 1 of the base station 114, Figure 1The network interface 204 can access other computing devices (e.g., location-based devices) and communicate with other computing devices, e.g., over a network 118 and / or a LAN established by a point-to-point connection. For example, in at least one example, the network interface 204 utilizes sub-GHz wireless networking to transmit a wake-up message to other computing devices to request a sensor data stream or other operation. Using sub-GHz wireless networking can improve operable communication distances and / or reduce power consumed to digest communications.

[0064] The processor 200, by executing the code 208, can control operation of the user interface 212. For example, in some examples, the user interface 212 includes user input and / or output devices (e.g., a keyboard, a mouse, a touchscreen, a display, a speaker, a camera, an accelerometer, a biometric scanner, an environmental sensor, etc.) and a software stack including drivers and / or other code 208 configured to communicate with the user input and / or output devices. For example, the user interface 212 can be implemented by the customer device 122 hosting the mobile application (e.g., the customer interface 132). The user interface 212 enables the base station 114 to interact with a user to receive input and / or render output. The rendered output can include, for example, one or more graphical user interfaces (GUIs) including one or more controls configured to display output and / or receive input. The input can specify values to be stored in the data storage 210. The output can indicate values stored in the data storage 210. It should be noted that, in some examples, portions of the user interface 212 can be part of or accessible through and / or visible by the housing 218. These portions of the user interface 212 can include, for example, one or more light-emitting diodes (LEDs). Alternatively or additionally, in some examples, the user interface 212 includes a 95db siren that the processor 200 sounds to indicate that a break-in event has been detected.

[0065] Continuing Figure 2In some examples, the interconnection mechanism 216 includes a communication bus. Further to that, in some examples, the battery assembly 214 is configured to supply operating power to the various features of the base station 114 described above. In some examples, the battery assembly 214 includes at least one rechargeable battery (e.g., one or more NiMH or lithium batteries). In some examples, the rechargeable battery has a run capacity sufficient to operate the base station 114 for 24 hours or more in the event that the base station 114 is disconnected from or otherwise does not receive line power. Alternatively or additionally, in some examples, the battery assembly 214 includes a power supply circuit to receive, condition, and distribute line power to operate both the base station 114 and to recharge the rechargeable battery. The power supply circuit can include, for example, a transformer and a rectifier, among other circuits, to convert AC line power to DC device and recharging power.

[0066] Turning now to Figure 3 , an example keypad 108 is schematically illustrated. As Figure 3 shown, the keypad 108 includes at least one processor 300, volatile memory 302, non-volatile memory 306, at least one network interface 304, a user interface 312, a battery assembly 314, and an interconnection mechanism 316. The non-volatile memory 306 stores executable code 308 and data storage 310. In some examples, illustrated by Figure 3 , the features of the keypad 108 listed above are incorporated within or as part of a housing 318.

[0067] In some examples, the respective descriptions of the processor 200, volatile memory 202, non-volatile memory 206, interconnection mechanism 216, and battery assembly 214 with reference to the base station 114 apply to the respective descriptions of the processor 300, volatile memory 302, non-volatile memory 306, interconnection mechanism 316, and battery assembly 314 with reference to the keypad 108. Accordingly, those descriptions will not be repeated.

[0068] Continuing Figure 3For example, by executing code 308, processor 300 can control the operation of network interface 304. In some examples, network interface 304 includes one or more physical interfaces (e.g., radio, Ethernet port, USB port, etc.) and a software stack including drivers and / or other code 308, which is configured to communicate with one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. These communication protocols may include, for example, TCP, UDP, HTTP, and MQTT. Therefore, network interface 304 enables keypad 108 to access and communicate with other computing devices (e.g., other location-based devices) via a computer network (e.g., a LAN established by router 116 and / or point-to-point connections).

[0069] continue Figure 3 For example, by executing code 308, processor 300 can control the operation of user interface 312. In some examples, user interface 312 includes user input and / or output devices (e.g., physical keys arranged as a keypad, touchscreen, display, speaker, camera, biometric scanner, environmental sensor, etc.) and a software stack including drivers and / or other code 308 configured to communicate with the user input and / or output devices. Therefore, user interface 312 enables keypad 108 to interact with the user to receive input and / or render output. The rendered output may include, for example, one or more GUIs including one or more controls configured to display output and / or receive input. Input may specify a value to be stored in data storage device 310. Output may indicate a value stored in data storage device 310. It should be noted that in some examples, components of user interface 312 (e.g., one or more LEDs) may be part of or accessible through a housing 318.

[0070] Now go to Figure 4A The example safety sensor 422 is illustrated schematically. Specific configurations of the safety sensor 422 (e.g., image capture devices 104 and 110, motion sensor assembly 112, and contact sensor assembly 106) are shown in... Figure 1 This is shown in the text and described above. For example... Figure 4A As shown, the safety sensor 422 includes at least one processor 400, volatile memory 402, non-volatile memory 406, at least one network interface 404, a battery assembly 414, an interconnection mechanism 416, and at least one sensor assembly 420. The non-volatile memory 406 stores executable code 408 and a data storage device 410. Some examples include a user interface 412. Figure 4AIn the particular example shown, the features of the safety sensor 422 listed above are incorporated within or as part of the housing 418.

[0071] In some examples, the respective descriptions of the processor 200, the volatile memory 202, the non-volatile memory 206, the interconnect mechanism 216, and the battery component 214 with reference to the base station 114 apply to the respective descriptions of the processor 400, the volatile memory 402, the non-volatile memory 406, the interconnect mechanism 416, and the battery component 414 with reference to the safety sensor 422. Accordingly, those descriptions will not be repeated.

[0072] Continuing Figure 4A In the example, by executing the code 408, the processor 400 can control the operation of the network interface 404. In some examples, the network interface 404 includes one or more physical interfaces (e.g., radios (including antennas), Ethernet ports, USB ports, etc.) and a software stack including drivers and / or other code 408 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. The communication protocols can include, for example, TCP, UDP, HTTP, and MQTT, among others. Thus, the network interface 404 enables the safety sensor 422 to access and communicate with other computing devices (e.g., other location-based devices) via a computer network (e.g., a LAN established by the router 116 and / or a point-to-point connection). For example, in at least one example, when executing the code 408, the processor 400 controls the network interface to stream sensor data acquired from the sensor component 420 (e.g., via UDP) to the base station 114. Alternatively or additionally, in at least one example, by executing the code 408, the processor 400 can control the network interface 404 to enter a power saving mode by turning off a 2.4 GHz radio and turning on a sub- GHz radio, both of which are included in the network interface 404. In this example, by executing the code 408, the processor 400 can control the network interface 404 to enter a streaming or interactive mode by turning on the 2.4 GHz radio and turning off the sub-GHz radio, for example, in response to receiving a wake-up signal from the base station via the sub-GHz radio.

[0073] Continuing Figure 4AFor example, by executing code 408, processor 400 can control the operation of user interface 412. In some examples, user interface 412 includes user input and / or output devices (e.g., physical buttons, touchscreens, displays, speakers, cameras, accelerometers, biometric scanners, environmental sensors, one or more LEDs, etc.) and a software stack containing drivers and / or other code 408, which is configured to communicate with the user input and / or output devices. Therefore, user interface 412 enables security sensor 422 to interact with the user to receive input and / or render output. The rendered output may include, for example, one or more GUIs including one or more controls configured to display output and / or receive input. Input may specify a value to be stored in data storage device 410. Output may indicate a value stored in data storage device 410. It should be noted that in some examples, components of user interface 412 may be part of or accessible through housing 418.

[0074] continue Figure 4A For example, sensor component 420 may include one or more types of sensors, such as those mentioned above. Figure 1 The sensor 420 may be one of the sensors described in image capture devices 104 and 110, motion sensor assembly 112, and contact sensor assembly 106, or other types of sensors. For example, in at least one example, sensor assembly 420 includes an image sensor (e.g., a charge-coupled device or an active pixel sensor) and a temperature or thermal imaging sensor (e.g., an active and / or passive infrared (PIR) sensor). Regardless of the type of sensor housed or what kind of sensor it is, processor 400 may (e.g., via execution code 408) acquire sensor data from the housed sensor and stream the acquired sensor data to processor 400 for transmission to a base station.

[0075] It should be noted that in some examples of devices 108 and 422, the operations performed by processors 300 and 400 under the control of the corresponding controls of codes 308 and 408 can be hard-decoded and / or implemented in hardware, rather than as a combination of hardware and software. Furthermore, the execution of code 408 can achieve... Figure 1 The camera agent 138 can generate manipulated data as part of the data storage device 410.

[0076] Now go to Figure 4B The illustration schematically shows an example image capture device 500. Specific configurations of image capture devices 500 (e.g., image capture devices 104 and 110) are shown in... Figure 1 This is shown in the text and described above. For example... Figure 4BAs shown, the image capture device 500 includes at least one processor 400, volatile memory 402, non-volatile memory 406, at least one network interface 404, a battery component 414, and an interconnection mechanism 416. These features of the image capture device are shown in dashed lines to indicate that they reside within a housing 418. The non-volatile memory 406 stores executable code 408 and a data store 410.

[0077] Some examples further include an image sensor assembly 450, a light source 452, a speaker 454, a microphone 456, a wall mount 458, and a magnet 460. The image sensor assembly 450 can include a lens and an image sensor. The light source 452 can include a light emitting diode (LED), such as a red-green-blue light emitting LED. In some examples, the light source 452 can also include an infrared light emitting diode. The speaker 454 can include a transducer configured to emit sound in a range of 60 dB to 80 dB or higher volume. Further, in some examples, the speaker 454 can include a siren configured to emit sound in a range of 70 dB to 90 db or higher volume. The microphone 456 can include a microelectromechanical system (MEMS) microphone. The wall mount 458 can include a mounting bracket configured to accept screws or other fasteners that attach the bracket to a wall, and a cover configured to mechanically couple to the mounting bracket. In some examples, the cover is made of a magnetic material, such as aluminum or stainless steel, to enable the magnet 460 to magnetically couple to the wall mount 458, thereby holding the image capture device 500 in place.

[0078] In some examples, the descriptions of the processor 400, the volatile memory 402, the network interface 404, the non-volatile memory 406, the code 408 with respect to the network interface 404, the interconnection mechanism 416, and the battery component 414 with respect to the security sensor 422 apply with respect to these same features of the image capture device 500. Accordingly, those descriptions will not be repeated here.

[0079] Continuing Figure 4B In some examples, by executing the code 408, the processor 400 can control the operation of the image sensor assembly 450, the light source 452, the speaker 454, and the microphone 456. For example, in at least one example, when executing the code 408, the processor 400 controls the image sensor assembly 450 to acquire, via the network interface 404, an image to be streamed to a base station 114 (or Figure 1The sensor data (in the form of image data) of one of processes 130, 128, or 132. Alternatively or additionally, in at least one example, by executing code 408, processor 400 controls light source 452 to emit light, such that image sensor assembly 450 collects sufficient reflected light to synthesize image data. Further, in some examples, by executing code 408, processor 400 controls speaker 454 to emit sound. This sound may be locally generated (e.g., a sound alarm via an siren) or received from base station 114 (or via network interface 404). Figure 1 The process 130, 128, or 132 is used for streaming (e.g., speech from a user or monitoring person). Furthermore, in some examples, by executing code 408, processor 400 controls microphone 456 to acquire sensor data in the form of sound for streaming to base station 114 via network interface 404. Figure 1 (One of processes 130, 128, or 132).

[0080] It should be understood that, Figure 4B In the example, light source 452, speaker 454, and microphone 456 are implemented Figure 4A An instance of user interface 412. It should also be understood that the image sensor component 450 and the light source 452 implement... Figure 4A An example of sensor component 420. Therefore, Figure 4B The image capture device 500 shown is Figure 4A At least one example of the safety sensor 422 shown.

[0081] Now go to Figure 5 It schematically demonstrates Figure 1 Data center environment 124 Figure 1 The monitoring center environment 120 Figure 1 One of the customer devices in customer device 122, Figure 1 Network 118 and Figure 1 Various aspects of the multiple monitored locations 102A to 102N (collectively referred to as location 102). For example... Figure 5 As shown, data center environment 124 hosts monitoring services 128 and transmission services 126 (referred to as transmission services 126A to 126D, respectively). Monitoring service 128 includes location data storage device 502, sensor data storage device 504, artificial intelligence (AI) service 508, event listening service 510, and identity provider 512. Monitoring center environment 120 includes computing devices 518A to 518M (collectively referred to as computing devices 518) hosting monitor interfaces 130A to 130M. Each location 102A to 102N includes base stations (e.g., hosting monitoring clients 136A to 136N (collectively referred to as monitoring clients 136)) hosting monitoring clients (e.g., monitoring clients 136A to 136D).Figure 1 of the base station 114 (not shown), and an image capture device (e.g., a camera) hosting a software camera agent 138A-138N (collectively, camera agents 138). Figure 1 of the image capture device 110 (not shown).

[0082] As shown in Figure 5 transmission service 126 is configured to process incoming messages 516B from the client interface 132A, the supervisor client 136, the camera agents 138, and / or the monitor interface 130. The transmission service 126 is also configured to process outgoing messages 516A addressed to the client interface 132A, the supervisor client 136, the camera agents 138, and the monitor interface 130. The location data store 502 is configured to store location data within a plurality of records in association with an identifier of a client for which the location is monitored. For example, the location data can be stored in a record having an identifier of the client and / or an identifier of the location to associate the location data with the client and the location. The sensor data store 504 is configured to store sensor data (e.g., one or more frames of image data) within a plurality of records in association with an identifier of a location at which the sensor data was acquired and a timestamp.

[0083] Continuing with the example of Figure 5 the AI service 508 is configured to process sensor data (e.g., images and / or image sequences) to identify movement, faces, and other features within the sensor data. The event listening service 510 is configured to scan location data transmitted via the incoming messages 516B for events and, if an event is identified, execute one or more event handlers to process the event. In some examples, the event handlers can include an event reporter configured to identify reportable events and configured to communicate a message specifying the reportable event to one or more receiver processes (e.g., the client interface 132 and / or the monitor interface 130). In some examples, the event listening service 510 can interoperate with the AI service 508 to identify events within the sensor data. The identity provider 512 is configured to receive authentication requests including security credentials from the supervisor client 136 or the camera agents 138 via the transmission service 126. When the identity provider 512 can authenticate the security credentials in the request (e.g., via a verification function, cross-reference lookup, or some other identity authentication process), the identity provider 512 can communicate a security token in response to the request. The supervisor client 136 or the camera agents 138 can receive, store, and include the security token in subsequent incoming messages 516B so that the transmission service 126A can securely process (e.g., unpack / parse) the packets included in the incoming messages 516B to extract the location data before passing the location data to the supervision service 128.

[0084] Continuing Figure 5 of the examples, prior to passing the location data to the oversight service 128 for processing, the transport service 126 is configured to receive the incoming message 516B, validate the authenticity of the message 516B, parse the message 516B, and extract the location data encoded therein. The location data can include any of the location data described above with reference to Figure 1 The various transport services 126 can be configured to process incoming messages 516B generated by location-based monitoring equipment of particular manufacturers and / or models. The oversight client 136 and camera agent 138 are configured to generate the incoming message 516B, and transmit it to the oversight service 128 via the network 118, the incoming message including a packet of location data based on sensor information received at the location 102.

[0085] Continuing Figure 5 of the examples, the computing device 518 is configured to host the monitor interface 130. In some examples, the various monitor interfaces 130A-130M are configured to render a GUI including one or more image frames and / or other sensor data. In particular examples, the client device 122 is configured to host the client interface 132. In some examples, the client interface 132 is configured to render a GUI including one or more image frames and / or other sensor data. Additional features of the monitor interface 130 and the client interface 132 are further described below with reference to Figure 6

[0086] Turning now to Figure 6 , the monitoring process 600 is illustrated as a sequence diagram. In some examples, the process 600 can be performed by a security system (e.g., the security system 100 of Figure 1 More specifically, in some examples, at least a portion of the process 600 is performed by a location-based device under control of device control system (DCS) code (e.g., the code 308 or 408) implemented by at least one processor (e.g., any of the processors 300 or 400 of Figure 3 or FIG. 4). The DCS code can include, for example, a camera agent (e.g., the camera agent 138 of Figure 1 At least a portion of the process 600 is performed by a base station (e.g., the base station 114 of Figure 1 under control of an oversight client (e.g., the oversight client 136 of Figure 1 At least a portion of the process 600 is performed by a monitoring center environment (e.g., the monitoring center environment 120 of Figure 1 under control of a monitor interface (e.g., the monitor interface 130 of Figure 1 At least a portion of the process 600 is performed by a data center environment (e.g., the data center environment 124 of Figure 1 ​The data center environment 124) in the monitoring service (e.g., Figure 1 Under the control of the supervisory service 128) or the transport service (e.g., Figure 1 The process 600 is executed under the control of the transmission service 126. At least a portion of the process 600 is controlled by the client device (e.g., Figure 1 Client equipment 122) at the client interface (e.g., Figure 1 Executed under the control of the client interface 132).

[0087] like Figure 6 As shown, process 600 begins with the monitoring client 136 exchanging one or more authentication requests and responses 604 with the transport service 126 to the identity provider (e.g., Figure 5 The identity provider 512 performs authentication. More specifically, in some examples, the supervisory client 136 transmits an authentication request to the transport service 126 via one or more API calls to the transport service 126. In these examples, the transport service 126 parses the authentication request to extract security credentials and passes the security credentials to the identity provider for authentication. In some examples, if the identity provider authenticates the security credentials, the transport service 126 generates a security token and transmits that security token as the payload within the authentication response to the authentication request. In these examples, if the identity provider cannot authenticate the security credentials, the transport service 126 generates an error code and transmits that error code as the payload within the authentication response to the authentication request. When an authentication response is received, the supervisory client 136 parses the authentication response to extract the payload. If the payload includes an error code, the supervisory client 136 may retry authentication and / or its user interface with the host device (e.g., ...). Figure 2 The monitoring client 136 interoperates with the user interface 212 of base station 114 to render output indicating authentication failure. If the payload includes a security token, the monitoring client 136 stores the security token for subsequent use in communications via location data from incoming messages. It should be noted that the security token may have a limited validity period (e.g., 1 hour, 1 day, 1 week, 1 month, etc.), after which the monitoring client 136 may need to re-authenticate with the transport service 126.

[0088] Continuing process 600, one or more DCS 602 hosted by one or more location-based devices obtain the location described in 606 (e.g., Figure 1 Sensor data at location 102A. The acquired sensor data can be of any type, as referenced above. Figure 1discussed in relation to FIG. 4. In some examples, one or more of the DCSs 602 continuously acquire sensor data. In some examples, one or more of the DCSs 602 acquire sensor data in response to an event, such as a local timer expiring (a push event) or receiving an acquire poll signal transmitted by the supervisory client 136 (a poll event). In particular examples, one or more of the DCSs 602 stream sensor data to the supervisory client 136 with minimal processing beyond acquisition and digitization. In these examples, the sensor data can constitute a sequence of vectors, where individual vector members include a sensor reading and a timestamp. Alternatively or additionally, in some examples, one or more of the DCSs 602 perform additional processing of the sensor data, such as generating one or more summaries of multiple sensor readings. Still further, in some examples, one or more of the DCSs 602 perform complex processing of the sensor data. For example, if a security sensor includes an image capture device, the security sensor can perform image processing routines, such as edge detection, motion detection, facial recognition, threat assessment, and reportable event generation.

[0089] Continuing with the process 600, the DCSs 602 transmit the sensor data 608 to the supervisory client 136. As with sensor data acquisition, the DCSs 602 can transmit the sensor data 608 continuously or in response to an event, such as a push event (originating from the DCSs 602) or a poll event (originating from the supervisory client 136).

[0090] Continuing process 600, supervisory client 136 monitors 610 the location by processing received sensor data 608. For example, in some examples, supervisory client 136 executes one or more image processing routines. These image processing routines can include any of the image processing routines described above with reference to operation 606. By distributing at least some of the image processing routines between DCS 602 and supervisory client 136, some examples reduce power consumed by the battery-powered device through offloading processing to the line-powered device. Further, in some examples, supervisory client 136 can execute an integrated threat detection process that utilizes sensor data 608 from multiple different DCSs 602 as input. For example, in at least one example, supervisory client 136 will attempt to corroborate an open state received from a contact sensor with motion and facial recognition processing that includes images of the scene that includes the window to which the contact sensor is attached. If two or more of the three processes indicate the presence of an intruder, a threat score is increased, or a break-in event is declared, locally logged, and communicated. Other processing that supervisory client 136 can perform includes outputting local alerts (e.g., in response to detecting particular events and / or satisfying other criteria) and detecting maintenance conditions for the location-based device, such as the need to replace or recharge a low power battery and / or replace / maintain the device hosting DCS 602. Any of the processes described above within operation 610 can result in the creation of location data specifying the results of those processes.

[0091] Continuing process 600, supervisory client 136 communicates location data 614 to supervisory service 128 via one or more incoming messages 612 to transmission service 126. As with the communication of sensor data 608, supervisory client 136 can communicate location data 614 continuously or in response to an event, such as a push event (originating from supervisory client 136) or a polling event (originating from supervisory service 128).

[0092] Continuing with process 600, supervisory service 128 processes 616 the received location data. For example, in some examples, supervisory service 128 executes one or more routines described above with reference to operations 606 and / or 610. Additionally or alternatively, in some examples, supervisory service 128 uses historical information associated with the location identified in the location data and / or other locations geographically close to that location (e.g., within the same Zone Improvement Plan (ZIP) code) to calculate a threat score or further refine an existing threat score. For example, in some examples, if multiple break-ins have been recorded for that location and / or other locations within the same ZIP code within a configurable time span including the current time, supervisory service 128 can increase the threat score calculated by DCS 602 and / or supervisory client 136. In some examples, supervisory service 128 determines whether location data 614 includes any reportable events by applying a set of rules and criteria to location data 614, and if so, transmits event reports 618A and / or 618B to monitor interface 130 and / or customer interface 132. The reportable events can be a particular type of event (e.g., break-ins), or a particular type of event that meets additional criteria (e.g., movement within a particular zone combined with a threat score that exceeds a threshold). Event reports 618A and / or 618B can have a priority based on the same criteria used to determine whether the events reported therein are reportable, or can have a priority based on a different set of criteria or rules.

[0093] Continuing with process 600, monitor interface 130 interacts 620 with a monitoring personnel through, for example, one or more GUIs. These GUIs can provide details and context regarding one or more reportable events.

[0094] Continuing with process 600, customer interface 132 interacts 622 with at least one customer through, for example, one or more GUIs. These GUIs can provide details and context regarding one or more reportable events.

[0095] Note that the processing of sensor data and / or location data, as described above with reference to operations 606, 610, and 616, can be performed by processors disposed within various pieces of system 100. For example, in some examples, DCS 602 performs minimal processing of sensor data (e.g., just fetching and streaming), while the remainder of the processing described above is performed by supervisory client 136 and / or supervisory service 128. This approach can help to extend battery run-time of location-based devices. In other examples, DCS 602 performs as much sensor data processing as possible, leaving supervisory client 136 and supervisory service 128 to perform only processes that require sensor data across location-based devices and / or locations. This approach can help to increase the scalability of system 100 with respect to adding new locations.

[0096] Turning now to Figure 7 , a set of processes 700 involved in establishing and conducting communication sessions (e.g., real-time communication sessions) that autonomously provision security devices for interactive communication sessions is illustrated in a schematic diagram. As Figure 7 shown, the set of processes 700 includes transport services 126, which are described above with reference to Figure 1 , Figure 5 and Figure 6 . As Figure 7 further shown, transport services 126 include a signaling server 702, one or more Session Traversal Utilities for Network Address Translators (STUN) servers 704, and one or more Traversal Using Relays around Network Address Translators (TURN) servers 706. The set of processes 700 further includes a session requester 708 and a session receiver 710. Requester 708 can be one of the monitor interfaces 130 or one of the client interfaces 132 described above with reference to Figure 1 , Figure 5 and Figure 6 . Receiver 710 can be supervisory client 136 or a DCS (e.g., camera agent 138 or another DCS), which are described above with reference to Figures 1-6 .

[0097] In some examples, the requestor 708 is configured to communicate with the receiver 710 via the signaling server 702 to establish a real-time communication session via, for example, a Web Real-Time Communication (WebRTC) framework. However, unlike other processes that use the WebRTC framework to establish a communication session, the requestor 708 and the receiver 710 interoperate via the signaling server 702 to execute code (e.g., provisioning code) on the secure device hosting the receiver 710. This provisioning code can control the processor of the secure device to take any of a variety of programmed actions, such as configuring one or more operational parameters of the secure device other than communication session parameters. For example, in some examples, the requestor 708 is configured to transmit an identifier (e.g., a client identifier) via the signaling server 702 that indicates whether the requestor 708 is a monitor interface, a client interface, or some other type of requestor. In these examples, the receiver 710 is configured to receive the client identifier, identify the type of requestor indicated by the client identifier, and autonomously configure operational parameters of the host device based on the identified requestor type. Examples of operational parameters that can be configured in these examples include operational parameters that control a user interface of the secure device, operational parameters that control recording of video acquired by the secure device (e.g., where the host device is or includes a camera), and operational parameters that control remote access to the secure device. Further examples of processes and operations that the requestor 708 and / or the receiver 710 are configured to perform are described below with reference to Figures 8A-12 Further examples of processes and operations that the requestor 708 and / or the receiver 710 are configured to perform are described below with reference to

[0098] Continuing Figure 7 In examples, the signaling server 702 is configured to act as an intermediary or go-between between the requestor 708 and the receiver 710 in establishing a communication session. Thus, in some examples, an address (e.g., an IP address and port) of the signaling server 702 is accessible to the requestor 708 and the receiver 710. For example, the IP address and port number of the signaling server 702 can be stored as configuration data in memory local to the devices hosting the requestor 708 and the receiver 710. In some examples, the receiver 710 is configured to retrieve the address of the signaling server 702 and is configured to register with the signaling server 702 during initialization to inform the signaling server of its availability for real-time communication sessions. In these examples, the requestor 708 is configured to retrieve the address of the signaling server 702 and is configured to connect with the signaling server 702 to initiate communication with the receiver 710 as part of establishing a communication session with the receiver 710. In this way, the signaling server 702 provides a central point of contact for a large number of requestors including the requestor 708 and a central point of management for a large number of receivers including the receiver 710. Further examples of processes and operations that the signaling server 702 is configured to perform are described below with reference to Figure 8A Further examples of processes and operations that the signaling server 702 is configured to perform are described below with reference to

[0099] continue Figure 7 For example, STUN server 704 receives, processes, and responds to requests from other devices seeking their own public IP addresses. In some examples, individual requesters 708 and receivers 710 are configured to interoperate with STUN server 704 to determine the public IP address of their host devices. TURN server 706 receives, processes, and forwards WebRTC messages from one device to another. In some examples, individual requesters 708 and receivers 710 are configured to interoperate with TURN server 706 when it is impossible to establish a WebRTC session utilizing the public IP address of a host device (e.g., when network translation devices, such as firewalls, are inserted between host devices). See below for more details. Figure 8A Further examples are provided of the processes and operations that STUN server 704 and / or TURN server 706 are configured to perform.

[0100] Now go to Figures 8A-8D The process 800 for establishing and conducting communication sessions (including remote intervention and autonomous security device preparation) is shown as a sequence diagram. In some examples, process 800 may be initiated by a security system (e.g., Figure 1 The security system 100) executes the process. More specifically, in some examples, at least a portion of process 800 is executed by one or more location-based devices in a session receiver (e.g., implemented by at least one processor). Figure 7 The session receives data under the control of receiver 710. At least a portion of process 800 is controlled by a monitoring center environment (e.g., Figure 1 The monitoring center environment 120) or customer equipment (e.g., Figure 1 The client device 122) in the session requester implemented by at least one processor ( Figure 7 The process 800 is executed under the control of the requester 708. At least a portion of the process 800 is controlled by the data center environment (e.g., Figure 1 In a data center environment 124, a transport service implemented by at least one processor (e.g., Figure 1 The process 800 is executed under the control of the transmission service 126. At least a portion of the process 800 is controlled by the base station (e.g., Figure 1 Base station 114) in monitoring client (e.g., Figure 1 The process 800 is executed under the control of the supervising client 136. In a particular example, at least a portion of the process 800 is executed by one or more location-based devices under the control of DCS code implemented by one or more processors of these location-based devices.

[0101] like Figure 8AAs shown, the process 800 begins with the session receiver transmitting a message 802 specifying a connection request to the signaling server. For example, in some examples, the session receiver transmits a request message to open a TCP socket or WebSocket to the signaling server as part of an initialization process performed by the device hosting the session receiver.

[0102] Continuing with the process 800, the signaling server processes the message 802 and transmits a message 804 specifying a connection response to the session receiver. For example, in some examples, the signaling server transmits a response message confirming that the parameters of the connection proposed in the message 802 are acceptable, and that a connection between the session receiver and the signaling server is established.

[0103] Continuing with the process 800, the session requester transmits a message 806 specifying a connection request to the signaling server. For example, in some examples, the session requester transmits a request message to open a TCP socket or WebSocket to the signaling server in response to receiving input from a user specifying a request for a communication session (e.g., a real-time communication session) with the session receiver. The user can input such a request in response to a notification of a reportable event (e.g., a detected motion, etc.) generated by the device hosting the session receiver. In such a case, the session requester records an association between the reportable event and the connection request (e.g., stores a data structure of an identifier of the reportable event and an identifier of the connection request). For example, in some examples, the session requester interoperates (e.g., via one or more API calls) with a supervisory service (e.g., the supervisory service 128 of FIG. 1) to request that the association be recorded. Figure 5

[0104] Continuing with the process 800, the signaling server processes the message 806 and transmits a message 808 specifying a connection response to the session requester. For example, in some examples, the signaling server transmits a response message confirming that the parameters of the connection proposed in the message 806 are acceptable, and that a connection between the session requester and the signaling server is established.

[0105] ​Continuing process 800, the session requester encodes an identifier (e.g., a client identifier) ​​810 to specify the type of the session requester and transmits a message 812 specifying the encoded client identifier to the signaling server. For example, in some examples, the session requester encodes the client identifier to specify the current timestamp, the type of the session requester, and the identifier of the device hosting the session receiver, and generates message 812 to incorporate the encoded client identifier. In certain examples, the client identifier has an object configured to store the current timestamp, the type of the session requester, and the identifier of the device hosting the session receiver. In these examples, the session requester stores data specifying the current timestamp, the type of the session requester, and the identifier of the device hosting the session receiver in the properties of the client identifier. It should be noted that the client identifier can be used as an indication of the type of user (e.g., a monitor or a customer) who initiated the request for the communication session. It should also be noted that in some examples, the client identifier is omitted from message 812 to support another identifier (e.g., an identifier without encoded information), but it still indicates the type of user. Next, the session requester sends message 812 to the signaling server.

[0106] Continuing with process 800, the signaling server processes message 812 and forwards it to the session receiver. For example, in some cases, the signaling server parses message 812, determines that message 812 is addressed to the session receiver, and forwards message 812 to the session receiver.

[0107] Continuing process 800, the session receiver processes message 812. For example, in some examples, the session receiver receives message 812 and parses message 812 to extract the encoded client identifier. Next, the session receiver decodes the encoded client identifier 820 and performs preparation operations 822 based on the type of session requester indicated by the decoded client identifier. Figure 9 A flowchart illustrates an example of process 900 executing within operation 822. For example... Figures 10-12 As shown, process 900 begins with the session receiver accessing 902 a timestamp specified by the client identifier. For example, in some examples, the session receiver accesses the nature of the client identifier that stores that timestamp.

[0108] Continuing with process 900, the session receiver determines 904 whether the timestamp specified by the client identifier is current. For example, in some examples, the session receiver accesses a current timestamp maintained by its host device and compares the current timestamp to the timestamp specified by the client identifier. In these examples, if the two timestamps differ by more than a configurable threshold, the session receiver determines that the timestamp specified by the client identifier is not current and proceeds to operation 916. In some examples, the value of the configurable threshold is set to match the maximum duration of a communication session (e.g., 5, 10, or 20 minutes, etc.). If the difference between the two timestamps is less than or equal to the configurable threshold, the session receiver determines that the timestamp specified by the client identifier is current and proceeds to operation 906.

[0109] Continuing with process 900, the session receiver accesses 906 an identifier of the device hosting the session receiver specified by the client identifier. For example, in some examples, the session receiver accesses a property of the client identifier that holds an identifier of the device hosting the session receiver.

[0110] Continuing with process 900, the session receiver determines 908 whether the identifier of the host device specified by the client identifier matches the identifier of the device actually hosting the session receiver. For example, in some examples, the session receiver accesses a device ID maintained by its host device and compares the device ID to the identifier of the host device specified by the client identifier. In these examples, if the identifier of the host device specified by the client identifier is different from the device ID maintained by the actual host device, the session receiver determines that there is a mismatch and proceeds to operation 916. If the identifier of the host device specified by the client identifier is not different from the device ID maintained by the actual host device, the session receiver determines that there is a match and proceeds to operation 910.

[0111] Continuing with process 900, the session receiver accesses 910 an identifier of the type of session requester specified by the client identifier. For example, in some examples, the session receiver accesses a property of the client identifier that holds an identifier of the type of session requester. Examples of these types can include string values such as "client" and "monitor," etc.

[0112] Continuing with process 900, the session receiver determines 912 whether the session requestor is of a type that is authorized to establish a live communication session with the session receiver. For example, in some examples, the session receiver accesses a configurable list of types of session requestors that are authorized to establish a live communication session with the session receiver, maintained by the host device of the session receiver. In these examples, the session receiver compares the type specified by the client identifier to the list of types. If the type specified by the client identifier is not in the list of types, the session receiver determines that the session requestor is not authorized to establish a live communication session with the session receiver, and interoperates with the session requestor to abort 916 the live communication session, ending process 900 and process 800 of FIG. 8. Operation 916 can include transmitting one or more error messages from the session receiver to the session requestor to indicate the reason for the abort (e.g., the timestamp is not current per operation 904, the device ID does not match the identifier of the host device per operation 908, or the session requestor lacks authorization to establish a live communication session with the session receiver per operation 912). If the type specified by the client identifier is in the list of types, the session receiver determines that the session requestor is authorized to establish a live communication session with the session receiver and proceeds to operation 914.

[0113] Continuing with process 900, the session receiver prepares 914 its host device for the communication session (e.g., live communication session) with the session requestor. For example, in some examples of operation 914, the session receiver performs one or more preparation procedural operations. These preparation procedural operations can include initiating execution of a process with flow control dependent on the type of the session requestor on the device hosting the session receiver. In some examples, the process with flow control dependent on the type of the session requestor initiated by operation 914 includes the process described below with reference to Figure 8A The preparation procedural operations can also include applying settings specific to the type of the session requestor to one or more operational parameters of the device hosting the session receiver. Applying these settings can include, for example, storing particular predefined or other values at memory locations referenced by the processor of the device hosting the session receiver during subsequent operations. The one or more operational parameters configured by operation 914 can vary based on the capabilities of the device hosting the session receiver, and can include parameters other than those specified in a Session Description Protocol (SDP) offer or answer, exchanged between processes to establish a live communication session using the WebRTC framework, described below with reference to Figure 8Bas further described. In some examples, the operational parameters can include a parameter specifying the type of session requester. This parameter can be set to a string value (e.g., "customer" or "monitor") that is accessed in various operations. Additionally or alternatively, one or more of the operational parameters can specify Figure 8C and Figure 8D one or more audio cues output in operations 854 and 859 of FIG. 8, as further described below. In some examples, as part of operation 914, the session receiver stores the original settings of the operational parameters in local memory before applying the new settings. This feature enables the session receiver to easily undo the new settings via subsequent processing (e.g., operation 868, which is further described below with reference to Figure 9 the operation). After performing operation 914, process 900 ends.

[0114] It should be noted that determinations 904, 908, and 912 are shown by way of example only. In some examples, these determinations are performed in an order different from Figure 9 that shown. Further, in some examples, one or more of determinations 904, 908, and 912 are omitted. Thus, the examples disclosed herein are not limited to the particular order of operations or particular determinations shown. Figure 8A

[0115] It should be further noted that process 900 prepares or configures features of the session receiver for a particular type of communication session based on the type of session requester. In at least some examples, the actions taken by the session receiver are not specified within the WebRTC framework, but reside outside of the actions natively supported by the WebRTC framework.

[0116] Returning to process 800 with reference to Figure 8B , the session requester exchanges Interactive Connectivity Establishment (ICE) messages 816 and / or 818 with a STUN server and / or a TURN server, respectively. Via this exchange of messages 816 and / or 818, the session requester generates one or more ICE candidates and includes the one or more ICE candidates in a message 824 specifying an SDP offer. Next, the session requester transmits message 824 to the signaling server, and the signaling server transmits message 824 to the session receiver. The session receiver exchanges ICE messages 828 and / or 830 with the TURN server and / or the STUN server, generates one or more ICE candidates and includes the one or more ICE candidates in a message 832 specifying an SDP answer. Next, the session receiver transmits message 832 to the signaling server, and the signaling server transmits message 832 to the session requester. Via messages 824 and 832, the session requester and the session receiver negotiate communication parameters for the real-time communication session, and continue with reference to Figure 8B ​Open the 834 real-time communication session.

[0117] Continue to refer to Figure 5 In process 800, the session requester opens a data channel with the session receiver at 840. For example, in some examples, the session requester calls the createDataChannel() WebRTC API call to open a data channel with the session receiver. In these examples, the createDataChannel() call transmits message 842, specifying the data channel, to the session receiver. The session receiver then processes message 842 and opens the requested data channel.

[0118] Continuing process 800, the session requester receives input 844 from the user, which specifies the device that releases the managed session requester (e.g., Figure 1 Computing device 518 or Figure 5 and Figure 1 The user (e.g., a monitoring agent or client) requests to mute the microphone of one of the client devices 122. For example, in some examples, the user (e.g., a monitoring agent or client) responds to a request to mute the microphone at the monitored location (e.g., Figure 9 Location 102A receives an alert and requests a real-time communication session via a host device (e.g., a location-based device with a speaker and microphone) through a session receiver.

[0119] Continuing process 800, the session requester processes the input by generating message 846 and transmitting it to the session receiver via a data channel. For example, in some examples, message 846 specifies a request for intervention by the host device of the session receiver for a reportable event occurring at the monitored location. Such intervention may include, for example, interaction between monitoring personnel and / or customers and people at the monitored location via the host device of the session receiver.

[0120] Continuing process 800, the session receiver processes message 846. For example, in some examples, if the alarm on the session receiver's host device is active, the session receiver mutes the alarm 848. For example, in some examples, the session receiver configures the operating parameters of the host device controlling the alarm volume to a mute setting. Further, in some examples, the session receiver generates message 850 and transmits it to a monitoring client hosted by a base station within the monitored location. Message 850 specifies a request to adjust the volume of the alarms at the monitored location. For example, in some examples, message 850 specifies via alarm settings that all alarms at the monitored location, except those mute in operation 848, should be adjusted to a low setting.

[0121] Continuing with process 800, the supervisory client receives and processes message 850. For example, in some examples, the supervisory client parses message 850 to extract the siren settings, and adjusts the volume of the siren to match the siren settings in instances in which the supervisory client is not hosted by the host device of the session receiver. In these examples, the supervisory client can store the previous siren settings in local memory for possible subsequent restoration. Additionally or alternatively, in some examples, the supervisory client generates and transmits one or more messages 852 to one or more DCSs of one or more other location-based devices 875 that incorporate or control the siren. Message 852 specifies a request to adjust the volume of the siren at the monitored location. For example, in some examples, message 852 specifies via the siren settings that the siren incorporated in or controlled by the one or more other location-based devices 875 should be adjusted to a low setting.

[0122] Continuing with process 800, the one or more DCSs of the one or more other location-based devices 875 receive and process the one or more messages 852. For example, in some examples, the one or more DCSs parse message 852 to extract the siren settings, and adjust the volume of the siren incorporated in or controlled by the one or more other location-based devices 875 to match the siren settings. In these examples, the one or more DCSs can store the previous siren settings in local memory for possible subsequent restoration.

[0123] Continuing with process 800, the session receiver outputs, via the host device’s speaker 854, an audio cue indicating that the live communication session is about to begin. In these examples, the audio cue output can be specified by a configurable operational parameter, for example, set based on the type of session requester in operation 914, as described above. Figure 8C

[0124] Continuing with process 800 of Figure 9 , the session receiver transmits, to the session requester via the data channel, message 836 specifying a response to message 846. In some examples, the response indicates a result (e.g., success or failure code, etc.) of the operation initiated by message 846.

[0125] Continuing with process 800, the session requester receives and processes 838 message 836. For example, in some examples, the session requester parses message 836 to extract the result indicated therein, and renders a human-readable representation of the result via a user interface of the device hosting the session requester. In this way, the session requester informs its user as to whether the monitored location is ready to support user interaction with the individual at the monitored location via the live communication session.

[0126] ​Continuing with process 800, the session requester and the session receiver exchange real-time communications 856 via the real-time communication session. These real-time communications 856 can include audio and / or video content that monitors the interaction between the monitoring personnel and / or the customer and the person at the monitored location. During these real-time communications 856, the session requester can receive input specifying further adjustments to the siren volume and can interoperate with the session receiver to implement those adjustments. The further adjustments to the siren volume can include, for example, restoring the original siren volume or other adjustments.

[0127] Continuing with process 800, at a subsequent point, the session receiver and / or the session requester notify the other that the communication session is about to be closed. For example, in some examples, a timer implemented by the session receiver can expire. Alternatively or additionally, a user interacting with the session requester or the session receiver can enter a request to terminate the communication session. For example, in some examples, the session requester receives 857 input from its user specifying a request to mute the microphone of the device hosting the session requester. In these examples, the session requester processes the input by generating a message 858 and transmitting it to the session receiver via the data channel. In some examples, the message 858 specifies a request to close the communication session. Regardless of who initiates, in some examples, the session receiver outputs 859 an audio prompt via the speaker of the host device indicating that the communication session has ended. In some examples, the audio prompt output can be specified by a configurable operational parameter, for example, set based on the type of session requester in operation 914, as described above. Figure 8D

[0128] Continuing with process 800, the session receiver unmutes 860 the siren. For example, in some examples, the session receiver configures the operational parameter of the host device of the session receiver that controls the siren volume to the unmuted setting. Further, in some examples, the session receiver generates a message 862 and transmits it to the supervisory client hosted by the base station within the monitored location. The message 862 specifies a request to adjust the volume of the sirens at the monitored location. For example, in some examples, the message 862 specifies via the siren setting that all sirens at the monitored location, except for the siren restored by operation 860, should be adjusted to the previous setting stored in local memory.

[0129] ​Continuing with process 800, the supervisory client receives and processes message 862. For example, in some examples, the supervisory client parses message 862 to extract the siren settings, and adjusts the volume of the siren to match the siren settings if the supervisory client is not hosted by the host device of the session receiver. Additionally or alternatively, in some examples, the supervisory client generates and transmits one or more messages 864 to one or more DCSs of one or more other location-based devices 875 that incorporate or control the siren. Message 864 specifies a request to adjust the volume of the siren at the monitored location. For example, in some examples, message 862 specifies via the siren settings that the siren incorporated in or controlled by one or more other location-based devices 875 should be adjusted to the previous settings stored in local memory.

[0130] Continuing with process 800, the one or more DCSs of the one or more other location-based devices 875 receive and process the one or more messages 864. For example, in some examples, the one or more DCSs parse message 864 to extract the siren settings, and adjust the volume of the siren incorporated in or controlled by the one or more other location-based devices 875 to match the siren settings.

[0131] It should be noted that, in some examples, operation 860 is omitted or the siren is not fully restored. In these examples, siren adjustment requests 862 and 864 are not sent or specify a volume level that is different from (e.g., lower than) the previous siren settings stored in local memory. In still other examples, operation 860 is performed if the communication session is abnormally closed (e.g., does not successfully complete operation 866 as described below).

[0132] Continuing with reference to process 800 of Figure 9 , the session requester and the session receiver interoperate to close 866 the communication session. After the communication session is closed, the session receiver undoes 868 one or more preparation operations performed in operation 914 of Figure 9 . For example, in some examples, the session receiver terminates processes initiated to prepare the device hosting the session receiver for the communication session, and reconfigures one or more operational parameters of the device hosting the session receiver to one or more default settings or one or more original settings (e.g., one or more values in place prior to operation 914 of Figure 10 ). Next, the session receiver performs any additional programmed operations necessary to validate the one or more reconfigured operational parameters. After performing operation 868, process 800 ends.

[0133] It should be noted that in some examples, each of the processes described herein can respond to a message received from another process by generating and transmitting an acknowledgement of receipt of the message to the other process. Such an acknowledgement message can indicate receipt of the message. Additionally or alternatively, an acknowledgement message can specify a result of processing the message (e.g., success, failure, error code, etc.).

[0134] Turning now to Figure 1 , a process 1000 indicating a type of session requester is shown as a flowchart that can be initiated during autonomous preparation of a security device for a communication session (e.g., a real-time communication session). In some examples, the process 1000 can be performed by a security system (e.g., the security system 100 of Figure 7 . More specifically, in some examples, at least a portion of the process 1000 is performed by one or more location-based devices under control of a session receiver (e.g., the receiver 710 of Figure 10 implemented by at least one processor, the session receiver. As shown in Figure 1 , the process 1000 begins with the session receiver accessing 1002 an operational parameter stored on a device hosting the session receiver. For example, in some examples, the session receiver reads a value of an operational parameter specifying a type of session requester.

[0135] Continuing with the process 1000, the session receiver determines 1004 whether the type of session requester is a customer interface (e.g., one of the customer interfaces 132 of Figure 1 . For example, in some examples, the session receiver compares the value of the operational parameter accessed in operation 1002 to a string (e.g., “customer”). In these examples, if the value of the operational parameter matches the string, the session receiver determines that the type of session requester is a customer interface and proceeds to operation 1006. Further, in these examples, if the value of the operational parameter does not match the string, the session receiver determines that the type of session requester is not a customer interface and proceeds to operation 1008.

[0136] Continuing with the process 1000, the session receiver controls 1006 a user interface to indicate that the session requester is a customer interface (e.g., that a customer is interacting with a host device of the session receiver via a real-time communication session). For example, in some examples, the session receiver controls an LED of the user interface to illuminate in a color or pattern associated with and indicating a customer access. In some examples, the session receiver controls the user interface to indicate that the session requester is a customer interface by causing a display of the user interface to display a message (e.g., a text message) indicating that a customer is interacting with the host device of the session receiver via a real-time communication session.

[0137] Continuing with the process 1000, the session receiver determines 1008 whether the type of session requester is a monitor interface (e.g., one of the monitor interfaces 134 of Figure 11(One of the monitor interfaces 130). For example, in some examples, the session receiver compares the value of the operation parameter accessed in operation 1002 with a string (e.g., "monitor"). In these examples, if the value of the operation parameter matches the string, the session receiver determines that the type of the session requester is a monitor interface and proceeds to operation 1010. Further, in these examples, if the value of the operation parameter does not match the string, the session receiver determines that the type of the session requester is not a monitor interface and proceeds to operation 1012.

[0138] Continuing process 1000, the session receiver controls the user interface 1010 to indicate that the session requester is a monitor interface (e.g., a monitor is interacting with the session receiver's host device via a real-time communication session). For example, in some examples, the session receiver controls the user interface's LEDs to be associated with monitor access and to indicate the color or pattern illuminated for monitor access.

[0139] Continuing process 1000, the session receiver terminates the communication session 1012 because the session requester is unknown. For example, in some examples, the session receiver interoperates with the session requester to terminate the communication session, thereby ending process 1000 and process 800 of Figure 8. This interoperation may include sending one or more error messages from the session receiver to the session requester indicating that the type of the session requester is not identified. After performing operation 1010 or operation 1012, process 1000 terminates.

[0140] Now go to Figure 1 The monitoring process 1100 is shown as a flowchart, which can be initiated during the autonomous preparation of a security device for a communication session (e.g., a real-time communication session) with a specific type of requester. In some examples, process 1100 may be initiated by a security system (e.g., Figure 7 The security system 100) executes the process. More specifically, in some examples, at least a portion of process 1100 is executed by one or more location-based devices in a session receiver (e.g., implemented by at least one processor). Figure 11 The session receives data under the control of the receiver 710. Figure 1 As shown, process 1100 begins with session receiver access 1102 to operation parameters stored on the device hosting the session receiver. For example, in some examples, the session receiver reads the value of an operation parameter that specifies the type of session requester.

[0141] Continuing process 1100, the session receiver determines whether the type of the session requester in 1104 is a monitor interface (e.g., Figure 12For example, in some examples, the session receiver compares the value of the operational parameter accessed in operation 1102 to a string (e.g., "monitor"). In these examples, if the value of the operational parameter matches the string, the session receiver determines that the type of the session requester is a monitor interface and proceeds to operation 1106. Further, in these examples, if the value of the operational parameter does not match the string, the session receiver determines that the type of the session requester is not a monitor interface, and the process 1100 ends.

[0142] Continuing with the process 1100, the session receiver determines 1106 whether the reportable event associated with the communication session has been cancelled by the client interface. For example, in some examples, the session receiver interoperates with the supervisory service (e.g., via one or more API calls) to determine the status of the reportable event associated with the communication session. If the status of the reportable event is not cancelled, the session receiver introduces a delay 1108 before re-determining 1106 the status of the reportable event. For example, in some examples, the session receiver initiates a short duration (> 1 sec, > 2 sec, > 3 sec, etc.) timer and re-determines 1106 the status of the reportable event after the timer expires. If the status of the reportable event is cancelled, the session receiver proceeds to operation 1110.

[0143] Continuing with the process 1100, the session receiver aborts 1110 the communication session because the client interface cancelled the associated reportable event. For example, in some examples, the session receiver interoperates with the session requester to terminate the communication session, ending the process 1100 and the process 800 of FIG. 8. This interoperating can include transmitting one or more error messages from the session receiver to the session requester specifying that the communication session is aborted due to the cancellation of the associated reportable event. After performing operation 1110, the process 1100 ends.

[0144] Turning now to Figure 1 , the session logging process 1200 is shown as a flowchart that can be initiated during the autonomous preparation of a security device for a communication session (e.g., a real-time communication session) with a particular type of requester. In some examples, the process 1200 can be performed by a security system (e.g., the security system 100 of Figure 7 . More specifically, in some examples, at least a portion of the process 1200 is performed by one or more location-based devices under the control of a session receiver (e.g., the receiver 710 of Figure 12 implemented by at least one processor, the session receiver. As Figure 1As shown, the process 1200 begins with the session receiver accessing 1202 an operational parameter stored on a device hosting the session receiver. For example, in some examples, the session receiver reads a value of an operational parameter that specifies a type of session requester.

[0145] Continuing with the process 1200, the session receiver determines 1204 whether the type of session requester is a monitor interface (e.g., one of the monitor interfaces 130). For example, in some examples, the session receiver compares the value of the operational parameter accessed in operation 1202 to a string (e.g., "monitor"). In these examples, if the value of the operational parameter matches the string, the session receiver determines that the type of session requester is a monitor interface and proceeds to operation 1206. Further, in these examples, if the value of the operational parameter does not match the string, the session receiver determines that the type of session requester is not a monitor interface and the process 1200 ends. Figure 5

[0146] Continuing with the process 1200, the session receiver initiates a session recording and a timer 1206 to record a communication session while limiting an amount of time consumed thereby and an amount of recording storage. For example, in some examples, the timer is set to expire in a configurable predetermined amount of time and the session recording is streamed to a supervisory service for storage (e.g., in the sensor data storage 504 of the supervisory service 500) as long as the timer has not expired. Examples of the configurable predetermined amount of time can include 2 minutes, 5 minutes, 10 minutes, 20 minutes, 30 minutes, or longer. Figure 1

[0147] Continuing with the process 1200, the session receiver continues 1208 the session recording and determines 1210 whether the timer initiated in operation 1206 has expired. If the timer has not expired, the session receiver continues 1208 the session recording. If the timer has expired, the session receiver proceeds to operation 1212.

[0148] Continuing with the process 1200, the session receiver terminates the session recording and reports 1212 the session recording to a customer interface (e.g., one of the customer interfaces 132). For example, in some examples, the session receiver interoperates with the supervisory service (e.g., via one or more API calls) to terminate the session recording and request that the session recording be reported to the customer interface. In particular examples, the supervisory service is configured to report the session recording within a customer timeline rendered by the customer interface. Figure 13

[0149] Turning now to Figure 13 , a computing device 1300 is schematically illustrated. As Figure 13 ​​​As shown, the computing device includes at least one processor 1302, volatile memory 1304, one or more interfaces 1306, non-volatile memory 1308, and an interconnect mechanism 1314. The non-volatile memory 1308 includes code 1310 and at least one data store 1312.

[0150] In some examples, the non-volatile (non-transitory) memory 1308 includes 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 SSD. In particular examples, the code 1310 stored in the non-volatile memory can include an operating system and one or more application programs or procedures configured to execute under the operating system. Alternatively or additionally, the code 1310 can include special-purpose firmware and embedded software that can be executed without reliance on a commercially available operating system. Regardless, execution of the code 1310 can produce manipulated data that can be stored as one or more data structures in the data store 1312. The data structures can have fields that are associated by colocation in the data structure. Such associations can also be implemented by assigning storage for a field in a location in memory that conveys an association between the fields. However, other mechanisms of establishing associations between information in fields of data structures can be used, including through the use of pointers, tags or other mechanisms.

[0151] Continuing Figure 13 In examples, the processor 1302 can be one or more programmable processors to execute one or more executable instructions, such as a computer program specified by the code 1310, to control operations of the computing device 1300. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations can be hard coded into the circuitry or soft coded by way of instructions held as a software program, in a memory device, e.g., the volatile memory 1304, and executed by the circuitry. In some examples, the processor 1302 is a digital processor, but the processor 1302 can be an analog processor, a digital processor, or a hybrid processor. Thus, the processor 1302 can perform a function, operation, or sequence of operations using digital values and / or using analog signals. In some examples, the processor 1302 can be embodied in 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. Examples of multi-core processors 1302 can provide functionality for parallel, simultaneous execution of instructions, or for parallel, simultaneous execution of more than one data segment of an instruction.

[0152] Continuing Figure 13 In the example of FIG. 13, the code 1310 includes instructions that, when executed by the processor 1302, enable the computing device 1300 to perform various features described herein. The code 1310 can be stored in the non-volatile memory 1308, the volatile memory 1304, and / or elsewhere on the computing device 1300. In some examples, the code 1310 includes instructions that, when executed by the processor 1302, enable the computing device 1300 to perform one or more of the methods described herein.

[0153] By executing the code 1310, the processor 1302 can control the operation of the interface 1306. The interface 1306 can include a network interface. These network interfaces can include one or more physical interfaces (e.g., radios, Ethernet ports, USB ports, etc.) as well as a software stack including drivers and / or other code 1310 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. The communication protocols can include, for example, TCP and UDP, among others. Thus, the network interface enables the computing device 1300 to access and communicate with other computing devices via a computer network.

[0154] The interface 1306 can include a user interface. For example, in some examples, the user interface includes user input and / or output devices (e.g., a keyboard, a mouse, a touchscreen, a display, a speaker, a camera, an accelerometer, a biometric scanner, an environmental sensor, etc.) as well as a software stack including drivers and / or other code 1310 configured to communicate with the user input and / or output devices. Thus, the user interface enables the computing device 1300 to interact with a user to receive input and / or render output. The rendered output can include, for example, one or more GUIs including one or more controls configured to display output and / or receive input. The input can specify values to be stored in the data storage 1312. The output can indicate values stored in the data storage 1312.

[0155] Continuing ​ In the example of FIG. 13, the various features of the computing device 1300 described above can communicate with each other via an interconnection mechanism 1314. In some examples, the interconnection mechanism 1314 includes a communication bus.

[0156] The various inventive concepts can be embodied as one or more methods, of which an example has been provided. The acts performed as part of the method can be ordered in any suitable way. Accordingly, examples can be constructed in which acts are performed in an order different than illustrated, which can include performing some acts simultaneously, even though shown as being performed sequentially by virtue of being included in the same example.

[0157] The following is a description of additional examples. Other variations will be apparent from the disclosure.

[0158] Example 1 is a method of receiving, by a first device from a second device, a request to participate in a session, the request being a message conforming to a web real-time communication (WebRTC) framework and including an identifier of a process hosted by the second device; validating, by the first device based on the identifier, a type of the process hosted by the second device; responsive to the validation of the type of the process hosted by the second device, initiating, by the first device, one or more actions to configure the first device to conduct the session, the one or more actions being defined outside of the WebRTC framework; and subsequent to the initiation of the one or more actions on the first device, establishing, by the first device and in conformity with the WebRTC framework, the session with the second device.

[0159] Example 2 includes the subject matter of Example 1, wherein initiating the one or more actions comprises initiating a process that controls a user interface of the first device to output an indication of the type of the process hosted by the second device; initiating a process that records the session; or initiating a process that aborts the session.

[0160] Example 3 includes the subject matter of Example 2, wherein: initiating the one or more actions comprises initiating the process that controls the user interface of the first device to output the indication of the type of the process hosted by the second device; and the process that controls the user interface comprises controlling a light-emitting diode to illuminate in a color or pattern associated with the type of the process hosted by the second device.

[0161] Example 4 includes the subject matter of Example 2 or Example 3, wherein: initiating the one or more actions comprises initiating the process that records the session; and the process that records the session comprises determining that the process hosted by the second device is a monitor interface.

[0162] Example 5 includes the subject matter of any of Examples 2-4, wherein: initiating the one or more actions comprises initiating the process that aborts the session; and the process that aborts the session comprises: determining that the process hosted by the second device is a monitor interface; and determining that an event associated with the session is canceled.

[0163] Example 6 includes the subject matter of any one of Examples 1-5, wherein receiving, by the first device, the request comprising the identifier of the process hosted by the second device comprises receiving, by a location-based device, an identifier of a client interface or a monitor interface.

[0164] Example 7 includes the subject matter of Example 6, wherein receiving the identifier of the client interface or the monitor interface comprises receiving, by an image capture device, the identifier of the client interface or the monitor interface.

[0165] Example 8 includes the subject matter of Example 6 or Example 7, wherein receiving the identifier of the client interface or the monitor interface comprises receiving an identifier that specifies the type of the process hosted by the second device, a timestamp, and an identifier of the first device.

[0166] Example 9 includes the subject matter of Example 8, further comprising determining an actual identifier of the first device, and comparing the identifier of the first device to the actual identifier of the first device as part of a process to validate the identifier of the process hosted by the second device.

[0167] Example 10 includes the subject matter of Example 8 or Example 9, further comprising encoding, by the process hosted by the second device, the identifier of the process hosted by the second device to specify the type of the process hosted by the second device, the timestamp, and the identifier of the first device.

[0168] Example 11 is a first device comprising: a memory; a network interface; and at least one processor coupled to the memory and the network interface and configured to: receive, via the network interface from a second device, a request to participate in a session, the request comprising a message conforming to a web real-time communication (WebRTC) framework and comprising an identifier of a process hosted by the second device; validate, based on the identifier, a type of the process hosted by the second device; responsive to the validation of the type of the process hosted by the second device, initiate one or more actions to configure the first device for the session, the one or more actions not specified by the WebRTC framework; and subsequent to the initiation of the one or more actions on the first device, establish the session with the second device in conformity with the WebRTC framework.

[0169] Example 12 includes the subject matter of Example 11, wherein initiating the one or more actions comprises initiating a process to control a user interface of the first device to output an indication of the type of the process hosted by the second device, initiating a process to record the session, or initiating a process to selectively abort the session.

[0170] Example 13 includes the subject matter of Example 12, wherein: initiating the one or more actions comprises initiating the process to control the user interface of the first device to output the indication of the type of the process hosted by the second device; and controlling the user interface comprises controlling a light emitting diode to illuminate in a color or pattern associated with the type of the process hosted by the second device.

[0171] Example 14 includes the subject matter of Example 12 or Example 13, wherein: initiating the one or more actions comprises initiating the process to record the session; and recording the session comprises determining that the process hosted by the second device is a monitor interface.

[0172] Example 15 includes the subject matter of any of Examples 12-14, wherein: initiating the one or more actions comprises initiating the process to selectively discontinue the session; and selectively discontinuing the session comprises: determining that the process hosted by the second device is a monitor interface; and determining that an event associated with the session is canceled.

[0173] Example 16 includes the subject matter of any of Examples 11-15, wherein: the first device is a location-based device; and receiving the request comprising the identifier of the process hosted by the second device comprises receiving an identifier of a client interface or a monitor interface.

[0174] Example 17 includes the subject matter of Example 16, wherein the location-based device is a camera.

[0175] Example 18 includes the subject matter of Example 16 or Example 17, wherein receiving the identifier of the client interface or the monitor interface comprises receiving an identifier that specifies the type of the process hosted by the second device, a timestamp, and an identifier of the first device.

[0176] Example 19 includes the subject matter of Example 18, wherein the at least one processor is further configured to: determine an actual identifier of the first device; and compare the identifier of the first device to the actual identifier of the first device as part of the process to validate the identifier of the process hosted by the second device.

[0177] Example 20 includes the subject matter of Example 18 or Example 19, wherein the at least one processor is further configured to decode the identifier of the process hosted by the second device to determine the type of the process hosted by the second device, the timestamp, and the identifier of the first device.

[0178] Example 21 is a security system comprising: a first device configured to host a first process, the first process configured to: receive an identifier of a second process requesting to participate in a live communication session with the first process; determine a type of the second process based on the identifier; configure the first device for the live communication session based on the type of the second process, wherein configuring comprises initiating one or more processes on the first device, or setting one or more operational parameters of the first device other than communication session parameters; and establish the live communication session with the second process after the configuration of the first device.

[0179] Example 22 includes the subject matter of Example 21, wherein initiating the one or more processes comprises: initiating a process that controls a user interface of the first device to output an indication of the type of the second process; initiating a process that records the live communication session; or initiating a process that aborts the live communication session.

[0180] Example 23 includes the subject matter of Example 22, wherein: initiating the one or more processes comprises initiating the process that controls the user interface of the first device to output the indication of the type of the second process; and initiating the process that controls the user interface comprises initiating a process that controls a light emitting diode to illuminate in a color or pattern associated with the type of the second process.

[0181] Example 24 includes the subject matter of Example 22 or Example 23, wherein: initiating the one or more processes comprises initiating the process that records the live communication session; and initiating the process that records the live communication session comprises determining that the type of the second process is a monitor interface.

[0182] Example 25 includes the subject matter of any of Examples 22-24, wherein initiating the one or more processes comprises initiating the process that aborts the live communication session; and initiating the process that aborts the live communication session comprises: determining that the type of the second process is a monitor interface; and determining that an event associated with the live communication session is canceled.

[0183] Example 26 includes the subject matter of any of Examples 21-25, wherein receiving the identifier of the second process comprises receiving an identifier of a client interface or a monitor interface by a process hosted by a location-based device.

[0184] Example 27 includes the subject matter of Example 26, wherein receiving the identifier of the client interface or the monitor interface comprises receiving an identifier of the client interface or the monitor interface by a camera agent hosted on an image capture device.

[0185] Example 28 includes the subject matter of Example 26 or Example 27, wherein receiving the identifier of the client interface or the monitor interface comprises receiving an identifier that specifies the type of the second process, a timestamp, and an identifier of the first device.

[0186] Example 29 includes the subject matter of Example 28, wherein the first process is further configured to: determine an actual identifier of the first device; and compare the identifier of the first device to the actual identifier of the first device as part of a process to validate the identifier of the second process.

[0187] Example 30 includes the subject matter of Example 28 or Example 29, further comprising a second device that hosts the second process, wherein the second process is further configured to encode the identifier of the second process to specify the type of the second process, the timestamp, and the identifier of the first device.

[0188] Example 31 is a method comprising: receiving, by a first device from a second device, a request to participate in a session, the request including an indication of a user accessing the second device, and the session being configured such that input received by the second device from the user is outputtable via the first device within less than 600 milliseconds after being received; identifying, by the first device based on the indication, a type of the user; responsive to identifying the type of the user, initiating, by the first device on the first device, one or more actions that are different from actions for communicating data between the first device and the second device; and establishing, by the first device, the session with the second device after initiation of the one or more actions on the first device.

[0189] Example 32 includes the subject matter of Example 31, the indication of the user comprising an identifier of a process hosted by the second device, wherein identifying the type of the user comprises identifying a type of the process hosted by the second device.

[0190] Example 33 includes the subject matter of Example 32, wherein initiating the one or more actions comprises: initiating a process that controls a user interface of the first device to output an indication of the type of the process hosted by the second device; initiating a process that records the session; or initiating a process that aborts the session.

[0191] Example 34 includes the subject matter of Example 33, wherein: initiating the one or more actions comprises initiating the process that controls the user interface of the first device to output the indication of the type of the process hosted by the second device; and the process that controls the user interface controls a light-emitting diode to illuminate in a color or pattern associated with the type of the process hosted by the second device.

[0192] Example 35 includes the subject matter of Example 33 or Example 34, wherein: initiating the one or more actions comprises initiating a process to record the session; and the process to record the session determines that the type of the user is a monitoring professional.

[0193] Example 36 includes the subject matter of Example 35, the indication of the user comprises the identifier of the process hosted by the second device, wherein the process to record the session determines that the type of the user is the monitoring professional by determining that the process hosted by the second device is a monitor interface based on the identifier of the process hosted by the second device.

[0194] Example 37 includes the subject matter of any of Examples 33-36, wherein: initiating the one or more actions comprises initiating a process to abort the session; the indication of the user comprises the identifier of the process hosted by the second device; and the process to abort the session: determines that the process hosted by the second device is a monitor interface; and determines that an event associated with the session is cancelled.

[0195] Example 38 includes the subject matter of any of Examples 31-37, wherein receiving, by the first device, the request comprising the indication of the user comprises receiving, by a location-based device, an indication of a customer or a monitoring professional.

[0196] Example 39 includes the subject matter of Example 38, wherein receiving the indication of the customer or the monitoring professional comprises receiving, by an image capture device, the indication of the customer or the monitoring professional.

[0197] Example 40 includes the subject matter of Example 39, wherein receiving the indication of the customer or the monitoring professional comprises receiving an identifier specifying a type of a process hosted by the second device, a timestamp, and an identifier of the first device.

[0198] Example 41 includes the subject matter of Example 40, further comprising: determining an actual identifier of the first device; and comparing the identifier of the first device to the actual identifier of the first device as part of a process to validate the indication of the user.

[0199] Example 42 includes the subject matter of Example 40 or Example 41, further comprising encoding, by the process hosted by the second device, the indication of the user to specify the type of the user, the timestamp, and the identifier of the first device.

[0200] Example 43 is a method comprising: receiving, by a first device comprising an active siren, a request from a second device to prepare for a remote intervention, the first device participating with the second device within a session established via a Web Real-Time Communication (WebRTC) framework; transmitting, by the first device to the second device, a response indicating receipt of the request; muting, by the first device, the active siren in response to receiving the request; receiving, by the first device from the second device via the session, audio content; and outputting, by the first device, the audio content.

[0201] Example 44 includes the subject matter of Example 43, further comprising transmitting, by the first device, at least one message to at least one other device located at a same location as the first device, the at least one message specifying at least one request to lower at least one volume of at least one siren controlled by the at least one other device.

[0202] Example 45 includes the subject matter of Example 44, the method further comprising transmitting, by the at least one other device, one or more messages to one or more other devices located at a same location as the at least one other device, the one or more messages requesting to lower one or more volumes of one or more other sirens controlled by the one or more other devices.

[0203] Example 46 includes the subject matter of any of Examples 43-45, wherein receiving the request to prepare for the remote intervention comprises receiving the request via a data channel of the session.

[0204] Example 47 includes the subject matter of any of Examples 43-46, further comprising outputting a first prompt prior to outputting the audio content.

[0205] Example 48 includes the subject matter of any of Examples 43-47, further comprising outputting a second prompt after outputting the audio content.

[0206] Example 49 includes the subject matter of Example 48, further comprising one or more of resuming the active siren or adjusting the active siren to a different volume after outputting the second prompt.

[0207] Example 50 includes the subject matter of any of Examples 44-49, further comprising transmitting, by the first device, at least one subsequent message to the at least one other device located at the same location as the first device, the at least one subsequent message specifying one or more of: at least one request to resume the at least one volume of the at least one siren controlled by the at least one other device; or at least one other request to adjust the at least one volume of the at least one siren to at least one different volume.

[0208] Example 51 includes the subject matter of Example 50, further comprising transmitting, by the at least one other device, one or more subsequent messages to the one or more other devices located at the same location as the at least one other device, the one or more subsequent messages requesting one or more of a resumption of or an adjustment of the one or more volumes of the one or more other sirens controlled by the one or more other devices to one or more different volumes.

[0209] Example 52 includes the subject matter of any one of Examples 43-51, further comprising rendering, by a user interface of the second device, an indication that the active siren was successfully silenced.

[0210] Example 53 is a security system comprising: a first device participating with a second device within a session established via a Web Real-Time Communication (WebRTC) framework and including an active siren, the first device configured to: receive, from the second device, a request to prepare for a remote intervention; transmit, to the second device, a response indicating receipt of the request; silence, responsive to receipt of the request, the active siren; receive, from the second device via the session, one or more messages specifying audio content; and output the audio content.

[0211] Example 54 includes the subject matter of Example 53, wherein the first device is further configured to transmit, to at least one other device located at the same location as the first device, at least one message specifying at least one request to lower at least one volume of at least one siren controlled by the at least one other device.

[0212] Example 55 includes the subject matter of Example 54, further comprising the at least one other device, wherein the at least one other device is configured to transmit, to one or more other devices located at the same location as the at least one other device, one or more messages specifying one or more requests to lower one or more volumes of one or more sirens controlled by the one or more other devices.

[0213] Example 56 includes the subject matter of any one of Examples 53-55, wherein receiving the request to prepare for the remote intervention comprises receiving the request via a data channel of the session.

[0214] Example 57 includes the subject matter of any one of Examples 53-56, wherein the first device is further configured to output a first prompt prior to the audio content.

[0215] Example 58 includes the subject matter of any one of Examples 53-57, wherein the first device is further configured to output a second prompt after the audio content.

[0216] Example 59 includes the subject matter of Example 53, wherein the first device is further configured to resume the active alarm after outputting the second prompt.

[0217] Example 60 includes the subject matter of any one of Examples 54-59, wherein the first device is further configured to transmit at least one subsequent message to the at least one other device located at the same location as the first device, the at least one subsequent message specifying at least one request to resume the at least one volume of the at least one alarm controlled by the at least one other device.

[0218] Example 61 includes the subject matter of Example 60, further comprising the at least one other device, wherein the at least one other device is configured to transmit one or more subsequent messages to the one or more other devices located at the same location as the at least one other device, the one or more subsequent messages specifying one or more requests to resume the one or more volumes of the one or more alarms controlled by the one or more other devices.

[0219] Example 62 includes the subject matter of any one of Examples 53-62, further comprising a second device, wherein the second device is configured to render, via a user interface, an indication that the active alarm was successfully muted.

[0220] The use of serial numbers such as "first," "second," "third" to modify a claim element itself does not imply a priority, precedence or order of one claim element over another claim element, or a time order in which methods performed by actions of the claim elements are performed. Such terminology is used merely as labels to distinguish between claim elements having the same name (but for use of the serial number terminology).

[0221] Examples of the methods and systems discussed herein are not limited in application to the details of construction and the arrangement of components set forth in the following description or illustrated in the accompanying drawings. The methods and systems are capable of implementation in other examples and of being practiced or of being carried out in various ways. Examples of specific implementations are provided herein for illustrative purposes only and are not intended to be limiting. In particular, acts, components, elements and features discussed in connection with any one or more examples are not intended to be excluded from a similar role in any other examples.

[0222] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Any references to examples, components, elements or acts of the systems and methods herein referenced in singular form are not intended to be construed as excluding the possibility of plural forms. Any references to examples, components, elements or acts in plural form are not intended to be construed as excluding the possibility of a single example, component, element or act. The use herein of "including," "comprising," "having," "containing," "involving," and variations thereof, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. References to "or" can be construed as inclusive so that any terms described using "or" can indicate any of a single, more than one, and all of the described terms. In addition, where there is a conflict between what is described in this document and what is described in a document that is incorporated herein by reference, the text in this document controls.

[0223] Having described several examples, one skilled in the art will be aware that modifications and variations are possible. Such modifications and variations are intended to be within the scope of the disclosure. Accordingly, the described examples are intended to be illustrative only and are not intended to be limiting.

Claims

1. A method comprising: The first device receives a request to participate in the session from the second device. The request is a message conforming to the Web Real-Time Communication (WebRTC) framework and includes an identifier of a process hosted by the second device. The first device uses the identifier to verify the type of the process hosted by the second device; In response to confirmation of the type of the process hosted by the second device, the first device initiates one or more actions to configure the first device to conduct the session, the one or more actions being defined outside the WebRTC framework; as well as Following the initiation of one or more actions on the first device, the first device establishes the session with the second device in accordance with the WebRTC framework.

2. The method of claim 1, wherein initiating the one or more actions comprises: A process that initiates control of the user interface of the first device to output an indication of the type of the process hosted by the second device; Initiate a process to record the session; Or initiate a process to terminate the session.

3. The method according to claim 2, wherein: Initiating one or more actions includes initiating a process that controls the user interface of the first device to output the indication of the type of the process hosted by the second device; and The process of controlling the user interface includes controlling light-emitting diodes to illuminate in a color or pattern associated with the type of the process hosted by the second device.

4. The method according to claim 2 or claim 3, wherein: Initiating one or more of the actions includes initiating the process of recording the session; and The process of recording the session includes determining that the process hosted by the second device is a monitor interface.

5. The method according to any one of claims 2 to 4, wherein: Initiating one or more of the actions includes initiating the process of terminating the session; and The process of terminating the session includes: It is determined that the process hosted by the second device is a monitor interface; as well as It was determined that the event associated with the session was cancelled.

6. The method of any one of claims 1 to 5, wherein receiving the request by the first device including the identifier of the process hosted by the second device includes receiving the identifier of a client interface or a monitor interface by a location-based device.

7. The method of claim 6, wherein receiving the identifier of the client interface or the monitor interface includes receiving the identifier of the client interface or the monitor interface by the image capture device.

8. The method of claim 6 or claim 7, wherein receiving the identifier of the client interface or the monitor interface includes a receiving identifier that specifies the type, timestamp, and identifier of the process hosted by the second device, and the first device.

9. The method of claim 8, further comprising: Determine the actual identifier of the first device; as well as The identifier of the first device is compared with the actual identifier of the first device as part of a process used to verify the identifier of the process hosted by the second device.

10. The method of claim 8 or claim 9, further comprising encoding the identifier of the process hosted by the second device through the process hosted by the second device to specify the type of the process hosted by the second device, the timestamp, and the identifier of the first device.

11. A first device comprising: Memory; Network interface; and At least one processor, coupled to the memory and the network interface and configured to A request to participate in a session is received from the second device via the network interface. This request includes a message conforming to the Web Real-Time Communication (WebRTC) framework and includes an identifier of a process hosted by the second device. The type of process hosted by the second device is confirmed based on the identifier. In response to confirmation of the type of the process hosted by the second device, one or more actions are initiated to configure the first device for the session, wherein the one or more actions are not specified by the WebRTC framework, and Following the initiation of one or more actions on the first device, a session with the second device is established in accordance with the WebRTC framework.

12. The first device of claim 11, wherein initiating the one or more actions includes initiating a process for controlling the user interface of the first device to output an indication of the type of the process hosted by the second device, initiating a process for recording the session, or initiating a process for selectively terminating the session.

13. The first device according to claim 12, wherein: Initiating one or more actions includes initiating a process for controlling the user interface of the first device to output the indication of the type of the process hosted by the second device; and Controlling the user interface includes controlling light-emitting diodes to illuminate in a color or pattern associated with the type of the process hosted by the second device.

14. The first device according to claim 12 or claim 13, wherein: Initiating one or more of the actions includes initiating the process for recording the session; and Recording the session includes determining that the process hosted by the second device is a monitor interface.

15. The first device according to any one of claims 12 to 14, wherein: Initiating one or more of the actions includes initiating the process for selectively terminating the session; and Selectively terminating the session includes: It is determined that the process hosted by the second device is a monitor interface; as well as It was determined that the event associated with the session was cancelled.

16. The first device according to any one of claims 11 to 15, wherein: The first device is a location-based device; and Receiving the request, which includes the identifier of the process hosted by the second device, includes receiving the identifier of the client interface or the monitor interface.

17. The first device of claim 16, wherein the location-based device is a camera.

18. The first device of claim 16 or 17, wherein the identifier for receiving the client interface or the monitor interface includes a receiving identifier that specifies the type, timestamp, and identifier of the process hosted by the second device.

19. The first device of claim 18, wherein the at least one processor is further configured to: Determine the actual identifier of the first device; and The identifier of the first device is compared with the actual identifier of the first device as part of a process used to verify the identifier of the process hosted by the second device.

20. The first device of claim 18 or claim 19, wherein the at least one processor is further configured to decode the identifier of the process hosted by the second device to determine the type of the process hosted by the second device, the timestamp, and the identifier of the first device.

21. A security system comprising: A first device, configured to host a first process, the first process being configured as... The identifier of the second process that receives the request to participate in the real-time communication session with the first process; The type of the second process is determined based on the identifier; The first device is configured to perform the real-time communication session based on the type of the second process, wherein the configuration includes initiating one or more processes on the first device, or setting one or more operational parameters of the first device other than communication session parameters; and After the first device is configured, a real-time communication session is established with the second process.

22. The security system of claim 21, wherein initiating the one or more processes comprises: A process that initiates control of the user interface of the first device to output an indication of the type of the second process; Initiate a process to record the real-time communication session; Or initiate a process to terminate the real-time communication session.

23. The security system according to claim 22, wherein: Initiating the one or more processes includes initiating the process that controls the user interface of the first device to output the indication of the type of the second process; and The process of initiating control of the user interface includes initiating a process of controlling light-emitting diodes to illuminate in a color or pattern associated with the type of the second process.

24. The security system according to claim 22 or claim 23, wherein: Initiating the one or more processes includes initiating the process of recording the real-time communication session; and The process that initiates the recording of the real-time communication session includes determining that the type of the second process is a monitor interface.

25. The security system according to any one of claims 22 to 24, wherein: Initiating one or more processes includes initiating the process to terminate the real-time communication session; and The process of initiating the termination of the real-time communication session includes: It was determined that the type of the second process was a monitor interface; and It was determined that the event associated with the real-time communication session was cancelled.

26. The security system according to any one of claims 21 to 25, wherein receiving the identifier of the second process includes receiving an identifier of a client interface or a monitor interface through a process hosted by a location-based device.

27. The security system of claim 26, wherein receiving the identifier of the client interface or the monitor interface includes receiving the identifier of the client interface or the monitor interface by a camera agent hosted on the image capture device.

28. The security system of claim 26 or claim 27, wherein the identifier receiving the client interface or the monitor interface includes a receiving identifier that specifies the type of the second process, the timestamp, and the identifier of the first device.

29. The security system of claim 28, wherein the first process is further configured to: Determine the actual identifier of the first device; and The identifier of the first device is compared with the actual identifier of the first device as part of a process used to verify the identifier of the second process.

30. The security system of claim 28 or claim 29, further comprising a second device hosting the second process, wherein the second process is further configured to encode the identifier of the second process to specify the type of the second process, the timestamp, and the identifier of the first device.

31. A method comprising: A request to participate in a session is received by a first device from a second device, the request including an indication to the user to access the second device, and the session is configured such that input received by the second device from the user can be output via the first device within less than 600 milliseconds after being received; The first device identifies the user's type based on the indication; In response to the identification of the user's type, the first device initiates one or more actions on the first device, the one or more actions being different from actions for transmitting data between the first device and the second device; as well as After one or more actions are initiated on the first device, the session between the first device and the second device is established.

32. The method of claim 31, wherein the instruction to the user includes an identifier of a process hosted by the second device, wherein identifying the type of the user includes identifying the type of the process hosted by the second device.

33. The method of claim 32, wherein initiating the one or more actions comprises: A process that initiates control of the user interface of the first device to output an indication of the type of the process hosted by the second device; Initiate a process to record the session; Or initiate a process to terminate the session.

34. The method of claim 33, wherein: Initiating one or more actions includes initiating a process that controls the user interface of the first device to output the indication of the type of the process hosted by the second device; and The process controlling the user interface controls the light-emitting diodes to illuminate in a color or pattern associated with the type of the process hosted by the second device.

35. The method according to claim 33 or claim 34, wherein: Initiating one or more of the actions includes initiating the process of recording the session; and The process of recording the session determines that the user's type is a monitoring professional.

36. The method of claim 35, wherein the instruction to the user includes the identifier of the process hosted by the second device, wherein the process recording the session determines, based on the identifier of the process hosted by the second device, that the process hosted by the second device is a monitor interface, and determines that the user's type is the monitoring professional.

37. The method according to any one of claims 33 to 36, wherein: Initiating one or more of the actions includes initiating the process of terminating the session; The instruction to the user includes the identifier of the process hosted by the second device; and The process of terminating the session: It is determined that the process hosted by the second device is a monitor interface; and It was determined that the event associated with the session was cancelled.

38. The method of any one of claims 31 to 37, wherein receiving the request including the instruction to the user by the first device includes receiving the instruction to a customer or monitoring professional by a location-based device.

39. The method of claim 38, wherein receiving the instruction to the customer or the monitoring professional comprises receiving the instruction to the customer or the monitoring professional by an image capture device.

40. The method of claim 39, wherein receiving the instruction to the customer or the monitoring professional includes receiving an identifier that specifies the type of process hosted by the second device, a timestamp, and an identifier of the first device.

41. The method of claim 40, further comprising: Determine the actual identifier of the first device; as well as The identifier of the first device is compared with the actual identifier of the first device as part of a process for verifying the instruction to the user.

42. The method of claim 40 or claim 41, further comprising encoding the instruction to the user by a process hosted by the second device, thereby specifying the user's type, the timestamp, and the identifier of the first device.

43. A method comprising: A first device, including an activity alarm, receives a request from a second device to prepare for remote intervention, and the first device participates together with the second device in a session established via a Web Real-Time Communication (WebRTC) framework; The first device sends a response to the second device, the response indicating that the request has been received; In response to receiving the request, the first device silences the active alarm; The first device receives audio content from the second device via the session; as well as The audio content is output by the first device.

44. The method of claim 43, further comprising transmitting at least one message from the first device to at least one other device located at the same location as the first device, the at least one message specifying at least one request to reduce at least one volume of at least one alarm controlled by the at least one other device.

45. The method of claim 44, further comprising transmitting one or more messages from the at least one other device to one or more other devices located at the same location as the at least one other device, the one or more messages requesting a reduction in the volume of one or more other alarms controlled by the one or more other devices.

46. ​​The method of any one of claims 43 to 45, wherein receiving the request to prepare for remote intervention comprises receiving the request via a data channel of the session.

47. The method according to any one of claims 43 to 46, further comprising outputting a first prompt before outputting the audio content.

48. The method according to any one of claims 43 to 47, further comprising outputting a second prompt after outputting the audio content.

49. The method of claim 48, further comprising, after outputting the second prompt, resuming the activity alarm or adjusting the activity alarm to one or more of different volumes.

50. The method of any one of claims 44 to 49, further comprising transmitting at least one follow-up message from the first device to the at least one other device located at the same location as the first device, the at least one follow-up message specifying one or more of the following: at least one request to restore at least one volume of the at least one alarm controlled by the at least one other device; or at least one other request to adjust the at least one volume of the at least one alarm to at least one different volume.

51. The method of claim 50, further comprising transmitting one or more follow-up messages from the at least one other device to the one or more other devices located at the same location as the at least one other device, the one or more follow-up messages requesting the restoration of one or more volumes of the one or more other alarms controlled by the one or more other devices or the adjustment of the one or more volumes of the one or more other alarms to one or more different volumes.

52. The method according to any one of claims 43 to 51, further comprising rendering an indication that the active alarm has been successfully muted by the user interface of the second device.

53. A security system comprising: A first device, participating in a session established via a Web Real-Time Communication (WebRTC) framework, together with a second device and including an activity alarm, is configured to: Receive a request from the second device to prepare for remote intervention. A response is sent to the second device, the response indicating that the request has been received. In response to receiving the request, the active alarm is silenced. Receive one or more messages containing specified audio content from the second device via the session, and Output the audio content.

54. The security system of claim 53, wherein the first device is further configured to transmit at least one message to at least one other device located at the same location as the first device, the at least one message specifying at least one request to reduce at least one volume of at least one alarm controlled by at least one other device.

55. The security system of claim 54, further comprising the at least one other device, wherein the at least one other device is configured to transmit one or more messages to one or more other devices located at the same location as the at least one other device, the one or more messages specifying one or more requests to reduce the volume of one or more alarms controlled by the one or more other devices.

56. The security system according to any one of claims 53 to 55, wherein receiving the request to prepare for remote intervention includes receiving the request via a data channel of the session.

57. The security system according to any one of claims 53 to 56, wherein the first device is further configured to output a first prompt before the audio content.

58. The security system according to any one of claims 53 to 57, wherein the first device is further configured to output a second prompt after the audio content.

59. The security system of claim 53, wherein the first device is further configured to resume the activity alarm after the second prompt is output.

60. The security system according to any one of claims 54 to 59, wherein the first device is further configured to transmit at least one follow-up message to the at least one other device located at the same location as the first device, the at least one follow-up message specifying at least one request to restore the at least one volume of the at least one alarm controlled by the at least one other device.

61. The security system of claim 60, further comprising the at least one other device, wherein the at least one other device is configured to transmit one or more follow-up messages to the one or more other devices located at the same location as the at least one other device, the one or more follow-up messages specifying one or more requests to restore the volume of the one or more alarms controlled by the one or more other devices.

62. The security system according to any one of claims 53 to 62, further comprising a second device, wherein the second device is configured to render an indication via a user interface that the active alarm has been successfully muted.

Images