Patent Description:
It is often desirable to secure and control access to certain secure areas. Typically, access control systems are located at access points which lead to the secured areas, and are configured to grant or deny access to each individual attempting to gain access to the secured areas. In some cases, an access control system may include an access device (e.g., one or more of an electronic card reader, a keypad, a biometric identification system, and other access devices) that is configured to accept identifying information from an individual attempting to gain access to a secured area. If it is determined that the individual has access rights to the secured area, the access control system may log the entry event and unlock a door or the like to provide the individual with access to the secured area.

For some secure areas, an access control system may use dual authentication for granting access to a secured area. Access control systems requiring dual authentication may operate in an escort control mode and may require personnel wanting to gain access to a secured area to be accompanied by a supervisor. A supervisor may be considered anyone that has been given the authority to grant access to the requester to gain access to the secured area. In such an example, an access control system may include an access device at a door to a secured area and the personnel along with a supervisor may each be required to enter user identifiable information into the access device(s) in order to gain access to the secured area. When an access control system is operating in an escort mode and requires dual authentication, personnel will not be able to gain access to a secured area if the supervisor or an assigned approval personnel is not available or cannot be immediately located (e.g., in a meeting, out of the office, or otherwise unavailable). This can be disruptive, particularly if urgent work needs to be performed in the secured area.

<CIT>) discloses methods and devices for obtaining authorization for a requestor to access a service. In one embodiment, there is provided a method comprising receiving a requestor request for access to a service; sending an authorization request to one or more mobile devices associated with one or more authorizers on a first approval list; receiving an authorization response from the one or more mobile devices associated with the one or more authorizers on the first approval list; determining whether a predetermined level of authorization is received; and when the predetermined level of authorization is received, authorizing access to the service.

<CIT>) discloses an access control method and corresponding system and, in particular, a method involving transmitting a personalized access code together with identification identifying an area) to be controlled with respect to an access from a mobile device to a server of an access control device over an official network to authenticate a person requesting access to the area. The identification of the area is read by a tag e.g. adhesive label with radio frequency identification-chip, arranged in the area, and the identification is transferred to the mobile device. An actuator locking a safety device is remotely controlled by the control device.

<CIT>) discloses a one-time access to electronic locking devices for non-keyholders.

The present invention provides for a system for providing access to a secure room and a corresponding method as claimed in the accompanying claims.

A full appreciation of the disclosure can be gained by taking the entire specification, claims, drawings, and abstract as a whole.

The disclosure may be more completely understood in consideration of the following description of various illustrative embodiments in connection with the accompanying drawings, in which:.

It should be understood, however, that the intention is not to limit aspects of the disclosure to the particular illustrative embodiments described.

The following description should be read with reference to the drawings wherein like reference numerals indicate like elements throughout the several views. The description and drawings show several illustrative embodiments which are meant to be illustrative in nature.

Areas, including buildings or rooms in buildings, or areas outside of buildings, may be secured by restricting access to those areas. Access control systems may be utilized at entry points for providing access to approved personnel.

Access controls systems may include one or more types of personnel authentication to help ensure access to a secured area is only granted to the personnel for which access is authorized. One example access control system may use dual authentication for granting access to a secured area. Access control systems requiring dual authentication may operate in an escort control mode and may require personnel wanting to gain access to a secured area to be accompanied by a supervisor. A supervisor may be considered anyone that has been given the authority to grant access to the requester to gain access to the secured area. In such an example, an access control system may include an access device (e.g., one or more of an electronic card reader, a keypad, a biometric identification system, and other access devices) at a door to a secured room and the personnel along with a supervisor may each be required to enter user identifiable information into the access device(s) in order to gain access to the secured area.

Secured areas may be any area for which access is to be restricted. Examples of secured areas may include, but are not limited to, server rooms, data centers, pharmaceutical rooms, laboratories, areas containing sensitive information, outdoor areas, and/or other areas. Further, secured areas may have different security levels, each having different requirements for gaining access. For example, a secured area may require submission of one or more of the following pieces of user identifiable information before access may be granted to the secured area: an identification card scan, a password, a personal identification number, a fingerprint scan, a retina scan, a facial recognition scan, and/or other identifiable information. In some cases, such as in a system requiring dual authentication, an access control system may require submission of user identifiable information from each of two (or more) people present at the secured area before granting access to the secured area.

