Method, computer program, and computer system for managing problems in a user system

Abstract

To provide a method, computer program and computer system for problem management in a user system.SOLUTION: The present disclosure relates to a method for problem management in a user system. The method may include detecting an error in the user system. A signed package may be provided in accordance with the detected error, where the package comprises at least a script. The user system may verify the authenticity of the package using a signature of the package, and may execute the script if the package is authentic.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to the field of digital computer systems, and more particularly to methods of problem management. [Background technology]

[0002] Problem management may include the activities required to diagnose the root causes of problems identified through the problem management process and to determine solutions to those problems, but problem management is also responsible for ensuring that the solutions are implemented through appropriate control procedures. Summary of the Invention [Problem to be solved by the invention]

[0003] The present invention aims to provide a method, a computer program, and a computer system for problem management in a user system. [Means for solving the problem]

[0004] Various embodiments provide a method, a computer system and a computer program product for problem management as described by the subject matter of the independent claims. Advantageous embodiments are set out in the dependent claims. The embodiments of the invention can be freely combined with one another if they are not mutually exclusive.

[0005] In one aspect, the present invention relates to a computer-implemented method including: detecting an error in a user system or receiving detection of the error; preparing (or receiving) a signed package according to the detected error, where the package includes at least a script (which may be termed a correction script or a diagnostic script); verifying the authenticity of the package by the user system using the package's signature; and, if the package is authentic, executing the script by the user system.

[0006] In another aspect, the present invention relates to a computer program product including a computer-readable storage medium having computer-readable program code embodied thereon, and the computer-readable program code configured to implement all the steps of the method according to the above-described embodiments.

[0007] In another aspect, the present invention relates to a computer system comprising a processor and a computer-readable recording medium having computer-readable program code implemented thereon, the computer-readable program code being configured to execute a method including: detecting an error in the user system or receiving detection of the error; preparing (or receiving) a signed package according to the detected error, the package including at least a script; verifying the authenticity of the package by the user system using the package signature; and, if the package is authentic, executing the script by the user system.

[0008] In the following embodiments of the invention will be described in more detail, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 illustrates a service system according to one example of the present subject matter. [Figure 2] FIG. 2 illustrates a service system according to one example of the present subject matter. [Figure 3] FIG. 3 is a flow chart of a problem management method according to one example of the present subject matter. [Figure 4] FIG. 4 is a flowchart for correcting detected errors in a user system, according to one example of the present subject matter. [Figure 5A] FIG. 5A shows a flowchart for correcting detected errors in a user system, according to one example of the present subject matter. [Figure 5B] FIG. 5B shows a flowchart for correcting detected errors at a user system, according to one example of the present subject matter. [Figure 6] 1 represents a computerized system suitable for implementing one or more method steps as included in the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0010] The description of various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or to be limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0011] The user system may be provided by a service provider. A user (e.g., a customer) of the user system may interact with the user system, e.g., using a workstation, through a predefined service interface. The service interface may allow limited access to the user system. The user system may have multiple functions. The service interface may allow access to a minimum number of functions of the user system, e.g., one or two functions. For example, the service interface may be a general-purpose interface for trace / log file collection, and the user may only monitor the output / logs of the user system. Thus, an initial problem may be that the service interface is not sufficient to handle a specific problem in the user system, let alone fix the problem.

[0012] The user system may be an appliance. The appliance may be, for example, a storage appliance, such as an IBM Db2 database system. However, the appliance may be complex because it may be composed of many interacting components. In various embodiments, the appliance may be any suitable computer system composed of software, hardware, or both software and hardware. This may be a second source of difficulty because the behavior of the appliance may be difficult to model or predict due to dependencies or other types of interactions between multiple components. Therefore, understanding and correcting errors or problems in the user system may be a very resource-intensive task, especially if not performed by a service provider, such as the appliance manufacturer or an authorized service provider. The detected error may be a defect or failure in the user system that causes it to produce incorrect or unexpected results or to operate in an unintended manner. The detected error may be, for example, a software error, a hardware error, or a combination thereof.

[0013] The subject of the present invention may solve these problems by providing a service provider problem management system that creates and provides packages to fix the detected errors. Thus, the user system can use the provided package to fix the error without having to find a fix locally on the user system. In another example, execution of a script of predefined commands within a provided package may allow the root cause, particularly for hardware-based errors, to be identified. The package may be referred to as a "service package." The service package may collect diagnostic data. For example, if hardware has a problem, the service package may run a script that narrows down the possible causes to find the root cause of the failure.

