Note: Descriptions are shown in the official language in which they were submitted.
WIRELESS LOCK WITH LOCKDOWN
FIELD OF THE INVENTION
The present disclosure relates a wireless lock, more particularly, to a
wireless lock having lockdown.
BACKGROUND AND SUMMARY OF THE INVENTION
According to the present invention, a wireless security system is provided.
The system includes a plurality of wireless locks positionable to control
access
through a plurality of doors, a plurality of communicators configured to
wirelessly
communicate with the plurality of wireless locks, and a central host including
a
database of credential information. The plurality of wireless locks include a
database of credential information regarding credentials that are authorized
to
allow access through the plurality of doors. The plurality of wireless locks
periodically initiate requests for updated credential information. The
plurality of
communicators include memory including updated credential information. The
plurality of communicators provide the updated credential information to the
plurality of wireless locks in response to request for updated credential
information from the plurality of wireless locks. The central host is
configured to
receive updated credential information and to communicate the updated
credential information to the plurality of communicators.
According to another aspect of the present disclosure, a wireless security
system is provided. The system includes a plurality of wireless locks
positionable
to control access through a plurality of doors, a plurality of communicators
configured to wirelessly communicate with the plurality of wireless locks, and
a
central host including a database of credential information. The plurality of
wireless locks includes a database of credential information regarding
credentials
that are authorized to allow access through the plurality of doors. The
plurality of
1
CA 2827516 2018-04-26
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
wireless locks periodically initiate requests for updated credential
information.
The plurality of communicators provide the updated credential information to
the
plurality of wireless locks in response to requests for updated credential
information from the plurality of wireless locks. The plurality of
communicators
provide lockdown instructions to the plurality of wireless locks. In response
to
receipt of lockdown instructions, the plurality of wireless locks block access
through the plurality of doors. The central host is configured to receive
updated
credential information and to communicate the updated credential information
to
the plurality of communicators.
According to another aspect of the present disclosure, a wireless security
system is provided. The system includes a plurality of wireless locks
positionable
to control access through a plurality of doors, a plurality of communicators
configured to wirelessly communicate with the plurality of wireless locks, and
a
central host including a database of credential information. The plurality of
wireless locks include a database of credential information regarding
credentials
that are authorized to allow access through the plurality of doors. The
plurality of
wireless locks periodically initiate requests for updated credential
information.
The plurality of wireless locks experience non-periodic access events. The
plurality of wireless locks initiate requests for updated access information
in
response to the non-periodic access events. The plurality of communicators
provide the updated credential information to the plurality of wireless locks
in
response to request for updated credential information from the plurality of
wireless locks. The central host is configured to receive updated credential
information and to communicate the updated credential information to the
plurality of communicators.
BRIEF DESCRIPTION OF THE DRAWINGS
The above-mentioned and other features of the present disclosure will
become more apparent and will be better understood by reference to the
following description of embodiments of the present disclosure taken in
conjunction with the accompanying drawings, wherein:
Figure 1 is a diagrammatic view of an access control system showing a
central host, wireless communicators communicating with the central host, and
a
2
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
plurality of wireless locks communicating with at least one of the wireless
communicators;
Figure 2 is a view showing one of the plurality of wireless locks of FIG. 1
on a door to control access through the door and monitoring the status of the
door; and
Figure 3 is a flow chart showing wireless lock control.
Corresponding reference characters indicate corresponding parts
throughout the several views. Although the drawings represent embodiments of
the present invention, the drawings are not necessarily to scale and certain
features may be exaggerated in order to better illustrate and explain the
present
invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION
The embodiments disclosed below are not intended to be exhaustive or
limit the invention to the precise forms disclosed in the following detailed
description. Rather, the embodiments are chosen and described so that others
skilled in the art may utilize their teachings.
As shown in FIG. 1, according to the present disclosure, an access control
system 10 is shown including a central host 12, such as a computer server, a
plurality of wireless communicators 14, and a plurality of wireless locks 16
mounted on doors 18. Each wireless lock 16 allows (or blocks) access through a
closed door 18 and a requester is authorized to open door 18. Central host 12,
either through wired (LAN, ethernet, internet, etc.) or wireless communication
(as
shown), communicates with wireless communicators 14. Wireless
communicators 14 communicate wirelessly with one or more wireless locks 16.
Although shown mounted to doors 18, portions or all of wireless locks 16
may be mounted in other locations relative to door 18, such as in a door
frame.
Typically, wireless communicators 14 are positioned within a building that
includes one or more of doors 18. However, doors 18 may be located in remote
locations away from the building in which a wireless communicator 14 is
positioned. For example, wireless communicator 14 may be located in a building
that is adjacent to an exterior turnstile installed in a fence to control
access
through the fence.
3
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
As shown in FIG. 2, wireless locks 16 are electro-mechanical devices that
include a housing 20, a latch bolt 22, an outside handle 24, and an inside
handle
26. Although illustrated and described as handles, handles 24, 26 may be other
devices. For example, inside handle 26 may be a push-bar type exit device on
an out swing door.
If door 18 is closed, authorized rotation of either outside handle 24 or
inside handle 26 by a user will retract latch bolt 22 inside housing 20 to
allow the
user to open door 18. Wireless lock 16 includes controller 28 that determines
whether a user is authorized to open door 18 to retract latch bolt 22 using
handles 24, 26. Often controller 28 is configured to verify if a user is
authorized
to open door 18 using outside handle 24. Often controller 28 allows a user
rotating inside handle 26 (or pushing a push bar on an out swing door) to
retract
latch bolt 22 without verifying whether the user is authorized to open door
18.
Locks 16 further include a reader 30, such as a card reader or fob reader,
and transceiver 32. Reader 30 reads a code from a credential (not shown), such
as a card or fob, presented by a user. Reader 30 is normally placed on the
secure side of door 18. Controller 28 and transceiver 32 may be positioned on
either the secured on non-secured side of door 18.
Controller 28 includes a database of codes that are authorized to open
door 18. Thus, if a user presents a credential having a code stored in the
database, controller 28 will allow the user with that credential to retract
latch bolt
22 using outside handle 24. Although reader 30 is the preferred input device
for
receiving authentication data, other input devices, such as a keypad for
receiving
a passcode, a biometric reader for reading biometrics, and other input devices
may be used for authentication.
During installation of a new system, central host 12 is programmed with
authorized users, who are given credentials. Each credential includes a code,
which is associated with the authorized user. During installation, the
databases
of controllers 28 of locks 16 are programmed with an initial set of codes for
authorized credentials. As shown in FIG. 3, after (or during) initial
installation,
authorized users are added at step 34 and/or removed from central host 12 by
host users to update who is authorized to open which doors 18, if any. These
updates are communicated from central host 12 to one or more wireless
communicators 14 at step 36. These updates are stored in memory 37 of each
4
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
respective communicator 14 until communicated to locks 16 as discussed below
in greater detail.
On occasion, it may be warranted to disable locks 16 from allowing most
or all passage through doors 18 for security or other purposes. One such
situation is during a building or campus lockdown when a security risk has
been
indentified, such as a gunman or other threat. During such a lockdown,
exterior
and interior doors 16 may be locked to prevent a gunman or anyone else from
entering or existing a building, classroom, or other area.
In addition to providing user updates, central host 12 may also initiate a
lockdown in response to a report of a security risk at step 38. After a host
user
initiates a lockdown, central host 12 pushes lockdown instructions to
communicator 14 at step 36, which stores the instructions in memory 37.
Lockdown instructions are given a higher communication priority than other
data,
such as user updates. Thus, if multiple types of data (ex. lockdown
instructions,
user updates, etc.) need to be communicated to communicators 14 from central
host 12 and from communicators 14 to locks 16, lockdown instructions are
always communicated first, even though the lockdown instructions may have
originated later than the other updated data.
As discussed in greater detail below, locks 16 request user updates from
communicators 14 that may have been entered into or otherwise provided to
central host 12 in step 34. Rather than waiting for communicators 14 to
request
these user updates, lockdown instructions, or other information based on
request
from locks 16, central host 12 pushes the user updates and lockdown
instructions
to communicators 14 after each update. Thus, pushing of the information from
central host 12 to communicators 14 occurs before locks 16 make any requests
for such user updates, lockdown instructions, or any other information. By
having
the updates and instructions in memory 37 of communicators 14, the time/delay
necessary to communicate the information between central host 12 and the
respective communicators 14 occurs before respective locks 16 request user
updates and/or lockdown instructions from communicators 14. As such, locks 16
may receive the updates sooner than if system 10 waited for requests from
locks
16 before communicating the information from central host 12 to communicators
14. Central host 12 only pushes updates, lockdown instructions, and other
5
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
information to communicators 14 associated with locks 16 that are to receive
the
updates, lockdown instructions, and other information.
Typically, locks 16 include a battery (not shown) and are not hardwired to
a building's electrical supply so locks 16 do not receive electrical power
from a
source other than the battery. To conserve battery power, transceiver 32 is
normally powered down as shown in step 40. Because controller 28 of lock 16
includes a database of authorized codes, controller 28 can determine who has
authorization to open door 18 when transceiver 32 is powered down. Thus,
controller 28 makes user-based access determinations at door 18 without a need
to communicate with central host 12 to determine if a user is authorized to
open
door 18 after the user presents the credential to reader 30. Rather,
controller 28
has the necessary information to make the user-based access decision before a
user presents a credential and avoids delays associated with communicating
with
communicators 14 and central host 12.
As shown in step 40 in FIG. 3, transceiver 32 is normally powered down
and in a wait mode 42. The length of wait mode 42 is adjustable. The longer
the
wait mode, the less battery power is used because transceiver 32 is powered
down for longer periods of time. According to the preferred embodiment, the
default wait mode 42 is one minute, but can adjusted upwardly or downwardly
(ex, 30 seconds, 2 minutes, 5 minutes, 10 minutes, etc.) at locks 16 or at
central
host 12.
To receive updates and lockdown instructions, lock 16 energizes
transceiver 32 at step 44 and sends a signal to communicator 14 that it is
ready
to receive any available updates and lockdown instructions stored in memory
37.
As discussed above, these user updates and lockdown instructions were
previously sent by central host 12 to communicator 14. At step 46,
communicator
14 sends and transceiver 32 receives any user updates and lockdown
instructions stored in memory 37 of communicator 14. Additionally at step 46,
transceiver 32 sends any history or other information to communicator 14, such
as which codes were presented to lock 16, the level of charge of the battery,
etc.
At step 48, communicator 14 sends the lock history and other data to central
host
12. After step 46, lock 16 returns to step 40 and powers down transceiver 32.
While transceiver 32 is powered down, it does not receive user updates or
lockdown instructions.
6
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
In addition to receiving lockdown instructions during receipt of normal user
updates, lock 16 can receive lockdown instructions during other times, such as
during access events at lock 16. Typically, access events are random events
that are not prompted by system 10, but by users or other external triggers.
As
discussed above, transceiver 32 is normally powered down so that it does not
communicate with communicators 14. Thus, during these times, controller 28
does not receive user updates or lockdown instructions from central host 12.
By
also receiving lockdown instructions at random times based on access events,
controller 28 may receive lockdown instructions sooner than otherwise.
As shown in FIG. 3, controller 28 is in wait mode 42. During this time,
central host 12 may initiate a lockdown at step 38 and push the lockdown
instructions to communicator 14 at step 36, which stores the instructions in
memory 37 as discussed above. Communicators 14 hold the lockdown
instructions and wait for locks 16 to request lockdown instructions and user
updates.
At step 50, controller 28 continuously monitors if an authorized user or
other person created an access event, such as a user presenting a credential
to
card reader 30. In addition to a user presenting a credential in an effort to
open a
door, other access events may include a user closing door 18, a user
attempting
to rotate outside handle 24 or inside handle 26 (or push a push bar on an exit
device), and other events that impact door 18, such as 18 door being left
open,
door 18 being forced open, or other such events. Lock 16 may include door
position sensor 52 that detects when door 18 moves between open and closed
positions or otherwise moves. In response to lockdown conditions, such as
hearing gunfire, users may attempt an access event, such as closing or
attempting to open door 18 with or without the use of a credential.
When controller 28 detects an access at step 50, it energizes transceiver
32 at step 53. Next, controller 28 determines the type of event that has
occurred
at step 54. If the event type is indicative of a normal activity, such as an
attempted access with a credential, door 18 opening or closing, or a request
to
exit caused by rotation of handles 24, 26 (or pushing on a push bar),
communicator 14 sends, and transceiver 32 receives the lockdown instructions
at
step 56. As discussed above, communicator 14 previously received the
7
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
lockdown instructions at step 36 in response to central host 12 initiating a
lockdown.
According to the preferred embodiment of the present disclosure,
communicator 14 waits for transceivers 32 of locks 16 to request lockdown
and/or
.. user updates and sends the information to transceivers 32 after receiving
the
request from transceivers 32. According to an alternative embodiment,
communicator 14 repeatedly broadcasts lockdown instructions while waiting for
transceiver 32 to energize at energize step 53. By repeatedly broadcasting the
lockdown instructions, the instructions are immediately available to locks 16
without transceivers 32 having to first request lockdown instructions from
communicators 14 based on a request from controllers 28 of locks 16 or
otherwise.
If the access event was something other than normal (ex. forced door
entry or door being held open indication), controller 28 of lock 16 proceeds
to
step 46 to receive user updates. According to one embodiment, the wait period
for step 42 is reset because user updates were just received from communicator
14. For example, if an access event occurred at 50 seconds into the default
wait
period of one minute, controller 28 would reset the wait period to wait
another
minute, rather energizing transceiver 32 after an additional 10 seconds.
Next, controller 28 determines if the lockdown instructions indicate that
there is a lockdown at step 58. If there is a lockdown, controller 28 locks
the
access point at step 60, such as door 18, to prevent latch bolt 22 from being
retracted. Depending on the configuration of lock 16, controller 28 will not
secured side/outside handle 26 to retract latch bolt 22. Controller 28 may
block
retraction of latch bolt 22 even if an authorized credential is presented to
reader
or otherwise. According to one embodiment, select individuals, such as
building security, police, etc., may be provided with override credentials so
that
their credentials allow retraction of latch bolt 22 even during lockdown while
all
other credentials do not.
30 According to
one embodiment, if door 18 is equipped with a door opener
(not shown) that holds door 18 open, controller 28 also initiates closing of
door 18
by instructing the door opener to no longer hold open door 18. Some door
openers, such as handicap access doors automatically open doors based on
sensed motion or pressing a button. Other door openers require manual opening
8
CA 02827516 2013-08-15
WO 2012/116037 PCT/US2012/026067
and hold the door 18 open once opened by a user. Such doors may
automatically close in the event of a fire to seal off a fire wall or
otherwise.
According to another embodiment, controller 28 makes an audible or other
alarm indicating or requesting that door 18 be closed by anyone nearby. For
example, controller 28 may make an audio alarm such as "Emergency! Close this
door now!" Thus, as a result of receiving the lockdown instructions,
controller 28
secures door 18 by automatically closing door 18 using a door opener or
requesting that door 18 be closed manually by a nearby person.
When a lockdown is no longer required, central host 12 changes the
lockdown instructions to indicate there is no longer a lockdown. Upon receipt
of
the new lockdown instructions, lock 14 will permit access through door 18 when
authorized credentials are presented to reader 30.
If there is no lockdown, controller 28 proceeds to step 62 and determines if
the access event was an access request. If the event was not an access
request, such as the door opening or closing, controller proceeds to steps 40
and
42 to power down transceiver 32 and continue waiting.
If a user presents a credential with a code, controller 28 checks its
database to determine if the credential, such as a card, has access rights to
door
18 at step 64. As discussed above, controller 28 does not need any additional
information from communicator 14 or central host 12 to determine if the user
has
access rights. Thus, no time is lost waiting for communications from central
host
12 and communicator 14 while controller 28 makes a user-based access
decision. If the credential is not authorized, controller 28 denies access
through
door 18 at step 64 by not allowing retraction of latch bolt 22 by outside
handle 24
.. and continues to power down transceiver 32 and wait at respective steps 40,
42.
If the credential is authorized to open the particular door 18, controller 28
moves to step 66 and grants access through door 18. At step 62, if the access
event was something other than a user presenting a credential, controller 28
maintains the status quo for latch bolt 22. After granting access, controller
28
.. proceeds to step 46 to receive user updates and provide audit histories.
In addition to checking if the credential is authorized in step 64, controller
28 may also determine if the user is authorized to access an area during a
given
time period. For example, a user may only be authorized to access a room
during a time period between 9:00 AM and 5:00 PM during the work week. If an
9
CA 02827516 2013-08-15
WO 2012/116037
PCT/US2012/026067
authorized credential is presented to lock 16 outside of this time period or
on a
weekend, controller 28 will not grant access. In addition to receiving user
updates on which credentials are authorized (or not), controller 28 may also
receive updated time periods of authorized access for each credential.
When the access event is a user presenting a credential, controller 28
preferably checks the credential and receives lockdown instructions in an
expeditious manner. As shown in FIG. 3, controller 28 checks for lockdown
instructions and checks the credential in a serial manner. However, certain
steps
may occur simultaneously or in a order not shown in FIG. 3. For example, to
expedite receipt of the lockdown instructions, controller 28 may first
energize
transceiver 32 at step 53. In parallel with transceiver 32 requesting
(optional),
receiving, and processing the lockdown instructions at step 54, controller 28
may
verifying the credential at step 64 by referring to its database. Because
controller
28 has already begun, and perhaps completed the credential check, it can
determine whether to grant access at step 64 immediately after step 58. Thus,
by using the parallel path to check the credential and determine if there is a
lockdown, an authorized user requesting access has less time to wait before
being granted access when there is no lockdown. Other steps depicted in FIG. 3
may occur in an order different than shown in FIG. 3. For example, to conserve
battery power, controller 28 may power down transceiver immediately after step
60 or immediately after any other step in which it is not expecting additional
data
before being powered down.
According to an alternative embodiment, user updates are also
communicated during step 56 while transceiver 32 is still energized and the
wait
.. period is reset as discussed above. As discussed above at step 56,
transceiver
32 receives the lockdown instructions from communicator 14. The lockdown
instructions from communicator 14 may positively indicate that there is no
lockdown and/or positively indicate that there is a lockdown. According to one
embodiment, if there is no communication regarding a lockdown, controller 28
may interpret this as a passive lockdown instruction indicating that there is
no
lockdown (i.e. no communication means there is no lockdown) or that there is a
lockdown (i.e. no communication means there is a lockdown).
By providing user updates after a predetermined waiting period of step 42,
lock 16 receives regular updated user data with which to make user-based
CA 02827516 2013-08-15
WO 2012/116037
PCT/1JS2012/026067
access decisions. By requesting lockdown instructions at random times, such as
when a door access event occurs, non-user based access decisions, such as
during a lockdown, can be made with instructions that are not dependent on the
predetermined waiting period. Thus, if the wait period is set for 30 minutes,
a
lockdown instruction can be received before the 30 minute wait period has
expired if a door access event has occurred within the 30 minute wait period.
While this invention has been described as having an exemplary design,
the present invention may be further modified within the spirit and scope of
this
disclosure. This application is therefore intended to cover any variations,
uses, or
adaptations of the invention using its general principles. Further, this
application
is intended to cover such departures from the present disclosure as come
within
known or customary practice in the art to which this invention pertains.
11