In some cases, a process for gaining access to a secured area requiring dual authentication may include an employee (e.g., the personnel wanting to gain access to the secured area) presenting credentials (e.g., user identifiable information including, but not limited to, one or more of an electronically identifiable card, electronically identifiable phone, a personal identification number (PIN), a password, biometric information (e.g., finger print, facial recognition, retina scan), and other user identifiable information) to the access device. The access device may provide an indication (e.g., provide a light, such as a red LED light or other light, or instructions) for a period of time (e.g., <NUM> second, <NUM> seconds, <NUM> seconds, <NUM> seconds, <NUM> seconds, or other period of time) to indicate that it is ready to accept a supervisor's credentials. When the supervisor's credentials have been received within the period of time after the employee's credentials are provided, access may be granted to the secured area (e.g., a door may unlock and/or open a door or gate to a secured room, building, or other area). If the period of time expires prior to the access device receiving the supervisor's credentials, the access device may provide an indication that the process for accessing the secured area needs be repeated, provide an indication the supervisor's credentials were not received, or provide no indication at all.

When an access control system is operating in an escort mode and requiring dual authentication, if the supervisor or an assigned approval personnel is not available (e.g., in a meeting, out of the office, or otherwise unavailable), then the personnel wanting to gain access to the secured area will not be able to gain entry to the secured area. <FIG> depicts an example flow of a first level personnel <NUM> (e.g., a first level user or employee) attempting to access a secured area through a door <NUM> through which access may be restricted by an access control system <NUM>, where the access control system may be operating in an escort mode. The access control system <NUM> may include an access device <NUM>, a control panel <NUM>, a lock <NUM>, and/or other features.

Access devices <NUM> may include an electronic device or other device configured to facilitate controlling access to a secured area. Access devices <NUM> may include, but are not limited to, a camera (e.g., a video and/or still camera), a Bluetooth transceiver and/or transponder, a Bluetooth Low Energy (BLE) transceiver and/or transponder, a Radio Frequency Identification (RFID) transceiver and/or transponder, a Near-Field Communications transceiver and/or transponder, a fingerprint scanner, a facial recognition scanner, a retina scanner, a temperature scanner, and/or other suitable access devices.

At step <NUM> in <FIG>, a first level personnel <NUM> may identify that access through the door <NUM> is desired (e.g., because the first level personnel needs to do some critical changes on data center machines in a data center room on the other side of the door <NUM> or for other purposes). However, when the first level personnel <NUM> approaches the door <NUM> at step <NUM>, the first level personnel <NUM> may realize access through the door <NUM> is controlled by an access control system <NUM> that requires dual authentication and operates in an escort mode, and an assigned second-level personnel (e.g., a supervisor or other second level personnel) is out of the office and cannot provide credentials to the access device <NUM>. As shown at step <NUM> of <FIG>, the first level personnel is unable to access the secured room through the door <NUM> because the access control system <NUM> is operating in an escort mode and the access control system <NUM> will not allow the first level personnel <NUM> to enter through the door <NUM> without supplying a second level personnel's credentials to the access device <NUM>. In such cases, it may be highly problematic if the first level personnel <NUM> is unable to gain access to the secured room at times that it is critical for the first level personnel <NUM> to access the secured room (e.g., to enter the data center room to make urgent changes on data center machines).

<FIG> depicts another example of an access control system <NUM> utilizing dual authentication. However, in the example of <FIG>, a second level personnel may be located remotely from the first level personnel and/or the door <NUM> through which the first level personnel would like to gain access. In this example, the access control system <NUM> may include an access device <NUM> (optional), a control panel <NUM>, a lock <NUM>, a mobile application accessible from mobile devices (e.g., a wireless device), a remote server in communication with the mobile devices and the control panel <NUM>, and/or one or more other devices or systems. The access device <NUM>, the control panel <NUM>, and/or the lock <NUM> may be electronic devices.

