Background of the invention Recently increasing numbers of access management systems employ electronic keys, that is keys which carry a rule and which are capable of communicating that rule to an electronic lock device which recognises the rule and accordingly can be opened. These systems include hotel key systems, card access systems and electronic lock systems. All these systems co-ordinate the rules between the keys and the iocks using various types of access management software.

These access management systems are designed for door access with high user traffic and indoor operating conditions. In order for the management software to communicate with the locks, direct cable or wireless connection is usually needed, which requires massive cabling and installation efforts, and, if the communication is carried on over a telecommunication network, may lead to expensive online charges. A typical system has built-in battery backup to overcome the problems of power failure.

An electronic lock usually comprises a solenoid which can be activated to release the locking mechanism. However, such a system is not energy efficient as power needs to be supplied continuously while activating the solenoid and turning the key, and therefore the energy stored in battery is quickly used up requiring frequent battery replacement or recharging.

Presently, electronic locks used in an outdoor rugged environment are protected from rain and wetness by separate devices such as plastic encasements. This method is inconvenient as the encasing is large and is usually a cumbersome accessory to the lock.

Summary of the invention The invention aims to provide new and useful systems for access management.

It further aims to provide new and useful electronic locks for use in an access management system.

In a first aspect, the invention proposes in general terms that a database for storing rules is accessible over the internet, so that a user can download access rules into the database over the internet from a first location, and terminals in communication with the database over the internet receive the codes and transmit the rules to the keys.

Thus, the first aspect of the invention makes it possible for a first user who administrates a secure area to load the rules into the database and to arrange for the locks to recognise the rules. A second user can use the terminals to transmit the rules to the keys, so as to empower them to permit access to the secure area.

In a second aspect, the invention proposes that a lock retains a record of interactions with keys, and at least one of the keys is arranged to download at least part of the records and transmit it to the database.

Thus, the second aspect of the invention makes it possible for records from the lock to be input to the database even though the lock has means of directly making contact with the database.

In a third aspect the invention provides a padlock comprising a shackle, a lock mechanism controlling whether the shackle can be opened, a control circuit controlling the lock mechanism, and an interface for receiving from a key an electronic signal encoding rules. The lock mechanism is a"magnetic solenoid" by which is meant a self-latching device in which a locking element is held by a magnetic force provided by a permanent magnet in a blocking position in which it blocks the lock being opened. The magnetic force is opposed by a mechanical force from a resilient body such as a spring, but the mechanical force is lower than the magnetic force, so that the locking element is normally retained in the locking position. However, the lock mechanism further contains a solenoid which can be powered by the control circuit to oppose the magnetic force generated by the permanent magnet, and so allow the locking element to be moved away from the blocking position, so that the lock can be opened.

Such magnetic solenoids ("self-latching devices") are conventionally used in CD drive systems. Suitable devices are available from the Shinmei company, and illustrated on http ://info. tactnet. co. jp/shinmei/e/product/pdf/EDL1630G. pdf).

Note that these magnetic solenoids are different from better known solenoid systems in which the movable element is moved by the solenoid both towards and away from the permanent magnet according to the current direction through the solenoid. Such systems are illustrated in http ://info. tactnet. co. jp/shinmei/e/product/pdf/EDL1630G. pdf.

Brief description of the figures Preferred features of the invention will now be described, for the sake of illustration only, with reference to the following figures in which: Fig. 1 shows a facility access management system which is an embodiment of the invention.

Fig. 2 illustrates schematically the operation of certain units of the system of Fig. 1.

Fig. 3,4 and 5 are flow diagrams of portions of various units of the system of Fig. 1.

Fig. 6 illustrates the construction of the lock of the system of Fig. 1.

Fig. 7 illustrates the construction of the key of the system of Fig. 1.

Fig. 8 illustrates the flowchart of operation of the lock of Fig. 1.

Fig. 9 illustrates the flowchart of the operation of the key of Fig. 1.

Fig. 10 is a perspective view of the lock of Fig. 1.

Fig. 11 is an exploded view of the lock of Fig. 1.

Fig. 12 is an exploded view of the cylinder insert shown in Fig. 11.

Fig. 13 and Fig. 14 are cut away perspective views the lock cylinder insert.

Fig. 15 is a perspective view of the key of Fig. 1.

Fig. 16 is an exploded view of the key of Fig 1.

Fig. 17, which is composed of Figs. 17 (a) and 17 (b), is cross-sectional views of the key of Fig. 1 in two different planes.

