WO2001027787A1 - Event monitoring and closed-loop response system - Google Patents

Abstract

A system (20) and method is provided for automatically monitoring events occuring at devices (22) such as web servers (90) and websites (90), responding, and providing closed-loop response verification. The system (20) and method automatically identifies events, implements pre-specified actions in response thereto, and verifies that information regarding events has been successfully communicated. Once an event is detected and notification of at least one respondent has been completed, the system (20) awaits further information to indicate that the respondent (26) has received notification and/or has or will taken corrective action. The notification may be escalated to additional respondents (26) until some respondent (26) commits to take such corrective action. The present invention thus helps ensure that every event is recognized and any reaction is noted and the entire sequence of actions recorded. The system also includes supporting infrastructure to maintain and analyze event history, to preserve event information and to disseminate the information to clients (22). The system (20) and method is implemented in a self-provisioned website to provide an automated, cost-efficient service that is user controlled, flexible, and scalable.

Description

EVENT MONITORING AND CLOSED-LOOP RESPONSE SYSTEM

Related Application

This application claims priority to U.S. Provisional Application Ser. No. 60/159,271 entitled Automated Event Monitoring System, filed October 13, 1999, and to U.S. Provisional Application Ser. No. 60/175,664 entitled Automated Event Monitoring System, filed January 12, 2000

BACKGROUND

1. Field of the Invention

This invention relates to event monitoring, and more particularly to an automated web-based detection, reporting, and closed-loop response system for events occurring in remote devices, systems, and/or processes.

2. Background Information

Recognizing the importance of reliability and continuity of operation of computer-based assets and other systems, a means is needed to automatically detect abnormal events or conditions and notify response agents who or which will correct those conditions so as to prevent or mitigate consequential losses.

Additionally, recognizing the central role played by computers and the information stored in them, the growing and intimate interaction of information support equipment (computers and telecommunications) with humans, and the increasing economic impact of failures, a need exists for monitoring and/or protecting such systems in numerous applications .

Society is becoming increasingly dependent on information technology: Annual IT spending in the U.S. alone is projected to be $444 Billion in 2000 up from $409 billion in 1999. Within this market, the on-line business services segment in 2000 is projected to climb to $43.7 billion from $22 billion in 1999. Within this segment, the market for hosting and related network services is projected to grow from $2 billion in 2000 to $14.6 billion by 2003.

One of the emerging elements in the vast revolution of worldwide inter-connectedness is a growing concern, about the devastating impact of technical failures. Downtime can sometimes have an enormous cost in lost business and market share, lost opportunities, or disruption in organizational functions. The impact of damage from downtime may be especially severe when it is not promptly detected and addressed. Some estimates of downtime cost range from thousands of dollars per hour to millions per hour for competitive high transaction-volume e-businesses, particularly during times of peak demand, i.e., holiday shopping.

In response to these concerns, some IT managers have cobbled together some provision for detecting failures that occur after hours and notifying on-call staff to take corrective action. However, these ad hoc arrangements often leave much to be desired as they typically lack (1) verification of receipt of the message, (2) verification of a respondent's intention to take action and (3) provision for escalating levels of response notification. Large risks and haphazard emergency response capabilities have led to a widespread uneasiness among those with the ultimate responsibility for the viability of organizations of all kinds seeking to survive and grow in a world of accelerating change, intense competitive pressures, and increasing dependence on electronic technology.

Currently, several methods exist for monitoring downtime of servers, websites, and networking equipment, ranging from relatively inexpensive stand-alone software packages, to sophisticated in-house proprietary network operations centers staffed by network engineers. Recently, several internet-based firms have launched new monitoring services that target the growing small-business market. The major drawback to many of these solutions, however, is the use of open-loop ("Send & Pray") attempted notification which simply sends email or page alerts. There is no verification that an authorized person has received or responded to the critical event notification and there is no provision for escalating response notification to additional respondents.

Drawbacks of some NOC (Network Operation Center) operations typically include lack of formal, automated, response procedures, lack of detailed, time-stamped record keeping of all response activity, capacity limitations when unautomated labor-intensive, human judgment-dependent processes are required for all alarms, and lack of infrastructure for efficiently notifying clients of critical events and response activity. Thus, a need exists for an improved automated event monitoring system that overcomes one or more of the aforementioned drawbacks.

SUMMARY

According to an embodiment of this invention, a computer implemented method in an interactive medium is provided for automatically monitoring events at a remote device and responding to the events. The method includes the step of providing a monitoring site implemented in one or more digital computers, the monitoring site adapted for communication with at least one remote device. Additional steps include automatically determining that an event has occurred at the remote device and recording the event automatically. A response routine is implemented, which includes transmitting a responsive communication to at least one designated entity using at least one of a plurality of communication media. Verification of receipt of the responsive communication is sought automatically. The monitoring site may be self-provisioned by a remote user.

In another aspect of the invention, a computer implemented method in an interactive medium is provided for automatically monitoring events within a group of one or more remote devices and responding to the events. The method includes the step of providing a monitoring website adapted for communication with the group of remote devices. Additional steps include automatically determining that an event has occurred by periodically polling and listening for a predetermined acknowledgement from each of the remote devices in the group, wherein lack of receipt of a predetermined acknowledgement indicates that an event has occurred within the group. A response routine is implemented, including the step of transmitting a responsive communication to at least one designated entity using at least one of a plurality of communication media. Automatic verification of receipt of the responsive communication is attempted by listening for a reply to the responsive communication in at least one of a plurality of communication media. The implementing step and the automatic verification step is iterated for each of a plurality of designated entities until one or more reply (ies) to the responsive communication has been received, wherein receipt of the responsive communication is verified. The content of the group of devices is user- selectable .

In a further aspect of the present invention, a computer system in an interactive medium is provided for automatically monitoring events within a group of one or more remote devices, and for responding to those events. The computer system includes a monitoring website, which is adapted for communication with the group of remote devices.

An event handler is provided to automatically determine that an event has occurred by periodically polling and listening for a predetermined acknowledgement from each of the remote devices in the group. Lack of receipt of one of the predetermined acknowledgements is indicative that an event has occurred within the group. A response routine is provided which includes a communication module to transmit a responsive communication to a designated entity using at least one of a plurality of communication media. A verification module automatically attempts to verify receipt of the responsive communication by the designated entity by listening for a reply to the responsive communication in at least one of a plurality of communication media. The response routine sequentially transmits the responsive communication and attempts to verify receipt thereof, for each of a plurality of designated entities until the reply to the responsive communication has been received, wherein the receipt of the responsive communication is verified.

In a still further aspect of the present invention, an article of manufacture for conducting commerce in an interactive environment is provided. The article of manufacture includes a computer usable medium having computer usable program code embodied therein. The computer usable medium includes computer readable program code for providing a website, which is adapted for automatically monitoring events at one or more remote devices and then responding to these events. Computer readable program code is also provided for electronically communicating with the remote devices. Additional program code automatically determines that an event has occurred by periodically initiating a query and listening for a predetermined acknowledgement from each of the remote devices. A lack of receipt of at least one of said predetermined acknowledgements is indicative that an event has occurred. Computer readable program code is further provided for implementing a response routine including the step of transmitting a responsive communication to a designated entity using at least one of a plurality of communication media. Computer readable program code is provided for listening for a reply to the responsive communication in at least one of a plurality of communication media. In addition, computer readable program code is provided for sequentially iterating the steps of transmitting a responsive communication and listening for a reply thereto, for each of a plurality of designated entities until the reply to the responsive communication has been received, wherein receipt of the responsive communication is verified.

The above and other aspects of this invention will be more readily apparent from a reading of the following detailed description of various aspects of the invention taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagrammatic high-level view of an embodiment of a system of the present invention, in an operational environment;

Fig. 2 is a functional block diagrammatic view of an operational scenario of the system of Fig. 1;

Fig. 3 is a view similar to that of Fig. 1, of an alternate embodiment of a system of the present invention;

Fig. 4 is a view similar to that of Fig. 3, of a user capable of being monitored by an embodiment of the present invention; Fig. 5 is a view similar to that of Fig. 2, of various operational scenarios of additional embodiments of the present invention;

Fig. 6 is a block diagrammatic representation of a more detailed embodiment of the system of Fig. 1;

Fig. 7 is a more detailed block diagrammatic view of the system of Fig. 6;

Fig. 8 is a functional block diagrammatic representation on a more detailed scale of a component of Fig. 7;

Fig. 9 is a view similar to that of Fig. 8, of an additional aspect of the present invention;

Fig. 10 is a view similar to that of Fig. 9, of a further aspect of an embodiment of the present invention;

Fig. 11 is a view similar to that of Fig. 9, of the alert handling functionality provided by the TCP/IP Socket Services of Fig. 7;

Fig. 12 is an overview of portions of Fig. 11; and

