WO2018218297A1

WO2018218297A1 - Physical access control systems and methods

Info

Publication number: WO2018218297A1
Application number: PCT/AU2018/050532
Authority: WO
Inventors: John Kininmonth Kane; Rafi Muller Leigh; David Christopher Frylinck; Jimmy Fang
Original assignee: Commonwealth Bank Of Australia
Priority date: 2017-05-31
Filing date: 2018-05-31
Publication date: 2018-12-06

Abstract

Systems and methods for providing access to a physical asset are provided. The method according to one aspect comprises: receiving an access request from a first computing system, the access request comprising identification information received from a requesting user; determining whether the requesting user is authorized to access the physical asset based at least on a verification of the requesting user identification information; upon determining that the requesting user is authorized, retrieving a task associated with the physical asset and the requesting user, the task comprising information about an authorizing user; authenticating the authorizing user; and in response to authenticating the authorizing user, generating and transmitting a control signal to the first computing system to allow access to the physical asset.

Description

PHYSICAL ACCESS CONTROL SYSTEMS AND METHODS

TECHNICAL FIELD

[0001] Aspects of the present invention are directed to physical access control systems and methods, and more particularly to remote authentication physical access control system and methods.

BACKGROUND

[0002] It is often desirable to control access to physical assets. Such assets may include, e.g., safes, vaults, secure locations (building sites, offices, and dwellings).

[0003] Various access control measures are available to choose from - but the ultimate selection usually depends on the level of security required. For example, simple mechanical lock and key arrangement may be sufficient to secure low value physical assets and/or assets in low crime areas, but more complex control systems may be necessary for high value assets and/or assets in high-security.

SUMMARY

[0004] According to a first aspect of the present invention, a method for providing access to a physical asset is provided. The method comprises: receiving an access request from a first computing system, the access request comprising identification information received from a requesting user; determining whether the requesting user is authorized to access the physical asset based at least on a verification of the requesting user identification information; upon determining that the requesting user is authorized, retrieving a task associated with the physical asset and the requesting user, the task comprising information about an authorizing user; authenticating the authorizing user; in response to authenticating the authorizing user, generating and transmitting a control signal to the first computing system to allow access to the physical asset.

[0005] According to a second aspect of the present invention, a method for providing access to a physical asset is provided. The method comprises: receiving identification information from a requesting user at an asset computing device and transmitting the received identification information to a remote computing device; receiving confirmation, at the asset computing device, from the remote computing device that the requesting user is authorized to access the physical asset and at least one task associated with the physical asset and the requesting user is scheduled; receiving an unlock control signal from the remote computing device; and transmitting the unlock control signal to an electronic lock associated with the physical asset to cause the electronic lock to unlock.

[0006] According to a third aspect of the present invention, a system for providing access to a physical asset is provided. The system comprises: a processor, and a non-transitory computer-readable storage medium storing sequences of instructions. The instructions when executed by the processor, cause the processor to: receive an access request from a first computing system, the access request comprising identification information received from a requesting user; determine whether the requesting user is authorized to access the physical asset based at least on a verification of the requesting user identification information; upon determining that the requesting user is authorized, retrieve a task associated with the physical asset and the requesting user, the task comprising information about an authorizing user; authenticate the authorizing user; in response to authenticating the authorizing user, generate and transmit a control signal to the first computing system to allow access to the physical asset.

[0007] According to a fourth aspect of the present invention, a system for providing access to a physical asset is provided. The system comprises: a processor, and a non- transitory computer-readable storage medium storing sequences of instructions. The instructions when executed by the processor, cause the processor to: receive identification information from a requesting user and transmit the received identification information to a remote computing device; receive confirmation from the remote computing device that the requesting user is authorized to access the physical asset and at least one task associated with the physical asset and the requesting user is scheduled; receive an unlock control signal from the remote computing device; and transmit the unlock control signal to an electronic lock associated with the physical asset to cause the electronic lock to unlock.

[0008] Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In the drawings:

[0010] Fig. 1 is a block diagram of a networked environment according to aspects of the present disclosure.

[0011] Fig. 2 is a block diagram of a computing system in which aspects of the present disclosure may be implemented.

[0012] Fig. 3 is a flowchart illustrating an exemplary method for creating and storing a new task according to some aspects of the present disclosure.

[0013] Fig. 4 illustrates a method for providing access to a physical asset according to some aspects of the present disclosure.

[0014] Fig. 5 illustrates a method for authenticating a user requesting access to a physical asset according to some aspects of the present disclosure.

[0015] Fig. 6 illustrates a method for requesting an authorizing user to authorize access to a physical asset according to some aspects of the present disclosure.

[0016] Fig. 7 illustrates a method for unlocking an ATM enclosure according to some aspects of the present disclosure.

[0017] Fig. 8 illustrates a method for monitoring the ATM enclosure according to some aspects of the present disclosure.

[0018] Fig. 9 is a block diagram of a networked environment according to another aspect of the present disclosure.

[0019] While the invention is amenable to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are described in detail. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. The intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. DETAILED DESCRIPTION

[0020] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessary obscuring.

Environment Overview

[0021] The present disclosure generally relates to access control systems and methods that may be utilized for controlling access to physical assets - such as buildings, sites, rooms, vaults, safes, automated teller machines (also referred to as banking kiosks and automated banking machines), etc. In the present disclosure, the control access methods and systems will be described with respect to a banking example and more specifically with respect to an automated teller machine (ATM). However, it will be appreciated that the disclosed systems and methods can be easily adapted for securing and controlling access to any other physical asset without departing from the scope of the present disclosure.

[0022] ATMs are electronic telecommunication devices that enable customers to perform financial transactions without the need of a teller. Typical functions of an ATM machine include cash withdrawals, cash and cheque deposits, and/or dispensing banking cards (such as debit and credit cards). To perform these functions, ATMs typically include one or more safes for storing cash and/or bank cards, computing systems configured to perform these functions, network devices to allow the ATM to communicate with external systems, and power supply modules. These components are generally encased in a highly-secure outer casing to prevent theft and/or any kind of tampering.

[0023] Over the years, as ATM technology has progressed, security measures to protect ATMs and their components have also become significantly more advanced. These days, there are many aspects to ATM security - physical security of the machine itself (e.g., to protect against theft and ram-raiding), computer security (e.g., to protect against cyberattacks), transaction security (e.g., to prevent card skimming during customer transactions), and maintenance security (e.g., to prevent unauthorized access to the ATM enclosure). [0024] While physical, computer, and transaction security measures usually protect the ATM from outsiders, there can also be a need to protect from insiders (i.e., people who are typically responsible for maintenance or replenishment of ATMs). Maintenance security typically deals with this type of protection.

[0025] Devising security measures against staff is characteristically challenging because it can require shared access among several companies including parties responsible for replenishing cash and collecting deposits, as well as those providing maintenance or repair of the ATMs.

[0026] One approach to security involves a dual-access control measure, which requires two people to simultaneously unlock the ATM. Dual-access control can be effective if implemented properly. Firstly, to commit a crime, two people have to consent and be involved, which is often more difficult, requires more planning, and increases the likelihood of getting caught as compared to committing a crime by oneself. Secondly, dual-access control not only protects the ATM from insiders but also protects it from outside criminals. A criminal has to coerce two people in order to gain access to the ATM. If both people are not present at the time of the robbery, the ATM cannot be opened.

[0027] However, even with dual access control as currently implemented, the ATM may be vulnerable to security threats.

