Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0803—Configuration setting
  • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/085—Retrieval of network configuration; Tracking network configuration history
  • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
  • H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0866—Checking the configuration
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0751—Error or fault detection not based on redundancy
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/06—Management of faults, events, alarms or notifications
  • H04L41/0681—Configuration of triggering conditions

Definitions

• the present invention relates generally to causal analysis in computers and, more particularly, cause analysis involving configuration changes for finding a solution to an application failure by analyzing configuration changes without using a knowledge database.
• One of the most stressful jobs for administrators of the desktop computing environment is the cause analysis in the case where trouble occurs (trouble shooting).
• the causal analysis is also critical for the helpdesk person who needs to provide the solution to the caller.
• End users tend to install many kinds of software or change OS settings that might cause the problems.
• the configuration of the computer can be changed without the end user's awareness. Thus, the end user does not know when the configuration became faulty and may not remember when the problem began.
• Paragraph 0134 discloses collecting the time series data of error log, event information, and configuration change from target monitoring computers.
• Paragraph 0137 and Figs.16, 17, and 18 disclose comparing error situation on target computer with that in the past data.
• Examples of collecting the event log remotely include U.S. Pat.
• the administrator or help desk person needs a kind of knowledge to provide a solution by reviewing the event log, configuration change history, application invocation history, or the like.
• the knowledge can be obtained from a knowledge database which presents "Cause” and "Solution” written by someone. Because someone needs to maintain the knowledge database up to date, it requires a maintenance cost.
• Exemplary embodiments of the invention provide a technique to determine which configuration changes caused the problem without the need for a knowledge database. Therefore, this invention does not provide the root cause but the "final straw” that needs to be removed (i.e., the final answer). The invention provides a direct way to address the problem that is solution- oriented rather than "root cause"-oriented.
• the end user makes an inquiry.
• the help desk starts analyzing.
• the first step is to detect the target period.
• a cause analysis program detects the last success of application invocation and the first failure of application invocation based on both the event log and the application invocation history.
• configuration change detection the configuration changes are determined by combining the configuration change history with the results of the target period detection. These configuration changes might affect the application invocation. One of these configuration changes will be the final straw.
• the next step is to check other computers. To determine which configuration change is the most likely cause, the cause analysis program checks other computers that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer.
• the program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.
• the cause analysis program then displays the result. The result of the analysis is shown in the form of ranking with charts. The help desk can answer the question as to which configuration change is the most susceptible.
• This invention does not use any knowledge database written by humans. It does not seek to find the root cause, because even if the user knew the root cause, the user might not know how to fix it easily. Instead, the invention identifies the final straw. What the user should do is to remove the final straw. It is more effective for the user to fix the problem than to be told what the root cause is.
• An aspect of the present invention is directed to a method of cause analysis for a target computer of a plurality of computers, the target computer having experienced an application invocation failure of a computer application at a first failure time and an application invocation success of the computer application at a first success time prior to the first failure time, without any other application invocation success and without any other application invocation failure of the computer application in a first time period between the first success time and the first failure time (see, e.g., FIG. 14).
• the method comprises (1 ) identifying one or more first configuration changes that occurred during the first time period of the computer application; and (2) performing at least one of causal configuration change analysis (A) or fixing configuration change analysis (B).
• the analysis (A) includes, for every other computer of the plurality of computers other than the target computer, identifying other application invocation failure instances in which said every other computer has experienced an application invocation success of the same computer application at a second success time and an application invocation failure of the same computer application at a second failure time after the second success time, without any other application invocation success and without any other application invocation failure of the same computer application in a second time period between the second success time and the second failure time, and identifying one or more second configuration changes that occurred during the second time period, and obtaining a total causal configuration change count for each of the one or more second configuration changes by summing for all the plurality of computers other than the target computer (see, e.g., FIG. 17).
• the analysis (B) includes, for every other computer of the plurality of computers other than the target computer, identifying application invocation success instances in which said every other computer has experienced an application invocation failure of the same computer application at a third failure time and an application invocation success of the same computer application at a third success time after the third failure time, without any other application invocation success and without any other application invocation failure of the same computer application in a third time period between the third failure time and the third success time, and identifying one or more third configuration changes that occurred during the third time period, and obtaining a total fixing configuration change count for each of the one or more third configuration changes by summing for all the plurality of computers other than the target computer (see, e.g., FIG. 19).
• Another aspect of the invention is directed to a system of cause analysis which has a plurality of computers including a target computer, and an analysis computer connected with the plurality of computers.
• the analysis computer is programmed to perform steps (1 ) and (2) above.
• the analysis computer is one of the plurality of computers (see, e.g., FIG. 25).
• Another aspect of the invention is directed to a computer- readable storage medium storing a plurality of instructions for controlling a data processor to perform steps (1 ) and (2) above.
• the method further comprises, presenting results for at least one of causal configuration change results (A1 ) or fixing configuration change results (B1 ).
• the method comprises, for each of the one or more second configuration changes, listing a number of application failure invocation instances identified for said every other computer, and a number of all instances involving each of the one or more second configuration changes for said every other computer (see, e.g., FIG. 10).
• step (B1 ) the method comprises, for each of the one or more third configuration changes, listing a number of application success invocation instances identified for said every other computer, and a number of all instances involving each of the one or more third configuration changes for said every other computer (see, e.g., FIG. 12).
• steps (1 ) and (2) are carried out for a plurality of computer applications.
• the method further comprises, for each of the plurality of computer applications, presenting results for at least one of causal configuration change results (A2) or fixing configuration change results (B2).
• step (A2) the method comprises, for each of the one or more second configuration changes, listing a number of application failure invocation instances identified for said every other computer, and a number of all instances involving each of the one or more second configuration changes for said every other computer, and listing an analyzed date and time for each of the plurality of computer applications (see, e.g., FIG. 21 ).
• step (B2) the method comprises, for each of the one or more third configuration changes, listing a number of application success invocation instances identified for said every other computer, and a number of all instances involving each of the one or more third configuration changes for said every other computer, and listing an analyzed date and time for each of the plurality of computer applications.
• the method further comprises, for a specified computer application, performing at least one of a matching causal configuration change analysis (A3) or a matching fixing configuration change analysis (B3).
• step (A3) the method includes searching the results of (A2) for a computer application that matches the specified computer application as matching causal configuration change results, and retrieving the matching causal configuration change results for analysis (see, e.g., FIG. 22).
• step (B3) the method includes searching the results of (B2) for a computer application that matches the specified computer application as matching fixing configuration change results, and retrieving the matching fixing configuration change results for analysis.
• the method further comprises performing at least one of a combination causal configuration change analysis (C) or a combination fixing configuration change analysis (D).
• step (C) the method comprises, for every other computer of the plurality of computers other than the target computer, identifying other application invocation failure instances in which said every other computer has experienced an application invocation success of the same computer application at a fourth success time and an application invocation failure of the same computer application at a fourth failure time after the fourth success time, without any other application invocation success and without any other application invocation failure of the same computer application in a fourth time period between the fourth success time and the fourth failure time, and identifying one or more combinations of fourth configuration changes that occurred during the fourth time period, and obtaining a total causal configuration change count for each of the combinations of fourth configuration changes by summing for all the plurality of computers other than the target computer (see, e.g., FIG.
• step (D) the method comprises, for every other computer of the plurality of computers other than the target computer, identifying application invocation success instances in which said every other computer has experienced an application invocation failure of the same computer application at a fifth failure time and an application invocation success of the same computer application at a fifth success time after the fifth failure time, without any other application invocation success and without any other application invocation failure of the same computer application in a fifth time period between the fifth failure time and the fifth success time, and identifying one or more combinations of fifth configuration changes that occurred during the fifth time period, and obtaining a total fixing configuration change count for each of the one or more fifth configuration changes by summing for all the plurality of computers other than the target computer.
• the method further comprises presenting results for at least one of combination causal configuration change results (C1 ) or combination fixing configuration change results (D1 ).
• step (C1 ) the method includes, for each of the one or more combinations of fourth configuration changes, listing a number of application failure invocation instances identified for said every other computer, and a number of all instances involving each of the one or more combinations of fourth configuration changes for said every other computer.
• step (D1 ) the method includes, for each of the one or more combinations of fifth configuration changes, listing a number of application success invocation instances identified for said every other computer, and a number of all instances involving each of the one or more combinations of fifth configuration changes for said every other computer.
• Another aspect of the invention is directed to a method in a computer system for performing a cause analysis for a target computer of a plurality of computers, the target computer having experienced an application invocation failure of a computer application at a first failure time and an application invocation success of the computer application at a first success time prior to the first failure time, without any other application invocation success and without any other application invocation failure of the computer application in a first time period between the first success time and the first failure time.
• the method comprises presenting a causal configuration changes table listing one or more first configuration changes that occurred during the first time period of the computer application; and a graphical chart corresponding to each first configuration change of the one or more first configuration changes, the graphical chart having a failure rate area and a success rate area.
• the failure rate area shows a representation of failure cases of identifying, for every other computer of the plurality of computers other than the target computer, other application invocation failure instances in which said every other computer has experienced an application invocation success of the same computer application at a second success time and an application invocation failure of the same computer application at a second failure time after the second success time, without any other application invocation success and without any other application invocation failure of the same computer application in a second time period between the second success time and the second failure time.
• a second configuration change identical to the corresponding first configuration change listed on the table occurred during the second time period.
• the success rate area shows a representation of success cases of identifying, for every other computer of the plurality of computers other than the target computer, no other application invocation failure instances in which said every other computer has experienced an application invocation success of the same computer application at a third success time and an application invocation failure of the same computer application at a third failure time after the third success time, without any other application invocation success and without any other application invocation failure of the same computer application in a third time period between the third success time and the third failure time.
• a third configuration change identical to the corresponding first configuration change listed on the table occurred during the third time period.
• the graphical chart comprises a graphical bar chart
• the failure rate area shows at least one of a number of the failure cases or a percentage of the failure cases as compared to a total number of both the failure cases and the success cases
• the failure success area shows at least one of a number of the success cases or a percentage of the success cases as compared to the total number of both the failure cases and the success cases.
• the causal configuration changes table lists a configuration item and a change type of the one or more first configuration changes, a change date and time corresponding to the one or more first configuration changes, and the graphical chart showing the failure rate area and the success rate area.
• the method further comprises presenting a sorting key indicator to a user for sorting the causal configuration changes table according to any one of the configuration item, change type, change date and time, and the failure rate of the graphical chart; and, in response to an input selection of the sorting key indicator by the user, presenting the causal configuration changes table which is sorted according to the input selection by the user.
• FIG. 1 illustrates an example of a hardware configuration for a client-server architecture in which the method and apparatus of the invention may be applied.
• FIG. 2 illustrates an example of a functional block diagram of the invention applied to the architecture of FIG. 1 .
• FIG. 3 shows examples of the relationship between application invocation result and configuration change illustrating the basic ideas of the present invention.
• FIG. 4 shows an example of the user interface of the Cause
• FIG. 5 shows an example of the result screen of the Cause
• FIG. 6 shows an example of the Event Log Table that resides in the analysis computer.
• FIG. 7 shows an example of the Configuration Change History
• FIG. 8 shows an example of the Application Invocation History
• FIG. 9 shows an example of the Causal Configuration Changes
• FIG. 10 shows an example of the Causal Configuration Changes
• FIG. 1 1 shows an example of the Fixing Configuration Changes
• FIG. 12 shows an example of the Fixing Configuration Changes
• FIG. 13 is an example of a flow diagram illustrating log collecting as executed by the Log Collector Program residing in the analysis computer.
• FIG. 14 is an example of a flow diagram illustrating causal analysis as executed by the Cause Analysis Program residing in the analysis computer according to the first embodiment of the invention.
• FIG. 15 is an example of a flow diagram illustrating the target period detection process as executed by the Target Period Detector residing in the analysis computer.
• FIG. 16 is an example of a flow diagram illustrating the application invocation result checking process as executed by the Invocation
• FIG. 17 is an example of a flow diagram illustrating the causal configuration change analysis process as executed by the Causal
• FIG. 18 is an example of a flow diagram illustrating the subroutine of the causal configuration change analysis process of FIG. 17.
• FIG. 19 is an example of a flow diagram illustrating the fixing configuration change analysis process as executed by the Fixing
• FIG. 20 is an example of a flow diagram illustrating the subroutine of the fixing configuration change analysis process of FIG. 19.
• FIG. 21 shows an example of the Causal Configuration Changes
• FIG. 22 is an example of a flow diagram illustrating causal analysis as executed by the Cause Analysis Program according to the second embodiment of the invention.
• FIG. 23 shows an example of the Causal Configuration Changes
• FIG. 24 is an example of a flow diagram illustrating the causal configuration change analysis process as executed by the Causal
• FIG. 25 illustrates an example of a configuration of hardware architecture, software modules, and tables of entire system according to a fourth embodiment of the invention.
• these quantities take the form of electrical or magnetic signals or instructions capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, instructions, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.
• the present invention also relates to an apparatus for performing the operations herein.
• This apparatus may be specially constructed for the required purposes, or it may include one or more general- purpose computers selectively activated or reconfigured by one or more computer programs.
• Such computer programs may be stored in a computer- readable storage medium, such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of media suitable for storing electronic information.
• Exemplary embodiments of the invention provide apparatuses, methods and computer programs for finding a solution to an application failure by analyzing configuration changes without using a knowledge database.
• FIG. 1 illustrates an example of a hardware configuration for a client-server architecture in which the method and apparatus of the invention may be applied.
• An analysis computer 101 and a plurality of target computers 102 are connected through a LAN 103.
• the analysis computer 101 is a generic computer that includes a CPU 1 1 1 , a memory 1 12, a disk 1 13, a video interface 1 14, and a network interface 1 15. Each element is connected through a system bus 1 16.
• the analysis computer 101 has a Cause Analysis Program 121 and a Log Collector Program 122 in its memory 1 12.
• Cause Analysis Program 121 includes a Target Period Detector 131 , a Causal Configuration Changes Analyzer 132, a Fixing Configuration Changes Analyzer 133, and an Invocation Result Checker 134, which are executed by the CPU 1 1 1 .
• the analysis computer 101 has a Causal Configuration Changes Temporary Table 144, a Fixing Configuration Changes Temporary Table 145, a Causal Configuration Changes Table 146, a Fixing Configuration Changes Table 147, and Log Information 123 in its disk 1 13.
• the Log Information 123 includes an Event Log Table 141 , an Application Invocation History Table 142, and a Configuration Change History Table 143.
• the analysis computer 101 has a Network Interface 1 15 that is connected to the LAN 103 and used to collect Log Information 171 from the plurality of target computers 102.
• the display 1 17 is connected to the video interface 1 14 and used to display the user interface of the Cause Analysis Program 121 and the result of causal configuration change analysis by the Cause Analysis Program 121 .
• the target computer 102 is a generic computer that includes a
• the target computer 102 has an agent 161 which sends Log Information 171 to the analysis computer 101 via the LAN 103.
• the target computer 102 has the Log Information 171 in its disk 153.
• the display 157 is connected to the video interface 154.
• FIG. 2 illustrates an example of a functional block diagram of the invention applied to the architecture of FIG. 1 .
• the Log Collector Program 122 resides in the analysis computer 101 and collects the Log Information 171 by communicating with each agent 161 which resides in the target computer 102, and stores the information to the Event Log Table 141 , the Application Invocation History Table 142, and the Configuration Change History Table 143 of the Log Information 123 in the analysis computer 101 .
• the Cause Analysis Program 121 reads the Log Information 123 and executes a causal configuration changes analysis as shown below.
• the Causal Configuration Changes Analyzer 132 checks the Log Information 123 of other computers and stores the result to the Causal Configuration Changes Table 146.
• the Causal Configuration Changes Temporary Table 144 is used as temporary data when the Causal Configuration Changes Analyzer 132 analyzes the causal configuration changes.
• the Fixing Configuration Changes Analyzer 133 detects the fixing configuration change and stores the result to the Fixing Configuration Changes Table 147.
• the Fixing Configuration Changes Temporary Table 145 is used as temporary data when the Fixing Configuration Changes Analyzer 133 analyzes the fixing configuration changes.
• the fixing configuration change is the configuration change which fixes the problem situation such as application invocation failure.
• the Invocation Result Checker 134 is the subroutine that detects whether a specific application could be invoked successfully or not, by referring to both the Event Log Table 141 and Application Invocation History Table 142.
• FIG. 3 shows examples 301 -304 of the relationship between application invocation result and configuration change illustrating the basic ideas of the present invention.
• the diagram 301 shows the situation of the target computer 102 of this causal configuration change analysis.
• four configuration changes happen between successful application invocation and failed invocation. There is no invocation between these configuration changes. Therefore, application invocation failure could be caused by one of these four configuration changes.
• the diagrams 302, 303 and 304 show the other computers' situations that will be used for detailed analysis.
• the same configuration changes happen in another computer A, but neither removing "VPN-CLIENT v1.8" nor adding "VPN-CLIENT v2.0" affects the application invocation. Therefore, the certainty which these two configuration changes affected the application invocation becomes lower.
• adding "PRINTER DRIVER A" and "PATCH-2322” produces a result between SUCCESS and FAILURE. Therefore, the certainty which these two configuration changes affected the application invocation becomes higher.
• FIG. 4 shows an example of the user interface 401 of the Cause
• the user can initiate the analysis by using this user interface 401 .
• the Cause analysis Program User Interface 401 has two text boxes to input the analysis condition. One is the Computer ID 41 1 , which the user can use to specify the identifier of the analysis target computer. The other is the Application Name 412, which the user can use to specify the application name that has a problem. To start the analysis, the user can press the "Start Analyze" button 413.
• FIG. 5 shows an example of the result screen of the Cause
• the column 51 1 shows the configuration item.
• the column 512 shows the change type.
• the column 513 shows the date and time corresponding to configuration change (i.e., 51 1 and 512).
• FIG. 5 shows four configuration change records 521 -524.
• the column 514 shows the graphical bar chart that indicates the certainty corresponding to the configuration change.
• the area 525 indicates the number of the configuration change cases ("PRINTER DRIVER A" - "ADD”) in record 521 which affected the invocation of the specified application in all computers.
• the area 526 indicates the number of the configuration change cases ("PRINTER DRIVER A" - "ADD”) which did not affect the invocation of the specified application in all computers.
• the percentages above the bar chart show the ratios of 525 and 526.
• the symbol 515 is the sorting key indicator. In this example, these configuration changes are shown in the order of the rate (certainty), not counts. This indicator can be moved to other columns by clicking the link (underline) of each column.
• FIG. 5 shows three configuration change records 541 - 543.
• the area 544 indicates the number of the configuration change cases ("PRINTER DRIVER A" - "REMOVE") in record 541 which fixed the invocation failure of the specified application in all computers.
• the area 545 indicates the number of the configuration change cases ("PRINTER DRIVER A” - "REMOVE") which did not fix the invocation failure of the specified application in all computers.
• the percentages above the bar chart show the ratios of 544 and 545.
• the symbol 534 is the sorting key indicator. In this example, these configuration changes are shown in the order of the rate (certainty), not counts.
• FIG. 6 shows an example of the Event Log Table 141 that resides in the analysis computer 101 .
• the event log data in this table is used to determine whether the specified application could be invoked successfully or not.
• the Invocation Result Checker 134 checks the number of events right after the application invocation time. If some events are found within a certain period right after the invocation, the Invocation Result Checker 134 judges that the invocation of the application failed.
• the Event Log Table 141 contains three columns, Computer ID
• FIG. 6 shows event log records 415-417 for Comp-001 , records 421 -422 for Comp-002, record 431 for Comp-003, record 441 for Comp-006, and records 451 -452 for Comp-007, and so on.
• the Event Log Table in each target computer 102 has its own event log data.
• the Event Log Table 141 in the analysis computer 101 has all event log data collected from each target computer 102.
• FIG. 7 shows an example of the Configuration Change History
• Table 143 that resides in the analysis computer 101 .
• the configuration change history data in this table is used to determine what kind of configuration changes were made between successful application invocation and failed invocation, and what kind of configuration changes fixed the failed application invocation.
• the Configuration Change History Table 143 contains four columns: Computer ID 701 , Change Date Time 702, Configuration Item 703, and Change Type 704. The four columns of data are collected from the agent 161 of each target computer 102 and stored to this table by the Log Collector Program 122.
• the table schema of the Configuration Change History Table in each target computer 102 is the same as that of the Configuration Change History Table 143 in the analysis computer 101 in this embodiment.
• the Configuration Change History Table in each target computer 102 has its own configuration change history data.
• the Configuration Change History Table 143 in the analysis computer 101 has all configuration change history data collected from each target computer 102.
• FIG. 7 shows configuration change history records 71 1 -716 for Comp-001 , records 721 -726 for Comp-002, records 731 - 734 for Comp-003, records 741 -743 for Comp-004, records 751 -752 for Comp-005, records 761 -762 for Comp-006, and so on.
• FIG. 8 shows an example of the Application Invocation History
• Table 142 that resides in the analysis computer 101 .
• the application invocation history data in this table is used to determine when the application is invoked before and after the configuration changes.
• This table contains three columns: Computer ID 801 , Invocation Date Time 802, and Application Name 803.
• the three columns of data are collected from the agent 161 of each target computer 102 and stored to this table by the Log Collector Program 122.
• the table schema of the Application Invocation History Table in each target computer 102 is the same as that of the Application Invocation History Table 142 in the analysis computer 101 in this embodiment.
• the Application Invocation History Table in each target computer 102 has its own application invocation history data.
• the Application Invocation History Table 142 in the analysis computer 101 has all application invocation history data collected from each target computer 102.
• FIG. 8 shows application invocation history records 81 1 -820 for Comp-001 , records 821 -822 for Comp-002, records 831 -835 for Comp-003, records 841 -844 for Comp-004, record 851 for Comp-005, and so on.
• FIG. 9 shows an example of the Causal Configuration Change
• Temporary Table 144 that resides in the analysis computer 101 according to a first embodiment of the invention.
• This table is a temporary table when the Cause Analysis Program 121 determines the causal configuration changes.
• This table shows the results of application invocation before and after the configuration changes.
• This table contains six columns: Computer ID 901 , Change Date Time 902, Configuration Item 903, Change Type 904,
• Invocation-Before 905 shows the results of application invocation before the configuration changes.
• the Invocation-After 906 shows the results of application invocation after the configuration changes.
• the records indicate the period from the last successful application invocation to the first failed application invocation. Assume that the value of Computer ID 901 of analysis target computer 102 in FIG. 9 is "Comp-001 .” For example, all values of the pair of Invocation-Before 905 and Invocation- After 906 of the records (91 1 - 914) are SUCCESS and FAILURE, respectively. For the other computers, the records indicate the invocation result of the application before and after the configuration changes which are the same as those of the analysis target computers 102.
• FIG. 9 shows causal configuration change records 91 1 -914 for Comp-001 , records 921 -924 for Comp-002, records 931 -932 for Comp-003, records 941 -942 for Comp-004, records 951 -952 for Comp-005, record 961 for Comp-006, record 971 for Comp-007, and so on.
• FIG. 10 shows an example of the Causal Configuration Changes
• Table 146 that resides in the analysis computer 101 .
• This table is a result table created by the Cause Analysis Program 121 .
• This table shows which configuration change made the application invocation fail and the corresponding certainty.
• This table contains five columns: Configuration Item 1001 , Change Type 1002, Change Date Time 1003, Number of Failure Cases
• the Number of All Cases 1005 indicates the number of all cases for the pair of Configuration Item 1001 and Change Type 1002.
• the Number of Failure Cases 1004 indicates the number of failed cases for the pair of Configuration Item 1001 and Change Type 1002.
• FIG. 10 shows four causal configuration change records 101 1 -1014. For example, in the record 101 1 , the configuration change is "PRINTER DRIVER A - ADD," the Number of Failure Cases 1004 is 12 and the Number of All Cases 1005 is 15.
• FIG. 1 1 shows an example of the Fixing Configuration Changes
• Temporary Table 145 that resides in the analysis computer 101 .
• This table is a temporary table when the Cause Analysis Program 121 determines the fixing configuration changes.
• This table shows the results of application invocation before and after the configuration changes which were made between the invocation failure and the invocation success of the specified application.
• This table contains six columns: Computer ID 1 101 , Change Date Time 1 102, Configuration Item 1 103, Change Type 1 104, Invocation- Before 1 105, and Invocation-After 1 106. The meaning of each column is the same as that of the Causal Configuration Changes Temporary Table 144.
• FIG. 1 1 shows fixing configuration change records 1 1 1 1 -1 1 13 for Comp-001 , record 1 121 for Comp-002, record 1 131 for Comp-003, record 1 141 for Comp-004, and so on.
• FIG. 12 shows an example of the Fixing Configuration Changes
• Table 147 that resides in the analysis computer 101 .
• This table is a result table created by the Cause Analysis Program 121 .
• This table shows which configuration change fixed the failed application invocation and the corresponding certainty.
• This table contains four columns: Configuration Item 1201 , Change Type 1202, Number of Fixing Cases 1203, and Number of All Cases 1204.
• the Number of All Cases 1204 indicates the number of all cases for the pair of Configuration Item 1201 and Change Type 1202.
• the Number of Fixing Cases 1203 indicates the number of fixing cases for the pair of Configuration Item 1201 and Change Type 1202. For example, in the record 121 1 , the configuration change is "PRINTER DRIVER A - ADD," the Number of Fixing Cases 1203 is 29, and the Number of All Cases 1204 is 33.
• FIG. 12 shows fixing configuration change records 121 1 -1213. [0078] 4. Process Flow
• FIG. 13 is an example of a flow diagram illustrating log collecting as executed by the Log Collector Program 122 residing in the analysis computer 101 .
• the Log Collector Program 122 initiates its process periodically in a certain interval. As illustrated in FIG. 13, in step 1301 , the Log Collector Program 122 discovers the target computers for log collecting. In step 1302, the Log Collector Program (122) checks whether all discovered computers are processed or not. If yes, the process ends. If no, the process proceeds to step 1303. In step 1303, the Log Collector Program 122 collects the event log by communicating with the agent 161 residing in the target computer 102. It also updates the Event Log Table 141 in the analysis computer 101 .
• step 1304 the Log Collector Program 122 collects the application invocation history by communicating with the agent 161 residing in target computer 102. It also updates the Application Invocation History Table 142 in the analysis computer 101 .
• step 1305 the Log Collector Program 122 collects the configuration change history by communicating with the agent
• the Log Collector Program 122 ends the process (checked at step 1302).
• FIG. 14 is an example of a flow diagram illustrating causal analysis as executed by the Cause Analysis Program 121 residing in the analysis computer 101 according to the first embodiment of the invention.
• the Cause Analysis Program 121 initiates the process by the user operation on the Cause Analysis Program User Interface 401 .
• the Cause Analysis Program 121 receives the Computer ID 41 1 and Application Name 412 from the Cause Analysis Program User Interface 401 as the parameters.
• the Computer ID is "Comp-001 " and the Application Name is "DOC EDITOR.”
• the Cause Analysis Program 121 initializes temporary tables and result tables (144, 145, 146 and 147).
• step 1403 the Cause Analysis Program 121 invokes the
• Target Period Detector 131 with the values of the Computer ID 41 1 and Application Name 412 as its parameters.
• the result will be stored in Causal Configuration Changes Temporary Table 144.
• the records (91 1 -914) are stored in the Configuration Changes Temporary Table 144.
• the configuration change that caused the application invocation failure might be one of these configuration changes (91 1 -914).
• the Cause Analysis Program 121 invokes the
• step 1405 the Cause Analysis Program 121 invokes the
• FIG. 15 is an example of a flow diagram illustrating the target period detection process as executed by the Target Period Detector 131 residing in the analysis computer 101 .
• the Target Period Detector 131 initiates the process by invocation from the Cause Analysis Program 121 .
• the Target Period Detector 131 receives the Computer ID and Application Name as the parameter.
• the Computer ID is "Comp-001" and the Application Name is "DOC EDITOR.”
• the Target Period Detector 131 extracts the records whose Computer ID is the same as the Computer ID received at Step 1501 from the Configuration Change History Table 143. It sorts the records by the Change Date Time 702 in descending order. As of this step, the records whose Computer ID 701 is "Comp-001 " are extracted (71 1 -716 on the Configuration Change History Table 143).
• step 1503 the Target Period Detector 131 checks whether any records are extracted in step 1502 or not. If yes, the process proceeds to step 1504. If no, the process ends. [0087] In step 1504, the Target Period Detector 131 retrieves one record from the top and reads the values of the Change Date Time 702, Configuration Item 703, and Change Type 704. In the first execution of this loop, the value of the Change Date Time 702 is "06/04/2008 08:20:1 1 ,” the Configuration Item 703 is "PRINTER DRIVER A,” and the Change Type (704) is "ADD.”
• step 1505 the Target Period Detector 131 invokes the
• Step 1501 the Computer ID
• Step 1504 the parameters are "Comp- 001 ,” “DOC EDITOR,” and "06/04/2008 08:20:1 1 .”
• step 1506 the Target Period Detector 131 receives the values of the Invocation-Before and Invocation-After variables as the result of step 1505. The result indicates whether the application could be invoked without any errors before and after the configuration change, or not.
• the Target Period Detector 131 checks the invocation result after the configuration change is SUCCESS, or not. If yes, the process ends. If no, the process proceeds to step 1508. [0091] In step 1508, the Target Period Detector 131 makes a record of the Computer ID 901 , Change Date Time 902, Configuration Item 903, Change Type 904, Invocation-Before 905, and Invocation-After 906. It inserts the record into the Causal Configuration Changes Temp Table 144. As of this step of the first loop, the record 91 1 is stored in the Causal Configuration Change Temporary Table 144.
• step 1509 the Target Period Detector 131 checks whether all records extracted at step 1502 are processed or not. If yes, the process ends. If no, the process returns to step 1504. In this embodiment, after the execution of the Target Period Detector 131 , the records (91 1 -914) are stored in the Configuration Changes Temporary Table 144.
• FIG. 16 is an example of a flow diagram illustrating the application invocation result checking process as executed by the Invocation Result Checker 134 residing in the analysis computer 101 . The Invocation Result Checker 134 initiates the process by invocation from the Target Period Detector 131 , Causal Configuration Changes Analyzer 132, and Fixing Configuration Changes Analyzer 133.
• the Invocation Result Checker 134 receives the Computer ID, Application Name, and Change Date Time as the parameters.
• the Computer ID is "Comp-001 ”
• the Application Name is "DOC EDITOR”
• the Change Date Time is "06/04/2008 08:20:1 1 .”
• step 1602 the Invocation Result Checker 134 gets the application invocation time right before the Change Date Time (step 1601 ) by referring to the Application Invocation History Table 142 for the Computer ID (step 1601 ) and Application Name (step 1601 ).
• the application invocation time of "DOC EDITOR” right before the "06/04/2008 08:20:1 1 " can be found as "06/02/2008 14:26:03" (818) in the Application Invocation History Table 142.
• step 1603 the Invocation Result Checker 134 counts the number of events within a certain time right after the application invocation time (step 1602) by referring to the Event Log Table 141 for the Computer ID (step 1601 ). When the invocation time is "06/02/2008 14:26:03," the number of events within 10 seconds is 0.
• step 1604 the Invocation Result Checker 134 checks the number of events counted in step 1603. If it is greater than 0, the process proceeds to step 1606. Otherwise, the process proceeds to step 1605. In step 1605, the Invocation Result Checker 134 sets SUCCESS to the Invocation-Before variable. Because the number of events is 0, the Invocation-Before variable is set to SUCCESS. In step 1606, the Invocation Result Checker 134 sets FAILURE to the Invocation-Before variable.
• step 1607 the Invocation Result Checker 134 gets the application invocation time right after the Change Date Time (step 1601 ) by referring to the Application Invocation History Table 142 for the Computer ID (step 1601 ) and Application Name (step 1601 ).
• the application invocation time of "DOC EDITOR” right after the "06/04/2008 08:20:1 1 " can be found as "06/04/2008 08:29:23" (record 417) in the Application Invocation History Table 142.
• step 1608 the Invocation Result Checker 134 counts the number of events within a certain time right after the application invocation time (step 1607) by referring to the Event Log Table 141 for the Computer ID (step 1601 ). When the invocation time is "06/04/2008 08:29:23," the number of events within 10 seconds is 1 . [0099] In step 1609, the Invocation Result Checker 134 checks the number of events counted in step 1608. If it is greater than 0, the process proceeds to step 161 1 . Otherwise, the process proceeds to step 1610. In step 1610, the Invocation Result Checker 134 sets SUCCESS to the Invocation-After variable.
• step 161 1 the Invocation Result Checker 134 sets FAILURE to the Invocation-After variable. Because the number of events is 1 , the Invocation-After variable is set to FAILURE. [0100] In step 1612, the Invocation Result Checker 134 returns the values of the Invocation-Before and Invocation-After variables. In this explanation, the return value of Invocation-Before is SUCCESS and the value of Invocation-After is FAILURE.
• FIG. 17 is an example of a flow diagram illustrating the causal configuration change analysis process as executed by the Causal Configuration Changes Analyzer 132 residing in the analysis computer 101 according to the first embodiment of the invention.
• the Causal Configuration Changes Analyzer 132 initiates the process by invocation from the Cause Analysis Program 121 .
• the Causal Configuration Changes Analyzer 132 receives the Computer ID and Application Name as the parameters.
• the Computer ID is "Comp-001 " and the Application Name is "DOC EDITOR.”
• the Causal Configuration Changes Analyzer 132 calls the subroutine in FIG.
• step 1701 the records (91 1 -971 ) are stored in the Causal Configuration Change Temporary Table 144.
• step 1703 the Causal
• Configuration Changes Analyzer 132 receives the configuration change list as the return of step 1702.
• An item in the list contains the Configuration Item, Change Type, and Change Date Time.
• the configuration change list contains "PRINTER DRIVER A - ADD - 06/04/2008 08:20:1 1 ,” “PATCH-2322 - ADD - 06/04/2008 07:43:1 1 ,” “VPN-CLIENT v2.0 - ADD - 06/03/2008 14:27:35,” and "VPN-CLIENT v1 .8 - REMOVE - 06/03/2008 13:59:28.”
• step 1704 the Causal Configuration Changes Analyzer 132 checks whether all the items in the list received in step 1703 are processed or not. If yes, the process ends. If no, the process proceeds to step 1705.
• step 1705 the Causal Configuration Changes Analyzer 132 retrieves one item from the list (step 1703) and reads the Configuration Item, Change Type, and Change Date Time.
• step 1708 the Causal Configuration Changes Analyzer 132 inserts the record of the result into the Causal Configuration Changes Table 146.
• the record includes the Configuration
• FIG. 18 is an example of a flow diagram illustrating the subroutine of the causal configuration change analysis process in step 1702 of FIG. 17. This subroutine initiates the process by invocation from the Causal Configuration Changes Analyzer 132. As illustrated in FIG. 18, in step 1801 , this subroutine receives the Computer ID and Application Name as the parameters.
• this subroutine retrieves all records from the Causal Configuration Changes Temp Table 144. It reads all the pairs of Configuration Item and Change Type and sets them to the CONFIG-LIST variable as a list.
• the CONFIG-LIST variable contains "PRINTER DRIVER A - ADD,” "PATCH-2322 - ADD,” “VPN-CLIENT v2.0 - ADD,” and "VPN-CLIENT v1 .8 - REMOVE.”
• this subroutine extracts the records which have the same pair of Configuration Item 903 and Change Type 904 as that in the CONFIG-LIST (step 1802) from the Configuration Change History Table 143 except the records for the Computer ID received at step 1801 .
• step 1804 this subroutine checks whether all records extracted in step 1803 are processed or not. If yes, the process ends. If no, the process proceeds to step 1805. In step 1805, this subroutine retrieves one record from the records extracted in step 1803, and reads the Computer ID 901 , Change Date Time 902, Configuration Item 903, and Change Type
• this subroutine invokes the Invocation Result Checker 134 with the values of the Computer ID (step 1805), Application Name (step 1801 ), and Change Date Time (step 1805).
• this subroutine receives the values of the Invocation-Before and Invocation-After variable as the result of step 1806. The result indicates whether the application could be invoked without any errors before and after the configuration change, or not.
• this subroutine makes a record including the Computer ID 901 , Change Date Time 902, Configuration Item 903, Change Type 904, Invocation-Before 905, and Invocation-After 906. It inserts the record into the Causal Configuration Changes Temp Table 144.
• FIG. 19 is an example of a flow diagram illustrating the fixing configuration change analysis process as executed by the Fixing Configuration Changes Analyzer 133 residing in the analysis computer 101 .
• the Fixing Configuration Changes Analyzer 133 initiates the process by invocation from the Cause Analysis Program 121 .
• the Fixing Configuration Changes Analyzer 133 receives the Application Name as the parameter.
• the Application Name is "DOC EDITOR.”
• the Fixing Configuration Changes Analyzer 133 calls the subroutine in FIG. 20 with the value of the Application Name (step 1901 ).
• step 1904 the Fixing Configuration Changes Analyzer 133 extracts the pairs of Configuration Item 1 103 and Change Type 1 104 from the records extracted in step 1903 without duplication.
• step 1905 the Fixing Configuration Changes Analyzer 133 deletes the records whose values of the Configuration Item 1 103 and Change Type 1 104 are not contained in the pairs extracted in step 1904 from records extracted in step 1903.
• step 1906 the Fixing Configuration Changes Analyzer 133 checks whether all the pairs extracted in step 1904 are processed or not. If yes, the process ends. If no, the process proceeds to step 1907.
• step 1907 the Fixing Configuration Changes Analyzer 133 retrieves one pair and reads the values of the Configuration Item 1 103 and Change Type 1 104.
• step 1910 the Fixing Configuration Changes Analyzer 133 inserts the record of the result into the Fixing Configuration Changes Table 147.
• the record includes the Configuration Item (step 1907), Change Type (step 1907), the number of SUCCESS records (result of step 1908), and the number of all related records (result of step 1909).
• FIG. 20 is an example of a flow diagram illustrating the subroutine of the fixing configuration change analysis process in step 1902 of
• This subroutine initiates the process by invocation from the Fixing Configuration Changes Analyzer 133. As illustrated in FIG. 20, in step 2001 , this subroutine receives the Application Name as the parameter. In step 2002, this subroutine extracts the records whose value of Invocation-After 906 is FAILURE from the Causal Configuration Changes Temp Table 144. [0108] In step 2003, this subroutine checks whether all records extracted in step 2002 are processed. If yes, the process proceeds to step 2012. If no, the process proceeds to step 2004. In step 2004, this subroutine retrieves one record from the records extracted in step 2002, and reads the Computer ID 901 and Change Date Time 902.
• step 2006 this subroutine checks whether all records extracted in step 2005 are processed or not. If yes, the process proceeds to step 2003. If no, the process proceeds to step 2007.
• step 2007, this subroutine retrieves one record from the records extracted in step 2005, and reads the Computer ID and Change Date Time.
• step 2008 this subroutine invokes the Invocation Result Checker 134 with the values of the Computer ID (step 2007), Application Name (step 2001 ), and Change Date Time (step 2007).
• this subroutine receives the values of the Invocation- Before and Invocation-After variables as the result of step 2008.
• this subroutine makes a record including the Computer ID 1 101 , Change Date Time 1 102, Configuration Item 1 103, Change Type 1 104, Invocation-Before 1 105, and Invocation-After 1 106. It inserts the record into the Fixing
• step 201 1 this subroutine checks whether the value of the Invocation-After (step 2009) is SUCCESS or not. If yes, the process returns to step 2003. If no, the process returns to step 2006. In step 2012, this sub-routine eliminates the duplication of records on the Fixing Configuration Changes Temp Table 145. [0110] B. Second Embodiment
• FIG. 21 shows an example of the Causal Configuration Changes
• Table 146-21 according to a second embodiment of the invention.
• the Cause Analysis Program 121 reuses and displays the result which was analyzed and stored in the past if the same analysis was done in the past.
• the Causal Configuration Changes Table 146 of FIG. 10 needs to be expanded.
• the columns from 1001 to 1005 are the same as those in FIG. 10. Additionally, new columns for Application Name 2101 and Analyzed Date Time 2102 are introduced.
• FIG. 22 is an example of a flow diagram illustrating causal analysis as executed by the Cause Analysis Program 121 according to the second embodiment of the invention. Steps 1401 , 1403, 1404, 1405 and 1406 are the same as those in FIG. 14. The differences between FIG. 14 and
• FIG. 22 are as follows.
• the Cause Analysis Program (121 ) does not initialize result tables (Causal Configuration Changes Table146 and Fixing Configuration Change Table 147).
• the Cause Analysis Program 121 searches the record that contains the same application name and configuration change as the Application Name 412 and configuration changes of step 1403, respectively, from the Causal Configuration Changes Table 146-21 (shown in FIG. 21 ).
• the Cause Analysis Program 121 checks whether the record of the past result was found or not. If yes, the process proceeds to the step 1406. If no, the process proceeds to step 1404.
• the result that is stored in step 1404 should be based on the schema of the Causal Configuration Changes Table 146-21 (FIG. 21 ).
• FIG. 23 shows an example of the Causal Configuration Changes
• Table 146-23 according to a third embodiment of the invention.
• the Cause Analysis Program 121 analyzes based on the combination of configuration changes.
• the Causal Configuration Changes Table 146 of FIG. 10 needs to be expanded.
• the columns from 1001 to 1005 are the same as those in FIG. 10.
• a new column for the Combination ID 2301 is introduced.
• the record 231 1 shows that the analysis was done by using all combinations of each configuration change. The same idea can be applied to expand the Fixing Configuration Change Table 147 of FIG. 12. [0115] FIG.
• Step 24 is an example of a flow diagram illustrating the causal configuration change analysis process as executed by the Causal Configuration Changes Analyzer 132 according to the third embodiment of the invention.
• Step 1701 , 1702 and 1703 are the same as those in FIG.17.
• the differences between FIG.17 and FIG. 24 are as follows.
• the Causal Configuration Change Analyzer 132 makes a list of all combinations of configuration changes 1703.
• the configuration changes are "PRINTER DRIVER A - ADD,” "VPN-CLIENT v2.0 - ADD,” and "VPN-CLIENT v1 .8 - REMOVE," the combination becomes the following:
• step 2402 the Causal Configuration Change Analyzer 132 checks whether all the items in the list made in step 2401 are processed or not. If yes, the process ends. If no, the process proceeds to the step 2403.
• step 2403 the Causal Configuration Change Analyzer 132 retrieves one item from the list (step 2401 ) and reads the Configuration Item, Change Type, and Change Date Time.
• step 2406 the Causal Configuration Change Analyzer 132 inserts the record of the result into the Causal Configuration Changes Table 146-23 (FIG. 23). [0117] D. Fourth Embodiment
• FIG. 25 illustrates an example of a configuration of hardware architecture, software modules, and tables of entire system according to a fourth embodiment of the invention.
• all of the computers can be server and client according to the situation. No centralized server is necessary.
• Each computer 2501 has the Cause Analysis Program (121 ), agent (161 ), Log Information (171 ), and Log Collector Program (122).
• the Log Information (171 ) in each computer contains not only Log Information of that computer but also Log Information of other computers.
• FIGS. 1 and 2 are purely exemplary of information systems in which the present invention may be implemented, and the invention is not limited to a particular hardware configuration.
• the computers and storage systems implementing the invention can also have known I/O devices (e.g., CD and DVD drives, floppy disk drives, hard drives, etc.) which can store and read the modules, programs and data structures used to implement the above-described invention.
• These modules, programs and data structures can be encoded on such computer-readable media.
• the data structures of the invention can be stored on computer-readable media independently of one or more computer-readable media on which reside the programs used in the invention.
• the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include local area networks, wide area networks, e.g., the Internet, wireless networks, storage area networks, and the like.
• embodiments of the invention may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out embodiments of the invention.
• some embodiments of the invention may be performed solely in hardware, whereas other embodiments may be performed solely in software.
• the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways.
• the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Quality & Reliability (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• Biomedical Technology (AREA)
• Debugging And Monitoring (AREA)

Priority Applications (6)

Applications Claiming Priority (1)

Related Child Applications (2)

Publications (1)

Family

ID=40974528

Family Applications (1)

Country Status (4)

Families Citing this family (37)

Citations (3)

Family Cites Families (10)

• 2009
  • 2009-03-30 WO PCT/IB2009/005640 patent/WO2010112960A1/en not_active Ceased
  • 2009-03-30 JP JP2011510061A patent/JP5274652B2/ja not_active Expired - Fee Related
  • 2009-03-30 EP EP09785914A patent/EP2300920A1/en not_active Withdrawn
  • 2009-03-30 US US12/526,383 patent/US8024617B2/en not_active Expired - Fee Related
• 2011
  • 2011-08-19 US US13/213,512 patent/US8601319B2/en not_active Expired - Fee Related
• 2013
  • 2013-11-21 US US14/085,996 patent/US9003230B2/en not_active Expired - Fee Related

Patent Citations (3)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events