Automatic Control of Distributed Computing Devices

Abstract

To provide a system and a method for remotely controlling distributed computing devices.SOLUTION: A method in a distributed computing system 100 includes: receiving, by a client device, a service ticket corresponding to an undesired system state; adjusting a remote control session between a technician device and the client device; obtaining a set of actions performed under remote control by a technician to transition the client device from the undesired system state to a desired system state, where each action of the set of actions represents one or more user interface (UI) interactions with the client device; selectively modifying the set of actions in response to receiving input from the technician; and selectively replaying the set of actions from a resolution profile (RP) on a second client device, where the RP is based on the modified set of actions and identified keywords.SELECTED DRAWING: Figure 1

Description

Cross - reference to related applications

[0001] This application is a PCT international application based on U.S. Provisional Application No. 62 / 693,410 filed on July 2, 2018. The entire disclosure of the above application is incorporated herein by reference.

Technical Field

[0002] The present disclosure relates to distributed computing devices, and more particularly, to an apparatus and method for remotely controlling a distributed computing device.

Background Art

[0003] In an environment where computers exist, computer users may encounter various incidents on their computers. For example, there is a possibility that the user cannot save a file to a network hard drive, cannot print a document, cannot start a specific application, etc. The user may contact an information technology (IT) technician who is likely to have the knowledge and resources to solve the incident. However, there may be cases where the technician cannot provide immediate assistance to the user, such as when the technician is assisting other users or when the incident occurs outside normal business hours.

[0004] Once the technician becomes available to provide assistance, before the technician remotely connects to the user's computer, the technician must request permission from the user and obtain approval from the user. The technician may perform a set of actions to solve the user's incident. In response to solving the incident, the technician may discuss the solution with other technicians so that if other technicians encounter the same incident, they can perform a similar solution.

[0005] The description of the background art provided herein is for the purpose of generally indicating the context of the disclosure. The current inventors' research does not, to the extent described in this background art section, nor in the manner of description that could not otherwise be prior art as of the filing date, expressly or implicitly, admit as prior art to this disclosure.

Summary of the Invention

Problems to be Solved by the Invention

[0006]

Means for Solving the Problems

[0007] The system has at least one processor and a non-transitory computer-readable medium configured to store instructions for execution by the at least one processor. The instructions include receiving a service ticket corresponding to an undesired system state of a client device. The instructions include assigning the service ticket to a technician. The instructions include coordinating a remote control session between the technician device and the client device, where the technician device is under the control of the technician. The instructions include obtaining, under remote control, a set of actions to be performed by the technician to transition the client device from the undesired system state to a desired system state, where each action in the set of actions represents an interaction with one or more user interfaces (UIs) of the client device. The instructions include identifying a set of keywords based on characteristics of the service ticket. The instructions include associating the identified keywords with the set of actions. The instructions include presenting the set of actions and the identified keywords to the technician. The instructions include selectively modifying the set of actions in response to an input from the technician. The instructions include saving a resolution profile (RP) in response to technician approval, where the RP is based on the modified set of actions and the identified keywords. The instructions include selectively reproducing, in a second client device, the set of actions from the RP in response to receiving a second service ticket submitted for the second client device.

[0008] In other features, each action in the set of actions is stored in a basic resolution step (BRS) data structure, the BRS data structure conforms to the BRS data structure definition, and the RP encodes the execution order of the BRS data structure. In other features, the first BRS data structure corresponding to the first action in the set of actions includes a screenshot of the client device captured before the first action is executed. In other features, the first BRS data structure stores a command, and in the command, the execution causes the client device to transition from an undesired system state to a second system state.

[0009] In other features, the first action in the set of actions includes at least one of a mouse event and a keyboard key press event. In other features, in response to the second client device being in an undesired system state, the instruction includes playing back the RP on the second client device. In other features, the RP is stored as a collection of files that correspond one-to-one with the set of actions. In other features, obtaining the set of actions includes receiving the set of actions from one of the client device or the technician device at the end of the remote control session.

[0010] In other features, obtaining the set of actions includes recording the set of actions as sent by the technician device to the client device. In other features, assigning a service ticket to a technician is performed in response to a ticket request by the technician. In other features, the instruction includes changing a set of keywords in response to a change request from the technician.

[0011] In other features, the set of keywords includes at least one of the operating system type and the name of the application. In other features, the instruction includes generating a service ticket from at least one of a web browser, an email interface, a chat interface, and a phone. In other features, the instruction includes selectively converting the RP to a knowledge base (KB) article for sharing with other technicians after saving, where the KB article includes serialized RPs.

[0012] The method includes receiving a service ticket corresponding to an undesired system state of a client device. The method includes assigning the service ticket to a technician. The method includes coordinating a remote control session between the technician device and the client device. The technician device is under the control of the technician. The method includes obtaining a set of actions to be performed by the technician under remote control to transition the client device from the undesired system state to a desired system state. Each action in the set of actions represents an interaction with one or more user interfaces (UIs) of the client device. The method includes identifying a set of keywords based on the characteristics of the service ticket. The method includes associating the identified keywords with the set of actions. The method includes presenting the set of actions and the identified keywords to the technician. The method includes selectively modifying the set of actions in response to input from the technician. The method includes saving a resolution profile (RP) in response to technician approval. The RP is based on the modified set of actions and the identified keywords. The method includes selectively reproducing a set of actions from the RP on a second client device in response to receiving a second service ticket submitted for the second client device.