[0028] Aspects of the present disclosure provide systems and methods that create an electronic event (referred to as a task in this disclosure) whenever a maintenance task needs to be performed for a physical asset. The electronic event defines the task, the estimated time required to complete the task, and the maintenance staff authorized to perform the task. When a user requests access to the physical asset, the system determines whether the requesting user is the authorized maintenance staff and whether he/she is scheduled to perform a maintenance task (by comparing user provided information with information stored in the electronic event). If based on the comparison, the requesting user is identified as the authorized maintenance staff, the ATM enclosure is remotely unlocked for the specific amount of time indicated in the electronic event to complete the task.

[0029] In addition, the ATM enclosure may be unlocked after a second user (also referred to as an authorizing user) authorizes that particular task. The authorizing user may be physically present at the ATM site with the requesting user or he/she may be at a remote location. Having a second user authorize the access request adds another level of security, similar to the dual-access control measures used on some previously-known ATMs. In some embodiments, the authorizing user is also authenticated before access can be granted to the ATM enclosure.

[0030] In certain embodiments, the presently disclosed systems and methods are also configured to automatically lock the ATM enclosure door after the assigned task is completed. Moreover, the systems and methods monitor the ATM enclosure door(s) and/or lock(s) and if the enclosure door(s) remains open for a period of time greater than an estimated time to complete the assigned task, the systems and methods are configured to generate an alarm and/or initiate a lockdown procedure.

System overview

[0031] Fig. 1 illustrates a networked environment 100 in which aspects of the present disclosure may be implemented. The environment 100 includes one or more physical assets (e.g., ATMs 101A, 101B and 101C) and a central server 102. Each physical asset 101 is associated with a computing system (e.g., asset computing systems 104A, 104B and 104C) and is secured by one or more electronic locks (e.g., electronic locks 106A, 106B, 106C, and 106D). The central server 102 communicates with the asset computing systems 104 over one or more communication networks 108. Furthermore, the electronic locks 106 can communicate with their respective asset computing systems 104 via communication links 107. In addition to asset computing systems 104, the environment 100 may also include one or more client devices (e.g., devices 109A and 109B). The client devices 109A and 109B may communicate with the central server 102 (see client device 109A) and/or the asset computing systems 104 (see client device 109B).

[0032] Generally speaking, the central server 102 controls and monitors ATM access during maintenance-related tasks. To that end, the central server 102 includes a task management module 114 to manage tasks and an access control module 116 to authenticate personnel, control and monitor status of the electronic locks 106 associated with the ATMs, and take corrective actions when certain conditions are met.

[0033] In addition, the central server 102 is configured to update and retrieve information from a number of databases from time to time. These databases include a task database 110 (to store task-related information), and an identification database 112 (to store user identification information).

[0034] The task database 110 is configured to store task information in respect of tasks. A variety of task information may be recorded and stored for a given task, e.g., against a unique task ID. For a given task ID, such information may include, e.g., information about the task type (e.g., cash replenishment, computer software update, etc.), the physical asset associated with the task, the person assigned to complete the task, the person assigned to authorize the task, date the task was created, intended completion date, task status, and so on.

[0035] An example of a data structure storing task information is illustrated in Table A below. Although a table is used to illustrate the data structure, the relevant information need not be stored in a table and could be stored in any appropriate format.

Table A: Example task information data structure

[0036] In the above example table, for each unique task ID, the task database 110 stores:

• task type ID (allowing identification of a type of the task),

• Asset ID (to identify the particular asset at which the task is to be performed. In some cases this may be an ID assigned to the asset, whereas in other cases this may be an ID assigned to the asset computing systems 104),

• task assignee (a user ID identifying person/company/role),

• task authorizer (a user ID identifying person/company/role),

• creation date (indicating when the given task was created),

• intended completion date (indicating when the task should be completed), and

• task status (pending, in progress (and if in progress, commencement time), completed (and if completed, completion time)).

[0037] In addition to task information, the task database 110 may also store certain information related to access control. For instance, it may store a list of the type of tasks that can be performed on ATMs in the environment 100 and for a given task type, it may store the estimated time required to complete the task, the corresponding ATM enclosure(s) that needs to be opened to perform the task, and the personnel/organizations/roles that can be assigned to complete the task.

• Table B below shows an example of a data structure for storing this information (in this case as a single table).

Table B: Example lookup table for task type information [0038] In this example, for a given unique task type ID, the task database 110 stores:

• task description (e.g. computer system maintenance, power system maintenance, cash refill, cash collection, or card refill),

• ATM type (e.g., ATM brand and model),

• estimated time to complete the task type, and

• locklD(s) (identifying electronic lock(s) involved in completing the task type - e.g. main enclosure, cash enclosure, card enclosure, computer enclosure, power system enclosure).

[0039] The task database 110 may also store information about the assets (e.g., ATMs) in the environment 101. For example, it may store information about the brand and model of an ATM, where the ATM is located, whether the location is secure or not, and/or the types of functions the ATM can perform (i.e., dispense cash and receive deposits, only dispense cash, dispense cash and cards, etc.).

[0040] Table C below shows an example of a data structure for storing this information (in this case as a single table).

Table C: Example lookup table for asset information

[0041] In this example, for a given unique Asset ID, the task database 110 stores:

• the type of physical asset, and

• the location of the physical asset.

[0042] The identification database 112 stores identification information about task assignees and authorizers. This information may include, for example, user profile information such as name, employee ID, badge ID, access card code, role, organization, address, phone number, email address, or any other such information about a person. The identification information may also include one or more biometric samples, such as fingerprint images, retinal images, facial images, and/or voice prints. [0043] Table D below show an example of a data structure for storing this information (in this case as a single table).

Table D: Example user information table [0044] In this example, for a given unique user ID, the identification database 112 stores:

• role (e.g. finance manager, maintenance staff, supervisor, etc.),

• user name,

• organisation (e.g. name of organisation person works for),

• communication information (e.g. mobile, email, pager numbers), and

• biometric data (e.g., fingerprint scan, retinal scan, or photograph).

[0045] The information stored in databases 110 and 112 may be stored in one or more data structures. For example, it may be stored in multiple linked tables (e.g., a relational database). Furthermore, it will be appreciated that the information depicted in the example tables A-D is merely representative and the data structure may include additional, fewer, or alternative fields without departing from the scope of the present disclosure.

[0046] The databases may be maintained by the central server 102 or by third parties (not shown). For example, the identification database 112 (or even just the biometric information) may be controlled and maintained by a central regulatory authority. It will be appreciated that these databases can be managed and stored in a single memory device or in multiple memory devices without departing from the scope of the present disclosure. Furthermore, the databases may include a single data structure or multiple interrelated data structures. For example, the identification database 112 may include one data structure for user profiles, another data structure for biometric data, and a third data structure for authorization codes, for instance. [0047] In operation, the asset computing systems 104 exchange data with the central server 102 and control operation of the electronic locks 106. To that end, an asset computing system 104 includes one or more installed applications such as an access control client 117, and/or a web browser (not shown). The access control client 117 is a client-side version of the access control module 116 installed on or operative on the central server 102. These server- side and client- side components interact with each other over the communication network 108 to perform their respective functions.

[0048] Particularly, the access control client 117 is configured to receive information entered by a user (such as identification information) on a user-interface of the asset computing system 104, transmit the information to the access control module 116, receive authentication information from the access control module 116, establish a connection with a particular electronic lock 106, receive lock status information from the electronic lock 106, and transmit control signals to lock/unlock the electronic lock 106.

[0049] In certain embodiments, instead of a dedicated access control client 117, the asset computing system 104 simply includes a web browser and communicates with the server 102 and/or the electronic locks 106 via the web browser.

