WO2003060711A2 - System and method for determining notification behavior of a system - Google Patents

Abstract

Embodiments of the present invention provide a system and method for dynamically controlling the notification behavior of a system. One embodiment of the present invention can include a system for controlling notification behavior of a system comprising a notification program stored on a computer-readable memory. The notification program can be executable by a computer processor to determine a first notification mode based on a set of configuration parameters and a first-system state. The notification program can be further executable to determine if a notification should be sent out based a set of configuration parameters associated with first notification mode and, if a notification should be sent out, communicate the notification over a network. The notification program can also receive an updated configuration parameter associated with the first notification mode and send out a new notification based on the updated configuration parameter.

Description

DESCRIPTION SYSTEM AND METHOD FOR DETERMINING NOTIFICATION BEHAVIOR OF A SYSTEM RELATED INFORMATION This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent

Application No.60/348,692, entitled "Mechanism for Dynamically Determining the Notification Behavior of a Complex System," by de Bonet et al., filed January 15, 2002, United States Provisional Patent Application No. 60/349,424, entitled "Network Proxy Platform that Simultaneously Supports Data Transformation, Storage, and Manipulation for Multiple Protocols" by de Bonet et al., filed on January 18, 2002, United States Provisional Patent Application No. 60/349,344 entitled "Modular Plug-In Transaction Processing Architecture" by de Bonet et al., filed January 18, 2002, which are hereby fully incorporated by reference herein. Additionally, United States Patent Application Serial

No. , entitled "Method and System of Performing Transactions Using Shared Resources and

Different Applications," by de Bonet et al., filed January 14, 2003 is incorporated by reference herein.

REFERENCE TO APPENDIX

An appendix is included in this application by way of attachment, the totality of which is hereby incorporated by reference for all purposes as an integral part of this application. The appendix is entitled "Network Proxy Platform and Its Use" and includes 17 pages of text and 8 sheets of drawings.

TECHNICAL FIELD OF THE INVENTION

Embodiments of the invention relate generally to notification systems. More particularly, embodiments of the present invention relate to systems and methods for determining the notification behavior of a system.

BACKGROUND OF THE INVENTION

Over the past several decades remote monitoring of complex hardware, software and physical systems has become more commonplace. The proliferation of remote monitoring has been facilitated by the increased sophistication and speed of digital communications media. In typical remote monitoring systems, a centralized management server receives notifications regarding the status of various monitored components from software agents installed on those components. Typically, the software agents will send out status notifications at the same frequency and in the same manner regardless of the state of the monitored component. Thus, whether a component is functioning properly or exhibiting an error, the software agent associated with that component will send out notifications at the same frequency. In a large system, this can lead to an overabundance of notifications.

In order to provide a more manageable set of notifications to an operator, many prior art systems employ a network management station ("NMS") at the centralized management server that provides a common human interface for receiving the notifications and allowing the operator to select which notifications to view. The operator can configure the NMS to display only a subset of the notifications received so that the operator does not have to view every notification received by the centralized management server.

While the NMS can reduce the number notifications viewed, the notifications are still sent from the software agents. If the software agents send a large number of notifications, the notifications may require a large amount of bandwidth, saturating and slowing the network conducting the notifications. Moreover, if the operator configures the NMS to display too many notifications, he or she might be conditioned to ignore the alarms. If, on the other hand, the operator configures the NMS to filter out too many of the received notifications, he or she may never see important notifications, again missing alarm conditions.

One example of a common system displaying the inadequacies of prior art notification systems is a computer network employing simple network management protocol ("SNMP") to monitor network components. SNMP was developed in the 1980's as a simple protocol that could be implemented to manage a variety of heterogeneous systems. Originally, SNMP was intended as a stopgap measure until a more robust protocol could be developed. However, the wide adoption of SNMP made it the de facto standard for internetwork management.

SNMP generally works on a server agent architecture with agents capable of using the SNMP protocol installed on each monitored component, in some cases as a portion of the firmware. The agent can send notifications, known as SNMP traps, to advise the centralized management server when one or more conditions at the monitored component has been met. In typical SNMP systems, an SNMP trap is sent every time this set of conditions is met.

In many prior art systems, the software agent will be configured to send out an SNMP trap with the monitored component's status information regardless of whether the component is functioning properly or whether the component is malfunctioning. This can lead to the software agent communicating a large volume of SNMP traps to the centralized management server. The operator, through an NMS, will then determine which SNMP traps to view. If the operator chooses to view a large number of the SNMP traps, he or she may miss alarm conditions due to information overload. Conversely, if the operator sets the NMS to filer too many SNMP traps, the operator may never see an SNMP trap indicating an alarm at a monitored component. To reduce the number of SNMP traps sent, some prior art systems define several levels for notification behavior. Examples of such levels include a level in which all alarm messages, but no other notifications, are sent by the software agents, a level in which all SNMP traps are sent by the software agents, or a midlevel in which both SNMP traps indicating normal operation and alarm conditions are sent by the software agent according to some predefined rule. However, these systems only provide a course control that is typically applied to all the software agents (or SNMP traps of those agents). They do not allow fine control for tuning a particular SNMP trap to send out notifications at, for example, different frequencies or for adjusting the behavior of the particular SNMP trap depending on the status of the component being monitored by the SNMP trap.

SUMMARY OF THE INVENTION Embodiments of the present invention provide a system and method for determining notification behavior of a system that substantially reduces or eliminates the disadvantages associated with previously-developed notification systems and methods. More particularly, embodiments of the present invention provide a system and method for dynamically controlling the notification behavior of a system. One embodiment of the present invention can include a system for controlling notification behavior of a system comprising a notification program stored on a computer-readable memory. The notification program can be executable by a computer processor to determine a first notification mode based on a set of configuration parameters and a first system state. The notification program can be further executable to determine if a notification should be sent out based a set of configuration parameters associated with first notification mode and, if a notification should be sent out, communicate the notification over a network. The notification program can also receive an updated configuration parameter associated with the first notification mode and send out a new notification based on the updated configuration parameter.

In one embodiment of the present invention, the notification program can determine if a notification should be sent out under the first notification mode based on the time the last notification associated with the first notification mode was sent out and a frequency parameter for the notification mode.

In another embodiment of the present invention, the notification program can determine if a notification should be sent out under a notification mode based on the number of previous consecutive notifications that have been sent out for that notification mode. Another embodiment of the present invention can include a method for controlling the notification behavior of a system, including the steps of: (i) determining a first notification mode based on a set of configuration parameters and a first system state; (ii) determining if a notification should be sent out based on the set of configuration parameters and the first notification mode; and (iii) if so, communicating a notification over a network. This embodiment of the present can further comprise: (iv) receiving an updated configuration parameter associated with the first notification mode; (v) determining a new notification mode based on a new system state and the set of configuration parameters; and (vi) if the new notification mode is determined to be the first notification mode, determining if a new notification should be sent out based on the updated set of configuration parameters; and (vii) sending out a new notification.

In one embodiment of the present invention, the step of determining if a notification should be sent out based on a set of configuration parameters and the first notification mode can be based on the time the last notification associated with the first notification mode was sent out and a frequency parameter.

In another embodiment of the present invention, the step of determining if a notification should be sent out under a notification mode can be based on the number of previous consecutive notifications that have been sent under that notification mode.

Embodiments of the present invention provide advantages over prior art notification systems by allowing the notification characteristics of multiple notification modes to be defined. This allows an operator to tune the notification characteristics of embodiments of the present invention to prevent information overload while ensuring that sufficient alarm notifications are received. Embodiments of the present invention provide another advantage over prior art systems and methods of determining notification behavior by allowing configuration parameters associated with various notification modes to be dynamically changed during execution of the remote agent thereby allowing the notification behavior of the system to be dynamically turned.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description, taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:

FIGURE 1 is a diagrammatic representation of a system according to one embodiment of the present invention;

FIGURE 2 is a diagrammatic representation of a set of configuration parameters defining multiple notification modes according to one embodiment of the present invention; and

FIGURE 3 illustrates a flow chart for a method of controlling notification behavior according to one embodiment of the present invention.

DETAILED DESCRIPTION

Preferred embodiments of the present invention are illustrated in the figures, like numerals being used to refer to like and corresponding parts of the various drawings. Embodiments of the present invention provide a system and method to manage the notification behavior of a system. One embodiment of the present invention can define multiple notification modes, each exhibiting different notification behavior, based on the state of a component being monitored. For example, embodiments of the present invention can define notification modes such that notifications that indicate a problem state in a monitored component can be sent out more frequently than notifications that indicate that the monitored component is functioning properly. A number of notification modes can be defined to provide various gradations of notification behavior depending on the state of the monitored component. Moreover, the manner in which a particular notification is sent out can also be controlled. Thus, for example, important notifications can be sent to an operator's pager whereas less important notifications can be sent in some other manner (e.g. email).

