WO2001008107A1

WO2001008107A1 - Computer software for issuing one-time combinations to electronic locks with lock group control

Info

Publication number: WO2001008107A1
Application number: PCT/US2000/016338
Authority: WO
Inventors: Tim Reed; Gerald Dawson; Robert L. Edwards
Original assignee: Mas-Hamilton Group, Inc.
Priority date: 1999-07-22
Filing date: 2000-07-21
Publication date: 2001-02-01
Also published as: AU6604900A

Abstract

A computer program or a system designed to allow an authorized operator, typically a supervisor, to control which lock or group of locks that a particular individual or individuals are permitted to open. Typically, this lock control enables heigher levels of security and control over the access to locks and/or issuance of combinations for electronic locks.

Description

COMPUTER SOFTWARE FOR ISSUING ONE-TIME COMBINATIONS TO ELECTRONIC LOCKS WITH LOCK GROUP CONTROL

FIELD OF THE INVENTION

This invention relates to the field of computer software and specifically to computer software used to issue combinations to electronic locks where the software provides at least one user supervisor the ability to control which lock or group of locks a particular lock operator is authorized to enter.

DESCRIPTION OF THE RELATED ART

Currently computer software in general, and more particularly computer software used to issue combinations to electronic locks does not permit controlling access to one or more locks based on lock operator ID or the operator. Thus, it is desirable to have a computer software program that enables one or more designated personal to control which individuals are allowed to access a particular lock or group of locks. SUMMARY OF THE INVENTION

The present invention solves the problems discussed above and is a computer program and/or system designed to allow an authorized operator, typically a supervisor, to control which lock or group of locks that a particular individual or individuals are permitted to open. Typically, this lock control enables higher levels of security and control over the software used to control and issue combinations for electronic locks.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings incorporated in and forming part of the specifications illustrates several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:

Figure 1 provides an index to the logical flowcharts utilized in the software program that allows a supervisor to select which lock users will access which locks.

Figure 2 illustrates the initialization process of the software prior to displaying the main menu.

Figure 3 illustrates the logic flow utilized to update the configuration file for the software.

Figure 4 illustrates the logic flow utilized to activate/shelve locks using keys. Figure 5 illustrates the activate/shelve locks subroutine called from Figure 4.

Figure 6 illustrates the verify lock group subroutine called from the activate/shelve lock subroutine shown in Figure 5.

Figures 7 and 8 illustrate the store lock in table subroutine called from Figure 5.

Figure 9 illustrates the logic flow utilized in the store lock data into lock table subroutine called from the subroutine illustrated in Figure 8.

Figures 10 and 10A illustrate the activate ATM locks subroutine called from Figure 5.

Figure 11 illustrates the logic flow executed when the user selects process and calls the activate ATM lock subroutine or presses the cancel button and calls the cancel subroutine illustrated in Figure 5.

Figures 12 and 12A illustrate the programming logic executed when the user selects the change lock group button on the special supervisor menu.

Figures 13, 13A, 13B, 13C, and 13D illustrate the program logic executed when the user selects or clicks on the add a new user ID button from the user ID and key maintenance menu which may be called from the special supervisor menu.

Figure 15 illustrates the program logic to verify group ID subroutine that is called from Figure 13A.

Figures 16 and 16A illustrates the program logic executed when the user selects the dispatch FLM service from the FLM services menu. Figure 17 illustrates program logic that may be executed when a service call is reassigned from the FLM services menu.

Figure 18 illustrates the get reassignment subroutine that is called from Figure 17.

Figures 19 and 19A illustrate the programming logicexecuted when the user selects dispatch a route from the route services menu.

Figures 20 and 20A illustrate the program logic executed when the user selects reassign route from the route services menu.

Figure 21 illustrates the programming logic called in the verify FLM subroutine called from Figure 20A.

Figure 22 illustrates the list code subroutine called from Figure 23.

Figure 23 illustrates the reassign locks on the route subroutine called from Figure 20A.

Figures 24 and 24A illustrate the programming logic executed when the user selects list locks from the reports menu.

Figure 25 illustrates the display data display list of locks subroutine called from Figure 24A.

Figure 26 illustrates program logic executed for the get lock data subroutine called from Figure 25.

Figure 27 illustrates the program logic that may be executed when the user clicks on or selects the list activity log from the supervisor reports menu.

Figure 28 illustrates the program logic that may be utilized in the display activity log subroutine called from Figure 27. Figure 29 illustrates the programming logic that may be utilized in the get log data subroutine called from Figure 28.

Figure 29A illustrates the programming logic that may be utilized in the get next access group of record subroutine called from Figure 28.

Figure 30 illustrates programming logic that may be executed when the user selects or clicks on the display user info button on the special supervisor services user ID/key maintenance menu.

Figure 31 illustrates the programming logic that may be called from the get password data subroutine called from Figure 30.

Figure 32 illustrates the display lock combination subroutine that may be called from Figure 4.

Figure 33 illustrates the format combo subroutine that may be called from Figure 32.

Figure 34 illustrates the put lock group ID into lock record subroutine that may be called from Figure 10A.

Figure 34A illustrates the programming logic that may be used in the update lock records subroutine that may be also called from Figure 10A.

Figure 35 illustrates the get lock group ID subroutine.

Figure 35A illustrates the retrieve lock group subroutine.

Figure 36 illustrates the add or change user ID subroutine program logic.

Figure 37 illustrates the program logic that may be utilized in the change lock group subroutine. Figure 38 illustrates the programming logic that may be utilized in the get password record subroutine.

Figure 39 illustrates the programming logic that may be executed in the find lock group in lock data base subroutine.

Figure 40 illustrates the programming logic that may be utilized in the dispatch service call subroutine.

Figure 41 illustrates the programming logic that may be utilized in the check lock group subroutine that is called from Figure 40.

Figures 42 and 42A illustrate the programming logic that may be utilized to reassign a service call.

Figures 43 and 43A illustrate programming logic that may be utilized to dispatch a route.

Figure 44 illustrates the programming logic that may be utilized to fill in entries in the lock tab.

Figure 45 illustrates the programming logic that may be utilized to reassign a route.

Figure 46 illustrates the graphic user interface that a user may see after studying the lock control program.

Figure 47 illustrates the menu choices that may be available on the supervisor services menu.

Figure 48 illustrates the menu choices that may be available from the special supervisor function menu.

Figure 49 illustrates the update configuration file dialog box that may be displayed by clicking the update configuration file button of Figure 48. Figure 50 illustrates the user ID and key maintenance menu that may be accessed by clicking on the user ID/key maintenance menu button on the special supervisor menu.

Figure 51 illustrates the dialog box that may be utilized to add a new user, this dialog box may be accessed from the user ID and key maintenance menu shown in Figure 50.

Figure 52 illustrates the dialog box that may be utilized to change a users ID, this dialog box may be displayed when a user selects change a user ID from the user ID and key maintenance menu shown in Figure 50.

Figure 53 illustrates the change a user ID dialog box that is displayed when a user ID is entered in the dialog box shown in Figure 52.

Figure 54 illustrates the FLM service menu that is accessed from the menu shown in Figure 46 by selecting the select access to FLM services button.

Figure 55 illustrates a route services menu that may be accessed by selecting access to route services button from Figure 46.

Figure 56 illustrates the activate lock using keys from either the FLM service menu shown in Figure 54 or the route services menu shown in Figure 55.

Figure 57 illustrates the window or dialog box to utilized to change a lock group ID, this window may be displayed by selecting the change ATM/lock group ID button on the special supervisor menu. Figure 58 illustrates the dialog box or display windows that is utilized to dispatch a service call and may be accessed from either the FLM or route services menu shown in Figures 54 and 55.

Figure 59 is may be the dialog box displayed when the user selects the group ID button in the windows shown if Figure 58.

