Problem management in user systems

Abstract

Embodiments of the present disclosure relate to problem management in a user system. The present disclosure relates to a method for problem management in a user system. A method can include detecting an error in a user system. A signature package can be provided in accordance with the detected error, where the package includes at least a script. The user system can use a signature of the package to verify authenticity of the package, and if the package is authentic, the script can be executed.

Description

TECHNICAL FIELD

[0001] The present invention relates to the field of digital computer systems, and more specifically, to a problem management method. BACKGROUND

[0002] Problem management can include diagnosing root causes of problems identified through the problem management process and determining activities required to resolve those problems. However, problem management is also responsible for ensuring that the resolution is implemented through appropriate control processes. SUMMARY

[0003] Different embodiments provide a problem management method, a computer system and a computer program product as described by the subject matter of the independent claims. Advantageous embodiments are described in the dependent claims. Embodiments of the invention can be freely combined with each other if they are not mutually exclusive.

[0004] In one aspect, the invention relates to a computer-implemented method comprising: detecting an error in a user system; providing (or receiving) a signed package in dependence of the detected error, the package comprising at least a script (the script can be named a correction script or a diagnostic script); verifying the authenticity of the package by the user system using the signature of the package; and executing the script by the user system if the package is authentic.

[0005] In another aspect, the invention relates to a computer program product comprising a computer readable storage medium having computer readable program code embodied therewith, the computer readable program code configured to implement all the steps of the method according to the preceding embodiment.

[0006] In another aspect, the invention relates to a computer system comprising a processor and a computer readable storage medium having computer readable program code embodied therewith, the computer readable program code configured to perform a method comprising: detecting an error in a user system; providing (or receiving) a signed package in dependence of the detected error, the signed package comprising at least a script; verifying the authenticity of the package by the user system using the signature of the package; and executing the script by the user system if the package is authentic. BRIEF DESCRIPTION OF DRAWINGS

[0007] In the following embodiments of the invention, embodiments of the invention are explained in more detail by way of example only, with reference to the accompanying drawings, in which:

[0008] Figure 1 A service system according to an example of the present subject matter is shown.

[0009] Figure 2 A service system according to an example of the present subject matter is shown.

[0010] Figure 3 is a flowchart of an example problem management method according to the present subject matter.

[0011] Figure 4 is a flowchart for fixing a detected error in a user system according to an example of the present subject matter.

[0012] Figure 5A 、 Figure 5B depicts a flowchart for fixing a detected error in a user system according to an example of the present subject matter.

[0013] Figure 6 represents a computerized system adapted to implement one or more method steps as referred to in the present disclosure. DETAILED DESCRIPTION

[0014] The description of various embodiments of the present invention will be presented for the purpose of illustration and description, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application, or technical improvements found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0015] A user system can be provided by a service provider. A user (e.g., a customer) of the user system can interact with the user system through a predefined service interface, e.g., using a workstation. The service interface can enable limited access to the user system. The user system can have multiple functionalities. The service interface can enable access to a minimum number of functionalities of the user system, e.g., one or two functionalities. For example, the service interface can be a generic interface for tracking / logging file collection, e.g., the user can only monitor the output / logs of the user system. Thus, a first problem can be that the service interface is not sufficient to handle a particular problem in the user system - let alone fix the problem.

[0016] A user system can be an appliance. The appliance can be, for example, a storage device such as an IBM Db2 database system. However, the appliance can be complex because it can be composed of many components that interact with each other. In different embodiments, the appliance can be any suitable computer system composed of software, hardware, or both. This can be a source of the second problem because the behavior of the appliance can be difficult to model or predict due to dependencies or other types of interactions between components. As a result, understanding and fixing errors or problems in a user system can be a very resource-consuming task, especially if it is not performed by a service provider (e.g., the manufacturer of the appliance or an authorized service provider). A detected error can be a defect or malfunction in the user system that causes the user system to produce incorrect or unexpected results, or behave in an unexpected manner. A detected error can be, for example, a software and / or hardware error.

