Methods and systems to minimize the number of messages transmitted between a client and a server in a client-server network. The messages may be error messages, and may be associated with a log such as an error log. The client requests permission of the server to transmit a message(s) to the server. Upon receipt of the request, the server provides the client with a filter, which may include a filter table with a filter parameter(s). The server may provide the filter in real time and/or without the client or server having to go off-line. The client uses the filter to filter at least a selected message from the message(s). Once the client has filtered the selected message the client transmits the selected message and/or the associated log of the selected message to the server.
|
2. A method to minimize the number of messages transmitted between a client and a server, the method comprising:
causing a client to request permission of a server to transmit at least a message from messages to the server;
in response to receipt of the request, causing the server to provide the client with a filter;
in response to receiving the filter, causing the client to use the filter to filter at least a selected message from the messages; and
causing the client to transmit the selected message to the server,
whereby the number of messages transmitted between the client and the server is minimized to the selected message based on the filter provided by the server to the client and used by the client to filter the selected message from the messages.
13. A system that minimizes the number of messages transmitted from a client to a server, the system comprising:
a client operative to request permission of the server to transmit at least a message from messages to the server;
a server operative, in response to receipt of the request, to provide a client with a filter; and
the client being also operative, in response to receiving the filter, to use the filter to filter at least a selected message from the messages and to transmit the selected message to the server,
whereby the number of messages transmitted between the client and the server is minimized to at least a selected message based on the filter provided by the server to the client and used by the client to filter at least a selected message from the messages.
1. A method to minimize the number of error messages transmitted between a client and a server, the method comprising:
causing a client to request permission of a server to transmit at least an error message from error messages to the server, wherein the error messages are associated with an error log;
in response to receipt of the request, causing the server to provide the client with a filter, wherein the filter comprises
a time stamp and
a filter table, having at least a filter parameter;
in response to receiving the filter, causing the client to use the filter to filter at least a selected error message from the error messages, wherein the selected error message is associated with a selected error log; and
causing the client to transmit the selected error log to the server,
whereby the number of error messages transmitted between the client and the server is minimized to the selected error message based on the filter provided by the server to the client and used by the client to filter the selected error message from the error messages.
10. The method of
20. The system of
|
The inventions generally relate to client-server networks, and particularly, to the filtering of messages in a client-server network.
In data communications, the term “client-server network” generally relates to a single-system integration of elements that share workload or that distribute workload. Generally, the “network” of a client-server network is a local area network (LAN) used to link computers, peripheral devices, or other elements or systems under some form of standard control. The “server” of a client-server network, typically, is the computer in the network that performs the bulk of centralized or generalized tasks. A “client” is an element in the network that may request information from or otherwise may use the resources of the server.
A client and a server communicate through the exchange of messages. There are many different types of messages. One type of message that may be exchanged between a client and a server is an error message. There are different kinds of error messages in a client-server network. One kind of error message is an error message that is passed from a client to a server.
A client may send an error message to the server after the error message is generated. Alternatively, a client may collect error messages in a log. At some point, the client may transmit the log including the collected error messages to the server.
At the server, the error messages in the transmitted log may be retrieved. Some client-server networks include a filter at the server to filter the error messages, typically, based on some selected feature of an error message such as urgency or source. In use, a filter may be applied at the server to the error messages of the transmitted log. The error messages retrieved through use of a filter may be referred to as filtered error messages. The retrieval of error messages through use of a filter at a server is referred to as the “filter-server system”.
Conveniently, a filter-server system allows for the retrieval at the server of filtered error messages. Among the drawbacks of the filter-server system is the drawback referred to as “over-transmission”. The over-transmission drawback stems from the fact that, in the filter-server system, all of the error messages in a log at the client are transmitted to the server prior to the filtering of the error messages. In other words, every single error message in the log is transmitted by the client to the server. But all of the error messages may not be ultimately retrieved at the client. Thus, the transmission of all of the error messages from the client to the server is an over-transmission of messages.
The over-transmission of error messages is not only unnecessary, but undesirable. In fact, the over-transmission of error messages adds unnecessary, and therefore, extraneous traffic to the network. Extraneous traffic negatively burdens the network such as through a slow-down in overall message transmission or even a slow-down of network operation. Extraneous traffic is particularly undesirable in a client-server network including many clients. Each additional client multiplies the extraneous traffic on the network, and therefore, unnecessarily burdens the network.
To avoid the over-transmission drawback posed by the filter-server system, a different system referred to as the “filter-client system” has been used. As the term implies, in a filter-client system, each of the clients in the client-server network is provided with a filter. Generally, the filter is provided by the server to the clients. The client applies the filter to the error messages in a log to obtain filtered error messages. The client then sends the filtered error messages to the server. By filtering the error messages at the client, the filter-client system avoids the over-transmission drawback because only the filtered error messages are transmitted from the client to the server. The error messages that fail to pass the filter at the client are not transmitted to the server.
Even though the filter-client system avoids the over-transmission drawback, the filter-client system has other drawbacks. One drawback is the “filter-decision” drawback. As explained, in the filter-client system, a client filters the error messages into filtered error messages, which are then transmitted to the server. Thus, the decision of whether an error message is a “filtered error message” is made at the client rather than at the server. One result of making the filter-decision at the client rather than at the server is that the error messages may be filtered incorrectly or may not be filtered as desired by the server. The server may receive extraneous error messages. In addition, the server may fail to receive desired error messages because such messages failed to pass the filter-decision at the client. Thus, filtering the error messages at a client, rather than at a server, takes the control of such decision making away from the server, and as a result, the error messages may not be filtered according to the desires of the server.
As noted, often a filter is provided from a server to each of its clients. In the case of a server providing the filter, the filter-decision drawback may appear to be avoided. The drawback may appear to be avoided because the server provides the filter for the decision making to each of the clients. If the client uses the filter provided by the server, then the server should, at least in theory, receive the error messages the server desires as filtered error messages.
Even when the server provides the client with the filter, the filter-decision drawback may not be completely avoided because of the passage of time and the events that may happen during that time passage. For example, assume a server provides its clients with a filter so error messages having a specific characteristic are passed to the server as filtered error messages. With the passage of time, the server may require error messages having a different characteristic as filtered error messages. Yet, the filter at each client continues to filter the error messages based on the specific characteristic rather than the different characteristic. As a result, the server may receive unnecessary, and therefore extraneous error messages. So, the client-server network may experience the over-transmission problem described above in connection with a filter-server system. Also as a result, the server may fail to receive its desired messages as filtered error messages.
The obvious solution to the filter-decision drawback may be for the server to send a new filter to its clients whenever there are changes required by the server in the filtering of error messages. This solution may be referred to as the “new filter” solution. For example, assume the server has sent a filter A to all of its clients. Time passes, and then the server requires error messages having different characteristics. The server sends another filter, a filter B, to all of its clients. Thereafter, the clients use the filter B to filter the error messages.
But the new filter solution has its own drawbacks. For example, in some cases, a client must be taken off the network or even shut-down in order to receive a new or changed filter. Obviously, taking a client off-line or shutting it down to accomplish the filter change may negatively affect the performance of the overall network as well as the client. If all of the clients have to be taken off-line or shut down for the filter change, the whole network may be negatively affected.
The drawbacks and problems discussed above have referred to error messages, but the drawbacks and problems also may apply to other types of information exchanged between a client to a server in a client-server network. These drawbacks and problems may especially apply if there is any type of filtering of information transmitted from a client to a server.
In sum, there is a need in client-server networks for improved methods and systems relating to the exchange of information between a client and a server in such networks. Particularly, there is a need for improved methods and systems that provide for the transmission of messages from a client to a server, and specifically, for the filtering of the messages so that only filtered messages are transmitted from the client to the server. Even more particularly, there is a need for improved methods and systems that accomplish the filtering of the messages at the client based on filter characteristics desired by the server. Finally, there is a need for improved methods and systems that accomplish the desired filtering without the need to take clients off-line or to shut them down or to otherwise burden the network.
As a result, per the present inventions, only filtered messages are transmitted from the client to the server. Moreover, the client filters the messages based on filter characteristics desired by the server. Further, the desired filtering is accomplished without the need to take a client off-line or to shut a client down or to otherwise burden the network.
The methods and systems according to the present inventions overcome the drawbacks of the prior art. The inventions described herein minimize the number of messages transmitted between a client and a server. The number of messages are minimized by causing the client to filter the messages using a filter updated as necessary via updated filters received from the server. The client may then transmit selected messages to the server. The methods and systems according to the present invention transmit a copy of the filter from the server to the client only when necessary so as to reduce the overall traffic on the client-server network. Moreover, the filtering of messages at the client may be based on filter characteristics desired by the server. Additionally, the methods and systems according to the present inventions may minimize the number of messages transmitted between a client and a server without the need to take clients off-line or to shut them down or to otherwise burden the network.
Stated generally, the present invention discloses methods and systems for minimizing the number of messages that are transmitted from a client to a server in a client-server network without discarding the messages requested by the server. More specifically, the present invention discloses a method to minimize the number of messages transmitted between a client and a server in a client-server network. The messages may be error messages, and may be associated with a log such as an error log. The client requests permission of the server to transmit a message(s) to the server. Upon receipt of the request, the server provides the client with a filter, which may include a filter table with a filter parameter(s). The server may provide the filter in real time and/or without the client or server having to go off-line. The client uses the filter to filter at least a selected message, which may be associated with a selected log, from the message(s). Once the client has filtered the selected message the client transmits the selected message and/or the selected log associated with the selected message to the server.
The present invention further discloses a system to minimize the number of messages transmitted between a client and a server in a client-server network. The messages may be error messages, and may be associated with a log such as an error log. The client is operative to request permission of the server to transmit messages to the server. Upon receipt of the request, the server is operative to provide the client with a filter which may include a filter table with a filter parameter(s). The client is also operative to use the filter to filter at least a selected message, which may be associated with a selected log, from the messages. The client is further operative to transmit the selected message and/or the selected log associated with the selected message to the server.
The present invention also discloses a method to minimize the number of error messages transmitted between a client and a server in a client-server network. The client requests permission of the server to transmit an error message(s) to the server. The error message(s) may be associated with a log such as an error log. Upon receipt of the request, the server provides the client with a filter. The filter may include a time stamp and a filter table with a filter parameter(s). The client uses the filter to filter at least a selected error message, which may be associated with a selected error log, from the error message(s). Once the client has filtered the selected error message the client transmits the selected error message and/or the selected error log of the selected message to the server.
Advantageously, the methods and systems according to the present invention accord filtering decisions to the server while creating the selected error log within the client. In addition, the present inventions allow the server to update the filter and provide the updated filter to the client in real time, without having to shut down any portion of the client-server network.
These and other features and advantages of the methods and systems according to the present invention may be more clearly understood and appreciated from a review of the following detailed description of the preferred embodiments and by reference to the appended drawings and claims.
The methods and systems according to the present inventions contemplate interaction of a server and one or more clients within a client-server network. The “client-server” of a client-server network may refer to a hardware configuration, to a software configuration, or to a combination thereof.
A “client” in a hardware configuration generally is a computer such as a personal computer (PC), intelligent device, or workstation used by a user. In use, the client may carry-out tasks in the process of which the client may request information or otherwise may use the resources of another object such as the server to accomplish such tasks.
A “server” in a hardware configuration generally also is a computer such as a personal computer (PC) or other intelligent device. A server typically performs the bulk of centralized or generalized task in the network and often has more memory, processing speed, and storage than other devices on the client-server network. Alternatively, the server may perform specialized tasks such as distributing electronic mail or printing.
In the software arrangement, a “server” typically is a program that provides data, stores data, or provides some service to other programs to which the server is connected. A server may be a program with higher priority, greater memory, or greater capabilities compared to the other programs connected through the network. A server also may be a program that includes specialized capabilities or has higher priority with respect to certain tasks or functions.
A “client” in the software arrangement generally is a program used by a user. A client program typically makes use of data, processing, storage, or other resources of another program. A client may be used to communicate with a source or destination through a higher priority, more powerful, more capable or different program.
Any given device or program may be capable of acting as a client and/or a server depending on the role the device or program plays based on the nature of the connection between the device or program and other elements. In other words, rather than a specific type of device or program, the terms “client” and “server” refer to the role a device or program performs during a specific connection or communication with another device, program or element.
An Exemplary Computing Environment—
The application program may include routines, programs, components, data structures, etc. that implement certain abstract data types, perform certain tasks, actions, or tasks. In a distributed computing environment, the application program (in whole or in part) may be located in local memory, or in other storage. In addition, or in the alternative, the application program (in whole or in part) may be located in remote memory or in storage to allow for the practice of the inventions where tasks are performed by remote processing devices linked through a communications network.
The PC 20 also may include a plurality of drives interconnected to other elements of the PC 20 through the system bus 24 (or otherwise). Exemplary drives include a hard disk drive 42, a magnetic disk drive 44, and an optical disk drive 46. Specifically, each disk drive may be connected to the system bus 24 through an appropriate interface (respectively, a hard disk drive interface 48, a magnetic disk drive interface 50, and an optical drive interface 52). Further, the PC 20 may include non-volatile storage or memory through the drives and their associated computer-readable media. For example, the magnetic disk drive 44 allows for the use of a magnetic disk 54; and the optical disk drive 46 allows for the use of an optical disk 56. Other types of media that are readable by a computer, e.g., magnetic cassettes, digital video disks, flash memory cards, ZIP cartridges, JAZZ cartridges, etc., also may be used in the exemplary operating environment.
In addition, the PC 20 may include a serial port interface 58 connected to the system bus 24. The serial port interface 58 connects to input devices that allow commands and information to be entered. These input devices may include a keyboard 60, a mouse 62, and/or other input device. Pens, touch-operated devices, microphones, joysticks, game pads, satellite dishes, scanners, etc. also may be used to enter commands and/or information. The input devices also may be connected by other interfaces, such as a game port or a universal serial bus (USB). Further, the PC 20 may include a monitor or other display screen 66. The monitor 66 is connected through an interface such as a video adaptor 68 to the system bus 24. The PC 20 may include other peripheral and/or output devices, such as speakers or printers (not illustrated).
The PC 20 may be connected to one or more remote computers 70, and may operate in a network environment. The remote computer 70 may be a PC, a server, a router, a peer device or other common network node, and may include many or all of the elements described in relation to the PC 20. The connection between the PC 20 and the remote computer 70 may be through a local area network (LAN) 72 and/or a wide area network (WAN) 74. The PC 20 is connected to the LAN 72 through a network interface 76. With respect to the WAN 74, the PC 50 may include a modem 78 or other device to channel communications over the WAN 74, or global data communications network (e.g., the Internet). The modem 78 (internal or external) is connected to the system bus 24 via the serial port interface 58. The network connections illustrated in
An Exemplary Embodiment—
The server 82, in an exemplary embodiment of the invention, includes a filter control 86 and a filter 88. The filter control 86 manages the creation and modification of the filter 88 and may be located within the server 82 or accessible to the server 82. The filter 88 governs the filtering of error messages by clients 84a-n, and particularly, within error logs 92a-n located, respectively, in the clients 84a-n. In particular, the server's filter 88 may be set by the filter control 86 to hold or pass error messages having a certain characteristic or feature. The error messages that pass through the filter are referred to herein as selected error messages. The error messages that do not pass through the filter (for failure to include the certain characteristic or feature or otherwise) generally are held or discarded, and therefore may be referred to as discarded error messages.
More particularly, the filter 88 may utilize filtering parameters, features or characteristics to filter error messages by date, time, type of error. For example, the filter 88 may filter an error log 92n for error messages that indicate program errors. As an alternative, the filter may be set so that error messages may be retrieved in some specific order, or only some of the error messages may be retrieved such as retrieval of only those error messages having a certain characteristic. The filter 88 may be set to retrieve only error messages having a specific feature or characteristic in common. For example, the filter 88 may be set to check each of the error messages of a log for a level of urgency, and pass only the error messages having the highest level of urgency.
Generally, the filter 88 may be updated or changed from time to time by the filter control 86 so the filter 88 is set to pass error messages having a different and/or additional characteristic(s) or feature(s). References herein to “changing a filter” relate to the changing of the filtering parameters, characteristic(s), or feature(s) reviewed or used by the filter (or copies of the filter or updated filters at the clients) and that allow an error message to pass through the filter or to be held or blocked by the filter. A filter 88 may be changed by the filter control 86 generally at any time and for a variety of reasons. For example, the filter 88 may be updated periodically or whenever the network administrator desires to receive different types of error messages.
An error message that is passed from a client to a server is a message about an error. Examples of the kinds of errors that may occur in a client include: run-time errors, program errors, network errors, stack errors, and/or input-output errors.
Also illustrated in
The error logs 92a-n are used to keep a record of error messages associated with the errors that occur within the clients 84a-n. An error log 92a-n may be a table, a record, a database, or a storage device. For example, the error log 92a may be a database that records the time, date, location and error message associated with each error. The error logs 92a-n may be included in the clients 84a-n or accessible to the clients 84a-n. The error logs 92a-n do not necessarily store all error messages. The error logs may store one or more types of error messages. Further, the error logs 92an may possess information to access the error messages rather than to store the error messages.
Actions of an Exemplary Embodiment—
Still referring to
Subsequent to the server receiving the request from the client, the server transmits a copy of the filter to the client in action 280. The filter in the server may contain a time stamp. The time stamp of the filter in the server indicates when the filter in the server was created, last updated or changed by the filter control. In other words, the filter in the server is the “most recent” or “most up-to-date” filter and is marked as such by its time stamp. As with the time stamp in the client, the server time stamp may or may not include a time, and/or may include other information to distinguish the server filter.
Advantageously, the efficiency of the network is increased because the server does not transmit a copy of the filter until a filter is needed by the client. Moreover, network traffic is reduced because the server does not transmit filters that may become obsolete before being used by the client.
In action 290, after receiving the copy of the filter, the client utilizes the copy of the filter to filter the error messages in the error log. The error messages that pass the filter are selected error messages. Subsequent to filtering the error messages in the error log, the client transmits the selected messages in the filtered error log, herein also referred to as the selected error log, to the server in action 300. In alternate embodiments, the messages may not be associated with a log. Thus, the client utilizes the copy of the filter to filter a selected message(s) from the messages and subsequently transmits the selected message(s) to the server. Thereafter, the method of an exemplary embodiment of the present invention ends at action 310.
In an alternative embodiment, the methods and systems according to the invention may be initiated by a request for the error log received by a client from the server or network administrator. The request to the client from the server may include a copy of the filter at the server. The copy of the filter may include updated filtering parameters. Thus, the client may be provided with a copy of the filter without having requested permission of the server to transmit the error log. For example, a network administrator may desire to investigate an error(s) occurring at a client to determine why the particular client is often not actively connected to the rest of the network, referred to as being “off-line.” Thus the network administrator may investigate the errors by having the server provide a copy of the filter to the particular client and requesting the particular client to filter the error log using the copy of the filter.
The methods and systems according to the present inventions are not restricted to error logs and may be applied to the logging of any type of information. For example, the methods and systems of the present inventions may be utilized by a corporation with a headquarters in one city and satellite offices in different cities across the country. The server may be located at the headquarters with clients located in the satellite offices. In this example, the corporation may be planning to add hyperlinks to the corporate intranet homepage for frequently visited intranet sites. The clients at the satellite offices may maintain a log that records every internet or intranet site accessed by computers at the satellite site.
In this example, the required event is set to equal every midnight. Therefore, at midnight, the client requests permission of the server to send the log of internet and intranet sites. The request for permission includes a time stamp indicating when the copy of the filter stored within the client was last updated.
When the server at the headquarter receives the request, the server compares the time stamp in the request against the time stamp of the filter stored within the server. If the filter in the server postdates the copy of the filter in the client, the server sends the client in the satellite office an updated filter. The updated filter replaces the existing copy of the filter stored in the client. Thus, the satellite office has the most recent copy of the filter from headquarters.
The client in the satellite office may then use the filtering parameters from the updated filter to filter the log of internet and intranet sites. The filtering parameters within the updated filter may indicate which internet and intranet sites should be discarded or kept. In this example, the filtering parameters within the updated filter instruct the client to filter out all of the internet sites, leaving only the intranet sites. The client in the satellite office may then transmit the log of intranet sites to the server in the headquarters. A network administrator may then review the log of intranet sites sent by the client to determine the most frequently visited intranet sites.
Additional information relating to centrally-controlled client-side filtering may be found in the commonly-owned United States patent application entitled “Methods and Systems for Transmitting Messages with Centrally-Controlled Client-Side Filtering” concurrently filed on May 9, 2002 in the USPTO with this application and assigned Patent Application Ser. No. 10/143,302.
The exemplary embodiments of the present invention were chosen and described above in order to explain the principles of the invention and their practical applications so as to enable others skilled in the art to utilize the invention including various embodiments and various modifications as are suited to the particular use contemplated. The examples provided herein in the written descriptions or in the drawings are not intended as limitations of the present invention. Other embodiments will suggest themselves to those skilled in the art. For example, the log may be utilized to store many different types of information, including but not limited to network error information, client error information or internet usage information. Therefore, the scope of the present invention is to be limited only by the claims below.
Perrella, Ronald, Zhou, Gaiye, Thobe, Steve
Patent | Priority | Assignee | Title |
10171289, | Sep 11 2013 | International Business Machines Corporation | Event and alert analysis in a distributed processing system |
10678621, | Oct 03 2017 | ServiceNow, Inc | System error codes for edge encryption |
7451349, | Apr 16 2004 | HONG FU JIN PRECISION INDUSTRY SHENZHEN CO , LTD ; HON HAI PRECISION INDUSTRY CO , LTD | System and method for automatically testing motherboards |
7529979, | Dec 12 2003 | International Business Machines Corporation | Hardware/software based indirect time stamping methodology for proactive hardware/software event detection and control |
7599934, | Sep 27 2005 | Microsoft Technology Licensing, LLC | Server side filtering and sorting with field level security |
7734961, | May 01 2007 | TWITTER, INC | Distributed logging apparatus system and method |
7908524, | Mar 15 2005 | Fujitsu Limited | Storage medium readable by a machine tangible embodying event notification management program and event notification management apparatus |
8156384, | Aug 06 2008 | SIEMENS HEALTHINEERS AG | Communications administration method and system for an electronic apparatus |
8195985, | Mar 19 2009 | Fujitsu Limited | Network monitor and control apparatus |
8499203, | May 24 2011 | International Business Machines Corporation | Configurable alert delivery in a distributed processing system |
8560689, | Nov 02 2010 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8621277, | Dec 06 2010 | International Business Machines Corporation | Dynamic administration of component event reporting in a distributed processing system |
8627154, | Dec 06 2010 | International Business Machines Corporation | Dynamic administration of component event reporting in a distributed processing system |
8639980, | May 26 2011 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8645757, | May 26 2011 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8660995, | Jun 22 2011 | International Business Machines Corporation | Flexible event data content management for relevant event and alert analysis within a distributed processing system |
8676883, | May 27 2011 | International Business Machines Corporation | Event management in a distributed processing system |
8688769, | Oct 18 2011 | International Business Machines Corporation | Selected alert delivery in a distributed processing system |
8689050, | Jun 22 2011 | International Business Machines Corporation | Restarting event and alert analysis after a shutdown in a distributed processing system |
8713366, | Jun 22 2011 | International Business Machines Corporation | Restarting event and alert analysis after a shutdown in a distributed processing system |
8713581, | Oct 27 2011 | International Business Machines Corporation | Selected alert delivery in a distributed processing system |
8730816, | Dec 07 2010 | International Business Machines Corporation | Dynamic administration of event pools for relevant event and alert analysis during event storms |
8737231, | Dec 07 2010 | International Business Machines Corporation | Dynamic administration of event pools for relevant event and alert analysis during event storms |
8756462, | May 24 2011 | International Business Machines Corporation | Configurable alert delivery for reducing the amount of alerts transmitted in a distributed processing system |
8805999, | Dec 07 2010 | International Business Machines Corporation | Administering event reporting rules in a distributed processing system |
8825852, | Nov 02 2010 | International Business Machines Corporation | Relevant alert delivery in a distributed processing system |
8863018, | Jan 29 2007 | Johnson Controls Technology Company | System and method for filter creation and use for building automation systems |
8868984, | Dec 07 2010 | International Business Machines Corporation | Relevant alert delivery in a distributed processing system with event listeners and alert listeners |
8868986, | Dec 07 2010 | International Business Machines Corporation | Relevant alert delivery in a distributed processing system with event listeners and alert listeners |
8880943, | Jun 22 2011 | International Business Machines Corporation | Restarting event and alert analysis after a shutdown in a distributed processing system |
8880944, | Jun 22 2011 | International Business Machines Corporation | Restarting event and alert analysis after a shutdown in a distributed processing system |
8887175, | Oct 18 2011 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8893157, | Oct 18 2011 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8898299, | Nov 02 2010 | International Business Machines Corporation | Administering incident pools for event and alert analysis |
8914667, | Jul 27 2011 | Pure Storage, Inc | Identifying a slice error in a dispersed storage network |
8943366, | Aug 09 2012 | International Business Machines Corporation | Administering checkpoints for incident analysis |
8954811, | Aug 06 2012 | International Business Machines Corporation | Administering incident pools for incident analysis |
9086968, | Sep 11 2013 | GLOBALFOUNDRIES Inc | Checkpointing for delayed alert creation |
9170860, | Jul 26 2013 | International Business Machines Corporation | Parallel incident processing |
9178936, | Oct 18 2011 | International Business Machines Corporation | Selected alert delivery in a distributed processing system |
9178937, | Oct 18 2011 | International Business Machines Corporation | Selected alert delivery in a distributed processing system |
9201756, | May 27 2011 | International Business Machines Corporation | Administering event pools for relevant event analysis in a distributed processing system |
9213621, | May 27 2011 | International Business Machines Corporation | Administering event pools for relevant event analysis in a distributed processing system |
9246865, | Oct 18 2011 | International Business Machines Corporation | Prioritized alert delivery in a distributed processing system |
9256482, | Aug 23 2013 | International Business Machines Corporation | Determining whether to send an alert in a distributed processing system |
9286143, | Jun 22 2011 | International Business Machines Corporation | Flexible event data content management for relevant event and alert analysis within a distributed processing system |
9329984, | Jan 23 2014 | Nvidia Corporation | Methods and systems for monitoring and logging software and hardware failures |
9344381, | May 27 2011 | International Business Machines Corporation | Event management in a distributed processing system |
9348687, | Jan 07 2014 | International Business Machines Corporation | Determining a number of unique incidents in a plurality of incidents for incident processing in a distributed processing system |
9361184, | May 09 2013 | International Business Machines Corporation | Selecting during a system shutdown procedure, a restart incident checkpoint of an incident analyzer in a distributed processing system |
9389943, | Jan 07 2014 | International Business Machines Corporation | Determining a number of unique incidents in a plurality of incidents for incident processing in a distributed processing system |
9419650, | Jun 22 2011 | International Business Machines Corporation | Flexible event data content management for relevant event and alert analysis within a distributed processing system |
9602337, | Sep 11 2013 | International Business Machines Corporation | Event and alert analysis in a distributed processing system |
9658902, | Aug 22 2013 | GLOBALFOUNDRIES U S INC | Adaptive clock throttling for event processing |
Patent | Priority | Assignee | Title |
4047977, | May 04 1972 | Nippon Steel Corporation | Method of continuous galvanizing steel strip on partial or one side |
6314533, | Sep 21 1998 | Microsoft Technology Licensing, LLC | System and method for forward custom marshaling event filters |
20010025278, | |||
20020124214, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Aug 07 2002 | PERELLA, RONALD | Bellsouth Intellectual Property Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013383 | /0061 | |
Aug 18 2002 | THOBE, STEVEN J | Bellsouth Intellectual Property Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 013383 | /0061 |
Date | Maintenance Fee Events |
Sep 30 2008 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 25 2013 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Apr 04 2013 | ASPN: Payor Number Assigned. |
Apr 04 2013 | RMPN: Payer Number De-assigned. |
Jan 26 2017 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Aug 02 2008 | 4 years fee payment window open |
Feb 02 2009 | 6 months grace period start (w surcharge) |
Aug 02 2009 | patent expiry (for year 4) |
Aug 02 2011 | 2 years to revive unintentionally abandoned end. (for year 4) |
Aug 02 2012 | 8 years fee payment window open |
Feb 02 2013 | 6 months grace period start (w surcharge) |
Aug 02 2013 | patent expiry (for year 8) |
Aug 02 2015 | 2 years to revive unintentionally abandoned end. (for year 8) |
Aug 02 2016 | 12 years fee payment window open |
Feb 02 2017 | 6 months grace period start (w surcharge) |
Aug 02 2017 | patent expiry (for year 12) |
Aug 02 2019 | 2 years to revive unintentionally abandoned end. (for year 12) |