[0013] In other features, each action in the set of actions is stored in a basic resolution step (BRS) data structure, and the BRS data structure complies with the BRS data structure definition. The RP encodes the execution order of the BRS data structure. In other features, the first basic resolution step (BRS) data structure corresponding to the first action in the set of actions includes a screenshot of the client device captured before the first action is executed. The first BRS data structure stores a command, and in the command, the execution causes the client device to transition from an undesired system state to a second system state. In other features, the method includes playing back the RP on a second client device in response to the second client device being in an undesired system state. In other features, the RP is stored as a collection of files that correspond one-to-one with the set of actions.

[0014] In other features, obtaining a set of actions includes at least one of receiving a set of actions from one of a client device or a technician device at the completion of a remote control session, and recording the set of actions as being sent from the technician device to the client device. In other features, assigning a service ticket to a technician is performed in response to a ticket request by the technician. This method includes changing a set of keywords in response to a change request from the technician. In other features, the first action of the set of actions includes at least one of a mouse event and a keyboard key press event. The set of keywords includes at least one of an operating system type and an application name. In other features, this method includes generating a service ticket from at least one of a web browser, an email interface, a chat interface, and a phone. In other features, this method includes selectively converting the RP to a knowledge base (KB) article for sharing with other technicians after saving. The KB article includes serialized RPs.

[0015] Further applicable areas of the present disclosure will become apparent from the embodiments for carrying out the invention, the claims, and the drawings. The embodiments for carrying out the invention and the specific examples are for illustrative purposes only and are not intended to limit the scope of the disclosure.

[0016] The present disclosure will be more fully understood from the embodiments for carrying out the invention and the accompanying drawings.

Brief Description of the Drawings

[0017]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 9

DETAILED DESCRIPTION OF THE INVENTION

[0018] In the drawings, reference numerals may be reused to identify similar and / or identical elements.

[0019] <Introduction> According to the present disclosure, a distributed computing system can record a set of actions and an accompanying screenshot of a client device during a remote control session. The recording can be saved on the client device during the remote control session. Through the remote control session, a technician can remotely execute a set of actions on the client device to resolve a service ticket. Each action in the set of actions represents an interaction with one or more user interfaces (UIs) of the client device, such as, for example, mouse events and / or keyboard events. The service ticket may correspond to an undesired system state of the client device. The service ticket can include an incident, a request, a request not specific to the system state of the client device (e.g., creating a mail system distribution list, resetting login credentials, etc.). For example, the undesired system state may be an issue that the user of the client device is experiencing on the client device, which is also referred to as an incident. As another example, the undesired system state may be the absence of a specific application on the client device, which is also referred to as a request.

[0020] When the recording is complete, the recording is compressed and sent from the client device to the control server. In various embodiments, the recording can be executed on the control server or on a technician device operated by the technician. A set of keywords can be identified based on the characteristics of the service ticket. The set of keywords can be associated with the recording.

[0021] A set of records and keywords is presented to the engineer. The engineer can review and modify the set of records and keywords. The engineer can delete some actions from the set of actions because those actions may be irrelevant or redundant. The engineer can also add annotations (such as arrows, highlights, text, labels, etc.) to the screenshots. The engineer can add explanations (such as additional instructions - scroll the window down, etc., comments, etc.) to the actions. When the review and editing are completed, the modified set of actions and the set of keywords can be saved as a solution story.

[0022] The solution story represents a set of actions performed by the engineer during a remote control session. The solution story can be presented to other engineers to explain to them how to solve a service ticket. In various embodiments, the solution story can be shown to the user to explain the set of actions performed by the engineer.

[0023] The solution story can also be used to quickly solve a second service ticket submitted for a second client device operated by a second user. In various embodiments, the service ticket can be automatically submitted in response to an anomaly detected by an anomaly detection process that receives monitoring data such as performance metrics.

[0024] The second service ticket is classified using, for example, natural language processing (NLP) and / or machine learning. Once the second service ticket is classified, the shortest path corresponding to the optimal approach for resolving the second service ticket is determined. For example, the shortest path is determined according to one or more criteria such as, for example, time to resolution, number of changes, presence or absence of a need for restart, etc. If a set of actions from the solution story contributes to the shortest path, the set of actions from the solution story can resolve the second service ticket by being executed on the second client device.

[0025] <Environment> FIG. 1 is a block diagram of an exemplary distributed computing system 100. The distributed computing system 100 includes a control server 102, client devices 104, and technician devices 106. The control server 102, client devices 104, and technician devices 106 can communicate with each other via a network 107 such as, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, and / or other types of networks. For the sake of simply explaining that the control server 102 can be provided according to a software-as-a-service (SaaS) model or can be provided using cloud infrastructure, the control server 102 is shown within the network 107. The control server 102, client devices 104, and technician devices 106 can connect to the network 107 using wireless and / or wired connections. The client devices 104 and technician devices 106 can be located at different geographical locations from the control server 102. The client devices 104 can be located at different geographical locations from the technician devices 106.

[0026] Each of the client device 104 and the technician device 106 can be, for example, a tablet, a laptop computer, a personal computer (PC), or the like. The client device 104 includes a web browser 108 and a remote assistance agent 110. For example, the remote assistance agent 110 can be provided by an operator who controls the control server 102.

[0027] A user of the client device 104 can log in to a web portal and open a service ticket using the web browser 108. The service ticket may be related to an incident - that is, an abnormal or unexpected behavior (for example, inability to access an existing file), or a request for a better or different functionality (for example, ability to access a new file store). The incident or request may be resolvable using the client device 104 alone (possibly requiring special administrator privileges), using another resource alone (such as something that configures a mail server), or may require the client device 104 and one or more other resources. This application is applicable to all three scenarios, but for the sake of brevity of explanation, the scenario where the service ticket can be resolved using the client device 104 alone will be described below.

