RELATED APPLICATION

This application claims priority to U.S. Provisional Patent Application Serial No. 61/445,286, filed February 22, 2011 , titled "Wireless Lock with Lockdown" to Bonahoom, the entire disclosure of which is expressly incorporated by reference herein.

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 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 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. 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 8. 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 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 2 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 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. 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 8 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 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 30 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.

According to one embodiment, if door 8 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 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 8, 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 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 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.