Patent Grant
7289023
I. Field of the Invention
This invention relates to security systems, and more particularly, to systems and methods of providing centralized monitoring of security guard tours.
II. Background of the Invention
It is well known and quite common for commercial and industrial premises to be protected by security companies providing on-site security guards as a service. A security company typically employs guards, which are assigned to patrol the premises of customers of the security company. To ensure that the premises are protected, each guard is responsible for thoroughly and regularly patrolling all or part of the premises. The security company will specify a “tour” that must be completed by a particular guard at predetermined intervals. A tour consists of a number of checkpoints located along a predefined route. While completing a tour, a guard inspects the customer's property, checking the security of doors and windows, and looking for intruders or other unauthorized activity. In addition, guards take note of situations that may tangentially affect security, including maintenance problems such as lighting fixture failures. To verify completion of each tour, a guard may be required to record the status of the premises at each checkpoint.
The tour record can be created manually, such as by writing entries into a log book, which is subsequently submitted to the security company. However, if a portion of the tour was not completed, or a non-emergency situation was logged, the security company would not be notified in a timely manner. For instance, if a theft went undetected during a guard's shift, the security company would have to review the log to determine whether the guard failed to detect the theft because one or more checkpoints were omitted from that guard's tour. Electronic tour tracking systems address this problem by automating the process of logging the tour. An electronic tour tracking system (ETTS) includes a means for electronically recording checkpoint conditions, and a means for uploading the information to a centralized monitoring center (CMC). The CMC may be located on or off the customer premises. With an exemplary ETTS, a guard touches a wand to a button fixed at each checkpoint, thereby creating an electronic record of the date and time that the checkpoint was toured. The record is stored in the wand until the guard uses a docking station to upload the data to the CMC. At a minimum, uploads preferably occur at the end of each tour.
If the guard encounters any condition or event that should be brought to the attention of the security company and/or customer, the guard may be able to enter additional information into the wand. The additional information is entered using a keypad, or a portable set of buttons to which the guard can touch the wand. Each of the portable set of buttons corresponds to a different condition or event, such as “broken lock” or “theft detected.” When the wand is uploaded, an exception is generated, which may appear as an icon alarm or other alert mechanism at the CMC.
An exception indicates to a CMC operator that a condition exists that must be rectified, for instance, by dispatching maintenance or security personnel by notifying emergency agencies or utility companies, or by notifying the customer. The condition is best rectified by selecting the most cost-effective and least disruptive option for determining the cause of the exception, and for notifying the appropriate responder. In other words, if the exception can be cleared by contacting the guard on duty to verify that a problem actually exists, the customer will appreciate that the problem is resolved without the customer's intervention. However, the exception may require the customer or operator at the CMC to personally reset an alarm. CMC operators typically simultaneously monitor more than one customer site in more than one geographic location—potentially all of the customers served by the security company. It is therefore difficult for operators to quickly determine the optimum protocol for addressing each exception that occurs, and to access the telephone numbers, work schedules, and names of guards, customers, local law enforcement, and supervisory staff that should respond to the exception. It is also possible for an exception to go unresolved, remaining in a pending state indefinitely if the operator fails to notice the alert.
Thus, although an ETTS can improve communication of conditions reported by the guard to the CMC and to the customer, the responsiveness and service quality of the security company can be impaired if the CMC personnel cannot properly respond to exceptions generated by the ETTS.
Therefore, there is an unresolved need for an ETTS that ensures that an exception is addressed by contacting the most appropriate responder for the situation.
The present invention addresses the needs identified above by providing systems and methods for addressing exceptions according to a predefined hierarchy, and for ensuring that each exception is resolved in a timely manner.
An embodiment of the present invention interfaces with an ETTS to control the resolution of exceptional conditions or events at customer premises by utilizing tour data from any number of customer premises in conjunction with security company, customer, utility company, and emergency agency data. The present invention receives tour data, and based upon predefined customer preferences and current conditions, generates a procedure to be followed to optimally resolve the exception.
One aspect of the present invention is the ability to customize an exception handling procedure according to various parameters, including customer, exception type, day, date, and time of day. In response to an exception, a contact list is generated, the contact list being associated with one or more of the parameters. The alarm created by the exception will not be closed out until the exception is resolved and an appropriate reason code for the exception is entered into the system.
Another aspect of the present invention is the ability to resolve the exception in the least costly and disruptive manner. Access to contacts on the contact list is controlled according to a predefined response hierarchy, preferably defined by the customer.
Another aspect of the invention is the ability to escalate the resolution to increasing higher levels of responders according to the severity of the exception or to the response or lack of response of the responder(s) previously contacted.
Yet another aspect of the present invention is the ability to generate reports that enable security companies and customers to improve infrastructure and response to exceptions.
In accordance with an embodiment of the present invention, a method for processing and resolving exception alarms associated with a guard tour at a premise comprises collecting tour data associated with a guard tour at a premise, analyzing the tour data to determine if an indication of an exception associated with the guard tour, and if an exception is identified in the analysis of the tour data, then generating an exception alarm, generating an exception handling procedure based on the exception and at least one other criteria, and receiving a reason code inputted by a user and based on the reason code closing the exception alarm or escalating the exception alarm. The other criteria utilized in generating the exception handling procedure may be selected from a group comprising the time, location, day of week, date, customer preference, and other identified exceptions. The exception handling procedure may comprise a list of people to contact in a specified order, and the step of collecting the tour data may comprise retrieving the tour data from a remote computer. The method may further comprise classifying the exception and storing the classification in a manner so that the classification is related to the exception, and/or generating at least one report based on a plurality of exceptions identified. The tour may include a tour plan that is randomly selected from a plurality of possible tour plans for the premise, and the step of analyzing the tour data may include determining if the tour data comprises one or more of missing checkpoints, improperly sequenced checkpoints, improper timing parameters for completion of the tour or individual checkpoints, and maintenance exceptions. Also, escalating the exception alarm may comprise contacting a next responder listed in the exception handling procedure.
In accordance with another embodiment of the present invention, a computer system for processing and resolving exception alarms associated with a guard tour at a premise comprises a collection module that periodically retrieves tour data associated with a tour at a premise, a comparison module that analyzes the tour data to determine if an indication of an exception associated with the guard tour, and an exception processing module that performs the following steps if an exception is identified in the analysis of the tour data: generating an exception alarm, generating an exception handling procedure based on the exception and at least one other criteria, and receiving a reason code inputted by a user and based on the reason code closing the exception alarm or escalating the exception alarm. The computer system further comprises an exception reporting module that generates reports based at least in part on the exception. The other criteria may be selected from a group comprising the time, location, day of week, date, customer preference, and other identified exceptions, and the exception handling procedure may comprise a list of people to contact in a specified order. Escalating the exception alarm may comprise contacting a next responder listed in the exception handling procedure, and the step of analyzing the tour data may include determining if the tour data comprises one or more of missing checkpoints, improperly sequenced checkpoints, improper timing parameters for completion of the tour or individual checkpoints, and maintenance exceptions.
In accordance with yet another embodiment of the present invention, a computer-readable medium having computer-executable instructions for performing a method for processing and resolving exception alarms associated with a guard tour at a premise comprises collecting tour data associated with a guard tour at a premise, analyzing the tour data to determine if an indication of an exception associated with the guard tour, and if an exception is identified in the analysis of the tour data, then generating an exception alarm, generating an exception handling procedure based on the exception and at least one other criteria, and receiving a reason code inputted by a user and based on the reason code closing the exception alarm or escalating the exception alarm.
An aspect of the present invention is the evaluation of the time interval between checkpoints on a tour. Intervals that exceed a predetermined range may result in an exception. The predetermined range can be user defined or based on a percentage variance or other criteria as desired. The predetermined intervals and range(s) can be empirically determined.
Additional objects, advantages and novel features of the present invention will be set forth in part in the description which follows, and in part will become more apparent to those skilled in the art upon examination of the following, or may be learned by practice of the invention.
Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
The present invention is described below with reference to block diagrams and flowchart illustrations of systems, methods, apparatuses and computer program products according to an embodiment of the invention. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions. The present invention comprises systems and methods for accurately and robustly predicting flame blowout precursors for combustors. The present invention is applicable to all types of combustors and is designed to operate over a diverse range of environmental condition, including varying temperatures, humidity, air compositions, and fuel compositions.
Exemplary embodiments of the present invention will hereinafter be described with reference to the figures, in which like numerals indicate like elements throughout the several drawings.
Application programs that are components of the invention may include routines, programs, components, data structures, etc. that implement certain abstract data types, perform certain tasks, actions, or tasks. In a distributed computing environment, the application program (in whole or in part) may be located in local memory, or in other storage. In addition, or in the alternative, the application program (in whole or in part) may be located in remote memory or in storage to allow for the practice of the inventions where tasks are performed by remote processing devices linked through a communications network.
The computer 50 also may include a plurality of drives interconnected to other elements of the computer 50 through the system bus 54 (or otherwise). Exemplary drives 72 include a hard disk drive, a magnetic disk drive, and an optical disk drive. Specifically, each disk drive may be connected to the system bus 54 through an appropriate interface 74. Further, the computer 50 may include non-volatile storage or memory through the drives and their associated computer-readable media. For example, the magnetic disk drive allows for the use of a magnetic disk; and the optical disk drive allows for the use of an optical disk. Other types of media that are readable by a computer, e.g., magnetic cassettes, digital video disks, flash memory cards, ZIP cartridges, JAZZ cartridges, etc., also may be used in the exemplary operating environment.
In addition, the computer 50 may include a serial port interface 76 connected to the system bus 54. The serial port interface 76 connects to input devices 78 that allow commands and information to be entered. These input devices may include a keyboard, a mouse, and/or other input device. Pens, touch-operated devices, microphones, joysticks, game pads, satellite dishes, scanners, etc. also may be used to enter commands and/or information. The input devices also may be connected by other interfaces, such as a game port or a universal serial bus (USB). Further, the computer 50 may include a monitor or other display screen 80. The monitor 80 is connected through an interface such as a video adaptor 82 to the system bus 54. The computer 50 may include other peripheral and/or output devices, such as speakers or printers (not illustrated).
The computer 50 may be connected to one or more remote computers 84, and may operate in a network environment. The remote computer 84 may be a computer, a server, a router, a peer device or other common network node, and may include many or all of the elements described in relation to the computer 50. The connection between the computer 50 and the remote computer 84 may be through a local area network (LAN) 86 and/or a wide area network (WAN) 88. The computer 50 is connected to the LAN 86 through a network interface 90. With respect to the WAN 88, the computer 50 may include a modem 92 or other device to channel communications over the WAN 88, or global data communications network (e.g., the Internet). The modem 92 (internal or external) is connected to the system bus 54 via the serial port interface 76. The network connections illustrated in
In accordance with an illustrative embodiment of the present invention, the SGTS program 70 includes a collection module 102, a comparison module 104, an exception processing module 106 and an exception reporting module 108. In operation, the centralized monitoring performed by the SGTS program 70 is executed in several phases. First, tour data is gathered using an ETTS, which is at least partially managed by the collection module 102. As described above, a guard completes a tour by collecting data at each checkpoint, and then the data is uploaded to the CMC. Next, the uploaded data is compared to tour schedules that have been established according to the customer's requirements, which is at least partially implemented by the comparison module 104. Customer requirements may vary based upon the level of service purchased by the customer from the security company, and the date, day, time, and conditions at the premises. If the comparison reveals that an exception has occurred, then an alarm is generated, and an exception handling procedure is invoked, which is at least partially implemented by the exception processing module. Finally, tour and exception data is reported for tracking and analysis by the customer and the security company, which is at least partially implemented by the exception reporting module 108. The operation and functionality of each module in accordance with an embodiment of the present invention is described in more detail below.
Collection Module
The data collection begins with a guard at a customer premise using an ETTS, for example, one of the systems available from Deggy Corporation of Miami, Fla. A schematic illustration of an exemplary system is provided in
In accordance with an aspect of the present invention, the tour plan may be random, as opposed to a set tour. That is, the specific sequence of checkpoints the guard is to pass may change according to which tour is selected. For example, a client site may have a plurality of tour sequences identified by tour codes, and when a guard checks in at a post or at some point prior to the time the tour should be conducted, one of the plurality of tour codes is randomly selected and communicated to the guard, such as by an automated call to the guard using voice simulation software or by e-mail. The selected tour is known by the computer 50 for implementation of the present invention. A table illustrating exemplary tour checkpoint sequences identified by a tour selection code is provided by
At the CMC, the collection module 102 of the computer 50 downloads the tour data from the FTP server at regularly scheduled intervals. In an exemplary embodiment, as illustrated in
Comparison Module
In the exemplary embodiment, as illustrated in
The comparison module then determines if a tour should have been completed since the last cycle of the module, as indicated by block 162. Based on the current time and the expected tour schedule, the comparison module decides that there should be at least some tour data stored to match the schedule. If no tours should have been completed since the last program cycle, then the process is restarted, that is, it is executed again at the time of the next program cycle, as indicated by block 164. For each tour that should have some tour data stored by this time of the day, the data from the tour requirements file is compared to the master tour file to determine if there is match of a tour in the tour requirements file with tour data in the master tour file, as indicated by block 166. If the comparison module does not find a tour in the master tour file that corresponds to a tour in the tour requirements file and is within a predefined period of time of when the tour should have been completed, then an alarm is generated.
If there is no tour data, an alarm is generated and stored in an alarm file on the computer disk drive, as indicated by block 168. The alarm file will contain information like, to which client the alarm belongs, when the tour should have been completed, and is it a service alarm or a maintenance alarm. In this example it is a service alarm because no tour was completed. Any variation in the tour schedule, outside a predefined tolerance, results in generation of an a service alarm.
If there is some tour data stored that matches the schedule, it is determined at block 170 if the tour data is complete. If the tour data is complete, then nothing is done but wait for the next cycle of this module, as indicated by block 172. If the tour data is incomplete, then a service alarm is generated and the module begins waiting for the next cycle, as indicated by block 174. It is worth noting that the process of checking whether or not there is tour data on file is done for at least each scheduled tour that should have tour data this cycle.
With reference now to
It should be noted that while the illustrative embodiment distinguishes between service alarms and maintenance alarms, this is not required for purposes of implementing the present invention. To the extent the alarms are classified, they need not be limited to service or maintenance, and may include additional or completely different classifications. An advantage to distinguishing the type of alarm is the ability to analyze and repot incidents based on the type of alarm, which may be useful in certain applications.
Exception Processing Module
In the illustrative embodiment, the CMC is continuously staffed 24 hours each day. Preferably, an operator monitors one or more display devices, which may be associated with one or more client sites or regions. The operator is preferably human, although a software application can be utilized instead to implement the functionality described herein. When an exception (i.e., alarm) is generated, an alert occurs. An alert may comprise an audible or visual alarm, such as a red alarm icon on the display device, which may blink or flash, and which may be accompanied by a beep or tone. The exception is then considered to be “open.” Once an exception is opened, the invention requires the operator to follow a procedure to close the exception.
A benefit of the present invention is that the exception handling procedure may be customized for each customer, each tour, each checkpoint, and each exception type. The exception handling procedure may also vary based upon the day of the week, time of day, weather conditions, or other parameter. Each exception handling procedure also includes a hierarchy of responders that are to be notified to clear the exception.
The security company can establish a set of default exception handling procedures. For example, the default exception handling procedure for a broken window exception can dictate that the responsible guard is the appropriate responder at the first level of the response hierarchy, followed by a maintenance supervisor at the next level of the response hierarchy. For each customer, the security company maintains a database of contact names, duty schedules, titles, and contact information. For each type of exception, which is preferably identifiable by a code, a contact list is generated that contains contact information for the appropriate responders for that exception code, in view of the customer requirements and other decision parameters (time of day, etc.). When the broken window exception occurs, the names and contact data for the responsible guard and the maintenance supervisor are retrieved from the database and presented to the operator for initiating the resolution of the exception.
The customer can elect to implement a variation of a default exception handling procedure, such as by adding a level to or removing a level from the hierarchy, or by conditioning one or more steps of the procedure on the occurrence of an event. The customer can choose to use the same exception handling procedure for multiple exception types. The customer requirements may call for a different exception handling procedure for the same exception code according to conditions on the customer premises. For instance, if the same exception code is received twice within a predefined period of time, the exception handling procedure may immediately escalate by skipping lower levels in the contact hierarchy. This feature is particularly useful in detecting trends in the observations of different guards on different tours of the same facility. If multiple “broken lock” exceptions are recorded by guards within one hour of each other, for example, the CMC operator effectively cross-references the tours, and provides a heightened response to an apparent intruder.
In the exemplary embodiment, as illustrated in
The calls are made by real people, preferably the operators at the CMC. The operators sit in front of a computer screen managing the exception processing. When an exception alarm is generated, a message pops up on the operator's screen that explains why the alarm was created, along with a list of the people that need to be called. The operator starts with the lowest ranking person on the list and calls each person, progressing up through the hierarchy, until a valid reason can be retrieved from the contact and entered into the alarm file. The users continue to call the responders until each alarm is closed with a valid reason code entered, as indicated by blocks 208 and 210.
The following is a non-inclusive set of examples of exception handling procedures according to the present invention:
On a Saturday afternoon, a “missed tour” exception is generated. A CMC operator promptly responds to an associated exception alert that appears on the operator's data terminal. By clicking on the alert icon, an exception window opens. The exception window contains a field that contains data from the master tour file, such as the client identifier, checkpoint identifier, an exception code and associated text indicates that the tour has been a missed, time and date that the exception occurred, and the name and contact information for the guard who should have completed the tour. If the customer premise is closed for the weekend and contains valuable and easily portable equipment, then the system generates an exception handling procedure that requires immediate notification of all guards on duty at the premise. Contact information for the guards is displayed, and the CMC operator notifies the guards of the situation. If the guard responsible for the tour responds, the CMC operator will determine whether the tour was completed, but not properly uploaded, or actually missed. If the tour was completed, the CMC operator inputs a reason code into a computer 50 that indicates the cause of the upload failure (e.g., guard error, equipment failure, or software failure), thereby closing the exception.
If the responsible guard is not reached, the CMC operator will request another guard to check the status of the responsible guard. If the operator determines that the tour was in fact missed without good cause, the “unexcused missed tour” reason code is inputted, and system provides the name and contact information of that guard's supervisor(s).
If no guards can be reached, the CMC operator enters the corresponding reason code, thereby causing the exception handling procedure to “escalate.” The exception handling procedure goes to the next level in the contact hierarchy. A new or updated exception window displays the next level of respondents to be notified—in this instance, the police.
On a weekday, a “broken lock” exception is generated at a busy office building. A CMC operator promptly responds to the alert by clicking on the alert icon, and an exception window opens. The exception window indicates that a lock on a door to the parking garage is broken, permitting access to unauthorized personnel. The exception handling procedure indicates that the CMC operator is to contact the responsible guard to verify the condition. If the condition is verified, the CMC operator enters the reason code into computer 50 that confirms the condition, thereby escalating the exception handling procedure, and receives contact information for the appropriate maintenance staff (either employees of the customer or outside contractors). The unlocked door creates a potentially dangerous situation for employees parking in the garage. Therefore, the “broken lock” exception code associated with that particular checkpoint also causes the exception handling procedure to prevent the CMC operator from closing the exception until the appropriate security company supervisor has also been notified of the situation. The security company supervisor will adjust tour schedules or dispatch additional guards to investigate and monitor the door until the lock is repaired.
If no guards can be reached, the CMC operator escalates the exception handling procedure by entering the appropriate reason code. The exception handling procedure goes to the next level in the contact hierarchy. A new or updated exception window displays the next level of respondents to be notified. In this example, the exception handling procedure may escalate through several levels of security company staff before notifying the police, to avoid unnecessarily disrupting the customer's operations while the situation is being resolved. Upon notifying the police, the CMC operator enters a reason code that indicates that police have been notified, but that the situation has not been resolved. The exception will remain pending until reason codes are entered that indicated that the police have found that the facility is safe, and the maintenance staff has repaired the lock.
A “water leak” exception is generated when a guard notices that condensate is draining from an air conditioner near a checkpoint. After upload, the CMC operator clicks the alert icon, and the exception window displays the customer's maintenance supervisor's name and contact information. The CMC operator contacts the supervisor, and informs the supervisor of the leak. The maintenance supervisor indicates that the problem will be addressed. The CMC operator enters a reason code that indicates that the customer intends to address the situation. However, this customer has required an exception handling procedure that, in response to this reason code, places the exception in a pending state, rather than allowing the CMC operator to close the exception. The exception remains in a pending state, periodically sounding or displaying a new alert, until the maintenance supervisor communicates completion of the repair to the CMC operator. The CMC operator changes the reason code to “customer has resolved,” thereby closing the exception.
In any instance, a CMC operator has the option to close the exception by entering a reason code that permits closing the exception, or to escalate the exception by entering a reason code that requires the operator to contact the next level of responders in the hierarchy. All exception codes and reason codes can be provided using any suitable data management tool, such as drop-down or pull-down fields, decision trees, or searchable field, etc.
An advantage of the present invention is the automated manner in which exception codes and alarms are generated, and the manual manner in which the operator enters reason codes to close or escalate the exception processing. This human interaction is often key to accurate, consistent and reliable resolution of exceptions.
At each level of the response hierarchy, the exception window may display a list of personnel that can be contacted. The CMC operator may contact any one of the personnel or agencies displayed in a given list, or may be required to contact the personnel in order, indicating whether each was successfully contacted. Responders can be contacted manually by the CMC operator, or an autodial or voice response feature can be implemented.
Exception Reporting Module
At least once daily, preferably, the exception reporting module calls at least one report program generator (RPG), which generates reports used by the customer and the security company to analyze the data collected and stored in the master tour file. For instance, the RPG can compile a report that show the frequency of specific types of exceptions. The security company can use this exception frequency report to determine whether a particular element of the ETTS, such as the docking station or a particular wand, should be replaced due to frequent failures. The RPG can also compile reports that identify problem personnel, by determining which guards frequently fail to correctly complete tours. The data gathered and stored in the master tour file can potentially be used for any number of purposes, including, but not limited to identification of training needs, and provision of information to insurance companies.
The foregoing description of the preferred embodiments of the invention has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. For example, all of the foregoing examples can be implemented with any suitable processing equipment and environment, and any combination of communications and device interface technologies. The exception handling procedures, responder types, exception types, information provided, and ETTS processes in the examples are not exhaustively enumerated. Rather, this invention is applicable to improving exception response procedures in any type of security system, which communicates over any suitable communications medium using any suitable communications protocol, and which provides information to a centralized control center or to distributed responders to optimize or customize the handling of various types of exception situations.
Checkpoint Interval Tracking
The comparison module can be configured to evaluate the time intervals between checkpoints on a tour to determine if the time it takes a guard to travel from one checkpoint to another is too short or too long, and in either case generate an exception as appropriate. The comparison module can determine the time interval between two checkpoints using timestamp data associated with each checkpoint. In accordance with the present invention, the time intervals can be the elapsed time between two consecutive checkpoints or the elapsed time between two nonconsecutive checkpoints. A time interval is compared to one or more predetermined values to determine if an exception occurred. The predetermined values can be empirically determined, and if desired, regularly updated based on use and/or other factors. In a preferred embodiment, the time interval is compared to a predetermined range. If the time interval is less than the minimum value of the range or more than the maximum value of the range then an exception is generated. Alternatively, an exception can be generated by comparing the time interval to only the minimum value or only the maximum value.
The result of the comparison may be utilized as a determining factor in generating an alarm or as one of several factors or criteria considered in the generation of an alarm. For example, the occurrence of another exception during the tour might negate the time interval exception because the reason for the other exception might be considered to have caused the time interval exception. In addition, the other data collected during that tour or another tour can be utilized to modify the predetermined maximum and minimum values. For example, rather than negating a time interval exception, as discussed above, the other exception may result in the increasing or decreasing of the predetermined time interval values. As another example, a single occurrence of a time interval being outside a predetermined may not result in an alarm, a certain number of occurrences, perhaps within a certain timeframe, may result in a alarm indicating the reason that the time interval is repeatedly outside the range should be investigated. It may even result in the modification of the predetermined time range, so as to include longer and/or shorter intervals of time.
A time interval less than the predetermined minimum time may indicate, for example, that the checkpoints have been moved, that is, the guard may have moved one or more of the buttons 122 from their respective locations throughout a facility to another location, presumably in an effort to reduce the length of the tour. This is undesirable because the relocation of the checkpoints jeopardizes the safety and security of the facility. Since some guards are generally unsupervised for a large portion of their shift, this additional degree of supervision is beneficial.
A time interval greater than the predetermined maximum time may indicate, for example, that the guard conducting the tour dealt with an issue during the tour, though presumably not one the guard was able to record as an exception with the wand 120. If such occurs on a regular basis, such as more than a predetermined times within a defined period of time as can determined by the comparison module, then an exception may be warranted and/or the cause of the delay investigated by the CMC. As an example, if the guard periodically finds and investigates a noxious odor at a particular location of the tour, then the guard may exceed the predetermined maximum time between checkpoints. If the wand 120 does not allow the guard to record an exception for noxious odors, then the problem may persist. Alternatively, when the time interval data is consistently outside the predetermined range, then that may generate a separate exception suggesting the predetermined values should be changed or at least reviewed.
In accordance with the random tour plan discussed above, the predetermined values or ranges can be designated by the particular tour plan or by the sequence of the checkpoints. Thus, once the tour plan or checkpoint sequence is known, then a time interval or range between any two checkpoints on the tour can be determined and utilized in accordance with the present invention.
In accordance with an embodiment of the present invention, there can be more than one predetermined range. For example, wherein a time interval that is outside of one range but within another might generate a different alarm than a time interval outside of both ranges. The different ranges may be considered in combination with other data collected during a tour, such as other exceptions or recorded conditions, in the generation of an alarm.
Accordingly, many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
This application is a continuation-in-part of application Ser. No. 10/461,249, filed Jun. 12, 2003, which is incorporated herein by reference in its entirety. This application also claims benefit of U.S. Provisional Application No. 60/388,999, filed Jun. 12, 2002, which is incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3781845 | Ellul | Dec 1973 | A |
| 3925763 | Wadhwani et al. | Dec 1975 | A |
| 4024527 | Houghton | May 1977 | A |
| 4141006 | Braxton | Feb 1979 | A |
| 4300124 | Vasquez | Nov 1981 | A |
| 4743892 | Zayle | May 1988 | A |
| 4801786 | Stobbe | Jan 1989 | A |
| 4922514 | Bergeron et al. | May 1990 | A |
| 5120942 | Holland et al. | Jun 1992 | A |
| 5166499 | Holland et al. | Nov 1992 | A |
| 5398277 | Martin, Jr. et al. | Mar 1995 | A |
| 5491672 | Ferris | Feb 1996 | A |
| 5572192 | Berube | Nov 1996 | A |
| 5610596 | Petitclerc | Mar 1997 | A |
| 5623258 | Dorfman | Apr 1997 | A |
| 5696486 | Poliquin et al. | Dec 1997 | A |
| 5926100 | Escolar | Jul 1999 | A |
| 6049272 | Lee et al. | Apr 2000 | A |
| 6078255 | Dividock et al. | Jun 2000 | A |
| 6104294 | Andersson et al. | Aug 2000 | A |
| 6266396 | Johnson | Jul 2001 | B1 |
| 6295346 | Markowitz et al. | Sep 2001 | B1 |
| 6353385 | Molini et al. | Mar 2002 | B1 |
| 6369705 | Kennedy | Apr 2002 | B1 |
| 6504482 | Mori et al. | Jan 2003 | B1 |
| 6693530 | Dowens et al. | Feb 2004 | B1 |
| 6798345 | Satoh | Sep 2004 | B2 |
| 6831563 | Contractor | Dec 2004 | B1 |
| 20020080025 | Beattie | Jun 2002 | A1 |
| 20020163998 | Mudd et al. | Nov 2002 | A1 |
| 20030081735 | Emory et al. | May 2003 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20060090101 A1 | Apr 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60388999 | Jun 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10461249 | Jun 2003 | US |
| Child | 11218175 | US |