[0050] Each asset computing system 104 may include a single computer (e.g., a computing device configured to perform user-facing operations and backend operations) or multiple computers (e.g., a user-facing computer operatively connected to a backend computer). The user-facing computer may be configured to receive identification information from a user requesting access to the ATM and provide status information to the user, whereas the backend computer may be configured to communicate with the central server 102 and the electronic locks and monitor status of the electronic locks and ATM enclosure doors.

[0051] In certain cases, for example, when a portion of the asset computing system 104 crashes or loses power, an external client device (e.g., 109B) may be connected to the ATM (e.g., ATM 101A) to perform certain operations of the corresponding asset computing system (e.g., computing system 104A). In some embodiments, these operations include the user- facing operations of the asset computing system 104. The external client device 109B may be connected wirelessly or with a wired connection. For example, external device 109B may be connected via a specialized port and cable to the ATM 101 A and may be configured to run the access control client 117 and/or a web browser (not shown). With this configuration, the external client device 109B can receive identification information from a user requesting access to the ATM 101A, provide status updates to the requesting user, and communicate directly with the central server 102 or via the asset computing system 104.

[0052] From time to time, task information is created and stored in the task database 110. In some embodiments, a user may utilize a client device (such as client device 109 A) to create and manage task information. To that end, the client device 109 may include one or more installed applications such as a task management client 115. The task management client 115 is a client-side version of the task management module 114 installed on or operative on the server 102. These server-side and client-side components interact with each other over the communication network 108 to perform their respective functions.

[0053] Particularly, the task management client 115 is configured to provide a user interface to receive task information from a user, display task information, and allow the user to edit or manage the task information. Furthermore, the task management client 115 is configured to communicate with the task management module 114 to save task information in the task database 110 and retrieve task information from the task database 110.

[0054] It will be appreciated that although only two client devices 109 A and 109B, and three physical assets 101A, 101B and 101C are illustrated, normal operation of the access control environment 100 typically involves many more client devices and physical assets connected to the server 102.

[0055] Generally speaking, an ATM includes multiple secured enclosures. For example, it may include an enclosure for cash, another for bank cards, a third for computing devices, and a fourth for power management equipment. Each of these enclosures may be secured by a lock. When cash needs to be replenished, a maintenance officer may unlock the cash enclosure, replace the cash, and lock the cash enclosure. Similarly, if a computer component needs to be replaced, a technical officer may unlock the computer enclosure, perform replace the component and lock the computer enclosure. By restricting access to required components, the risk of theft and/or tampering can be minimized. The ATM may also include an outer enclosure door that encloses the individual enclosures.

[0056] In the presently disclosed systems and methods, an electronic lock 106 as disclosed in the present disclosure may be fitted each of the individual enclosure doors, on a few of the individual enclosure doors, or only on the outer enclosure door. For example, an electronic lock 106 may be fitted on the doors of the cash or card enclosures, but not on the power management or computer hardware enclosures. Alternatively, an electronic lock 106 may be fitted on the outer enclosure door, whereas doors of the individual enclosures may be fitted with conventional locks.

[0057] The communication link 107 between an asset computing system 104 and a corresponding electronic lock 106 may be established using any known communication standard or protocol, such as Wi-Fi, Bluetooth, or near field communication (NFC). Once the connection is established, the electronic lock 106 is configured to receive unlock/lock control signals from the asset computing system 104, generate electrical signals to unlock or lock the electrical components, and provide lock status information (such as unlocked or locked state information) to the asset computing system 104.

[0058] In the implementation described with reference to Fig. 1, each physical asset includes an asset computing system 104. It will be appreciated that in other implementations, (e.g., when the physical asset is a safe), the physical asset may not include its own asset computing system 104. In such cases, the external client device 109 may communicate directly with the electronic lock 106 to control its operation and with the central server 102 to authenticate users and provide lock information.

[0059] Operation of these various devices and modules will be described in detail with reference to Figures 2-7.

Hardware overview

Electronic Lock

[0060] Each electronic lock 106 includes basic locking components such as one or more bolts, a latch, cylinder or cam, and a motor which upon receiving an electrical signal provides the mechanical force required to move the bolt between an Open' and a 'closed' position. In addition to these basic lock components, the electronic lock 106 further includes computer hardware and software components. For example, the electronic lock 106 may include a communication module (not shown) that allows the asset computing system 104 to establish a communication link 107 with the electronic lock 106, one or more microcontrollers (not shown) to receive control signals, activate the motor, send lock status information from and to the computing system 104, and provide information about the time period for which the electronic lock and/or door has been in an unlocked and/or open position. The electronic lock 106 may further include one or more sensors such as micro switches to detect the position of the mechanical components of the lock.

Computing devices

[0061] The operations/techniques described herein are implemented by one or more special-purpose computing systems or devices. For example, in environment 100: central server 102 may be provided by one or more computer systems, the asset computing systems 104 may be provided by one or more computer systems, and the client devices 109 are computer systems.

[0062] A special-purpose computing system may be hard-wired to perform the relevant operations. Alternatively, a special-purpose computing system may include digital electronic devices such as one or more application- specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the relevant operations. Further alternatively, a special-purpose computing system may include one or more general purpose hardware processors programmed to perform the relevant operations pursuant to program instructions stored in firmware, memory, other storage, or a combination.

[0063] A special-purpose computing system may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the relevant operations described herein. A special-purpose computing system may be a desktop computer system, a portable computer system, a handheld device, a networking device or any other device that incorporates hard- wired and/or program logic to implement relevant operations.

[0064] By way of example, FIG. 2 provides a block diagram that illustrates one example of a computer system 200 upon which embodiments of the invention may be implemented. Computer system 200 includes a bus 202 or other communication mechanism for communicating information, and a hardware processor 204 coupled with bus 202 for processing information. Hardware processor 204 may be, for example, a general purpose microprocessor, a graphical processing unit, or other processing unit.

[0065] Computer system 300 also includes a main memory 206, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 202 for storing information and instructions to be executed by processor 204. Main memory 206 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 204. Such instructions, when stored in non-transitory storage media accessible to processor 204, render computer system 200 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0066] Computer system 200 further includes a read only memory (ROM) 208 or other static storage device coupled to bus 202 for storing static information and instructions for processor 204. A storage device 210, such as a magnetic disk or optical disk, is provided and coupled to bus 202 for storing information and instructions. For example, in case the computer system 200 is the central server 102, the storage device 210 may store data from the task database 110 and/or the identification database 112.

[0067] In case the computer system 200 is the client device 104, the computer system 200 may be coupled via bus 202 to a display 212 (such as an LCD, LED, touch screen display or other display), for displaying information to a computer user. An input device 213, including alphanumeric and other keys, may be coupled to the bus 202 for communicating information and command selections to processor 204. Another type of user input device is cursor control 214, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on display 212.

[0068] Furthermore, in case the computer system 200 is an asset computing system 104 or a client device 109, the computer system 200 may further be coupled via bus 202 to any one or more of a biometric reader 216, a camera 215, and an RFID reader 217.

[0069] According to one embodiment, the techniques herein are performed by computer system 200 in response to processor 204 executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another storage medium, such as a remote database. Execution of the sequences of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0070] The term "storage media" as used herein refers to any non-transitory media that stores data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 210. Volatile media includes dynamic memory, such as main memory 206. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0071] Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 202. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications .

