GB2564477A

GB2564477A - An access terminal control system

Info

Publication number: GB2564477A
Application number: GB1711343.2A
Authority: GB
Inventors: Bhanushali Anand
Original assignee: Argus Global Pty Ltd
Current assignee: Argus Global Pty Ltd
Priority date: 2017-07-06
Filing date: 2017-07-14
Publication date: 2019-01-16
Also published as: WO2019006495A1; AU2018204805A1; GB201711343D0

Abstract

An access terminal control system and method to permit utilisation of at least one of multiple operational features comprises a plurality of access terminals 1 each having at least one terminal feature, the terminals each being connected directly, or remotely, to a controlling server 200 which includes access to a plurality of operational features 207-211 each of which is transmissible to each of the access terminals to enable different specific operational features for each terminal to be customised for each purchaser of the system. The terminals and controlling server operate preferably act as a client-server system and the operational features are specific to the commercial operations of each purchaser. The terminal features may include a time and attendance feature or biometric authentication. The terminal feature may be controlled by the server in accordance with a time basis. The operational features are allocated to specific terminals on the basis of the location of the terminals. Communications between the terminals and the server can be encrypted. User validation may occur at the server 200. The terminals preferably have essentially identical construction and are configured on installation to meet the relevant commercial needs of the customer.

Description

An Access Terminal Control System

Field of the Invention

The present invention relates to the field of security and, in particular, to access terminals.

Background Art

Access terminals are used by a wide range of industrial, commercial and government organisations to permit access, or control access, of personnel. Such personnel can have a wide range of possible status conditions such as employee, contractor, visitor, and so on.

An access terminal can provide a wide range of operational features. One such operational feature is authentication, which is ensuring that a person presenting as a particular identity does in fact have that identity. A biometric reader at the terminal captures a user’s biometric template. A matching engine compares the captured biometric template to the entire template database to find a match. If the match is found and belongs to the expected user, authentication is completed. If the user is unknown, the terminal can identify the user based on the captured biometric template.

Another such operational feature is authorisation, which is ensuring that a person presenting as being authorised to conduct an activity does have that authority. Another such operational feature is location accessibility, which is ensuring that a particular person is authorised to access a location, possibly at a particular time. A further such operational feature is personnel interrogation which is asking a person a previously arranged question and checking that the answer given by the person interrogated by the terminal matches a previously given answer to a security question. Such security questions are typically the maiden name of the person’s grandmother, the make of a person’s first car, and the like.

The requirements of prospective customers for such access terminals are many and varied. For example, a bank may have a requirement that specific personnel travel directly between a vault and a loading dock so that cash loaded into an armoured car only travels directly between the vault and the loading dock. As a consequence, the access terminals at the loading dock, the vault and the doorways on the route between the loading dock and the vault, will not permit entry of persons other than those intended to handle cash, and will not permit departure from the route of the persons intended to handle cash. Nor will they permit entry into the route of persons not intended to handle cash.

In other situations, employees may not be permitted to access a rejected product storage area after specified hours. This is to prevent employee pilfering by a dishonest employee declaring a product rejected, storing it in a rejected product storage area, and after hours removing the product from the rejected product storage area.

Other situations include straightforward access to building sites, customer identification prior to conducting a financial transaction, and the like.

Furthermore, from time to time new sensors become available which are used in conjunction with access terminals and which incorporate enhanced technology. Such sensors include iris detectors, fingerprint detectors, biometric detectors and the like. It is desirable to enable such new sensors to be deployed and the control system for the access terminals reconfigured, if necessary, so as to achieve enhanced functionality.

Genesis of the Invention

The Genesis of the present invention is a desire to enable a single system including multiple access terminals to cater for a wide range of customers. In this way, economies of scale in manufacturing and production can be achieved where the installed access terminals of the system are the same irrespective of the nature of the customer, but the functionality of the access terminals in the system is able to be tailored for each individual customer.

Summary of the Invention