[0014] However, because the service package does not need to be executed by the appliance manufacturer or an authorized service provider, the provided service package may be misused if its execution is not controlled, for example, if it is executed on an unauthorized appliance. Therefore, the subject matter of the present invention may use signatures to control the provision of service packages and the execution of scripts. For example, a user system may execute a script only if the user system has access to a public key. Also, signing the package may ensure that only scripts provided by the service provider can be executed on the user system. The signature may be a digital signature. The digital signature may be a mathematical scheme for verifying the authenticity of the package. The signature may be generated, for example, using a public-private pair key scheme.

[0015] The script of the provided service package may be named a fix script or a diagnostic script. It may provide functionality for correcting the detected error or for performing diagnostics of the detected error to identify the root cause. For example, it may be sufficient to use the service package to collect more diagnostic information about the detected error, which may then be used by a support engineer to create another service package that includes actual procedures for correcting the detected error. In this case, the method further includes receiving diagnostic information about the detected error in response to executing the fix script, and providing another service package based on the collected information. The user system may then re-verify the signature of the newly provided service package and execute the new script of the newly provided service package.

[0016] The subject matter of the present invention may enable fast turnaround times for problems / service requests. Additionally, when the appliance manufacturer or an authorized service provider attempts to resolve a problem reported by a user, the service provider may use screen-sharing sessions. These sessions are used to gather information about the specific problem and upload that information to a problem management system or to apply workarounds / fixes, for example, by applying a software update package. An advantage of this embodiment is that a screen-sharing approach does not need to be used. Because the user's system is not blocked (e.g., by a support engineer using the user's workstation via a screen-sharing session) while the problem is being analyzed by the service package's script running in the background, the user can use the user's system (appliance) while the problem is being analyzed / fixed by the problem management system.

[0017] According to one embodiment, the service package includes metadata, including a maximum execution count, where execution of the script is performed in response to determining that the number of previous executions of the script on the user system is less than the maximum execution count. This implementation may allow for setting the number of times a script can be executed (e.g., 1 time or x number of times) to prevent re-execution and data leakage in selected cases.

[0018] The package signature indicates the contents of the metadata and script provided by the problem management system. That is, any change in the metadata, the script, or a combination thereof may result in the package being unauthenticated. Execution of the script may be performed using the metadata. For example, the metadata may allow initialization of one or more variables in the script. The same metadata used to perform the package validation is used to execute the script. If the metadata has been changed on the user system, the script may not execute. For example, because the metadata is part of the signed data, it cannot be tampered with without revoking the signature. The user system may detect such illegal or fraudulent activity, and in response, the user system simply does not execute the script.

[0019] According to one embodiment, the signed package is received from a problem management system configured to remotely connect to the user system, and determining that the number of previous executions of the script on the user system is less than a maximum execution count includes determining by the user system that the number of previous executions of the script on the user system is less than a maximum execution count, and determining by the problem management system that the number of previous executions of the script on the user system is less than the maximum execution count.

[0020] For example, a check that the number of previous executions of the script is less than the maximum execution count may be performed by both the user system and the problem management system, and the script may be executed only if both checks are successful. If the check fails in either the user system or the problem management system, the method may terminate and include reporting a check error by the user system to the problem management system. This embodiment may further improve control of the script execution by requiring that both systems agree on the number of times the script has been executed. For example, this may prevent the user system from executing the package without the consent of the problem management system.

[0021] The number of previous executions of the script can be determined in various ways. For example, a log that stores a history of executions on the user system can be used to determine the number on the user system. The problem management system can also determine the number using its own log, for example, a log that logs delivered packages.

[0022] According to one embodiment, the user system and the problem management system may include an execution counter indicating the number of previous executions of the script. The method further includes incrementing the execution counter if the script executes successfully. For example, the execution counter may be incremented in the problem management system upon receiving a report from the user system indicating that the script executed successfully. This may be particularly advantageous if the user system is configured to automatically report the results of the execution.

[0023] In another example, the execution counter may be incremented in the problem management system and in the user system each time a package with the same script is provided by the problem management system. This may be advantageous because the problem management system does not rely on the user system's reports to count the number of executions. This may prevent misuse, for example, where the user system (knowing the count check feature) fails to send a report to allow the package to be executed further (beyond the allowed number of executions) by using the same existing count.

[0024] According to one embodiment, the package includes metadata, including a unique identifier for the user system, and execution of the script is performed in response to determining that the user system has that unique identifier. The unique identifier may be, for example, the user system's serial number. In this way, the signed package can be tailored to run only on one specific machine and not on other machines.