[0072] Computer system 200 also includes a communication interface 218 coupled to bus 202. Communication interface 218 provides a two-way data communication coupling to a network link 220 that is connected to the communication network 108. For example, communication interface 268 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, etc. As another example, communication interface 218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 218 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0073] When the computer system 200 is an asset computing system 104, the communication interface 218 may further include means for establishing a connection with one or more electronic locks 106. For example, the communication interface may include a Bluetooth module, a Wi-Fi module or an NFC module to establish a Bluetooth, Wi-Fi or NFC data communication connection with the electronic lock(s) 106 via communication link 107.

[0074] Computer system 200 can send messages and receive data, including program code, through the network 108, network link 220, communication link 107, and communication interface 218. In case the computer system hosts the server 102, the computer system 200 may receive identification information from the client device 104 via the network 108, network link 220, and communication interface 218. The received identification information may be executed by processor 204 as it is received, and/or stored in storage device 210, or other non-volatile storage for later execution. Alternatively, in case the computer system 200 is the client device 104, the computer system 200 may receive lock status information from an electronic lock 106 via the communication link 107, and communication interface 218.

[0075] As described previously, the computer system 200 as described above may be configured in a plurality of useful arrangements. In one arrangement, the computer system 200 is a server computer (such as a computer system hosting the central server 102) comprising one or more non-transitory computer-readable data storage media stored with one or more sequences of instructions/software modules such as the task management module 114 and the access control module 116 which when executed cause the computer to perform the operations/techniques that are described herein.

[0076] In another arrangement, the computer system 200 is an asset computing system 104 or a client device 109 comprising one or more non-transitory computer-readable data storage media stored with one or more sequences of instructions/software modules such as the task management client 115 and/or the access control client 117 which when executed cause the computer to perform the operations/techniques that are described herein.

Task creation

[0077] Each time an ATM (e.g., ATM 101A) requires maintenance or replenishment, a task is created and information about the task is stored in the task database 110. The task may be created by an administrator, or an authorized representative of a maintenance company, a replenishment company, a bank, or any other third party authorized to create and store task information when ATM related jobs need to be completed.

[0078] Fig. 3 illustrates an exemplary method 300 for creating and storing a new task. The method 300 begins at step 302, where a new unique task ID is generated. To that end, an authorized user (such as the authorizing user) may access the task management client 115 on his/her client device (e.g., client device 109A) and select an option to create a 'new task' . In one example, the task management client 115 may display a homepage or a dashboard and one or more options to manage, edit, or create tasks. When the user selects the 'new task' option, the task management client 115 sends a new task request to the task management module 114, which generates the new task ID.

[0079] At step 304, information about the task is received by the task management client 115. As noted previously, the task information includes information about the ATM, information about the person assigned to complete the task (assignee), and information about the type of task. Information about the ATM may include an identifier (such as an asset ID or location) that uniquely identifies a particular ATM. Information about the assignee may similarly include an identifier (such as an employee ID and/or a name) that uniquely identifies the assignee, and information about the type of task may include a task type ID and/or a task description, for example.

[0080] This information may be provided using any known techniques such as entering data via an electronic form, drop-down menus, or lists. The drop down menus may be prepopulated from lookup tables stored in the task database 110. For example, the task management module 114 may retrieve information about all the ATMs 101 controlled by the central server 102 (e.g., from table C) and display information about these ATMs in a dropdown menu. Similarly, the task management module 114 may retrieve a list of all personnel authorized to perform maintenance on the ATMs in the environment 100 (e.g., from table B) and a list of all task types associated with the ATMs 101 (e.g., from table B).

[0081] In some cases, the drop-down menus may be interconnected so that selection of an entry in one drop-down menu or list automatically filters the content displayed in subsequent drop-down menus/lists. For example, if a user selects a particular ATM from the list of ATMs, the drop down menu for task type may only display task types that are possible for the selected ATM (for example based on the brand/model of the ATM). Further, selection of a particular task type may filter the drop-down menu/list of assignees to display only those assignees that are authorized to perform the selected task on the selected ATM.

[0082] At step 306, it is determined whether the new task is a duplicate of a task previously created and stored in the task database 110. In one embodiment, the task management client 115 sends the task information received from the user to the task management module 114, which compares the received task information with task information stored in the task database 110. If the received task information is a duplicate (e.g., if the received task type, asset ID, and assignee match the task type, asset ID, and assignee of a previously stored task), the method proceeds to step 308, where the newly- created task is deleted.

[0083] If at step 306 it is determined that no duplicates exist for the task (i.e., the task information of the newly-created task does not match the task information of any pending task), the method proceeds to step 310, where the task management system determines whether a parent task exists for the newly-created task.

[0084] A particular operation, such as installing a new software program, may include multiple individual tasks, e.g., opening the computer enclosure, running a diagnostic test, installing the software, and checking the installed software. In certain embodiments, these individual tasks may be linked to one another through a parent-child relationship, such that a parent task must be completed before a child task can be started. The task database may store a hierarchy of such parent-child tasks.

[0085] In such embodiments, at step 310, the task management module 114 determines whether the newly created task is a parent task or a child task and if it is a child task, the task management module 114 determines whether a parent task is already created. In certain embodiments, the task management module 114 may check the task type ID and Asset ID of currently pending tasks to determine if a task matching a parent task for the newly created task is present.

[0086] If at step 310 it is determined that a parent task exists, the task management module 114 sets the assignee of the newly-created task as the assignee to complete the parent task at step 314.

[0087] On the other hand, if it is determined that a parent task does not exist, the task management module 114 creates the corresponding parent task at step 312 and then proceeds to step 314.

[0088] Next, at step 316, the task management module 114 determines a suitable authorizing user for the task. In one embodiment, the task management module 114 may identify a specific person to be the authorizing user. In another embodiment, a suitable role may be identified and any person that matches the identified role can be assigned as the authorizing user.

[0089] In certain embodiments, the authorizing user is selected based on the type of task. In this case, the task management module 114 may perform a lookup in the task database 110 (for example in Table B) to retrieve information about suitable authorizing users or suitable roles for the present task type. For example, if the newly-created task is for cash replenishment, the task management module 114 may look up 'cash replenishment' in table B and retrieve the data stored in the authorizing user field, which in the case is 'finance manager' . Similarly, if the newly-created task is for a software update job, the task management module 114 may look up 'computing system related tasks' in table D and retrieve the data stored in the authorizing user field, which in the case is 'team lead' .

[0090] Once a suitable role is selected, the task management module 114 updates the task with information about the authorizing user (e.g., their name, employee ID, or role) and stores the task information with the unique task ID in the task database 110 at step 318.

[0091] An example of the information stored for a newly created task is illustrated in table E below.

Table E: Example new task

[0092] Once a new task is created, the assignee may be informed. This may be done via email, SMS, voice mail, or a dedicated application that provides alerts to the assignee whenever a new task is assigned. In another embodiment, the alert may be provided to the assignee's organization and the assignee's organization may be responsible for informing the assignee of the pending task(s).

[0093] Furthermore, it will be appreciated that instead of assigning the task to a person, the task may be assigned to an organization or company that handles the corresponding task types. In these cases, the alert may be provided directly to the organization, and the organization may subsequently assign the task to a particular user (i.e., someone whose identification information is already provided to the central server 102) based on the urgency of the task and the work schedules of the staff.

[0094] In certain alternate embodiments, the method 300 may be automatically performed by the task management module 114 without any user intervention. Specifically, the task management module 114 may automatically create a new task ID and populate task information (including ATM, task type, assignee, and authorizing user information). This may be possible for tasks that need to be completed on a fixed schedule (e.g., weekly cash replenishments or daily deposit withdrawals), or for routine tasks (e.g., in cases where an ATM 101 automatically requests cash or card refills when volumes are running low). In these cases, the task management module 114 knows the asset identifier and the task type and retrieves assignee and authorizing user information from the task database 110.