In accordance with a first aspect of the present invention there is disclosed an access terminal control system to permit utilisation of at least one of multiple operational features, said system comprising a plurality of access terminals each having at least one terminal feature, said terminals each being connected directly, or remotely, to a controlling server which includes access to a plurality of operational features each of which is transmissible to each of said access terminals to enable different specific operational features for each terminal to be customised for each purchaser of the system.

In accordance with another aspect of the present invention there is disclosed a method of controlling multiple access terminals to permit utilisation of at least one of multiple operational features, said method comprising the steps of: providing a plurality of access terminals each having at least one terminal feature, connecting each of said terminals directly, or remotely, to a controlling server, and providing said server with access to a plurality of operational features each of which is transmissible to each of said access terminals to thereby enable different specific operational features for each terminal to be customised for each user.

Brief Description of the Drawings

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 is a block diagram of the hardware of a representative terminal,

Fig. 2 is a schematic functional block diagram of the terminal of Fig. 1,

Fig. 3 is a perspective view of the terminal of Figs. 1 and 2,

Fig. 4 is a flowchart showing the procedure for the encryption of data,

Fig. 5 is a flowchart showing the procedure for the decryption of data,

Fig. 6 is a flowchart showing the set up for an employee clock on/clock off situation,

Fig. 7 is a flowchart showing the use of a portable terminal in the healthcare industry,

Fig. 8 is a flowchart showing the set up for a terminal for use in lift or elevator access control,

Fig. 9 is a flowchart showing the set up for a terminal for use in vehicle hiring, Fig. 10 is a flowchart showing the set up for a terminal for use in inventory control, and

Fig. 11 is a block diagram showing the overall system architecture.

Detailed Description

As seen in Fig. 1, at the heart of each terminal 1 is a core processor or central processor 2 to which is connected a memory 3, an LCD/Touch Screen 5 and a buffered digital input/output unit 6 including relay outputs to operate door locks, etc. Also connected to the central processor 2 is an USB host 8 which is connected to a plurality of individual sensors 9. A card reader 10 is also connected to the central processor 2. The individual sensors 9 can include fingerprint sensors, vein sensors, palm sensors, iris sensors, camera sensors, proximity sensors, biometric sensors and RFID readers.

In addition to the hardware items of Fig. 1, additional capabilities rendered in software are present as illustrated in Fig. 2. A user database 12, a template database 13, a screens database 14 and a workflow database 15 are stored in the memory 3. In addition, interfaces are provided in the form of a touchscreen interface 17, a camera interface 18, a biometric interface 19 and a network interface 20. The latter connects each terminal 1 with all other terminals 1 and with a server 200 (Fig. 11). The remaining interfaces 17-19 provide data connectivity between the central processor 2 and the touchscreen 5, and various sensors 9 including a camera , one or more biometric sensors, and a proximity sensor 21.

Also illustrated in Fig. 2 is an encryption engine 22 which is interposed between the terminal 1 and the network. Since the terminal 1 needs to communicate securely and reliably across a network which will not necessarily be controlled by the owner of the terminal(s) 1, it is desirable to ensure that the data transmitted over the network is encrypted. Encryption is preferably achieved by means of a commercially available standard, for example using a 256 bit key, which is then manipulated to suit the hardware and software of the terminal 1. The pre-shared key is used at both ends of each communication link, however, the key is never sent over the network link and will be installed in the central processor 2 on its initial installation. There is a unique key for each terminal 1. The encryption process is schematically illustrated in Fig. 4 and the decryption process is schematically illustrated in Fig. 5.

As data packets to be transmitted will contain data which, for example, permits or enables the activation of locks, and similar tasks, it is essential that a packet which is capable of unlocking a door, is not captured and then re-transmitted at a later time. Such a re-transmission may be attempted in order to open the lock by simulating the presence of an authorised individual. To prevent this, each data packet is unique and verifiable, even if the useful data within the packet is substantially identical to the data of other packets.