FIGURE 1, is a diagrammatical representation of a system 100 in which one embodiment of the present invention can be implemented. System 100 can comprise a management system 110 that can include a management computer processor 112, a management computer readable memory 114 (e.g. RAM, ROM, magnetic storage device, optical storage device, and/or any other computer readable memory known in the art) and a management system network adaptor 116 (e.g. modem, Ethernet card or any other network communication device known in the art). Management System 110 can further include a management program 115 stored on computer-readable memory 114 that is executable by management processor 112. Management program 115 can Teceive and process multiple notifications from various software agents over network 120. Moreover, management program 115 can include an NMS to allow an operator to limit the number of notifications he or she views. Although shown as a single physical unit in FIGURE 1, it should be noted that the functionality of management System 110 can be distributed. In addition to management system 110, system 100 can include multiple monitoring systems

(e.g. monitoring system 130, monitoring system 160 and monitoring system 170). Although only shown for monitoring System 130, each monitoring system can include a computer processor 132 and a computer-readable memory 134 (e.g. RAM, ROM, magnetic storage device, optical storage device, and/or any other computer readable memory known in the art). Moreover, each monitoring system can include a network adaptor device 139 (e.g. Ethernet Card Modem or any other network communications device known in the art). A notification program 140 can reside at computer- readable memory 134. In the embodiment shown in Figure 1, notification program 140 can contain a monitoring portion 145 and a notification portion 150. Monitoring portion 145 can receive data regarding the state of a monitored component, and based on this data, notification portion 140 can send notifications to management system 110 via network 120. In another embodiment, notification program 140 can be separate from the program that determines the system state or can be implemented in any other suitable manner as would be understood by one of ordinary skill in the art (e.g. as a software component of larger software package, a function larger software package, a separate program, a portion of another program). The monitored components can include components of the monitoring system, such as hardware or software components, or may include external components. For example, in the system of FIGURE 1, notification program 140 of monitoring system 130 can determine the system state of one or components of monitoring system 130. In fact, notification program 140 can be implemented, in one embodiment of the present invention, as firmware on the monitored component (e.g. firmware on a hard drive). As another example, notification program 140 of monitoring system 170 can receive data from pressure gauge 175 to determine the system state of a pressure chamber. Other examples of monitored components can include hardware components, such as hard drives, memory, network adapters or any other hardware, software or mechanical system capable of being automatically monitored by a program.

In operation, notification program 140 can determine the system state for a component being monitored. For example, notification program 140 of monitoring system 170 can, through monitoring portion 145, can determine the pressure of a chamber through pressure gauge 175. Similarly, monitoring portion 145 in monitoring system 130 can determine, for example, the saturation of RAM in monitoring system 130 (i.e. can determine the amount of memory being used). Based on this state information, notification program 140 can determine a notification mode that corresponds to the system state. Each notification mode can define the notification behavior for a particular system state. For example, monitoring system 170 can define a first notification mode for a pressure between zero and 1,000 psi (e.g. a low-pressure mode), a second notification mode for a pressure from 1,000 psi to 9,000 psi (e.g. a normal-pressure mode), and a third notification mode for a pressure from 9,000 psi to 10,000 psi (e.g. a high-pressure mode). Each notification mode can define how frequently and how many times a notification for a particular system state is sent out.

Continuing with the previous example, the first notification mode (the low-pressure notification mode), corresponding to a pressure of less than 1,000 psi, can be configured to send out notifications every five minutes for a maximum of six consecutive notifications. The second notification mode (the normal-pressure notification mode), corresponding to a pressure of 1,000 to 9,000 psi, can be configured to send out notifications every two minutes for a maximum of 8 consecutive notifications, and the third notification mode (the high-pressure notification mode), corresponding to a pressure of greater than 9,000 psi, can be configured to send out notifications every 10 seconds without limit.

If the notification mode changes because the system state changes (e.g. the pressure goes from 800 psi to 3000 psi), a new notification can be sent out based on the new notification mode. As an example, if, at minute five, notification program 140 sends out a notification based on the first notification mode, and, at minute six, notification program 140 of system 170 determines that the pressure has changed to 3,000 psi, the notification program 140 can send out anew notification in accordance with the second notification mode. If at minute seven the pressure changes back to the below 1,000 psi, corresponding to the first notification mode, notification program 140 can send out a new notification in accordance with the first notification mode. Alternatively, because five minutes (i.e. the frequency of the first notification mode) have not passed since the last notification under the first notification mode was sent out, system 170 may delay sending out the new notification until the five minutes pass.

Notification program 140 can send out notifications in a variety of manners including email, pager, fax or SNMP trap and embodiments of notification program 140 can send notifications associated with different notification modes in different formats. For example, notifications program 140 could send high-priority notifications to an operator's pager, but send lower priority notifications to the operator's email address.

In one embodiment of the present invention, management program 115 can send updated configuration parameters to the monitoring systems thereby dynamically altering the notification behavior of a monitored system. For example, rather than having a frequency of every five minutes for the first notification mode of monitoring system 170, management program 115 can change the frequency parameter for the first notification mode to 3 minutes. This can be done while notification program 140 is running, resulting in a dynamic update to the notification behavior of monitoring system 170.

FIGURE 2A is a diagrammatic representation of a notification type 198 with configuration parameters that can be used by notification program 140 to determine if a notification should be sent according to the state of a monitored component. Each notification program 140 can utilize several notification types, with notification modes defined for each notification type. The notification type can represent the function for sending out a notification for a particular type of system state. For example, monitoring system 170 could have two notification types, one for notifications regarding pressure and one for notifications regarding temperature, with each notification type having several notification modes. As another example, each notification type can represent different types of SNMP traps implemented at the same monitored components). The configuration parameters for each notification type can include a status parameter 200 and a count parameter 205. The status parameter indicates the notification mode (e.g. notification mode 210-1, notification mode 210-1 or notification mode 210-3) that is associated with the current state of the component being monitored for notification type 198. The appropriate notification mode for a system state can be determined from one or more threshold parameters. In the embodiment of FIGURE 2A, each notification mode is associated with a "min" parameter 215 and a "max" parameter 220. Other threshold parameters can be used and m some cases the notification modes may only be associated with a single threshold parameter, rather than multiple threshold parameters as shown in FIGURE 2A.

Each notification mode can further be associated with a frequency parameter 230, a repeats parameter 235 and a last-sent parameter 240. The frequency parameter can determine how much time must lapse between notifications sent for a particular mode. Thus, for example, frequency parameter 230-1 will indicate the frequency at which notifications according to notification mode 210-1 can be sent. The last sent parameter 240 can indicate the time that a notification was last sent for the respective notification mode and the repeats parameter 235 can indicate the number of consecutive times that a notification according to the associated notification mode can be sent. For each notification type, a count parameter 205 can keep track of how many consecutive. times a notification according to the current notification mode (indicated by status parameter 200) has been sent.

In addition, the configuration parameters can include an action parameter 245 that indicates the type of notification to be sent (e.g. SNMP trap, email, page, dialog box, telephone call, fax print out, SMS chat or other notification mechanism known in the art). In the embodiment of FIGURE 2A, each notification for a notification type 198 is sent using the same notification method as determined by action parameter 245. In the embodiment of FIGURE 2B, on the other hand, each notification mode can be associated with a different notification action.

Assuming, for the sake of explanation, that a particular notification program 140 monitors the amount of RAM being used by a network component, notification program 140 can define a notification type associated with monitoring RAM saturation and further defining multiple notification modes, including a light-usage mode 210-1, a medium-usage mode 210-2, and a heavy- usage mode 210-3. The names of the modes can be stored in the respective mode parameter 250. In this example, light-usage mode can have a min parameter equal or greater than to 0% and a max parameter equal to or less than 20%, medium-usage mode 210-2 can have a min parameter 215-2 greater than 20% and a max parameter 220-2 equal to or less than 70% and the heavy usage mode

210-3 can have a min parameter 215-3 of 70% and a max parameter 220-3 of 100%. Thus, depending on the percentage of RAM used by the network component, the different notification modes will govern the notification behavior of notification program 140.

In operation, notification program 140 can determine the status of the component being monitored by comparing the performance data of the monitored component to the threshold parameter or parameters for the notification modes. For example, if the performance measurements indicate that 15% of the RAM of the monitored component is being used, this is within the threshold parameters 215-1 and 220-1 of light-usage mode 210-1. Therefore, notification program 140 can determine that the system state corresponds to light-usage mode 210-1 and set the status parameter 200 equal to the mode parameter 250-1. Additionally, if the status has changed since the last measurement was taken, notification program 140 can reset count parameter 205 to zero.

Assuming, for the sake of example, that the notification mode has remained the same between measurements of the system's state (i.e. the previously determined system state and the current system state correspond to the same notification mode), notification program 140 can determine if a notification should be sent out under the current notification mode (e.g. light-usage mode 210-1), based on frequency parameter 230-1 and last-sent parameter 240-1. If, for example, the frequency parameter 230-1 of light-usage mode 210-1 is set to 10 seconds and the time at which the last notification under light usage mode 210-1, as indicated by last-sent parameter 240-1, was greater than 10 seconds ago, notification program 140 can, in one embodiment of the present invention send out a notification. In another embodiment of the present invention, notification program 140 can further determine if the number of notifications sent out under notification mode 210-1 (e.g. as indicated by . count parameter 205), exceeds the number of allowed repeats indicated by repeats parameter 235-1. If the number of notifications does not exceed the allowed number of repeats, notification program 140 can send out a notification and increment the value of count parameter 205.