[0017] The present subject matter can address these problems by providing a service provider’s problem management system that creates and provides a package for fixing a detected error. A user system can thus use the provided package to fix the error without having to find a correction locally in the user system. In another example, a script that executes predefined commands in the provided package can enable identification of one or more root causes, especially for hardware-based errors. The package can be referred to as a “service package.” A service package can collect diagnostic data. For example, if a hardware has a problem, the service package can execute a script that narrows down possible causes to find a root cause of the malfunction.

[0018] However, because the service package does not need to be run by the manufacturer of the appliance or an authorized service provider, a provided service package can be misused if the execution of one provided service package is not controlled (e.g., run on an unauthorized appliance). To this end, the present subject matter can use a signature to control the provision of a service package and the execution of a script, for example, a user system can only execute a script if the script has access to a public key. Additionally, by signing a package, it can be guaranteed that only scripts provided by a service provider can be executed on a user system. The signature can be a digital signature. A digital signature can be a mathematical scheme for verifying the authenticity of a package. The signature can be generated, for example, using a public-private pair of keys scheme.

[0019] The script of the service package provided can be named a correction script or a diagnostic script. It can provide the ability to either correct the detected error or perform a diagnosis of the detected error in order to identify the root cause. For example, it can be sufficient to use the service package to collect more diagnostic information about the detected error, and then a support engineer can use that service package to create another service package that includes the actual steps for correcting the detected error. In this case, the method further comprises, upon execution of the correction script, receiving diagnostic information about the detected error, and providing another service package based on the information collected. The user system can again verify the signature of the newly provided service package, and can execute the new script of the newly provided service package.