[0025] According to one embodiment, detecting the error includes automatically detecting the error by a monitoring unit of the user system or detecting the error by a user of the user system, and providing the detected error to a problem management system, wherein providing the signed package is performed by the problem management system.

[0026] According to one embodiment, the user system may schedule the execution of the script using one of three execution methods: execute the script immediately after determining that the package is authentic, execute the script within a predefined maintenance time window, or execute the script after receiving user approval to execute the script. Thus, the script is provided so that its application is customizable, for example, so that the time slot in which the script is executed can be selected by the user.

[0027] This embodiment may allow for multiple scheduling strategies. For example, if a customer sets the execution strategy to "immediate" in their configuration, the scheduler on the user system will execute the script immediately after it is submitted. If the customer sets the execution strategy to "approved" in their configuration, the customer must approve the execution of each and every script. To enable the customer to act in a timely manner, the customer will be notified of each new script submitted to their system. If the customer sets the execution strategy to "maintenance window" in their configuration, the customer can define a maintenance window in their configuration. Scripts will only be executed during a maintenance window. If there is no maintenance window but there are scripts queued for execution, they may not be executed. The customer may need to define a new maintenance window first. The customer will be notified of such a situation.

[0028] According to one embodiment, the method further includes providing a report on the results of the execution of the script and combining it with the package in an integrity-protected manner. In one example, a user of the user system can transfer the execution results from the user system to the user's workstation to create the report and upload the report from the workstation to the problem management system. In another example, the report can be created by the user system and sent by the user system to the problem management system via a direct secure connection between the user system and the problem management system. The report may or may not be reviewed by the user. For example, the execution results can be saved in an archive file. This archive file can be reviewed by the user to check that no sensitive data is included in the archive before sending it to the problem management system.

[0029] According to one embodiment, providing the signed package includes one of transmitting the service package to the user system via an established secure connection between the user system and the problem management system, or downloading the service package from the problem management system to the user system. For example, a user of the user system can download the service package to the user's workstation and then transfer the service package from the workstation to the user system when the script is executed.

[0030] According to one embodiment, the method is performed automatically, which may correct the detected error in time without relying on user intervention. For example, the error may be automatically detected by the user system, and a support request may be automatically sent by the user system to a problem management system indicating the detected error. Upon receiving the support request, the problem management system may create a package and automatically provide it to the user system. For example, the problem management system may use a history file containing a mapping between previously detected errors and associated scripts. The file may be used by the problem management system to create the script by identifying an entry in the file that corresponds to the detected error and associated script. The service package may be derived, for example, based on appliances of other user systems that have similar problems that have been resolved by a particular set of one or more service packages.

[0031] The automatic execution of the script may be triggered by the problem management system, and a user of the user system may allow this automatic execution by enabling direct communication from the problem management system to the user system on which the script is to be executed.

[0032] In another example, manual execution of the script may allow the user to review what was executed and what will be sent to the problem management system.

[0033] According to one embodiment, the script is not encrypted. The method further includes analyzing the script to log one or more actions performed by the script in an audit log and providing the audit log to enable inspection of actions performed on the user system. This may allow the user to inspect the script. For example, the user may be required to provide the audit log to an auditing authority (e.g., tax authorities) to audit the script that has been applied to the user system.

[0034] The service package may be provided only in response to user authentication of a user of the user system. The problem management system may check the authenticity of the user of the user system before providing the package. According to one embodiment, the method further includes receiving a support request from a user of the user system indicating the detected error, authenticating the user, wherein if the user is authenticated, the package is provided.

[0035] FIG. 1 illustrates a service system 100 according to an example of the present inventive subject matter. The service system 100 includes a problem management system 101 and one or more computer systems (or user systems) 102a-n. The problem management system 101 may be configured to communicate with each of the computer systems 102a-n via one or more networks 103. For simplicity of explanation, only one network is shown. However, the problem management system 101 may connect to the computer systems 102a-n via multiple networks. For example, the problem management system 101 may connect to each of the computer systems 102a-n via a respective network. For example, the network 103 may include, but is not limited to, a cable network, an optical fiber network, a hybrid fiber-coaxial network, a wireless network (e.g., Wi-Fi or a cellular network, or a combination thereof), a satellite network, the Internet, an intranet, a local area network, any other suitable network, or any combination of these networks.