At step <NUM> of <FIG>, a first level personnel <NUM> may identify that access through the door <NUM> is desired (e.g., because the first level personnel needs to do some critical changes on data center machines in the data center room on the other side of the door <NUM> or for other purposes). However, when the first level personnel approaches the door <NUM> at step <NUM>, the first level personnel <NUM> may realize that access through the door <NUM> is controlled by an access control system <NUM> that requires dual authentication and an assigned second level personnel <NUM> (e.g., a supervisor or other second level personnel) is out of the office. At step <NUM>, the first level personnel <NUM> identifies that it can send a request for approve to gain entry through the door <NUM>. In some cases, the first level personnel <NUM> may be able to enter and/or send its credentials using a first device (e.g., the access device <NUM> or a mobile device <NUM>). Although the device of the first level personnel may be described herein as a mobile device <NUM> or other wireless device, it is contemplated that the first level personnel <NUM> may execute a process of requesting approval for access using access device <NUM> adjacent the secured area, rather than mobile device <NUM>.

In step <NUM>, the first level personnel <NUM> may enter its credentials at the first device and send an access request to the remote server. The remote server may verify the credentials of the first level personnel <NUM>, and if verified, send a request for approval to a second device (e.g., a mobile device <NUM>) held by the second level personnel <NUM>, as shown at step <NUM>. In response, and in step <NUM>, the second level personnel <NUM> may enter its credentials in the second device (e.g., a mobile device <NUM>) to approve the access request and send a response to the remote server approving access through the door <NUM> for the first level personnel <NUM>. The remote server may then verify the credentials of the second level personnel <NUM>, and if verified, send a command to the control panel <NUM> to unlock the lock <NUM> of the door <NUM>. The first level personnel <NUM> may then gain access to the secured room via the unlocked door <NUM>.

<FIG> is a schematic view of another illustrative access control system. In <FIG>, the access control system <NUM> may include a server <NUM>, access devices <NUM> including one or more sub-devices, an application program code executable by a processor of an access device <NUM> and/or one or more other devices (e.g., a first mobile device <NUM> and a second mobile device <NUM>), locks <NUM>, and a control panel <NUM>. Mobile devices (e.g., wireless devices) may be any type of computing device that may be locally powered (e.g., battery powered) and capable of wireless communication (e.g., a mobile phone, a tablet computer, a laptop computer, etc.).

The server <NUM> may be located at or remotely from one or more of the control panel <NUM>, the first mobile device <NUM>, and the second mobile device <NUM>. The server <NUM> may be located in the same building or facility as a secured area and/or may be located off-site. The control panel <NUM> may communicate with the server <NUM> in a wired or wireless manner. The first mobile device <NUM> and the second mobile device <NUM> may communicate with the server <NUM> at least in part over a wireless network.

The server <NUM> may include a memory <NUM> and a processor <NUM> in communication with the memory <NUM>. The memory may store a first database and a second database, where the first database may be one of a requester database and a supervisor database, and the second database may be the other of the requester database and the supervisor database. Although the requester database and the supervisor database may be separately called out, it should be realized that the requester database and the supervisor database may be part of one or more larger databases or may together be a single database. That is, when the requester database and the supervisor database are separately called out herein, this does not mean that the requester database and the supervisor database are necessarily separate databases, and in many cases may be implemented as a single database.

The application program code (or app) running on the mobile devices <NUM>, <NUM> (e.g., a phone, table computer, laptop computer, etc.) may be the same or different application program codes, and may be downloaded from an external Web service. In some cases, the application program code may be downloaded from Apple Inc. 's ITUNES™ or Google Play. Alternatively, or in addition, the application program code may be available for download from a web service that is provided to support the access control system <NUM> or supplies the access control system <NUM>.