Fig. 18, which is composed of Figs. 18 (a) and 18 (b), is cross-sectional views of the lock cylinder insert of Fig. 1 in a first plane at different moments in the operation of the lock cylinder insert.

Fig. 19, which is composed of Figs. 19 (a) and 19(b), is cross-sectional views of the lock cylinder insert of Fig. 1 in a second plane at different moments in the operation of the lock cylinder insert.

Fig. 20, which is composed of Figs. 18 (a), 18 (b) and 18 (c), is cross-sectional views of the lock cylinder insert of Fig. 1 in a third plane at different moments in the operation of the lock cylinder insert.

Description of the preferred embodiment Fig. 1 shows an embodiment of a facility access management system which is an embodiment of the invention. The system is for permitting access to a number of different premises, of which one is shown on the left of Fig. 1. The

premises are shown as a wall 11 having a door 10. The door is sealed by a lock 12, which is to be opened by a key 13, held by a user (the"key-holder") who has to complete a route passing a number of such premises, and using the key 13 to open the lock 12 in the manner described below. As described below, the electronic locks 13 are rugged enough to withstand weathering. Whether or not the lock 12 can be opened by the key 13 depends on rules stored in the key 13, and whether those rules match rules stored by the lock 12. (Note that the respective sets of rules need not be identical in order to"match".).