[0036] As shown, users 105a-n may each be associated with a computer system 102a-n, e.g., an instance of computer system 600. Users 105a-n may include viewers, owners, support technicians, etc. Users 105a-n may use workstations (not shown) to interact or communicate with computer systems 102a-n and problem management system 101. Each computer system 102a-n may include an appliance 104a-n. Appliance 104 may be a hardware-software appliance. For example, appliance 104a-n may be an IBM Db2® Analytics Accelerator. Users 105a-n may interact with appliance 104a-n only through the service interfaces provided. For example, the user may not have access to the appliance itself. These service interfaces may not be sufficient to address a particular problem, let alone fix the problem. For example, the appliance may not offer the end user (customer) the possibility to open a shell that can be used to analyze and fix the problem. Therefore, only very limited pre-provisioned generic service interfaces, e.g., trace / log file collection, are available to the end user, and the user 105a-n may need to involve the creator / manufacturer of the appliance 104a-n or an authorized service provider.

[0037] Problem management system 101 provides support for computer systems 102a-n. Problem management system 101 may be remote from computer systems 102a-n, accessible via network 103. Problem management system 101 may handle at least a portion of the processing of errors when they occur on computer systems 102a-n. Problem management system 101 may provide an explanation and a solution for an error when an error occurs on computer systems 102a-n. The solution may be provided according to a problem management methodology, for example, as described with reference to FIG. 2. To this end, problem management system 101 may be implemented by any combination of computing devices (e.g., a server, one or more instances of computer system 600) as may be useful for a particular implementation.

[0038] The problem management system 101 may include a problem detection module 110, a support module 111, and a storage system 112 selectively and communicatively coupled to each other. The problem detection module 110 may be configured to receive (e.g., detect) support requests from the computer systems 102a-n. The support requests may be submitted automatically in response to the occurrence of an error at the computer systems 102a-n, or may be submitted by the users 105a-n.

[0039] Support module 111 may be configured to perform one or more support session management operations as may be useful for a particular implementation. For example, support module 111 may respond to a support request received by problem detection module 110 by processing information included in the support request, opening a support ticket associated with the support request, and assigning a unique ticket identifier associated with the support ticket to the support request. For example, support module 111 may use the ticket identifier to establish a remote control session to the computer system.

[0040] The storage system 112 may be configured to store ticket identifier data 113 representing one or more ticket identifiers generated by the support module 111, and problem management records (PMRs) 114 containing information regarding the detected errors in the computer systems 102a-n.

[0041] 2 is a block diagram of a service system 200 illustrating a method of problem management for supporting computer systems in accordance with an example of the present subject matter. FIG. 2 illustrates an example of the problem management method as it is executed between the problem management system of FIG. 1 and one of the computer systems 102a-n.

[0042] The service system 200 may include a problem management system 201 and a computer system 202. The problem management system 201 is similar to the problem management system 101 of FIG. 1, and the computer system 202 is similar to the computer systems 102a-n of FIG. 1. The computer system 202 includes an appliance 204. The appliance 204 may be, for example, a DB2 system. The appliance 204 may be monitored automatically by a monitoring unit 221 or with the assistance of a user 205. Thus, an error or problem in the appliance 204 may be detected automatically or manually in step B1 or step A1, respectively. If the error is detected by the monitoring unit 221, the call home unit 220 may receive an indication of the error from the monitoring unit 221. In response to receiving the indication, the call home unit 222 may automatically open a problem management record in the problem management system 201 (step B2). This may be performed, for example, by sending a support request to the problem management system 201 in step B2. If the error is manually detected, user 205 may open a problem management record in problem management system 201 (step A2). This may be performed, for example, by entering a support request into problem management system 201 in step A2, e.g., via an interface. In response to receiving the support request, problem management system 201 may automatically create problem management record 214. As shown, problem management record 214 may include information indicating appliance 204, a problem description, diagnostic information, and a signed service package (including one or more service commands) to be provided, e.g., to resolve the problem. Support engineer 216 of problem management system 201 may analyze the data in problem management record 214 (step C1) and provide the service package accordingly (step C2). In another example, the service package may be automatically created by problem management system 201. The service package may include metadata and a payload.The payload may include a script to be executed (named a fix script) and one or more resource files containing additional information required by the fix script to be executed to fix an error, gather diagnostic information on the error, or a combination thereof. The metadata may include information indicating the creator of the service package, the serial number of the computer system 202, the maximum execution count of the fix script (e.g., a fix script using a one-time password), the name of the fix script to be executed, the name of a file containing the execution results, and a signature indicating the contents of the package. The service package may be provided to the user 205 or to the service command scheduling and execution engine 223 of the computer system 202. When the service package is provided to the user 205, the user 205 may trigger execution of the fix script by the service command scheduling and execution engine 223 (step C3a). When the service package is provided to the service command scheduling and execution engine 223, it may trigger execution of the service command scheduling and execution engine 223 to schedule execution of the fix script (step C3b). The corrective or diagnostic script may be executed in the appliance in step C4, for example, to correct the detected error. The results of the execution of the corrective script may be used to update PMR 214 (step C5) and to post to audit log file 224 of computer system 202. Audit log file 224 may also be stored in problem management system 201.The audit log file 224 may include the complete service package (metadata and payload), who submitted the service package for execution (which may only be known on the customer system when using an automated approach), the complete execution results, the time the fix script was sent for execution, the execution start time, the execution end time, configuration details regarding the execution scheduling strategy, who reviewed and approved the execution results, and (if approval is required), the time of creation of the script in the problem management system 201 and the time of execution of the script in the appliance 204.