In the foregoing example, the notification program 140 determined that the notification mode did not change. If however, notification program 140 determines that the notification mode changes since the last system measurement (e.g. goes from light-usage mode 210-1 to medium-usage mode 210-2), notification program 140 can reset count parameter 205 to zero. In one embodiment notification program 140 can then send out a notification under medium-usage mode 210-2. Alternatively, notification program 140 can determine if enough time has passed since the last notification has been sent out under medium-usage mode 210-2 to send out a new notification under medium-usage mode 210-2 by, for example, comparing the difference between the current time and the value of last sent parameter 240-2 to frequency parameter 230-2. If enough time has passed, notification program 240 can send out a new notification under medium-usage mode 210-2. In one embodiment of the present invention, the notification modes can be updated by management program 115. In this embodiment, management program 115 can push out new configuration parameters to notification program 140. For example, if an operator wishes to receive a light-usage RAM notification more often, management program 115 can communicate a new frequency parameter 230-1 to notification program 140. Frequency parameter 230-1 can be updated during execution. When notification program 140 next determines the notification should be sent out under light-usage mode 210-1, notification program 140 can base this decision on the new or updated frequency parameter 230-1. In other cases, management program 115 can communicate multiple new configuration parameters to notification program 140 and can define new notification modes for a notification type. Thus, in addition to controlling the notification behavior of a system based on the system state, one embodiment of the present invention can allow for dynamic updates to the notification behavior.

It should be noted that while in FIGURE 2A and FIGURE 2B the set of configuration parameters associated with each notification mode are shown together, they can be stored in different locations or accessed at different times during the execution of notification program 140. Moreover, each notification program 140 may define several notification types. For example, if notification program 140 monitors both CPU usage and memory usage, the notification program may define a RAM usage notification function and a CPU usage notification function, each defining their own notification modes. Based on the system state of the monitored competent, notification program 140 can call the various notification types to send notifications regarding the RAM usage and the CPU usage. This allows notifications regarding different aspects of the same or different monitored component to be sent separately. Moreover, in the embodiments of FIGURE 2A and FIGURE 2B, multiple notification modes are defined for notification type 198. However, in one embodiment of the present invention, a single notification mode may be defined for notification type 198. In this case, the notification mode can act as a "heartbeat" notification that can be sent according to frequency parameter 230. The notification can be, for example, a "System Okay" notification. If management program 115 does not receive this heartbeat notification, this can indicate that the system state of the monitored component no longer corresponds to a "system okay" notification mode, indicating a problem with the component, or it can indicate a problem with notification program 140, the network connection or other communications issue. The frequency of the heartbeat notification can be adjustable through frequency parameter 230. Additionally, the form of notification sent (e.g. SNMP trap, email, fax, etc.) can also be controlled through an action parameter 245 associated with notification type 1 8 or the notification mode. FIGURE 3 illustrates a flow chart for controlling the notification behavior of a system according to one embodiment of the present invention. At step 302, notification program 140 can perform the tasks necessary to determine a system state such as monitoring a component for various performance parameters such as CPU usage, RAM usage, ASP queuing and other performance parameters known in the art (e.g. via monitoring portion 145) or receiving a system state or system state data from another program. At step 305, notification program 140 can determine a notification mode based on the system state and, for example, a set of configuration parameters. Continuing with the previous example, the system state may indicate that 15% of the RAM is being used, indicating a light-usage mode for the notification type corresponding to RAM monitoring. Notification program 140, at step 315, can then determine if the notification mode is the same as the previous notification mode or if a new notification mode has been entered. Notification program 140 can also check to ensure that a notification for the notification mode has not been sent too many times (step 325). In one embodiment of the present invention, this can be done by comparing count parameter 205 for the notification type to the repeats parameter for a particular notification mode. If, for example, the notification mode is the light-usage mode, repeats parameter 235-1 can be compared to count parameter 205. If the value of counts parameter 205 is equal to that of repeats parameter 235-1, in one embodiment of the present invention, notification program 140 will not send out a notification and control can pass to step 345. If, however, the value of counts parameter 205 is less than repeats parameter 235-1, control can pass to step 330. At step 330, notification program 140 can check if a notification under the notification mode has been sent out too recently to repeat by, for example, comparing the difference in the current time and the value of the last-sent parameter 240 for the notification mode to the frequency parameter 230 for the notification mode. Again using the previous example, notification program 140 can subtract the value of the last-sent parameter 240-1 from the current time and compare this to the value of frequency parameter 230-1. If the last notification under the light-usage mode was not sent out too recently, as determined at step 330, notification program 140, at step 335, can send a notification according to action parameter 245.

In one embodiment of the present invention, step 330 can occur even if a new notification mode was entered as determined at step 315. Therefore, notification program 140, in one embodiment of the present invention, may not immediately send out a notification even if notification program 140 determines that the system state corresponds to a new notification mode. At step 340, notification program 140 can increment the count parameter 205 for the notification type and update the last-sent parameter for the notification mode if a notification is sent out. Notification program 140 can optionally repeat the process of FIGURE 3 (step 345).

Table 1 includes an example of pseudo-code for implementing one embodiment of the process of FIGURE 3. The code of table 1 is provided by way of example only and is not limiting of the present invention. Notification program 140 can be implemented using any suitable programming language and structure, as would be understood by those of ordinary skill in the art.

TABLE 1

function main_loop(...) { while( program_running ) { // monitor system

// determine the system state system_state = CheckSystemQ;

// potentially send an notification reporting the system state NotificationFunction("SYSTEM-STATE" , system_state);

} }