The application program code (or app) may be stored in memory of a user's mobile device <NUM>, <NUM> and may contain a set of instructions for execution by a processor related to controlling access to a secured area. The user's mobile device <NUM>, <NUM> may be any type of the mobile device described herein or otherwise known to be a mobile device. In some cases, the application program code may be stored in the memory of a user's phone or tablet computer for execution by the phone or tablet computer's processor to carry out various functions to facilitate receiving and/or providing access to a secured area.

The application program code may utilize a communication protocol that allows the application program code to be executed by multiple platforms (e.g., web, phone/tablet application, etc.). For example, a laptop computer and a phone/tablet may utilize the same installation setup logic by executing the same code from the same code base. In some cases, the application program code may be programmed to determine how to display each feature of a secured area access process to a user via the device's user interface. The application program code executed by a user's mobile device (e.g., phone, tablet, etc.) may connect to the server <NUM> directly or indirectly.

Turning to <FIG>, the mobile devices (e.g., mobile devices <NUM>, <NUM>) of <FIG> may include a user interface <NUM>, a controller <NUM> (e.g., a microprocessor, microcontroller, etc.) in two-way communication with the user interface <NUM>, memory <NUM> connected to the controller <NUM>, and one or more wireless input/output ports <NUM> in two-way communication with the controller <NUM>. In some instances and as discussed, the mobile devices <NUM>, <NUM> may be a phone (e.g., a smartphone) or a tablet computer, but this is not required.

As discussed above with reference to <FIG>, the mobile devices <NUM>, <NUM> may be used to communicate with one or more of the access devices <NUM> and/or the server <NUM> of the access control system <NUM>. The mobile devices <NUM>, <NUM> may be programmed to communicate over one or more wireless networks. Communication and data may be transmitted between mobile devices <NUM>, <NUM> and one or more of the access devices <NUM> and the server <NUM> via the one or more wireless networks. The wireless input/output port(s) <NUM> of the mobile devices <NUM>, <NUM> may facilitate wireless communication (e.g., sending and/or receiving data) with other devices (e.g., other mobile devices, the access devices <NUM>, the server <NUM>, etc.) through any suitable connection including, but not limited to, cellular communication, ZigBee, REDLINK™, Bluetooth, Bluetooth Low Energy (BLE), WiFi, IrDA, dedicated short range communication (DSRC), EnOcean, Near Field Communication (NFC), and/or any other suitable common or proprietary wireless protocol.

The user interface may be any type of user interface including an output (e.g., display, speakers, and/or other outputs) and/or an input (e.g., a keyboard, a touch screen, one or more buttons, biometric reader <NUM>, and/or other inputs). In some cases, the user interface <NUM> may include one or more biometric readers <NUM>. For example, an included biometric reader <NUM> may be a finger print sensor, a retina scanner, a facial recognition scanner, and/or other biometric reader <NUM>.

The memory <NUM> may be any type of memory including, but not limited to, FLASH memory, Random Access Memory (RAM), Read Only Memory (ROM), and/or other memory types. In some instances, one or more application program codes (apps) <NUM> may be stored in the memory <NUM> for execution by the controller <NUM>. The memory may be a computer readable medium capable of storing the application program codes <NUM> in a non-transitory state.

In some cases, the one or more application program codes <NUM> may be downloaded from an external web service such as, for example, Apple, Inc. 's ITUNES™, Google, Inc. 's Google Play, Honeywell's TOTAL CONNECT™ web service, a contractor's web site, and/or any other suitable location. In one instance, at least one of the application program codes <NUM> stored in the memory <NUM> may be related to controlling access to a secured room.

<FIG> depicts a device (e.g., a mobile device <NUM>) of a first level personnel and a device (e.g., a mobile device <NUM>) of a second level personnel <NUM> interacting with an access control system <NUM>. The first level personnel <NUM> may wish to gain access to a secured area through the door <NUM>. By interacting with an application program code of the access control system <NUM> on the device (e.g., mobile device <NUM>), the first level personnel may enter its credentials into the device (e.g., the mobile device <NUM>). In the example shown in <FIG>, the first level personnel's credentials may include a PIN and a finger print scan, but additional and/or alternative biometric information and/or other authenticating information may be entered via the device (e.g., mobile device <NUM>) or other device. As shown in <FIG>, the biometric reader <NUM> may be a fingerprint reader, and once the first level personnel's fingerprint has been received, the application program code may send a request to the server <NUM> via the wireless input/output port <NUM> (or other communication port) for receiving access through the door <NUM>. In some cases, the request may include the first level personnel's credentials.