Figs. 13-25 are website screen displays of various functions of a detailed embodiment of the present invention.

DETAILED DESCRIPTION

Referring to the figures set forth in the accompanying Drawings, the illustrative embodiments of the present invention will be described in detail hereinbelow. For clarity of exposition, like features shown in the accompanying Drawings shall be indicated with like reference numerals and similar features as shown in alternate embodiments in the Drawings shall be indicated with similar reference numerals. As used herein, the terms 'user' and 'client' interchangeably refer to entities such as businesses and other organizations or individuals, having devices or sites monitored by the present invention. The terms 'device' and

'site' 22 interchangeably refer to individual monitored objects, including electronic, electro-mechanical, or software implemented components such as network devices

(e.g., computers, servers, routers), systems, websites, facsimile machines, webcams, alarm systems, etc., as set forth in greater detail herein. The term 'remote' refers to any device or site 22 communicably coupled to the monitoring site/website of the present invention by an interactive network such as the Internet (e.g., World Wide Web), and/or unified messaging, as defined herein. The term 'computer' refers to any device incorporating a microprocessor (processor) , including stand-alone general purpose machines commonly known as PCs or workstations, and embedded devices. The term 'embedded' device refers to a device having a processor within it and in some cases limited user I/O (input and/or output) , but lacking a complex user interface such as a large display and full keyboard typically associated with PCs. Examples of embedded devices include web enabled cell phones, webcams, etc. As used herein, the term 'unified messaging' includes any communication media (including format) available now or hereafter including the Internet (email, HTTP, HTTPS, FTP, voice over IP, etc.), wireless web, POTS (Plain Old Telephone Service) , wireless telephone (cellular, PCS

(Personal Communications Service) including messaging, etc.), satellite, Cable (CATV) , DSL (Digital Subscriber Line) Internet telephone, paging (1-way and 2-way including short message service) , local/private computer network (LAN, WAN), private radio, home networking (over standard Ethernet, power lines, phone lines or short-range radio) , and voice response systems (automated voice recognition and generation which may use any type of phone connection) , or combination thereof. The term 'database', as u-sed herein, refers to any type of data store, including both application-specific storage structures and conventional databases, such as implemented using conventional database programs such as DB2™ available from Microsoft Corporation

(Redmond Washington) or Oracle Corporation (Redwood City, California) .

Briefly described, the system and method according to the principles of the present invention includes a self-service Web application (e.g., website) in which a customer (e.g., user) is able to purchase monitoring services delivered over the web. The customer is able to subsequently log onto the website and change purchased services by reducing the services, increasing them, changing respondents, and/or changing data or other instructions related to the services desired. The system stores and tracks all service changes.

The monitoring services provided by the system 20 of the present invention include monitoring for event (s) such as a failed web server, automatically notifying a respondent (s) of the event (s), and completing the scenario (e.g., closing the loop) by verifying that the notification was received by the respondent and preferably that the respondent commits to respond. The skilled artisan will recognize that the respondent may include an individual and/or a machine or tool controlled by the individual. The system 20 provides automatic escalation by notifying additional respondents as necessary until receipt and/or commitment is verified. The invention also preferably includes supporting infrastructure to maintain and/or analyze event history, and to preserve this information for dissemination to users. In an alternate embodiment, optional per-event modifications of those actions may be provided.

The present invention thus provides an automated, cost- efficient service that is user controllable, flexible, and scalable. Human involvement is optional. In addition, system 20 also advantageously acts as a disinterested third party, i.e., a "witness" to events, for insurance, legal, and law enforcement purposes, any of which could be informed of an event either in real time or at any time subsequent thereto.

The present invention thus advantageously provides monitoring services over the Internet, with automatic verified response and/or commitment, automatic escalation procedures, and detailed record keeping.

Referring now to Figures, the system and method of the present invention will be more thoroughly described.

Turning now to Fig. 1, in one generalized embodiment, system 20 includes a website (implemented in one or multiple locations and/or computers) that is communicably coupled by one or more communication channels (e.g., unified messaging) 24 to one or more user sites 22 and to one or more respondents 26. On a regularly (or irregularly) scheduled basis, system 20 may examine the entity's devices, including communication infrastructure, such as its internet presence (e.g., website(s)). When a problem (i.e., event) is detected, system 20 preferably uses unified messaging 24 to notify a responsible respondent 26. System 20 holds any event in an unresolved state until the respondent 26 acknowledges the notification and, preferably, commits to respond, thus "closing the loop" to ensure follow-up.

In additional embodiments, substantially any other element of a user' s communication infrastructure may also be examined, including telephone systems, email servers, fax machines, networks, and webcams. Moreover, additional equipment, such as alarm systems, personnel access systems, and even activity at particular workstations (i.e., to monitor employee presence) may be examined. For example, system 20 may monitor the availability of the client's Internet presence by periodically attempting to access the user's website. The validity of URL (Uniform Resource Locator) links within each of the web pages, and content of these pages (e.g., pricing information) may also be monitored. The ability of the user's email server to send, receive, forward, and/or autoreply to email may also be checked. In additional embodiments, ability of the client's PBX to answer the phone, transfer calls, take, forward, and delete voice mail may also be verified. System 20 may check availability of the company' s facsimile machines to answer the phone, present its station ID, and check quality of the phone line. Additionally, site 22 may include multiple discrete devices, such as may be found in a user's network as shown in phantom. In such an embodiment, system 20 may monitor the availability of the company' s network, including network servers 21, routers (not shown), as well as the presence of devices (e.g., PCs) 23 on the network. In addition to checking the operation of webcams, the system 20 may store images captured by a webcam and/or forward them to a respondent 26.

Although the foregoing includes a representative list of devices capable of being monitored by system 20, the skilled artisan should recognize that substantially any electronic, electromechanical, or web-enabled device may be periodically checked for operation by system 20, without departing from the spirit and scope of the present invention.

As additional options, system 20 may provide analyses based on accumulated event data. For example, reliability information for Internet Service Providers (ISPs) may be compiled based upon various user's website availability. This information may be tabulated and displayed as a ranking or a trend analysis available to interested customers as a service.

The collection of the above data for individual clients may also be assimilated into an "electronic profile" for the client that is collected periodically (e.g., daily) and presented to the client's administrator (s) to alert them to any problems. A summary of all events and images (if any) may be sent to each user periodically (e.g., at the end of the month or as requested) . This summary may be conveyed using any convenient media/format such as compact disc (CD) , hardcopy, or by transmission using any communications media/format including unified messaging and/or an electronic network (e.g., Internet), as will be discussed in greater detail below.