Figure 60 illustrates the dialog box that is displayed when the user ID selected is not eligible to service the ATM/lock selected.

Figure 61 illustrates the supervisor reports menu that is accessed by selecting the reports menu button on Figure 47.

Figure 62 illustrates the lock listing report showing the ATM/lock group ID's, this report may be generated when a user selects list ATM/lock log from the supervisor reports menu shown in Figure 61.

Figure 63 illustrates the list activity log that may be displayed when a user selects list activity log button on the supervisor reports menu shown on Figure 61.

Reference will now be made in detail to the present preferred embodiment to the invention, examples which are illustrated in the accompanying drawings.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Overview

The programming logic described in detail herein enables a user, typically a senior or supervisor user, to establish the particular locks and/or lock groups that a particular lock user is authorized to access. The program may be installed or run on a network or on individual computers. Preferably the software system is installed on a network. The advantage of this computer software is that lock users in different areas or who service only a specific group of locks would be prevented from accessing locks in other areas or for which they had no need or authorization to access.

Preferably a six or eight digit lock group code is employed. Each lock in a lock group would be given a six or eight digit identifier. Each lock user may also be given a lock group number that identifies the lock or a group of locks that the particular person is authorized to access. The user lock group ID may be two, four, six or in the event an eight digit lock group identifier is used, eight digits. The lock group user identifier as well as the lock group identifier may be any number of characters. A longer lock group ID permits managing a larger number of locks using the software. Additionally, blanks or wild card characters may be employed, however, the use of blanks or wild cards is not preferred due to the potential for errors.

Preferably for a user to access a particular lock in a lock group, the user ID must match corresponding characters in the lock group ID. For example, if the user lock group ID were a two character identifier, then the lock group ID for the lock that the particular lock user desires to access would have the two characters of the lock group user ID. Preferably, the lock group user ID would match the first two digits as read from left to right from the lock group ID. Alternatively, a different access scheme could be utilized whereby the user lock group ID could match the last two characters of the lock group ID as read from left to right. Other character placements schemes could equally be utilized. Similarly if a four digit lock group user ID was selected for a particular user then the four digits of the lock group ID would correspond to the appropriate four characters of the lock group ID for the lock the user desired to enter. Consequently, some users could have access to a greater number of locks than other users depending on the access requirements of a particular user and how the lock groups where established .

Detailed Description

Figure 1 illustrates the basic functional programming logic pieces that are utilized in the software program. Typically, the lock groups programming logic contains/utilizes an ATM/lock group definition routine 102; activate ATM locks and check lock group ID routines 104; the software routines that permit the user ID to be changed or a new user added 106; configuration files 108 that allow the user and/or the supervisor to alter the way the program functions; and the ATM database 110. This database contains the basic information about each lock.

Some embodiments of the program may contain a password database 112. This database is utilized when access to various functions is protected by a password. There may also be a ATM/lock group checking subroutines 114; subroutines that are utilized to display the ATM/lock group ID's 116; and a group of subroutines generally called back end functions 118 that support the overall program function. Each of these functions will be discussed in greater detail below. Figure 2 illustrates the programming initialization sequence that begins at terminator 202. This sequence takes the operator to the main menu. Typically, the application will load and initialize in the block 204 thereafter the logic checks to see if the configuration file was successfully opened in decision block 206. If there was an error detected then an error display message would be provided in block 208 and a return constant in terminator 210. When the configuration file was properly opened the initialization would continue in block 212. Next the user may log on in block 214. The log on provision is optional, however, this is a security system. Thus, it is preferred that only authorized users access the files that can generate combinations for locks. After the user logs on, if required, program logic verifies the users authorization to utilize the program in decision block 216. If the user was authorized the main menu would be display in block 218. When the user was not authorized to utilize the software and computer system an error may be displayed in block 220 followed by a return constant in terminator 222. A typical main menu 4602 displayed is shown in Figure 46. This menu permits the user to access FLM services 4604, route services 4606 and supervisors services 4608 that are provided by the software application.

In order to update the configuration file, the user typically selects the supervisor services button on Figure 46 which may cause the supervisor services menu 4702 shown in Figure 47 to be displayed. Thereafter, it is preferred that configuration file and other updates be only performed by a second tier supervisor who would access these functions by selecting the special supervisor menu button 4704 in Figure 47. Selecting the special supervisors function 4704 may display the special supervisor menu 4802 shown in Figure 48. An authorized operator may select the update configuration file button 4804 which may execute the program logic shown in Figure 3. Alternative programming logic would be obvious to one of ordinary skill in the art having seen and understood the programming logic illustrated in Figure 3.

The updated configuration programming logic shown in Figure 3 may display the update configuration window 4900 shown in Figure 49. Other graphically user interface displays/windows may be utilized to accomplish this function. The updated configuration file button 4804 in Figure 48 may cause the programming logic the Figure 3 that begins with terminator 302 to be executed. The programming flow transfers configuration values to the panel in box 304 for the initial display of the window. Next the program checks in decision box 306 to see if locks groups are configured.

Thereafter if lock groups are being utilized a check box would be set in block 308 and if the lock groups were not being utilized the check box would be cleared in block 310. Thereafter the configuration panel would be displayed at 312. This display may be similar to that shown in Figure 49. Preferably, the update configuration file window would contain the same information that is shown in Figure 49. The check box that would be displayed as a result of the programming logic shown in blocks 306, 308, 310, and 312 is shown in Figure 49 at 4902. Thereafter, after displaying the configuration window in block 312, the program waits for the user response in decision block 314. When the user selects exit, a cancellation or exit message would be display in display 316 and the program would return to the special supervisor menu at terminator 318.

When the user selects process or alternatively the user may select OK or some other button to indicate that the user wishes the program to update the user selections or changes to the update configuration file window 4900. The program could continue to block 320 where the changes made by the user would be transferred to the configuration record file. Thereafter in decision block 322 the program would see if the use ATM/lock groups check box 4902 contained a check. When there was a check in the box the program logic in box 324 would set cfg.lockgrps to true. When there was no check box the cfg.lockgrps would be set to false in block 326. Thereafter the configuration file would be update in block 328 and a completion message displayed in display block 330. Thereafter the program logic would return to display the changes to the configuration panel in display block 312 and await the user response in block 314.

Preferably the program would contain the above discussed provision that would allow the user to select or deselect the lock group feature. Alternatively, an embodiment of the program without the ability to disable the lock groups feature could provide the lock group functions.

Figure 4 illustrates the programming logic that may be accessed from the special supervisors function menu 4802 shown in Figure 48, the FLM services menu 5402 shown in Figure 54, or the route services menu 5502 shown in Figure 55. The programming logic shown in Figure 4 may be executed when the activate using keys function 5504 on the route services menu 5502 or the activate lock using keys function 5404 on the FLM services menu 5402 is selected by the user. Alternatively, the programming logic may be accessed from the special supervisor function menu 4802 by selecting the shelve ATM /lock button 4806. Selecting one of these three buttons may pull up an activate locks window similar to that shown in Figure 56 as panel 5602. The activate FLM services locks panel 5602 shown in Figure 56 is an exemplary panel that would be displayed when accessing the activate locks function from the FLM services menu 5402 using activate lock using keys button 5404. Similar panels could be shown when accessing the programming logic that begins with terminator 5402 from the special supervisor menu 5802 or the route services menu 5502. The difference could be the title of the window/panel as well as the lock mode would come up defaulted from the route services menu 5502.

Initially the programming logic may check to see if the dialog box 5602 is active in decision block 404. The dialog box is active if the lock record for the lock request is opened by an operator. The inclusion of decision block 404 helps maintain the integrity of the lock records and/or files. If the dialog box is not yet active then the programming flow may move to block 406 where the dialog active indicator is set. Thereafter, an activate locks subroutine 500 may be called.