[0043] 3 is a flowchart of a method for managing problems in a user system in accordance with one example of the present subject matter. For illustrative purposes, the method described in FIG. 3 may be implemented in the systems illustrated in FIGS. 1-2, but is not limited to this implementation.

[0044] In step 301, an error may be detected in the user system 202. The detected error may have, for example, one or more predefined error codes, such as a DB2 error code. The error may be associated, for example, with an error description provided by the user system 202. For example, the error description may indicate an unavailable resource if someone has locked data used by the appliance. The error may be automatically detected by the user system 202 using the monitoring unit 221 and reported to the problem management system 201. In another example, the error may be detected by a user 205, for example, using a service interface on the user's workstation, where the service interface displays the results of the monitoring by the monitoring unit 221. The user 205 may use the workstation to report the error to the problem management system 201.

[0045] In response to detecting the error, in step 303, the problem management system 201 may provide a signed package to the user system 202. The signed package may be referred to as a trusted service package. The package may include at least a fix script (including one or more service commands) that, when executed on the user system 202, may, for example, fix the detected error. In one example, the package may be provided with additional information that enables controlled execution of the fix script. For example, the package may include metadata and a payload. The payload includes the fix script. The payload may further include, for example, one or more resource files containing additional information that may be required by the fix script to be executed. The metadata may indicate the creator (e.g., the support engineer 216 who created the service command), the serial number of the user system 202, a maximum execution count (e.g., a one-time password for executing the fix script), the name of the fix script, the execution result, and the name of the file containing the signature. The signature is obtained by signing the package.

[0046] In one example, the fix script can be automatically determined by the problem management system using, for example, a mapping between known errors and associated fix scripts. The mapping can, for example, map an error code to fix scripts that can each fix multiple problems having the error code. The problem management system can maintain a history of corrective actions based on the experiences of other users. These corrective actions can be used to provide the fix script.

[0047] In step 305, the user system 202 may verify the authenticity of the fix script using the signature. If the script is authentic (query step 307), the user system 202 may execute the fix script in step 309. Otherwise, the fix script may not be executed, and in step 311, a check error may be reported to the problem management system.

[0048] Execution of the fix script may or may not be successful. If it is not successful, the user system 202 may send a report error to the problem management system 201. In response, the problem management system 201 may, for example, send another signed package containing another fix script, and steps 305-309 may be repeated with other service packages.

[0049] The execution of steps 305-309 may be controlled by problem management system 201. For example, problem management system 201 may trigger the execution of steps 305-309 via a direct connection between problem management system 201 and user system 202, e.g., by sending a control command to the user system, and in response to receiving the control command, the user system may schedule the execution of steps 305-309 according to an "immediate" strategy or a "maintenance window" strategy. This may be advantageous because problem management system 201 may have control over when the execution of the fix script should be scheduled.

[0050] After execution (success or failure), the execution results may be collected by the user system 202. The collected data may be defined in the package metadata. Additionally, the return code of the script execution and all content written to STDOUT and STDERR during script execution may be captured, written to a file, and included in the execution results. The execution results may be saved in an archive file. This file can be reviewed by the user to check that no sensitive data is included in the archive before sending the file to the problem management system. When using automatic execution of the method of FIG. 3, the customer / user 205 may decide whether to review the data before submitting it to the problem management system. If this is configured, the customer may be notified that the execution results are available for review and approval. If the customer approves, the data may be automatically uploaded to the problem management system via a secure connection. When using manual execution, it is the customer's responsibility to manually upload the execution results to the problem management system. In this case, the customer has the possibility to review the data included in the archive file. If the customer approves, the customer uploads the data to the problem management system.