The system discussed hereinabove is also preferably self- provisioned, (e.g., the client may register it's device (s) 22 for service) and enter all data needed for operation of the service as will be discussed in greater detail below. Such self-provisioning may be accomplished by the use of screen displays on web pages as discussed in greater detail hereinbelow or by any other unified messaging transport (eg., by phone). The user may self-provision with or without guidance from a conventional automated "wizard" and/or help desk personnel communicating with the user in any convenient manner, such as by telephone or private chat room.

In a still further alternative embodiment, system 20 may act as an application service provider (ASP) for re-sellers and installers of devices (e.g., providers of computers, servers, networks, telecommunications gear, and others). System 20 will enable these re-sellers and installers to conveniently offer the web-based monitoring services of system 20 to their own clients.

System 20 thus includes a generalized approach to event monitoring that is applicable to a wide range of industries using the Internet and/or other suitable communication media/format. Also, "life and limb" (such as traditional fire, intrusion, hold-up, and medical emergency) response capabilities may be provided. For example, conventional fire, burglar, and medical emergency alarm systems may be monitored. In addition, the present invention may be used to monitor emergency signals such as '911' calls from devices (e.g., wireless telephones) equipped with GPS (Global Positioning System) receivers. System 20 may then incorporate the physical location of the device within the event message 32.

System 20 may thus be used to monitor nominally any measurable parameter. Additional examples include monitoring devices commonly associated with the Tank Storage (underground storage tanks) ; Environmental (HVAC) ; Process Control (fieldbus nodes including Ethernet) ; Power (meter reading done via a data network) ; Delivery (FedEx®, etc. using commonly available wireless web microprocessors) ; Vending machine industries; and substantially any application in which an abnormal condition may require intervention. The present invention supports not only the transmission of information but also includes protocols that check on the successful delivery of the message 32 and/or the respondent's 26 commitment to respond, for example, by requesting a return receipt as will be discussed in greater detail hereinbelow.

System 20 also preferably includes provisions, including conventional human interfaces (e.g., keyboard, display) and software provisions, to permit individuals to observe and/or intervene in the automated operation thereof. This aspect advantageously facilitates the provision of user support, such as during provisioning, and/or to provide human judgment during particularly complex or "life and limb" type of event transactions as discussed hereinabove. Respondents 26 may be some combination of computer (s) and people capable of accessing messaging 24.

Turning to Fig. 2, a basic embodiment of the present invention is shown. Three locations are involved in a typical scenario. The monitored device (site) 22 includes an environment 28 being monitored by system 20 for events.

An event at device 22 is signaled by an event message 30.

As used herein, the term 'event message' refers interchangeably to a specific message (e.g., error message) generated by device 22, to a failure of system 20 to receive an expected response (acknowledgement) to a query 31 (e.g. handshake request or ping), and/or to an expected acknowledgement of query 31. System 20 may determine that an 'event' has occurred by either receipt or non-receipt of an event message 30, depending on the type of event message 30. When an event message 30 is detected the system 20 executes a procedure (e.g., script). Among many possible sequences of actions, a typical one is to inform (notify) 32 a respondent 26 of the event, e.g., by email, fax, page, or an automated telephone call. The respondent 26 may then communicate 34 with the system 20 to acknowledge receipt of the notification 32. Communication 34 may include an indication of whether or not the respondent 26 will respond. This communication 34 may be, for example, a return email or entering a code into the keypad of a telephone. As shown in phantom, respondent 26 may then contact 36 the site 22 to effect corrective action.

In an alternative environment shown in phantom, the system 20 may either independently (e.g., in response to script instructions) , or in response to instructions from the respondent 26, send a corrective message 42 directly to device 22 (e.g., instructing an environment controller 38 to issue a re-boot command 40) to effect corrective action. The communication 34 and/or the change in the environment effected by messages 42 and 40 observed by system 20 (e.g., by receipt of an appropriate acknowledgement 30 upon a subsequent query to site 22) as at 43 in Fig. 5a, completes the action-reaction sequence to "close the loop" and complete the event "transaction". System 20 then preferably stores appropriate archive information about the transaction in its database 96 (Fig. 6) . As mentioned hereinabove, the foregoing sequence of actions controlled by the script is preferably implemented as a conventional programmed "transaction", which includes support of programming capabilities typically associated therewith (for example, by implementing the script using JAVA®, available from Sun Microsystems, Inc., of Palo Alto California) . In particular, conventional "rendezvous" functionality may be provided so a multiplicity of actors may each join in controlling a joint decision point.

Many other scenarios are possible. The client may specify choices using a script builder, presented as simple screen displays or web pages as discussed in greater detail hereinbelow. The skilled artisan will recognize that a variety of additional conventional script languages, such as JAVASCRIPT® (Sun Microsystems, Inc., Palo Alto California) , CGI (Common Gateway Interface) , and/or proprietary languages, may be used to specify more complex action-reaction sequences.

Examples of such other operational scenarios are shown in Figs. 5a-5c. For example, in Fig. 5a, system 20 operates substantially as described with respect to Fig. 2, with respondent 26 sending an communication 34' instructing system 20 to correct the problem at the site 22. Site 22 then indicates 43 (e.g., by a sensor or in response to a query) that the problem has been resolved, after which system 20 notifies respondent 26, which subsequently acknowledges 47. Fig. 5b illustrates that one or more steps and/or events may be affected in parallel. As shown, a script associated with a particular event and/or site 22 may involve notifying two or more respondents 26, 26', either serially or in parallel. Turning to Fig. 5c, system 20 may send a message 42 to manage an event prior to notifying 32 a respondent 26. As shown in Fig. 5d, at any time in a transaction, system 20 may interact with third parties, such as police or other authorities 49, an insurance company 51, or other designee 53. Having described system 20, specific aspects of the present invention will be described in greater detail with respect to additional embodiments, referred to herein as systems 20', 20'', etc. Attention is now directed to Fig. 3, which shows an exemplary flow of information and processing of a more detailed embodiment of the present invention shown as system 20'. As shown, a query 31 is sent by system 20', using communication channel 24, to the monitored site 22. Upon receipt of query 31, such as 'ping' or actuation of a hyperlink (e.g., in the event the site 22 is a website or a link therein) or a handshake request (e.g., in the event the site 22 is a facsimile machine) , the site 22 may generate an event message 30 to system 20' . Message 30 similarly uses communication channel 24. If the system 20' fails to receive the message 30 within a predetermined time period, or it receives an incorrect response, then system 20' determines that an event has occurred. For example, as shown, message 30 is received at the system 20' by a transport interface (e.g., modem) 46 and is distributed to a sub process (e.g., event handler) 48, which determines whether an event has occurred. If event handler 48 determines that an event has occurred, then a script associated with the particular event is retrieved from response script database 50. The script includes a prescribed sequence of actions and reactions from event detection to response completion for that particular event. Among other activities, the script may instruct system 20' to forward a notification 32 to at least one respondent 26 using transport interface 54 and unified messaging channel 24. The script preferably includes a "call list" of multiple respondents 26 (as shown in Fig. 1) . The script waits a predetermined period after sending message 32 for a communication 34 (discussed hereinbelow) . If the message 34 is not received during that time period, then system 20' iterates the message sending step to forward a new message 32 to the next respondent 26 in the list. This process continues to iterate until the transaction is closed by a communication 34 and/or commitment. The call list is thus implemented by a computer program, which may be implemented either by a compiled (fixed) program, a fixed program which is interpreted (e.g., a script expressed in an application- specific language) , or a load-on-demand interpreted language such as JAVA®.

As mentioned hereinabove, upon receipt of message 32, a respondent 26 generates a communication 34 that is sent via the unified messaging channel 24 back to the system 20' to provide closed loop verification that a respondent 26 has indeed been notified of the event. Preferably, acknowlegement 34 includes an indication of whether or not the respondent 26 will respond. If no communication 34 is received, or a non-response option is indicated, system 20' iterates the message-sending step to forward a new message 32 to the next respondent 26. Alternatively, or in addition, the present invention may continue to iterate the message-sending step until it receives an appropriate response, to verify that the corrective action was actually taken.

Optionally, as shown in phantom, as events are handled by event handler 48, a real-time, multi-site pattern recognizer 56 may be provided. This pattern recognizer 56 may examine all events within a moving time window from a pre-specified set of a client's sites 22 to identify coincident, or other systematic activity. If such is detected it may be reported 57 as a distinct event to event handler 48, which may then generate a message 32 as described hereinabove. (As used herein, the term 'remote event' shall include distinct events recognized by pattern recognizer 56 of system 20'.) This capability, optionally provided by pattern recognizer 56, may be particularly useful in large client organizations having multiple sites 22 and/or respondents 26. Pattern recognizer 56 thus serves to detect systematic events (e.g., repeated attempts to breach a client's network at multiple locations) that may otherwise be difficult to recognize. (Although shown as separate entities, the communication channels 24 both represent the same uniform messaging infrastructure.)

As also shown, the steps taken by system 20', i.e., the transaction sequences, are preferably saved to an event handling database 58 (which may include any application- specific data stores, databases, or any other store for data) and, thereafter, to an archiving process 60, which may include a long-term data store. An optional data mining process 60 may be used to analyze event history for a particular client to look for profiles of intrusions, behavioral patterns, or other activities relevant to a client's interests. This information may also be stored in the archive 60. A client archiving utility 62 may provide a complete, or subsetted, copy of the client's history of events and other interactions with system 20' by storing the information onto a storage device such as a Compact Disk 64, or by transmitting the client history to the client using communication channel 24.

Turning now to Fig. 4, optionally, rather than or in addition to the periodic queries/polling effected by systems 20, 20' discussed hereinabove, a site 22' may itself identify events and subsequently forward an event message 30' to system 20, 20' . An example of such a site 22' includes a security system or a computer having self diagnostic tools capable of generating an event signal, i.e., in the event of an attempted break into a protected premises or an impending crash of a computer. Upon receipt of event message 30', the system 20, 20' may operate substantially as discussed hereinabove with respect to Fig. 3. In an exemplary embodiment of this feature, environment 28 may include a transducer (e.g., sensor, probe) 80 coupled to a signal receiver 82 that sends data generated by the transducer 80 to an event detector 84. Detector 84 watches for an event 86, such as may be indicated by a distinctive predetermined pattern in the signal data generated by transducer 80. Upon recognizing an event 86, the event detector (e.g., discriminator) 84 constructs an event message 30' suitable for transmission by the transport interface (e.g., modem) 87 over the communication channel 24 to a system 20, 20' as described hereinabove. The skilled artisan will recognize that event detector 84 may be programmed to recognize substantially any predetermined pattern (and/or lack of desired pattern (s)) in the signal data generated by transducer 80.

In addition to a sensor or transducer, probe 80 and/or discriminator 84 may include a hardware and/or software agent that runs on a user's servers and/or computers. Such an agent may provide various functionality. For example, the agent may check the connectivity between two sites 22' by sending/receiving email between the sites. Failure to either send or receive the email may be treated as an event . A desired aspect of all of the aforementioned embodiments of the present invention is reliability and availability (i.e., fault-tolerance) of system 20, 20'. System 20, 20' provides this, in part, through use of conventional store- and-forward functionality. If, for example, an element of system 20, 20' needs to be re-initiated (re-booted), i.e., due to a fault of some sort, the state of any pending transactions will have been stored (and thus saved) . Then, upon restarting, the system 20, 20' will appropriately restart or complete the transaction at the point at which it was disposed immediately prior to the re-boot. The system will also provide an indication that a fault occurred and that the system 20, 20' is now handling the event transaction as part of a failure recovery. The fault is then recorded as an event in its own right. This store- and-forward functionality also advantageously facilitates the handling of transactions that may not complete for extended periods of time, such as in the event respondents are off-line or otherwise temporarily unavailable. The scripts for such events may include timeouts (e.g., time limits) on the amount of time spent waiting for a particular response before proceeding to a default transaction closure, such as notifying authorities. This "store and forward" capability thus allows flexibility at nominally every step of the process to either act immediately or after a delay of some amount of time. Further, the amount of information forwarded may depend on system parameters or requirements of the client.

The skilled artisan will also recognize that system 20, 20' of the present invention may use any suitable encryption technology (e.g., conventional public key/private key encryption) to protect the privacy of messages and to authenticate their integrity.

System 20, 20' is also transport independent and may be used with any suitable presently available or future protocol (s). A "return receipt" may be provided through well-known programming techniques in the event the underlying transport does not provide one.

System 20, 20' may be implemented using any number of commercially available components. Some of these include a WAP (Wireless Application Protocol) server available from NOKIA® Americas Corporation of Irving Texas that allows access to the Internet using wireless technology. A JAVA® Mail API (Application Programming Interface) , which allows any JAVA® program to send and receive email may also be used. Numerous toolkits may be used, such as SOCKETOOLS® by Catalyst Corporation of Newtown Pennsylvania, which provides a library to access the Internet with nominally any standard protocol (sockets, email (POP3 or IMAP4), HTTP/1.1, FTP, NNTP,...) .

A monitor for MS Windows NT®-based LANs for performance, availability, and capacity analysis, such as the NETCLARITY® Suite by LanQuest Corporation of Fremont, California and/or a logging program such as LOGCASTER® by RippleTech Corporation of Washington Crossing, Pennsylvania, that watches MS Windows NT® systems for failures of hardware or system services, monitors the event logs, watches flat files (i.e., files that are not database oriented) and can report by email and paging (e-mail and dial-up) may be used. A monitoring program such as STORCAST® by ASTRUM® Software Corporation of Charlestown, Massachusetts, that monitors MS Windows NT® services, disk space and manner of use, and system performance levels; and standard features built into Windows NT® and Windows 2000® by Microsoft Corporation (Redmond, Washington) , including built-in aids for the diagnosis of problems and the analysis of system activity, may be advantageously utilized. For example, event logs are used to capture messages from both the operating system itself and from user programs. Measurement counters capture information about activities in each arena. In particular, disk and Internet I/O as well as operating system actions such as allocated pages and amount of swapping (i.e., between memory and disc storage) may all be monitored. The present invention may thus be used to collect data from an operating system (e.g., using standard logs found in the WINDOWS NT™ or WINDOWS 2000™ Operating System, conventional private and/or flat file logs) of a remote device 22, conduct an analysis of that data to predict that a system failure is imminent, and then treat the prediction as an event.

The system 20, 20' of the present invention thus provides fully automated messaging and event-response procedures. Additional aspects, such as the website, e-commerce (i.e., the self-provisioning of monitoring services and the payment thereof using the Internet) , information storage and retrieval warehousing, analytical processing, subscription control, and any other special services) are also preferably automated in a manner familiar to those skilled in the art.

The following Table 1 lists various aspects of a client's telephone/fax system that may be selectively monitored by various embodiments of the present invention. Table 1

FEATURE - CATEGORY I

Initiate FAX back

Check Polling

Call Corporate Telephone Number

Check Call Transfer

Leave Voice Mail

Escape Voice Mail Jail

Check voicemail Page Notification

Check for full voicemail (1 or all)

Check for error voicemail on invalid extensions

Busy / no answer forward to live person

Fax - send Fax

The following Table 2 lists various aspects of a client's computer/network system that may be selectively monitored by various embodiments of the present invention.

Table 2

The following Table 3 lists various diagnostic messages and corresponding user message numbers that may be generated by embodiments of the present invention in response to particular event messages 30. Tables 4 and 5 list representative user messages corresponding to the user message numbers of Table 3.

Table 3

Table 4

Table 5

Having described embodiments of the present invention of varying scope, more detailed aspects of the present invention will be discussed, including various optional aspects thereof. Turning to Fig. 6, in a relatively basic embodiment, system 20 primarily communicates with devices/sites 22 and respondents 26 using the Internet component of communications channel 24 (Figs. 1-5). System 20 is coupled to the Internet using a conventional web/email server 90. Server 90 is coupled to Event Handler 48, which, as shown, may include a User Profile Information module 92 and a Scheduler 94. Module 92 is coupled to response script database 50. Scheduler 94 includes a clock, which, in combination with module 92 and database 50, determines when to poll or query a particular site 22 (Figs. 1-4), how to respond to a particular event message 30 (Figs. 3, 5), and/or generate time-out actions as discussed hereinabove. Scheduler 94 is communicably coupled to history database 58 and to Transport module 54.

As shown, transport module 54 preferably includes a Transport Invocation module 97 which may invoke web/e-mail server 90. Optionally, as shown in phantom, transport module 97 may invoke a fax server 98 and/or computer telephony server 100. One or more of such servers 90, 98, and 100 may thus be used to send messages to and from respondent (s) 26 over communications channel 24 (Figs. 3 and 4) as described hereinabove. As also shown, master database 96 preferably includes both response script database 50 and history database 58.

Turning to Fig. 7, in a further embodiment, the present invention may include a system 20' ' , which, in addition components of system 20 discussed hereinabove, preferably includes a reporting module 102. Module 102 serves to generate management and/or historical reports 104, 106, respectively, in various media or formats, such as email, html, pdf, or any other suitable format. Optionally, as shown in phantom, system 20' ' may include a profile management module 108 to enable a client, e.g., by using a browser, to conveniently manage the services provided by the system, such as adding/deleting respondents 26 and/or sites (users) 22 (Figs. 1-3). System 20'' may also include an e-mail provisioning module 110, also shown in phantom, to enable a client to manage his account simply by sending e-mail instructions. As shown, both modules 108 and 110 are communicably coupled to event handler 48 and database 96.

As a further option shown in phantom, transport module 54 may be provided with a computer telephony (CT) engine 111 communicably coupled to invocation module 97, which serves to drive the optional fax, telephone, and email servers 98, 100, and 90, respectively. Optional CT Engine 111 facilitates communication using conventional communication media/formats (e.g., plain-old-telephone-service (POTS) and other web or non-web enabled media) . CT engine 111 will be discussed in greater detail hereinbelow.

Turning now to Fig. 8, operational aspects of system 20'' are discussed in greater detail. As shown, event handler 48 may include an Update module (i.e., PUUpdate) 112, which includes program code written as a JAVA® application, that calls scheduler 94. As shown, scheduler 94 preferably includes three discrete methods, PUScheduler 114, PUFactory 116, and PURequest 118. PUUpdate 112 initially calls PUScheduler 114, which is preferably a conventional 'method' and schedules actions at predetermined intervals based upon users' profile information stored in database 96. PUScheduler 114 generates a discrete thread for each user transaction. For example, these threads effect the polling or 'pinging' of the device (s) 22 as described hereinabove. Each thread generated by PUScheduler 114 calls PUFactory 116 (also a method) , that calls PURequest 118 and then waits for results (e.g., waits for an update flag to be set to a 'normal' state, such as designated by the numeral '1') attained by PURequest 118. PUFactory 116 then updates database 96 (e.g., by replacing a flag field in a status table (described hereinbelow) with a 'normal' state designation of ^λl' ) based on the results of the PURequest 118 query.