The preferred programming logic for the activate locks subroutine 500 is illustrated in Figure 5 beginning with terminator 502. When the activate locks subroutine is completed the programming logic may check to verify that some of the locks selected are ok to activate or shelve in decision block 410. If none of the locks are "ok" then the programming logic would return at terminator 412. When some of the locks are "ok" the programming flow may continue to display lock subroutine 3200.

The preferred logic for this subroutine is illustrated in Figure 32. It begins at display lock combos terminator 3202. After the display lock combination subroutine 3200 has completed its logic, the cleared dialog active indicator will typically be set in block 416. Thereafter, the programming flow would return at terminator 412.

When the dialog was active in decision block 404 the program flow would move to decision block 418 where the program flow checks to see if the user is requesting to activate a lock. When the user is requesting to activate a lock the program flow moves to block 420 where the activation perimeters are set up in the programming logic. When the request is to shelve the lock the program logic moves to block 422 where the shelving perimeters for the particular are set. Thereafter the program logic may move to decision block 424 to check to see if the current use of the lock is for activation . When the current use is to activate locks in decision block 424 program logic may move to block 426 where the dialog box perimeters for the activate message is set up. When the current use is not activate or could be for shelving the lock the programming logic would move to 428 which sets up the message for shelving. Thereafter, from either block 428 or block 426 the programming flow may display a message stating that either the shelve function is in use by a particular operator or that the activate function is in use by a particular operator depending on the use selected by the current operator. Thereafter the program may return at terminator 412. The purpose for checking if the dialog box is activate in decision block 404 is to prevent corruption of the lock tables and files by two users using the files at the same time when the program is set up on a network.

Figure 5 illustrates the activate or shelve lock subroutine 500 that is called from the activate/shelve locks logic shown in Figure 4. This subroutine is one of two subroutines in the activate/shelve locks program logic that were altered to incorporate the lock groups feature. The subroutine begins at activate locks terminator 502 and continues to block 504 where the ATM/lock entry panel is initialized. Thereafter, the display panel is shown in block 506. The display panel that is shown in block 506 may permit the user/operator to enter information about a particular lock being activated. An example of one activate locks display window 5602 is shown in Figure 56. This information includes the lock group ID if utilized. After entering the data into the display panel the user in decision block 508 may validate and process the data entered with one or more functions. These functions may include accepting the data entered in block 510; selecting the previous lock in the list in block 512 clicking on the next button to get to the next lock in the list in block 514; processing the locks request for activation beginning with subroutine the activate ATM/lock subroutine 1100; or cancel the activate function to access the cancel activate function subroutine 1101 which result in the program returning at terminator 520 to the activate/shelve locks logic 400 at decision block 410. When the user clicks on the accept button the program logic will verify the ATM lock data in block 510. Thereafter the logic may check to see if the lock data has been accepted in block 524. If the data is not accepted an error message may be displayed and the program flow will return to the display panel 506. When the lock data is accepted the program logic may move to decision block 508 to check to see if lock groups are selected as being active in the configuration file. If lock groups are not active the program flow moves to decision block 538 and avoids the section of the program employed for the locks groups functionality. When lock groups are active the program flow moves to verify the lock group by ID using subroutine 600, thereafter the program logic checks the lock group ID in decision block 523. If there is an error in the lock group ID the program returns to display panel in block 506.

When no lock group ID has been specified the program flow moves to display block 534 where the user is asked if a lock group ID is desired. Thereafter in decision block 536 the user may select that they wish to use a lock group ID or do not wish to use a lock group ID. When a user desires to use a lock group ID in decision block 536 the program flow returns to display panel 506 where the user may enter a lock group ID. When the user does not desire to use a lock group ID the program flow returns to decision block 538. Additionally, when the lock group ID entered was valid the program flow may also move to decision block 538. Decision block 538 checks to see if the lock entered duplicates a lock already in the data base. If the lock is a duplicate then an error message is displayed in display block 540 and the program flow returns to redisplay panel block 506. When the lock is not duplicated then the program flow moves to the store lock and table subroutine 700. Upon completion of that subroutine the program logic also returns to display panel 506 where the user to select the next function.

When the user selects previous or next the program logic will get the previous or next lock in the list using block 512 and 514 respectively, thereafter, the program logic moves to transfer the lock data from either the previous or next lock to the panel in block 522 thereafter the program flow return to display panel 506 discussed above.

Figure 6 illustrates the verify lock group ID subroutine 600 called in Figure 5. The program logic for this subroutine begins with terminator 602. Thereafter, the program logic checks to the if a lock ID was entered in decision block 604. If the lock group ID is empty then a return constant is assigned in block 606. If the lock group is not empty then program flow continues to decision block 608, where the program checks for empty spaces or embedded blanks in the lock group ID. If there are embedded blanks in the lock group ID, an error message is displayed in block 610 and a return constant is assigned. When there are no embedded blanks the program flow may move to display block 612 where the program logic checks to see if the lock group ID is of the appropriate length. If the lock group ID is not of the appropriate length an error message is displayed and a return constant of 4 is assigned in block 614. If the lock group ID is of the proper length then a return constant is assigned in block 616. Thereafter the subroutine terminates and returns the particular return constant assigned in terminator 618.

This subroutine verifies that the lock group ID is present and formatted in the appropriate way for use in the program. In the preferred embodiment it is preferred that there not be blanks and that the lock group ID have a specific length of 2, 4, or 6 characters, however, the use of blanks or other group ID lengths is well within the skill of the art given the disclosure provided herein. A programmer can select any convenient return constants to display and/or control the remaining attributes of the program provided that the programmer is consistent in their use of those return constants. The return constants given are merely to provide an exemplary functional program.

Figure 7 and 8 illustrate the store lock in table subroutine 700 called from Figure 5. This subroutine checks to see if the data in the panel is in the proper format for storing in the lock data tables and for use in the remainder of the program. The format selected by a particular programmer may vary from that disclosed and as such this subroutine is merely exemplary of that utilized. The modifications to this subroutine provided to utilize lock groups were alternations in the store lock data in lock table subroutine 900 entered when the return constant is equal to 0.

Figure 9 illustrates the store lock data subroutine 900 called from Figure 8. This subroutine begins at store lock data terminator 901 and continues through the return terminator 922. Store lock group ID block 912 is added to store the lock group ID. The remaining portions of the program store other portions of the information entered on the lock. Figure 11 illustrates the activate ATM/locks subroutine 1100 and the cancel activate function subroutine1101 called from Figure 5. The cancel function 1101 begins at cancel terminator 1104 continues to the end dialog terminator 1160 or can return to the dialog window at terminator 1156 if the cancel is terminated. This routine is standard and will not be discussed in detail. The activate ATM/lock subroutine 1100 that begins with the process terminator1102 is also unchanged from prior subroutines with the exception of the activate lock subroutine 1000 that is called after block 1126. The remaining portions of the subroutine illustrate portions of this subroutine 1100 have not been altered to support lock group functionality .

^• Figure 10 and 10A illustrate the activate lock subroutine 1000 which begins with activate lock terminator 1002. In the activate locks subroutine 1000, a put lock group ID into lock record subroutine 3400 has been added. The remaining portions of this subroutine indicated in blocks 1002 through 1094 including the subroutines called therein were not changed to support lock group functionality and therefore do not need to be discussed in detail.

Figure 12 and 12A illustrate the program logic utilized to change the lock group ID and may be called from the exemplary special supervisor functions menu 4802 shown in Figure 48. The program logic illustrated in Figure 12 is typically accessed using button 4808 titled "Change ATM/Lock Group ID." On selecting this function the change lock group program 1200 executes. This program logic begins at the change lock group terminator 1202. Thereafter the dialog box is initialized in block 1204 and displayed in block 1206. An exemplary dialog box is shown in Figure 57 as the change ATM/lock group ID window 5700 illustrating process button 5702, which initiates program logic beginning with block 1210 of Figure 12; an exit button 5704, which terminates the dialog box at exit terminator at 1208; and a get lock group ID button 5706, which initiates the program logic beginning with the verify data in panel fields block 1212.