[0020] The subject matter can enable short turnaround time for problem / service requests. Furthermore, when a manufacturer of the device or an authorized service provider attempts to resolve a problem reported by a user, the service provider can employ a screen sharing session. These sessions are used to collect information for a particular problem and upload that information to a problem management system, or apply a work-around / fix, for example, by applying a software update package. An advantage of the embodiments herein is that there is no need to employ a screen sharing approach. When the problem is analyzed / fixed by the problem management system, the user can use the user system (device) because the user system is not blocked (e.g., analyzed by a support engineer via a screen sharing session using the user's workstation) when the problem is analyzed by the script of the service package running in the background.

[0021] According to one embodiment, the service package includes metadata. The metadata includes a maximum execution count, wherein the execution of the script is performed in response to determining that a number of previous executions of the script on the user system is less than the maximum execution count. This embodiment can enable setting a number of how many times (e.g., once or x times) a script can be executed to prevent re-execution and data leakage for select cases.

[0022] The signature of the package indicates the content of the metadata and the script provided by the problem management system. That is, any change to the metadata and / or the script can result in a non-authentication of the package. The execution of the script can use the metadata, for example, the metadata supports the initialization of one or more variables of the script. The same metadata that was used to authenticate the package is used to execute the script. If the metadata in the user system has changed, then the script can not be executed. For example, since the metadata is part of the data that is signed, it cannot be tampered with without breaking the signature. The user system can detect such illegal or unauthorized activity, and in response, the user system simply does not execute the script.

[0023] According to an embodiment, wherein the signed package is received from a problem management system configured to remotely connect to the user system, wherein determining that the number of previous executions of the script on the user system is less than the maximum execution count comprises: determining, by the user system, that the number of previous executions of the script on the user system is less than the 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.

[0024] For example, the check that the number of previous executions of the script is less than the maximum execution count can be performed by both the user system and the problem management system, and the script can only be executed if both checks are successful. If the check fails on the user system or the problem management system, the method comprises: exiting the check error by the user system and reporting the check error back to the problem management system. This embodiment can further improve control over the execution of scripts, as it requires both systems to agree on the number of times a script has been executed, for example, this can prevent the user system from executing a package without the agreement of the problem management system.

[0025] The number of previous executions of the script can be determined in different ways. For example, a log that keeps a history of executions in the user system can be used to determine the number in the user system. The problem management system can also use its own log (e.g. a log that records the provided packages) to determine the number.

[0026] According to an embodiment, the user system and the problem management system comprise an execution counter that indicates the number of previous executions of the script. The method further comprises incrementing the execution counter in the event that the execution of the script is successful. For example, upon receiving a report from the user system that indicates that the execution of the script was successful, the execution counter can be incremented in the problem management system. This can be particularly advantageous if the user system is configured to automatically report the result of the execution.

[0027] In another example, the execution counter can be incremented in the problem management system and in the user system each time the problem management system provides a package with the same script. This can be advantageous as the problem management system does not rely on the reporting of the user system to count the number of executions. This can for example prevent misuse cases where the user system (knowing the counting check feature) can not send a report in order to be able to further execute the package by exploiting the same existing count (beyond the allowed number of executions).

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

[0029] According to one embodiment, the detection of the error comprises: the automatic detection of the error by a monitoring unit of the user system or the detection of the error by a user of the user system; and the provision of the detected error to the problem management system, wherein the provision of the signature package is performed by the problem management system.

[0030] According to one embodiment, the user system can schedule the execution of the script using one of the following three execution methods: the execution of the script immediately after the determination that the package is authentic, or the execution of the script in a predefined maintenance time window; or the execution of the script after receiving a user approval to execute the script. Thereby, the script is provided such that the application of the script is customizable, e.g. such that the user can select the time slot in which the script is executed.

[0031] This embodiment can implement multiple scheduling policies. For example, if a customer sets the execution policy to "immediate" in his configuration, the scheduler of the user system will execute the script immediately after the script has been submitted. If a customer sets the execution policy to "approval" in his configuration, he needs to approve the execution of each script. The customer will be informed about each new script submitted to his system so that he can act in time. If a customer sets the execution policy to "maintenance window" in his configuration, he can define a maintenance window in his configuration. Scripts will only be executed in the maintenance window. If no maintenance window exists, but scripts are queued for execution, they can not be executed. The customer can first have to define a new maintenance window. These cases will be informed to the customer.

[0032] According to one embodiment, the method further comprises: providing a report on the execution results of the script and combining it with the package in a way that it is integrity protected. In one example, the user of the user system can transfer the execution results from the user system to his workstation in order to create the report and can upload the report from the workstation to the problem management system. In another example, the report can be created 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 can or can 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 before submitting it to the problem management system to check that no sensitive data is contained in the archive.

[0033] According to one embodiment, the provision of the signature package comprises one of: sending the service package to the user system via a secure connection established 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, when a script is to be executed, the user of the user system can download the service package to the user's workstation and then transfer it from the workstation to the user system.

[0034] According to one embodiment, the method is performed automatically. This can fix detected errors in time without relying on user intervention. For example, the error can be detected automatically by the user system, and a support request indicating the detected error can be sent automatically by the user system to the problem management system. The problem management system can automatically create the package and provide it to the user system upon receiving the support request. For example, the problem management system can use a history file comprising a mapping between previously detected errors and associated scripts. This file can be used by the problem management system to create the script by identifying an entry corresponding to the detected error in the file and the associated script. The service package can be derived, for example, based on devices of other user systems having similar problems solved by a particular (set of) service package.

[0035] The automatic execution of the script can be triggered by the problem management system. The user of the user system can allow such automatic execution by support from the problem management system to the user system where the script should be executed.

[0036] In another example, the manual execution of the script can allow the user to audit what is executed and what is sent to the problem management system.

[0037] According to one embodiment, the script is unencrypted. The method further comprises analyzing the script for logging one or more operations of the execution of the script in an audit log, and providing the audit log for enabling inspection of operations performed on the user system. This can allow the user to investigate the script. For example, the user can be requested to provide the audit log to an auditing authority (e.g. a tax authority) for auditing the script that has been applied to the user system.

[0038] The service package can be provided only upon user authentication of the user of the user system. The problem management system can check the authenticity of the user of the user system before providing the package. According to one embodiment, the method comprises receiving a support request from the user of the user system indicating the detected error, and authenticating the user, wherein the package is provided if the user is authenticated.

[0039] Figure 1A service system 100 is shown in accordance with examples of the present 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 can be configured to communicate with each of the computer systems 102a-n via one or more networks 103. To simplify the description, only one network is shown; however, the problem management system 101 can be connected to the computer systems 102a-n via more than one network, e.g., the problem management system 101 can be connected to each of the computer systems 102a-n via a respective network. For example, the network 103 can include, but is not limited to, a cable network, a fiber optic network, a hybrid fiber coaxial cable network, a wireless network (e.g., Wi-Fi and / or a mobile phone network), a satellite network, the Internet, an intranet, a local area network, any other suitable network, and / or any combination of these networks.

[0040] As shown, users 105a-n can be associated with the computer systems 102a-n (e.g., instances of the computer system 600), respectively. The users 105a-n can include viewers, owners, technical support personnel, etc. The users 105a-n can use workstations (not shown) in order to interact or communicate with the computer systems 102a-n and the problem management system 101. Each computer system 102a-n can include an appliance 104a-n. The appliance 104 can be a hardware-software appliance. For example, the appliances 104a-n can be IBM Db2 Analytics Accelerators. The users 105a-n can interact with the appliances 104a-n only through provided service interfaces, e.g., the users cannot access the appliances themselves. These service interfaces can not be sufficient to handle particular problems - let alone solve them. For example, the appliance can not provide the end user (customer) with the possibility to open a shell that can be used for problem analysis and repair. Thus, the users 105a-n can need to involve the creator / producer of the appliance 104a-n or an authorized service provider, as only very limited pre-provided generic service interfaces (such as trace / log file collections) are available to the end user.

[0041] The problem management system 101 provides support for the computer systems 102a-n. The problem management system 101 can be remote from the computer systems 102a-n, accessible over the network 103. When an error occurs on a computer system 102a-n, the problem management system 101 can handle at least a portion of the error handling. The problem management system 101 can provide a description of the error and a remedy for the error when the error occurs on the computer system 102a-n. The remedy can be provided in accordance with a problem management method, e.g., as described in U.S. Patent No. 9, 130, 858, which is incorporated by reference herein in its entirety. Figure 2The described. To this end, the problem management system 101 can be implemented by any combination of computing devices (e.g., servers, one or more instances of the computer system 600) that can serve a particular implementation.

[0042] The problem management system 101 can include a problem detection module 110, a support module 111, and a storage system 112 that are selectively and communicatively coupled to one another. The problem detection module 110 can be configured to receive (e.g., detect) support requests from the computer systems 102a-n. The support requests can be provided automatically or can be provided by the users 105a-n upon occurrence of an error in the computer systems 102a-n.

[0043] The support module 111 can be configured to perform one or more support session management operations as can serve a particular implementation. For example, the support module 111 can process information included in a support request, open a support ticket associated with the support request, and assign a unique ticket identifier associated with the support ticket to the support request in response to the support request being received by the problem detection module 110. For example, the support module 111 can use the ticket identifier to establish a remote control session to the computer system.

[0044] The storage system 112 can 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 including information about errors detected in the computer systems 102a-n.

[0045] Figure 2 is a block diagram of a service system 200 for a problem management method for supporting a computer system according to an example of the present subject matter. Figure 2 An example of the problem management method performed between the problem management system and one of the computer systems 102a-n is illustrated in Figure 1

[0046] The service system 200 can include a problem management system 201 and a computer system 202. The problem management system 201 is similar to Figure 1 the problem management system 101, and the computer system 202 is similar to Figure 1 ​The computer system 202 comprises an appliance 204. For example, the appliance 204 can be a DB2 system. The appliance 204 can be monitored automatically by the monitoring unit 221 or can be monitored with the help of the user 205. Thus, the error or problem in the appliance 204 can be detected automatically or manually in step Bl or Al, respectively. If the monitoring unit 221 detects an error, the central unit 220 can receive an indication of the error from the monitoring unit 221. Upon receiving the indication, the central unit 222 can automatically open (step B2) a problem management record in the problem management system 201. This can be performed, for example, by sending a support request to the problem management system 201 in step B2. If the error is detected manually, the user 205 can open (step A2) a problem management record in the problem management system 201. This can be performed, for example, by entering a support request to the problem management system 201, for example via an interface, in step A2. Upon receiving the support request, the problem management system 201 can automatically create a problem management record 214. As shown, the problem management record 214 can comprise information indicating the device 204, a description of the problem, diagnostic information, and a service package (comprising one or more service commands) provided, for example, signed, to resolve the problem. A support engineer 216 of the problem management system 201 can analyze (step Cl) the data of the problem management record 214 and can provide a service package accordingly (in step C2). In another example, the service package can be created automatically by the problem management system 201. The service package can comprise metadata and a payload. The payload can comprise a script to be executed (named a correction script) and one or more resource files containing additional information needed by the correction script in order to fix the error and / or to collect diagnostic information about the error. The metadata can comprise information indicating the creator of the service package, a serial number of the computer system 202, a maximum execution count of the correction script, for example, using a one-time password, a name of the correction script to be executed, a name of a file containing the execution results, and a signature indicating the content of the data packet. The service package can be provided to the user 205 or to a service command scheduling and execution engine 223 of the computer system 202. If the service package is provided to the user 205, the user 205 can trigger (step C3a) the execution of the correction script through the service command scheduling and execution engine 223. If the service package is provided to the service command scheduling and execution engine 223, this can automatically trigger (step C3b) the service command scheduling and execution engine 223 to schedule the execution of the correction script. The correction or diagnostic script can be executed on the appliance in step C4, for example, in order to fix the detected error. The execution results of the correction script can be used to update (step C5) the PMR 214 and to populate an audit log file 224 of the computer system 202. The audit log file 224 can also be stored in the problem management system 201.The audit log file 224 can contain the full service package (metadata and payload) that submitted the service package for execution (which can only be known on the customer system when using the automated approach), the full execution results, the time the correction script was submitted for execution, the time the execution started, the time the execution completed, configuration details about the execution scheduling policy, who audited and approved the execution results and when (if approval is required), log creation of the script in the problem management system 201 and log execution of the script on the device 204.

[0047] Figure 3 is a flowchart of a problem management method for a user system according to an example of the present subject matter. For the purpose of explanation, Figure 3 The method described in Figures 1-2 The system illustrated in

[0048] The error can be detected in step 301 in the user system 202. The detected error can for example have one or more predefined error codes, such as DB2 error codes. The error can for example be associated with an error description provided by the user system 202. For example, if someone is locking the data that the device is using, the error description can indicate an unavailable resource. The error can be detected automatically by the user system 202 using the monitoring unit 221 and can be reported to the problem management system 201. In another example, the error can be detected by the user 205, for example using a service interface on his workstation, where the service interface displays the results monitored by the monitoring unit 221. The user 205 can use the workstation to report the error to the problem management system 201.

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

[0050] In one example, the correction script can be determined automatically by the problem management system, e.g. using a mapping between known errors and associated correction scripts. The mapping can for example map error codes with correction scripts that can for example fix the problem with the error code respectively. The problem management system can be able to maintain a history of corrective actions based on the experience of other users. These corrective actions can be used to provide the correction script.

[0051] The user system 202 can verify the authenticity of the correction script with the signature in step 305. If the script is authentic (query step 307), the user system 202 can execute the correction script in step 309; otherwise, the correction script can not be executed and an inspection error can be reported to the problem management system in step 311.

[0052] The execution of the correction script can be successful or not. If not, the user system 202 can send a report error to the problem management system 201. In response, the problem management system 201 can for example send another signed package with another correction script and steps 305 to 309 can be repeated with this other service package.

[0053] The execution of steps 305 to 309 can be controlled by the problem management system 201, e.g. the problem management system 201 can trigger the execution of steps 305 to 309 via a direct connection between the problem management system 201 and the user system 202, e.g. by sending a control command to the user system and upon receipt of the control command, the user system can schedule the execution of steps 305 to 309, e.g. according to an "immediately" policy or a "maintenance window" policy. This can be advantageous because the problem management system 201 can control when the execution of the correction script is scheduled.

[0054] After the execution (successful or not), the execution results can be collected by the user system 202. The data being collected can be defined in the metadata of the package. Furthermore, the return code of the script execution and everything written to STDOUT and STDERR during the script execution can be captured, written to a file and included in the execution results. The execution results can 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 submitting the archive to the problem management system. When using Figure 3When the method of automatic execution of the script is used, the client / user 205 can decide whether to review the data before submitting it to the problem management system. If this is set, the client can be notified that the execution results are available for review and approval. If he approves, the data can be automatically uploaded to the problem management system via a secure connection. When the manual execution is used, it is the client's responsibility to manually upload the execution results to the problem management system. In this case, he has the possibility to check the data contained in the archive file. If he approves, he uploads the data to the problem management system.

[0055] Figure 4 is a flowchart for repairing or diagnosing an error detected in a user system according to an example of the present subject matter. For the purpose of explanation, Figure 4 The method described in Figures 1-2 The system illustrated in Figure 4 The method of can enable the automatic execution of a correction script. The correction script can support the repair or diagnosis of a detected error. A user of a user system can allow such automatic execution by supporting a direct communication from the problem management system to the user system for which the correction script should be executed. In this case, the problem management system can trigger Figure 4 The following sequence of actions of the method of

[0056] In step 401, the problem management system 201 requests the execution of a correction 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 transmits a signed package including the correction script to the user system 202. In step 407, the problem management system 201 triggers the execution of the correction script on the user system 202, for example the problem management system 201 triggers Figure 4the remaining steps of the method. The user system 202 validates the signature of the package in step 409. If (query step 411) it is valid, the user system 202 continues with step 413 in the process, if not, it exits and reports an error to the problem management system 201 in step 429. In step 413, the user system 202 validates the sequence number in the package and compares it to the user system's sequence number. If (query step 415) the comparison is successful, it continues to step 417 of the process, if not, it exits and reports an error to the problem management system 201 in step 429. In step 417, the user system 202 checks if this particular correction script has already been executed before. In addition to this, the problem management system 201 checks if this correction script has already been executed on the user system 202 before. The user system 202 and the problem management system 201 can check if the maximum number of executions (stored in the user system 202 and the problem management system 201) has already been reached. If (query step 417) this check fails on the user system 202 or the problem management system 201, the user system 202 exits and reports an error back to the problem management system 201 in step 429. If (query step 417) no, the process continues to step 421. In step 421, the user system 202 schedules the correction script for execution. In case of successful execution (query step 423), the user system 202 can report the execution result to the problem management system 201 in step 425 and the user system 202 and the problem management system 201 can increase the execution counter of this correction script by one in step 427. In case of unsuccessful execution, an error can be reported in step 429, for example.

[0057] Figure 5A 、 Figure 5B a flowchart for repairing or diagnosing an error detected in a user system according to an example of the present subject matter is depicted. For the purpose of explanation, the method described in Figure 5A 、 Figure 5B The method described in Figures 1-2 may be implemented in the system shown in

[0058] In step 501, the problem management system 201 requests manual execution of the correction script by attaching the signed package to the problem management system 201 and a message requesting execution to the customer 205. The correction script can support fixing or diagnosing a detected error. In step 503, the customer downloads the package to his workstation. In step 505, the customer transfers the package from his workstation to the user system 202, where the script shall be executed. In step 507, the customer schedules execution of the script, for example by selecting the script from a list of available scripts on the user system in a service interface and by clicking an execute button. This step 507 can include a way to specify the execution schedule, for example, immediately or in the future within a maintenance period.

[0059] The user system 202 verifies the signature of the package in step 509. If (query step 511) it is valid, the user system 202 continues the process in step 513, if not, it exits 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 data package and compares it to the serial number of the user system. If (query step 515) the comparison is successful, it continues to step 517 of the process, if not, it exits and reports an error back to the problem management system 201 in step 531. In step 517, the user system 202 checks whether the particular correction script has already been executed before. In addition, the problem management system 201 checks whether this correction script has already been executed on the user system 202 before. The user system 202 and the problem management system 201 can now check whether the maximum number of executions (stored in the user system 202 and the problem management system 201) has already been reached. If (query step 517) this check fails on the user system 202 or the problem management system 201, the user system 202 exits and reports an error back to the problem management system 201 in step 531. If (query step 517) no, the process continues with step 521.

[0060] The user system schedules the script for execution in step 521 and saves the execution result locally. In case of a successful execution (query step 523), the user system can increase the execution counter of this script by one in step 529. In step 525, the customer transfers the execution result from the user system 202 to his workstation. In step 527, the customer transfers the execution result from his workstation and uploads the execution result to the problem management system 201. The problem management system 201 can save the execution result. The problem management system 201 can increase the execution counter of this script by one. In case of an unsuccessful execution, an error can be reported in step 531, for example.

[0061] Figure 6represents a general computerized system 600 suitable for implementing at least a portion of the method steps as referred to in this disclosure.

[0062] It will be appreciated that the methods described herein are at least partially non-interactive and are performed automatically by a computerized system such as a server or embedded system. However, in exemplary embodiments, the methods described herein can be implemented in (partially) interactive systems. The methods can further 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 special or general digital computer (such as a personal computer, workstation, minicomputer, or mainframe computer). The most general system 600 therefore includes a general computer 601.

[0063] In exemplary embodiments, in terms of hardware architecture, as shown in Figure 6 the computer 601 includes a processor 605, memory (main memory) 610 coupled to a memory controller 615, and one or more input and / or output (I / O) devices 10, 645 (or peripherals) communicatively coupled via a local input / output controller 635. The input / output controller 635 can be, without limitation, one or more buses or other wired or wireless connections, as is known in the art. The input / output controller 635 can have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface can include address, control, and / or data connections to enable appropriate communications among the aforementioned components. The I / O devices 10, 645 can generally include any input and / or output devices known in the art, including but not limited to a general purpose I / O card or smart card as described herein.

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

[0065] The memory 610 can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)) and nonvolatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), programmable read only memory (PROM)), and the like. Note that the memory 610 can have a distributed architecture, where different components are situated remote from one another, but can be accessed by the processor 605.