PURequest 118 is a method that transmits a request 31 (i.e., a ping or poll) (Fig. 2) to gather information from a particular site 22. The request is transmitted by the invocation module 97 in combination with the web/e-mail server 90 (Fig. 7) as discussed hereinabove. Once the site 22 has acknowledged, e.g., by sending a message 30 (Fig. 2) , PUFactory 116 is notified, such as by setting the update flag to a 'normal' state, such as designated by the numeral '1' . In a preferred embodiment, PURequest 118 effects this transmission/acknowledgment by calling getCTState 130 and/or getlPState 140, which will be discussed hereinbelow with respect to Figs. 9 and 10, respectively. As discussed hereinabove, if message 30 is not received, after a predetermined time period the thread is timed out and the thread treats the non-response as an event, e.g., by generating an alert trigger. Such an event (and alert trigger) is addressed by PUAlertFinder 136, discussed hereinbelow with respect to Fig. 11. Turning now to Fig. 9, invocation module 97 (Fig. 7) may include a GetCTState method 130. As mentioned hereinabove, this method 130 may be called by PURequest 118 to check on the status of devices using optional CT Engine 111. For example, GetCTState 130 may be used to query CTEngine 111 about the state of a user' s telephone system and/or facsimile machine. GetCTState 130 initiates a thread that accesses database 96 for user information and opens a connection to CTServer 132. As shown, CTServer 132 is a server that preferably includes CTEngine 111. The thread sends a message 134 in a suitable media or format/protocol (e.g., TCP/IP) to server 132 with instructions to call (i.e., send a message 31 (Fig. 2)) a user's telephone system and/or fax machine (s). The thread then waits for an acknowledgment message 30 as discussed hereinabove. CTServer 132 receives message 134 on a suitable port (e.g., a socket connection) and sends appropriate call instructions to CTEngine 111 which in turn, initiates an appropriate call using servers 98 and/or 100 (Fig. 7). CTEngine 111 will wait for an expected acknowledgement 30 (Fig. 2) and if not received within a predetermined time period, will signal that an event has occurred, as discussed hereinabove, such as by generating an alert trigger. Such an alert trigger may be addressed by PUAlertFinder 136, discussed hereinbelow with respect to Fig. 11.