When the user selects the exit 5704 the program logic exits from the change lock group program 1200 an returns the user to the exemplary special supervisor functions menu 4802, shown in Figure 48. When the user selects the process button 5702 the program logic may move to block 1210 were the program logicverifiesthatthe current program operator is authorized to access this feature. Thereafter the program logic moves to decision block 1214 were the program logic verifies access. If the operator is not permitted access to the change lock group function the dialog box will close at dialog terminator 1216. The functions provided in blocks 1210, 1214 and 1216 are only required if the program utilizes a security function that verifies that the operator is authorized to access various features and functions of the program.

Thereafter, the program logic may move to block 1218 were the program logic retrieves the data from the exemplary change ATM/lock group ID dialog box 5700, shown in Figure 57. Alternatively, the program in block 1218 could accept user input. Thereafter, the entered data may be verified in block 1220. After verifying the data, the data may be checked in decision block 1220 to see if it is valid. If the data is not valid the program moves to decision 1258 where the program logic checks for errors. If there are errors a display message is shown in display block 1260. Thereafter the program flow from either decision block 1258 or display block 1260 continues to block 1262 where the program logic updates the panel with current data and returns and the program logic to display the change lock group ID panel 5700 in display block 1206.

When the data in decision block 1220 is valid the program logic may move to check that the lock group entry is valid according to the programmers predetermined criteria. In the current preferred embodiment the program verifies that there are no blanks or spaces in the lock group ID and that the lock group ID has a valid length. Blanks are checked for in decision block 1224 and length is checked in decision block 1230. If a blank is found in block 1224 an error message is set up in block 1226 and a return constant is set in block 1228. When the length is invalid in decision block 1230 an error message is set up in block 1232. Preferably this error message specifies that the lock group length must be either 0, 2, 4 or 6 characters long. Thereafter a return constant is set in block 1234. The program flow from either block 1228 or 1234 then continues to decision block 1258 with the result as discussed above.

After verifying that the lock group ID is properly formatted in blocks 1224 and 1230 the program logic continues to the update lock ID subroutine 3700 which is discussed in detail below. After updating the lock group ID the program logic may verify that the update was successful in decision block 1238. When the update was successful a message indicating such may be displayed in block 1240. The program logic could continue at decision block 1258 by checking for errors as discussed above. When there is a problem found in decision block 1238 the program logic may check to see what the problem with updating the record was in decision block using a series of decision blocks and error messages.

In decision block 1242 the program logic checks to see if the lock record was found, if not, an error message stating that the lock message was not found may be set up in block 1224 and displayed in block 1260 as discussed above. The program logic may verify that the serial numbers match in decision block 1246. If the serial numbers do not match then the appropriate error message may be set up in block 1248 and the program logic continues to decision block 1258 checking for errors. The program logic may check to see if the lock record is open in decision block 1250. An open lock record occurs when a combination has been issued for a particular lock and a close seal has not yet been received. If the lock record is open then a lock is open error message may be set in block 1252 with the program logic thereafter continuing to decision block 1258 checking for errors. The program logic may also check to see if the lock file is busy in decision block 1254. The lock file is busy if another operator in the network is using the lock file and to prevent corruption only one user at a time may access a particular lock file. If a particular lock file is busy, a lock file busy message may be set up in block 1256 with the program logic thereafter continuing to check for errors in decision block 1258 as discussed above. When the user selects the get lock group ID button 5706 shown in Figure 57 the program logic beginning with block 1212 of Figure 12 would be initiated. Lock 1212 verifies the data displayed. Thereafter, in decision block 1264 the data's verified to be valid. If the data is not valid the program logic moves to decision block 1290 where errors are detected, if errors are detected the appropriate message is displayed in display block 1292 the program logic from either lock 1290 or 1292 would return to the display change lock group ID panel block 1206.

When the data in block 1264 is valid the program logic moves to the get the lock group ID from the lock database using subroutine 3500. Thereafter the program logic may check the return constant from subroutine 3500 and performs the appropriate function. The return constants selected are based on the convenience of the programmer and are provided for exemplary purpose only. When the return constant is 0 in decision block 1268 the group ID assigned is transferred to the data panel and the program logic continues to block 1270 and the program logic thereafter continues to decision block 1290. When the return constant is 4 in decision block 1272 an error message is set up in block 1274 indicating that the lock has no group ID assigned when the return constant is 8 in decision block 1276 a message in block 1278 is set up to indicate that the lock is not in the database. When the return constant is 12 in block 1280 an error message is set up in block 1282 indicating that the serial numbers was not found for this lock and when the return constant is 32 in block 1284 a message is set up in block 1286 to indicate that the database is busy. Additionally, in block 1288 an unknown error message is set up if one of the preformatted errors is not detected, thereafter the program logic would check for errors in block 1290 if an error was detected the appropriate display message would be displayed in display block 1292 and the program would return to display the change lock group ID panel at display block 1206.

Figures 13, 13A, 13B, 13C and 13D illustrate the program logic employed to add or change the user ID. This program logic may be accessed from the user ID and key maintenance menu 5002 shown in Figure 50. The user ID and key maintenance menu 5002 may be accessed from the special supervisors functions menu by selecting the user ID/key maintenance button 4810. An example of the adding a user ID dialog box displayed by the add user ID program 1300 is shown in Figure 51. The adding a user ID window 5102 is a windows dialog box utilized in the add a user ID program logic 1300. The program logic begins with the add user ID terminator 1301 and continues through logic elements with reference numbers through 1444. To add the functionality of the lock group ID's, changes to the existing program to add new users was required. Many of the features shown would not be required when adding a new user strictly for the purpose of lock group ID's. However, for complete disclosure the entire flowchart is shown. Only the changes, however, will be discussed.

Blocks 1306, 1308 and 1309 were added to support lock group functionality. Block 1306 loads a string forthe lock group ID shown in text box 5104. Thereafter the program logic in decision block 1308 checks to see if lock groups are active. If the lock groups are active the program logic continues with block 1310 loading strings to the two command buttons 5106 and 5108 labeled process and exit respectively. When lock groups are not active in the configuration menu then the ATM lock groups edit box 5104 would be disabled in block 1309. The add user ID panel 5102 is displayed at display box 1316. Because the add user ID program 1300 is also utilized in the change user ID subroutine after loading the command strings in block 1310 a decision block at 1311 checks to see if changing user ID dialog is required, if so, the load user ID data into panel subroutine 1300A is utilized. This subroutine shown in Figure 13A begins at load user info terminator 1445. The addition to this subroutine is block 1450 where the program subroutine logic gets the lock group ID from the database.

Additional changes to the add user ID program 1300 include the addition of decision block 1366 which checks to see if lock groups are active, if the lock groups are active, the verify lock group ID subroutine 1500 is called and thereafter the lock group ID is verified in decision block 1367. A similar set of logic processes is shown in the beginning at decision block 1339 and again checking that lock groups are active, if the lock groups are active, calling the verify lock group ID entered subroutine 1500 and then checking that the lock group ID is valid at decision block 1541. This subroutine is associated with the change lock group ID portion of the subroutine and as such calls the set change indicator 1400A as discussed below. Additionally, two other subroutines called by the add/change user ID program 1300 have been updated to utilize the lock group functionality disclosed herein. These subroutines included in the update database subroutine 3600 and the update configuration data routine 300 are discussed above.