function NotificationFunction (notificationjype, mode) (

// if we've entered a new mode then the count is no longer relevant if (GetVariable(notfication_type + "::STATUS") != mode) { SetVariablefnotification ype + ""COUNT", 0); }

// keep track of the latest mode SetVariable(notification_type + ""STATUS", mode);

// check if the notification hasn't been repeated too many times if (GetVariable(notification_type + "::COUNT") < GetVariable(notification_type+mode + ": -.REPEATS")) { // check if the notification was reported too recently if(

(Date() - GetVariable(notification_type+mode + "::LASTSENT"))

> GetVariable(notifιcation_type+mode + ""FREQUENCY")

) { // actually send the notification

DoNoti fication(GetVariable(notification_type + "^•.-.ACTION"), notification, mode);

// do some bookkeeping

IncrementVariable(notification_type + "::COUNT"); SetVariable(notification_type+mode + ""LASTSENT", DatefJ);

} }

In this embodiment of the present invention, a notification type can be called as a function of a main program that is capable of calling one or more notification types. With reference to FIGURE 3, notification program 140, at step 302, can perform the tasks necessary to determine a system state, such as monitoring a component for various performance parameters such as CPU usage, RAM usage, ASP queuing and other performance parameters known in the art (e.g. via monitoring portion 145) or receiving a system state or system state data from another program. At step 305, notification program 140 can determine a notification mode for a system state. For example, the system state may indicate that 15% of the RAM is being used. The "system_state" variable, at step 305, can be set equal to a particular notification mode based on the threshold parameters for each notification mode of an underlying notification type (e.g. the system_state variable can be set equal to light-usage if the RAM usage is 15%). Notification program 140 can call a notification function using the value of the system_state variable as input to that notification function. If notification program 140 defines a notification type as "SYSTEM-STATE" to send notifications regarding RAM usage, notification program 140 can call a notification function using the SYSTEM-STATE as an input for the notification type and the system_state variable as the input for the notification mode. As step 315, notification program 140 can determine if a new mode has been entered by comparing the status parameter 200 to the input mode value (i.e. to the value of the system_state variable). If a new mode has been entered, then notification program 140 can set the count parameter 205 for the "SYSTEM-STATE" notification type to zero. Notification program 140 can then set the status parameter 200 for the "SYSTEM-STATE" notification type to the value of the mode variable, (e.g. the value of the system_state variable). It should be noted that other notification types can be called (e.g. "SYSTEM-STATE2") depending on the performance characteristics being monitored.

Notification program 140 can also check to ensure that a notification for the notification mode has not been sent too many times(step 325). In one embodiment of the present invention, this can be done by comparing count parameter 205 for the notification type to the repeats parameter for a particular notification mode. For example, if the notification mode is the light-usage mode, as determined by the system_state variable, repeats parameter 235-1 can be compared to count parameter 205. If the value of counts parameter 205 is equal to that of repeats parameter 235-1, notification program 140 will not send out a notification. If, however, the value of counts parameter 205 is less than repeats parameter 235-1, control can pass to step 330. At step 330, notification program 140 can check if a notification under the notification mode has been sent out too recently to repeat by, for example, comparing the difference in the current time and the value of the last-sent parameter 240 for the notification mode to the frequency parameter 230 for the notification mode. Again using the previous example, notification program 140 can subtract the value of the last-sent parameter 240-1 from the current time and compare this to the value of frequency parameter 230-1. If the last notification under the light-usage mode not been sent out too recently, as determined at step 330, notification program 140, at step 335, can send a notification according to action parameter 245. At step 340, notification program 140 can increment the count parameter 205 for the notification type and update the last-sent parameter for the notification mode. If however, a notification is not sent at step 335, notification program 140 can exit the "SYSTEM- STATE" notification type and return to the main loop. As another example of one embodiment of the present invention in operation, assume the notification type called "SYSTEM-STATE2" has three notification modes: OKAY, THROTTLE and ERROR. The configuration parameters that define the behavior of the SYSTEM-STATE2 notification type can be as follows:

SYSTEM-STATE2: :STATUS SYSTEM-STATE2::COUNT

SYSTEM-STATE2:: ACTION = SNMPTRAP

SYSTEM-STATE2::OKAY::FREQUENCY = 0 SYSTEM-STATE2::OKAY::REPEATS = 1 SYSTEM-STATE2::OKAY::LAST SENT

SYSTEM-STATE2::THROTTLE::FREQUENCY = 30 SYSTEM-STATE2::THROTTLE::REPEATS = 1 SYSTEM-STATE2::THROTTLE::LAST SENT

SYSTEM-STATE2::ERROR::FREQUENCY = 0 SYSTEM-STATE2::ERROR::REPEATS: = INFINITE SYSTEM-STATE2::ERROR::LAST SENT When the notification mode "SYSTEM-STATE2::OKAY" is called, an SNMP trap is sent once per status change (i.e. "SYSTEM-STATE2::OKAY::REPEATS" = 1) without restriction on how often it will be sent (i.e. "SYSTEM-STATE2::OKAY: FREQUENCY" = 0). When "SYSTEM- STATE2::THROTTLE" is called, an SNMP trap will be sent at a maximum rate of once every 30 seconds. The trap will only be sent once per status change. If "SYSTEM-STATE2::ERROR" is called, an SNMP trap is sent as often and as rapidly as they are triggered because frequency equals zero and repeats equals infinite. In one embodiment of the present invention, notifications under the ERROR mode can represent the highest priority notifications for the SYSTEM-STATE2 notification type as they are the least restricted.

Table 2 provides an example timeline for the "SYSTEM-STATE2" notification modes.

In the example of Table 2, notification program 140 can determine the notification mode to which system state corresponds every second beginning at zero seconds. Using the psuedocode of Table 1 and substituting SYSTEM-STATE2 for SYSTEM-STATE, notification program 140 can set variable system_state equal to OKAY (step 305).

Notification program 140 can then call the "SYSTEM-STATE2" notification type using OKAY as the notification mode. Since this is the first notification of this notification type, the count parameter 205 can be reset to zero and the notification can be sent out (step 335). At t=l, notification program 140 can determine that the system state corresponds to the notification mode THROTTLE (step 305), call the "SYSTEM-STATE2" notification type, determine that a new mode has been entered, reset the count parameter 205 and send out a notification (step 335) as no previous notification of this type has been sent out.

At t=2, notification program 140 can determine that the system state corresponds to the notification mode OKAY (step 305) and call the notification function using the notification type SYSTEM-STATE2 with OKAY as the notification mode. At step 315, since this is a new notification mode compared to the last measurement, notification program 140 can reset the count parameter 205 to zero and update the status parameter 200 to reflect the OKAY mode. Because the frequency parameter corresponding to the OKAY mode is set to zero, and the number of repeats is set to 1, monitoring system 140 can send out a notification (step 335) indicating a system state of OKAY. Skipping now to t=4, monitoring system 140 can determine that the system state corresponds to a notification mode of THROTTLE (step 305). At step 315, notification program 140 can determine that this is a new notification mode as the previous notification mode indicated by status parameter 200 being equal to ERROR (from t=3). Notification program 140 can reset the count parameter 205 to zero and set the status parameter 200 to THROTTLE. Notification program 140, at step 325, can check if the notification under the THROTTLE notification mode has been repeated too many times. However, in this case the count is equal to zero as this is an new notification mode. At step 330, notification program 140 can determine if the last notification sent under the THROTTLE notification mode has been sent too recently. In this case, the current time, which is equal to 4 seconds, minus the value of the last-sent parameter 240 (i.e. 1 second) is less than the value of the frequency parameter 230, which is set at 30 seconds. Therefore, no notification will be sent out under the THROTTLE notification mode at t=4. Since no notification was sent, notification program 140 will not increment count parameter 205 or change last-sent parameter 240.

As illustrated in Table 2, the notification mode does not change between t=5 and t=6. The system state at both of these times corresponds to a notification mode of OKAY. At t=5, a notification will be sent out because there are no restrictions on the frequency of notifications sent under the OKAY mode and this is a new notification mode. Once the notification is sent under the

OKAY notification mode, notification program 140 can then increment count parameter 205. At t=6, however, the notification will not be sent out because a new notification mode has not been entered and the repeats parameter 235 is set to 1. In other words, notification program 140 will determine that the value of count parameter 205, having been incremented at t=5, is not less than the value of repeats parameter 235 (step 325) for the OKAY mode.

At times t=28-30, monitoring system 140 can determine that the system state corresponds to a notification mode of ERROR. In each of these cases, an error notification can be sent out as there are no limits on the frequency or number of consecutive notifications that can be sent out under the ERROR mode. At the time t=32, notification program 140 can determine that the system state corresponds to a notification mode of THROTTLE (step 305) and call the "SYSTEM-STATE2" notification type using THROTTLE as the mode. Notification program 140 can then determine that this is a new notification mode compared to the previous notification mode, reset count parameter 205 to zero and status parameter 200 to THROTTLE. Since count parameter is equal to zero, the value of repeats parameter 235 does not restrict the sending of a notification. Moreover, since the last notification under the Throttle notification mode was sent at the time t=l , the frequency parameter 230, which was set to 30 seconds, will not restrict the sending of a notification. Therefore, at step 335, notification program 140 can send a notification according to the THROTTLE notification mode. Additionally, notification program 140 can increment count parameter 205 and set the last-sent parameter to 32, starting a new 30 second period.

It should be noted that, in the embodiment of Table 2, since the action parameter 210 was set to SNMP trap, each of the notifications generated will be sent as an SNMP trap. In other embodiments of the present invention, the notifications can be sent in other formats such as email, pager, fax, telephone, chat session, dialogue box or other notification method known in the art. In addition to determining if a notification should be sent out based on a set of notification modes, embodiments of notification program 140 can receive dynamic updates to the notification modes. Management program 115 can determine if the configuration parameters for the notification program 140 need to be updated. This can occur even if no notification was sent out at step 335 because, for example, the number of previous notifications met or exceeded the repeat parameter as determined at step 320, or the last notification corresponding to the current notification mode was sent out too recently as determined at step 325. If management program 115 determines that updated configuration parameters should be sent to notification program 140, management program 115 can send out one or more update configuration parameters. Updates, in one embodiment of the present invention, can be performed via SNMP. In another embodiment of the present invention, notification program 140 can present an interface through which configuration parameters can be adjusted. At step 345, one embodiment of the present invention can repeat steps 305-345 using the updated configuration parameters.

In summary, notification program 140 can determine a notification mode based on the system state of a component being monitored and a set of configuration parameters. Notification program 140 can then determine if a notification should be sent out based the number of previous consecutive notifications that correspond to the same notification mode and/or the time at which the last notification under the current notification mode was sent out and a frequency parameter. Because both the repeats parameter and frequency parameter can be updated, the number of consecutive notifications corresponding to a particular notification mode and how often those notifications are sent can be dynamically adjusted by an operator. Embodiments of the present invention provide an advantage over prior art systems by allowing the operator to configure notification program 140 to send out notifications of different priorities with different frequencies. This can reduce information overloading and bandwidth requirements as the overall number of notifications can be reduced, while priority notifications can still be sent out frequently. Moreover, the notification behavior of a notification program can be dynamically tuned without requiring the notification program to be reinstalled.

Although the present invention has been described in detail herein with reference to the illustrative embodiments, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiments of this invention and additional embodiments of this invention will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within the spirit and true scope of this invention as claimed below. APPENDLX

NETWORK PROXY PLATFORM AND ITS USE Reference is made in detail to exemplary embodiments of the network proxy platform and its use, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements). A method and system can comprise a software architecture that allows different applications in the same or different communications protocols to interact with shared resources within a computer. More specifically, code for a computer program may be written to increase the amount of code that is generic to (i.e., shared by) more than one application or communications protocol and reduce the amount of code that handle application-specific or protocol-specific actions. In one embodiment, a transaction may be broken down into a set of discrete actions. The discrete actions may include functions that are common to more than one network application. These functions may be performed by the shared resources. For each action, code that is specific to a particular protocol or application may be written as part of a software plug-in module with function calls to functions of the shared resources. Each software plug-in module may substantially act similar to a manager for the action, where common tasks are delegated to the shared resources and the module performs specialized functions. Each protocol may have its own set of software plug-in modules for the discrete actions. New applications and support for new protocols can be added by developing a new set of plug-in modules instead of writing an entirely new program. New applications for the same protocol may be developed by replacing or editing as little as one plug-in module from a different application in the same protocol. The software architecture can reduce development time, increase the likelihood that new applications may be developed quickly with fewer changes from an existing application, more protocols will be properly supported, and reduce the burden on hardware and software resources.