Turning now to Fig. 10, invocation module 97 (Fig. 7) preferably includes a GetlPState method 140 which operates in a manner that is conceptually similar to that of GetCTState 130, while using web/e-mail server 90. As mentioned hereinabove, this method 140 may be called by PURequest 118 to check on the status of a web-enabled site 22 (e.g., TCP/IP enabled device). For example, GetlPState 140 may be used to initiate a thread that accesses database 96 for user information and call GETIPStatefor Service method 142. This method 142 initiates a query 31 in a suitable Internet protocol (e.g., TCP/IP) using web/e-mail server 90. The thread then waits for an acknowledgment (event message) 30 as discussed hereinabove. If an expected acknowledgement 30 (Fig. 2) is not received within a predetermined time period, event handler 48 will signal that an event has occurred, as discussed hereinabove, such as by generating an alert trigger. In a preferred embodiment, such alert triggers may be addressed by PUAlertFinder 136, discussed hereinbelow with respect to Fig. 11.

Referring now to Fig. 11, in a preferred embodiment, PUUpdate 112 periodically calls PUAlertFinder method 136, which looks for any alert triggers generated by getlPState 140 and/or getCTState 130 as discussed hereinabove. If any alert triggers are found, then PUAlertFactory method 144 is called (i.e., a new thread is generated). This method 144 serves to access database 96 (Fig. 8) and update the device's flag in the aforementioned status table, e.g., from 'normal' designation of '1' to an 'alert' designation of '2' . Method 144 then calls PUAlertHandler method 146 and then waits a predetermined amount of time for the device's flag to be returned to the normal (e.g., '1') state. While waiting, PUAlertHandler 146 sends a suitable message 148 to CTServer 132, which in turn, generates an instruction to CTEngine 111 and/or to web/e-mail server 90 (Fig. 10) to send a message 32 (Fig. 2) to a respondent 26 (Fig. 2) . If a reply message 34 (Fig. 5) is not received within a predetermined period of time, then PUAlertHandler 146 reiterates the above message 32 for the next respondent 26 (Fig. 1) on the user's 'call list' profile. A reply message 34 (Fig. 5) or report 43 (Fig. 5) or a suitable event message 30 will serve to change the aforementioned device flag to a normal ('1') state, which signals PUAlertHandler 146 to close the transaction thread. Once the device flag has been returned to a normal ('1') state, all previously notified respondent (s) are preferably re- notified of both the event and the return to normal state.

Such re-notification may be accomplished either with or without the aforementioned closed loop verification.

Turning now to Fig. 12, a more detailed embodiment of the CTServer 132 is shown. As shown, CTEngine 111 may include a communications server (CS) 150 coupled to a mail server (MS) 152, which in combination, serve to distribute operational messages to a system failure messaging server (SFMS) 154, a system management console (SMC) 156, a debug and operations logging server (DOLS) 158, and CT queue server (CTQS) 160. Servers 154, 156, and 158 operate in a substantially conventional manner, to provide messages of system malfunctions, an interface for system management, and debugging and logging functions, respectively. CT queue server (CTQS) 160 functions as a conventional queue or buffer for messages 32 to be sent to a Centrex resource server (CRS) 162, to a paging messaging server (PMS) 164, the fax messaging server (FMS) 98, voice messaging server (VMS) 100, or email server.

As shown, in this embodiment, CTServer 132 preferably acts as if it were developed using a free-threading development language. This design model compensates for the lack of free-threading resources in the current version of Microsoft® Visual Basic™ 6.0 Enterprise Level™. The skilled artisan will recognize that this architecture may be modified based on system metrics and the release of Microsoft Visual Basic 7.0™, which is expected to have enhanced threading capability.

Described in greater detail, a primary purpose of the CS 150 is to receive communications from CMS 133 and deliver those messages to the MS 152. Further, the CS 150 transports messages from the MS 152 back to the CMS 133 as status reports on requested computer telephony services initiated at the CMS 133 level. These status reports reflect the progress of services in progress, such as whether a call has been connected, a fax has been sent, or a pager has been notified. The CS 150 communicates with the CMS 133 on a regular interval (e.g., of ten (10) seconds) to refresh the CMS 133 regarding the operability of the CTServer 132. A primary responsibility of MS 152 is to direct packet traffic to particular servers. The reason for the use of a separate mail server in handling traffic management is that as the system is scaled, some form of server will need to determine where a particular message directive from the CMS 133 is actually being executed. As messages arrive at the MS 152, it must decipher what type of action message it is.

For example, the CMS 133 may be requesting that the CTServer 132 send a fax to a client, or test a fax machine, or call a person to tell him there is something wrong with a fax machine. Alternatively, the action message may be requesting that the CTServer 132 test a telephone number or pager for proper operation. As discussed hereinabove, there are many types of potential action messages.

The CRS 162 is a process that actively monitors all ports (i.e., telephone line resources) to determine whether they are available or inoperative. When lines are inoperative, the CRS 162 is programmatically designed to inform the SFMS 154 that a line is not operating correctly. There are typically a limited number of telephone lines to process all voice, data, and facsimile calls in the environments. Advantageously, since all reservation requests for such shared telephone lines may be made through the CRS 162, the resources, and any line troubles that occur throughout the environments, may be centrally managed. Thus, a central function of the CRS 162 is telephone line resource management and malfunction reporting.

Messages that are relayed to the CTQS 160 from the MS 152 inform the CTServer 132 that it must complete some action related to voice, pager, facsimile, or other communications . Once CTQS 160 has received an action message from the MS 152 that a call must take place, it requests a line resource from the CRS 162. If a line is available, the CRS 162 informs the reserving party of where that physical and logical resource is located. When the CTQS 160 receives this "go-ahead" message, it then, in turn, notifies another process to make the call and use the line resource provided to it by the CRS 162. If the CRS 162 does not have any line resource available, it will tell the CTQS 160 through the MS 152 that it is busy. It is the responsibility of the CTQS 160 to keep in queue the action message until the CRS 162 has a line resource available. Once the CRS 162 has a resource available, its situation is broadcast to the CTQS 160.

The scope of the CTQS 160 functional behavior is increased beyond mere resource delivery, contrasted with the CRS 162 whose job is resource allocation, because CTQS also acts as a system-wide fault tolerance system check. This means that to ensure all of the independent servers are operational, the SFMS 154 sends out a system-wide broadcast for all processes to send back some form of an acknowledgement that they "heard" the broadcast. To ensure that the SFMS 154 is operating correctly (since if it were not operational it could not listen for replies to the broadcast) , and since the CTQS 160 listens for the broadcast as well as all of the other processes running, if it does not hear this broadcast within a predetermined (e.g., ten (10) second) time period it must assume the SFMS 154 is not executing any longer. This is different than checking to see whether the SFMS 154 is merely running as a process in Windows™. This method ensures that the SFMS 154 is not only running as a process, but is responding to its logic. If the SFMS 154 should fail, then control of minimal system failure reporting becomes the responsibility of the MS 152.

If system failures do occur, such as lines that are not available for a long period of time, or a particular process is no longer functioning, then SFMS 154 notifies both the CMS 133 and a system administrator through some telephony resource that the engine 111 is not working as designed. The SFMS 154 is capable of seizing a resource to make that alert call, and if the MS 152, CS 150, and Operating System (OS) of CTServer 132 are working correctly, then SFMS 154 will also attempt to notify the CMS 133 of the system failure.