The system further comprises a database system 150, comprising a database 1 for containing data including rules, and a server 2 which can be accessed over the internet from any of the PCs (personal computers) 21,23, 24,25, and from mobile phone 20. The terminal 21 is in a location available to the key-holder before starting on the route and after completing the route (e. g. at the user's office), whereas the terminals 23, 24,25 are locations which are in general remote from the terminal 21. The mobile phone 20 may actually be owned by the key-hoider. The communication path (socket connection) between one of the PC 21 and the mobile phone 20, and the server 2 is shown in Fig. 1 as path 15. For this purpose, the mobile phone 20 supports the downloading of application program, such as a small Java client program, or a C++ client program.

The key 13 has a built-in infrared port and can communicate with the PC 21 or mobile phone 20 via the IrDA protocol on a communication path 14 wirelessly.

Once the communication paths 14,15 are established, data can flow freely between the key 13 and the server 2. For example, if the user carries the mobile phone 20 with him, he can transfer the information to the server 22 while he is on the move.

Whether the communication between the lock 12 and key 13 is such as to permit or refuse access, the access transaction is logged in respective embedded memories in the key 13 and the lock 12. After the user completes

the route of services and returns back to his office, he can upload the access transaction stored in the key 13 to the server 2 using the office PC 21 or a mobile phone 20. The server 2 stores it in the database 1. The office PC 21 has established network connection, i. e. the Internet, with the server 2 either by dialup or office network before the key can communicate with the server 2.

The server 2 may contain server programs, such as Java application or VB, for socket connections 15 and web applications, such as JSP or ASP. NET applications, for displaying the data uploaded into the database 1 which is used to manage the status of locks, keys, users, facilities and system users. The web server 2 supports three groups of Internet users, who are indicated schematically on Fig. 1 as the three respective terminals 23,24, 25. The user 23 is a system administrator, such as a managing agent, who wants to arrange for maintenance services (such as cleaning services) to be performed on the site. An maintenance manager (indicated schematically as terminal 24) is someone who provides such maintenance services using the key-holders (maintenance workers). The maintenance manager 24 can log into the system to verify the service routes performed by his maintenance workers. The administrator 23 uses the system to change the access rules, generate reports or monitor the incoming transactions and connections The user 25 is a facility officer associated with the site (e. g. he may be a caretaker of the site). A system administrator 23 can login to the system to perform system administration services. The administrator 23 or system administrator 25 can log in to the system to register a new lock, a new key or a new maintenance manager 24. The communication paths between the terminals 23,24, 25 and the server 2 are labeled 18.

Fig. 2 is the overview of the program design in this embodiment. The unit 140 in this diagram represents either of the terminal. 21 or the mobile phone 20. The unit 160 represents software present in the terminals 23,24, 25 for communicating with the database system 150.

The key 13 contains firmware 131 including an application program, and a database 132 containing key data, including rules downloaded from the unit 140, and data recording the interaction of the key 13 and lock 12. The embedded program 131 is for managing communication between the database 132 and the unit 140.

The unit 140 contains software 141 which is a small device client program located in the user's office PC 21 or mobile phone 20.

As described in more detail below, the unit 160 receives a plug-in or applet program 162 into a web browser 161.

The database system 150 includes server programs running on the server 2 and the database 1. The device server program 151 establishes the socket connection with the device client program 141 over a network, for example TCP/IP over the Internet. A livefeed server program 152 is used to update the information displayed in the web browser 161 automatically whenever there is a change in the SQL database 155. The SQL server program 154 will manage the data transfer in to or out of the database 1. In this present embodiment, an http web server program 153 allows http connections to the terminal 160 through the standard web browser 161.

The communication protocol between the key and the device client is via IrDA 14. The device server and the device client are connected via socket connection 15 over a network, typically TCP/IP. The web browser 161 and the web server 153 are connected via the http protocol over the TCP/IP network. In order to achieve real time display in the web browser, the plug-in or applet program 162 in the displayed webpage is able to get updated data from the livefeed server 152 over the socket connection 174.

Fig. 3 and 4 are flow diagrams of the operation of the socket connection 15 between the device client program 140 (installed in the user's PC or mobile equipment) and the device server program 151 installed in the server 2.

Referring to Fig. 3, in step 51 the data in the key 13 is beamed to the IrDA port of the PC 21 or the mobile phone 20. In step 52, the device client will establish the IrDA connection with the key. In step 53, the device client 141 will open the TCP/IP socket connection 14 with the device server. Once the IrDA connection 14 and the socket connection 15 is established, data in the key 13 can be sent to the device server 151 (step 54) and similarly the data in the device server 151 can be sent to key 13 (step 55). When data transfer is completed, the device client 151 terminates the IrDA connection 14 and the socket connection 15 (step 57).

Referring to Fig. 4, the device server 151 listens to the TCP/IP network (step 60) and upon a request being transmitted to it (step 61), it opens a socket connection 15 (step 62). In a multi-threaded design, the server 2 can communicate with many devices 140 at one time. In each thread, the server communicates with the device client (step 63) via the socket connection 15. The communication includes receiving data from the device client 141, performing error checking and data decryption, locating the device in the database, writing the received data into the device database 1, and reading data, encrypting it and sending the data to the device client 140. Once the communication is completed, the socket is closed and the thread is killed (step 64).

Fig. 5 is a flow-diagram of the operation of the livefeed server 152. The livefeed server 152 is used to update information to web pages on the terminals 23,24, 25 without refreshing the pages. When an Interne browser connects to the server 1, the livefeed server 152 sends a small client program (e. g. applet) 162 to the browser 161 (step 210). The client program will poll the livefeed server 152 at regular intervals (step 211) over, for example, a TCP/IP socket connection 18. When the livefeed server receives the polling signal (step 212), it

will probe the database 1 to get the latest data and send it to the client program 162. When the client program 162 receives the data (step 213), it stores it in a memory buffer and then displays the content on, for example, a computer screen.

Although it is mentioned here that the display is a computer screen, other kinds of methods for retrieving and displaying the data are possible within the scope of the invention, such as via a mobile phone installed with a suitable technology or software for the purpose, such as a Java program.

Turning to Fig. 6 shows the circuit design of the lock 12, while Fig. 7 shows the design of the key 13. The key 13 sends strong data pulses to the lock 12 via the contact point 122. The lock 12 includes a contact point 122, and a circuit 101 which contains a filter circuit to separate a signal received by the aerial 122 into power and data. The power is stored, and is sufficient to power the lock 12 and also operate a magnet solenoid contained within the lock (as described below).

The data transfer 14 between the lock 12 and key 13 is preferably in half-duplex mode.

The lock 12 further includes a NVRAM (non-volatile memory) 102 which contains information such as the lock header, for identifying the lock, and premise access history. It further includes a CPU 103 for establishing whether there is a match between data received from the key 13 and rules stored within the lock 12. After the exchange of data between the key 13 and the lock 12, if the CPU 103 gives permission to the lock 12 to open, the CPU 103 will issue a pulse signal of a predetermined duration to a magnet solenoid 104. The pulse has a duration which is preferably no more than 100 milliseconds, and more preferably no more than 50 milliseconds, such as 20milliseconds.

Compared to supplying power continuously (which is the technique used in conventional electronic locks), the technique used in the embodiment of supplying energy to the solenoid in pulses saves energy. For example, a

conventional lock may require an amount of power to open a lock 1000 times, but in comparison the same amount of energy in the present invention may be sufficient to open the lock 20,000 times. As described below, the reason why the embodiment can use pulsed energy, is that unlike conventional electronic locks, the embodiment uses a magnet solenoid instead of a normal solenoid.

Turning to Fig. 7, the key 13 includes a contact point 125. When lock 12 responds to the connection with the key 13, the key's contact point 125 become a high impedance input port and which is able to read data from the lock using the electronic contact. The key 13 further includes a battery 114, which is a rechargeable battery which can be charged via the contact 125 and a charging circuit 110. Whether the battery 144 is to be charged depends on whether the voltage level at the input to the battery is higher than the voltage generally delivered by the battery. The battery 114 supplies power to the key 13 and also to the lock 12 upon contact with it. A protection circuit 111 is able to monitor the battery voltage and provide short circuit protection. An IrDA transceiver circuit 116 employs the IrDA protocol and a transceiver chipset for wireless connection with a PC 21 or mobile equipment 20. The key 13 further comprises a NVRAM 113, which is a non-volatile memory and holds the configuration and access information. A Real Time Clock RTC 115 provides the date and time information. The key 13 transmits information to the database 1 for storage along with date and time information, and this allows verification of the access history. A unit 117 contains a pushbutton for enabling the initiation of an IrDA connection, and an LED for providing visual indication of access and communication status.

Fig. 8 is a flowchart of the operation of the lock 12. The lock 12 is powered and initialised on contact with the key 13 (step 30). The lock 12 then reads information stored in the key 13 (step 31). If the key's pushbutton is pressed, the key 13 will become a gateway (step 32) for the lock 12 to communicate with the server 2 through the user's office PC 21 or mobile equipment 20 to upload access history (step 34). Otherwise, the lock 12 will enter into the access mode

with key (step 33). In the access mode, the access rules will be checked, transaction will be logged and solenoid is activated if it is in granted status.

Fig. 9 is a flowchart of the operation of the key. After power up and initialisation (step 35), the key 13 will monitor the battery voltage (step 36) and blink the LED if the battery is weak, and shutdown the entire circuit if it is in an under voltage condition. If the lock 12 is detected (step 37), the key 13 will enter into the access mode (step 38). In the access mode, the access rules will be checked and transaction will be logged (i. e. access rules in the key will be checked and transaction stored in the key or the lock). If the key's pushbutton is pressed (step 39), the module will establish IrDA connection with the user's office PC 21 or mobile equipment 20 and data will be transferred to the server (step 40). If there are no other tasks, the key will go into sleep mode until it is re-activated by contact with the lock or by the pushbutton (step 41).

Fig. 10 is a perspective view of the lock 13, and Fig. 11 shows the exploded view of the lock 13. The lock 13 comprises a rugged rubber top 302 and a rubber bottom 307, which together provide an outer layer of water proofing and shock proofing. A screw 303 is used to tighten a cylinder insert 306. A compression spring 305 is used to spring load a shackle 301. A lock body 304 is used to house the cylinder insert 306. The rubber bottom 307 includes an aperture 361, which leads to an aperture 360 in one half 362 of the cylinder insert 306.

Fig. 12 is an exploded view of the cylinder insert 306, and the components within its other half. The direction which is towards the right in Fig. 12 is the direction towards the left in Fig. 11. It comprises an outer barrel 310 and an insert cap 323, which are to be fixed together. These elements do not move within the lock 12. The cylinder insert 306 further comprises a cylinder 321 which is for rotation about its longitudinal axis. Two insulators 312 are provided for insulated housing of two respective contact pins 311. The contact pins 311 are typically soldered directly onto a lock printed circuit board (PCB) 317

carrying a CPU 316, and are used to electrically connect to a portion of the key 13 when it is inserted into the lock 12. Two 0-rings 313a and 313b are used to waterproof the front and back ends of the cylinder 321 when it is fitted into the outer barrel 310. A magnet solenoid 315 is fitted inside the cylinder 321 and is secured by two guide pins 314. A lock plate 324 with a certain thickness is used to hold apart the two lock pins 319a and 319b located on respective sides of the lock plate 324. A torsion spring 318 is used to bias the lock plate 324. A C spring 320 is used to bias the two lock pins 319. The insert cap 323 is the rear cover of the cylinder insert 306, and is secured to the outer barrel 310. A circlip 322 is used to lock the cylinder 321 when the cylinder 321 is inserted into the outer barrel 310. The lock PCB 317 contains lock circuitry as illustrated in Fig.

6. The position switch 325 is used to locate the angular position of the cylinder when it is turned by the key.

Fig. 13 and Fig. 14 are cut away views of the assembled lock cylinder insert.

The direction which is uppermost in Fig. 13 is the direction towards the bottom of Fig. 12. One end 324 of the iock piate 362 is arranged in a depression 327 in the element 323. As described below, the depression 327 provides tamper protection. In Fig. 14, the outer barrel 310 is sectioned to display the assembled details of the parts that illustrated in Fig. 12.

Fig. 15 is a perspective view of the electronic key 13. Fig. 16 is an exploded view of the key 13. The key 13 includes terminal pins 330 extending through respective holes in an insulator body 331. The terminal pins 330 can be soldered directly to a PCB 335 of the key 13. The key includes a neck body 332 which is moulded to a plastic bottom case 333. A top cover 337 fits onto the bottom case 333, sandwiching the PCT 335. The neck body 332 provides strength for the key 13 to open the lock 12. The neck body 332 has U cuts 332a at both sides which work as a key retaining mechanism when the key is turning in the lock. The key 13 further includes a waterproofed pushbutton 334 inserted at the corner of the bottom case 333. The key further includes an IR lens 336

which provides a window for wireless communication along the path 14 shown in Fig. 1. The key further includes a pin 339 and a ring 338, which together provide a key chain holder assembly. The pin 339 must be inserted into the bottom case 333 with the ring 338 around it before the top cover 337 is closed.

The top cover 337 is sealed to the bottom case for the water proofing when the gadget is assembled. The light guide 340 is aligned with a SMD LED on the PCB 335 and provides status indication. The PCB 335 contains the circuitry as illustrated in the Fig. 7. Figs. 17 (a) and (b) are sectional view of the key 13, respectively in a side view and in a view in the plane marked as C-C in Fig.

17 (a).

Fig. 18 to 20 are cross-sectional views illustrating the operations of the lock cylinder insert 306. Figs. 18 (a) and Fig. 18 (b) are views through the cylinder insert in a plane including its longitudinal axis. When a portion of a key 13 is inserted into the aperture 362, power from the key is transferred to the lock 12 through the contact pins 311. The CPU 316 on the lock's PCB circuits 317 is then powered up and a communication link is established between the lock 12 and the key 13. After the data in the key 13 is verified by the lock CPU 316 and permission is granted, the lock circuit will wait until the key rotates the cylinder 321 mechanically to an angle, preferably 30°, before triggering the magnet solenoid 315. This rotation, as illustrated in Fig. 13, is such that the end 362 of the lock plate 324 is released from tamper protection 327. If the magnet solenoid 315 is not powered, a plunger (shown as 315a in Fig. 18a) is always kept in place in the solenoid by a constant magnetic force generated by a permanent magnet (not shown) and consumes no power. However, a small current pulse supplied by the circuit 317 will cause the solenoid 315 to oppose the magnetic force generated by the permanent magnet, and the hence release the plunger. A spring may then move the plunger away from the position in which it prevents the lock being opened.

Figs. 19 (a) and (b) are views through the central portion of the lock in the plane shown as A-A in Fig. 18 (b). These views show how the turning angle of the

cylinder is detected. When the cylinder is at angle 0°, the switch 325 is normally closed and is blocked by a small metal ball 326. When the cylinder rotates to 30° as shown in Fig. 19 (b), the metal ball 326 moves into a cavity and releases the switch to an'open'position.

When the lock circuit detects that the switch is opened, the CPU can process the decision of sending a current pulse to the magnet solenoid. At angle 0°, the lock plate 324 is blocking the lock pins 319 from moving inward. At angle 30°, if the magnet solenoid is pulsed because the data in the key allows the lock to be opened, the lock plate 324 moves away from the lock pins 319 and turning action can continue to an angle beyond 30°. The re-turning of the cylinder back to 0° pushes the lock plate 324 and the solenoid's 315 plunger back to the original positions. The pushing effect is achieved by the tamper protection profile 327 in Fig. 13.

Fig. 20 illustrates the mechanism of locking and unlocking by the lock plate 324.

The magnet solenoid 315 is pulsed to generate a magnetic fieid to oppose the magnetic force from the permanent magnet, and its plunger 315a is subsequently released. Due to the spring loading by the torsion spring 318 (shown in Fig. 12), the lock plate 324 will move away from the lock pins 319.

When the lock plate 324 is not blocking the lock pins 319, the lock pins 319 can then move inwards when the cylinder 321 rotates beyond 30°. If the lock pins were held in place by the plunger because the solenoid is not powered, the cylinder 321 is prevented from turning by the lock pins 319. The turning of cylinder unlocks the shackle (301 in Fig. 11).

According to the embodiment described, the key connects to a desktop PC or mobile equipment via the built-in IrDA port. The PC or mobile equipment may have network connectivity via LAN, dialup or GPRS network, and the key can communicate with the server through these protocols. The database server is therefore able to keep track of the detail information of all locks and keys deployed at field, and allows the administrator to directly configures the keys for accessibility of the users into different locked premises.