In addition to data encryption, a strong hash algorithm is applied to the data after encryption. This provides a checksum for the data which can be verified before that data is decrypted. This procedure allows invalid packets to be rejected quickly. The seed value for the algorithm is unique to each terminal 1, is not sent over the network, and is installed at the time of initial installation of the terminal 1. A data prefix and data suffix, which are random, are used to shift the valid data within the full length of the data packet. The prefix length randomly varies from one to 30 and contains random data characters. The prefix length of 16 is avoided lest the entropy of the data of those packets be reduced. The suffix allows the data length to be increased so as to be preferably a multiple of 16. The random data can be generated “on-the-fly”. Alternatively, the random data can be generated at system start time by generating a long string of over 4000 bytes of suitable random data and then randomly selecting a subset of this random data.

The packet length is 4 bytes being the length of the valid unencrypted data within the overall packet, so it excludes the random data, marker and sequence ID. The packets are preferably transmitted most significant bit first and least significant bit last. Each packet has a 64-bit packet sequence number which is incremented with each message sent. Preferably a 64-bit timestamp is used with an increment of lmSec. This provides a usable life of approximately 300,000,000 years if the number is treated as signed. One terminal 1 starts with a sequence identification number of zero, allowing a defined start date of the timestamp. Once this is set the start date of the timestamp is not changed. The sequence number is also sent with most significant bit first and least significant bit last. Any packets arriving with invalid sequence numbers are ignored by the encryption engine 22.

It will be seen that the hash or checksum is added to the start of the encrypted data and is validated on receipt to ensure that the data packet has not been tampered with. To ensure that the data packets can be reliably transmitted, the data is encoded with URL Safe Base64.

Turning now to Fig. 6, a basic application for the terminal 1 is schematically illustrated. The drawing consists of three bands of which the upper band shows the activity of the client’s existing equipment, namely a time and attendance logging device 61 (commonly known as a Bundy Clock) and particularly used in commercial establishments with flexitime and/or shift work. The middle band shows the activity of the terminal 1, and the lower band shows the activity of the user.

As indicated in Fig. 6, the procedure starts by the user scanning the user’s finger at step 62 in a fingerprint scanner 9 (Fig. 1) of the terminal 1. As a consequence, the terminal 1 then performs a one to many (N representing an integer of unknown magnitude) identification at step 63 by checking the scanned fingerprint against the existing database of employee fingerprints. If no match is identified, the terminal 1 reports an error at step 64 and the processing stops without the employee being able to clock on.

Alternatively, if a match is found, then in step 65 the terminal display indicates to the user that confirmation of the user’s identity has taken place and the clock 61 is actuated. That is, the time of entry or exit of the (correctly identified) employee is entered into the clock 61. Clearly, such an arrangement prohibits friends clocking on for one another and thereby defrauding an employer.

Turning now to Fig. 7, an installation of a typical terminal 1 to control dosage of medicines in hospital, or like medical situation, is illustrated. The hospital has a centralised computer 25 and each patient on admittance to the hospital has biodata captured and stored in the patient database 26 of the hospital computer 25 so as to create initial updated patient information 27. A convenient biodata is a fingerprint, for example. A nurse in charge of administering medicines has a trolley (not illustrated) on which is located a portable battery-powered terminal 1. The terminal 21 communicates with the hospital computer 25 by means of a network 28. Such a nurse in the course of a single shift may well be required to administer medicines to well over 100 patients and it is vital that the correct medicines are administered to the correct patients without any mix up. This is achieved by the nurse approaching a patient and having the patient touch the touch screen 5 so as to thereby capture the fingerprint of the patient. Alternatively, the terminal 1 can be provided with a fingerprint scanner.

Either way, there is capture of the patient biometrics at step 29.

The next step is a patient verification step 30 where the recently captured data is compared with the equivalent data in the patient database 26 thereby enabling a YES/NO matching to be achieved. If there is no match, the procedure ends safely.

However, if there is a match, the patient’s information from the patient database 26 is downloaded at step 31 and this information includes data on the type of medicines required by the patient and the dosage of the medicine. The next step 32 is for a medicine dispenser travelling on or with the trolley, to be instructed to dispense the correct medicine at the correct dose. This can be achieved by means of relay controlled doors or flaps on the medicine dispenser. The medicine is given to the patient and the patient is watched by the nurse while the medicine is ingested. Then at step 33 the updated nation information including the time and dose of the medicine is sent back to the patient database 26 via the network so as to update the patient database 26.