SMC 156 is the server that handles specialized, customer- specific recording needs. This server's role is to provide a browser-based console that displays action items (as opposed to action messages) requiring recordings be made. These recordings are used in the delivery of consumer- friendly telephony messages. This server 156 simplifies the process of making the numerous recordings that each customer (client) may require.

The VMS 100, PMS 164, and FMS 98 are preferably object instances with logic that will operate with voice, pager, or facsimile data. Although these object instances are depicted discretely for clarification, they are preferably implemented generically, i.e., using a single object type capable of handling any type of messaging described hereinabove. These servers are implemented with resources reserved by the CTQS 160 and allocated by the CRS 162. Once these processes completes their own logic, such as making a telephone call and delivering a message, the process expires and the resources are returned to the system.

Summarized descriptions of the aforementioned servers included in CTServer 132 are set forth in Tables 6 to 12 found in Appendix A hereof.

Several of the aforementioned messages, i.e., messages 134 and 148 are described as using TCP/IP protocols. The skilled artisan will recognize that use of such protocols advantageously facilitates scalability to large numbers of devices/threads, while also providing compatibility with Internet messaging. The skilled artisan will also recognize, however, that any other protocols may be used without departing from the spirit and scope of the present invention.

Database 96 may be organized as a series of interconnected tables used to store client profile information, logging, and history data. Examples of these database tables are set forth in Appendix B hereof. These tables are preferably linked together using numeric key codes to reduce record size.

Having described the structure and operation of the present invention, exemplary screen displays accessible by a client on a website of the present invention are shown and described. Advantageously, these screen displays serve as a graphical user interface (GUI) to enable the client to access and self provision (e.g., register and provide profile information to) system 20, 20', 20'', etc.

Turning now to Fig. 13, welcome page 200 provides various features well-known to those skilled in the art, such as language selection 202, and a menu bar 204 for selecting various functions such as registering 206, accessing a site map 208, contacting the proprietor of the system 210, and help 212. Registered users may log in 212, and indicate which, of a variety of devices, they would like to set up for monitoring by the system 20, 20', etc. information 206, etc. Actuating the register button 206 displays registration screen 216 of Fig. 14.

As shown in Fig. 14, screen 216 may provide several selectable options, including setting up/managing accounts 218, profile 220 for entering accounting and billing information, and various optional functions such as a client's personal homepage 222, client's personal e-mail 224, and other functionality such as business sales prospects 226 for the client. These optional functions may be used to enable system 20, 20', 20'' to function as an application service provider (ASP) enabling clients such as equipment installers to offer the monitoring services of the present invention to their own customers. Actuating setting up button 218 opens screen 228 of Fig. 15. Turning to Fig. 15, screen 228 enables a client to enter information and observe the status 230 of various monitored devices (sites) 22, e.g., by use of a color coded display 232. These devices may be at the same or distinct locations, and may be owned by one or more discrete entities. As shown, each site 22 may be a customer of the client .

New account set up screen 236 is shown in Fig. 16. This screen 236 enables a client to enter information such as the type of service 238 (e.g., computer server/network, video) device description 240 (e.g., Internet connection, webcam) message 242 to be sent, such as "Connection On", "Motion Detected"), and device location 244. Billing information 246 and call list (contact information) 248 (i.e., list of respondents 26) is entered on profile screen 250 in Fig. 17.

A client event history screen 252 is shown in Fig. 18, which enables a client to access various aspects of devices (sites) 22, including transaction (event notification) progress in real time.

Turning now to Fig. 19, a client may access its electronic profile screen 254, which may provide a color-coded status 232 profile of each of various devices (sites) being monitored by the present invention. Examples of the types of devices monitored, and displayed by screen 254 include corporate PBXs 256, Fax machines 258, email servers 260, Exchange Servers 262, Lotus® Notes™ servers 264, Web sites 266, video cameras 268, LANs/WANs 270, other servers 272, security systems 274, fire alarm systems 276, Environmental controls 278, and presence/absence of personnel 280. A client may drill down by actuating (e.g., clicking) any of the icons for 256-280 to obtain more detailed information. For example, actuating corporate PBX 256 will display PBX screen 282. This screen 282 may include additional information, preferably including color-coded status indicators 232, for various additional parameters. This information may include whether telephones were answered 284, voicemail accepted 286, valid extension accepted 288, invalid extension rejected 290, voicemail forwarding accepted 292, message deletion operational 294, and message archival operational 294.

Similarly, actuating web sites 266 will display web site screen 298 with a graphical color-coded display for various optional features. As shown, such features may include determining that the main web page is present 300, secure socket layer is operational 302, all links are operational 304, attempted break-ins failed 306, whether web page changed since previous test 308, links changed since previous test 310, e-commerce status (e.g., pricing spot checked, credit card server operational, etc.) 312.

As shown in Fig. 22, e-mail screen 314 may indicate whether auto response is functional 316, incoming email is accepted 318, outgoing email is sent 320, email filters are operational 322, and junk mail (i.e., spam) filters are operational 324.

Fax machine screen 326, as shown in Fig. 23, may verify that the machine answered 328, fax was accepted 330, station identifier was operational 332, junk fax functions were operational 334, polling was operational 336, delayed send function operated 338, transmission speed was acceptable 340, fax on demand functioned 342, and connect speed was within parameters 344.

Personnel screen 346, when personnel access control systems and/or LANs are registered as users of system 20, 20', 20'', may graphically indicate whether employees are absent/not logged in 348, have designated levels of attendance over- a predetermined time period 350, have used all available sick time 352, or have attempted an unauthorized entry 354.

Video camera screen 356 is shown in Fig. 25. This screen may indicate whether a camera is operational 358, whether motion was sensed 360, that the video was captured and archived 362, and may show the video archive 364.

The foregoing description is intended primarily for purposes of illustration. Although the invention has been shown and described with respect to an exemplary embodiment thereof, it should be understood by those skilled in the art that the foregoing and various other changes, omissions, and additions in the form and detail thereof may be made therein without departing from the spirit and scope of the invention.

Having thus described the invention, what is claimed is:

APPENDIX A

Table 6

Server Name : 'Communications Server" ALIAS "CS'

Scope of Services: The CS is an application that listens for messages on a port opened for communications and talks to the JAVA®-based Core Messaging Server ALIAS "CMS". The messages received are sent to the "Mail Server" ALIAS "MS" as a package for further delivery and processing by other processes that handle the servicing of CT requests or of new account management (such as creating audio recordings) . Messages received from the MS are sent back to the CMS to indicate the status of former requests to the CT Engine System ALIAS "CTES".

Listen to incoming messages from the CMS and send to MS as a discrete message package.

Listen to incoming packages from the MS and send to the CMS as a bitstream.

