Source: http://www.google.com/patents/US20070088972?dq=4316055
Timestamp: 2014-10-24 09:38:44
Document Index: 615785425

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No, 60', 'art 200']

Patent US20070088972 - Automatic monitoring method for managed server health - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically...http://www.google.com/patents/US20070088972?utm_source=gb-gplus-sharePatent US20070088972 - Automatic monitoring method for managed server healthAdvanced Patent SearchPublication numberUS20070088972 A1Publication typeApplicationApplication numberUS 11/610,667Publication dateApr 19, 2007Filing dateDec 14, 2006Priority dateFeb 22, 2002Also published asUS7233989, US20030225880Publication number11610667, 610667, US 2007/0088972 A1, US 2007/088972 A1, US 20070088972 A1, US 20070088972A1, US 2007088972 A1, US 2007088972A1, US-A1-20070088972, US-A1-2007088972, US2007/0088972A1, US2007/088972A1, US20070088972 A1, US20070088972A1, US2007088972 A1, US2007088972A1InventorsRahul Srivastava, Ananthan Srinivasan, Eric Halpern, Dean JacobsOriginal AssigneeBea Systems, Inc.Export CitationBiBTeX, EndNote, RefManReferenced by (6), Classifications (6) External Links: USPTO, USPTO Assignment, EspacenetAutomatic monitoring method for managed server healthUS 20070088972 A1Abstract A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security. Images(6) Claims(14)
CLAIM OF PRIORITY This application is a continuation of U.S. patent application Ser. No. 10/339,469, entitled �METHOD FOR AUTOMATIC MONITORING OF MANAGED SERVER HEALTH,� by Rahul Srivastava, et al., filed Jan. 9, 2003, which claims priority to U.S. Provisional Patent Application No. 60/359,009, entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION,� by Rahul Srivastava, et al., filed Feb. 22, 2002, which applications are incorporated herein by reference. CROSS REFERENCE TO RELATED APPLICATIONS The present application is related to the following United States Patents and Patent Applications, which patents/applications are assigned to the owner of the present invention, and which patents/applications are incorporated by reference herein in their entirety: U.S. patent application Ser. No. 10/338,981, entitled �METHOD FOR EVENT TRIGGERED MONITORING OF MANAGED SERVER HEALTH,� filed on Jan. 9, 2003, now U.S. Pat. No. 7,152,185, issued Dec. 19, 2006, which claims priority to U.S. Provisional Patent Application No. 60/359,009, entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION,� filed on Feb. 22, 2002; U.S. patent application Ser. No. 10/339,144, entitled �SYSTEM FOR MONITORING MANAGED SERVER HEALTH,� filed on Jan. 9, 2003, currently pending, which claims priority to U.S. Provisional Patent Application No. 60/359,009, entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION,� filed on Feb. 22, 2002; U.S. patent application Ser. No. 10/340,496, entitled �METHOD FOR INITIATING A SUB-SYSTEM HEALTH CHECK,� filed on Jan. 10, 2003, currently pending, which claims priority to U.S. Provisional Patent Application No. 60/359,010, entitled �SERVER SELF-HEALTH MONITOR,� filed on Feb. 22, 2002; U.S. patent application Ser. No. 10/340,227, entitled �METHOD FOR MONITORING A SUB-SYSTEM HEALTH,� filed on Jan. 10, 2003, currently pending, which claims priority to U.S. Provisional Patent Application No. 60/359,010, entitled �SERVER SELF-HEALTH MONITOR,� filed on Feb. 22, 2002; and U.S. patent application Ser. No. 10/340,002, entitled �SYSTEM FOR MONITORING A SUBSYSTEM HEALTH,� filed on Jan. 10, 2003, currently pending, which claims priority to U. S. Provisional Patent Application No, 60/359,010, entitled �SERVER SELF-HEALTH MONITOR,� filed on Feb. 22, 2002.
DETAILED DESCRIPTION A selfhealth monitoring system may be composed of several nodes. A node may be a single physical machine or take some other form. In one embodiment of the present invention, each node has a Node Manager (NM), an Administration Server (AS), and several other managed servers or server instances. The AS and NM may send and transmit messages to each other. The NM may also send and transmit messages with the other servers located on the node. In one embodiment, the NM performs two primary functions. First, the NM automatically detects and restarts failed servers. The NM continually monitors servers running on the local machine. Upon detecting a server has failed, the NM will automatically restart the failed server. The server restart may occur as soon as the NM detects the server failure. Secondly, the NM periodically monitors and restarts failed or degenerate servers. The NM will periodically monitor servers running on the local machine. When the NM detects that a server is less than healthy, the NM may restart the server depending on server parameters and the condition of the server. In one embodiment, runtime java MBeans hosted on the AS are used in conjunction with the NM to achieve these functions. The runtime java MBeans offer the functionality of the NM and the health information acquired by the NM to clients in a programmatic manner. FIG. 1 depicts a self health monitoring system 100 in accordance with one embodiment of the present invention. As shown, system 100 includes a first node 10, a second 20, and a third node 30. Each node may contain an AS 11, 21, and 31, and an NM 12, 22, and 32, respectively. In each node, the AS communicates with the NM. In one embodiment of the present invention, the AS and the NM communicate through a (SSL) secure socket layer connection. Each node also contains at least one managed server. In one embodiment, these managed servers may be composed of server instance processors or logic servers all located on one hardware machine. Hereinafter, the term �server� shall be understood to include server instance processors, server instance logic, and other managed servers. A node may be one physical machine with servers that communicate with other servers on the same machine. As shown in FIG. 1, node 10 includes servers 13-15, node 20 includes servers 23-25, and node 30 includes servers 33-35. An NM may communicate with the servers within the particular NM's node. For example, NM 12 can communicate with servers 13, 14, 15, all within node 10. In one embodiment, the NM communicates with the servers within its node through a secure socket layer connection. In accordance with one embodiment of the present invention, the operation of an automatic monitoring system for detecting failed servers in the selfhealth monitoring system of FIG. 1 is shown in flow chart 200 of FIG. 2 and described as follows. The operation of an NM starts at step 205. Next, the NM undergoes start-up and configuration operations in step 210. In one embodiment of the present invention, the NM receives instructions from an AS at start-up. The AS may instruct the NM to start an instance on a local machine. The AS may also instruct the NM to provide information to the AS regarding servers previously monitored during previous monitoring periods by the NM. The NM may assume that all of the monitored servers are alive upon NM startup and sets each server state to �unknown.� In step 220, the NM begins monitoring a server. In one embodiment, the server is monitored over an SSL connection established with the server. In another embodiment, the server is monitored over a plain text protocol connection or some other type of connection. The NM determines if a server has failed in step 230. In one embodiment, the server failure is detected by a breakdown of the connection between the NM and the server. In these embodiments, the NM monitors the server by confirming the integrity of the connection between the NM and the server. When the server being monitored dies, the NM is notified accordingly. In one embodiment, the NM receives an IOException error when the server dies. The integrity of the connection may also be verified in other ways, all considered within the scope of the invention. If the NM does not detect a failed server, operation of the system returns to step 220 to continue monitoring the server. If the NM does detect a failed server in step 230, the NM will determine if the server is restartable in step 240. In one embodiment, a restart parameter specifies whether the server should be restarted upon detecting a server failure. The restart parameter may reside on the server, the NM, or in some other memory location. The parameter may be defined per server instance or for a number of servers. The parameter may also be modifiable at runtime though commands issued through the AS. If the server is not restartable, operation continues to step 250 and the server is not restarted. In one embodiment, a message is written to a log file indicating that the server is not restartable and no further action is taken by the NM towards the failed server. Once the event is recorded, the process ends at step 260 and the NM ceases monitoring the failed server. Though no further action is performed on the server at step 260, the server may be monitored again beginning at step 220 if the server is restarted or at step 205 if the NM is restarted. If the server is deemed restartable in step 240, operation of the system continues to step 270. At step 270, the system checks to confirm that no other conditions exist to prevent the server from being restarted. If at step 270 any conditions exist preventing a server restart, then system operation proceeds to step 275. In step 275, an action or inaction is taken to address the condition that is preventing the server from being restarted. The action or inaction may be taken by either the NM, AS, or some other server. After the condition is addressed in step 275, the system determines whether the condition is satisfied in step 280. If the condition is not satisfied in step 280, operation returns to step 275. If the condition is satisfied in step 280, operation continues to step 270. In one embodiment of the present invention, operation continues from step 275 to step 270 whether the condition is satisfied or not. In yet another embodiment of the present invention, the NM will check to see if the server may be restarted after each time a restart is considered in step 270. In this embodiment (not shown), operation continues from step 275 or step 280 to step 240. In any case, the results of step 280 may be recorded in a log or memory as either condition satisfied, condition not satisfied, or some other message. If at step 270 the conditions are satisfied, then operation continues to step 290. In one embodiment, system conditions may exist at step 270 that limit the server to a maximum number of restarts allowed during a period of time. In this case, parameters may control the maximum number of server restarts permitted within the period of time and the length of the time period. The number of actual restarts for a particular server may be indicated by a restart counter. If at step 270, the value in the maximum restarts allowed parameter is larger than the restart counter, then the maximum number of restarts has not occurred during the current time period and the process continues to step 290. If the restart counter value is larger than the maximum number of server restarts permitted within the particular time period, then operation continues to step 280. Operation of the system may remain at step 280 until the current time period has elapsed. Once the time period has elapsed, the restart counter is reset to zero and the time period begins again. The system then continues to step 270. At step 270, the restart counter is again compared to the maximum number of restarts parameter and operation continues accordingly. In another embodiment, system operation will continue past step 280 even though the maximum start parameter has been exceeded. In this case, a message is logged regarding this event and operation continues. System operation in this embodiment will consist of a loop between step 270 and step 280 until the time period has elapsed and the restart counter is reset to zero. At step 290, the server is restarted. Then, the NM, server, or AS may perform actions or process events. In one embodiment, the server restart counter is incremented. In another embodiment, certain server parameters may be configured to take effect upon the next server incarnation. Parameters determine how a NM is to act upon detecting server failure. Examples of these parameters in one embodiment of the present invention are shown below. These parameters can be defined per server instance and modified at runtime via the Admin Console. AutoRestartEnabled=<true|false>
If Servers are restartable, this parameter specifies the max # times a Server can be started within the period specified by RestartIntervalSeconds. In one embodiment, the default is 2. Certain methods implemented in java may be used to access or modify the parameter examples listed above. Examples of these methods include boolean getAutoRestartEnabled( ), void setAutoRestartEnabled(boolean), int getRestartIntervalSeconds( ), void setRestartIntervalSeconds (int), int getRestartMax( ), and void setRestartMax(int). In addition to detecting the failure of a server, the NM may monitor the health of a server or perform maintenance on a server. The NM may monitor server health or perform server maintenance without detecting a change or degradation in the health status of the server. Server maintenance and monitoring may be performed simultaneously on multiple servers at any time. The simultaneous monitoring and maintenance may be synchronous or asynchronous. The operation of a system for monitoring the health of a server with a NM in accordance with one embodiment of the present invention is shown in diagram 300 of FIG. 3 and described as follows. Health monitoring system operation 300 starts off with a start step 310. Next, the system determines whether the NM should begin monitoring a server in step 320. If the system determines the NM should monitor the particular server, operation continues to step 330. If the system determines the particular server should not be monitored at the current time, the NM will not monitor the current server. In one embodiment, a server will not be monitored until a period of time has passed since the server has been restarted. In this case, a monitor delay parameter will determine the period of time the NM shall wait before monitoring the restarted server. The delay parameter may be stored by the AS, NM, or the server itself. The delay parameter may correspond to a particular server or several servers. In one embodiment of the present invention, the value of the delay parameter may be modified at server runtime. Next, the NM determines if a health check is triggered for a particular server in operation 330. A health check may be triggered by an internal event in the NM. In another embodiment, the health check is triggered by an external event occurring outside the NM, the occurrence of which is communicated to the NM. In one embodiment, a health check is triggered for a server after a period of time has elapsed. In this case, a health check interval parameter may specify a period of time. The expiration of the time period specified by the interval parameter will trigger a health check for a server. In one embodiment, an interval parameter corresponds to a single server. In another embodiment, an interval parameter corresponds to several servers. In any case, the interval parameter may be modified at server runtime. If a health check is not triggered in step 330, the system continues in a standby state waiting for a triggering event to occur regarding a particular server. If a health check triggering event does occur, system operation continues to step 340. In step 340, the NM queries a server for its health status. In one embodiment of the present invention, the NM invokes a java servlet located on the server to return the server's health status to the NM. This java servlet is an asynchronous servlet that will return the server's health information upon the occurrence of a particular event. In one embodiment, the event is the elapse of a period of time. The NM may inquire about the server's health status by communicating with the server itself or a server self health monitor application running on the server. The query may be transmitted over a TCP connection established between the NM and server or in some other manner. After querying the server for its health status, the NM determines if a response is received from the server in step 350. In one embodiment, there are at least three possible response scenarios between the NM and the server subject to the NM's inquiry. In the first scenario, the server may be unable to receive the NM's query. The server may be too busy to accept a connection from the NM. In another scenario, the server may have failed and be unable to accept an NM connection request. In either case, the NM may throw an IOException and consider the server as �failed.� The NM would then set an internal value of the server state to �failed.� In the final scenario, no response is received from the server although the NM and server have established an initial connection. In this case, the NM will wait for a response from the server for a specified period of time. In one embodiment, a timeout parameter may specify the period of time the NM will wait for a response from the server. Until the length of time specified in the timeout parameter has transpired, the NM will continue to wait for a response as indicated in the loop of steps 350 and 360. If the NM has not received a response from the server in step 350 and the NM has determined not to wait any longer to receive a response in operation 360, operation continues to step 370 where the server is deemed failed. In one embodiment, the NM may attempt to inquire about the delay of the response or resend a health inquiry to the server before proceeding from to 370. In this embodiment, the NM may proceed to step 350, 360, or 380 depending on the result of the delay inquiry or the health inquiry. If the NM does receive a response in step 350, operation flows to step 380 where the NM interprets the server's response. The NM interprets the server's response to determine if the server is healthy. If the NM determines the server is healthy from the response received by the server, operation flows to step 330 where the NM waits for another health check to be triggered. If the NM determines that the server is not healthy in step 380, operation continues to step 370. In step 370, the NM deems the server has failed. In one embodiment, the NM sets a parameter indicating the state of the particular server to �failed.� The parameter may be stored internally within the NM, in the AS, or at some other memory location. Once deemed failed, operation continues to step 390 where the NM determines whether to terminate the server. In one embodiment, the NM contains an auto-terminate parameter. The auto-terminate parameter may relate to a single server or multiple servers at once. A user may set a value for the auto-terminate parameter or the parameter may be preset by the system. If the auto-terminate parameter indicates the server should not be terminated upon server failure, then operation continues to step 396. In one embodiment of the present invention, the system enters a message in a log indicating the failed status of the server and that the server is not to be restarted. After step 396, system operation proceeds to step 330. If the auto-terminate parameter indicates the server should be terminated upon server failure in step 390, then operation continues to step 392. The failed server is terminated in step 392. In one embodiment of the present invention, an entry is made to a log indicating the server is deemed failed and that the server was terminated. Monitoring of the terminated server ends in step 394. Once the server is terminated, the automatic detection system of FIG. 1 may detect the terminated server at step 230. The NM may then proceed to determine whether to restart the server as shown in FIG. 1. In one embodiment of the present invention, certain parameters will control how the server periodically checks the servers running on the local machine. Examples of parameters controlling the check are shown below. HealthCheckIntervalSeconds=<number of seconds>
The time that a server takes to startup depends upon the applications being deployed on it. The NM will wait for a server to complete its startup before the NM starts monitoring the server. This parameter specifies the length of time (in seconds) the NM will wait before starting its monitoring of the server. In one embodiment, the default is 120 seconds. The HealthCheckIntervalSeconds and HealthCheckTimeoutSeconds and parameters can be defined per NM and on the NM command line. The AutoKillIfFailedEnabled and HealthCheckStartDelaySeconds parameters can be defined per server instance and can be modified at runtime via the Admin Console. These new parameters for the Server will be modifiable at runtime via the Admin Console. In conjunction with the parameter examples above, methods implemented in java code can be added to the server MBean and may be used to access or modify the parameters. Examples of these java methods include boolean getAutoKillIfFailedEnabled( ), void setAutoKillIfFailedEnabled(boolean), int getHealthCheckStartDelaySeconds( ), and void setHealthCheckStartDelaySeconds (int secs). In one embodiment, the NM may allow its functionality and access to server health information to become available to external administrative clients. External administrative clients such as third party application monitors and high availability frameworks may need to be able to start and kill servers using the functionality of the NM. In one embodiment of the present invention, this is done programmatically with runtime MBeans. Use of an admin console is not required. The MBeans provide a programmatic interface to the NM's functionality. Further, the MBeans allow the NM's record of a server's health to be shared. Internal or external administrative clients may use the MBeans to access server health information collected by the NM. In one embodiment, the AS hosts [one]a NodeManagerRuntime MBean that provides methods to accomplish different tasks. Each machine may have one such MBean. [One task may involve starting a specified server.] In one embodiment, the AS may have methods according to the examples shown below. java.io.reader start(serverMBean server) throws NodeManagerException; This method starts the specified server. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.reader starInStandby (serverMBean server) throws NodeManagerException; This method starts the specified server in Standby Mode. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.Reader shutdown (ServerMBean server) throws NodeManagerException; This method shuts down the specified server. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.reader kill(ServerMBean server) throws NodeManagerException; This method kills specified server. It is used to kill the server process when the server does not respond to shutdown operation. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.reader startMonitoring (ServerMBean server) throws NodeManagerException; This method instructs the NM to start monitoring the specified server. The NM will automatically restart the server if it crashes (if auto restartEnabled is set to true) or gets into failed state (if AutoKillIfFailedEnabled and AutoRestartEnabled are set to true). It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.reader stopmonitoring (serverMBean server) throws NodeManagerException; This method instructs the NM to stop monitoring the specified server. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. java.io.Reader getlogs(ServerMBean server, String type) throws NodeManagerException; This method gets logs from the NM for the specified server. The type is either �WL_output� or �WL_Error.� It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. string get state (ServerMBean server) throws NodeManagerException; This method queries the NM for its view of the specified server state. It is used when the server does not respond to queries to its ServerRuntimeMBean. The method will return �unknown� if NM is either not monitoring the server or does not have any knowledge of the server. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs. In another embodiment, MBeans may provide an interface for JMX clients to access the functionality of the NM. In this case, the MBeans for JMX client interfacing may have a different interface than the Server configuration MBeans. Operations such as �start� and �shutdown� may return precise information on their success or failure. They will throw an exception if the operation fails. All operations on the Node Manager Runtime MBeans may be blocking. A TaskMBean interface may be provided around the Server Lifecycle MBeans to provide an asynchronous interface to JMX clients. JMX clients can make use of the NM functionality to perform a wide variety of Server lifecycle and health monitoring control operations. Detailed below are the interactions between these two entities during each of the Server Lifecycle state transitions. Admin console, weblogic.Admin command line utility and other Admin Clients will be effecting these state transitions by invoking methods on the ServerLifecycleRuntimeMBean. start( ) [SHUTDOWN->RUNNING]
This argument specifies the Admin Server password. Must be specified if WebLogic.nodemanager.enableChannelBinding is set to 1. In one embodiment, an alternate NM may have features in addition to those described above. In particular, the alternate NM may function to aggregate administrative actions and information in the NM. The actions and information could then be accessed by third party application monitors and high availability frameworks using standard JMX interfaces. The NM may also achieve internal interactions with the admin console and cluster group leader using standard JMX interfaces. In one embodiment, certain services are required by the administrator for the alternate NM to operate properly. One such service is a ProcessControl (�PC�) service. The PC service operates to start, kill and restart managed servers on the local node. The service can be hosted by the AS and by the NM on the other nodes. Restart capability is provided to internal and external clients via Runtime MBeans. Another service is the HealthMonitoring (�HM�) service. The HS service monitors state and other runtime attributes of managed servers on local or remote nodes. Either the AS or an individual NM can host the HM service. Server health information is provided to internal and external clients via Runtime MBeans. The alternate NM has several advantageous characteristics. In one embodiment, some aspects of the configuration for the alternate NM are similar to the basic NM of the present invention. The alternate NM may be hosted on a stripped-down managed server. In this case, the alternate NM registers as a managed server with the AS. With this configuration, the NM performs startup independently of the AS. Further, no configuration MBeans are required for runtime configuration changes The alternate NM may include a �watchdog� service. The watchdog service operates to monitor the NM on platforms where operating system monitoring is not available, such as non-NT and Solaris platforms. The watchdog service may be configured to spawn the NM when it performs startup, thereby allowing administrators to manually start just one process. In one embodiment, a system could use a watchdog service to bootstrap the NM service on a local node upon command of an AS. This watchdog service configuration would eliminate manual configuration of the NM on each remote node and allow runtime configuration through configuration MBeans implemented in java. For Solaris and NT systems, the NM may be used as the operating system in one embodiment of the present invention. In this case, the NM may be installed on a node in conjunction with other software and can be started manually. The alternate NM can be configured to enable its operation to enhance aspects of an entire domain or local node. One NM could be used for an entire domain. This would simplify security in that multiple certificates would not need to be managed. In one embodiment, the NM is the highest release. The alternate NM may be used to aggregate cluster heartbeats for all cluster members on a local node. The cluster members may include managed servers on the local node. The alternate NM may also be configured to operate as a surrogate AS. The present invention includes a Node Manager that monitors the status of multiple servers. The NM detects server failures, periodically monitors server health status, and performs server maintenance. When the NM detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the NM may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The NM may be controlled by an AS directly or by an external administrative agent. An administrative agent may control the NM by interfacing with the AS. The NM and AS may authenticate each other and encode their communications to each other for increased security. An Appendix is attached to this application containing examples within the scope and spirit of the present invention. In addition to an embodiment consisting of specifically designed integrated circuits or other electronics, the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art. The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, and user applications. Ultimately, such computer readable media further includes software for implementing Node Managers. Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to, separating planes of a source image, averaging at least one of foreground and background colors, replacing colors, and compensating for error introduced by color replacement in one plane by feeding error into a second plane, storage, communication of results, and reconstructing an image according to the processes of the present invention. Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims. The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to the practitioner skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7392421 *Mar 18, 2002Jun 24, 2008Symantec Operating CorporationFramework for managing clustering and replicationUS7392433 *Jan 25, 2005Jun 24, 2008International Business Machines CorporationMethod and system for deciding when to checkpoint an application based on risk analysisUS8073806 *Oct 17, 2007Dec 6, 2011Avaya Inc.Message log analysis for system behavior evaluationUS8135980 *Dec 23, 2008Mar 13, 2012Unisys CorporationStorage availability using cryptographic splittingUS8201016 *Jun 28, 2007Jun 12, 2012Alcatel LucentHeartbeat distribution that facilitates recovery in the event of a server failure during a user dialogUS20130283347 *Apr 20, 2012Oct 24, 2013Cisco Technology, Inc.Scalable replay counters for network security* Cited by examinerClassifications U.S. Classification714/4.11, 714/E11.186International ClassificationG06F11/32, G06F11/00Cooperative ClassificationG06F11/326European ClassificationG06F11/32S2ERotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google