[0051] FIG. 4 is a flowchart for correcting or diagnosing a detected error in a user system in accordance with one example of the present subject matter. For illustrative purposes, the method described in FIG. 4 may be implemented in the systems shown in FIGS. 1-2, but is not limited to this implementation. The method of FIG. 4 may enable automatic execution of a fix script. The fix script may enable correcting or diagnosing the detected error. A user of the user system may allow this automatic execution by enabling direct communication from the problem management system to the user system on which the fix script should be executed. In this case, the problem management system may trigger the following sequence of actions in the method of FIG. 4:

[0052] In step 401, the problem management system 201 requests the execution of a fix script on the user system 202. In step 403, the problem management system 201 establishes a secure connection to the user system 202. In step 405, the problem management system 201 sends a signed package containing the fix script to the user system 202. In step 407, the problem management system 201 triggers the execution of the fix script on the user system 202. For example, the problem management system 201 triggers the execution of the remaining steps of the method of FIG. 4. In step 409, the user system 202 verifies the signature of the package. If the signature is valid (query step 411), the user system 202 continues the process in step 413; otherwise, the method ends and in step 429, reports an error back to the problem management system 201. In step 413, the user system 202 verifies the serial number in the package and compares it with the serial number of the user system. If the comparison is successful (query step 415), it continues the process at step 417; otherwise, the method ends and reports an error back to problem management system 201 at step 429. At step 417, user system 202 checks whether this particular fix script has already been executed before. In addition, problem management system 201 checks whether this fix script has been executed before at user system 202. User system 202 and problem management system 201 may check whether the maximum number of executions (stored at user system 202 and at problem management system 201) has already been reached. If this check fails at either user system 202 or problem management system 201 (query step 417), user system 202 ends and reports an error back to problem management system 201 at step 429. Otherwise (query step 417), the process continues at step 421. At step 421, user system 202 schedules the fix script for execution.If the execution is successful (query step 423), in step 425, the user system 202 may report the execution result to the problem management system 201, and the user system 202 and the problem management system 201 may increment the execution counter for this fix script by one in step 427. For example, if the execution is unsuccessful, in step 429, an error may be reported.

[0053] 5A and 5B illustrate a flowchart for correcting or diagnosing detected errors in a user system in accordance with one example of the present subject matter. For illustrative purposes, the method described in FIGS. 5A and 5B may be implemented in the system shown in FIGS. 1-2, but is not limited to this implementation.

[0054] In step 501, the problem management system 201 requests manual execution of a fix script by attaching the signed package to the problem management system 201 and attaching a message to the customer 205 requesting execution. The fix script may make it possible to fix or diagnose the detected error. In step 503, the customer downloads the package to their workstation. In step 505, the customer transfers the package from their workstation to the user system 202 where the script should be executed. In step 507, the customer schedules the execution of the script, for example, by selecting the script in a service interface from a list of available scripts on the user system and clicking the execute button. This step 507 may include a means for specifying an execution schedule, for example, an immediate or future execution schedule within a maintenance window.

[0055] In step 509, the user system 202 verifies the signature of the package (inquiry step 511). If the signature is valid, the user system 202 continues the process in step 513; if not, it terminates and reports an error back to the problem management system 201 in step 531. In step 513, the user system 202 verifies the serial number in the package and compares it with the user system's serial number (inquiry step 515). If the comparison is successful, it continues the process in step 517; if not, it terminates and reports an error back to the problem management system 201 in step 531. The user system 202 checks in step 517 whether this particular fix script has already been run before. In addition, the problem management system 201 checks whether this fix script has been run before on the user system 202. User system 202 and problem management system 201 may check whether the maximum number of runs (stored in user system 202 and in problem management system 201) has already been reached (query step 517). If this check fails in either user system 202 or problem management system 201, user system 202 terminates and reports an error back to problem management system 201 in step 531. Otherwise (query step 517), the process continues in step 521.

[0056] In step 521, the user system schedules the script for execution and saves the execution results locally. If the execution is successful (query step 523), the user system may increment the execution counter for this script by one in step 529. In step 525, the customer sends the execution results from the user system 202 to the customer's workstation. In step 527, the customer transfers the execution results from the customer's workstation and uploads them to the problem management system 201. The problem management system 201 may save the execution results. The problem management system 201 may increment the execution counter for this script by one. For example, if the execution fails, an error may be reported in step 531.

[0057] FIG. 6 depicts a general computerized system 600 suitable for implementing at least some of the method steps included in the present disclosure.

[0058] It will be understood that the methods described herein are at least partially non-interactive and automated by a computerized system, such as a server or embedded system. However, in exemplary embodiments, the methods described herein can be implemented in a (partially) interactive system. These methods can also be implemented in software 612, 622 (including firmware 622), hardware (processor) 605, or a combination thereof. In exemplary embodiments, the methods described herein are implemented in software as executable programs and executed by a specialized or general-purpose digital computer, such as a personal computer, workstation, minicomputer, or mainframe computer. Thus, the most general system 600 includes a general-purpose computer 601.