Send an acknowledgement to the CMS every ten (101 seconds on reception of request.

Listen for a broadcast from the CMS every ten (101 seconds for an acknowledgement. If a broadcast request has not come in within that time period, treat as CMS failure.

The ability to close and restart communications ports by request of the "System Failure Messaging

Table 7

Server Name: "Mail Server" ALIAS "MS"

Scope of Services: The purpose of the MS is to receive incoming message packages from many different sources.

The MS reads the package type and forwards it to the appropriate process server on the correct domain & machine. This is needed when scalable hardware architecture is required to produce adequate load- balancing requirements.

Creation of communications channels to all client process servers.

Monitoring of the channels and redirecting mail packages to the appropriate domain / machine / process server for the event identification number

(EIN) that the package is related to and for other purposes that are not EIN specific.

Table 8

Server Name: 'System Management Console" ALIAS "SMC"

Scope of Services: The SMC is responsible for handling requests from the MS that originate from the CMS regarding information that the CTES needs to have completed before the end-user account can be established.

This information is primarily data, such as audio recordings that detail the name of the company system 20, Inc. is protecting or the recorded names of the individuals system 20, Inc. will be contacting in the event of an alert message.

The SMC is the web-based document that runs in MSIE 5.0 or greater that permits the system 20, Inc. system administrator to perform various administrative tasks related to the set-up of new accounts and the overall management of the CTES. Future embodiments may remove the need for the SMC interface for audio recording since new account data may be "spoken" to end-users through the use of a text-to-speech engine. The SMC however, may still be needed to control the overall maintenance operations of the CTES and the system 20 Operating System (comprised of both the CMS and the CTES) such as providing a visual interface to the system administrator to issue commands to the CTES for shutdown, restart, obtaining metrics, supervision of current processes, CTES requests, & threads.

Receive & send message packages from/to the MS

Display system metrics such as throughput, latency, service provider delay; machine specific data; software processes & threads; and, event/alert task data. Permit the initiation of system or server shutdown and restart requests across domains and machines.

Permit the recording of .WAV files and data entry for new customer data items .

Interface to other machine specific controls or properties as needed.

Table 9

Server Name: CT Queue Server" ALIAS "CTQS'

Scope of Services: The CTQS is the central storage queue for incoming CT service requests from the MS.

As any service request is received from the MS, the CTQS simply puts the message in queue to be acted upon by the individual CT service providers .

These servers are named "Paging Messaging Server" ALIAS "PMS", "Fax Messaging Server" ALIAS "FMS", and the "Voice Messaging Server" ALIAS "VMS", and "email messaging server" ALIAS "EMS."

Receive message packages from the MS related to providing a CT service provider to complete some messaging action.

Maintain a queue of active and pending CT service requests .

Query itself as to the intraprocess status of a CT service provider.

Communicate a message package to the MS for forwarding to the CS on queries the CMS has performed.

Communicate a message pac kage to the MS for forwarding to the CS on a stepped or incremental basis on the intraprocess status of a CT service provider automatically wi thout the need for an originating CMS query.

Table 10

Server Name: 'Centrex Resource Server" ALIAS "CRS"

Scope of Services: The CRS is the central allocation manager of shared resources, namely the Centrex telephone lines within the company.

As calls need to be made on the system 20 Operating System, the CRS receives requests from the CTQS to reserve a telephone line resource for a call that needs to be placed or received. The CRS then reserves the line for sole use of the CTQS for a specified period.

Once the CTQS has created a new job that uses the line the CRS reserved and the job completes, the CRS is notified that the line is free.

Monitor all Centrex lines to ensure operatability

Report all Centrex line failures to the SFMS

Reserve a line resource for a specified time as requests are made from the CTQS and report the line reservation number to the CTQS.

Clear lines where the allotted reservation time has expired.

Clear lines when the CTQS informs it that a resource is no longer needed.

Table 11

Server Name: "Debug Operations Logging Server"

ALIAS "DOLS"

Scope of Services: The DOLS is responsible for logging all metric and debug information to a central file from the different processes executing. All processes report the status of their execution threads through DOLS and enc [ here as well. Report requests are also handled through DOLS via the MS.

Log all messages that come in through MS to centralized log file.

Table 12

Process report requests via MS on historical data about a call, line use, or any other discrete field in the log file.

Server Name: 'System Failure Messaging Server' ALIAS "SFMS'

Scope of Services: The SFMS is the task that manages notification of the CMS and the System Administrator through its own resource management if there is a failure in any component of the CTES or the CMS. How the SFMS notifies the System Administrator is dependent on which part of the WOS has failed.

It is also the process that is responsible for broadcasting a signal every ten (10) seconds to all of the other CTES tasks executing and listening for their response. In the event that two consecutive broadcasts are not acknowledged by a particular component (s) , the SFMS sends out a failure message to the CMS (if communications channels are open) , to the System Administrator via the PMS (if telephone lines are available) and to the system console (via the SMC) .

Broadcast "Are you there?" signals every ten (10) seconds .

Listen for broadcast acknowledgements

Report failures to the appropriate processes if failure

Server Name: "Paging, Faxing, Voice and email Messaging Servers" ALIAS "PMS", "FMS", "VMS", "EMS"

Scope of Services: The PMS, FMS, VMS & EMS are spawned threads that actually execute the requested CT services from the CTQS. They notify the intended recipient of a particular type of message. The PMS handles paging services, the

FMS handles faxing services, the VMS handles voice-messaging services, and the EMS handles email services. The PMS, FMS, VMS & EMS further notifies the CTQS of it call progress status during the process.

Execute predefined logic on the transport path resource given to it Report progress throughout the task to the CTQS and DOLS.

APPENDIX B

CLIENT PROFILE INFORMATION

Description: Information about the system 20 Client Account .

Table: T_PROFI E Type: Data Table One record

Table. T_DEVICE_TYPE Type: Data Table

Wield Name Type Description

Devιce_Name_Code int 0,1,2,3

Devιce_Name varchar (32)

'PAGER' , ' PHONE' , ' AX' , ' PALMPIV Table: T_EQUIPMENT_TYPE Type: Data Table

Field Name Type Description

Equipment_Code int

0,1,2,3,4 Equipment_Name varchar (32) ATT', ETC

2. Client Services Profile Table

Description: This table holds information about the services (devices) that the client wants to monitor.

*** DEFINES WHAT SERVICE WE ARE TESTING ***

Table : T_SERVICES

Type: Data Table

Table : T SERVICES CONTACT LIST

Description : All Respondents for this service (device) . Defines a specific device/equipment that maybe contacted using CTServer 132 and/or web/e-mail server 90 . Type : Data Table One to Many

Field Name Tvpe Description

Account id char (5) link to t service table

Contact id char unique identifier

Contact Name varchar (128) Company or

Organization Name Contact Phone char

Contact email char

Contact Device Type code char Lookup -> t_ device type table

Contact Equipment code char Lookup -> t equipment_type table Voice Resource File Name varchar2 (255)

Voice Resource File Name Index int

SERVICE Type Table

Table : LU_SERVICE_TYPE

Type : Lookup Table

Description : Information about services that are available

1-100 Socket Services ( i . e . , web-enabled devices )

101-200 - CT Functions ( i . e . , non web-enabled, telephony devices)

Example :

0, ' TCP/IP' , ' Socket Service-HTTP' , 80 1, 'TCP/IP' , ' Socket Service-HTTPS' , 336.

101, 'CT' , ' PHONE' ,0 102, 'CT' , 'FAX' ,0

Field Name Type Description

Service_Code int Service_Type int Description char Socket Port int FREQUENCY Table

Table: LU_FREQUENCY

Type: Lookup table

Description: Information about services that are available

Example :

Code, Description Field Name Type Description

Frequency_Code int

0, '15 Minute Interval' Description char

1, ^Λl Hour Interval'

2, ' 12 Hour Internal'

LEVEL of Service Table

Table: LU_LEVEL_OF_SERVICE

Type: Lookup table

Description: Information about services that are available

Example:

Field Name Type Description

0 - basic code int

1 - silver Description char

2 - gold

3. PROVISIONING HISTORICAL TABLE

Description: Historical Information about services. This table has events taking place in the lifecycle of system 20, 20', etc. processing including debug information so that all events can be tracked. Transactions (events) are logged at various steps of processing .

Event_id = character field composed of date time+client id+service code

Field Name Type Description

Account id char (5)

Service id char

Event id char

Event Service Code int

Event Date Time char

Delay int

Event Message char

Table: T_PROV_2DTE

Type: Data Table

Example1: SERVICE Lifecycle - Checking Phone using CT ENGINE Client id event id

^ΛABC123', 120100-12:00-CODE1' ,0 , 05/05/00, 24 : 01, 0, 'EVENT : Beginning Checking status of PHONE -123-1234' λABC123', 120100-12:00-CODE1',0 ,05/05/00,24:01,0, 'EVENT: Contacting CT Engine'

^ΛABC123', 120100-12:00-CODE1' ,0 ,05/05/00,24:01,0, 'EVENT: CT ENGINE Response - OK'

^,ABC123', 120100-12:00-CODE1' ,0 ,05/05/00,24:01,0, 'EVENT: Processing Complete'

Example2: SERVICE Lifecycle - RED Alert Event - call Phone number defined in client profile λABC123', 120100-12:00-CODE1' ,0 ,05/05/00 24 :01,0, ' EVENT : RED ALERT EVENT- PHONE -123-1234'

λABC123', 120100-12:00-CODE1' ,0 ,05/05/00, 24 01,0, ' EVENT : Contacting CT Engine'

ΑBC123', 120100-12:00-CODE1' ,0 ,05/05/00, 24 01,0, ' EVENT : CT ENGINE Response - OK' λABC123', 120100-12:00-CODE1' ,0 ,05/05/00, 24 01,0, ' EVENT : Processing Complete'

PU Status table

Description : Provides a method of determining if a PU request has been complete .

Table : T_PU_STATUS

Type : Data Table

Set to 0 if not complete Update_flag = 1 i f complete

Field Name Type Description

Account_id char (5) Identifier int Update_flagl int Update_flag2 int

Example :

0, 'TCP/IP' , 'Socket Service- HTTP' , 80 1, 'TCP/IP',' Socket Service-HTTPS' , 336.

101, 'CT' , 'PHONE' ,0

102, ^λCT' , 'FAX' ,0

FREQUENCY Table Table : LU_FREQUENCY

Type : Lookup Table

Description : Information about services that are available

Wield Name Type Description

Frequency_Code int Description char Example :

Code, Description

0, 15 Minute Interval'

1, ^vl Hour Interval'

2, '12 Hour Interval'

LEVEL of Service Table

Table : LU_LEVEL_OF_SERVICE

Type: Lookup table

Description: Information about service that are available

Example : 0-basic 1-silver 2-gold

Claims

1. A computer implemented method in an interactive medium for automatically monitoring events at at least one remote device and responding to the events, said method comprising the steps of:

(a) providing a monitoring website implemented in one or more computers, the monitoring website adapted for communication with at least one remote device;

(b) automatically determining that an event has occurred at the remote device;

(c) recording the event automatically;

(d) automatically implementing a response routine including transmitting a responsive communication to at least one designated entity using at least one of a plurality of communication media;

(e) automatically verifying receipt of the responsive communication by the at least one designated entity; and

(f) enabling the monitoring website to be self- provisioned by at least one remote user.

2. The method of claim 1, wherein said automatically verifying step (e) further comprises obtaining a commitment by the at least one designated entity to take appropriate corrective action.

3. The method of claim 2, further comprising the step of (g) upon completion of step (e) , automatically confirming that the corrective action has been completed.

4. The method of claim 3, further comprising the step of (h) upon completion of said step (g) , automatically notifying the at least one designated entity that the corrective action has been completed.

5. The method of claim 1, wherein said enabling step (f) comprises enabling the remote user to select the remote device and the designated entity.

6. The method of claim 1, wherein said implementing a response routine step (d) and said automatically verifying step (e) comprise a closed-loop responsive communication.

7. The method of claim 1, wherein said recording step (c) comprises recording the time and date of the occurrence of the event.

8. The method of claim 1, wherein the monitoring website is adapted for communication with a plurality of remote devices and said method further comprises the step of (f) iterating said steps (a) to (c) for each of the plurality of remote devices.

9. The method of claim 8, further comprising the step of iterating said implementing a response routine step (d) and said automatically verifying step (e) for each of the plurality of remote devices.

10. The method of claim 8, further comprising the step of (g) identifying a pattern of events for the plurality of monitored devices.

11. The method of claim 10, further comprising the step of (h) iterating said implementing a response routine step (d) and said automatically verifying step (e) in response to said identifying step (g) .

12. The method of claim 10, further comprising the step of (h) detecting an aberration from the pattern of events.

13. The method of claim 12, further comprising the step of (i) iterating said implementing a response routine step (d) and said automatically verifying step (e) in response to said detecting step (h) .

14. The method of claim 1, wherein said implementing a response routine step (d) further comprises transmitting the responsive communication simultaneously using a plurality of communication media.

15. The method of claim 14, wherein each one of the plurality of communication media is selected from the group consisting of voice, facsimile transmission, electronic mail, video, and a combination thereof.

16. The method of claim 1, wherein said implementing a response routine step (d) further comprises transmitting the responsive communication by universal messaging.

17. The method of claim 1, wherein said automatically verifying step (e) comprises receiving a reply to the responsive communication over at least one of a plurality of communication media.

18. The method of claim 17, further comprising the step of automatically escalating the response routine for a plurality of designated entities.

19. The method of claim 18, wherein said step of automatically escalating the response routine comprises sequentially iterating said implementing step (d) for each of a plurality of designated entities until said automatically verifying step (e) has been completed.

20. The method of claim 19, wherein one of said plurality of designated entities is a designee of the operator of the monitoring website.

21. The method of claim 17, wherein each one of the plurality of communication media is selected from the group consisting of facsimile transmission, electronic mail, Internet, wireless web, POTS, wireless telephone, PCS, satellite, CATV, DSL, Internet telephone, paging, local/private network, radio, and a combination thereof.

22. The method of claim 1, wherein said implementing a response routine step (d) and said automatically verifying step (e) are each effected in at least one of a plurality of communication media.

23. The method of claim 22, wherein each one of the plurality of communication media is selected from the group consisting of facsimile transmission, electronic mail, Internet, wireless web, POTS, wireless telephone, PCS, satellite, CATV, DSL, Internet telephone, paging, local/private network, radio, and a combination thereof.

24. The method of claim 1, wherein said determining step (b) further comprises receiving a predetermined signal from the remote device.

25. The method of claim 1, wherein said determining step (b) further comprises failing to receive a predetermined signal from the monitored device.

26. The method of claim 1, wherein said determining step

(b) further comprises the steps of:

(g) periodically initiating a query to the remote device and listening for a predetermined acknowledgment of the query; and

(h) determining that an event has occurred upon failure to receive the predetermined acknowledgment.

27. The method of claim 1, wherein said implementing a response routine step (d) further comprises the step of automatically initiating a corrective action.

28. The method of claim 27, wherein the corrective action comprises shutting down the remote device.

29. The method of claim 27, wherein the corrective action comprises re-booting the remote device.

30. The method of claim 27, wherein said recording step

(c) further comprises digitally recording and archiving: the event of said determining step (b) ; the protective action and responsive communication of said step (d) ; and the verification of said step (e) .

31. The method of claim 1, further comprising the step of implementing said steps (a) through (e) in an automated, integrated system.

32. The method of claim 6, wherein said closed-loop communication is encrypted.

33. The method of claim 32, wherein said closed-loop communication includes an electronic signature.

34. The method of claim 1, wherein the response routine of said implementing a response routine step (d) is customizable for each of the remote devices.

35. The method of claim 34, wherein the response routine is customizable for each of a plurality of discrete types of events.

36. A computer implemented method in an interactive medium for automatically monitoring events within a group of one or more remote devices and responding to the events, said method comprising the steps of:

(a) providing a monitoring website coupled to a communication module for communication with the group of remote devices;

(b) automatically determining that an event has occurred by periodically polling and listening for a predetermined acknowledgement from each of the remote devices in the group, wherein lack of receipt of at least one of said predetermined acknowledgements is indicative that an event has occurred within the group of remote devices;

(c) implementing a response routine including the step of transmitting a responsive communication to at least one designated entity using at least one of a plurality of communication media; (e) automatically attempting to verify receipt of the responsive communication by the designated entity by listening for a reply to the responsive communication in at least one of a plurality of communication media;

(f) sequentially iterating said implementing step (d) and said automatically attempting step (e) for each of a plurality of designated entities until the reply to the responsive communication has been received, wherein receipt of the responsive communication is verified; and

(g) enabling the content of the group to be user- selectable .

37. The method of claim 36, wherein the monitoring website is self-provisionable by individual remote users.

38. The method of claim 37, wherein the self-provisioning comprises enabling the individual remote users to specify the designated entity.

39. The method of claim 36, further comprising the step of recording the event in a database;

40. The method of claim 36, wherein said implementing a response routine step (d) further comprises transmitting the responsive communication simultaneously using a plurality of communication media.

41. The method of claim 40, wherein each one of the plurality of communication media is selected from the group consisting of: voice; facsimile transmission; electronic mail; video; and a combination thereof.

42. The method of claim 36, wherein said implementing a response routine step (d) further comprises transmitting the responsive communication by unified messaging.

43. The method of claim 1, wherein said recording step (c) comprises recording the event in a database.

44. A computer system in an interactive medium for automatically monitoring events within a group of one or more remote devices and responding to the events, said computer system comprising:

(a) a monitoring website, the monitoring website adapted for electronic communication with the group of remote devices;

(b) an event handler adapted to automatically determine that an event has occurred by periodically polling and listening for a predetermined acknowledgement from each of the remote devices in the group, wherein lack of receipt of one of said predetermined acknowledgements is indicative that an event has occurred within the group;

(c) a response routine including a communication module adapted to transmit a responsive communication to at least one designated entity using at least one of a plurality of communication media;

(d) a verification module to automatically attempt to verify receipt of the responsive communication by the designated entity by listening for a reply to the responsive communication in at least one of a plurality of communication media; and

(e) said response routine transmitting the responsive communication and attempting to verify receipt thereof, for each of a plurality of designated entities until the reply to the responsive communication has been received, wherein the receipt of the responsive communication is verified.

45. An article of manufacture for conducting commerce in an interactive environment, said article of manufacture comprising : a computer usable medium having computer usable program code embodied therein, said computer usable medium having:

(a) computer readable program code for providing a website, the website adapted for automatically monitoring events at one or more remote electronic devices and responding to the events;

(b) computer readable program code for electronically communicating with the remote electronic devices;

(c) computer readable program code for automatically determining that an event has occurred by periodically initiating a query and listening for a predetermined acknowledgement from each of the remote electronic devices, wherein lack of receipt of any of said predetermined acknowledgements is indicative that an event has occurred;

(d) computer readable program code for implementing a response routine including the step of transmitting a responsive communication to at least one designated entity using at least one of a plurality of communication media;

(e) computer readable program code for listening for a reply to the responsive communication in at least one of a plurality of communication media; and

(f) computer readable program code for sequentially or in a parallel fashion iterating the steps of transmitting a responsive communication and listening for a reply thereto, for each of a plurality of designated entities until the reply to the responsive communication has been received, wherein receipt of the responsive communication is verified.