The change user ID portion of the subroutine begins at terminator 1393 and is accessed with button 5006 on the user ID and key maintenance menu 5002 shown on Figure 50. This button may display the change user ID function window 5202 shown in Figure 53. This window could be displayed at display box 1398. Thereafter upon selecting the process button 5204 the change a user ID window 5302 shown in Figure 53 would be displayed in place of window 5102 when the add user ID program 1300 was called after decision block 1423.

Figure 14 illustrates the set change indicator subroutine 1400A called from Figure 13A. Program logic first checks to see that the lock group ID is the same as that in the past with record in decision block 1482. If the lock group ID's are not the same then a change flag is set in block 1484. Thereafter from either decision block 1482 or 1484 the program logic returns at lock 1486.

Figure 15 illustrates the verify group ID subroutine 1500 called from Figure 13A. This subroutine verifies that the lock group ID entered is properly formatted and that if the lock group is not found in the lock database that the user wants to use this new lock group.

The verify group ID subroutine 1500 begins with the verify group ID terminator 1502. In the preferred embodiment, a group ID would not contain blanks and would have a pre-specified length of either 2, 4 or 6 characters. However, a lock group ID could contain blanks and could be any length. If the programmer permitted blanks or any length of a lock group ID then checking for these items would not be required. The program logic checks to see if the group ID contains blanks in decision block 1504. If the lock group ID contains blanks then a message would be displayed at block 1506 and a return constant set. Thereafter the program flow from blocks 1506 and 1504 may continue to decision block 1508 where the length of the lock group ID is checked. If the length is 0 then the program logic would continue to block 1510 where the lock group ID would be blank. Thereafter the program logic would continue to execute the find lock group in subroutine 3900. When the lock group length was 2, 4 or 6 characters in decision block 1508 then the program logic would move directly to the find lock group in lock database subroutine 3900. If the length was not 0, 2, 4 or 6 characters then the program logic would move to display an error message at display block 1522 and set a return constant. After the find lock group in lock database subroutine 3900 was complete program logic would then check to see if a lock group ID was found in decision block 1514. If the group ID was not found then a display message may be displayed in block 1516 stating that the lock group ID entered was not found and asking the user if that lock group ID used. The program flow thereafter continues in decision block 1518 were the user can choose to use the new lock group or to not use the lock group selected. If the user chooses not to use the group ID entered then the program logic continues to block 1520 which sets up the appropriate message. Thereafter the program flow from blocks 1522, 1520, 1518 and 1514 may continue to terminator 1524. Terminator 1524 returns the program logic flow to the point in the program control to the function calling the verifying group ID subroutine 1500.

Figure 16 and 16A illustrates the program logic utilized to dispatch a service call. A service call may be dispatched from either the FLM services menu 5402 using the dispatch service call button 5406 both shown in Figure 54 or from the route services menu, an example which is 5502 using dispatch service call button 5408 an example shown in Figure 55. Both the FLM services menu 5402 and the route service menu 5502 are exemplary and other icons or methods of accessing dispatching a service call may be utilized. The dispatch service program 1600 commences at dispatch FLM service terminator 1602. The dispatch service call program 1600 has been modified for use with lock groups thus only the modifications will be discussed.

Decision block 1606 checks whether lock groups are active. If lock groups are not active in the configuration file, then in block 1608 the get ATM lock group button would be disabled. An example of the get ATM lock group button is shown in Figure 58 as the group ID button 5802 on the dispatch and FLM services call screen 5800. Thus, block 1606 and 1608 act to disable this button or similar button when the dispatch a FLM services call screen 5800 is displayed in display block 1618. The use of the group ID button 5802 along with the lock group functionality described in Figure 16 is optional and would not be required to use lock groups and is added for ease of operator use. Additionally, changes to the dispatch lock subroutine 4000 were made to support lock group utilization. Selecting the group ID button from the dispatch service call screen 5800 in the preferred embodiment executes the program logic shown beginning with the get data from panel lock 1622 and continuing to update data in panel lock 1652. After obtaining the data from the panel, an example which shown in Figure 58, the data is checked for a lock name in decision block 1624. If a lock name has not been entered then a message is formatted in block 1626 to inform the user that they must enter a lock name. Thereafter, the program flow continues when a lock group name is present to the get lock group ID subroutine 3500. Thereafter, the program logic checks to see if a lock group ID was found in block 1628. If a lock group was found then a message would be formatted and displayed in display block 1630, an example of one possible display message is that shown in the dispatcher route for a route service call is shown in dispatcher route service call window 5900 shown in Figure 59.

If no lock group ID was found the program logic may move to decision block 1632. Decision block 1632 checks to see if there is a group ID. When there is no group ID a message is formatted in block 1634 indicating no group ID. The program logic may also check for other errors or reasons that a lock group ID was not found. These include that the lock was not found which may be checked for in decision block 1636 and an error message indicating this information may be then formatted in block 1638. If the lock database was busy at the time of the request this may be checked in decision block 1640 and an appropriate message formatted in block 1642. Also the program may check to see if the return constant is a value that does not correspond to any preset error message in decision block 1644 and then format an error message in block 1646. Thereafter the program logic moves to decision block 1648 which checks for errors and displays the appropriate error message in display block 1650. Thereafter the data in the panel is updated in block 1652 and the program logic may return to display block 1618.

Figure 17 illustrates the program logic that is accessed if it is desired to reassign a service call. This program logic may be accessed form either the FLM services menu 5402 with a reassign service call button 5408 or from the route service menu 5502 with the reassign service button 5510. The program logic utilized to reassign a service call was modified. These changes are contained in changes to the get reassignment subroutine 1800 discussed below.

Figures 18 and 18A illustrate the get reassignment subroutine 1800. This subroutine begins at the reassign lock service terminator 1802 and continues through display message block 1882. The changes to add the lock group functionality are contained in the reassign call record subroutine 4200.

Figures 19 and 19A illustrate the program logic used to dispatch a route. A route may be dispatched from the route services menu 5502 utilizing the dispatch a route button 5512. The changes to the dispatcher route program 1900 are included in changes to the dispatch route subroutine 4300 and the display combinations for route subroutine 3200 both of these subroutines will be discussed in greater detail below. The remaining portions of the dispatcher route program 1900, which begins with dispatcher route terminator 1902 and includes logic boxes through 1991 provide functionality that was not changed to incorporate the lock groups features.

Figures 20 and 20A illustrate the program logic that may be utilized to reassign a route. A route may be reassigned from the routes services menu 5502 using the reassign a route button 5514. The program logic shown may be accessed by clicking the reassign a route button 5514, which calls the reassign a route program 2000. This program begins with reassign route terminator 2002 and includes logic boxes through 2096. To incorporate the lock groups function, the reassign in the route subroutine 2100 was altered as discussed below. The remaining portions of the reassign a route program 2000 were not altered to incorporate the lock groups features are not discussed.

Figure 21 illustrates the verify route service ID's subroutine 2100 that is called from Figure 20A. This subroutine did not require changing or alternation to incorporate the lock group features discussed herein and is provided for a complete disclosure.

Figure 22 illustrates the list code subroutine 2200 that is called from Figure 23. This subroutine begins list code terminator 2202 and continues to return terminator 2214. The list code subroutine 2200 also did not require modification to support the lock group features and is shown for a complete disclosure of the preferred embodiment.

Figure 23 illustrates the reassign lock subroutine 2300 called from Figure 20A. This subroutine begins at the reassign locks terminator 2301 and includes logic blocks through 2368. The reassign lock subroutine 2300 was modified to support using lock groups by modifying the reassign locks on a route subroutine 4500 and the display new combination subroutine 3200. The remaining portions of the reassign lock subroutine 2300 are unchanged and are provided for a full disclosure.