Access control

[0095] Fig. 4 illustrates an exemplary method 400 for providing access to a physical asset. For illustrative purposes the physical asset is considered to be an ATM in the following methods. However, it will be understood that the method may be suitably adapted for any other type of physical asset without departing from the scope of the present disclosure.

[0096] The method 400 begins at step 402, where an access request is received at the access control module 116. The access request may include a physical asset identifier (e.g., an asset ID) and user identification information. In one embodiment, a requesting user (i.e., a person requesting access to the ATM) may interact with the access control client 117 on an asset computing system 104 and enter their identification information using input device 213. In some embodiments, the access control client 117 may prompt the requesting user to enter their identification information. In other embodiments, the requesting user may enter the information without any prompts.

[0097] The user identification information may include any information that is unique to the requesting user and allows the access control module 116 to authenticate the requesting user. Examples of user identification information include name and password, telephone number, answer to a secret question, a unique authorization code, an image, an employee code, an access card code or biometric information, etc. Moreover, the requesting user may utilize a suitable input device to provide the identification information. For example, they may enter the information using input devices 213, 214, access card reader 217, camera 215, or biometric reader 216.

[0098] The requesting user may be requested to enter a single type of identification information or multiple types of identification information. For illustrative purposes, the remainder of this process assumes that the requesting user provides two types of identification information - 1) a unique identification code associated with the user (perhaps by bringing an access card assigned to the user in proximity to the card reader 217) and 2) biometric data (e.g., fingerprint scan). In this case, once the requesting user provides the unique identification code, the access control client 117 may prompt the requesting user to provide their biometric data. The user may do so using the biometric reader 216.

[0099] If the entered biometric data is not collected correctly (e.g., if the user moved their finger, eye, or face too quickly, did not place the corresponding body part correctly on/near the reader, or moved it during the scanning), the access control client 117 may request the user to retry. Once the biometric data is received correctly, the access control client 117 forwards the unique identification code and the biometric data to the access control module 116 over the communication network 108.

[00100] In one embodiment, the access control client 117 may automatically add the asset identifier to the communication when transmitting the user identification information to the access control module 116.

[00101] At step 404, the access control module 116 attempts to authenticate the requesting user (i.e., determine whether the requesting user should be granted access to the physical asset 101 or not). This may be done by verifying the received identification information. The verification process is described in detail with reference to Fig. 5.