[0066] The software in the memory 610 can include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions (and particularly those functions described in the embodiments of the application). In the Figure 6 In the example of FIG. 6, the software in the memory 610 includes, for example, instructions 612. The instructions manage a database, such as a database management system.

[0067] The software in the memory 610 is generally also arranged to include a suitable operating system (OS) 611. The OS 611 is essentially the fundamental program that controls all of the resources of the computer and that coordinates the activities of all the programs and applications on the computer, such as the possible software 612 for implementing the methods described herein.

[0068] The methods described herein can be in the form of source program 612, executable program 612 (object code), script, or any other entity comprising a set of instructions which when executed by a machine, such as the computer 600, cause the machine to perform functions. When in the form of source program 612, the program is translated via a compiler, assembler, interpreter, or the like, which can or can not be included within the memory 610, so as to operate in conjunction with the OS 611 to perform the functions of the program. Furthermore, the methods can be written as an object oriented programming language, which has classes of data and methods, and a graphical programming language, which has modules that can be configured and rearranged to solve a particular problem. The methods can also be implemented using a rule based system or a framework that applies a set of rules in a specific sequence, or in parallel.

[0069] In exemplary embodiments, a conventional keyboard 650 and mouse 655 can be coupled to the input / output controller 635. Other output devices such as the I / O device 645 can include input devices such as, but not limited to, a printer, a scanner, a microphone, etc. Finally, the I / O devices 10, 645 can also include devices that communicate both inputs and outputs, such as but not limited to, a network interface card (NIC) or modulator / demodulator (modem) used to access other files, devices, systems, or networks, a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The I / O devices 10, 645 can be any general purpose