[0059] In an exemplary embodiment, with respect to the hardware architecture, as shown in FIG. 6 , a computer 601 includes a processor 605, a memory (main memory) 610 connected to a memory controller 615, and one or more input and / or output (I / O) devices (or peripherals) 10, 645 communicatively connected via a local input / output controller 635. The input / output controller 635 can be, but is not limited to, one or more buses or other wired or wireless connections, as known in the art. The input / output controller 635 may include additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communication, although these are omitted from the drawing for simplicity. Furthermore, the local interface may include address, control, or data connections, or a combination thereof, to enable appropriate communication between the above-mentioned components. As described herein, the I / O devices 10, 645 may generally comprise any generalized cryptographic card or smart card known in the art.

[0060] Processor 605 is a hardware device for executing software, particularly software stored in memory 610. Processor 605 can be any custom-made or commercially available processor, a central processing unit (CPU), a coprocessor among several processors associated with computer 601, a semiconductor-based microprocessor (in the form of a microchip or chipset), or any device in general for executing software instructions.

[0061] The memory 610 can include any one or any combination of volatile memory elements (e.g., random access memory (RAM), e.g., DRAM, SRAM, SDRAM, etc.) and non-volatile memory elements (e.g., read only memory (ROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM)). It should be noted that the memory 610 can have a distributed architecture in which various components are located remotely from each other, yet can be accessed by the processor 605.

[0062] The software in memory 610 may include one or more individual programs, each of which includes an ordered list of executable instructions for implementing logical functions, among other functions, involved in embodiments of the present invention. In the example of Figure 6, the software in memory 610 includes instructions 612, such as instructions for managing a database, e.g., a database management system.

[0063] The software in memory 610 must also typically include a suitable operating system (OS) 411. The OS 611 essentially controls the execution of other computer programs, such as software 612 for implementing the methods described herein.

[0064] The methods described herein may be in the form of a source program 612, an executable program 612 (object code), a script, or any other entity comprising a set of instructions 612 to be executed. In the case of a source program, the program needs to be converted via a compiler, assembler, interpreter, etc., which may or may not be contained within memory 610 in order to operate properly in conjunction with the OS 611. Moreover, the methods may be written as an object-oriented programming language with classes of data and methods, or a procedural programming language with routines, subroutines, or functions, or a combination thereof.

[0065] In an exemplary embodiment, a conventional keyboard 650 and mouse 655 can be connected to the input / output controller 635. Other output devices, such as I / O devices 645, include, but are not limited to, input devices such as printers, scanners, microphones, etc. Finally, I / O devices 10, 645 can also include, but are not limited to, devices that communicate both input and output, such as, but not limited to, network interface cards (NICs) or modulators / demodulators (for accessing other files, devices, systems, or networks), radio frequency (RF) or other transceivers, telephone interfaces, bridges, routers, etc. I / O devices 10, 645 can be any generalized cryptographic card or smart card known in the art. System 600 can further include a display controller 625 connected to a display 630. In an exemplary embodiment, system 600 can include a network interface for connecting to a network 665. Network 665 can be an IP-based network for communication between computer 601 and any external servers, clients, etc. via a broadband connection. Network 665 transmits and receives data between computer 601 and external system 30, which may be involved to perform some or all of the steps of the methods discussed herein. In an exemplary embodiment, network 665 may be a managed IP network managed by a service provider. Network 665 may be implemented wirelessly using wireless protocols and technologies, such as WiFi, WiMax, etc. Network 665 may also be a packet-switched network, such as a local area network, wide area network, metropolitan area network, Internet network, or other similar type of network environment.The network 665 may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WWAN), a personal area network (PAN), a virtual private network (VPN), an intranet, or other suitable network system and includes equipment for transmitting and receiving signals.

[0066] If computer 601 is a PC, workstation, intelligent device, etc., the software in memory 610 may further include a basic input / output system (BIOS) 622. The BIOS is a set of important software routines that initializes and tests hardware at startup, starts OS 611, and supports data transfer between hardware devices. The BIOS is stored in ROM so that it can be executed when computer 601 is activated.

[0067] When computer 601 is operating, processor 605 is configured to execute software 612 stored in memory 610, to communicate data to and from memory 610, and generally to control the operation of computer 601 in accordance with the software. The methods and OS 611 described herein, in whole or in part, but typically the latter, are read by processor 605, possibly buffered within processor 605, and then executed.