In some cases, the first level personnel <NUM> may not have a mobile device <NUM>. In this example, the first level personnel may enter its credentials into the access control device <NUM>. Once received, the access control device <NUM> may send a request to the server <NUM> for receiving access through the door <NUM>, sometimes via the control panel <NUM>.

The server <NUM> may authenticate the first level personnel and if authenticated, send the request to a device (e.g., mobile device <NUM>) of an appropriate second level personnel. If the second level personnel approves of the access request, the second level personnel may enter its credentials into the device by interacting with an application program code of the access control system <NUM> on a device (e.g., the mobile device <NUM>). In the example shown in <FIG>, the second level personnel's credentials may include a PIN and a finger print scan, but additional and/or alternative biometric information and/or other authenticating information may be entered via the device (e.g., the mobile device <NUM>). Similar to as on the device of the first level personnel, the biometric reader <NUM> on the device of the second level personnel in <FIG> is a fingerprint reader. Once the second level personnel's PIN and fingerprint has been received, the application program code may send an approval of the request to the server <NUM> via the wireless input/output port <NUM> (or other communication port) for approving access through the door <NUM>. In some cases, the approval may include the second level personnel's credentials.

The server <NUM> may authenticate the second level personnel and if authenticated, send a signal to the control panel <NUM> to provide access through the door <NUM> to the secured area for the first level personnel. In some cases, the signal from the server <NUM> may trigger the control panel to unlock the lock <NUM>, to open the door <NUM>, and/or otherwise allow access to the secured area.

<FIG> is a flow of an illustrative method <NUM> of interacting with the access control system <NUM> to gain access to a secured area, which is explained in the context of an employee (e.g., a first level personnel and/or a user of a first device) and a supervisor (e.g., a second level personnel and/or a user of a second device). In the description below, reference numerals for steps of the illustrative method <NUM> are either preceded by the term "step" or are within parentheses.

In the illustrative method <NUM>, an employee may approach a door (e.g., door <NUM> or other door) securing access to a secured area with the access control system <NUM> (<NUM>). In some cases, as the employee approaches the door, the employee's device (e.g., a first device, such as the mobile device <NUM> or other device) may recognize its location relative to the door and automatically open an access control app (e.g., the application program code <NUM> executed by the controller <NUM> to provide a user interface screen) in the employee's device (<NUM>). In some cases, an access device <NUM> at the door and employee's device may be BLUETOOTH LOW ENERGY (BLE) enabled, and the employee's device may detect its location relative to the door by sensing the BLE enabled access device <NUM>. Alternatively, or in addition, the employee's device may detect a Global Positioning System (GPS) identified position, sense a Radio Frequency Identification (RFID) tag at the door, a Near-Field Communication (NFC) signal, and/or one or more other location indicating signals to determine a location relative to the door.

In some cases, the employee may need to manually open the application program code. In some cases, the application program code may only be opened or openable when the employee's device detects a proximity to the secured area. Such a feature may be provided for added security of the secured area and/or for other reasons associated with avoiding in advertently providing access to the secured area.

At step <NUM>, the employee may begin an access request process by selecting a button on a screen of the application program code operating on its device. Once the access request process has been initiated, the application program code may display a screen with a request on the employee's device for the employee to provide identification information (e.g., employee or user identifiable information). In one example, the requested identification information may include at least one password or PIN and at least one piece of biometric information. Other information may be requested as desired. The employee may enter its password or PIN and its biometric information (<NUM>) and the request for access to the secured area may be sent to and received at a server of the access control system <NUM> for authentication and further processing (<NUM>). The request for access may be sent from the employee's device automatically upon the submission of the identification information or after submission of the identification information and after the employee selects a button on a screen of the application program code.