[0028] The current state of the system (of which client device 104 is a part) can be described as undesirable - for example, an incident has revealed an abnormal operation, or a request indicates some recognized defects, etc. Therefore, the service ticket corresponds to an undesirable system state that is different from the desired system state of client device 104. As a further example, a malfunction where an already installed application does not open can be expressed as an incident - on the other hand, when a user cannot launch a specific application on the client device, a request for a new application to be installed may be made.

[0029] The user may need to insert, for example, a title, a description of the symptoms that occurred, contact information (such as name, username, email address, phone number, etc.) into certain fields of the service ticket before the service ticket is submitted. Some fields of the service ticket, such as contact information, may be automatically inserted, such as tracking fields like ticket creation date, ticket ID, ticket number, etc. These types of fields may be called automatically inserted fields.

[0030] The technician operating the technician device 106 may need to insert, for example, the technician's contact information (such as name, email address, phone number, etc.), the priority of the ticket, the source of the ticket, etc. into certain fields of the service ticket. Once the user submits a service ticket, a notification may be sent to the technician device 106 to inform the technician that a new service ticket has been received. The technician can use the web browser 118 to view the service ticket by logging into the ticket management system. The technician can request an assignment of the service ticket. Depending on the service ticket assigned to the technician, the technician can remotely connect to the client device 104 to diagnose and resolve the service ticket.

[0031] The web browser 118 can send an initialization request for remote control to the client control module 112 via the control server 102. The initialization request for remote control is to request the user's consent to the remote control session. In some embodiments, the user may have given consent in advance - in which case, the user does not need to be present for the start of the remote session. Once consent is given by the user, the remote control software 120 establishes a remote control session with the client control module 112 via the network 107. Through the remote control session, the technician can remotely control the client device 104. In various embodiments, the client control module 112 can be Splashtop remote control software, TeamViewer remote control software, or other types of remote control software.

[0032] In response to the establishment of a remote control session, the recording module 116 records the remote control session. During the remote control session, a technician can use an input device to execute a set of actions to resolve a service ticket. For example, input devices such as a keyboard, touchpad, mouse, touch screen, etc. can be connected to the technician device. Each action in the set of actions represents an interaction with one or more user interfaces (UIs) with the client device 104. The UI interaction can correspond to a mouse event of the mouse and / or a key of the keyboard. For example, the mouse event can be a button down, button up, click (e.g., button up follows immediately after button down), etc. A key press can be represented as a key down followed immediately by a key up.

[0033] As described above, each action in the set of actions represents an interaction with one or more UIs. For example, a dialog box can include five check boxes that are all unchecked. A technician can execute a mouse event (e.g., click) on the check box to mark it as checked. Checking all five check boxes may require five mouse events - one mouse event for each check box. In this case, the five mouse events can be collectively referred to as one action. In other cases, the five mouse events can be recorded as five individual actions - each mouse event corresponding to one action.

[0034] The recording of a remote control session can include a set of actions and screenshots of the client device 104 before each action is executed. For example, if a technician opens a window, then scrolls the window down to a text box, and then enters text into the text box, two screenshots can be recorded. The first screenshot can include the opened window, and the second screenshot can include the text box with the entered text. The screenshots of the client device 104 can be recorded before the first action is executed. For example, if a technician wants to close a dialog box, the technician can manipulate the mouse pointer on X before executing a mouse event (e.g., click) on X. The screenshot can include the mouse pointer on X rather than the result of executing the mouse event on X. In various embodiments, screenshots can be recorded after the execution of the first action.

[0035] In response to the end of the remote control session, the recording is completed. The remote control session can end when the technician disconnects from the client device 104. The recording can be compressed (e.g., using the rar or zip format) and sent to the control server 102. In various embodiments, during the remote control session at various time intervals (e.g., every minute, every three minutes, every ten minutes, etc.), the recording can be sent partially to the control server 102. Although the recording module 116 is shown and represented as being located on the client device 104, the recording module 116 and the recording can be located on the control server 102, the technician device 106, or another location.

[0036] The monitoring module 114 monitors the metrics of the client device 104, which can include performance metrics, installed applications, user lists, and the like. The metrics can include, for example, system resources of the client device 104 such as processor utilization rate, memory (e.g., volatile or non-volatile memory, cache, etc.) utilization rate, mass storage device (e.g., flash memory, magnetic hard disk drive (HDD), etc.) utilization rate, network connectivity (e.g., wired, wireless, etc.). The monitoring module 114 can send the metrics to the control server 102 based on a predetermined schedule. For example, the predetermined schedule can be once a day, twice a day, once a week, etc. In various embodiments, in response to an anomaly detected in the metrics, the metrics can be sent immediately to the control server 102. In various embodiments, a notification informing that an anomaly has been detected in the metrics can be sent to the technician. Information from the monitoring module 114 (e.g., operating system, installed RAM, patch level, CPU utilization, etc.) can be added to the service ticket created for the client device 104.

[0037] Figure 2 is a functional block diagram of an exemplary embodiment of the control server 102. The control server 102 includes a web portal 202, an email interface 204, a chat module 206, a ticket management module 208, a ticket database 210, a remote adjustment module 212, a solution story creation module 214, a metrics data store 216, an anomaly detection module 218, an automation module 220, a manual creation module 222, and a solution story data store 224.

[0038] The user can log in to the web portal 202 and open a service ticket using the web browser 108. The ticket management module 208 can generate a service ticket based on the provided fields and can also automatically insert into certain specific fields.

[0039] In various embodiments, for example, using email, chat, or phone, the user can directly contact the help desk or technician. The email interface 204 can identify relevant information from the user's email and can automatically insert it into the fields of the service ticket based on that relevant information.