[00102] At step 404, if the access control module 116 fails to authenticate the user, the method proceeds to step 406, where access is denied to the requesting user (and the method 400 ends. In certain embodiments, the access control module 116 may generate and transmit a 'fail' signal to the access control client 117. The access control client 117 may subsequently display an error message, such as 'access not granted' on the display 212.

[00103] Alternatively, if at step 404 the access control module 116 succeeds in authenticating the requesting user, the method proceeds to step 408, where it is determined whether a pending task for the ATM 101 is assigned to the requesting user. In certain embodiments, the access control module 116 performs this check by looking up in the task database 110 and finding any pending task that has an asset identifier matching the asset identifier received at step 402 and that has an assignee identifier matching the identifier of the requesting user verified at step 404.

[00104] If the access control module 116 fails to find a pending task for the ATM assigned to the requesting user, the method proceeds to step 406 where access is denied to the ATM 101 (and the method ends). In certain embodiments, the access control module 116 generates and sends an error message to the access control client 117. The access control client 117 may also notify the requesting user using some form of notification such as a message displayed on the display 212.

[00105] On the other hand, if at step 408 the access control module 116 finds a pending task assigned to the requesting user at the ATM 101, information in respect of the related task information is retrieved from the task database 110 at step 410.

[00106] At step 412, an authorizing user is identified for the retrieved task, for example, by obtaining authorizing user information in respect of the task. In certain embodiments, the authorizing user role ID in respect of the task may be retrieved and compared with role IDs in the identification database 112 to identify an authorizing user.

[00107] Next, at step 414, the identified authorizing user is authenticated. This step is described in further detail with references to Fig. 6.

[00108] At step 416, it is determined whether the task assigned to the requesting user at the ATM is authorized. If at this step it is determined that the task is successfully authorized, access is granted to the ATM enclosure at step 418. Conversely, if at step 416 it is determined that the task is not authorized, the method proceeds to step 406 where access is denied to the ATM 101 (and the method ends).

[00109] In certain embodiments, at step 420, in order to grant access, the access control module 116 identifies the electronic lock or locks 106 that need to be unlocked to allow the requesting user to perform the pending task assigned to the requesting user. To that end, the access control module 116 performs a lookup in the task database 110 to determine the particular lock or locks which are involved with the authorized task. At this stage, the access control module 116 may also optionally perform a lookup in the task database 110 to determine the estimated time required to complete the assigned task.

[00110] With this information, at step 422, the access control module 116 generates and sends a command signal to the access control client 117 to send an 'unlock' control signal to the identified electronic lock or locks 106. The steps performed by the access control client 116 once it receives the command signal are described in detail with references to Fig. 7.

[00111] Process 400 as described above assumes a single pending task related to the ATM and requesting user is identified at step 408. In certain cases, however, the access control module 116 may identify multiple pending tasks assigned to the requesting user at that ATM. In such cases, if all the identified tasks have the same parent task (and the same task authorizer), the access control module 116 may retrieve the parent task in step 410. Thereafter, the process 400 remains the same. This is because the parent task includes information about a single authorizing user and that authorizing user is sufficient to authorize all the identified tasks. Alternatively, if all the identified tasks do not have the same parent, the access control module 116 retrieves information in respect of each identified task at step 410. Thereafter, if different authorizing roles are defined the access control module 116 identifies the authorizing user/role for each identified task and requests the identified authorizing users to authorize the tasks they are responsible for.

Authentication and authorization methods

[00112] Fig. 5 illustrates an exemplary method 500 for authenticating the requesting user (as performed at step 404 of Fig. 4). It will be appreciated that method 500 describes one particular way of authenticating the requesting user and step 404 of method 400 may just as easily be performed with any suitable authentication process different from the one described here.

[00113] The method begins at step 502, where the access control module 116 attempts to identify the requesting user. To that end, the access control module 116 may perform a lookup of the identification information (e.g., the unique identification code) received from the requesting user at step 402 in the identification database 112 to find any user entries with a matching identification code. It will be appreciated that this step can be performed with any other type of identification information, such as badge ID, employee ID, authorization code, name, telephone number, etc. If a match is found, the access control module 116 identifies the requesting user as the user with the matching identification information. However, if no match is found, the access control module 116 is unable to identify the requesting user.

[00114] If at step 502 the access control module 116 fails to identify the requesting user, the access control module 116 determines that the requesting user is not an authorized person and the method proceeds to step 406 of Fig. 4 (i.e., access is denied to the ATM 101).

[00115] If the requesting user is identified at step 502, the method proceeds to step 504, where the access control module 116 determines whether the received biometric data matches the corresponding biometric data stored for the identified user in the identification database 110. To that end, biometric data for the identified user is retrieved from the identification database 110 and compared with the received biometric data.

[00116] If at step 504 the biometric data matches the stored biometric data, the method proceeds to step 506 where the user is authenticated. In certain embodiments, the access control module 116 may send a 'success' message to the access control client 117. In response, the access control client 117 may optionally display a success message on the display 212 and/or a message informing the first user that the system is waiting for supplementary authorization.

[00117] On the other hand, if at step 504 the received biometric data does not match the stored biometric data, the method proceeds to step 406 of Fig. 4 (i.e., access is denied to the ATM).

[00118] Fig. 6 illustrates a method 600 for authorizing a task (as performed at steps 416 and 418 of Fig. 4). This method 600 describes one technique of receiving authorization information from the authorizing user. It will be appreciated that step 416-418 of Fig. 4 may be implemented using any other suitable authorization technique without departing from the scope of the present disclosure.

[00119] In this case, the authorizing user is assumed to be at a remote location and not proximate to the ATM for which access is required.

[00120] The method begins at step 602, where the access control module 116 receives identification data from an authorizing user. In some embodiments, the access control module 116 may send a notification (associated with a particular task) via the task management module 114 to one or more authorizing users. For example, the notification may be sent to a particular authorizing user (if a user ID is provided in the task that requires authorization) or it may be sent to multiple authorizing users (if a role ID is provided in the task that requires authorization). In this example method, it is assumed that the task is sent to the authorizing users that match the role ID provided in the task for which authorization is required.

[00121] Any one of the authorizing users that receive the notification may provide their identification information at this step.

[00122] The authorizing user may be requested to enter a single type of identification information or multiple types of identification information. The requested identification information may be similar to the identification information required from the first user in method 400.

[00123] Similar to process 500, the remainder of this process assumes that the authorizing user provides two types of identification information - a unique identification code associated with the authorizing user and biometric data. Once the authorizing user provides the identification information (e.g., unique identification code), the access control module 116 identifies the person associated with the identification information (for example by a process similar to that carried out at step 502). At step 604, the access control module 116 also identifies the role associated with the authorizing user for example by retrieving the role from the identification database 110 from the matched user entry.

[00124] At step 606, the access control module 116 determines whether the role is appropriate for the assigned tasks. To this end, the access control module 116 may retrieve the authorizer role from the task database 110 for the assigned tasks and compare that retrieved role with the role identified at step 604. This step may be optional. If the system requests a particular authorizing user to enter their identification information (e.g., by sending a personal message to that particular authorizing user), the system may not perform this step. However, if the access control module sends a general broadcast message via the task management module to multiple authorizing users, this step can be performed.

[00125] If at step 606 the identified role does not match the role assigned to the task, the access control module 116 determines that the role is inappropriate for the assigned tasks and the method proceeds to step 406 of Fig. 4 where access is denied to the physical asset. In certain embodiments, the access control module 116 sends an 'authorization fail' message to the access control client 117 so that the access control client can notify the first user that the authorization has failed.

[00126] If at step 606 the identified role matches the role assigned to the task, the access control module 116 determines that the role is appropriate and the method 600 proceeds to step 608, where the access control module 116 receives biometric data from the authorizing user. The authorizing user may provide the biometric data by using the biometric reader 216 of the client device 109. [00127] If the entered biometric data is not received correctly, the access control module 116 may request the authorizing user to retry. Once the biometric data is received correctly, the method proceeds to step 610.

[00128] Steps 610-614 are essentially similar to the steps 502-506 of Fig. 5. Accordingly, the description of these steps is not repeated.

[00129] In certain embodiments, the authorizing user may not be remote, but present at the asset site with the requesting user. In such cases, once the requesting user is authenticated (see method 500), the authorizing user may be requested to provide their identification details either through the client computing device 104 or via their own client computing device 109. Once the authorizing user is also authenticated (see method 600), access is granted to the asset to perform the tasks the requesting user is authorized to perform.

Physical asset control methods

[00130] Fig. 7 is a flowchart illustrating an exemplary method for providing access to the ATM 101 (e.g., by unlocking an electronic lock 106 securing an enclosure of the ATM 101) after the requesting user has been authenticated and the authorizing user has authorized the task(s) assigned to the requesting user at the ATM 101. Specifically, method 700 commences after the access control client 117 receives a command to send an 'unlock' control signal to the identified electronic lock(s). Method 700 is described with respect to one electronic lock 106; however, it will be appreciated that the method can be repeated for multiple electronic locks.

[00131] The access control client 117 determines whether a connection exists between the asset computing system 104 and the electronic lock 106. As noted previously, any suitable communication protocol (including Wi-Fi, Bluetooth and NFC) may be utilized to establish a connection between the asset computing system 104 and the electronic lock 106. If the protocol utilized is Bluetooth, the communication interface 218 may check if the asset computing system 104 is 'paired' with the relevant electronic lock 106 at step 702.

[00132] In Bluetooth, 'pairing' is the first step in connecting two Bluetooth enabled devices. This step establishes permission that the two devices can communicate with each other. When the asset computing system 104 and the electronic lock 106 are first installed in the ATM 101, these devices may be paired with each other. Similarly, specific client computing device 109 may also be paired with the electronic lock 106 when these devices are first issued to maintenance staff. Typically, pairing is performed once and does not need to be repeated each subsequent time two Bluetooth enabled devices need to communicate. 'Connecting' is the step after pairing, in which the two devices can actively communicate with each other.

[00133] If at step 702 it is determined that the asset computing system 104 and electronic lock 106 are not paired, the access control client 117 does not send the unlock command to the electronic lock 106 and the method 700 ends at step 704. In some embodiments, the access control client 117 sets the state of the connection with the electronic lock as 'unpaired' before ending the process.

[00134] Conversely, if at step 702 it is determined that the asset computing system 104 and the electronic lock 106 are paired, the method proceeds to step 706 where the computing system 104 checks whether it is connected to the electronic lock 106 (i.e., if they are able to communicate with each other).

[00135] If at step 706 the asset computing system 104 and the electronic lock 106 are not connected, an attempt is made to connect the two devices at step 708. At step 710 the access control client 117 checks once again if the devices are connected. A predetermined number of connection attempts may be made. If the connection fails after the predetermined attempts, the method proceeds to step 704 where the access control client 117 does not send the unlock command and the method 700 ends. In certain embodiments, the access control client 117 sets the state of the connection as 'connection failure' before ending the process.

[00136] Alternatively, if it is determined that the computing system 104 and the electronic lock 106 are connected at step 706 or step 710, the access control client 104 generates and sends the unlock control signal to the electronic lock 106 to unlock it at step 712.

[00137] The electronic lock 106 may act on the received signal to cause the lock to open. For example, the electronic lock 106 may generate an electrical signal that activates an electromagnetic motor to turn the lock mechanical components from a 'closed' state to an 'open' state at step 714. It will be understood that the operation of an electrical lock is standard and therefore this is not described in more detail here.

[00138] Once the control signal is communicated to the relevant electronic lock 106, the access control client 117 and/or access control module 116 may monitor the status of the electronic lock 106 to determine whether the corresponding enclosure door has been opened or not. This door information is utilized to perform additional steps such as locking the electronic lock 106 once it is determined that the enclosure door is closed.

[00139] The door information is also used to add an additional layer of security after the ATM enclosure door is opened. Specifically, the enclosure door state is monitored so that the access control system may determine the time for which the ATM enclosure door remains opened. If the door remains open for a period greater than the period required to complete the assigned tasks, the access control system may determine that foul play is afoot and may take a theft-deterrent or corrective action such as generating an alert, informing local authorities, initiating lockdown of the ATM 101, or destroying all cash and/or cards in the ATM 101.

[00140] Fig. 8 illustrates an exemplary physical asset monitoring method 800. The method begins at step 802, where the access control module 116 determines the state of the lock and the ATM enclosure door(s). As noted previously, the electronic lock may be equipped with sensors such as microcontroller switches that detect the state of the lock and the ATM enclosure door(s). The access control module 116 may receive signals from these sensors (e.g., via the access control client 117) indicating whether the lock 106 is in an open or closed state and whether the corresponding enclosure door is open or closed. This method is described with reference to a single door. However, it will be appreciated that the physical asset may have multiple nested doors and in that case, the access control module 116 determines the state of multiple doors.

[00141] In certain embodiments, the electronic lock 106 may generate four different types of signals -

1) a signal indicating that the door is open and the lock is unlocked (e.g., if a portion of the lock is disengaged from a corresponding recess in the enclosure and the lock is in an unlocked state);