In Fig. 8, access control for a lift or elevator is illustrated. The procedure starts at step 81 with the person wishing to utilise the lift scanning a finger so as to generate a fingerprint which enables the user to be identified in step 82. As in Fig. 6, if there is no match the fingerprints, then the terminal 1 in step 83 displays the text “Access denied” and the procedure stops. Alternatively, if there is a match, then the staff access data is retrieved from the lift operator’s existing data.

This existing data preferably includes not only the data (e.g. a fingerprint) used to identify the user, but also the floor or floors of the building to which the user is permitted access. Following retrieval of the staff access data in step 84, the terminal 1 has its display changed so as to display at step 85 virtual buttons on the touchscreen 5 of the terminal 1. Utilising the virtual buttons, the user in step 86 than presses the level or floor to which the lift is intended to convey the user. The terminal 1 then determines whether the desired level or floor is a permitted level or floor for that particular user. If the access is permitted, then in step 87 the lift is operated and the procedure ends. Alternatively, if the identified user does not have permission to access the level or floor, then the touch screen of the terminal in step 88 displays the words “No Access” and the procedure ends without the lift being operated.

In an alternative arrangement is illustrated in Fig. 9, where the terminal 1 can be used to control the hiring of a shared vehicle such as a bicycle. As before, in step 91 the user scans a finger so as to generate a fingerprint which in step 92 is matched with the existing database for identification. If there is no match, then in step 93 access is denied and the procedure ends. If a match does take place, then in step 94 the existing records of the bike hiring firm are accessed to ensure that the user has an unblemished record and does not have a bad prior history with the hiring firm. If there is such a bad history, then in steps 95 and 96 a decision to deny access is taken and the terminal screen displays information to the effect that access is denied, respectively.

Alternatively, if the user has an unblemished record, then in step 97, the user is requested to scan a unique tag, such as an RFID tag, which identifies the bike intended to be used by the user. The data from the scanned tag in step 98 is then transferred to the hiring firm’s computer to indicate that hiring has commenced for the identified user. Finally, in step 99 the lock which prevents access to the selected bike is unlocked thereby allowing the identified user to access the bicycle. A still further arrangement is illustrated in Fig. 10 which illustrates how the terminal 1 can be used to manage access to a company’s inventory system. A particular problem with inventory systems is that it is desirable to restrict access so that, for example, staff which are repairing lawnmowers only have access to spare parts for lawnmowers whilst staff which are repairing motorbikes only have access to spare parts for motorbikes, lest staff obtain spare parts which permit the repair or maintenance of their own motorbikes and lawnmowers.

As before, in step 101 the user scans a finger so as to produce a fingerprint which in step 102 is identified. Following correct identification, the terminal in step 103 retrieves from the existing company inventory system, the information regarding those items of inventory which are assigned to the identified staff member. This list of items is then displayed in step 104 on the touchscreen of the terminal so as to permit the identified staff member to select or pick those items of permitted inventory which are desired on this occasion. In step 105 the user scans the finger again in order to confirm the highlighted or selected inventory items. In step 106 a further identification takes place on the second scan output which, if successful, permits the company computer to retrieve in step 107 the details of the location(s) of the selected inventory item(s). These location(s) in step 108 are then displayed on the screen of the terminal.

In step 109 the staff member utilising the system picks or manually selects the inventory items at their corresponding locations and scans the barcode, which each item contains, into the terminal 1. As a consequence, the terminal 1 in step 110 can update the company inventory data by carrying out a comparison between the inventory items selected in step 104 and the inventory items scanned in step 109. If this comparison indicates that all the items have been picked and scanned in step 109, then this information is displayed on the display of terminal 1 in step 111. In step 112 the user scans the finger for the third time in order to confirm receipt of the inventory items and the procedure ends. Alternatively, if not all inventory items have been picked, then step 110 permits the inventory data in the company’s computer to be updated accordingly.

The above described arrangements indicate that different prospective customers require differently configured terminals to suit their commercial needs. How the terminals of essentially identical construction are configured on installation to meet the relevant commercial needs is illustrated in Fig. 11.

