Source: http://www.google.com/patents/US6633230?dq=5,758,352
Timestamp: 2016-12-09 10:43:45
Document Index: 105592700

Matched Legal Cases: ['Application No 9917993', 'Application No 9917993', 'art 2', 'art 3', 'art 2', 'art 3']

Patent US6633230 - Apparatus and method for providing improved stress thresholds in network ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA network management apparatus and method for determining an optimum threshold value for a monitored characteristic of a network is described. The optimum threshold value is determined by counting a number of previously received events generated from values for a monitored characteristic which were above...http://www.google.com/patents/US6633230?utm_source=gb-gplus-sharePatent US6633230 - Apparatus and method for providing improved stress thresholds in network management systemsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS6633230 B2Publication typeGrantApplication numberUS 09/897,266Publication dateOct 14, 2003Filing dateJul 2, 2001Priority dateFeb 21, 2001Fee statusPaidAlso published asUS20020141337Publication number09897266, 897266, US 6633230 B2, US 6633230B2, US-B2-6633230, US6633230 B2, US6633230B2InventorsRonan François Daniel Grandin, David James Stevenson, Andrew Hunter Gray, Neil William GrayOriginal Assignee3Com CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (29), Non-Patent Citations (18), Referenced by (29), Classifications (9), Legal Events (11) External Links: USPTO, USPTO Assignment, EspacenetApparatus and method for providing improved stress thresholds in network management systems
US 6633230 B2Abstract
A network management apparatus and method for determining an optimum threshold value for a monitored characteristic of a network is described. The optimum threshold value is determined by counting a number of previously received events generated from values for a monitored characteristic which were above or below an existing threshold value for the monitored characteristic, and determining the optimum threshold value in dependence on the counted number. An optimum threshold value is provided, which is tailored to suit the network concerned.
What is claimed is: 1. A method for determining an optimum threshold value for a monitored characteristic of a managed network, the threshold value defining a value for the monitored characteristic above or below which an event is generated, the method comprising the steps of:
for a preceding time period, counting a number of events generated from values for the monitored characteristic, received during the time period, which were above or below an existing threshold value for said monitored characteristic, and determining an optimum threshold value for the monitored characteristic in dependence on the number determined by the counting step. 2. A method as claimed in claim 1, in which the preceding time period is an immediately preceding time period.
3. A method as claimed in claim 1, in which, prior to the step of counting, the method further comprises the step of: retrieving data from a data storage, the data including the values for the monitored characteristic received during the preceding time period.
4. A method as claimed in claim 1, in which, if the number determined by the counting step is zero, the step of determining an optimum threshold value comprises: determining the optimum threshold value as either the existing threshold value or a default threshold value for the monitored characteristic.
5. A method as claimed in claim 4, in which, if the number determined by the counting step is zero, the method further comprises the step of: comparing the existing threshold value with a default threshold value, and, if the existing threshold value exceeds the default threshold value, determining the optimum threshold value as the default threshold.
6. A method as claimed in claim 5, in which, if the existing threshold value is less than the default threshold value, the step of determining an optimum threshold value comprises: determining the optimum threshold value as the existing threshold value.
7. A method as claimed in claim 5, in which, if the existing threshold value is less than the default threshold value, the method further comprises the step of: comparing the existing threshold value with a minimum recommended threshold, and if the existing threshold value is greater than the minimum recommended threshold, determining the optimum threshold value as the existing threshold value, and if the existing threshold value is less than or equal to the minimum recommended threshold, determining the optimum threshold value as the default threshold value.
8. A method as claimed in claim 1, in which, if the number determined by the counting step is less than a predetermined number greater than zero, the step of determining comprises determining the optimum threshold value as the existing threshold value.
9. A method as claimed in claim 1, in which, if the number determined by the counting step is less than a predetermined number greater than zero, the method further comprises the step of: comparing the existing threshold value with a minimum recommended threshold, and, if the existing threshold value exceeds the minimum recommended threshold, determining the optimum threshold value as the existing threshold value, and if the existing threshold is less than or equal to the minimum recommended threshold, determining the optimum threshold value as the default threshold value.
10. A method as claimed in claim 1, in which, if the number determined by the counting step is greater than or equal to a predetermined number greater than zero, the method further comprises the step of: calculating a statistical value based on an average of the values of the monitored characteristic received during the predetermined time interval, and, using said statistical value to determine the optimum threshold value.
11. A method as claimed in claim 10, in which the step of calculating a statistical value includes: determining a mean average by summing said values for the monitored characteristic and dividing the sum by the number determined by the counting step, and adding X% to the mean average, where X is a predetermined value to obtain said statistical value.
12. A method as claimed in claim 10, further comprising the step of comparing the statistical value with a default threshold value plus Y%, where Y is a predetermined value, and, if the statistical value exceeds the default threshold plus Y%, determining the optimum threshold value as the default threshold value plus Y%.
13. A method as claimed in claim 12, in which, if the statistical value is less than or equal to the default threshold plus Y%, determining the optimum threshold value as the statistical value.
14. A method as claimed in claim 12, in which, if the statistical value is less than or equal to the default threshold plus Y%, the method further comprises the step of: comparing the statistical value with a minimum recommended threshold, and, if the statistical value is less than the minimum recommended threshold, determining the optimum threshold value as the minimum recommended threshold, and if the statistical value is greater than or equal to the minimum recommended threshold, determining the optimum threshold value as the statistical value.
15. A computer readable medium comprising a computer program for carrying out the method as claimed in claim 1.
16. A computer readable medium including a computer program for determining an optimum threshold value for a monitored characteristic of a managed network, the threshold value defining a value for the monitored characteristic above or below which an event is generated, the program comprising:
a program step for counting a number of events generated from values for the monitored characteristic that were received during a preceding time period and that were above or below an existing threshold value for said monitored characteristic, and a program step for determining an optimum threshold value for the monitored characteristic in dependence on the number determined by the program step for counting. 17. A network management apparatus for monitoring a network and for determining an optimum threshold value for a monitored characteristic of the network, the threshold value defining a value for the monitored characteristic above or below which an event is generated, the apparatus comprising:
a processor configured to count the number of events generated from values for a monitored characteristic which were above or below an existing threshold value for said monitored characteristic, said values received during a preceding time period, and configured to determine an optimum threshold value for the monitored characteristic in dependence on the number determined by the counting step. 18. An apparatus as claimed in claim 17, in which the processor is further configured to retrieve management data from the network, the management data including values for the monitored characteristic.
19. An apparatus as claimed in claim 18, further comprising memory for storing the retrieved management data.
The present invention relates generally to an apparatus and method for the management of a network, and more particularly to a network management apparatus and method for monitoring the stress of a network, and generating events when high stress conditions are detected.
A network is generally configured with core devices having a plurality of ports, which can be used to interconnect a plurality of media links on the network. Such devices include hubs, routers and switches which pass data packets received at one port to one or more of its other ports, depending upon the type of device. Such core devices can be managed or unmanaged.
A managed device is capable of monitoring data packets passing through its ports. For example, a managed device can learn the physical or MAC addresses of the devices connected to its ports by monitoring the source address of data packets passing through the respective ports. Identified source and destination addresses transmitted from or to a port of a managed network device, such as a router, hub, or switch, are stored in a respective “address table” associated with the port.
Managed devices additionally have the capability of communicating with each other using a management protocol such as the SNMP (Simple Network Management Protocol), as described in more detail below. Whilst the following description is concerned with the SNMP management protocol, the skilled person will appreciate that the invention is not limited to use with SNMP, but can be applied to managed networks using other network management protocols.
SNMP forms part of the TCP/IP protocol suite, which is a number of associated protocols developed for networks connected to the Internet. SNMP defines agents, managers and MIBs (where MIB is Management Information Base), as well as various predefined messages and commands for data communication. An agent is present in each managed network device and stores management data, responds to requests from the manager using the GETRESPONSE message and may send a TRAP message to the manager after sensing a predefined condition. A manager is present within the network management station of a network and automatically interrogates the agents of managed devices on the network using various SNMP commands such as GET and GETNEXT commands, to obtain information suitable for use by the network administrator, whose function is described below. A MIB is a managed “object” database which stores management data obtained by managed devices, and is accessible to agents for network management applications.
An example of a known network management software application capable of determining monitoring the stress of a network is the 3Com® Network Supervisor available from 3Com Corporation of Santa Clara, Calif., USA. This application, and similar applications, uses SNMP commands to retrieve relevant management data from managed network devices, and processes the data as described below.
A part of the network administrator's function is to identify and resolve problems occurring on the network, such as device or link malfunction or failure. In order to provide the network administrator with the necessary information to identify such problems, the network management application monitors the devices on the network. An example of such monitoring is described in co pending UK Patent Application No 9917993.9 entitled “Management System and Method for Monitoring Stress in a Network” in the name of the present applicant. In the system and method described in UK Patent Application No 9917993.9 the SNMP manager in the network management station requests the agents of managed network devices on the network to retrieve selected MIB data indicative of device and link operation, and performs tests for device activity and service availability. Such MIB data may relate to characteristics such as traffic activity or errors occurring at a particular port in the relevant network device. Tests may include sending ICMP Ping requests to each device on the network, or sending selected requests for services such as SMTP, NFS and DNS to servers, and monitoring the time taken to receive a response. The monitored parameters or characteristics are referred to herein as “stress metrics”.
The network management application compares, for each stress metric, the retrieved data or test results against a corresponding threshold level for the stress metric. The threshold level is the level above (or below) which performance is considered to be unacceptable. For simplicity, the following description is based on a maximum threshold, that is, a threshold level above which performance is considered to be unacceptable. The skilled person will appreciate that for some stress metrics the threshold level could be a level below which performance is unacceptable. Default values for threshold levels of monitored stress metrics are typically preset by the application vendor, but may be adjusted by the network administrator.
Each time a threshold is exceeded, the application logs an “Event”. The “Event log” lists each Event, and includes information such as the date and time of the Event, the identity of the device affected and the nature of the Event. The network administrator can then review the Event list to identify problems on the network.
It is important that the thresholds for the monitored stress metrics are chosen so that the number of Events presented in the Event log for review is minimised whilst still keeping the network administrator informed of Events which indicate genuine problems on the network. It can be difficult for the network administrator to choose a threshold level which will be exceeded only if genuine problems exist on his particular network. Accordingly, there is a need for a system and method which can be used to assist the network administrator in the task of setting the threshold levels.
In the present applicant's UK Patent Application number 0009050.6 entitled “Network Management Apparatus and Method for Monitoring Stress in a Network”, a method is proposed to assist the network administrator in setting threshold levels. In the method the administrator moves the threshold value up or down and the program simulates the Events which would have been generated if the threshold had been set at the changed value using previously received stress values from the network devices. The administrator can use the simulated Event lists to select a threshold level which generates only significant Events.
A problem with the method proposed in UK Patent Application number 0009050.6 is that the network administrator must have sufficient knowledge of the nature and type of Events generated so that he or she can determine which simulated Event list produced by the method includes all significant Events but few, and preferably no, unimportant Events. It cannot assist the inexperienced network administrator who does not have this knowledge.
The present invention seeks to address this problem, and provide a method and apparatus which can be used by even the most inexperienced network administrator in setting threshold levels.
In accordance with a first aspect, the present invention provides a method for determining an optimum threshold value for a monitored characteristic of a managed network, the method comprising the steps of: for a preceding time period, counting a number of values for a monitored characteristic, received during the time period, which exceeded an existing threshold value for said monitored characteristic, and determining an optimum threshold value for the monitored characteristic in dependence on the number determined by the counting step.
The method of the present invention thus provides the user with a suggested optimum threshold value for a monitored characteristic based on the number of previously received monitored values for the characteristic. The network administrator does not need to have knowledge of the nature and type of Events in order to adjust the threshold setting for the monitored characteristic. By using previously received monitored values, the suggested optimum threshold level is specific to the particular network.
In accordance with a third aspect, the present invention provides a network management apparatus for monitoring a network and for determining an optimum threshold value for a monitored characteristic of the network, the apparatus comprising: a processor configured to count the number of values for a monitored characteristic which exceeded an existing threshold value for said monitored characteristic, said values previously received during a preceding time period, and configured to determine an optimum threshold value for the monitored characteristic in dependence on the number determined by the counting step.
Other preferred features of the present invention will be apparent from the following description and accompanying claims.
FIG. 1 is a block diagram of a typical network having a network management station which may be employed in accordance with the present invention, and
FIG. 2 is a flow chart showing the steps carried out by a computer program implementing a method in accordance with a preferred embodiment of the present invention.
FIG. 1 shows a typical network 1 incorporating a network management system according to a preferred embodiment of the present invention. The network 1 includes a network management station 3A which incorporates the necessary hardware and software for network management. In particular, the network management station 3A includes a processor, a memory and a disk drive as well as user interfaces such as a keyboard and mouse, and a visual display unit. Network management application software in accordance with the present invention is loaded into the memory of management station 3A for processing data as described in detail below. The network management station 3A is connected by network media links 5 to a plurality of managed network devices including core devices such as network switch 7, hubs 11 and 12, and a router (not shown) which may be managed or unmanaged, and end stations including personal computers (PCs) 3 and workstations. The network may also include unmanaged devices, for example peripheral devices such as printers.
The network management station 3A is capable of communicating with the managed network devices such as network switch 7 and hubs 11 and 12 by means of a network management protocol, in the present embodiment the SNMP protocol, in order to obtain network management data. Each managed device includes a processor which monitors operational characteristics and an SNMP agent which stores the monitored data as MIB data in memory on the device as is well known in the art, including data relating to inter alia data traffic at the device.
An SNMP managed device may monitor data for a number of MIBs. An example of a MIB containing network management data is MIB-II (formerly MIB-I) as specified by the IETF (Internet Engineering Task Force) in specification RFC1213. MIB-II is common to most vendors' core devices and any network management system should preferably be capable of reading and utilising management data from MIB-II. Furthermore, the network management system of the preferred embodiment of the present invention is additionally capable of reading and utilising more complex management data contained in such MIBs as RMON (Remote Monitoring MIB, RFC1271), RMON2 (Remote Monitoring MIB 2, RFC2021), the standard bridge MIB (RFC1493), the standard repeater MIB (RFC1516), or any proprietary MIBs produced by original equipment manufacturers (e.g. the 3Com Remote Poll MIB).
In network 1, hubs 11 and 12 and switch 7 are MIB-II compatible, and switch 7 is also RMON compatible. Other configurations are possible, and contemplated.
In accordance with the preferred embodiment of the present invention, the network management station 3A monitors a plurality of stress metrics. The stress levels or values for the metrics are obtained by periodically requesting relevant MIB-II data from hubs 11 and 12 and switch 7, and RMON data from switch 7, and by periodically polling all network devices using Ping or service requests and monitoring response times.
The network management station 3A compares each monitored stress level against a corresponding predetermined threshold level for the stress metric. Each time a threshold is exceeded, the network management station 3A stores details about the monitored stress level in an Event log in memory. The memory typically stores the Event log data in the form of a database or similar data file, which stores Event data in different time intervals separately. Thus, the database provides a history of Events that have occurred on the network for different time periods. It should be noted that monitored stress levels which do not exceed the threshold are not stored in the Event log, in accordance with the preferred embodiment, and the received data about these monitored levels is discarded or overwritten by subsequent monitored stress levels. It will be appreciated that in other embodiments all monitored stress levels for some or all time intervals may be stored in the database.
A typical Event log is shown in Table 1 below. Each Event listed in the Event log represents a monitored stress level which exceeded the threshold set for the stress metric at the time of the Event.
HUB10-1-72
Utilisation on port 2
exceeded 80%
S1000-1-72
Errors on port 24
exceeded 5%
Errors on port 2
PSH40-1-72
PSHUB 40
Broadcasts on port 12
exceeded 200/s
Utilisation on port 24
The threshold for each metric is preset to a default value in the network management station 3A and is adjustable by the network administrator. The network administrator conventionally has no means of establishing the appropriate threshold level for the monitored stress metrics to ensure that he or she is informed of all genuine Events, i.e. Events indicative of genuine problems on the network, but is not notified of Events which are not significant for the network concerned.
In accordance with a preferred embodiment of the present invention, the network management station 3A operates a method which uses data obtained during previous monitoring of the network to suggest the optimum value for the threshold level of a stress metric for the network concerned.
The method of the present invention is preferably implemented in a computer program which is run on the management station 3A. It will be appreciated that the method may be implemented in other forms such as hardware. In accordance with the preferred embodiment, the computer program carries out the steps illustrated in FIG. 2.
As described above, the network management system employed in the present invention monitors stress metrics by retrieving and processing management data from managed network devices, and generates Events when threshold levels for the relevant metrics are exceeded.
For the purposes of the following description it is assumed that the network management station 3A has an Event log stored in a database as described above, which the program of FIG. 2 utilises, as described below.
The program begins when the network administrator runs the part of the management software application to set the threshold level of the stress metrics. It will be appreciated that the program may be initiated automatically at selectable regular time intervals, e.g. once a week, in order to prompt the administrator to optimise the threshold levels.
At step 101 the program retrieves Event data from the database, preferably for a selected time period. In accordance with the preferred embodiment, the selected time period is an immediately preceding time period such as the last 7 days. It will be appreciated that in other embodiments, other time ranges, which need not be immediately preceding, may be selected. The selected time period ideally represents the time interval since the last threshold adjustment was performed. The Event data includes an identifier for each separate Event (this is generated when an Event is logged in the Event log and/or stored in the database, as is well known in the art), the identity of the monitored metric, the value of the monitored metric, which caused the Event and the threshold which the value exceeded.
In the preferred embodiment, the Events for all metrics in the relevant time interval are retrieved at this stage. In other embodiments, the user may select a monitored metric and only events relating to the selected metric may be retrieved and processed.
At step 102 the program counts the number of Events for a selected metric represented in the Event data retrieved by step 101. This is the number of Events occurring in the immediately preceding selected time interval for the monitored metric.
As will be appreciated from the following, the way in which the program proceeds to determine the optimum threshold for the selected monitored metric is dependent upon the number of Events found in step 102.
The program first considers if there are any Events at step 103.
If step 103 determines that there are no Events for the monitored metric, this could suggest that the network is operating well for this metric, and no problems have therefore arisen. Alternatively, it may be that the threshold has been set too high, and the network management station has failed to log values for the metric which represent problems of high stress.
Thus, at step 104 the program compares the “current” threshold value for the monitored stress metric concerned (i.e. the threshold which led to no Events being logged in the relevant time interval) against the “default” threshold for the metric. As previously mentioned, the default value for each threshold is preset, typically by the application vendor, at a level which is expected to be suited to the average network.
If step 104 determines that the current threshold exceeds the default threshold, the threshold may be too high, and the program therefore determines, at step 105, that the optimum threshold level is the default value for the threshold.
The program may then end, or continue for another monitored stress metric.
If step 104 determines that the current threshold is less than or equal to the default threshold, the program continues at step 106 by considering whether the current threshold exceeds the minimum recommended threshold. The minimum recommended threshold is typically expressed as a percentage Z of the default value for each stress metric (e.g. Z=20). Both the value of Z and the default threshold value are specific to the stress metric, and corresponding values are laid down by the application for each monitored stress metric. If no value Z is preset for a stress metric, the program of the preferred embodiment uses a default percentage value defined for all stress metrics (e.g. 20%). If a threshold is set below the minimum recommended threshold, Events are likely to be generated for monitored values which are normal, thus giving the administrator the false impression that the network is stressed.
If step 106 determines that the current threshold is above the minimum recommended threshold, the current threshold is within appropriate parameters and the network is most likely operating well. The program therefore determines, at step 107, that the optimum threshold level is the current threshold level.
If step 106 determines that the current threshold is below the minimum recommended threshold, the current threshold is not within appropriate parameters and, although the network is probably operating well (since no Events have been generated that represent normal operation), the program continues with step 105 by determining that the optimum threshold level is the default threshold level.
Again, the program may then end, or continue for another monitored stress metric.
It will be appreciated that, in another embodiment, step 106 may be omitted, so that if step 104 determines that the current threshold is above the default threshold, the program proceeds directly to step 107 and determines that the current threshold does not need to be changed.
Returning now to the situation in which Events are present, i.e. step 103 determines that there was at least one logged Event for the relevant monitored stress metric in the selected time interval.
The program proceeds with step 108 which considers whether there are five or more Events. The integer five is employed in the preferred embodiment as the number of Events which would be expected in a typical 7-day time interval for a network operating normally. However, it will be appreciated that this number is arbitrary and other numbers may be used depending upon the selected time interval and the nature of the stress metric. Typically, for a 7-day time interval, integer values between 3 and 7 may be used, and for other time intervals the number calculated on a pro rata basis.
If step 108 determines that there are fewer than five Events for the monitored metric, this suggests that the network is operating normally and, whilst problems have arisen, the number of occasions is not significant and represents normal network behaviour. This current threshold is likely to be optimal, and, accordingly, in some embodiments the program may simply proceed with step 107.
Alternatively, it is possible that the threshold has been set too low, therefore highlighting situations that should not need attention. Thus, in accordance with the preferred embodiment shown in FIG. 2, the program continues with step 106, as described above, to ensure that the current threshold is within appropriate parameters (i.e. above the minimum recommended threshold). The optimum threshold is then determined as the default threshold or the current threshold depending upon whether the program proceeds from step 106 to step 105 or step 107 respectively.
If there are five or more Events, this could suggest the network is experiencing severe problems or is under more that average stress. Alternatively is may be that the threshold for the monitored metric is too low, thereby generating Events for monitored values which are normal (i.e. represent low stress).
In order to determine which of these situations has arisen, the program calculates the optimal threshold on the basis of the Events under consideration.
Thus, if step 108 determines that there are at least five Events, the program continues with step 109 which, using the Event data retrieved in step 101, calculates the mean average of all the values of the monitored metric which caused the Events. In particular, using the Event data, the program adds together the values of all the Events for the monitored metric and divides the resulting sum by the number of Events determined in step 102. It will be appreciated that other statistical techniques for calculating a statistical average may be employed e.g. a median average may be calculated.
At step 110 the program adds to the average value, calculated in step 109, a metric-specific percentage, which is illustrated as X % where X is dependent on the monitored metric. If X is not preset, in the preferred embodiment, X=5 by default. Thus, in the default situation, the resulting value is equal to 105% of the average value determined in step 109. It will be appreciated that in other embodiments step 110 may be omitted. In the preferred embodiment, step 110 is employed to filter out minor stress conditions as they occur.
The value calculated in step 110 may be used as the new threshold value to reduce the number of Events logged in the future. However, this value should not be used as a new threshold if the excessive number of Events is not because the current threshold is too low but instead is because all the Events in the time interval concerned are genuine and the network has been experiencing severe problems.
To deal with this, in accordance with the preferred embodiment, the program continues with step 111, which compares the value calculated in step 110 with the maximum recommended threshold for the monitored metric. The maximum recommended threshold is a threshold value which, if exceeded, is likely to prevent genuine Events from being generated and logged. The maximum recommended threshold is typically calculated as the default threshold plus Y% of the default threshold value (e.g. 40-90%), where Y is dependent on the stress metric concerned, and may be laid down by the application vendor along with the percentage value Z and the default threshold value for each stress metric. If no maximum recommended threshold of value for Y is preset, the program of the preferred embodiment uses a default percentage value Y% for all stress metrics (e.g. 50%, so that the maximum recommended threshold=150% of the default value).
If the value calculated in step 110 exceeds the maximum recommended threshold, the program continues with step 112 and determines that the optimum threshold is the maximum recommended threshold (default+Y%).
If the value calculated in step 110 is less than or equal to the maximum recommended threshold, the program continues with step 113 by comparing the value calculated in step 110 with the minimum recommended threshold (Z% of the default as described above).
If step 113 determines that the value calculated in step 110 is less than the minimum recommended threshold, the value is too low, and the program continues to step 114 by determining that the optimum threshold value is the minimum threshold value (Z% of the default threshold).
Alternatively, if step 113 determines that the value calculated in step 110 is greater than or equal to than the minimum recommended threshold, the value calculated in step 110 is within appropriate boundaries, and the program continues to step 115 by determining that the optimum threshold value is the average value+X% as calculated instep 110.
It will be appreciated that various modifications and changes may be made to the described embodiments.
For example, whilst the program of the preferred embodiment retrieves Event data for a preceding predetermined time interval, in other embodiments the program could be run in real time by maintaining a counter for each metric and incrementing the counter by one each time an Event for the metric is generated. Each time the counter is incremented, or each time the counter reaches a value which is a multiple of n, where n is an integer greater than one, the program would then be run to determine a new optimum threshold value.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5434872 *Jul 28, 1992Jul 18, 19953Com CorporationApparatus for automatic initiation of data transmissionUS5471399Aug 17, 1992Nov 28, 1995Hitachi, Ltd.Network management system and network status display methodUS5615323Mar 12, 1996Mar 25, 1997Concord Communications, Inc.Displaying resource performance and utilization informationUS5696486Nov 16, 1995Dec 9, 1997Cabletron Systems, Inc.Method and apparatus for policy-based alarm notification in a distributed network management environmentUS5732094 *Sep 16, 1996Mar 24, 19983Com CorporationMethod for automatic initiation of data transmissionUS5751964Sep 12, 1995May 12, 1998International Business Machines CorporationSystem and method for automatic determination of thresholds in network managementUS5819028Apr 16, 1997Oct 6, 1998Bay Networks, Inc.Method and apparatus for determining the health of a networkUS5828830Oct 30, 1996Oct 27, 1998Sun Microsystems, Inc.Method and system for priortizing and filtering traps from network devicesUS5923247Dec 22, 1995Jul 13, 1999British Telecommunications Public Limited CompanyFault monitoringUS6040834Dec 31, 1996Mar 21, 2000Cisco Technology, Inc.Customizable user interface for network navigation and managementUS6147974 *Feb 27, 1998Nov 14, 2000Kokusai Denshin Denwa Co., Ltd.Apparatus for monitoring state of traffic in telecommunication networkUS6167032 *Nov 7, 1997Dec 26, 2000International Business Machines CorporationSystem and method for avoiding host transmit underruns in a communication networkUS6438184 *Jan 12, 1999Aug 20, 2002Sunnyvale Micro Devices, Inc.Apparatus and method for adjusting an input gain and comparator threshold value within an access identifier interval on a telephone line mediumEP0515296A1Apr 30, 1992Nov 25, 1992International Business Machines CorporationProcess and apparatus for managing network event countersEP0849910A2Aug 4, 1997Jun 24, 1998Northern Telecom LimitedCommunications network monitoringEP1065894A1Jun 29, 1999Jan 3, 2001Lucent Technologies Inc.Event notification in a network management systemGB2271918A Title not availableGB2286317A Title not availableGB2333672A Title not availableGB2350035A Title not availableGB2362061A Title not availableGB2362062A Title not availableWO1994019888A1Feb 25, 1994Sep 1, 1994Cabletron Systems, Inc.Method and apparatus for resolving faults in communications networksWO1996004755A1Jul 25, 1995Feb 15, 1996British Telecommunications Public Limited CompanyApparatus for managing a telecommunications networkWO1997031451A1Feb 21, 1997Aug 28, 1997Mci Communications CorporationNetwork management systemWO1998019470A1Oct 14, 1997May 7, 1998British Telecommunications Public Limited CompanyTraffic control in a communications networkWO2000013373A1Aug 27, 1999Mar 9, 2000Green Cathedral LimitedComputer network information use monitoringWO2000047003A1Jan 27, 2000Aug 10, 2000Mpath Interactive, Inc.Method, system and computer program product for adaptive loggingWO2000072514A1Apr 28, 2000Nov 30, 2000Telefonaktiebolaget L M Ericsson (Publ)Method and apparatus for displaying information in a fault management system* Cited by examinerNon-Patent CitationsReference1Decker et al., "Definitions Of Managed Objects For Bridges", RFC: 1493, Jul. 1993, pp. 1-34. </STEXT>2Decker et al., "Definitions Of Managed Objects For Bridges", RFC: 1493, Jul. 1993, pp. 1-34.3IEEE Standard For Information Technology, "Part 2: Logical Link Control", 802.2, 1998, pp. i-239. </STEXT>4IEEE Standard for Information Technology, "Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 802.3, 2000, pp. i-1515. </STEXT>5IEEE Standard For Information Technology, "Part 2: Logical Link Control", 802.2, 1998, pp. i-239.6IEEE Standard for Information Technology, "Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 802.3, 2000, pp. i-1515.7Lenoir et al., "Real-Time Transmission Network Management and Operation Support System", Commutation & Transmission, vol. 12, No. 3, 1990, pp. 87-98. </STEXT>8Lenoir et al., "Real-Time Transmission Network Management and Operation Support System", Commutation & Transmission, vol. 12, No. 3, 1990, pp. 87-98.9McCloghrie et al., "Management Information Base For Network Management Of TCP/IP-Based Internets: MIB-II", RFC:1213, Mar. 1991, pp. 1-70. </STEXT>10McCloghrie et al., "Management Information Base For Network Management Of TCP/IP-Based Internets: MIB-II", RFC:1213, Mar. 1991, pp. 1-70.11McMaster et al., "Definitions Of Managed Objects For IEEE 802.3 Repeater Devices", RFC: 1516, Sep. 1993, pp. 1-40. </STEXT>12McMaster et al., "Definitions Of Managed Objects For IEEE 802.3 Repeater Devices", RFC: 1516, Sep. 1993, pp. 1-40.13S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC 1757, Feb. 1995, pp. 1-91. </STEXT>14S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC:1271, Nov. 1991, pp. 1-81. </STEXT>15S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC:2021, Jan. 1997, pp. 1-104.</STEXT>16S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC 1757, Feb. 1995, pp. 1-91.17S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC:1271, Nov. 1991, pp. 1-81.18S. Waldbusser, "Remote Network Monitoring Management Information Base", RFC:2021, Jan. 1997, pp. 1-104.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS6810367 *Aug 8, 2002Oct 26, 2004Agilent Technologies, Inc.Method and apparatus for responding to threshold events from heterogeneous measurement sourcesUS7272648 *Mar 14, 2002Sep 18, 2007Fujitsu LimitedNetwork monitoring device and methodUS7325060Mar 15, 2004Jan 29, 2008Micrel, Inc.Management system for hardware network devicesUS7373402 *Aug 19, 2002May 13, 2008Agilent Technologies, Inc.Method, apparatus, and machine-readable medium for configuring thresholds on heterogeneous network elementsUS7680921 *Sep 10, 2003Mar 16, 2010Hitachi, Ltd.Management system, management computer, managed computer, management method and programUS8082506 *Aug 12, 2004Dec 20, 2011Verizon Corporate Services Group Inc.Geographical vulnerability mitigation response mapping systemUS8091130Aug 12, 2004Jan 3, 2012Verizon Corporate Services Group Inc.Geographical intrusion response prioritization mapping systemUS8266270 *Jul 16, 2002Sep 11, 2012At&T Intellectual Property I, L.P.Delivery performance analysis for internet servicesUS8418246Dec 28, 2006Apr 9, 2013Verizon Patent And Licensing Inc.Geographical threat response prioritization mapping system and methods of useUS8572734Mar 7, 2007Oct 29, 2013Verizon Patent And Licensing Inc.Geographical intrusion response prioritization mapping through authentication and flight data correlationUS8621076Aug 15, 2012Dec 31, 2013At&T Intellectual Property I, L.P.Delivery performance analysis for internet servicesUS8631493Jul 10, 2006Jan 14, 2014Verizon Patent And Licensing Inc.Geographical intrusion mapping system using telecommunication billing and inventory systemsUS8799446 *Aug 18, 2006Aug 5, 2014Microsoft CorporationService resiliency within on-premise productsUS8990696Dec 22, 2010Mar 24, 2015Verizon Corporate Services Group Inc.Geographical vulnerability mitgation response mapping systemUS9008617Dec 28, 2006Apr 14, 2015Verizon Patent And Licensing Inc.Layered graphical event mappingUS9124473Jul 25, 2013Sep 1, 2015At&T Intellectual Property I, L.P.Delivery performance analysis for Internet servicesUS20030014481 *Jan 31, 2002Jan 16, 2003Hitachi, Ltd.Management system and method for sharing operating informationUS20030110252 *Dec 7, 2001Jun 12, 2003Siew-Hong Yang-HuffmanEnhanced system and method for network usage monitoringUS20040030537 *Aug 8, 2002Feb 12, 2004Barnard David L.Method and apparatus for responding to threshold events from heterogeneous measurement sourcesUS20040034704 *Aug 19, 2002Feb 19, 2004Connelly Stephen P.Method, apparatus, and machine-readable medium for configuring thresholds on heterogeneous network elementsUS20040107278 *Sep 10, 2003Jun 3, 2004Hitachi, Ltd.Management system, management computer, managed computer, management method and programUS20050204027 *Mar 15, 2004Sep 15, 2005Claseman George R.Management system for hardware network devicesUS20060253907 *Jul 10, 2006Nov 9, 2006Verizon Corporate Services Group Inc.Geographical intrusion mapping system using telecommunication billing and inventory systemsUS20070112512 *Jul 11, 2006May 17, 2007Verizon Corporate Services Group Inc.Methods and systems for locating source of computer-originated attack based on GPS equipped computing deviceUS20070152849 *Mar 7, 2007Jul 5, 2007Verizon Corporate Services Group Inc.Geographical intrusion response prioritization mapping through authentication and flight data correlationUS20070186284 *Dec 28, 2006Aug 9, 2007Verizon Corporate Services Group Inc.Geographical Threat Response Prioritization Mapping System And Methods Of UseUS20080046552 *Aug 18, 2006Feb 21, 2008Microsoft CorporationService resiliency within on-premise productsUS20080162556 *Dec 28, 2006Jul 3, 2008Verizon Corporate Services Group Inc.Layered Graphical Event MappingUS20110093786 *Dec 22, 2010Apr 21, 2011Verizon Corporate Services Group Inc.Geographical vulnerability mitgation response mapping system* Cited by examinerClassifications U.S. Classification340/506, 370/252, 340/511International ClassificationH04Q3/00, H04L12/26Cooperative ClassificationH04Q3/0087, H04L43/16European ClassificationH04L43/16, H04Q3/00D4TLegal EventsDateCodeEventDescriptionJul 2, 2001ASAssignmentOwner name: 3COM CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRANDIN, RONAN FRANCOIS DANIEL;STEVENSON, DAVID JAMES;GRAY, ANDREW HUNTER;AND OTHERS;REEL/FRAME:011960/0364Effective date: 20010509Apr 16, 2007FPAYFee paymentYear of fee payment: 4Jul 6, 2010ASAssignmentOwner name: HEWLETT-PACKARD COMPANY, CALIFORNIAFree format text: MERGER;ASSIGNOR:3COM CORPORATION;REEL/FRAME:024630/0820Effective date: 20100428Jul 15, 2010ASAssignmentOwner name: HEWLETT-PACKARD COMPANY, CALIFORNIAFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE SEE ATTACHED;ASSIGNOR:3COM CORPORATION;REEL/FRAME:025039/0844Effective date: 20100428Apr 14, 2011FPAYFee paymentYear of fee payment: 8Dec 6, 2011ASAssignmentOwner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXASFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:027329/0044Effective date: 20030131May 1, 2012ASAssignmentOwner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXASFree format text: CORRECTIVE ASSIGNMENT PREVIUOSLY RECORDED ON REEL 027329 FRAME 0001 AND 0044;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:028911/0846Effective date: 20111010May 22, 2015REMIMaintenance fee reminder mailedOct 14, 2015FPAYFee paymentYear of fee payment: 12Oct 14, 2015SULPSurcharge for late paymentYear of fee payment: 11Nov 9, 2015ASAssignmentOwner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXASFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001Effective date: 20151027RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services