[0040] The chat module 206 can identify relevant information provided in a chat conversation exchanged between the user and the technician or help desk staff. The ticket management module 208 generates a service ticket based on the relevant information. The chat conversation exchanged between the user and the technician can be attached to the service ticket. The service ticket can be generated after the chat conversation ends. In various embodiments, the service ticket can be generated during the chat conversation. In various other embodiments, the ticket can be generated from relevant information exchanged during a phone call between the user and the technician.

[0041] The ticket management module 208 generates and manages service tickets received from various sources including the web portal 202, the email interface 204, and the chat module 206. Technicians can view service tickets including the status of the service tickets (e.g., waiting for assignment, open, in progress, closed, etc.) by logging into the ticket management module 208 from the web browser 118. The ticket management module 208 can assign service tickets marked as "waiting for assignment" to available technicians. The ticket management module 208 can assign the service ticket to the technician who requested the service ticket or to the technician with the most relevant knowledge about the characteristics of the service ticket. For example, if the service ticket indicates a network connectivity incident, the technician most knowledgeable about the network can be assigned to resolve the service ticket. Once the ticket is assigned to a technician, the ticket management module 208 can update the status of the service ticket from "waiting for assignment" to "open", and the ticket management module 208 can send a notification to the technician informing the technician that the service ticket has been assigned.

[0042] In response to the notification, the technician can select the corresponding service ticket from the ticket management module 208. The technician can insert a part of the technician field of the service ticket. Additionally, the ticket management module 208 enables the technician to view a list of all open service tickets assigned to the technician under the "open" status.

[0043] When the technician is ready to resolve the service ticket, the technician can remotely connect to the client device 104. The web browser 118 can send an initialization request for remote control to the client control module 112 via the remote adjustment module 212. Once consent is given by the user of the client device 104, the remote control software 120 can directly establish a remote control session with the client control module 112. The ticket management module 208 can update the status of the service ticket from "open" to "in progress" in response to the remote control session.

[0044] The recording module 116 is configured to record the remote control session. The ticket management module 208 can update the status of the service ticket from "in progress" to "closed" in response to the end of the remote control session by the technician. When the remote control session ends, the recording can be compressed and sent to the resolution story creation module 214. The recording can be viewed and modified by the technician before being saved as a resolution story in the resolution story data store 224. The resolution story can be a record representing the set of actions performed by the technician during the remote control session. The resolution story can be presented to other technicians to explain how the service ticket was resolved, shown to the user to explain the set of actions performed by the technician, and also used to automatically execute the set of actions from the resolution story on the second client device in response to receiving a second service ticket submitted for the second client device.

[0045] The manual creation module 222 manually creates each action among a set of actions. For example, a technician can create a text document that includes one or more UI interactions, constructed as a JavaScript Object Notation (JSON) document. The manually created actions can also include screenshots manually recorded by a technician using a screenshot manipulation application (such as the Windows® Snipping Tool). Additionally or alternatively, the manual creation module 222 can manually create each action among a set of actions by converting knowledge base (KB) articles into a set of actions. The manually created solution stories are stored in the solution story data store 224.

[0046] The metrics data store 216 receives metrics of the client device 104 from the monitoring module 114. The anomaly detection module 218 processes the metrics stored in the metrics data store 216 and detects anomalies in the metrics, such as a deviation outside the historical behavior envelope range. Once an anomaly is detected, the anomaly detection module 218 can identify relevant information from the metrics and generate a service ticket based on the relevant information. The ticket management module 208 generates a service ticket based on mandatory fields and automatically inserted fields.

[0047] The automation module 220 attempts to automatically resolve a new service ticket based on the saved solution story. If a relevant solution story is available, the remote adjustment module 212 can establish a connection between the automation module 220 and the client control module 112. Once the connection is established, the automation module 220 can reproduce the UI interactions saved as part of the solution story by communicating directly with the client control module 112. The automation module 220 can be fully automated, so that a particular service ticket can be automatically resolved without any intervention by a technician. In various embodiments, the automation module 220 can be partially automated, so that a particular service ticket can be resolved with the help of a technician. For example, the technician can select which actions of the solution story to execute, and the automation module 220 can execute the selected actions to resolve the service ticket.

[0048] <Solution Story Creation> Figure 3 is a functional block diagram of an exemplary embodiment of the solution story creation module 214. The solution story creation module 214 includes a recording data store 302, a keyword identification module 304, a review module 306, and a solution story approval module 308. The solution story creation module 214 can generate a solution story based on the recording received from the recording module 116. The recording is stored in the recording data store 302. The solution story can include a recording representing a set of actions performed by a technician during a remote control session. The solution story can be stored as a set of basic resolution step (BRS) data structures stored within a resolution profile (RP) data structure. Each action of the set of actions is stored as a BRS as described in FIG. 4, and the BRS conforms to the BRS data structure definition. The RP is a data structure that stores or includes a pointer to the BRS for each action.

[0049] The keyword identification module 304 identifies a set of keywords based on the characteristics of the service ticket. The keyword identification module 304 can identify a set of keywords, for example, from text such as a title and / or description associated with the service ticket. The keyword identification module 304 can identify a set of keywords using, for example, natural language processing (NLP). If NLP cannot identify any keywords, the set of keywords may initially be an empty set. The characteristics of the service ticket can include the operating system type of the client device 104, the application name, and / or the hardware category (e.g., network hardware, printer hardware, input device hardware, etc.). The keyword identification module 304 associates the set of keywords with the recording, thereby quickly classifying the recording.