Figure 24 illustrates the list locks program 2400 that may be accessed from the reports menu 6100 shown in Figure 61. The reports menu 6100 is accessed from the supervisor services menu 4702 by clicking the reports menu button 4706. The list locks program 2400 is accessed from the reports menu 6100 by clicking the list ATM/lock button 6102. Clicking this button will initiate the program logic shown on Figure 24 that begins with the list locks terminator 2402 and continues through the program logic shown in display block 2478 an Figure 24A. This program included some modification so that the lock group would be listed in the report generated by the list lock program 2400. An exemplary report is shown at 6200 in Figure 62. Prior to generating the report shown on Figure 62, the list ATM/locks window shown on page 85 of the reference manual attached as Annex A is displayed to permit the operator to specify the list contents. The change to blocks 2404 and 2406 place the group ID heading and text box in the window displayed. After the user has entered the appropriate information for the locks that the user wishes to be listed the user would select the process button to continue and generate the report.

The changes to the program logic executed when the user selects the process button include changes to block 2412 where the program logic initializes return constants group ID indicators and error messages. Thereafter the program flow may move to decision block 2414 to check to see if the user was authorized to generate the report, if not, the dialog box would be terminated at dialog terminator 2410. Thereafter the program logic would get data from the panel at 2416 and then check various information about the data in the panel. In particular, if a lock group is the search parameter it is desirable to verify that the lock group entered is a valid lock group for the program.

First the program logic checks decision block 2420 if data has been entered into the lock group ID box. If data has been entered, the program logic continues to decision block 2422 and checks for embedded blanks in the characters. When embedded blanks are found, an error message is formatted in block 2424. Additionally, the lock group length may be check in decision block 2426 and if the lock group length was incorrect, an error message would be formatted in block 2428. As discussed above a lock group ID could contain blanks or have any length, however, in the current preferred embodiment it is preferred that the lock group ID not contain blanks and have specified lengths for ease of operator use.

Thereafter the program logic would continue at decision block 2430 where the program logic would check for errors. When there were no errors the program flow may move to decision block 2432 where the program logic checks to see it the lock group or some other field were selected in the panel. If both the lock group and another field were selected a message may be displayed in block 2434 stating that the selection other than lock group may be ignored and then asking in decision block 2436 if the operator wishes to continue. The operators response to the dialog box generated in block 2434 would set a return constant in either block 2440 or block 2438. Thereafter the program logic may continue to decision block 2442, which checks to see if there are any errors or if there are not errors or lock groups. If there are no errors or lock groups the program flow would continue to decision block 2444.

The program flow from decision block from 2444 has not been changed with the exception of block 2474. Decision block 2474 checks to see if the user has selected list all or lock group ID's prior to displaying data for the lock using the display lock data subroutine 2500. Thereafter after checking for errors in decision block 2476 and displaying any errors found in display block 2478 program logic would return to display panel 2408.

The list locks report subroutine 2500 is shown in Figure 25. This subroutine generates the report, an example of which is shown and referenced in 6200 in Figure 62. To incorporate the lock groups feature the get lock data subroutine 2600 called by the list locks report subroutine 2500 was altered to incorporate the lock groups features.

Figure 26 illustrates the get lock data subroutine 2600 called from Figure 25. The get lock data subroutine 2600 retrieves the data from one or several locks from a lock database table or other record and displays that information in the form selected by the programmer and useful for the operator. Typically this data would be displayed in a table format similar to that shown in Figure 62. The get lock data subroutine 2600 begins at get lock data terminator 2602 and concludes at either an end dialog terminator 2636 or at return terminator 2668. The changes to this subroutine to incorporate the lock groups features are shown in the subroutines used to list the lock data for a specific lock 2612 and list all locks in a lock group ID subroutine 2620. Additionally the heading 6202 titled "group" is added to indicate to the user the column that contains the group ID for a particular lock. The subroutine shown in block 2612 and 2620 would access the records that contain the lock data and retrieve that information. Such subroutines are believed to be of ordinary skill in the art as such are not shown in detail or discussed further.

Figure 27 illustrates the list activity log program 2700. This program may be accessed from the supervisor reports menu 6100 by clicking the list activity log button 6104. This program is substantially the same as that utilized in prior programs to list the activity log with the exception that the display activity report subroutine 2800 has been altered to incorporate the lock groups features. The list activity log subroutine begins at list activity log terminator 2702 and includes logic boxes reference numerals through 2772.

Figure 28 illustrates the display activity log report subroutine 2800 called from Figure 27. This subroutine is designed to display the exemplary activity log shown in Figure 63. The list activity log window 6300 is shown with a log entry 6303 that indicates a change in a lock group ID. The list activity file report subroutine 2800 begins at list activity file report terminator 2802 and continues through logic boxes 2848. Two subroutines called by the list activity file report subroutine 2800 were modified to incorporate the lock groups feature. These include the get log data subroutine 2900 and get access group subroutine 2960 both discussed below. Figure 29 illustrates the get log data subroutine 2900 called from Figure 28. The get log data subroutine 2900 begins at get log data terminator 2903 and terminates at end dialog terminator 2930 or return re terminator 2950.

The get and format activity log data subroutine 2922 is not illustrated that there are a large number of ways of formatting, storing and retrieving activity log event, date, time and text strings. The change to this particular subroutine including adding converters between event numbers and text strings which are used to minimize the activity log storage space required. Thus, a character identifier is utilized for events, for example, "Lock group ID changed for lock", would be represented by a single character to save storage space.

Figure 29A illustrates the get an access group subroutine 2960 that is called from Figure 28. This subroutine beings with get an access group terminator 2962 and concludes at return terminator 2972. The only change to this subroutine required for this lock groups feature was a change in the get lock data subroutine 2900 as discussed above.

Figure 30 illustrates the display user info routine 3000 that may be called from the user ID and key maintenance menu 5002 using display user information button 5008. The display user info routine 3000 beings at the display user terminator 3001 and includes logic boxes through reference 3010. Of the programming logic shown, support for lock groups was incorporated in changes in the get password data subroutine 3100 and in the subroutine used to invoke the on more subroutine 3036. A sample of the window displayed by the subroutine is shown on page 121 of the reference manual attached as Annex A. The changes to the on more subroutine 3036 were designed to accommodate the additional heading and file size used in the user information panel since the lock group ID would now be displayed for each user ID.

Figure 31 illustrates the get password data called from Figure 30. This subroutine begins at get password data terminator 3102 and concludes at return terminator 3136. The portions of this subroutine that are altered to support the lock groups feature are found at blocks 3122 and 3124.

The get and format password data subroutine 3122 was altered similar to the get and format activity log data subroutine 2922 discussed above to incorporate the ability to convert from a stored character to a text string for headings and for the contents of the lock group ID. Block 3124 that puts the data into the panel was also altered to provide a heading titled Lock Groups or Groups, as the programmer desires, to ease the operators utilization of the display box. In both the activity log and in the lock list if storage space for a text string was not considered important the conversions discussed would not be required and this data could easily be stored as a text string or in any other form.

Figure 32 illustrates the display lock combo subroutine 3200 called from Figure 4. The display lock combo subroutine begins at terminator 3202 and concludes at end dialog terminator 3242 and includes logic boxes through 3252. In order to support the lock groups features discussed herein the format display data for locks subroutine 3300 utilized in the display lock combo subroutine 3200 was altered. The remaining logic was unchanged and will not be discussed.

The format combo subroutine 3300 illustrated in Figure 33 begins with format combo terminator 3202 and concludes at return terminator 3360. The changes to this subroutine includes the addition of three return constants and associated messages shown in blocks 3318, 3322, 3326 . These messages indicate that the ID of the person requesting a combination is ineligible to receive that combination. This ineligibility would be based on the individual not having the proper lock group ID.

Figure 34 illustrates the put lock group in password record subroutine 3400 called from Figure 10A. The subroutine begins with put lock group in password record terminator 3402 and continues to lock 3404 which sets a string delimiter in the lock group ID his block would be optional if memory storage was not a consideration. Thereafter in block 3406 the lock group ID is copied to the specific record field location and then program returns to return terminator 3408.