As seen in Fig. 11, each of a multiplicity of terminals 1 is connected to a server 200. Only the interior details of one of the terminals 1 are illustrated, the interior details of each of the other terminals 1 being essentially identical. The server 200 communicates with each of the terminals 1 via a network 201 which can take various forms including the Internet. Both the server 200 and each of the terminals 1 includes an encryption engine 22 which carries out the encryption and decryption of the data transmitted over the network 201 in accordance with the explanation above in relation to Figs. 4 and 5. Loaded into each terminal is the software required for the basic time and attendance (T & A) function 102. This is directly controlled by a time basis by scripting unit 203 within the server 200.

The server 200 is also connected via an interface 205 to customer specific software relating to hospital operation 207, lift access control 208, bike sharing 209 and warehouse inventory picking 210 which respectively correspond to the activities described in Figs. 7-10. Provision is made for other activities 211 by further clients. The interface 205 is preferably realised as an application program interface (API) utilising REST technology.

It will be seen that the server 200 and the various terminals 1 operate together as a client-server system. Thus data kept in the server 200, or accessible by the server 200, can be shared with any number of the terminals 1 on request.

In a typical installation, the time based scripting permits the time and attendance function 102 to operate during specific hours, for example 6 AM-10 AM and 4 PM-8 PM to permit employees to arrive and depart from their employment as explained above in relation to Fig. 6. In addition, specific terminals at specific locations can be provided with additional functionality. For example, mobile terminals can be provided with the hospital software 107 so as to permit these terminals to operate as described above in relation to Fig. 7. In addition, terminals located at access locations for a lift or elevator are provided with lift access control software 108 to permit these terminals to operate as described above in relation to Fig. 8.

The foregoing describes only some embodiments of the present invention and modifications, obvious to those skilled in the security arts, can be made thereto without departing from the scope of the present invention.

The term “comprising” (and its grammatical variations) as used herein is used in the inclusive sense of “including” or “having” and not in the exclusive sense of “consisting only of’.

Claims

1. An access terminal control system to permit utilisation of at least one of multiple operational features, said system comprising a plurality of access terminals each having at least one terminal feature, said terminals each being connected directly, or remotely, to a controlling server which includes access to a plurality of operational features each of which is transmissible to each of said access terminals to enable different specific operational features for each terminal to be customised for each purchaser of the system.

2. The control system as claimed in claim 1 wherein said terminals and said controlling server operate as a client-server system.

3. The control system as claimed in claim lor 2 wherein said operational features are specific to the commercial operations of each purchaser.

4. The control system as claimed in any one of claims 1-3 wherein said one terminal feature comprises a time and attendance feature.

5. The control system as claimed in any one of claims 1-3 wherein said one terminal feature comprises biometric authentication.

6. The control system as claimed in any one of claims 1-5 wherein said terminal feature is controlled by said server in accordance with a time basis.

7. The control system as claimed in any one of claims 1-6 wherein said operational features are allocated to specific ones of said terminals on the basis of the location of the terminals.

8. A method of controlling multiple access terminals to permit utilisation of at least one of multiple operational features, said method comprising the steps of: providing a plurality of access terminals each having at least one terminal feature, connecting each of said terminals directly, or remotely, to a controlling server, and providing said server with access to a plurality of operational features each of which is transmissible to each of said access terminals to thereby enable different specific operational features for each terminal to be customised for each user.

9. The method as claimed in claim 8 including the further step of operating said terminals and said controlling server as a client-server system.

10. The method as claimed in claim 8 or 9 including the further step of transmitting an operational feature specific to the commercial operations of a user to the terminals of that user.

11. The method as claimed in any one of claims 8-10 including the further step of selecting said one terminal feature to be a time and attendance feature.

12. The method as claimed in any one of claims 8-10 including the further step of selecting said one terminal feature to be a biometric authentication.

13. The method as claimed in any one of claims 8-12 including the further step of controlling said terminal features by said server in accordance with a time basis.

14. The method as claimed in any one of claims 8-13 including the further step of allocating said operational features to specific ones of said terminals on the basis of the location of said terminals.