In some cases, the request for access may include a confirmation that the employee and/or the employee's device is within a certain proximity of the door providing access to the secured area. The confirmation that the employee and/or the employee's device is within the certain proximity may be, but is not limited to, one or more of a signal indicating the phone is sensing an access device <NUM> adjacent the secured area at the time a request is sent, a picture from a camera adjacent the secured area, a video from a camera adjacent the secured area, and/or one or more other indications.

At step <NUM>, the server may authenticate the employee's provided identification information. In one example, as referred to above, the server may include a requester database that includes a list of employees that are authorized for access to a secured area if approved by a supervisor, where the list may include identification information for each listed employee. In the example, to authenticate the employee, the server may be configured (e.g., programmed) to compare (e.g., match) the identification information in the request from the employee's mobile device to the identification information in the requester database. If the identification information in the request does not match identification information in the requester database, the server may send a signal to the employee's device via the application program code on the device indicating that access has been denied (<NUM>). In some cases, the application program code on the employee's device may display a screen indicating why access was denied (e.g., identification information in the request did not match identification information in the requester database), but this is not required. Additionally, or alternatively, the application program code on the employee's device may display a screen asking the employee to try submitting its request with identification information again in response to the denied access signal from the server.

If the server is able to authenticate the employee's provided identification information (e.g., the employee's identity) at step <NUM>, the server may send the employee's secured area access request to and the request may be received at a supervisor's device (e.g., a second device such as mobile device <NUM>) for approval or denial of the request (<NUM>), where the supervisor is listed in the requester database as being approved for reviewing secured area access requests from that employee and/or is approved for reviewing secured area access requests for the requested secured area. In response to receiving an employee secured area access request from the server, the supervisor's device may open an application program code screen on the device and the application program code may display a screen asking the supervisor to approve or deny the request (<NUM>). If the supervisor selects a deny button on the screen provided by the application program code, the request will be denied (<NUM>) and the supervisor's device may send a signal to the server indicating the secured area access request has been denied. The server may then relay the denial of the request to the employee's device. The relay of the denial may or may not indicate why the request was denied (e.g., because the supervisor denied the request).

As an alternative to selecting a deny button on a screen provided by the application program code, the supervisor may not answer the employee's request and after a period of time without a response from the supervisor's device, the server may be configured to relay a signal to the employee's device that its secured area access request has been denied. Such a signal may or may not indicate why the request was denied (e.g., because the request was not answered by the supervisor).

In some cases, when an employee's secured area access request is not answered by a supervisor, the server may be configured to try sending the request to a different supervisor associated with the employee and/or the requested secured area. The server may be configured to send the request to a different supervisor automatically upon receiving a denial of access due to a request not being answered or in response to a request to do so from the employee's device.

If the supervisor approves of the secured area access request, the supervisor may begin a request approval process by selecting a button on a screen displayed by the application program code on its device or through other input. Once the request approval process has been initiated, the application program code may display a screen requesting the supervisor provide identification information (e.g., supervisor or user identifiable information) via the supervisor's device. In one example, the requested identification information may include at least one password or PIN and at least one piece of biometric information. Other information may be requested as desired. The supervisor may enter its password or PIN and its biometric information (<NUM>) and the approval of the request for access to the secured area may be sent to and received at a server of the access control system <NUM> for authentication and further processing (<NUM>).

At step <NUM>, the server may authenticate the supervisor's provided identification information. In one example, as referred to above, the server may include a supervisor database that includes a list of supervisors and associated employees that are authorized for approving access to a secured area for the associated employees, where the list may include identification information for each listed supervisor. In the example, to authenticate the supervisor, the server may be configured to compare (e.g., match) the identification information in the approval from the supervisor's device to the identification information in the supervisor database. If the identification information in the approval does not match the identification information in the supervisor database, the server may send a signal to and the signal may be received at the employee's device via the application program code on the device indicating access has been denied (<NUM>) and, optionally, the server may send a signal to and the signal may be received at the supervisor's device via the application program code on the device indicating that authentication could not be confirmed. In some cases, a screen provided by the application program code on the employee's device may indicate why access was denied (e.g., because identification information in an approval did not match identification information in the supervisor database), but this is not required. Additionally, or alternatively, the application program code on the employee's device may display a screen asking the employee to try submitting its request with identification information again in response to the denied access signal from the server. Similarly, the application program code on the supervisor's device may display a screen asking the supervisor to try submitting an approval again in response to the denied authentication of the supervisor's identification information.