Figure 34A illustrates the update lock record subroutine 3450 also called from Figure 10A. The program logic for this subroutine begins with update lock record terminator 3452 and terminates at either return true terminator 3458 or return false terminator 3466. The program logic utilized in the update lock record subroutine 3450 did not require alternations to support lock group features and is provided for a complete disclosure of the preferred embodiment. Figure 35 illustrates the get lock group ID 3500 that is called from Figures 12, 16A and 41. This subroutine obtains the lock group ID from the record, table, database or other file utilized to store the lock group ID for a particular lock. The subroutine begins with get lock group ID terminator 3502 and provides return constants at return terminator 3518. After initiation the subroutine finds the lock record without locking that lock record in block 3504 thereafter the program may verify that the lock record was found in decision block 3506. If no record is found the subroutine would return at terminator 3518. Additionally, the program may verify that the lock group ID string contained characters in decision block 3508. If the string is empty or null then the program logic would cause the subroutine to return. Furthermore, the program logic may check in decision block 3510 to see if the record lock group number matched that in the lock group ID string. When these two strings fail to compare a return constant would be set in decision block 3512 and the program returns. When the two strings are equivalent then the extract group ID from lock record subroutine 3550 would be called. Thereafter the lock group ID would be copied to a variable for output when the subroutine returned at terminator 3518.

Figure 35A illustrates the extract lock group ID from lock record subroutine 3550 called from Figure 35 and 44. This subroutine begins with retrieve lock group terminator 3552 and returns to return RC terminator 3564. Initially the lock group ID may be checked to verify that the string contains some data in decision block 3554. When the lock group ID does not contain data or characters a return constant is set in block 3558. When the lock group ID contains data the program logic may check to verify that the lock group ID has been initialized in decision block 3556. If the lock group ID has not been initialized then the program logic could also move to block 3558. The program flow from block 3558 would move to set the receiving string to null and block 3562 prior to returning to terminator 3564. When the lock group has been initialized in decision block 3556 the program logic may move to block 3560 where the group ID is copied from the record to the receiving string thereafter the program flow would return to terminator 3564.

Figure 36 illustrates the add or change user ID subroutine 3600 called from Figure 13B. This subroutine begins at add or change terminator 3602 and concludes at terminator 3648. The only changes required of this subroutine to support lock group features were changes in the put lock group ID into password record subroutine 3400 discussed above. The remaining functions in this subroutine are not discussed further.

Figure 37 illustrates the change lock group subroutine 3700 called from Figure 12A. This subroutine begins with the change lock group terminator 3702 and continues to the find lock record subroutine 3704 that finds the lock record and locks that lock record so that other users can not open the record. Thereafter, in decision block 3706 the program logic may verify that the lock record was found. If the lock record was not found the program logic would unlock the lock database and backup lock databases in block 3708 and update the activity log in block 3710 and return an appropriate return constant in terminator 3712. When a lock record was found in decision block 3706 the program logic would continue to find the backup log lock record in decision block 3714. Thereafter the program logic may check to verify that the backup record was found in decision block 3716. If the backup record was not found the program logic may move to block 3708 as discussed above. When the backup record was found the program logic may compare the lock serial numbers in decision block 3718. If these numbers fails to compare equal a return constant may be set in block 3720 so that the user would know the error in accessing the lock record. The lock program may also check to see if the lock is open in decision block 3722 and if the lock is currently open the return constant may be set in block 3724 to provide the user with this information.

Thereafter the program logic would store the lock group ID in the lock record in block 3726. Additionally, the program logic could call the update lock database subroutine 3450 discussed above to update the lock database. Preferably, the program logic verifies that the update was accomplished satisfactory at decision block 3730. If the update failed, a subroutine that could obtain the lock record number may be called in block 3736 to output this information, if required. After updating the lock database the program may update the backup lock database, if utilized, in block 3732. Utilizing a subroutine similar to that shown in subroutine 3450. Thereafter, in the preferred embodiment the program logic would check the update of the lock backup database was satisfactorily completed in decision block 3734. If this update failed, the program logic would again call the get lock record number subroutine 3736. Thereafter, program flow would return to block 3708 to unlock the database and update the activity log if utilized in block 3710 and return a return constant in terminator 3712.

Figure 38 illustrates the get password record subroutine 3800 called from Figure 10. This subroutine did not required alternation to accommodate the lock groups feature and is shown for completeness. The subroutine begins at get password record terminator 3802 and terminates at terminator 3822 and utilizes logic boxes with reference numbers through 3834.

Figure 39 illustrates the subroutine utilized to find a lock group in the lock database. The find lock group in lock database in subroutine 3900 begins with terminator 3902. Variables may be initialized in block 3904 and then depending on the lock record utilized the first lock record may be skipped in block 3906. In the preferred embodiment the first record in the lock record contains security and other information that is not required to be searched when finding a particular lock group in the lock database. Thereafter the program flow may check in decision block 3908 to see if the search has been completed. If the search has been completed in block 3908 then the program flow would move to decision block 3910 to check for errors, if there were no errors then a return constant would be set at the number of locks found in block 3912 thereafter the subroutine would return at terminator 3914.

When the search is not complete in decision block 3908 the program logic may check to see if the current record has been deleted in block 3916. If the lock has been deleted then the program logic may move to a subroutine that would obtain the next lock record at block 3918. If the current record has not been deleted then the program logic may move to the subroutine that would retrieve the lock data from the lock table in block 3920. Thereafter, it is preferred that the program check this data for errors and/or matches prior to obtaining the next record, however, these checks are optional.

Preferably the program logic will check for database error at decision block 3922 and if there has been an error in the search and provide an appropriate return constant in block 3924 prior to returning the program flow to decision block 3908 discussed above. Additionally, the program logic may verify that the lock group ID matches the lock group ID in the record retrieved in decision block 3926. If these two values do not match then the program flow could move to the get next record subroutine 3918. When the values match the program flow may move to decision block 3928 which ask the user if they wish to stop after the first match. When the user wishes to stop after the first match then the lock count is set to one and the end search flag is set to true in 3930. Thereafter the program flow may return to the end search decision block 3908.

When the user wishes to continue searching after the first match, the program continues to decision block 3932 which checks to see if the user wishes to count all matches of that lock group in the database. In this event the lock counter is incremented in block 3934. If the user desires to build a matching lock table then in decision block 3936 the program flow will move to block 3938 to insert the lock entry into the lock table. Thereafter, the program flow could return to the get next record subroutine 3918 after incrementing the counter in block 3934. Thus, the find lock group in lock database subroutine 3900 may perform one of several different functions. It may determine if the lock group is in the database, it may count the number of times the lock group is in the database, or it may build a lock table depending upon the desires of the operator.

Figure 40 illustrates the dispatch service call subroutine 4000. This subroutine is called from Figure 16A. This subroutine begins at dispatch service call terminator 4002 and concludes with a return RC terminator 4056 that returns a return constant to the calling program. The addition of decision block 4024 and the addition of subroutine 4100 have modified this subroutine.

If lock groups are active in decision block 4024 then the program logic will call the check lock group subroutine 4100. If lock groups are not active then the program flow does not call this subroutine. These are the only changes that were made to the dispatch service call subroutine 4000 to enable the lock group feature.

Figure 41 illustrates the check lock group 4100 called from Figure 40. After the check lock group subroutine 4100 is called the program logic initiates a subroutine that finds a particular lock record in the lock database in block 4104. If the lock is found in decision block 4106 the program logic continues, however if the lock is not found an error message is formatted in block 4108 and the program logic moves to return to the calling program with a return constant.