2) a signal indicating that the door closed and the lock is unlocked (e.g., if a portion of the lock is engaged with the corresponding recess and the lock is in the unlocked state);

3) a signal indicating that the door is open and the lock is locked (e.g., if a portion of the lock is disengaged from the corresponding recess and the lock is in a locked state); and

4) a signal indicating that the door is closed and the lock locked (e.g., if a portion of the lock is engaged with the recess and the lock is in the unlocked state). [00142] Alternatively, the electronic lock 106 may provide two different signals - one based on door state (i.e., open or closed) and another based on lock state (i.e., locked or unlocked). The access control module 116 can use these received signals to determine the ATM enclosure state- unlocked but unopened, unlocked and open, locked but open, or locked and unopened.

[00143] If at step 802 it is determined that the lock is in the locked state and the door is closed, the access control client 117 determines that the electronic lock 106 did not unlock properly at step 804 and may attempt to retry unlocking the electronic lock at step 804 (e.g., by performing method 700 again). In certain embodiments, the access control client 117 sets the state of the lock 106 as 'lock failure' and may forward this message to the access control module 116.

[00144] Alternatively, if at step 802 it is determined that the door is opened and the lock is locked, the access control client 116 determines that the requesting user has opened the enclosure door and may set the state of the lock 106 as Opened' along with a timestamp of the time when the access control client 116 first determined that the door was in the opened state. It may also forward this message to the access control module 116. The method subsequently proceeds to step 806 where the access control client 117 determines whether the door has been open for a period of time greater than an estimated time required to complete the assigned tasks.

[00145] This determination may be made by first determining the duration for which the door has been open (e.g., by comparing the timestamp of the time when the access control client 116 first determined that the door was open with the current time) and then comparing this duration with the estimated time required to complete the assigned task(s) (retrieved from the task database 110).

[00146] If at step 806 the access control client 117 determines that the door has not been open for a period greater than the estimated period, the method proceeds to step 802, where the client 117 rechecks the status of the door after a predetermined delay (e.g., 200ms).

[00147] Alternatively, at step 806, if the client 117 determines that the door has been open for a period greater than the estimated period, the method proceeds to step 808 where the client 117 communicates this information to the access control module 116, which initiates a corrective measure as described previously. [00148] If at step 802 it is determined that the lock is locked but the door is open, the access control client 116 determines that the requesting user has opened the enclosure door at step 806 and may set the state of the lock as Opened' along with a timestamp of the time the access control client 117 first determined that the door was open. The method proceeds to step 810, where the access control client sends a 'lock' signal to the electronic lock 106 to cause the lock to lock. This is done so that the door is locked as soon as it is closed.

[00149] Next, the method proceeds to step 806 where the access control client 117 determines whether the door has been open for a period of time greater than an estimated time required to complete the assigned tasks (as described previously).

[00150] Finally, if at step 802 it is determined that the lock is unlocked and the door is closed, the access control client 116 determines that the door is unlocked, but the requesting user has not yet opened the enclosure door. In this case, the access control client 117 determines the time period for which the electronic lock has been unlocked at step 812. This may be determined by calculating the duration of time from the time the 'unlock' command was sent to the current time.

[00151] Next, at step 814, it is determined whether the lock has been unlocked for a period greater than a predetermined period. This is done by comparing the duration determined at step 812 with a threshold duration (e.g., 60 seconds). If the determined duration exceeds the threshold duration, it is determined that the lock has been unlocked for sufficient period of time to allow the requesting user to open the enclosure door and the access control client 116 issues a 'lock' control signal to the electronic lock causing the lock 106 to lock at step 816.

[00152] However, if at step 814 it is determined that the door has not been unlocked for a period greater than the predetermined period, the method proceeds to step 802 after a predetermined delay (e.g., 200ms) to recheck the status of the door and lock. In certain embodiments, access control client 117 sets the status of the lock as 'unlocked' and may cause the asset computing system 104 to display a message to the requesting user informing the user that the lock is unlocked and will be locked with the user does not open the enclosure door within the predetermined threshold duration.

[00153] The method described with reference to Fig. 7 assumes a typical Bluetooth pairing and connection regime is followed to connect the asset computing device 104 and/or external client device 109 with the electronic lock(s) 106. However, in other embodiments, a different connection regime may be adopted. The following section describes one particular implementation of this alternate pairing/connection regime.

Alternative embodiment

[00154] Typically, Bluetooth technology was developed to create ad-hoc networks for exchanging data between electronic devices and was not developed with security in mind. Accordingly, in typical Bluetooth pairing, when a pairing request is received, a Bluetooth enabled device may be configured to broadcast a pairing key. Any Bluetooth enabled device in its vicinity can essentially then pair with the broadcasting device by echoing this pairing key back to the broadcasting device.

[00155] To increase pairing security and prevent any unauthorized access to the electronic lock 106, a pairing module may be introduced in the central server 102 and corresponding pairing clients may be installed on asset computing systems 104 and/or external client devices 109.

[00156] Fig. 9 illustrates an exemplary networked environment 900 with these system elements. As will be appreciated, Fig. 9 is identical to Fig. 1 (except for addition of the pairing module 902 and corresponding pairing clients 904A, 904B, ... ,904N) and therefore, the same reference numerals are used with respect to the network elements described with reference to Fig. 1. Further, the functionality of the network elements previously disclosed and described with reference to Fig. 1 remain the same in this embodiment.

[00157] Together, the pairing module 902 and the corresponding clients (collectively referred to as pairing clients 904) provide a security layer and are configured to automatically connect an authenticated computing device to an electronic lock 106. In the case of Bluetooth pairing, this is done without exposing a pairing key.

[00158] In operation, the pairing client 904 may be downloaded onto each asset computing device 104 and external client device 109 in the network 100 and registered. To register, an authorized user (e.g., the requesting user or the authorizing user) may be prompted to enter their authentication credentials. The pairing client submits these authentication credentials along with computing device specific information to the pairing module 902. Upon receipt of this information, the pairing module 902 may be configured to register the pairing client 904 and assign security credentials to the registered pairing client (e.g., a unique token/identifier). These credentials may be saved at the central server 102 (e.g., in the identification database or a separate pairing database) and forwarded back to the pairing client 904 (which is also configured to store this information).

[00159] When access is requested to the ATM 101 (e.g., during execution of method 700), the requesting user may activate the pairing client 904 either on the asset computing system 104 or on their personal client device (in case the asset computing system 104 is not available). Activation of the pairing client 904 causes the client 904 to transmit its security credentials (unique identifier) to the pairing module 902. The pairing module 902 in turn compares the received security credentials with stored security credentials to validate the pairing client 904 and consequently validate the computing device on which the pairing client 904 is installed.