A few terms are defined or clarified to aid in understanding the descriptions that follow. A network includes an interconnected set of server and client computers over a publicly available medium (e g., the Internet) or over an internal (company-owned) system. A user at a client computer may gam access to the network using a network access provider. An Internet Service Provider ("ISP") is a common type of network access provider.

As used herein, the terms "compπses," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, article, or apparatus that compnses a list of elements is not necessaπly limited to only those elements but may include other elements not expressly listed or inherent to such method, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

The term "software component" is intended to mean at least a portion of a computer program (i.e., a software application). An example includes a software plug-in module or the like. Different software components may reside in the same computer program or in different computer programs on the same computer or different computers.

Before discussing embodiments of the network proxy platform, an exemplary hardware architecture for using network proxy platform is described. FIG. 1 illustrates such an exemplary hardware architecture and includes client computer 120, proxy computer 140, and server computer 160. Client computer 120 and proxy computer 140 are bi-directionally coupled to network 11, and proxy computer 140 and server computer 160 are bi-directionally coupled to network 13. Each of networks 11 and 13 may be an internal network or an external network (e.g., the Internet). In one embodiment, networks 11 and 13 may be the same network, such as the Internet. Computers 140 and 160 may be bi-directionally coupled to databases 14 and 16, respectively. Client computer 120 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular phone, or nearly other device capable of communicating over network 11. Other client computers (not shown) may also be bi-directionally coupled to network 11. The proxy computer 140 can be a server computer, but in another embodiment may be a client computer. Other server computers (not shown) similar to server computer 160 may be bi-directionally coupled to network 13.

In an alternative embodiment, each of proxy computer 140 and server computer 160 may be replaced by a plurality of computers (not shown) that may be interconnected to each other over a network or a combination of networks. For simplicity, a single system is shown for each of proxy computer 140 and server computer 160. The client computer 120 can include central processing unit ("CPU") 122, read-only memory

("ROM") 124, random access memory ("RAM") 126, hard drive ("HD") or storage memory 128, and input output devιce(s) ("I/O") 129. I O 129 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc ), or the like. Proxy computer 140 can include CPU 142, ROM 144, RAM 146, HD 148, and I/O 149, and server computer 160 can include CPU 162, ROM 164, RAM 166, HD 168, and I/O 169.

Each of the computers in FIG. 1 may have more than one CPU, ROM, RAM, HD, VO, or other hardware components. For simplicity, each computer is illustrated as having one of each of the hardware components, even if more than one is used. Note that FIG. 1 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to skilled artisans. Each of computers 120, 140, and 160 is an example of a data processing system. ROM 124, 144, and 164; RAM 126, 146, and 166; HD 128, 148, and 168; and databases 14 and 16 can include media that can be read by CPU 122, 142, or 162. Therefore, each of these types of memories includes a data processing system readable medium. These memories may be internal or external to computers 120, 140, or 160.

Portions of the methods descnbed herein may be implemented in suitable software code that may reside within ROM 124, 144, or 164, RAM 126, 146, or 166, orHD 128, 148, or 168. The instructions in an embodiment may be contained on a data storage device, such as HD 148. FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202, on HD 148. Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

In an illustrative embodiment, the computer-executable instructions may be lines of compiled assembly, C, C*^"\ Java, or other language code. Other architectures may be used. For example, the functions of any one of the computers may be performed by a different computer shown in FIG. 1. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

In the hardware configuration above, the various software components may reside on a single computer or on any combination of separate computers. In alternative embodiments, some or all of the software components may reside on the same computer. For example, one or more the software components) of the proxy computer 140 could reside on the client computer 120, the server computer 160, or both. In still another embodiment, the proxy computer 140 and database 14 may not be required if the functions performed by the proxy computer 140 are merged into client computer 120 or server computer 160. In such an embodiment, the client computer 120 and server computer 160 may be bi-directionally coupled to the same network (not shown in FIG. 1).

Communications between any of the computers in FIG. 1 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, when a user is at client computer 120, client computer 120 may convert the signals to a human understandable form when sending a communication to the user and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by, computers 140 or 160. Similarly, when an operator is at server computer 160, server computer 160 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by computers 120, 140, or 160.

Attention is now directed to the methodology of developing a software architecture for the software accordance with one embodiment The method can compnse breaking down a transaction into a set of discrete actions. The actual definitions used for separating the transaction into the discrete actions is variable and may be selected by skilled artisans in manners that best suit their particular transactions, hardware requirements, and software requirements. The method can also include determining which functions within the set of discrete actions are common to more than one application. As more are identified, the number of shared resources can increase and the amount of application-specific code can be decreased. Therefore, skilled artisans are encouraged to examine the software from many different levels of abstraction to discover potential shared resources that may otherwise be missed.

The method can further comprise generating software components for the discrete actions. A set of software plug-in modules can correspond to the different discrete actions for the transaction. Each application may have its own set of software plug-in modules. The amount of code within each software plug-in module should be kept relatively low if the identification of shared resources was performed properly. To the extent code for any shared resources does not currently exist, code for the shared resources should be generated to maximize its ability to be used by as many different plug-in modules as possible. At least two of the software plug-in modules for different applications, whether they use the same or different protocols, can make function calls to any one or more of the shared resources. For different applications using the same protocol, only a request manipulation plug-in module, a content manipulation plug-in module, or both may be the only modules changed. Therefore, creating new application for the same protocol may be simplified because other plug-in modules used for the application may be copied from another application using the same protocol. These other plug-in modules may be substantially the same between the applications. By replacing or editing the request manipulation plug-in module, content manipulation plug-in module, or both, new applications may be developed very quickly.

Regarding applications in different protocols, each protocol may have a module that performs substantially the same action as any or all of the similar module(s) for the other protocol(s) though reducing this duplicative code by combining the common functionality is preferable.

Attention is now directed to the software architecture of the software in accordance with one embodiment. The software architecture is illustrated in FIGs. 3 and 4 and is directed towards an electronic transaction that can be performed over a network. A basic idea behind the architecture is to allow programming code for shared resources to be commonly used by as many different network applications as possible. Note that all of the resources may or may not be shared by all the applications. The programming code for each application-specific plug-in module may include code to connect the incoming communication in any supported application to the shared resources. By limiting the code within the plug-in modules, a user of the software architecture can reduce development time, increase the likelihood that more applications in the same or different protocols will be properly supported (especially proprietary protocols that may be used by only a limited nu ber of computers or users), and reduce the burden on hardware and software resources for different applications because only relatively small plug-in modules may be used.

In FIG. 3, each row of boxes 3200, 3400, and 3600 represents different applications in the same or different protocols. For example, row 3200 may represent a first application using HTTP, row 3400 may represent a different application using HTTP, and row 3600 may represent yet another application in a different protocol, such as POP, SNMP, WAP, and the like. Note that the series of dots between rows 3400 and 3600 indicate that many other applications in the same or different protocols may be present. Additionally, the architecture may be configured to allow the addition of future applications. The software architecture easily supports at least three different and potentially many more protocols.

Referring to row 3200, each of the boxes 3202 through 3214 represents different stages (actions) that may occur during an electronic transaction. For example, box 3202 may represent a request reception plug-in module, box 3204 may represent an authorization plug-in module, box 3206 may represent a request manipulation plug-in module, box 3208 may represent a content retrieval plug-in module, box 3210 may represents a content manipulation plug-in module, box 3212 may represent a content delivery plug-in module, and box 3214 may represent a post-response communication plug-in module (e.g., acknowledgement, billing, etc.). Each module may correspond to one or more of the discrete actions. Details about the individual plug-in modules are described later in this specification. Note that the other rows 3400 and 3600 include corresponding boxes for substantially the same types of actions except that they are designed for different applications. More specifically, box 3402 represents an incoming message reception plug-in module for a different application using the same protocol as box 3202, and box 3602 represents an incoming message reception plug-in module for yet another application using a different protocol compared to box 3202. New applications that make use of already-supported protocols can be developed with a minimum of effort. This is achieved by creating a new row, which makes use of protocol specific plug-ins used in another row and combines them with other plug-ins developed for the specific application at hand. Some plug-in modules may be substantially the same for many different applications in the same protocol. In different protocols, the plug-in modules for at least some of the different applications may provide substantially the same functionality, although the code within those plug-in modules may be different compared to similar modules for the other protocols.

Within the software architecture, shared resources are illustrated as planes 3102, 3104, and 3106 that lie beneath each of the rows 3200, 3400, and 3600. Referring to FIG. 4, interfaces may be made to each of the shared resources for each plug-in module. Specifically referring to box 3214, functional connectivity 4102 links module 3214 and shared resource 3102. Likewise, functional connectivity 4104 links module 3214 and shared resource 3104, and functional connectivity 4106 links module 3214 shared resource 3106. Links 4102, 4104, and 4106 can be achieved by function calls to the shared resources. Examples of the shared resources may include a content cache, a parameter cache, a connection pool, a domain name server cache, a clock, a counter, a database/a global variables space (e.g., a logging database), or the like. A list of potential shared resources is nearly limitless. Note that not all shared resources may be connected to all modules along a row. For example, modules 3202 and 3204 may not need access to the content cache because they may not receive or process content returned for a request. Each connection from a client may be handled independently on its own thread. However in other embodiments, fewer threads or a single thread can be used to operate all connections to a specific row that supports a particular application or protocol. Unless stated to the contrary, the method below is described from the perspective of proxy computer 140.