When the lock has been found the lock group ID is obtained with the get lock group ID subroutine 3500. After that subroutine returns the program logic checks to see if the lock has a lock group ID in decision block 4110. If the lock does not have a lock group ID then the program flow moves to block 4112 where a return constant is set to allow the lock to be serviced and then the program logic returns at terminator 4114. If the lock group has a lock group ID in decision block 4110 then the program logic may move to decision block 4116 which checks to see if the ID of the individual requesting to access the lock has a group ID. If the user ID does not have a group ID then the lock group ID is set to null for that user in block 4118. If the user has a group ID then that ID is copied from the password record to a variable in block 4120. Thereafter, the program flow may move to decision block 4112 that checks to see if the group ID for that user is null. When the lock group ID forthe user is null the program logic does not compare the group ID to the lock group in decision block 4124. If the lock group ID's do not match in decision block 4124 then the program logic moves to block 4126 which formats an error message and provides a return constant to provide that error message.

Thereafter the program flow from decision block 4122, 4124 and 4126 may continue to decision block 4128 where the program logic may check to see if the lock is a dual mode lock. A dual mode lock requires two user ID's each entering their own combination to open the lock. If the lock is not a dual mode lock then the program flow would continue to terminator 4114. When the lock is a dual mode lock the program logic may continue to block 4130 where the group ID for the second user is copied from the password record to the working variable. Thereafter the program logic may check to see if the value of the group ID for user two is hull in decision block 4132. If the group ID for user two is null then the program would return and provide a return constant in terminator 4114. When the lock group ID or the second user is not null then the lock group ID's would be compared in decision block 4134. When the lock group ID's compare equal the subroutine return at terminator 4114. If the lock group ID's did not compare equal in decision block 4134 then the return constant would be set to indicate that the user number two was not eligible to access the lock. It is preferable that when formatting the error messages provided by blocks 4126 and 4136 the output enable the program user to determine what error caused a failure or a problem with the program and these errors are typically indicated by the return constant provided.

Figure 42 illustrates the reassign service call subroutine 4200 called from Figure 18A. This subroutine begins at reassign service call terminator 4202 and returns at terminator 4226 and has logic blocks through reference number 4292. The reassign service call subroutine 4200 has been altered for use with the lock groups feature by the addition of block 4222 which checks to see if lock groups are active if the lock groups are active then the check lock group subroutine 4100 discussed above is called after that subroutine has provided its return constant the program logic checks to see if the user ID's requesting access to the lock are eligible to access that lock in decision block 4224. If the user ID's are not eligible then the subroutine terminates at terminator 4226. If lock groups are not active in the software then the check lock group subroutine 4100 and decision block 4224 would be bypassed.

Figures 43 and 43A illustrate the dispatch a route subroutine 4300 as called from Figure 19A. This subroutine commences at dispatch a route terminator 4302 and terminates at terminator 4398. The program logic was modified by modifying the fill entries in lock tab subroutine 4400 and the check lock group subroutine 4100 discussed above.

Figure 44 illustrates the fill entries in lock tab subroutine 4400 called from Figure 43. This subroutine commences with fill entries in lock tab terminator 4402 and concludes with terminator 4450. This subroutine was modified to incorporate the lock groups features with changes to the retrieve lock group ID from lock record subroutine 3550.

Figure 45 illustrates the program logic utilized in the reassign a route subroutine 4500 that is called from Figure 23. This subroutine was modified to add the lock groups functionality by the addition of decision block 4522 which checks to see if lock groups are active in the configuration file. When lock groups are active the program logic is directed to the check lock group subroutine 4100 discussed above. After the subroutine returns, the reassign a route program logic preferably checks to see if the user ID checked is eligible to open the lock in decision block 4524. If the user ID is not eligible then the program flow preferably moves to decision block 4526 where the code indicating that the user ID is ineligible is stored for the current lock. Thereafter, the program flow from block 4522, 4524 or 4526 would continue in the remaining portions of the reassign route to subroutine 4500 that have not be altered by the addition of the lock groups feature. This subroutine will continue from block 4528 through the terminator 4586. Operation

The above discussion describes the programming features utilized in the lock groups feature which provides a supervisor or other person the ability to control which users can access which lock or lock groups in the performance of their duties. A description of the use, operation, and further details regarding this program are contained in the user reference manual incorporated herein as Annex A.

In summary, numerous benefits have been described which result from employing the concepts of the invention. The foregoing description of a preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiment was chosen and described in order to best illustrate the principles of the invention and its practical application to thereby enable one of ordinary skill in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.

Claims

CLAIMSWe claim:

1. A method for controlling access to a plurality of electronic locks, the method comprising: assigning a lock group code to at least one of the plurality of electronic locks; assigning a lock group number to at least one of a plurality of authorized lock users; and comparing the lock group code for a requested lock and the lock group number for a requesting user.

2. The method of claim 1 , further comprising: providing an access code for the requested lock to the requesting user when the lock group number assigned to the requesting user indicates that the requesting user is permitted to open the requested lock.

3. The method of claim 1 , further comprising: providing a one-time access code for the requested lock to the requesting user when the lock group number assigned to the requesting user indicates that the requesting user is permitted to open the requested lock.

4. The method of claim 3 wherein the step of comparing, compares the lock group number to the lock group code character by character, beginning with the first character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

5. The method of claim 4, wherein a predetermined character when utilized in a lock group number is considered to match any character utilized in the lock group code.

6. The method of claim 3 wherein the step of comparing, compares the lock group number to the lock group code character by character, beginning with the last character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

7. The method of claim 6, wherein a predetermined character when utilized in the lock group number is considered to match any character utilized in the lock group code.

8. A system for controlling a plurality of locks comprising: lock group code assigning means for assigning a lock group code to each of the plurality of locks; lock group number assigning means for assigning a lock group number to at least one of a plurality of authorized users; and comparing means for comparing the lock group code for a requested lock and the lock group number for a requesting user.

9. The system of claim 8 further comprising: providing means for providing an access code for the requested Jock to the requesting user when the lock group number assigned to the requesting user indicates that the requesting user is permitted to open the requested lock.

10. The system of claim 9 wherein the providing means provides a one-time access code for the requested lock.

11. The system of claim 10 wherein the comparing means, compares the lock group number to the lock group code character by character, beginning with the first character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

12. The system of claim 11 wherein a predetermined character when utilized in a lock group number is considered to match any character utilized in the lock group code.

13. The system of claim 10 wherein the comparing means, compares the lock group number to the lock group code character by character, beginning with the last character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

14. The system of claim 13 wherein a predetermined character when utilized in the lock group number is considered to match any character utilized in the lock group code.

15. A lock combination issuing system comprising: a display screen having an area to enter a lock group code assigned to a lock; a user screen having an area to enter a lock group number assigned to an authorized user; and comparing means for comparing the lock group code assigned to a requested lock and the lock group number assigned to a requesting user.

16. The system of claim 15, further comprising: a combination display screen, the screen having a screen to display a combination for the requested lock when the lock group number assigned to the requesting user indicates that the user is permitted to open the requested lock.

17. The system of claim 16, wherein the combination is a one-time user combination.

18. The system of claim 10 wherein the comparing means, compares the lock group number to the lock group code character by character, beginning with the first character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

19. The system of claim 11 wherein a predetermined character when utilized in a lock group number utilized id considered to match any character utilized in the lock group code.

20. The system of claim 10 wherein the comparing means, compares the lock group number to the lock group code character by character, beginning with the last character of each of the lock group number and the lock group code and wherein the one-time access code is provided when each character of the lock group number matches a corresponding character in the lock group code.

21. The system of claim 13 wherein a predetermined character when utilized in the lock group number is considered to match any character utilized in the lock group code.

22. Lock combination issuing software that issues a combination to a lock when characters of the lock group ID of the person using the lock match corresponding characters of the lock group ID of the lock.