[0070] If the computer 601 is a PC, workstation, intelligent device or the like, software in the memory 610 can also include a basic input output system (BIOS) 622. The BIOS is a set of basic software routines that initialize and test hardware, start the OS 611 and support the transfer of data between the hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when the computer 601 is activated.

[0071] When the computer 601 is in operation, the processor 605 is configured to execute software 612 stored within the memory 610, to communicate data to and from the memory 610, and to generally control operations of the computer 601 pursuant to the software. The methods and OS 611 described herein are read, possibly cached, and executed by the processor 605.

[0072] When implementing the systems and methods described herein in software 612, as Figure 6As shown, the methods can be stored on any computer-readable medium (e.g., storage 620) for use by or in connection with any computer-related system or method. The memory 620 can include a disk storage such as HDD storage.

[0073] The present application can be a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0074] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is 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 of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium 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 punch cards or raised structures in grooves of a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0075] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0076] Computer readable program instructions for carrying out operations of the present application can be assembly 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 code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0077] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0078] These computer readable program instructions can be provided to a processor of a computer, or other programmable data processing apparatus, to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

[0079] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0080] The computer program product can have a signal bearing medium (or media) 110 with instructions 112 for carrying out the functions of the system, methods, and computer program products of the present application.

Claims

1. A method for problem management of a user system, the method comprising: detecting an error in the user system provided by a service provider, wherein the user accesses the service provider through a service interface; receiving, by the user system, a signature package according to the detected error, the signature package comprising at least a correction script or a diagnostic script, wherein the correction script or the diagnostic script is used by the service provider to correct or diagnose the detected error without having to look up a correction or diagnosis locally at the user system; verifying, by the user system, authenticity of the signature package using a signature of the signature package; and if the signature package is authentic, executing, by the user system, the correction script or the diagnostic script, wherein the correction script or the diagnostic script identifies one or more root causes of the error.