[0050] The review module 306 enables a technician to review and edit a set of actions performed by the technician during a remote control session. Each action in the set of actions can correspond to a BRS. The technician can edit the set of BRSs. For example, the technician can delete non-related or redundant screenshots and / or actions, add annotations (such as arrows, highlights, text, etc.) to the screenshots, or add explanations (such as additional instructions, comments, etc.) to the actions. The review module 306 also enables the technician to edit (e.g., by adding or deleting, etc.) a set of keywords associated with the record. Once the review and editing are completed, the modified set of BRSs and the set of keywords can be saved as an RP - an RP is also called a resolution story.

[0051] The resolution story approval module 308 determines whether the resolution story complies with best practices. For example, the IT administrator can review the resolution story to determine that the resolution story is the most efficient way to resolve a service ticket with the fewest side effects (such as deletion or recreation of the user's Windows (registered trademark) profile, etc.). Efficiency can be defined by the minimum amount of actions, the minimum amount of resources used, etc. The approved resolution story is saved in the resolution story data store 224.

[0052] <Data Structure> Figure 4 is a diagram of an exemplary data structure definition that includes BRS402 and RP412. BRS402 includes step data 404 that provides an explanation and instructions for BRS402. The step data 404 includes a text description, author, creation date, BRS identifier (ID), and name. The text description is an explanation of BRS402 that can be automatically generated and that a technician can modify. The author can be the technician who created BRS402 or the tool used to generate BRS402. The creation date is the date on which the BRS was generated. The BRS ID is an identifier that uniquely identifies BRS402 and can also include a numeric or alphanumeric value. The name of BRS402 can be derived from the text description.

[0053] The step data 404 also includes an image field, an overlay, an array of weights, resources required for BRS402, commands, and verification. The image field can specify a uniform resource locator (URL) where a relevant screenshot is saved. The array of weights includes numeric weights for each of a set of predetermined criteria such as, for example, time to resolution, number of changes, and need for restart. The resources required for BRS402 can represent the hardware or software components required to execute BRS402 on a client device. The commands can indicate an overview of how to execute an action on a client device, and the verification can indicate an overview of how to verify that the command was successfully executed.

[0054] BRS402 also includes parameter data 406, media container 408, and overlay container 410. Parameter data 406 is a set of predefined parameters inserted to execute BRS402 based on the user type. For example, parameter data 406 can include a route, host name, and user name. Media container 408 can include one or more screenshots of the client device. In various embodiments, media container 408 can be located in a cloud storage device. Overlay container 410 includes annotations (such as arrows, highlights, shapes, text, etc.) attached on the screenshots.

[0055] BRS402 can be a directory (such as a compressed folder, etc.) in the file system. Step data 404 and parameter data 406 can be JSON files or documents, hypertext markup language (HTML) files or documents, or extensible markup language (XML) files or documents (stored in that directory).

[0056] RP412 includes a set of BRSs stored in a BRS container 413 such as a file system folder. BRS container 413 includes a set of BRSs 414-1, 414-2, ···, and 414-N (collectively, BRS414), where N is an integer greater than or equal to 1. Each of the BRSs is characterized by a BRS ID. The BRS ID can correspond to the order in which the BRS is listed in BRS container 413. For example, BRS414-1 can have a BRS ID that is one lower than the BRS ID of BRS414-2, and the ID of BRS-(n-l) can be one lower than the ID of BRS414-N. In various embodiments, the BRS ID is stored in each BRS as part of step data 404.

[0057] RP412 also includes a text description 416, an author 418, a creation date 420, and an RP ID 422. The text description 416 is a description of RP412 that can be automatically generated and can also be modified by a technician. The author 418 can be the creator of RP412 or the tool used to generate RP412. The creation date 420 is the date on which the RP was generated. The RP ID 422 is a unique identifier that identifies RP412 and can include numerical or alphanumeric values.

[0058] RP412 also includes a first step ID 424 and a solution step list 426. The first step ID 424 identifies which BRS414 within the BRS container 413 to start from. For example, the first step ID 424 can identify BRS414-2. In various embodiments, the solution step list 426 is an array that describes the order of execution of BRS414.

[0059] Each entry in the solution step list 426 includes a condition for proceeding to the next step, the BRS ID of the current step, a delay when the current step ends, the ID of the next step when the condition is met, and the ID of the next step when the condition is not met. The condition for the next step determines which step is executed next. As a specific example, the RP includes 10 BRSs corresponding to 10 steps, where step 6 creates a specific folder on the client device. As a simple explanation, the multiple IDs of the multiple BRS414 can simply be integers from offset +1 to offset +N respectively, where the offset is the ID last used at the end of the BRS previously recorded in RP412.

[0060] The first four entries in the solution step list 426 simply specify BRS414-1 through 414-4 respectively, have no associated conditions, and can simply specify the next ID as the next step. In other words, the first entry specifies BRS414-1 as the current step and BRS414-2 as the next step. In various embodiments, the condition can be set to a null value to avoid testing the condition. On the other hand, in this example, the fifth entry in the solution step list 426 specifies BRS414-5 as the current step, specifies BRS414-7 as the next step if the condition is met, and specifies BRS414-6 as the next step if the condition is not met. The condition tests for the presence or absence of a specific folder within the file system of the client device. BRS414-7 encodes a command to create a specific folder, which is skipped if the specific folder already exists.

[0061] RP412 can be a collection within the file system, such as compressed files (e.g., using zip, rar, or 7z compression formats). The text description 416, the creator 418, the creation date 420, the RP ID 422, the first step ID 424, and the solution step list 426 can collectively be a JSON file or document, an HTML file or document, or an XML file or document.

[0062] <Auto-correction> FIG. 5 is a functional block diagram of an exemplary embodiment of the automation module 220. The automation module 220 executes a set of actions from the solution story to resolve a service ticket. The automation module 220 includes a classification module 502, a solution determination module 504, and an automation execution module 506.

[0063] The classification module 502 classifies service tickets from the ticket management module 208. The classification module 502 can classify service tickets, for example, using NLP and / or machine learning. The classification module 502 can classify service tickets by processing the titles and descriptions of the symptoms identified in the service tickets. A particular symptom can be associated with various incidents or requests. The classification module 502 can obtain additional test results to classify the incident.

[0064] For example, if a service ticket identifies that a file cannot be saved to a remote disk, one or more conditions may have resulted in this undesirable state - examples include lack of connection to the remote disk, insufficient permissions to write to the remote disk, or unavailability of space on the remote disk (either physical space or remaining quota allocation). The classification module 502 can request tests, including connectivity tests to the remote disk, inquiries about user permissions, and inquiries about available free space on the remote disk. Based on the results from the additional information, the classification module 502 can classify the service ticket. In various embodiments, if the classification module 502 is unable to classify the service ticket, a technician may be requested to classify the service ticket.

[0065] The solution determination module 504 determines whether a solution story or RP is available based on the classification of the service ticket. If a relevant solution story is available, the solution determination module 504 can retrieve the solution story from the solution story data store 224. If no solution story is available, the ticket management module 208 can update the status of the service ticket to "solution story unavailable". Thereafter, the ticket can be processed manually by a technician.

[0066] The automation execution module 506 includes a solution execution module 508, a solution verification module 510, and remote control software 512 that can be similar to the remote control software 120. The remote control software 512 establishes a connection between the client device associated with the service ticket and the automation execution module 506.

[0067] After the connection is established, the solution execution module 508 executes a set of actions from the solution story loaded on the client device. The solution execution module 508 can replay a set of actions (each including one or more UI interactions) from the solution story to transition the client device from an undesired system state to a desired system state. The solution verification module 510 can verify that the solution story has resolved the service ticket by transitioning the client device from an undesired system state to a desired system state. In response to successfully verifying that the set of actions has resolved the service ticket, the ticket management module 208 can update the status of the service ticket to "closed", and the remote control software 512 can terminate the connection.

[0068] <Control> FIG. 6 is a flowchart of an exemplary RP record and use. Control starts at 600, where the user of the client device will open a service ticket. At 602, control assigns the service ticket to a technician. The technician can request to have the service ticket assigned to that technician. At 604, control determines whether an RP relevant to the ticket is already available. If it is available, control moves to 608. Otherwise, control continues to 606. At 608, control determines whether the technician approves the available RP. If approved, control continues to 610. Otherwise, control moves to 606. At 610, control displays the RP for the technician to perform an action. This can include displaying to the technician a series of screenshots that the technician can step through. Then, control ends.

[0069] At 606, control starts recording a remote control session of the client device. At 612, control determines whether a solution to the service ticket can be found. If a solution is found, control continues at 614. Otherwise, control returns to 612. At 614, control closes the service ticket, stops recording the remote control session, and continues at 616. At 616, control parses the service ticket and the recording of the remote control session to identify a set of keywords. At 618, control shows the technician the keywords and a draft of the recording.

[0070] At 620, the control determines whether there are changes to the draft of the record. If there are changes, the control moves to 622. Otherwise, the control continues to 624. At 622, the control applies the engineer's changes to the draft of the record and continues to 624. At 624, the control saves the record as RP. The control can end after 624. In various embodiments, the control can continue to 626, where the control converts RP to a KB article and then ends.

[0071] The KB article can serialize the RP into a human-readable document (e.g., a web document, a Portable Document Format (PDF) document, etc.) along with a set of screenshots. The KB article can identify text proximate to the equivalent location where a mouse event occurred in the RP. The KB article can associate the identified text with the screenshot. The resulting KB article can include text, screenshots, text, screenshots, text, etc.

[0072] Figure 7 is an exemplary flowchart of an automatic correction of a service ticket. After a service ticket - which may have an associated resolution story - is received, the control starts at 700. At 700, the control identifies the root cause for the incident or request identified in the service ticket. For example, the inability to open a file may be caused by the lack of an appropriate installed application, connectivity issues, access restrictions, etc. In another example, a request to use a particular printer can be expressed as an undesired system state, i.e., the inability to print. The root cause of this state may be the lack of a printer driver, the printer not being identified for the client operating system, network connectivity issues, the absence of the client computer from a particular domain, the lack of access rights to the corresponding print spooler, etc.

[0073] At 702, the control determines whether there is a single root cause for an undesired system state associated by a service ticket. If there is a single root cause, the control proceeds to 710. Otherwise, the control continues to 704. At 704, the control executes additional tests to determine the root cause of the service ticket. At 706, the control attempts to classify the root cause of the service ticket based on the tests. At 708, the control determines whether the root cause (or causes) can be classified. If it can be classified, the control continues to 710. Otherwise, the control moves to 728. At 728, the control determines whether all additional tests have been exhausted. If they have been exhausted, the control executes error handling at 730 and then ends. Otherwise, the control returns to 704.

[0074] At 710, the control determines the presence or absence of a predefined RP to handle the classified cause of the incident. If it exists, the control continues to 714, where the control selects a predefined RP. Otherwise, the control continues to 712. At 712, the control determines the optimal steps (e.g., BRS) to resolve the service ticket. As a simple example, the current state of the system can be called state A, while the desired state of the system can be called state D. The optimal steps can include: · A first BRS to transition the system from state A to state B; · A second BRS to transition the system from state B to state D; · A third BRS to transition the system from state A to state C; and · A fourth BRS to transition the system from state C to state D.

[0075] For example, these BRS can be determined using deep learning analysis such as convolutional neural networks, deep neural networks, deep belief networks, etc.

[0076] At 716, the control selects a set of BRSs from the determined optimal steps. For example, this selection can be performed using deep learning analysis such as convolutional neural networks, deep neural networks, deep belief networks, etc. In various embodiments, the shortest path algorithm can select a predefined BRS to resolve the service ticket. Continuing with the above example, there are two possible combinations - whether to use the first and second BRSs or the third and fourth BRSs. The shortest path algorithm determines which of the two possible combinations to use. The shortest path algorithm can evaluate the path length based on one or more criteria, such as some or all of the weight arrays described above for each BRS. These weights can include, for example, the time to resolution, the number of changes, the need for restart, etc.

[0077] At 718, the control executes the selected solution (i.e., the predefined RP or the selected set of BRSs). At 720, the control verifies whether the selected solution was effective. At 722, the control determines whether the selected solution resolved the service ticket. If it did, the control closes the service ticket at 724 and then terminates. Otherwise, the control performs error handling at 726 and then terminates.

[0078] <Application User Interface> Both FIGS. 8A and 8B form an exemplary solution story creation screen of a solution story application, which can be a web application or a native application. The solution story application can include a navigation section window 802 that enables a technician to navigate within the solution story application. For example, the navigation section window 802 of FIGS. 8A and 8B (collectively also referred to as FIG. 8) includes a dashboard tab, a ticket tab, an alert tab, a device tab, a customer tab, a solution tab, a knowledge base tab, an online backup tab, a mail security tab, a web root tab, a payment billing tab, a report tab, and an administrator tab. The ticket tab provides a list of service tickets, and a technician can view a specific service ticket. The solution tab can be used to view existing solution stories or create new solution stories, as shown in the example of FIG. 8.

[0079] For a selected solution story (which may have just been created), an annotation toolbar 804 is used to annotate the screenshot. The annotation toolbar 804 can include tools such as adding an overlay to the screenshot, for example, a pointer, a text cursor, a cropping tool, a highlighter marker, a shape selector, etc.

[0080] FIG. 9 is an exemplary annotated solution story creation screen of a solution story application. It shows a technician annotating a screenshot with a rectangular highlight to emphasize the battery saver settings. The rectangular shape was selected from the shape selector tool of the annotation toolbar 804. To the right of the rectangular shape, as indicated by the vertical line and the text insertion cursor, the technician is ready to enter text.

[0081] <Conclusion> The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or its use. The broad teachings of the disclosure can be implemented in a variety of forms. Accordingly, while the disclosure includes specific examples, the true scope of the disclosure should not be limited as other modifications will become apparent upon consideration of the drawings, this specification, and the following claims. It should be understood that one or more steps within a method can be executed in a different order (or concurrently) without changing the principles of the disclosure. Further, each of the examples described above is described as having specific features, but any one or more of these features described with respect to any example of the disclosure can be implemented in and / or combined with the features of any other example, even if the combination is not explicitly described. In other words, the described examples are not mutually exclusive, and a change in the order of one or more examples is within the scope of the disclosure.

[0082] Spatial and functional relationships between elements (e.g., between modules) are described using various terms including "connected," "engaged," "interface," and "coupled." Unless explicitly described as being "direct," when a relationship between a first element and a second element is described in the above disclosure, the relationship includes both a direct relationship where no other intervening elements exist between the first and second elements and an indirect relationship where one or more intervening elements exist (spatially or functionally) between the first and second elements. As used herein, the phrase "at least one of A, B, and C" should be interpreted to mean the logical (A OR B OR C) using a non-exclusive logical "OR," and the phrase should not be interpreted to mean "at least one of A, at least one of B, and at least one of C." The term subset does not necessarily require a proper subset. In other words, a first subset of a first set can be interpreted as having the same extent (being equal) to the first set.

[0083] In the drawings, the direction of the arrow indicated by the arrow generally indicates the flow of information (such as data and instructions) related to the illustration. For example, when element A and element B exchange various information, and the information transmitted from element A to element B is related to the illustration, the arrow can point from element A to element B. This one-way arrow does not mean that there is no other information transmitted from element B to element A. Furthermore, regarding the information transmitted from element A to element B, element B can transmit an information request or a reception confirmation to element A.

[0084] In this application, it includes the following definitions. The term "module" or the term "controller" can be replaced by the term "circuit". The term "module" may refer to, be part of, or include processor hardware (shared, dedicated, or grouped) that executes code and memory hardware (shared, dedicated, or grouped) that stores the code executed by the processor hardware.

[0085] A module can include one or more interface circuits. In some examples, the interface circuit can include a wired or wireless interface that connects to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functions of any given module of the present disclosure can be distributed among a plurality of modules connected via the interface circuit. For example, load sharing is possible among a plurality of modules. In a further example, a server (also known as remote or cloud) module can achieve some functions on behalf of the client module.

[0086] The term code as used above can include software, firmware, and / or microcode, and it can refer to programs, routines, functions, classes, data structures, and / or objects. Shared processor hardware encompasses a single microprocessor that executes some or all of the code from multiple modules. Group processor hardware encompasses a microprocessor combined with additional microprocessors that execute some or all of the code from one or more modules. When referring to multiple microprocessors, it includes multiple microprocessors on separate dies, multiple microprocessors on a single die, multiple cores of a single microprocessor, multiple threads of a single microprocessor, or combinations as described above.

[0087] Shared memory hardware encompasses a single memory device that stores some or all of the code from multiple modules. Group memory hardware encompasses a memory device that stores some or all of the code from one or more modules in combination with other memory devices.

[0088] The term "memory hardware" is a subset of the term "computer-readable medium". The term "computer-readable medium" as used herein does not include transient electrical or electromagnetic signals propagated through a medium (such as on a carrier wave). Thus, the term "computer-readable medium" is considered to be tangible and non-transitory. Non-limiting examples of non-transitory computer-readable media are non-volatile memory devices (such as flash memory devices, erasable programmable read-only memory devices, or mask read-only memory devices), volatile memory devices (such as static random access memory devices or dynamic random access memory devices), magnetic storage media (such as analog or digital magnetic tape or hard disk drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0089] The devices and methods described in this application can be implemented, in part or in whole, by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions embodied in a computer program. The above-described functional blocks and flowchart elements function as software specifications and can be converted into a computer program by routine work of a skilled technician or programmer.

[0090] A computer program includes processor-executable instructions stored on at least one non-transitory computer-readable medium. A computer program can also include or depend on stored data. A computer program can include a basic input / output system (BIOS) that exchanges information with the hardware of a special-purpose computer, device drivers that exchange information with specific devices of a special-purpose computer, one or more operating systems, user applications, background services, background applications, and the like.

[0091] A computer program can include the following: (i) parsed descriptive texts such as HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation); (ii) assembly code; (iii) object code generated from source code by a compiler; (iv) source code for execution by an interpreter; (v) source code for compilation and execution by a just-in-time compiler, etc. By way of mere example, source code can be written using the syntax of the following languages: C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, JavaScript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, VisualBasic®, Lua, MATLAB®, SIMULINK, and Python®.