[00160] In certain embodiments, the requesting user and/or authorizing user may be authorized (e.g., using the method described with reference to Fig. 5) before the computing device validated. In other embodiments, the computing device is validated before the requesting user and/or authorizing user can be authorized. In any case, once the required parties are authorized and the client 904 is validated, the pairing module 902 is configured to manage pairing of the computing device 104 or 109 running the validated pairing client 902 with the electronic lock 106. In particular, a pairing key is provided to the pairing client 904 in a secure manner. This may include encrypting the pairing key using any known encryption technique (such as public-private key encryption), and or creating a hash of the pairing key. The pairing client 904 automatically decrypts the pairing key and forwards the key to the electronic lock 106, allowing the two devices to be paired and connected. It will be appreciated that as the pairing key is encrypted, it is not displayed in plain text on the computing device (104 or 109) during this process and the pairing process is carried out in the background.

[00161] In some embodiments, the pairing may be performed when the asset computing system 104 and the electronic lock 106 are first installed in the ATM 101. Similarly, pairing may be performed when specific client computing devices 109 are first issued to maintenance staff and brought in range of the electronic lock 106. In other embodiments, once the particular task is completed, the electronic lock 106 may be unpaired from the asset computing device 104 and/or client device 109 and the pairing module and client may be configured to perform pairing each time access to the ATM 101 is requested. [00162] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

[00163] As used herein the terms "include" and "comprise" (and variations of those terms, such as "including", "includes", "comprising", "comprises", "comprised" and the like) are intended to be inclusive and are not intended to exclude further features, components, integers or steps.

[00164] Various features of the disclosure have been described using process steps. The functionality/processing of a given process step could potentially be performed in various different ways and by various different systems or system modules. Furthermore, a given process step could be divided into multiple steps and/or multiple steps could be combined into a single step. Furthermore, the order of the steps can be changed without departing from the scope of the present disclosure.

[00165] It will be understood that the embodiments disclosed and defined in this specification extends to alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. These different combinations constitute various alternative aspects of the embodiments.

Claims

1. A method for providing access to a physical asset, comprising: receiving an access request from a first computing system, the access request comprising identification information received from a requesting user; determining whether the requesting user is authorized to access the physical asset based at least on a verification of the requesting user identification information; upon determining that the requesting user is authorized, retrieving a task associated with the physical asset and the requesting user, the task comprising information about an authorizing user; authenticating the authorizing user; in response to authenticating the authorizing user, generating and transmitting a control signal to the first computing system to allow access to the physical asset.

2. The method of claim 1, wherein allowing access to the physical asset comprises causing an electronic lock associated with the physical asset to unlock.

3. The method of claim 2, further comprising:

determining that a door of the physical asset is closed; and

transmitting a control signal to the first computing device to cause the electronic lock to lock.

4. The method of claim 2, further comprising:

determining after a predetermined period of time that a door of the physical asset is in an open state, and

initiating a lockdown sequence of the physical asset.

5. The method of claim 4, wherein the predetermined period of time exceeds an estimated period of time for completing the retrieved task.

6. The method of claim 1, wherein the authorizing user is a remote user.

7. A method for providing access to a physical asset, the method comprising: receiving identification information from a requesting user at an asset computing device and transmitting the received identification information to a remote computing device; receiving confirmation, at the asset computing device, from the remote computing device that the requesting user is authorized to access the physical asset and at least one task associated with the physical asset and the requesting user is scheduled; receiving an unlock control signal from the remote computing device; and transmitting the unlock control signal to an electronic lock associated with the physical asset to cause the electronic lock to unlock.

8. The method of claim 7, wherein the unlock control signal is received in response to the remote computing device verifying identification information received from an authorizing user, wherein the authorizing user is identified from the at least one task associated with the physical asset and the requesting user.

9. The method of claim 7 further comprising: determining a state of the electronic lock and a state of a door of the physical asset, wherein the state of the electronic lock is one of unlocked or locked and the state of the door is one of opened or closed, and transmitting lock state and/or door state information to the remote computing device.

10. The method of claim 9 further comprising:

in response to transmitting the lock state information indicating that the electronic lock is in an unlocked state, receiving a lock control signal from the remote computing device after a predetermined period of time, the predetermined period of time based on an estimated time period required to complete the at least one task; and

transmitting the lock control signal to the electronic lock to cause the electronic lock to lock.

11. The method of claim 7 further comprising: in response to transmitting door state information indicating that the door is in an opened state after a predetermined period of time, receiving a lockdown signal from the remote computing device to cause the physical asset to initiate a lockdown sequence, wherein the predetermined period of time exceeds an estimated time period required to complete the at least one task.

12. A system for providing access to a physical asset, the system comprising:

a processor, and

a non-transitory computer-readable storage medium storing sequences of instructions, which when executed by the processor, cause the processor to: receive an access request from a first computing system, the access request comprising identification information received from a requesting user; determine whether the requesting user is authorized to access the physical asset based at least on a verification of the requesting user identification information; upon determining that the requesting user is authorized, retrieve a task associated with the physical asset and the requesting user, the task comprising information about an authorizing user; authenticate the authorizing user; and in response to authenticating the authorizing user, generate and transmit a control signal to the first computing system to allow access to the physical asset.

13. The system of claim 12, wherein the control signal causes an electronic lock associated with the physical asset to unlock.

14. The system of claim 13, wherein the processor is further configured to execute instructions which cause the processor to: determine that a door of the physical asset is closed; and transmit a control signal to the first computing device to cause the electronic lock to lock.

15. The system of claim 13, wherein the processor is further configured to execute instructions which cause the processor to:

determine after a predetermined period of time that a door of the physical asset is in an open state, wherein the predetermined period of time exceeds an estimated period of time for completing the retrieved task; and

initiate a lockdown sequence of the physical asset.

16. A system for providing access to a physical asset, the system comprising:

a processor, and

a non-transitory computer-readable storage medium storing sequences of instructions, which when executed by the processor, cause the processor to:

receive identification information from a requesting user and transmit the received identification information to a remote computing device;

receive confirmation from the remote computing device that the requesting user is authorized to access the physical asset and at least one task associated with the physical asset and the requesting user is scheduled; receive an unlock control signal from the remote computing device; and transmit the unlock control signal to an electronic lock associated with the physical asset to cause the electronic lock to unlock.

17. The system of claim 16, wherein the processor is configured to execute instructions which cause the processor to receive the unlock control signal in response to the remote computing device verifying identification information received from an authorizing user, wherein the authorizing user is identified from the at least one task associated with the physical asset and the requesting user.

18. The system of claim 16, wherein the processor is further configured to execute instructions which cause the processor to: determine a state of the electronic lock and a state of a door of the physical asset, wherein the state of the electronic lock is one of unlocked or locked and the state of the door is one of opened or closed, and transmit lock state and door state information to the remote computing device.

19. The system of claim 16 wherein the processor is further configured to execute instructions which cause the processor to:

in response to transmitting the lock state information indicating that the electronic lock is in an unlocked state, receive a lock control signal from the remote computing device after a predetermined period of time, the predetermined period of time based on an estimated time period required to complete the at least one task; and

transmit the lock control signal to the electronic lock to cause the electronic lock to lock.

20. The system of claim 16 wherein the processor is further configured to execute instructions which cause the processor to:

in response to transmitting door state information indicating that the door is in an open state after a predetermined period of time, receive a lockdown signal from the remote computing device to cause the physical asset to initiate a lockdown sequence, wherein the predetermined period of time exceeds an estimated time period required to complete the at least one task.

21. Non-transient computer readable storage comprising instructions which, when executed by a processor, cause the processor to perform the steps of claims 1-11.