2. The method of claim 1, wherein the signature package comprises metadata, the metadata comprising a maximum execution count; and wherein the execution of the script is performed in response to determining that a number of previous executions of the script on the user system is less than the maximum execution count.

3. The method of claim 2, wherein the signature package is received from a problem management system, the problem management system configured to remotely connect to the user system, and wherein determining that the number of previous executions of the script on the user system is less than the maximum execution count comprises: determining, by the user system, that the number of previous executions of the script on the user system is less than the 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.

4. The method of claim 3, wherein the user system and the problem management system comprise an execution counter that indicates the number of previous executions of the script, the method further comprising incrementing the execution counter in the event that the previous execution of the script is successful.

5. The method of claim 1, wherein the signature package comprises metadata, the metadata comprising a unique identifier of the user system, and wherein the execution of the script is performed in response to determining that the user system has the unique identifier.

6. The method of claim 1, wherein detecting the error further comprises: detecting, by a monitoring unit of the user system, the error automatically or detecting, by a user of the user system, the error; and providing, to a problem management system, the detected error, wherein the providing of the signature package is performed in response to the receiving of the detected error by the problem management system.

7. The method of claim 1, wherein the execution of the script is performed: immediately after determining that the signature package is authentic; in a predefined maintenance time window; or after receiving user approval for execution of the script.

8. The method of claim 1, further comprising: ​ ​ ​ sending a service package to the user system via the established secure connection between the user system and the problem management system, the service package being a package for fixing the detected error; or downloading the service package from the problem management system to the user system.

9. The method of claim 1, the method being performed automatically.

10. The method of claim 1, wherein the script is unencrypted, the method further comprising: analyzing the script for recording one or more operations performed by the script in an audit log; and providing the audit log for supporting an examination of operations performed on the user system.

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

12. The method of claim 1, wherein the user system comprises a device database system.

13. The method of claim 1, wherein a signature of the signed package is verified using a public-private pair of keys scheme.

14. A computer program product comprising a computer readable storage medium, the computer readable storage medium comprising computer readable program code embodied therewith, the computer readable program code being configured to perform the steps of the method according to any one of claims 1 to 13.

15. A computer system comprising a processor and a computer readable storage medium, the computer readable storage medium having computer readable program code embodied therewith, the computer readable program code being configured to perform the steps of the method according to any one of claims 1 to 13.

16. A computer system comprising means for performing the steps of the method according to any one of claims 1 to 13.

Images