[0068] 6, when the systems and methods described herein are implemented in software 612, the methods can be stored on any computer-readable medium, such as storage 620, for use by or in connection with any computer-related system or method. Storage 620 can comprise disk storage, such as HDD storage.

[0069] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0070] The computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge structure in a groove in which instructions are recorded, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0071] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to an individual computing device / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to the individual computing device / processing device for storage in a computer-readable storage medium.

[0072] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(e.g., Smalltalk, C++, etc.), procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0073] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions.

[0074] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or combinations thereof, to function in a particular manner, such that the computer-readable storage medium having stored thereon instructions includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or combinations thereof.

[0075] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, implement the functions / operations identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, causing the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0076] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should also be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

Claims

1. A problem management method in a user system, comprising: detecting errors in the user system provided by a service provider, wherein the service provider is accessible by the user via a service interface; receiving a package signed by the user system according to the detected error, the package including at least a fix or diagnostic script for fixing or diagnosing the detected error by the service provider without having to locate a fix or diagnostic locally on the user system; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script, wherein the script enables one or more root causes of the detected error on the user system to be identified. The method comprising:

2. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, The method, wherein the method is performed automatically.

3. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, Detecting the error detecting the error automatically by a monitoring unit of the user system or by a user of the user system; and providing the detected error to a problem management system, wherein providing the signed package is performed in response to receiving the detected error by the problem management system. The method.

4. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, Executing the script, Immediately after determining that said package is authentic, Within a predefined maintenance window, or After receiving user approval to run said script To be executed, The method.

5. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, the script is not encrypted, and the method further includes analyzing the script to log one or more actions performed by the script in an audit log, and providing the audit log to enable inspection of actions performed on the user system. The method.

6. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, the method further comprising receiving a support request from a user of the user system indicating the detected error; authenticating the user; and wherein if the user is authenticated, the package is provided by a problem management system. The method.

7. A problem management method in a user system, comprising: detecting an error in the user system or receiving detection of the error; the user system receiving a signed package according to the detected error, wherein the package includes at least a correction script or a diagnostic script; the user system verifies the authenticity of the package using the package signature; and If the package is authentic, the user system executes the script. Including, the user system comprises an appliance database system; The method.

8. the package includes metadata, the metadata includes a maximum execution count; and executing the script in response to determining that the number of previous executions of the script on the user system is less than the maximum execution count; The method according to any one of claims 1 to 7.

9. The signed package is received from a problem management system configured to remotely connect to the user system, and a determination that the number of previous executions of the script on the user system is less than the maximum execution count is made by: the user system determining that the number of previous executions of the script on the user system is less than the maximum execution count; and the problem management system determining that the number of previous executions of the script on the user system is less than the maximum execution count; The method of claim 8, comprising:

10. the user system and the problem management system are equipped with an execution counter indicating the number of previous executions of the script, the method further comprising incrementing the execution counter if the script is successfully executed.

10. The method of claim 9.

11. 11. The method of claim 1, wherein the package includes metadata, the metadata having a unique identifier for the user system, and wherein the execution of the script is performed in response to determining that the user system has the unique identifier.

12. Detecting the error detecting the error automatically by a monitoring unit of the user system or by a user of the user system; and providing the detected error to a problem management system, wherein providing the signed package is performed in response to receiving the detected error by the problem management system. The method according to any one of claims 1, 2 and 4 to 7.

13. Executing the script, Immediately after determining that said package is authentic, Within a predefined maintenance window, or After receiving user approval to run said script The method according to any one of claims 1 to 3 and 5 to 7, wherein

14. transmitting the service package to the user system via the established secure connection between the user system and the problem management system; or downloading the service package from the problem management system to the user system; The method of any one of claims 1 to 13, further comprising:

15. 8. The method of any one of claims 1 to 4 and 6 to 7, wherein the script is not encrypted, and the method further comprises analyzing the script to log one or more actions performed by the script in an audit log, and providing the audit log to enable inspection of actions performed on the user system.

16. 8. The method of claim 1, further comprising receiving a support request from a user of the user system indicating the detected error, and authenticating the user, wherein if the user is authenticated, the package is provided by a problem management system.

17. The method of any one of claims 1 to 6, wherein the user system comprises an appliance database system.

18. The method of any one of claims 1 to 17, wherein the package signature is verified using a public-private pair key scheme.

19. A computer program comprising causing the user system to carry out the method of any one of claims 1 to 18.

20. 20. A computer system comprising a processor and a computer-readable recording medium storing the computer program of claim 19.

Images