Claims

1. Storing a solution profile based on a set of actions executed under remote control to transition a client device from an undesired system state to a desired system state in response to a service ticket, where each action in the set of actions represents an interaction with one or more user interfaces (UIs) with the client device and a set of text descriptors; Classifying a second service ticket in response to receiving the second service ticket submitted for a second client device; Indicating that the solution profile is applicable to the second service ticket according to the classification of the second service ticket: Selectively instructing a software agent executed on the second client device to programmatically reproduce the set of actions from the solution profile on the second client device without the intervention of a technician: and, Verifying that the programmatic reproduction of the set of actions has transitioned the second client device to a desired system state associated with the solution profile: A method having.

2. The method according to claim 1, wherein classifying the second service ticket is performed using natural language processing of the text in the second service ticket.

3. The method according to claim 2, wherein the natural language processing is performed on the title text and text description of the second service ticket.

4. The method according to claim 1, wherein classifying the second service ticket includes selectively requesting a test to be performed by the second client device.

5. The method according to claim 1, having selectively requesting a test to be performed by the second client device in response to receiving the second service ticket.

6. The method according to claim 5, wherein the test includes at least one of a connectivity test, a user permission inquiry, and an available space inquiry.

7. The method according to claim 1, having presenting the second solution to the user of the second client device according to the classification indicating that the second solution is applicable to the second service ticket.