If the server is able to authenticate the supervisor's provided identification information (e.g., the supervisor's identity) at step <NUM>, the server may send a signal (e.g., a "door open" command) to and the signal may be received at a control panel of the access control system to allow access to the secured area through the door (<NUM>). The access devices at or adjacent the secured area may be configured to provide an indication (e.g., visual, audio, and/or sensual indication) that the employee may access the secured area. Optionally, the server may send a signal indicating the supervisor's approval of the employee's secured area access request to and the signal may be received at one or more of the employee's device and the supervisor's device.

In some cases after step <NUM>, a process of securing access to the secured area may be complete. Alternatively, and optionally (as indicated by surrounding steps <NUM>-<NUM> in a dotted box), after the supervisor approves a secured area access request, the server may send a signal to the supervisor's device from the control panel of the access control system <NUM> that includes a video feed or an invitation to view a video feed form one or more cameras (e.g., surveillance cameras) located adjacent the door of a secured area (e.g., inside or outside of the secured area) and/or at other locations around and/or within the secured area. The signal from the control panel may cause the application program code on the supervisor's device to automatically display a screen with the video feed or may cause the application program code to display a screen prompting the user to display the video feed (<NUM>) or deny playing the video feed. At step <NUM>, the supervisor may choose whether to view the video feed or end the process of securing access to the secured area. If the supervisor chooses to view the video feed, the supervisor may be able to view video from the cameras while the employee is in the secured area (<NUM>) by accepting the video feed on a screen displayed on its device, selecting a button on a screen displayed by the application program code, by not closing the screen displayed by the application program code, and/or by taking one or more other actions or by doing nothing. If the supervisor chooses not to view the video feed or decides to end the video feed, the supervisor may end the process of securing access to the secured area (<NUM>) by selecting a button on a screen displayed by the application program code, by closing a screen displayed by the application program code, and/or by taking one or more other actions or by doing nothing.

Claim 1:
A system (<NUM>) for providing access to a secure room, the system (<NUM>) comprising:
a server (<NUM>) comprising:
a processor (<NUM>);
memory (<NUM>) in communication with the processor (<NUM>), the memory (<NUM>) storing a requester database and a supervisor database;
wherein:
the server (<NUM>) is configured to receive a request for access to a secured room from a first device (<NUM>) associated with a first user listed in the requester database;
the server (<NUM>) is configured to receive approval from a second device (<NUM>) for granting access to the secured room in response to the request for access, where the second device (<NUM>) is associated with a second user listed in the supervisor database; and
the server (<NUM>) is configured to send an instruction to provide access to the secured room in response to receiving approval for granting access to the secured room, wherein the server (<NUM>) is configured to authenticate:
the first user of the first device (<NUM>) from which the request for access to a secured room is received; and
the second user of the second device (<NUM>) from which the approval for granting access to
the secured room is received, wherein the request for access to the secured room comprises a confirmation the first device (<NUM>) is adjacent to the secured room,
wherein the request for access to the secured room comprises one or more pieces of user identifiable information of the first user, and the server (<NUM>) uses the one or more pieces of user identifiable information of the first user to authenticate the first user's identity, wherein the one or more pieces of user identifiable information of the first user include one or more of a finger print, a facial recognition, a retina scan and/or alternative biometric information from a biometric reader (<NUM>), wherein the approval for granting access to the secured room includes two or more pieces of user identifiable information of the second user, and the server (<NUM>) uses the two or more pieces of user identifiable information of the second user to authenticate the second user's identity.