FIG. 5 includes a flow diagram of a method of performing an electronic transaction that corresponds to the software plug-in modules that lie along any of rows 3200, 3400, and 3600. Note that all modules are not required and that functions of some modules may be combined with others (e.g., authorization may be part of processing an initial request). The process flow diagram will be briefly covered followed by a more detailed description of each module.

The method can comprise receiving a request from a client computer using a request reception plug-in module (block 502) and performing authorization using an authorization plug-in module (block 504). The method can also comprise manipulating a request using a request manipulation plug-in module (block 512). The method can further comprise retrieving content using a content retrieval plug-in module (block 522). The method can yet further comprise manipulating returned content using a content manipulation plug-in module (block 532) and sending the modified content to the client computer using a content delivery plug-in module (block 534). The method can still further comprise processing post-response communications using a post-response plug-in module (block 542). Note that not all of the activities described in the process flow diagram are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs. Attention is now directed to the protocol-specific plug-in modules along the rows 3200, 3400, and 3600 and how they are related to the activities illustrated in FIG. 5. Although the discussion is directed to row 3200, the corresponding modules along other rows can provide similar functionality. Also, in the example below, client computer 120 is sending a request for content to proxy computer 140, and server computer 160 is providing content in response to the request. The flow of information could be in the opposite direction (server computer 160 seeking information from client computer 120). The method can comprise receiving a request from client computer 120 using request reception plug-in module 3202 (block 502 in FIG. 5). Request reception plug-in module 3202 can be used when a request from client computer 120 is received or accessed by proxy computer 140. Module 3202 can initially generate an associative array from portions of the header of the request. Part or all of the associative array may be used by the other modules along the same row. The associative array may provide information that can be part of function calls to the shared resources. Any or all the data (including the associative array) may be passed from any prior plug-in module (e.g., module 3202) to any or all the subsequent plug-in modules along the same row (e.g., 3204, 3206, 3208, 3210, 3212, or 3214). The method can also comprise performing authorization using authorization plug-in module

3204 (block 504). The authorization plug-in module 3204 is optional and can be used for determining whether a user at client computer 120 has proper authorization. The authorization modules may be based on an Internet Protocol ("IP") address or a name and a password. Module 3204 may send the IP address or name and password to a shared resource to determine if the user is allowed access. The method can further comprise manipulating the request using request manipulation plug-in module 3206 (block 512). Request manipulation plug-in module 3206 may be used to modify, replace, or otherwise manipulate the request. For example, proxy computer 140 may have code to redirect a URL within a request to a different URL. More specifically, proxy computer 140 may make a function call to that shared resource using the requested URL. The shared resource may pass the different URL back to module 3206. Module 3206 may have the logic to put the different URL in the correct protocol, so that it will be understood by a computer that may receive the redirected request.

The method can yet further comprise retrieving content using content retrieval plug-in module 3208 (block 522). Content retrieval plug-in module 3208 may be used to send the request and receive or access content in response to the original request or manipulated request. More specifically, a request originating from client computer 120 may have been processed by proxy computer 140 before being received by server computer 160. Content from server computer 160, in response to the processed request from proxy computer 140, would be processed using module 3208. Similar to module 3202, the code may parse the content from server computer 160 into a header portion and a content portion and append that information onto a previously generated associative array. The method can still further comprise manipulating returned content from the server computer using content manipulation plug-in module 3210 (block 532). Content manipulation plug- in module 3210 may be used to add or modify content before sending it to client computer 120. More specifically, proxy computer 140 may add advertisements or supplementary information from third parties to the content provided by server computer 160. In an alternative embodiment, part or all of the content originating from server computer 160 may be deleted or replaced with other content. The method can comprise sending the modified content to the client computer using content delivery plug-in module 3212 (block 534). Content delivery plug-in module 3212 may be used to route the content, after manipulation, if any, to client computer 120. Some of the information in the associative array generated when the original request from client computer 120 was processed may be used by module 3212 when sending the outgoing content to client computer 120.

The method can also comprise processing post-response communications using post-response plug-in module 3214 (block 542). Post-response communication plug-in module 3214 may be used for acknowledgement, billing, or other purposes. For example, after content is successfully sent to client computer 120 from module 3212, module 3124 could then charge the user's credit card for that transaction. Alternatively, module 3214 may look for a signal that service to or from client computer 120 or server computer 160 is being terminated for the current transaction. Such post-response processing may be helpful in avoiding invoices or other bills sent to a user at client computer 120 if a product or service was either incomplete or defective or to properly reflect the connect time for a transaction. Along similar lines, one of the planes as illustrated in FIG. 3 may include global space variables that may need to be used by other shared resources, proxy computer 140, or the plug-in modules. System statistics are examples of information that may be within a global variable space. This information may be useful to proxy computer 140 or another computer, such as client computer 120 or server computer 160, in monitoring activity. The statistics may include how many computers are connected to proxy computer 140, the amount of time each of those computers are connected to proxy computer 140, the amount of or time lapsed during transactions being processed through proxy computer 140, or the like.

These global variables may be used in conjunction with a module, such as authorization module 3204. If too many users are currently logged into proxy computer 140, authorization may be denied even if the computer attempting a connection to proxy computer 140 has proper security clearance. After another transaction by another client computer is terminated, a signal from module 3214 can be sent to the logging system within the shared resources. A new client computer may now gain access to the services provided by proxy computer 140 after the connection from the other transaction is terminated. Attention is now directed to more specific activities that may be performed by a specific module, and how that specific module may interact with other modules for the same transaction using a specific application. The process flow diagram illustrated in FIGs. 6-8 is used to describe some of the specific activities. Again, unless stated to the contrary, the method is primarily described from the perspective of proxy computer 140. To aid in understanding the method in FIGs. 6-8, a specific example is used and occasionally referenced. In the example, an incoming communication may be a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The client computer 120 is communicating using HTTP, using a Netscape™ browser (of AOL Time Warner, L e. of New York, New York), and has a MacOS X™ operating system (of Apple Computer, Inc. of Cupertino, California).

Referring to FIG.6, the method can comprise receiving an incoming communication for a specific application (block 602). The communication can comprise a request, a message, or other form of communication. The communication can be sent by client computer 120 and received or accessed by proxy computer 140 via network 11. Proxy computer 140 can access or read at least a portion of the incoming communication and determine the specific application for the communication. In the example, the incoming communication is a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The incoming communication will also contain other information within the header of the request. Li the example, the other information can include the browser and operating system of client computer 120.

After determining the application for the communication, proxy computer 140 can determine which row 3200, 3400, 3600, or other or row of plug-in modules will be used for the transaction. At this point in the method, proxy computer 140 may activate any or all of the plug-in modules for the row corresponding to the specific application. In one embodiment, plug-in modules within each row may be activated only as they are first used. Referring to the example, the request is for an application corresponding to row 3200. Therefore, plug-in module 3202 may be activated. If the communication is for another application, plug-in module 3402 or 3602 may be activated for the particular application.

The method can further comprise routing the incoming communication to a first software plug-in module for the specific application (block 604). Proxy computer 140 can route the request to request reception software plug-in module 3202 because the incoming request uses the application corresponding to row 3200. The method can comprise parsing the incoming communication into a header portion and a content portion (block 622). The parsing can be performed by module 3202 to obtain information from the request.

The method can also comprise generating an associative array using information contained within the header portion (block 624). The associative array can include nearly any finite number of rows. Each row can comprise a key and a value. The key can comprise a parameter within the header portion, and the value can comprise a value for that parameter. In general, the header portion may include one or more lines of a command followed by a command argument. The command may be a key, and the command argument may be the corresponding value for the key. The associative array may be searched by the key or the value. By knowing conventions used by each of the protocols for incoming communications and the characteristics of headers used for those protocols, formation of the associative array can be performed without complicated coding requirements. The associative array is flexible regarding the number of rows and allows different sizes of associative arrays to be used for different protocols.

For HTTP, one of the lines within the header may include a line with "User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv.1.1) Gecko." The key will be "User-Agent," and the value will be " Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv: 1.1) Gecko." For POP, a line may include "RETR 27," where 27 is an object identifier for is a particular item to be retrieved. The key will be "COMMAND," and the value will be "RETR." A second entry will be made with a key of "ARGUMENT" and a value of "27." For SNMP, a line may include "get 47.12.112.38," where 47.12.112.38 corresponds to an object identifier. The key will be "COMMAND", and the value will be "GET," and a second entry will have the key "ARGUMENT" and the value "47.12.112.38."

The content may or may not be part of the associative array. If it is, the associative array can include a key of "CONTENT" and the entire content data block as the value. For an image, the content may be a very large amount of data. Alternatively, the associative array may be paired with a data pointer that points to the data block, rather than incorporating it directly into the associative array.