8. Classifying the second service ticket is based selectively on metrics obtained from a monitoring module that processes the second client device, in addition to the second service ticket, the method according to claim 1.

9. Monitoring metrics obtained from a monitoring module that processes the second client device; and Programmatically generating the second service ticket in response to an anomaly in the metrics, the method according to claim 1.

10. After saving the solution profile, selectively converting the solution profile into a knowledge base (KB) article, where the KB article includes a serialized solution profile, the method according to claim 1.

11. Each action of the set of actions is stored in a basic resolution step (BRS) data structure that conforms to a BRS data structure definition, The solution profile encodes the execution order of the BRS data structure, the method according to claim 1.

12. The first basic resolution step (BRS) data structure corresponding to the first action of the set of actions includes a screenshot of the client device captured before the first action is executed, the method according to claim 1.

13. The first BRS data structure stores a command, and in the command, execution causes the client device to transition from the undesired system state to a second system state, the method according to claim 12.

14. The first action of the set of actions includes at least one of a mouse event and a keyboard key press event, the method according to claim 1.

15. Playing back the solution profile on the second client device in response to the second client device being in the undesired system state, the method according to claim 1.

16. Generating the service ticket from at least one of a web browser, an email interface, a chat interface, and a phone, the method according to claim 1.

17. Storing a solution profile based on a set of actions executed under remote control to transition a client device from an undesired system state to a desired system state in response to a service ticket, where each action in the set of actions represents an interaction with one or more user interfaces (UIs) with the client device and a set of text descriptors; Classifying a second service ticket in response to receiving the second service ticket submitted for a second client device; Indicating that the solution profile is applicable to the second service ticket in response to the classification of the second service ticket; Selectively instructing a software agent executed on the second client device to programmatically reproduce the set of actions from the solution profile on the second client device without the intervention of a technician; and, Verifying that the programmatic reproduction of the set of actions has transitioned the second client device to the desired system state associated with the solution profile: A program for causing a processor hardware to execute.

18. The program according to claim 17, wherein classifying the second service ticket is performed using natural language processing of the text in the second service ticket.

19. A system comprising a processor hardware and a memory hardware configured to store instructions for execution by the processor hardware, the instructions being: Storing a solution profile based on a set of actions executed under remote control to transition a client device from an undesired system state to a desired system state in response to a service ticket, where each action in the set of actions represents an interaction with one or more user interfaces (UIs) with the client device and a set of text descriptors; Classifying a second service ticket in response to receiving the second service ticket submitted for a second client device; Classifying the second service ticket in response to receiving the second service ticket submitted for the second client device; Indicating that the solution profile is applicable to the second service ticket according to the classification of the second service ticket: Selectively instructing a software agent executed on the second client device to programmatically reproduce the set of actions from the solution profile on the second client device without intervention of a technician; and Verifying that the programmatic reproduction of the set of actions has caused the second client device to transition to a desired system state associated with the solution profile. A system having the above.

20. The system according to claim 19, wherein classifying the second service ticket is performed using natural language processing of text in the second service ticket.

Images