Technical field
[0001] The present invention relates to security monitoring systems and methods.
Background
[0002] Security installations that are or include security monitoring systems for monitoring
premises, often referred to as alarm systems, typically provide a means for detecting
the presence and/or actions of people at the premises and reacting to detected events.
Commonly such systems include sensors to detect the opening and closing of doors and
windows to provide a secure perimeter to the premises, creating one or more protected
interior spaces, movement detectors to monitor spaces (both within and outside buildings)
for signs of movement, microphones to detect sounds such as breaking glass, and image
sensors to capture still or moving images of monitored zones, and optionally smoke
and/or fire detectors. Such systems may be self-contained, with alarm indicators such
as sirens and flashing lights that may be activated in the event of an alarm condition
being detected. Such installations typically include a control unit (which may also
be termed a central unit), generally mains powered, that is coupled to the sensors,
detectors, cameras, etc. ("nodes"), and which processes received notifications and
determines a response. The central unit may be linked to the various nodes by wires,
but increasingly is instead linked wirelessly, rather than by wires, since this facilitates
installation and may also provide some safeguards against sensors/detectors effectively
being disabled by disconnecting them from the central unit. Similarly, for ease of
installation and to improve security, the nodes of such systems typically include
an autonomous power source, such as a battery power supply, rather than being mains
powered.
[0003] As an alternative to self-contained systems, a security monitoring system may include
an installation at a premises, domestic or commercial, that is linked to a remote
Central Monitoring Station (CMS) or Alarm Receiving Centre (ARC) (the terms are interchangeable)
where, typically, human operators manage the responses required by different alarm
and notification types. In such centrally monitored systems the central unit at the
premises installation typically processes notifications received from the nodes in
the installation and notifies the Central Monitoring Station of only some of these,
depending upon the settings of the system and the nature of the detected events. In
such a configuration, the central unit at the installation is effectively acting as
a gateway between the nodes and the Central Monitoring Station. Again, in such installations
the central unit may be linked by wires, or wirelessly, to the various nodes of the
installation, and these nodes will typically be battery rather than mains powered.
[0004] In such centrally monitored systems, the personnel of the CMS may raise an alarm
with the police or other emergency services (such as a Fire Brigade, or a medical
service) in the event that an alarm notification is received from the monitored premises.
But frequently penalties (e.g. significant fines or other sanctions) are applied if
a provider of a managed alarm service raises with the emergency service an alarm (or
more than a certain number of alarms within a predetermined period) where the alarm(s)
turn out to be false alarms. Under certain circumstances a service provider may even
be prohibited from reporting alarm events at all. Consequently, service providers
try to ensure that alarm events are only notified to the emergency services once they
have been confirmed in some way - for example by performing a visual check of feeds
from cameras installed at the premises, or by listening to sounds (e.g. sounds characteristic
of a burglar ransacking premises following the triggering of a door or window sensor,
the sounds of an argument, altercation or fight, after the triggering of an SOS or
personal alarm sender, etc.), or by contacting someone (for example by telephone)
associated with the premises, e.g. the owner, to confirm whether or not an alarm has
been triggered accidentally - as is often the case.
[0005] Such security monitoring systems contribute to the safety and wellbeing of occupants
of the protected premises, as well as safeguarding articles within the protected perimeter
- which may of course not simply be limited to a house or dwelling but may also extend
to the grounds of the house, protected by a boundary fence and gate, for example.
[0006] Generally, a centrally monitored security monitoring system only reports alarm events
if the system is armed - with the possible exceptions of fire and smoke detection,
SOS alerts or the triggering of a personal alarm of the type worn or carried by the
elderly or infirm.
[0007] Embodiments of the present invention seek to provide enhanced security monitoring
systems, and corresponding applications, methods and other implementations that improve
the ability of security monitoring systems for handling potential alarm events that
are detected while a premises security monitoring system is in an armed mode, as well
as providing corresponding new functionality and methods.
Summary
[0008] According to a first aspect there is provided a method, performed by a system that
comprises a security monitoring installation at premises protected by the installation
and optionally a system back end remote from the premises, the security monitoring
installation having a plurality of arm states, the plurality of armed states including
a disarmed state and at least one armed state, and being configured to report alarm
events to a monitoring station remote from the premises, the method comprising, in
an armed state:
- i) detecting the occurrence of an event at the premises; and
- ii) transmitting a notification in respect of the event to a user device, the notification
including event data, and optionally context information.
[0009] In some embodiments, the method comprises at least one, optionally any two, optionally
all three of the following steps (iii), (iv) and (v):
iii) in response to receiving a user reaction to the notification indicating that
the event is a false alarm or that the user does not wish to report the event to the
monitoring station, determining (a) not to notify the monitoring station of an alarm
event in respect of the event, and/or (b) to deescalate notification of the monitoring
station;
iv) in response to receiving a user reaction to the notification indicating a desire
to raise an alert in respect of the event with the monitoring station, (a) notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data (and optionally also the context information), and/or (b)
escalating notification of the monitoring station; and v) in response to not receiving
within a predetermined time period a user reaction to the notification, notifying
the monitoring station of an alarm event (in respect of the event) and providing the
monitoring station with access to the event data, and optionally also the context
information.
[0010] Optionally, step (v) may include notifying the monitoring station of an absence of
user reaction.
[0011] Methods according to the first aspect may further comprise the step of reporting
the occurrence of the event to a system back end remote from the premises, wherein
the system back end performs any of steps iii) to v).
[0012] In methods according to the first aspect, the step of transmitting a notification
in respect of the event to a user device may be performed by the security monitoring
installation, wherein the security monitoring installation performs any of steps iii)
to v),
optionally wherein the installation comprises a controller, and the step of transmitting
a notification in respect of the event to a user device is performed by the controller,
and wherein the controller performs any of steps iii) to v).
[0013] In methods according to the first aspect, the notification in respect of the event
may include at least one of:
an image related to the event, and optionally wherein the image is a still image;
and/or
a link giving access to a video capture related to the event.
[0014] In methods according to the first aspect, the event may be at least one selected
from:
sensor based detection of motion;
sensor based detection of presence;
triggering of a window sensor, optionally a contact switch, magnetic sensor, or a
shock sensor;
triggering of a door sensor, optionally a contact switch, magnetic sensor, or a shock
sensor.
[0015] In methods according to the first aspect, whether the notification of step ii) is
transmitted or not may depend upon at least one condition selected from: the time
of day, day of the week, date, nature of the event, or some combination thereof.
[0016] In methods according to the first aspect, the notification may further include context
information, the context information distinct from the event data and complementing
the event data, optionally wherein the context information includes one or more selected
from: the arm state; occupation state of the premises; camera identity; status of
other detectors at the premises.
[0017] In methods according to the first aspect, the armed state may be an armed away state.
[0018] The invention provides several advantages. For example, by soliciting a reaction
from the user when an alarm event occurs, the invention can enable additional information
about the alarm event to be obtained to assist discriminating between alarm events
that need to be acted on at the monitoring station, and alarm events that are accidental
or false. This can reduce the burden at the monitoring station in handling false alarms,
and also enable the monitoring station to react more quickly when there is additional
confidence that the alarm event is a true alarm event.
[0019] By providing an option to signal an alarm event even if the user does not react within
a predetermined time, alarm events are not missed at the monitoring station when the
user is not able to receive or reply to the notification. In other words, the monitoring
station can receive and treat the alarm event generated during the armed state, without
the reaction of the user to the notification.
[0020] In some embodiments, the reaction of the user to the notification is used to determine
whether or not to notify the monitoring station of the alarm event. Additionally or
alternatively, the reaction of the user may be used to escalate or deescalate the
alarm event at the monitoring station. The term "escalating" may refer to prioritising
an alarm event by the monitoring station, for example, due to the response of the
user providing increased confidence that the alarm is not a false alarm. The term
"deescalating" may refer to deprioritising the alarm event by the monitoring station,
for example, due to the response of the user providing increased confidence that the
alarm event is an accidental or false alarm. The term "deescalating" may also include
cancelling the alarm event at the monitoring station.
[0021] In devising the present invention, it has been appreciated that detectors or nodes
(e.g. intrusion detectors and/or movement detectors and/or cameras) monitoring exterior
space in the grounds of the house or premises (so-called exterior nodes or exterior
detectors) are especially vulnerable to generating false alarms, because they can
be subjected to a greater range of natural variation in the environment, for example,
movement caused by animals, by weather, by leaves, trees and plants moving in the
wind, by shadows, sunlight or other lighting conditions, by temperature variations,
or by people entering the grounds without mal-intent. The invention, in its various
aspects, can be especially advantageous in enhancing the versatility of the system
to accommodate external detectors, while mitigating the accompanying difficulty of
false alarms.
[0022] According to a second aspect there is provided a system that comprises a security
monitoring installation at premises protected by the installation and a system back
end remote from the premises, the security monitoring installation having a controller
and a plurality of sensors configured to transmit event notifications to the controller,
the controller being configured to report alarm events to a monitoring station remote
from the premises, the controller having at least one operating mode in which it is
configured to respond to receiving certain event notifications by transmitting an
alert, in respect of the event notification, to the system back end remote from the
premises,
the system back end being configured to:
- i) transmit a notification in respect of the event to a user device, the notification
including event data, and optionally context information.
[0023] In some embodiments, the system back end is further configured to perform at least
one, optionally any two, optionally all three of the following steps (ii), (iii) and
(iv):
ii) in response to receiving a user reaction to the notification indicating that the
event is a false alarm or that the user does not wish to report the event to the monitoring
station, determining (a) not to notify the monitoring station of an alarm event in
respect of the event, and/or (b) to deescalate notification of the monitoring station;
iii) in response to receiving a user reaction to the notification indicating a desire
to raise an alert in respect of the event with the monitoring station, (a) notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data (and optionally also to the context information), and/or
(b) escalating notification of the monitoring station; and iv) in response to not
receiving within a predetermined time period a user reaction to the notification,
notifying the monitoring station of an alarm event (in respect of the event) and providing
the monitoring station with access to the event data, and optionally also the context
information.
[0024] Optionally, step (iv) may include notifying the monitoring station of an absence
of user reaction.
[0025] According to a third aspect there is provided a security monitoring installation
at premises protected by the installation, the installation comprising a controller
and a plurality of sensors configured to transmit event notifications to the controller,
the controller having at least one operating mode in which it is configured to respond
to certain event notifications by:
- i) transmitting a notification in respect of the event to a user device, the notification
including event data, and optionally context information.
[0026] In some embodiments, the controller is further configured to perform at least one,
optionally any two, optionally all three of the following steps (ii), (iii) and (iv):
ii) in response to receiving a user reaction to the notification indicating that the
event is a false alarm or that the user does not wish to report the event to the monitoring
station, determining (a) not to notify the monitoring station of an alarm event in
respect of the event, and/or (b) to deescalate notification of the monitoring station;
iii) in response to receiving a user reaction to the notification indicating a desire
to raise an alert in respect of the event with the monitoring station, (a) notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data (and optionally to context information), and/or (b) escalating
notification of the monitoring station; and
iv) in response to not receiving within a predetermined time period a user reaction
to the notification, notifying the monitoring station of an alarm event (in respect
of the event) and providing the monitoring station with access to the event data,
and optionally also the context information.
[0027] Optionally, step (iv) may include notifying the monitoring station of an absence
of user reaction.
Brief description of Figures
[0028] Embodiments of the invention will now be described, by way of example only, with
reference to the accompanying Figures, in which:
Figure 1 is a schematic view of the front of a premises 100 protected by a security
monitoring installation according to an aspect of the present invention;
Figure 2 is a schematic plan view of the premises of Figure 1 illustrating elements
of the installation and a system of which it forms part;
Figure 3A illustrates schematically, at a high level, a method according to an aspect
of the invention;
Figure 3B illustrates schematically, at a high level, another method according to
an aspect of the invention;
Figure 4 is a flow chart illustrating a method according to an aspect of the invention;
Figure 5 illustrates schematically, at a high level, another method according to an
aspect of the invention;
Figure 6 illustrates schematically, at a high level, another method according to an
aspect of the invention; and
Figure 7 is a flow chart illustrating a method according to an aspect of the invention.
Specific description
[0029] Figure 1 shows a view of the front of a premises 100 protected by a security monitoring
system according to an aspect of the present invention. The premises, here is in the
form of a house, surrounded by a garden defined in part by a border fence 101 to the
rear and sides of the property. The house has at least one exterior door, here front
door, 102. The door gives access to a protected interior space. The security monitoring
system secures at least part of a perimeter to the premises 100, and the door constitutes
an exterior closure 102 in the secure perimeter giving access to a protected interior
space 201 of the premises. A lock 104 on the exterior door is optionally electrically
controlled so that it can be locked and unlocked remotely.
[0030] To the side of the door, on the facade of the house, is a first video camera in the
form of a video doorbell 106 which looks out from the facade of the premises so that
anyone approaching the door along the path 108 can be seen, and in particular when
a visitor stands at the door their face should clearly be visible. The video doorbell
includes an actuator, e.g., a push button, for a visitor to indicate their presence
at the door. The video doorbell also includes an audio interface to enable bidirectional
audio communication with a visitor at the door 102.
[0031] The video doorbell preferably includes an infrared light source to illuminate whatever
or whoever is in front of the video doorbell. Optionally, as shown, the facade of
the house also carries an external keypad, or access node, 110 by means of which a
user can disarm the security monitoring system, and unlock the lock 104 if fitted,
by entering an access code or by presenting a security tag, dongle, or suitably coded
mobile device - for example using NFC. Also shown is an optional second video camera
112 which is coupled to a presence and/or movement detector 114 that may be integral
with the camera 112. The detector may optionally be a thermal detector, for example
a PIR sensor. The second video camera 112 may be arranged to capture video of the
front of the house and the private area, e.g., the garden, in front of the house and
to signal events to a controller of the security monitoring system. As with the doorbell
camera, the second video camera is preferably provided with an audio interface 116
to enable bidirectional audio communication with anyone observed by the second video
camera. Although the first video camera is illustrated in the form of a video doorbell,
the first video camera may additionally or alternatively have the features described
above for the second video camera, whether or not plural video cameras are used. A
further video camera may also be provided to the rear and or side of the house to
capture video of the side and/or rear of the house and the private area, e.g. the
garden, to the side or rear of the house and to signal events to a controller of the
security monitoring system. As with the second video camera the further video camera
is preferably provided with an audio interface 116 to enable bidirectional audio communication
with anyone observed by the further video camera.
[0032] Figure 2 is a schematic part plan view of a premises 100 protected by security monitoring
system according to an aspect of the invention, together with other elements of the
system, corresponding generally to the premises of figure 1. The front door 102, with
the optional electrically controlled lock 104, leads into an entrance hall 200 that
is part of the protected interior space of the premises which also includes a study
or home office 201. Each of the windows 202, and external doors (including rear door
204) is fitted with a sensor 206 (e.g., a contact switch, which may include an accelerometer
to provide shock detection) to detect when the door is opened. Each of the sensors
206 preferably includes a radio transceiver to report events to a controller, or central
unit, 208 of the security monitoring system. If one of the sensors 206 is triggered
a signal is sent to the central unit 208 which in turn may (typically depending upon
that arm state of the security monitoring system) signal an alarm event to a remote
central monitoring station 210. The central unit 208 is preferably connected to the
remote central monitoring station 210 via the Internet 211, via a wired or a wireless
connection, or both.
[0033] The security monitoring installation at the premises is also coupled to a remote
system back end 230 (typically comprising one or more servers with associated memory,
programs and data storage) which may be functionally separate from the central monitoring
station 210 or they may form part of a common back end function 240 - although of
course whether or not the back end function and the central monitoring station form
a common back end function, their hardware may be co-located or located at different
geographical sites, and the human operators may be co-located with the relevant system
hardware or access it through terminals that are themselves remote from the relevant
hardware. The system back end and the central monitoring station support plural security
monitoring installations all typically remote from both the system back end and the
central monitoring station. The central monitoring station 210 is able to call upon
the emergency services (e.g., police, fire brigade, medical) 250.
[0034] Also coupled (optionally wirelessly) to the central unit 208 are the video doorbell
106, the electrically controlled lock 104 (if present), and also if present the second
video camera 112 and the rear video camera 212, and its/their associated presence
and/or movement detectors 114 (although the latter may be integral with the relevant
video camera 112/212) and the audio interface(s) 116. A control panel 227 may also
be provided, for example within the protected space of the premises, for the arming
and disarming of the security monitoring system. These items, and the sensors 206,
are preferably coupled to the central unit 208 using transceivers operating in the
industrial scientific and medical (ISM) bandwidths, for example a sub-gigahertz bandwidth
such as 868 MHz, and the communications are encrypted preferably using shared secret
keys. The security monitoring system may also include other sensors within the protected
interior space, such as an interior video camera 214 and associated movement detector
216 (which again may be integral with the camera 214), and each of the interior doors
218 may also be provided with a sensor 206 to detect the opening/closing of the door.
One or more fire and/or smoke detector nodes 252 may also be provided within the protected
premises. Also shown in figure 2 are a user device 220 (such as a smartphone), preferably
loaded with an appropriate app - as will be described later, and a public land mobile
network (PLMN) 222 by means of which the central monitoring station 210, and the central
unit 208, may communicate with the user device 220.
[0035] The study 201, like the rest of the rooms in the protected premises, may include
a stand-alone motion sensor, such as a PIR, 216' to detect presence or motion within
the room. The motion sensor may be a "smart" motion sensor such as one that uses artificial
intelligence to help distinguish between the presence of an animal, such as a pet
dog or pet cat, and a human. Such sensors can distinguish reliably between movement
of a pet animal and movement of a human who crawls along the floor, for example, and
can readily distinguish between a standing or crouching human and a pet animal. As
such, such smart motion/presence sensors can contribute significantly to a reduction
in the incidence of false alarms. The study 201 may also include a camera, optionally
a video camera, 214' which may include or be associated with a smart motion/presence
sensing detector.
[0036] In some embodiments, rather than using a motion/presence detector to trigger a camera
of the installation, one or more cameras of the installation may be configured to
capture images continuously or quasi continuously, the captured images then being
shared with an image analysis system or arrangement that detects the existence of
motion by analysing differences between images taken at different times. The image
analysis system or arrangement being arranged to provide a "motion detected" signal,
for example to a controller of the installation, so that the detection of motion can
be used as a trigger for further action. Examples of such an approach are described
further with reference to figures 7 and 8.
[0037] In various embodiments operation of the security monitoring system may be controlled
by one or more of: the controller 208, the control panel 227, the remote monitoring
station 210, and a security monitoring app installed on the user device 220. For example,
the remote monitoring station 210, may receive one or more signals from any of the
first camera and/or video doorbell 106, the second camera 112/212, the keypad 110,
and the sensors 206,252. The remote monitoring station 210 may transmit commands for
controlling any one or more of: the arm state of the alarm system (e.g. armed or unarmed);
commanding a tripped alarm state to be signalled by the alarm system (e.g. by triggering
one or more sirens to generate alarm noise); commanding a lock state of the door lock
104 (e.g. locked or unlocked), commanding operation of one or more functions of the
video doorbell 106, commanding operation of one or more cameras to transmit images
to the remote monitoring unit. Communication with the remote monitoring station 210
may pass through the controller 208, as described above. In yet other embodiments,
the controller 208 may be omitted, and the individual peripheral devices may communicate
directly with the system back end 230/240 and, as appropriate with the remote monitoring
station 210. For example, the security monitoring installation may be configured without
a central unit 208, the various nodes/sensors/cameras of the installation instead
working on an edge computing basis, either each communicating directly with the system
back end 230, or common back end function 240 (or at least having the inbuilt capability
to do this) and, as appropriate with the remote monitoring station 210, or one or
more of the nodes/sensors/cameras/control panels may act as a gateway and controller
for the other nodes/sensors/cameras/control panels. Optionally at least the nodes/sensors/cameras/control
panels that act(s) as the gateway may be powered from a mains power source (with battery
backup). The nodes/sensors/cameras/control panels may form a self-organising system.
[0038] The security monitoring system may further comprise an audio interface to enable
audio communication with a visitor at the closure 102, or at or within sight of any
of the image capture devices (e.g., cameras or video cameras) of the installation,
the controller 208 being configured to enable the remote monitoring centre 210 to
use the audio interface to speak to the visitor (who may be a potential intruder).
Likewise, the control panel 227 may include an audio interface to enable audio communication
with the central monitoring station and optionally the user device (for example via
the system back end 230/240).
[0039] The security monitoring system app is installed on a user device 220, here shown
as a smartphone, although of course it could be almost any kind of electronic device,
such as a laptop or desktop computer, a tablet such as an iPad, a smart watch, or
even a television.
[0040] The inventors have realised that under some circumstances while a security monitoring
installation is armed (either or both of armed away and armed at home) it can be helpful
to check, with a user of the installation, whether a potential alarm event detected
by a sensor of the installation should in fact be treated as an alarm event or not,
before the event is reported to the remote monitoring station. Events that the user
confirms to be alarm events may be given a higher priority (e.g., joining a high priority
feed or being flagged for (more) immediate handling), while those that the user identifies
as non-alarm events may be discarded without being reported to the remote monitoring
station. Such user feedback may also be used as an element of a machine learning system
run on the system controller 208 or at the system backend 230. Some high priority
event types may be treated in the conventional way with an alert being raised with
the remote monitoring centre immediately, only certain event types using this pre-reporting
notification. For example, events reported by personal SOS alarms of the type carried
by the elderly may be notified to the remote monitoring station 210 immediately (e.g.
via the controller 208 if the system includes sone), personnel of the monitoring station
210 then typically attempting to start a dialogue with the user of the relevant SOS
device (and typically such reporting is agnostic to the arm state of the security
monitoring system).
[0041] Conversely, alerts triggered by events detected in the grounds of protected premises,
e.g., in a secluded back garden, may in both armed at home and armed away modes be
subject to user pre-qualification - although this may depend upon the nature of the
alert, the characteristics of the outside space, and the situation and concerns of
the user. For example, detection of motion in a back garden may be a frequent occurrence
in a garden with luxurious plant growth, whereas a bare concrete back yard is likely
to experience detectable motion much less frequently. The concrete yard may also have
such a secure perimeter that animal intrusion is very rare, whereas the heavily vegetated
garden may host foxes, badgers, deer, and/or roaming pets. By using an intelligent
motion sensor (such as a "smart" PIR or radar sensing arrangement) it may be possible
to discriminate to a high degree of certainty between human and animal presence, so
that only suspected human presence constitutes a notifiable event. But even with the
ability to discriminate between human and animal presence, different installations
may warrant different treatment - for example it may be that at a property adjacent
the protected premises their live children who like to play with balls (e.g. a football
or tennis balls), and it may be that the ball(s) periodically find their way across
the boundary between the two adjacent properties, with the result that the children
periodically come to retrieve their balls. The owner of the protected premises does
not want such incursions treated as alarm events, because the events are harmless,
and the children are well behaved and respectful. It will be appreciated that this
scenario is representative of many other scenarios in which third parties may appear
in the back garden of the protected premises with no risk to the premises and no threat
to anyone else in or at the premises. It would be beneficial if a method could be
devised for dealing with such events, so that false alarms could be avoided while
still allowing real villains to be caught as the result of triggering a sensor or
camera. Conversely in a more industrial setting there may be very limited likelihood
of innocent human incursion into a protected outside area - and in this situation
the security monitoring installation may be configured in armed modes to treat any
human incursion into the protected exterior space as an alarm event for which no user
check should be performed before reporting the event to the remote monitoring station.
[0042] The handling of other potential alarm events may also, under some circumstances,
benefit from the introduction of a user notification before an event is reported to
the remote monitoring station, so that the user is given an opportunity either to
prevent the event being reported or to confirm that the event should be treated as
an alarm event, potentially enabling the event to be flagged as high(er) priority
and hence potentially facilitating quicker response while reducing the incidence of
false alarms (which at the very least needlessly consume the time and attention of
the personnel of the remote monitoring centre 210).
[0043] This method in various guises will now be explained further with reference to the
remaining figures.
[0044] Figure 3A illustrates schematically, at a high level, a method according to an aspect
of the invention. Here we assume that the premises installation 200, which may correspond
to the installation described with reference to Figures 1 and 2, is in an armed away
or armed at home state. At 300 an event is detected by a sensor or node of the installation,
for example a motion sensor associated with a camera, such as camera 212, overlooking
the back garden is triggered.
[0045] If the installation includes a central unit, such as central unit 208, the triggered
sensor will send an event alert message to the central unit, and the central unit
will then process the alert message at 302. The event alert message/report preferably
includes parameters of the event, the sensor's identity and if relevant the nature
of the event detected. For example, camera 212 may be arranged to capture an image
(e.g., a still image or a brief video clip) upon its associated (possibly internal)
motion sensor being triggered, and then to send an event alert, optionally including
the captured image, to the central unit. Based on the prevailing system settings the
central unit determines that a user is to be notified of the event. Based on this
determination, the central unit then reports to the back-end system 230/240 the occurrence
of an event at the premises 100.
[0046] If the installation is configured without a central unit, a processor of the triggered
sensor will at step 302 process the event data to determine how it should be handled.
Based on the prevailing system settings the processor may determine that a user is
to be notified of the event. Based on this determination, at step 304 the sensor's
processor then reports to the back-end system 230/240 the occurrence of an event at
the premises 100, for example using a PLMN. The event alert message/report preferably
includes parameters of the event, the sensor's identity and if relevant the nature
of the event detected. Again, if the sensor is a camera, such as camera 212, it may
be arranged to capture an image upon its associated (possibly internal) motion sensor
being triggered, and then to send an event alert, optionally including the captured
image, to the back-end system 230/240.
[0047] At step 305 the back-end system 230/240 processes the alert, determining the nature
of the alert and identifying the installation from which the report was received,
and based upon this identification determines relevant user contact details (such
as SIP address, mobile device number, etc.) to be used for any user contact.
[0048] At step 306 the back-end system 230/240 transmits parameters of the event to a user
device 220, for example in the form of a push notification. The parameters transmitted
at this stage may be the same as those received from the installation 200, for example
if the received parameters comprise an image file or video clip, the image file or
video clip (optionally including both sound and visual components) is forwarded to
the user device. Optionally, received image/video content may be labelled or tagged
to identify the precise source of the image/video capture. Additional or alternative
parameters may be transmitted to the user device, for example a textual or graphical
message may be composed to inform the user of the type of sensor (e.g. door or window
sensor, shock sensor, smoke detector, fire detector, motion detector) and/or its location
(e.g. door or window name, room name or other location descriptor), and the nature
of the event detected (e.g. tamper detected, door/window opened, door/window shock
sensed, smoke detected, fire detected, sound detected, etc.). A graphical display
format may be used to facilitate comprehension both of the location of the event (e.g.
by including an outline map to indicate the location of the detected event with respect
to an outline or plan of the protected premises, and/or by labelling the display with
a name of the location) and the nature (motion detection, person detection, door/window
sensor (+ type) triggered) and/or severity of the event.
[0049] At step 308 the parameters received at the user device are displayed on a display
of the device 220. The user device 220 will typically host an app for the security
monitoring system, to enable the user to view communications from the system back-end
230/240, images/video from cameras at the installation (e.g., from a doorbell camera
of the installation) and also optionally to enable a user to speak to someone at the
video doorbell, or at other nodes of the installation.
[0050] The parameters are preferably sent in a push notification that will display on lock-screen
or at least give rise to a user alert on the device to prompt the user to view the
notification. The notification may be an action notification that includes, for example,
an action button or that permits a user to respond by clicking or "pushing" (e.g.,
using "force touch" on an Apple brand device, or the equivalent on other devices)
on the notification as a way to enter a response. Where the received parameters include
a video clip or image, the user may be able to indicate a part of the image - e.g.
a person or a person's face, by "drawing" (i.e. annotating) on the display using a
finger, finger nail, or stylus, for example, to enable the user to identity a person
(or some other thing) - e.g. to indicate someone whose presence is unauthorised or
otherwise problematic, so that personnel at the central monitoring station can take
appropriate action. Alternatively, the notification may include an icon or button
for the user to indicate that there is no cause for alarm (e.g., an "all OK" button)
and/or another icon or button to indicate that the event should be treated as an alarm
event and notified to the remote monitoring centre 210.
[0051] Optionally, the app may be configured to communicate with the system backend 230/240
to inform the backend that the notification has been displayed. If the user does not
respond within a predetermined time period, the event is escalated to the remote monitoring
station. The notification may include an option for the user to respond to indicate
the absence of any perceived threat/risk, in which case, at step 312 the user response
is transmitted to the system backend 230/240. Again, there is no escalation of the
event to the remote monitoring station.
[0052] Conversely, if the user's response at 310 indicates that the user is concerned/threatened
or worried by the reported event, at step 314 the system back end notifies the remote
monitoring centre 210 - signifying the user's concern. The remote monitoring centre
210 is also provided with access to the parameters of the event, together with any
annotations or other input received from the user. The parameters may be transmitted
to the remote monitoring centre 210 by the system back end 230, or they may be made
available in some other way - for example by being shared within the back end system
240, or a link provided to the remote monitoring centre 201 by means of which the
parameters (such as any image capture or video content) may be downloaded or otherwise
accessed by the remote monitoring centre 210. As mentioned previously, the alert sent
to the remote monitoring station may be flagged to raise the priority of the event
compared to other events that have not been "pre-qualified" in this way.
[0053] The personnel in the remote monitoring centre 210 upon receiving notification of
the event are made aware that a user was alarmed by the details of the event (i.e.
that this is a higher priority alert), based on the event context (e.g. the fact that
the event occurred when children were home alone, and possibly the time of day) and
the event data made available to the user (for example any image capture, video capture,
audio, etc.). This higher priority ranking may justify an earlier involvement of the
police or other security personnel.
[0054] The monitoring personnel are also able to review the event details and are further
able to communicate with the monitoring installation, for example to request 316 access
to further images or video from the relevant camera and also from any other cameras
of the installation, and also to acquire audio from any microphones of the installation
- all either via a central unit of the installation or directly with the relevant
nodes if the installation does not include a central unit. Any requested captures
or streams are provided by the installation to the remote monitoring centre 210 at
step 318.
[0055] In this way, personnel in the remote monitoring centre 210 may for example be able
to communicate orally with any intruder in the garden, for example by an audio interface
in camera 212, hopefully to persuade them to leave the grounds of the premises, or
the personnel may assess the situation and may report the incident to the emergency
services or private security personnel if their involvement is required. Meanwhile,
the personnel may liaise with the user via the user device, and optionally with those
within the protected premises - for example via an audio interface in a control panel
227 of the installation.
[0056] Figure 3B corresponds generally to Figure 3A but illustrates a method in which the
premises installation 200 is able to send notifications directly to the user device
220 rather than only via the system back end as in Figure 3A. Here we assume the same
scenario as for Figure 3A. That is, we assume that the premises installation 200,
which may correspond to the installation described with reference to Figures 1 and
2, is in an armed away or armed at home state. At 320 an event is detected by a sensor
or node of the installation, for example a motion sensor associated with a camera,
such as camera 212, overlooking the back garden is triggered.
[0057] If the installation includes a central unit, such as central unit 208, the triggered
sensor will send an event alert message to the central unit, and the central unit
will then process the alert message at 322. The event alert message/report preferably
includes parameters of the event, the sensor's identity and if relevant the nature
of the event detected. For example, camera 212 may be arranged to capture an image
(e.g., a still image or a brief video clip) upon its associated (possibly internal)
motion sensor being triggered, and then to send an event alert, optionally including
the captured image, to the central unit. Based on the prevailing system settings the
central unit determines that despite the arm state of the installation being disarmed,
or merely armed at home, a user is to be notified of the event. Based on this determination,
the central unit prepares a notification to report the event and its context to a
user device whose contact details (e.g., SIP address or mobile phone number) may be
stored in the central unit. Using these contact details, the central unit pushes a
notification to the user device at step 324.
[0058] If the installation is configured without a central unit, a processor of the triggered
sensor will at step 322 process the event data to determine how it should be handled.
Based on the prevailing system settings the processor may determine that a user is
to be notified of the event. Based on this determination, at step 324 the sensor's
processor then prepares a notification to report the event and its context to a user
device whose details may be stored in the relevant sensor, for example using a PLMN.
The event alert notification preferably includes parameters of the event, the sensor's
identity and if relevant the nature of the event detected. Again, if the sensor is
a camera, such as camera 212, it may be arranged to capture an image upon its associated
(possibly internal) motion sensor being triggered, and then to send a notification,
optionally including the captured image, to the relevant user device 220.
[0059] The display of the notification on the display of the user device, at step 326, and
the following steps 328 to 336 correspond generally to steps 310 to 318 of Figure
3A and the above description of these applies equally in respect of Figure 3B.
[0060] Figure 4 illustrates schematically a method 400 according to an aspect of the invention
in which an event at the premises 100 is captured as an image capture or video.
[0061] At step 402 a security monitoring installation at premises is in an armed state or
in an armed at home state, and an event occurs at the protected premises leading to
an image capture, for example as the result of a motion detector of or associated
with a camera having been triggered. The camera may, for example, be a camera such
as camera 212 having a view of the back garden of the protected premises. Triggering
of the motion sensor results in activation of the associated camera and an image capture
of the event either as one or more still images or in the form of a video sequence.
[0062] At step 404 the camera optionally transmits the captured image to the system backend,
preferably together with status information for the security monitoring installation
such as arm state, occupant details or occupancy status (either in detail, e.g. with
names of those determined to be present, or in terms of the presence of a least one
"vulnerable" individual (e.g. a child or elderly or infirm person_ and the absence
of a carer or responsible adult (e.g. possibly determined by the fact that no such
person has touched in or entered the appropriate passcode or PIN)), and such other
information as may be helpful in terms of giving a user context for the detected event.
For example, these data may be transmitted from the triggered node (e.g., camera)
over a Wi-Fi link to a Wi-Fi router of the premises (or via a lower bandwidth channel
such as an 868MHz channel to a system controller 208) and thence via the Internet
to system backend 230/240.
[0063] Even if the camera is a video camera it may initially just provide a still image
capture. Alternatively, the camera may stream the video so that the back end receives
a continuous or quasi-continuous video stream, or the camera may transmit a subset
of the available video, in the form of one or more still images or video clips. The
capture may also include an audio channel which may also be transmitted to the system
backend 230/240. The transmission(s) to the system backend 230/240 includes an identifier
of some kind so that the backend knows from which security monitoring installation
(and hence which premises) the event capture is being received. The system backend
includes for example a database that maps installations/premises with a user identity.
For each user identity the system backend preferably also stores contact details,
including for example a SIP address, device phone number, other contact numbers and
email addresses for each user identity, optionally in the same database that maps
installations/premises with a user identity. On receiving an event capture from a
premises installation, the system back end determines contact details for a user device
to be contacted in case of alarm events. Using the relevant contact details, the system
backend pushes a notification to the relevant device at step 406. The pushed notification
includes the event capture (e.g., the image capture) and/or a link to any video stream,
preferably together with an identifier or indication of the source of the event capture
- e.g., a name assigned to the camera such as "Back Garden Camera", optionally also
with an indication of the time and date of the event capture.
[0064] Following delivery of the push notification to the user device, the user may interact
with the user device to access the notification, causing the event capture (e.g.,
image capture) to be displayed on a display of the user device at step 408. This may
involve the user clicking on (or otherwise selecting) a link to a remote site from
which the video may be downloaded or streamed. The user may then view the image capture
(image or video clip or stream) on the user device to determine whether or not the
notified event raises any cause for concern. If the event doesn't give rise to any
concerns, the user may click on an icon, button or the like to indicate that no issues
arise - the icon or button optionally being labelled with a designation signifying
that no issues arise - e.g. "all OK", "no concerns", "no problem", and/or colour coded
(e.g. colour coded green for safe), causing an appropriate indication to be captured
at step 410.
[0065] Conversely, if the event capture is a cause for alarm, the user may take an action
to indicate that they wish the event to be flagged to the remote monitoring station
210. Such an action may be to interact with an icon or button colour coded red, or
labelled with a designation signifying that there is a problem or that the event notification
causes the user alarm - e.g., "Escalate to ARC", "action required", "I don't like
this", etc. Additionally, or alternatively, the user may be able to indicate concern
by pressing on the display on which the event capture is being displayed. Also, as
previously mentioned, the user may have the option to draw on the image capture (either
in the form of a still or in the form of a video sequence) to draw around a feature
of the displayed image or to add a label or tag, to indicate a person or some other
feature of the displayed image (video) whose presence gives rise to concern - e.g.
to indicate a stranger or a known person whose presence is unwelcome. The drawing,
tagging, or labelling may be captured in the form of a layer or overlay whose details
may be transmitted to the system backend for sharing, by onward transmission or otherwise,
with the remote monitoring centre 210. In the event that a user fails to provide an
active response within a predetermined time period, the detected event will be reported
to the monitoring station as an alarm event. If this mode of providing an indication
of indifference is supported the app in the user device is preferably configured to
signal to the system backend the fact of the event capture having been displayed.
The system backend may then set a timer at the expiry of which, if no active response
has been received, the event will be escalated to the ARC 210.
[0066] At step 412 the system backend determines the user reaction, optionally by receiving
an indication of the perception of a threat or by receiving an indication that the
event gives the user no cause for concern. As already noted, an event is treated as
a cause for concern if no overt response is received from the user within a predetermined
period.
[0067] If it is determined 414 that a reported event does not give the user any cause for
concern, the system back end ends the process at step 415 and does not escalate the
event to the remote monitoring centre 210.
[0068] Conversely, if it is determined that the user is concerned, alarmed, or threatened
by the reported event, the system back end at step 416 may share the event details
and context (e.g., installation status/occupation status, etc) and raises an alert
with the remote monitoring centre. The sharing of event details may involve the system
backend transmitting the event capture (e.g., image capture or video capture) to the
remote monitoring centre, particularly if the system backend 230 and the remote monitoring
centre 210 are not integrated, but as an alternative the backend may simply share
a link with the remote monitoring centre 210. If the system backend 230 and the remote
monitoring centre 210 are integrated, the system may be so arranged that the remote
monitoring centre 210 is able to access any image (e.g. video) capture for which it
receives a relevant identifier - so that the system backend, by raising an escalation
event (which will typically include a unique identifier and/or an identifier for the
premises installation together with a timestamp) with the remote monitoring centre
210 also makes available the corresponding event parameters (e.g. video capture or
video stream) and context.
[0069] At step 418 personnel at the remote monitoring centre 210 review the event, based
on the knowledge that the user is concerned by what they saw in the event capture
(e.g., image capture or video) so that the event is treated as a high(er) priority
event. The personnel than make any necessary escalation to emergency services, or
call in private security personnel as required. The remote monitoring centre 210 preferably
has the ability to command the central unit 208 of the installation to activate other
cameras, microphones, speakers, etc., so that its personnel can obtain a fuller picture
of the situation at the protected premises - enabling the personnel to make better
informed decisions about escalating an event to the emergency services. In this way
the incidence of an event being escalated to the emergency services as the result
of a false alarm is likely to be reduced.
[0070] Figure 5 illustrates schematically, at a high level, another method 500 according
to an aspect of the invention. In this case we consider the role of a security monitoring
installation controller, such as the device 208 shown in Figure 2. When we considered
the method illustrated in Figure 3, the security monitoring installation was treated
as an entity without further consideration of interaction between elements of the
installation. The nodes of the security monitoring installation may be configured
as IoT terminals which communicate with each other and with the system backend, the
installation being configured without a local control unit such as 208. But we will
now consider a method performed in a system in which the installation does include
a local control unit to which the installation nodes report, and which in turn reports
to the system backend and the central monitoring station (if these are separate).
As before, the system back end 230 and the alarm receiving centre (central monitoring
station 210) may be separate entities, or they may each form part of an integrated
whole 240 within which event data and parameters received by the system back end 240
may be made available to the central monitoring station 210 without the need for an
explicit transmission step.
[0071] At step 502 a node of the security monitoring installation is triggered. This may
happen irrespective of the arm state of the installation. Generally, the nodes of
a security monitoring installation that includes a central unit such as 208 are unaware
of the arm state of the installation. The node may for example be a video camera with
an associated motion sensor (e.g. an internal or external PIR or radar sensor) such
as camera 112, 212, 214, a door or window contact sensor such as 206, a shock sensor
mounted on a window or door, a fire or smoke sensor 252, a keypad 110 or control panel
227, a movement detector 216, a video doorbell 106, a microphone, or some other device.
[0072] At step 504 the triggered node sends an alert message to the local control unit 208
over a wired or wireless interface. At step 506 the control unit 208 processes the
received alert (the event details) based on the identity of the node reporting the
event, the nature of the reported event (e.g. the magnitude of a shock reported by
a shock sensor, the type and details of an interaction with a disarm node or control
panel, etc.) stored rules that dictate the circumstances under which alerts are to
be shared with a user device for "pre-alarm consideration" and which not, and optionally
the time (hour, date, day) and the arm state of the installation (the same or similar
factors may of course be taken into account by the system back end when performing
the methods of Figures 3 and 4).
[0073] At step 508 the control unit 208 transmits event parameters to the system back end
230/240. In the case that the event has given rise to an image capture, the event
parameters include the image capture and control unit 208 may start to stream video
from the relevant camera (if it is a video camera) to the system backend 230/240.
If the event has not given rise to an image capture, the event parameters may include
the identity of the node that has been triggered, the nature and optionally magnitude
of the event detected, optionally the arm state of the alarm, and such other details
(such as occupancy status) as may be appropriate.
[0074] At step 509 the system backend 230/240 processes the information received from the
control unit of the installation. The transmission to the system backend 230/240 includes
an identifier of some kind so that the backend knows from which security monitoring
installation (and hence which premises) the event capture is being received. The system
backend includes a database that maps installations/premises with a user identity.
For each user identity the system backend also stores contact details, including for
example SIP addresses, device phone numbers, other contact numbers and email addresses
for each user identity, optionally in the same database that maps installations/premises
with a user identity. On receiving an event capture from a premises installation,
the system back end determines contact details for a user device to be contacted in
case of alarm events. Using the relevant contact details, the system backend pushes
a notification to the relevant device at step 510. The pushed notification includes
the event parameters. If the event capture includes an image capture, the notification
may include the captured image, a video clip or a link to the video stream, preferably
together with an identifier or indication of the source of the video capture - e.g.
a name assigned to the camera such as "Back Garden Camera", optionally also with an
indication of the time and date of the capture, together with relevant context information
(such as arm state and occupancy status).
[0075] Following delivery of the push notification to the user device 220, the user interacts
with the user device to access the notification, causing the video capture to be displayed
on a display of the user device at step 512. This may involve the user clicking on
(or otherwise selecting) a link to a remote site from which a video may be downloaded
or streamed. The user then views the event capture (image, video clip or stream) on
the user device to determine whether or not the event capture raises any cause for
concern. If the event capture doesn't give rise to any concerns, the user may click
on an icon, button or the like to indicate that no issues arise - the icon or button
optionally being labelled with a designation signifying that no issues arise - e.g.
"all OK", "no concerns", "no problem", and/or colour coded (e.g. colour coded green
for safe), causing an appropriate indication to be captured at step 514.
[0076] Conversely, if the event parameters are a cause for alarm, the user may take an action
to indicate that they wish the event to be flagged to the remote monitoring station
210, with the result that the user device transmits a user response message at step
516. Such an action may be to interact with an icon or button colour coded red, or
labelled with a designation signifying that there is a problem or that the video causes
the user alarm - e.g. "Escalate to ARC", "action required", "I don't like this", etc.
If a user fails to provide an active response within a predetermined period (based
for example on when the notification was transmitted 510 to the user device) the system
back end may be configured to report the event to the remote monitoring centre 210.
Additionally, or alternatively, the user may be able to indicate concern by pressing
on the display on which the event capture is being displayed. Also, as previously
mentioned, the user may have the option to draw on any image or video (e.g. a frame
of the video - generally on an image capture) to draw around a feature of the displayed
image or to add a label or tag, to indicate a person or some other feature of the
displayed image (video) whose presence gives rise to concern - e.g. to indicate a
stranger or a known person whose presence is unwelcome. The drawing, tagging, or labelling
may be captured in the form of a layer or overlay whose details may be transmitted
to the system backend at step 516 for sharing, by onward transmission or otherwise,
with the remote monitoring centre 210.
[0077] At step 518 the system backend determines the user reaction, optionally by receiving
an indication of the perception of a threat or by receiving an indication that the
event gives the user no cause for concern.
[0078] If it is determined that a reported event does not give the user any cause for concern,
the system back end ends the process and does not escalate the event to the remote
monitoring centre 210.
[0079] Conversely, if it is determined that the user is concerned, alarmed, or threatened
by the reported event, the system back end at step 520 shares the event details and
context and raises an alert with the remote monitoring centre, preferably indicating
the fact that the user has been notified of the event and is concerned ( which may
be interpreted as "treat as high(er) priority"). The sharing of event details may
involve the system backend transmitting an image or video capture to the remote monitoring
centre, particularly if the system backend 230 and the remote monitoring centre 210
are not integrated, but as an alternative the backend may simply share a link with
the remote monitoring centre 210. If the system backend 230 and the remote monitoring
centre 210 are integrated, the system may be so arranged that the remote monitoring
centre 210 is able to access any image/video capture for which it receives a relevant
identifier - so that the system backend, by raising an escalation event (which will
typically include a unique identifier and/or an identifier for the premises installation
together with a timestamp) with the remote monitoring centre 210 also makes available
the corresponding event parameters (e.g. image/video capture or video stream).
[0080] At step 522 the remote monitoring centre 210 reviews the event, based on the knowledge
that the user is concerned by what they saw in the event capture in association with
the parameters provided for the captured event, and makes any necessary escalation
to emergency services, or calls in private security personnel as required. The remote
monitoring centre 210 preferably has the ability to command the central unit 208 of
the installation to activate other cameras, microphones, speakers, etc., so that its
personnel can obtain a fuller picture of the situation at the protected premises -
enabling them to make better informed decisions about escalating an event to the emergency
services. In this way it is possible to escalate to the monitoring station an event
occurring while the installation is disarmed or in an armed at home mode while minimising
the incidence of events being escalated to the emergency services as the result of
a false alarm.
[0081] Figures 6 and 7 correspond generally to figure 5 but in this was with off-site motion
detection based on image analysis. Here we assume that a camera such as study camera
214' or back garden camera 212 is arranged to capture 604 images on a continuous or
quasi continuous (e.g., a capture every few seconds) basis. The captured images are
then passed 606 to an image (e.g., video) analysis system 602 for the detection of
movement based on differences between images. The image analysis system 602 may be
internal to the camera (214' or 212), internal to the control unit 208, or provided
by a hardware arrangement that is remote from the installation - optionally part of
the system backend 230 or 240, or provided by some other entity. In Figure 6 we assume
that the image analysis system 602 is located somewhere intermediate the camera and
the system backend - for example either provided by the installation controller 208,
or provided by an off-premises function somewhere.
[0082] At step 608 the image analysis system 602 determines, based on differences between
captured images, that there is movement at the premises. If the image analysis system
is provided by an entity remote from the premises, it will typically be arranged to
provide the result of its analysis to the installation control unit 208 or to the
relevant requesting node if the installation includes no intermediate control unit.
If the image analysis system 602 is provided by the control unit, or if the control
unit receives an output from the image analysis system 602 to the effect that movement
has been detected, the control unit taking account of any stored rules for event handling,
based on arm state of the installation, time of day, day of week etc. and any other
status data as necessary, provides details of the detected event - for example including
an image capture or video clip, etc. together with event parameters, in the form of
a notification for a relevant user device. As described previously, the central unit
may use an internal transceiver to transmit the notification to the user device, e.g.,
over a 4G or 5G PLMN, or it may send the relevant information to the system backend
230/240 for the backend to handle the provision of a notification to the user device.
Figure 6 assumes that latter approach, but it will be understood that the direct approach
may be used in other embodiments of the invention.
[0083] Thus, at step 610 a message is sent to the system backend 230/240, optionally from
a control unit 208 of the installation. The message includes one or more relevant
image captures and/or one or more video clips or a link to an image capture or video
clip(s).
[0084] At step 612 the system backend processes the received message to determine how the
message is to be handled, and in particular if it should be sent to a user device
220, and if so to which one, or direct to the monitoring station 210. Again, the system
backend is able to determine based on the received message the identity of the installation
and also contact details for the relevant user device 220. The various approaches
mentioned previously apply equally here. Based on this determination, the system back
end may send a push notification to the user device 220, the notification including
one or more of the image capture, the video capture, or a link thereto.
[0085] The remainder of the steps illustrated in Figure 6 correspond to those of the comparable
earlier figures.
[0086] Figure 7 is a flow chart illustrating a method 700 in which the detection of motion
based on analysis of repeated images of a scene is a trigger for action. The method
may be performed by a security monitoring installation in a domestic setting, such
as at a home as illustrated in Figures 1 and 2, or in a commercial setting such as
a retail outlet (e.g., a restaurant or shop) or at some other kind of business, such
as at an office. The security monitoring installation may be in a fully armed state
or "armed at home" state. The camera may be surveying an out of bounds area, or may
be surveying an open access area for detection of a potential threat under certain
circumstances (for example in a commercial setting the installation may be used to
alert to the arrival of potential customers or potential villains while the commercial
enterprise is short-staffed, e.g., before or after the main operating hours).
[0087] At step 702 a camera of the installation captures at least two images of a scene
at the installation. The camera may only be able to capture still images, or it may
be configured to capture video with a frame rate high enough to generate a watchable
video sequence. For example, the camera may be any one of the cameras shown in Figures
1 or 2. The camera may be a stills camera configured to capture still images periodically
- for example every 10 to 20 seconds, or a few times each minute. Conversely, the
camera may be a video camera configured to capture video with a frame rate of between
several times a second and, for example, 20 to 24 frames per second.
[0088] At step 704 images captured by the camera are analysed in an attempt to detect movement
of image elements between an earlier image and a later image. The analysis may be
based on consecutive image captures or may be based on non-adjacent images from a
sequence of image captures. The image analysis may be performed on the camera that
captures the images but may alternatively be performed by a processor remote from
the camera, the camera images having been transmitted or otherwise sent directly or
indirectly to the processor. For example, the camera may be configured to send image
captures to a controller of the installation, e.g., controller 208, for processing
on the controller or to a controller or other gateway for onward transmission by the
controller/gateway (directly or indirectly) to another entity that will perform the
image analysis. Thus, the image analysis may be performed by a system backend, such
as 230 or 240, remote from the installation.
[0089] At step 706 the processor performing the image analysis detects movement based on
differences between image captures made at different instants in time. The processor
may be programmed to react to any detected movement, or it may be programmed to ignore
some categories of movement or only to respond to certain categories of movement or
to respond only if certain feature types (e.g., humans and/or vehicles) are present.
Commercially available image analysis systems based on A.I., e.g., software packages,
may be used to perform the image analysis.
[0090] Based on the detection of movement (according to the rules being applied by the processor
or system performing the image analysis) a report is generated for notification of
the detected motion to a user device. Depending upon the location of the entity performing
the image analysis the report may be in the form of the notification for the user
device, or the report may be provided, directly or indirectly, to another entity (e.g.,
the installation controller or the system backend) for the preparation and despatch
of the notification. The report and notification, if different, each both preferably
include at least the later of the compared images, and preferably the object of interest
whose movement has been detected is marked, annotated, or highlighted in some way
so that the basis of the motion detection will be clear from the notification. The
notification may include two or more of the images from which motion was determined,
or only one image (suitably annotated or marked) may be included. If the image analysis
was performed on a video sequence, that video sequence or a relevant clip from that
sequence may be included in the notification. The notification may then be transmitted
to the user device, e.g., device 220, at step 708, based on the identity of the installation
and e.g., a database linking the installation to a relevant user device identifier.
The notification preferably also includes context data (for example arm state, occupancy,
camera identity, other node sensing data, etc.) regarding the installation at the
time of the relevant image captures.
[0091] At step 710 the notification is displayed on a display of the user device in such
a way as to provide the user with a clear indication of the basis for movement detection.
The notification may include textual information (e.g., labelling) and/or audio description
to aid the user's understanding of the nature of the reported event - e.g., "person
spotted in the back garden". The notification may also include one or more "action
elements" e.g., buttons or icons with which the user may interact to provide a response.
[0092] At step 712 the user may provide a reaction - for example, if the notification is
a cause for alarm, the user may interact with an actionable element such as a button
or icon, or perform a deep touch, to indicate a desire to escalate the event to the
remote monitoring centre or to indicate that no threat is perceived based on an action
taken by the user ( interacting with a "not a threat" or "all OK" button, for example).
Again, if no response is received within a predetermined period after notification,
the processing entity may be configured to escalate the vent to the remote monitoring
centre 210.
[0093] At step 714 the user reaction is determined at a processing entity, such as the system
backend 230/240 or the installation controller 208, based either on an overt response
received from the user device or based on the lack of an overt response.
[0094] Based upon the determined response the processing entity either, based on a determination
of no threat, discounts the event at 716, or based upon a determination of a perceived
threat escalates 818 the event to the remote monitoring centre 210. Escalating to
the remote monitoring centre includes making the relevant image capture(s) available
to the remote monitoring centre and also providing any relevant information from the
user's reaction (in particular that the user perceives the existence of a threat -
and hence that the event should be treated as a priority).
[0095] At step 720 the personnel of the remote monitoring centre review the relevant captures
and the contextual information, and if necessary, instruct the installation to make
available video feeds, provide a bidirectional audio channel, etc., so that the personnel
are better able to determine the nature of any incident. If necessary, based on the
captures, contextual information, and later gathered information, the personnel may
decide to involve security personnel or the police, of others.
[0096] The processor/system used to determine motion based on image analysis, and/or the
processor/system that decides whether or not to notify a user device based on any
detected movement, may use user feedback (e.g., escalations, "all OK" responses, and
passive "responses") in a machine learning approach to improving system performance.
1. A method, performed by a system that comprises a security monitoring installation
at premises protected by the installation, the security monitoring installation having
a plurality of arm states, the plurality of arm states including a disarmed state
and at least one armed state, and being configured to report alarm events to a monitoring
station remote from the premises, the method comprising, in an armed state:
i) detecting the occurrence of an event at the premises;
ii) transmitting a notification in respect of the event to a user device, the notification
including event data;
iii) in response to receiving a user reaction to the notification indicating that
the event is a false alarm or that the user does not wish to report the event to the
monitoring station, determining (a) not to notify the monitoring station of an alarm
event in respect of the event and/or (b) to deescalate notification of the monitoring
station;
iv) in response to receiving a user reaction to the notification indicating a desire
to raise an alert in respect of the event with the monitoring station, (a) notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data, and/or (b) escalating notification of the monitoring station;
and
v) in response to not receiving within a predetermined time period a user reaction
to the notification, notifying the monitoring station of an alarm event (in respect
of the event) and providing the monitoring station with access to the event data;
and optionally notifying the monitoring station of an absence of user reaction.
2. A method as claimed in claim 1, further comprising the step of reporting the occurrence
of the event to a system back end remote from the premises, wherein the system back
end performs any of steps iii) to v).
3. A method as claimed in claim 1, wherein the step of transmitting a notification in
respect of the event to a user device is performed by the security monitoring installation,
wherein the security monitoring installation performs any of steps iii) to v),
optionally wherein the installation comprises a controller, and the step of transmitting
a notification in respect of the event to a user device is performed by the controller,
and wherein the controller performs any of steps iii) to v).
4. A method as claimed in any one of the preceding claims, wherein the notification in
respect of the event includes at least one of:
an image related to the event, and optionally wherein the image is a still image;
and/or
a link giving access to a video capture related to the event.
5. A method as claimed in any one of the preceding claims, wherein the event is at least
one selected from:
sensor based detection of motion;
sensor based detection of presence;
triggering of a window sensor, optionally a contact switch, magnetic sensor, or a
shock sensor;
triggering of a door sensor, optionally a contact switch, magnetic sensor, or a shock
sensor.
6. A method as claimed in any one of the preceding claims, wherein whether the notification
of step ii) is transmitted or not depends upon at least one condition selected from:
the time of day, day of the week, date, nature of the event, or some combination thereof.
7. A method as claimed in any one of the preceding claims, wherein the notification further
includes context information, the context information distinct from the event data
and complementing the event data, optionally wherein the context information includes
one or more selected from: the arm state; occupation state of the premises; camera
identity; status of other detectors at the premises.
8. A method as claimed in any one of the preceding claims, wherein the armed state is
an armed away state.
9. A system that comprises a security monitoring installation at premises protected by
the installation and a system back end remote from the premises, the security monitoring
installation having a controller and a plurality of sensors configured to transmit
event notifications to the controller, the controller being configured to report alarm
events to a monitoring station remote from the premises, the controller having at
least one operating mode in which it is configured to respond to receiving certain
event notifications by transmitting an alert, in respect of the notification of an
event, to the system back end remote from the premises,
the system back end being configured to:
i) transmit a notification in respect of the event to a user device, the notification
including event data, and optionally context information;
ii) in response to receiving a user reaction to the transmitted notification indicating
that the event is a false alarm or that the user does not wish to report the event
to the monitoring station, determining not to notify the monitoring station of an
alarm event in respect of the event;
iii) in response to receiving a user reaction to the transmitted notification indicating
a desire to raise an alert in respect of the event with the monitoring station, notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data and
optionally to context information; and
iv) in response to not receiving within a predetermined time period a user reaction
to the transmitted notification, notifying the monitoring station of an alarm event
(in respect of the event) and providing the monitoring station with access to the
event data and optionally to context information.
10. A security monitoring installation at premises protected by the installation, the
installation comprising a controller and a plurality of sensors configured to transmit
event notifications to the controller, the controller having at least one operating
mode in which it is configured to respond to certain event notifications by:
i) transmitting a notification in respect of the notification of an event to a user
device, the transmitted notification including event data, and optionally context
information;
ii) in response to receiving a user reaction to the transmitted notification indicating
that the event is a false alarm or that the user does not wish to report the event
to the monitoring station, determining not to notify the monitoring station of an
alarm event in respect of the event;
iii) in response to receiving a user reaction to the transmitted notification indicating
a desire to raise an alert in respect of the event with the monitoring station, notifying
the monitoring station of an alarm event and providing the monitoring station with
access to the event data and optionally to context information and; and
iv) in response to not receiving within a predetermined time period a user reaction
to the transmitted notification, notifying the monitoring station of an alarm event
(in respect of the event) and providing the monitoring station with access to the
event data and optionally to context information.
11. A system as claimed in claim 9 or an installation as claimed in claim 10, wherein
the context information is distinct from the event data and complementing the event
data, the context information including one or more selected from: the arm state;
occupation state of the premises; camera identity; status of other detectors at the
premises.
12. A system or installation as claimed in any one of claims 9 to 11, wherein the transmitted
notification in respect of the event includes at least one of:
an image related to the event, and optionally wherein the image is a still image;
and/or
a link giving access to a video capture related to the event.
13. A system or installation as claimed in any one of claims 9 to 12, wherein the event
is at least one selected from:
sensor based detection of motion;
sensor based detection of presence;
triggering of a window sensor, optionally a contact switch, magnetic sensor, or a
shock sensor;
triggering of a door sensor, optionally a contact switch, magnetic sensor, or a shock
sensor.
14. A system or installation as claimed in any one of claims 9 to 13, wherein whether
the notification of i) is transmitted or not depends upon at least one condition selected
from: the time of day, day of the week, date, nature of the event, or some combination
thereof.