Turning to the example, the associative array may include information as shown in Table 1 below. Descriptive names are used instead of actual names to aid in understanding the associative array. Also, the associative array may include many more rows. Because the associative array may be searched by key or value, the order of the rows is unimportant.

Table 1. Exemplary associative array

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 702 in FIG. 7). In the example, proxy computer 140 can make a function call to a shared resource, more specifically to a clock (shared resource) and a logging system (another shared resource) to get the time and log the beginning of the transaction. The logging information may include the time and a transaction identifier. Note that some of the information within the associative array could be sent with the function call to the shared resource. The method can further comprise receiving data from the function call (block 704). In the example, the transaction identifier may be passed back to module 3202. The method can still further comprise processing data from the function call with other code within the first software module (block 706). Module 3202 may be more focused on processing the incoming message rather than processing data coming back from the function call. Other modules, such as the content deliver plug- in module 3212, may perform such data processing. Note that the application-specific processing may occur before, during, or after function call(s), if any, are made to the shared resource(s).

A determination may be made whether the first software plug-in module is the last software plug-in module (diamond 722). If so, the method may end. Otherwise, the method may continue with passing any or all of the data (including the associative array) from a prior software plug-in module to the next software plug-in module (block 802 in FIG. 8). In the example, the next software plug-in module is authorization module 3204. Authorization module 3204 may use some of the information that was collected or generated by module 3202. Passing the information reduces the load on hardware by not sending a communication from proxy computer 140 to another computer (e.g., client computer 120) or making the same or similar function call to a shared resource for the same information.

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 822). Authorization module 3204 may make a function call to the parameter system to determine if the user has proper authorization, whether access can be granted (whether number of users currently connected to proxy computer has exceeded its limits), priority of connection (level or speed of service to be provided), etc. Module 3204 may pass user name and password when making the function call to the logging system. Module 3204 may also make a function call to the shared clock to obtain a time for the action.

The method can also comprise receiving data from the function call (block 824). The data may include information regarding whether user at client computer 120 has proper security clearance, whether the connection could be made, priority of the connection, and the like. The method can further comprise processing data from the function call with other code within the current software plug-in module (block 826). An example may include sending a communication from proxy computer 140 to client computer 120 informing the user whether the connection was made. Alternatively, no further processing may occur with module 3204.

A determination may be made whether the current software plug-in module is the last software plug-in module (diamond 842). If so, the method may end. Otherwise, the method may continue with block 802 in FIG. 8 and proceed in an iterative manner until the last software plug-in module is reached. The remaining modules along row 3200 will be addressed to complete the example transaction to give a better understanding of actions within the modules and some function calls that those modules may make. More or fewer modules may be used. Also, more, fewer, or different function calls may be made by the modules.

Data can be passed to request manipulation software plug-in module 3206. A function call can be made to a shared resource to determine if the request should be changed. The function call may pass information that a request for www.yahoo.com has been received or accessed. The shared resource may include logic to replace the original client request with www.google.com. The associative array may be changed to replace www.yahoo.com with www.google.com or be appended to note that the manipulated request is www.google.com.

Module 3208 may perform the content retrieval. A function call can be made to a content cache (shared resource) at proxy computer 140 to determine if the content cache includes a network page for www.google.com specifically formatted for a computer having a Netscape™ browser and a MacOS X™ operating system. Note that the browser and operating system information can be obtained from the associative array. If the content cache has the network page, it can be passed to module 3208. Otherwise, module 3208 may formulate an HTTP request to server computer 160 requesting the network page for the specific browser and operating system of client computer 120. After proxy computer 140 obtains the proper network page from server computer 160, module 3208 may send a function call to the content cache at proxy computer 140 to cache the network page. The proper network page and other information previously collected may be sent to module 3210.

Content manipulation module 3210 may delete, add, or replace some or all of the content within the proper network page returned. For example, when the proper Google network page is received or accessed, module 3210 may add advertisement(s) around the border(s) of the page. A function call can be made to a shared resource to determine which advertisement(s) should be added. The logging system may keep track of which advertisement is being added, whose advertisement it is, and how many times the advertisement has been added during the current billing cycle. The logging system, which is a shared resource, may access the counter (another shared resource) by itself. In other works, some or all of the shared resources may interact with each other without requiring an application-specific software plug-in module to intervene. The manipulated content and other information may be passed to module 3212.

Content delivery software plug-in module 3212 may take the Google network page formatted for a Netscape™ browser and MacOS X™ operating system and the advertisement(s) from module 3210 and prepare a communication using HTTP. The communication can be sent from proxy computer 140 to client computer 120. Function calls can be made to the logging system to note the actual content sent to client computer 120 and time sent. Any or all information collected or generated by modules 3202-3212 maybe passed to module 3214. Post-response communications module 3214 may be used to track usage or billing information. At the end of a transaction, module 3214 may make a function call to the clock to determine the current time, and make another function call to the logging system to determine how much time lapsed during the transaction and record any billing information. The billing information may be within a shared resource managed by an accounting department. Billing information for the user at client computer 120 may be passed from one of the shared resources to module 3214, which may return some of the information for the user at client computer 120. Proxy computer 140 may send a message to client computer 120 similar to "You were connected for 2.1 minutes and were charged $1.27. Thank you for using our service." Alternatively, no message may be sent and the method may end.

Note that not all of the activities described in the process flow diagram in FIGs. 6-8 are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs.

The power of creating new applications for the same, protocol may be better understood with the flow diagram in FIG. 9 and an example. In one embodiment, different applications may be generated for different priorities of users for a network site. The communication protocol may use HTTP. The method can comprise developing a first set of plug-in modules for a first application (block 902). The set may correspond to row 3200 and be directed to premium users of a network site. A new application may need to be developed for regular users of the network site. The communication protocol may also use HTTP. The method can comprise copying the first set of plug- in modules to form a second set of plug-in modules (block 922).

For the new application, only the request manipulation plug-in module, the content manipulation plug-in module, or both may be replaced. The remainder of the plug-in modules may be unchanged and be substantially the same as the remainder of the plug-in modules for the first application.

The method may comprise replacing a first request manipulation plug-in module with a second request manipulation plug-in module for a second application (block 924). For example, the premium user may have access to some network pages that the regular user may not. If the regular user requests a premium page, the second request manipulation module may direct the regular user to another network page for which the regular user has proper access.

The method may also comprise replacing a first content manipulation plug-in module with a second content manipulation plug-in module for the second application (block 926). The premium user may have only 10 percent of his or her window occupied by advertisements, whereas the regular user may have 50 percent of his or her window occupied by advertisements. The second content manipulation module may reformat the retrieved content to allow for more advertising space. The second content manipulation module may also access the shared resources to obtain the advertisements and keep track of which advertisements were used. Device dependent optimization of network pages (desktop computer vs. cellular phone, etc.) can be achieved by plugging in a module which transcodes content using settings developed for the particular device that made the initial request. After one or both of the request manipulation and content manipulation modules are replaced, the method can still further comprise executing the second application using the second set of plug-in modules (block 942).

Note that while the example focused more on replacing specific modules, in other embodiments, those modules may be generated by editing code within the corresponding modules within the first set for the first application.

After reading this specification, skilled artisans will appreciate that entirely different applications, using the same network protocol, can be developed by simply inserting new plug-in module(s) at the request manipulation location, the content request location, or both locations.

In other embodiments, the method and system may be used for nearly any other network communications. As an example, client computer 120 may make a request for information within a database located at server computer 160. The request may be handled in a manner similar to a request for a network page. If the user does not have proper authorization to all information within a request, the request manipulation module may request only that information for which the user has property access or the content manipulation module may add information stating that the user does not have proper access to some or all the information.

In another embodiment, the multiple-protocol software architecture and plug-in modules may be installed in client computer 120 or server computer 160. Not all modules in proxy computer 140 may be needed by client computer 120 or server computer 160. Authorization modules 3204, 3404, and 3604 may not be used or can be coded to allow authorization (always authorized) at client computer 120. The content manipulation modules 3210, 3410, and 3610 may not be used by the server computer 160. After reading this specification, skilled artisans are capable of determine which modules are needed and which ones can be eliminated or bypassed (module exists but passes information through without performing any other significant activity).

The software components can be designed to maximize their ability use shared resources while minimizing the amount of code used for application-specific operations. Therefore, relatively smaller plug-in modules (compared to the shared resources) may be used to access the shared resources illustrated in the planes below the modules. In this manner, less code needs to be written for a new protocol compared to the prior-art method of writing or copying and modifying an entire program for a specific protocol. For applications in the same protocol, the specific coding requirements may be much less. Furthermore, protocols are more likely to be supported because the coding requirements are less, and therefore, may be generated for protocols that have relatively fewer users compared to other protocols. The method and system are significantly more efficient in both time and cost compared to existing prior-art methods dealing with the problem of many different applications in the same or different protocols.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Claims

1. A system for controlling notification behavior of a system comprising a notification program stored on a computer-readable memory, executable by a computer processor to: determine a first notification mode based a set of configuration parameters and the first system state for a system being monitored, wherein said set of configuration parameters defines at least two notification modes for a notification type; determine if a first notification should be sent out based on the set of configuration parameters and the first notification mode; and if the first notification should be sent out, communicate the first notification over a network.

2. The system of Claim 1, wherein the notification program is further executable to determine if the first notification should be sent out based on the time the last notification associated with the first notification mode was sent out and a frequency parameter associated with the first notification mode.

3. The system of Claim 1, wherein the notification program is further executable to determine if the first notification should be sent out based on the set of configuration parameters and the first notification mode by: determining if the number of consecutive notifications associated with the first notification mode exceeds a preset value.

4. The system of Claim 1, wherein said notification program is further executable to: determine a new notification mode based on a new system state and the set of configuration parameters; if the new notification mode is determined to be a second notification mode: determine if a new notification should be sent out based on the second notification mode and the set of configuration parameters; if a new notification should be sent out, communicate the new notification over a network.

5. The system of Claim 4, wherein if the new notification mode is determined to be a second notification mode, the notification program is further executable to: determine if the new notification should be sent out based on the time the last notification associated with the second notification mode was sent out and a frequency parameter associated with the second notification mode; if a new notification should be sent out, communicate the new notification over the network.

6. The system of Claim 1, wherein said notification program is further executable to: receive an updated configuration parameter associated with said first notification mode; determine a new notification mode based on a new system state and the set of configuration parameters; if the new notification mode is determined to be the same as the first notification mode: determine if a new notification should be sent out based on the updated set of configuration parameters; if a new notification should be sent out, communicate the new notification over a network.

7. The system of Claim 6, wherein said updated configuration parameter is an updated frequency parameter associated with said first notification mode and wherein the notification program is further executable to determine if the new notification should be sent out based on the time the last notification associated with the first notification mode was sent out and the updated frequency parameter associated with the first notification mode.

8. The system of Claim 6, wherein the updated configuration parameter is a repeats parameter and wherein if the new notification mode is determined to be a second notification mode, the notification program is further executable to: determine if the number of consecutive notifications associated with the first notification mode exceeds the value of the updated repeats parameter.

9. The system of Claim 1, wherein the first notification is one of an email notification is one of email notification, a fax, a dialog box, a page or an SMS notification.

10. A system for dynamically controlling notification behavior comprising: a network; a monitoring system further comprising: a monitoring system computer processor; a monitoring system network interface device electrically connected to the monitoring system computer processor to communicate data to a network; a monitoring system computer readable memory containing a notification program executable by the monitoring system computer processor to: load a set of configuration parameters; determine if a first notification should be sent based on said set of configuration parameters and a system state of a system being monitored; if the first notification should be sent, communicate said notification over said network; receive an update to at least one configuration parameter of the set of configuration parameters during execution; and send out at an additional notification based on the update to the at least one configuration parameter; and a management system further compnsing: a management system computer processor; a management system network interface device electncally connected to the monitoring system computer processor to communicate data to the network; a management system computer readable memory containing a management program executable by the monitoring system computer processor to: receive the first notification; and communicate the update to at least one configuration parameter of the set of configuration parameters to the monitoring system.

11. The system of Claim 10, wherem said set of configuration parameters defines at least two notification modes for a notification type.

12. The system of Claim 11, wherein for each notification mode, said set of configuration parameters further compnses: a frequency parameter defining the frequency that notifications are sent out under the associated notification mode; and a repeats parameter defining the number of consecutive notifications sent out under the associated notification mode.

13. The system of Claim 12, wherein for each notification mode, said set of configuration parameters further compnses a last sent parameter defining the time a notification for the associated notification mode was last sent out.

14. The system of Claim 13, wherem for each notification mode, said set of configuration parameters further compnses at least one threshold parameter.

15. The system of Claim 13, wherein said set of configuration parameters further comprises an action parameter defining the action to be taken when a notification is sent out.

16. The system of Claim 15, wherein said monitoring software is further executable to send out said first notification as an SNMP trap based on said action parameter.

17. The system of Claim 11 , wherein said set of configuration parameters further comprises a status parameter defining the notification mode under which the first notification is sent out.

18. The system of Claim 17, wherein said set of configuration parameters further comprises a count parameter indicating the number of consecutive notifications sent out under at least one notification mode of said at least two notification modes.

19. The system of Claim 11 , wherein the notification program is further executable to determine if the first notification should be sent based on the time a previous notification was sent out under the first notification mode and a frequency parameter associated with the first notification mode.

20. The system of Claim 19, wherein said updated configuration parameter is an updated frequency parameter associated with said first notification mode.

21. The system of Claim 20, wherein the notification program is further executable to determine if the additional notification should be sent based on the time the first notification was sent out and the updated frequency parameter.

22. The system of Claim 10 wherein the notification program is further executable to determine if the first notification should be sent out based on the set of configuration parameters and the first notification mode by: determining if a number of consecutive notifications associated with the first notification mode exceeds a preset value.

23. A system for controlling notification behavior of a system comprising a notification program stored on a computer-readable memory, executable by a computer processor to: determine a first notification mode based a set of configuration parameters and the first system state for a system being monitored, wherein said set of configuration parameters defines at least two notification modes for a notification type; determine if a first SNMP trap should be sent out based on the set of configuration parameters and the first notification mode; and if the first SNMP trap should be sent out, communicate the first SNMP trap over a network.

24. The system of Claim 23, wherein the notification program is further executable to determine if the first SNMP trap should be sent out based on the time the last SNMP trap associated with the first notification mode was sent out and a frequency parameter associated with the first notification mode.

25. The system of Claim 23, wherein the notification program is further executable to determine if the first SNMP trap should be sent out based on the set of configuration parameters and the first notification mode by: determining if the number of consecutive SNMP traps associated with the first notification mode exceeds a preset value.

26. The system of Claim 23, wherein said notification program is further executable to: determine a new notification mode based on a new system state and the set of configuration parameters; . if the new notification mode is determined to be a second notification mode: determine if a new SNMP trap should be sent out based on the system state and second notification mode; if a new SNMP trap should be sent out, communicate the new SNMP trap over a network.

27. The system of Claim 26, wherein if the new notification mode is determined to be a second notification mode, the notification program is further executable to: determine if the new SNMP trap should be sent out based on the time the last SNMP trap associated with the second notification mode was sent out and a frequency parameter associated with the second notification mode; if a new SNMP trap should be sent out, communicate the new SNMP trap over the network.

28. The system of Claim 23, wherein said notification program is further executable to: receive an updated configuration parameter associated with said first notification mode; determine a new notification mode based on a new system state and the set of configuration parameters; if the new notification mode is determined to be the same as the first notification mode: determine if a new SNMP trap should be sent out based on the updated set of configuration parameters; if a new SNMP trap should be sent out, communicate the new SNMP trap over a network.

29. The system of Claim 28, wherein said updated configuration parameter is an updated frequency parameter associated with said first notification mode and wherein the notification program is further executable to determine if the new SNMP trap should be sent out based on the time the last SNMP trap associated with the first notification mode was sent out and the updated frequency parameter associated with the first notification mode.

30. The system of Claim 28, wherein the updated configuration parameter is a repeats parameter and wherein if the new notification mode is determined to be a second notification mode, the notification program is further executable to: determine if the number of consecutive SNMP traps associated with the first notification mode exceeds the value of the updated repeats parameter.

31. A method for controlling notification behavior of a system comprising: determining a first notification mode based a set of configuration parameters and the first system state for a system being monitored, wherein a plurality of notification modes are defined for a notification type; determining if a notification should be sent out based on the set of configuration parameters and the first notification mode; and if the notification should be sent out, communicating the notification over a network.

32. The method of Claim 31, wherein the step of determining if a notification should be sent out based on the set of configuration parameters and the first notification mode further comprises determining if the notification should be sent out based on the time the last notification associated with the first notification mode was sent out and a frequency parameter associated with the first notification mode.

33. The method of Claim 31 wherein the step of determining if a notification should be sent out based on the set of configuration parameters and the first notification mode by further comprises determining if the number of consecutive notifications associated with the first notification mode exceeds a preset value.

33. The method of Claim 31, further comprising: receiving an updated configuration parameter associated with said first notification mode; determining a new notification mode based on a new system state and the set of configuration parameters; if the new notification mode is determined to be the first notification mode: determining if a new notification should be sent out based on the updated set of configuration parameters; if a new notification should be sent out, communicating the new notification over a network.

35. The method of Claim 34, wherein the first notification and new notification are SNMP traps.

36. A system for controlling notification behavior of a system comprising a notification program stored on a computer-readable memory, executable by a computer processor to: determine if a system state corresponds to a first notification mode based a set of configuration parameters and the system state for a system being monitored; determine if a first notification should be sent out based on the set of configuration parameters and the first notification mode; and if the first notification should be sent out, communicate the first notification over a network.

37. The system of Claim 35, wherein the notification program is further executable to determine if the first notification should be sent out based on the time the last notification associated with the first notification mode was sent out and a frequency parameter associated with the first notification mode.

38. The system of Claim 37, wherein said first notification mode defines a heartbeat notification mode.

39. The system of Claim 37, wherein the form of notification sent out under the first notification mode is adjustable based on an action parameter.