Automated system management for mitigation of user‑induced errors
A machine learning-based system autonomously detects and resolves user-induced errors in computer systems, enhancing efficiency and customer satisfaction by analyzing user interactions and executing solutions or providing proactive alerts.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- ATERA NETWORKS LTD
- Filing Date
- 2025-10-17
- Publication Date
- 2026-04-23
AI Technical Summary
Conventional remote troubleshooting for user-induced errors in computer systems is time-consuming and inefficient, often failing to provide a satisfactory customer experience due to the need for technician intervention and permission protocols.
A system utilizing a machine learning model to analyze user interactions, detect error states, and autonomously execute solutions or provide proactive alerts to prevent errors, with a database for storing and retrieving effective solutions.
Enhances efficiency by automating error resolution and prevention, providing immediate user assistance and reducing the need for manual technician intervention, thereby improving the customer experience.
Smart Images

Figure IB2025060621_23042026_PF_FP_ABST
Abstract
Description
Attorney Docket No. 51267-23AUTOMATED SYSTEM MANAGEMENT FOR MITIGATION OFUSER-INDUCED ERRORSCROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 708,489 filed October 17, 2024.FIELD
[0002] The disclosure relates generally to computer system management, and more particularly to computer-implemented techniques for error detection, fault recovery, and system management within managed endpoint devices.BACKGROUND
[0003] In an environment filled with computers, a user of a computer may encounter various incidents with the user's computer. For example, the user may be unable to save a file to a network hard drive, unable to print a document, unable to launch a particular application, etc. The user may contact an information technology (IT) technician, who may have the knowledge and resources to resolve the incident. However, the technician may be unavailable to provide immediate assistance to the user, such as when the technician is assisting other users, the incident arises outside of normal business hours, etc.
[0004] Once the technician becomes available to provide assistance, the technician must request and be granted permission from the user before the technician can remotely connect to the user's computer. Typically, these technicians attempt to fix problems or perform troubleshooting during these remote sessions. However, this conventional approach is timeconsuming, lacks efficiency, and often fails to provide a satisfactory customer experience.
[0005] The background description provided here is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.SUMMARY
[0006] A method includes receiving an indication of a first error state on a target device. The first error state is associated with a first set of user inputs. The method includes summarizing, via a machine learning model, the first set of user inputs. The method includes reviewing a first solution. Reviewing the first solution includes, in response to a determination that the firstAttorney Docket No. 51267-23 solution resolves the first error state, automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database. The method includes, in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database. The method includes detecting, via a recording module on a target device, a second set of user inputs. The method includes generating, via the machine learning model, a summary of the second set of user inputs. The method includes determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state. The method includes, in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.
[0007] In other features, the prompt is outputted before the target device has entered the first error state. In other features, outputting the prompt includes at least one of displaying a user interface element, outputting an auditory alert, or outputting a haptic alert. In other features, summarizing the second set of user inputs includes interpreting, via the machine learning model, a context of the second set of user inputs. Interpreting the context includes at least one of interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.
[0008] In other features, determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of the first set of user inputs, the first error state, and the first solution.
[0009] In other features, the method includes, in response to the determination that the second set of user inputs corresponds to the first error state, blocking additional user input associated with the first error state. In other features, the method includes starting a recording session. In other features, the recording session runs on the target device, the recording session records user interactions on the target device, and the user interactions include the first set of user inputs and the second set of user inputs.
[0010] In other features, the method includes receiving a user ticket associated with a second error state on the target device. In other features, the method includes, in response to receiving the user ticket, generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state.
[0011] In other features, the method includes generating a package including the user ticket and the third set of user inputs. In other features, the method includes adding the package to a package database by correlating the user ticket with a second ticket. The second ticket is associated with a third error state. The second error state is similar to the third error state. In other features, the method includes correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.Attorney Docket No. 51267-23
[0012] In other features, the prompt includes at least one of instructions associated with a solution for the first error state, and a warning that the first error state has been detected. In other features, the prompt includes a second user interface element, that when selected, automatically performs a task associated with the first error state. The task avoids an error associated with the first error state. The task is based on a previous task performed on the target device. The task is based on a previous task performed on a second target device. The task is based on the second set of user inputs. In other features, the method includes, in response to the determination that the second set of user inputs corresponds to the first error state, automatically performing a task to prevent an error associated with the first error state.
[0013] A system includes memory hardware configured to store instructions and processor hardware configured to execute instructions stored by the memory hardware. The instructions include receiving an indication of a first error state on a target device. The first error state is associated with a first set of user inputs. The instructions include summarizing, via a machine learning model, the first set of user inputs. The instructions include reviewing a first solution. Reviewing a first solution includes, in response to a determination that the first solution resolves the first error state, automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database. The instructions include, in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database. The instructions include detecting, via a recording module on a target device, a second set of user inputs. The instructions include generating, via the machine learning model, a summary of the second set of user inputs. The instructions include determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state. The instructions include, in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.
[0014] In other features, the prompt is outputted before the target device has entered the first error state. In other features, outputting the prompt includes at least one of displaying a user interface element, outputting an auditory alert, or outputting a haptic alert. In other features, summarizing the second set of user inputs includes interpreting, via the machine learning model, a context of the second set of user inputs. Interpreting the context includes at least one of interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.
[0015] In other features, determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of the first set of user inputs, the first error state, and the first solution. In other features, the instructions include starting a recording session. The recording session runs on the target device, the recording session records user interactions on the target device, and the user interactions include the first set of user inputs and the second set of user inputs.Attorney Docket No. 51267-23
[0016] In other features, the instructions include receiving a user ticket associated with a second error state on the target device. In other features, the instructions include, in response to receiving the user ticket, generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state.
[0017] In other features, the instructions include generating a package including the user ticket and the third set of user inputs. In other features, the instructions include adding the package to a package database. Adding the package to the package database includes correlating the user ticket with a second ticket. The second ticket is associated with a third error state. The second error state is similar to the third error state. Adding the package to the package database includes correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.
[0018] In other features, the prompt includes a second user interface element, that when selected, automatically performs a task associated with the first error state. The task avoids an error associated with the first error state. The task is based on a previous task performed on the target device. The task is based on a previous task performed on a second target device. The task is based on the second set of user inputs.
[0019] A non-transitory computer-readable medium stores processor-executable instructions. The instructions include receiving an indication of a first error state on a target device. The first error state is associated with a first set of user inputs. The instructions include summarizing, via a machine learning model, the first set of user inputs. The instructions include reviewing a first solution. Reviewing a first solution includes, in response to a determination that the first solution resolves the first error state, automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database. The instructions include, in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database. The instructions include detecting, via a recording module on a target device, a second set of user inputs. The instructions include generating, via the machine learning model, a summary of the second set of user inputs. The instructions include determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state. The instructions include, in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.
[0020] In other features, the prompt is outputted before the target device has entered the first error state. Outputting the prompt includes at least one of displaying a user interface element, outputting an auditory alert, or outputting a haptic alert. In other features, summarizing the second set of user inputs includes interpreting, via the machine learning model, a context of the second set of user inputs. In other features, interpreting the context includes at least one of interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.Attorney Docket No. 51267-23
[0021] In other features, determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of the first set of user inputs, the first error state, and the first solution. In other features, the instructions include starting a recording session. The recording session runs on the target device. The recording session records user interactions on the target device. The user interactions include the first set of user inputs and the second set of user inputs. In other features, the instructions include receiving a user ticket associated with a second error state on the target device. In other features, the instructions include, in response to receiving the user ticket, generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state.
[0022] In other features, the instructions include generating a package including the user ticket and the third set of user inputs. In other features, the instructions include adding the package to a package database. Adding the package to a package database includes correlating the user ticket with a second ticket. The second ticket is associated with a third error state, and the second error state is similar to the third error state. In other features, adding the package to a package database includes correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.
[0023] Further areas of applicability of the present disclosure will become apparent from the detailed description, the claims, and the drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS
[0024] The present disclosure will become more fully understood from the detailed description and the accompanying drawings.
[0025] FIG. 1 is a block diagram of an example system for automatically mitigating user created errors.
[0026] FIG. 2 is a flowchart of an example method for recording and transmitting user errors.
[0027] FIG. 3 is a flowchart of an example method for receiving, cataloging, and storing user errors.
[0028] FIGS. 4A-4B are a flowchart of an example method for automatically mitigating user created errors.
[0029] In the drawings, reference numbers may be reused to identify similar and / or identical elements.Attorney Docket No. 51267-23DETAILED DESCRIPTIONINTRODUCTION
[0030] According to the present disclosure, user interactions with a client device (such as user interactions with the operating system, including mouse and keyboard actions) are captured and stored locally on the client. For example, an application programming interface (API) of the operating system may allow an agent executing on the client device to record the user actions. Given the sheer volume and complexity of the raw interaction data, human analysis is impractical. According to the principles of the present disclosure, an Al model (which may be partially or wholly executing on the client device) is used to analyze interactions and generate a concise summary of user actions. In various implementations, the Al model produces a summary devoid of any user identifiers, focusing solely on action patterns relevant to problem-solving.
[0031] Records of user interactions contain raw technical information like the position on the screen, timestamps, software used, text typed, user interface (UI) identifiers / handles and corresponding images and text of UI elements interacted with, etc. This raw data is not readable and may not be useful without translating to a human-readable text that explains what the user performed. A user actions Al model is a dedicated large language model (LLM) trained specifically to analyze raw user interaction data and provide textual action patterns. The model is trained for purposes of two main tasks. The first task is to analyze raw data of user interactions. The result of the analysis will be a summary of an interaction pattern. The second task is to detect anomalies in the user interaction. These anomalies are indications that an error may occur in the near future. In various implementations, the second task may be implemented using a separate system, which may be a distinct LLM, a neural network, an anomaly detector, etc.
[0032] In response to detection of an anomaly, a solution may be identified. Once a solution is identified (either by the Al model or the technician), the solution is provided as a one-click option, readily executable by either the user, an agent on the client device, or an IT technician. After a solution is confirmed to resolve the issue, a remote solution system archives the user actions and the corresponding solution are archived within a database. This database acts as an initial filter in future instances, seeking effective solutions based on user actions to ensure faster and more precise responses.
[0033] Using the database, the client device agent may detect user interactions that may result in error. In some implementations, the client device agent triggers a notification on the client device, which may allow the error to be proactively prevented. For example, the client device agent may provide the user with a solution to a task the user is performing (or attempting to perform) and / or warn the user that the actions may result in an error. In some implementations, the notification includes step-by-step instructions to complete a task. As an example, in response to a user selecting a network printer that is offline, the client device agent notifies the user that the printer is offline and suggests another printer. As another example, the client device agentAttorney Docket No. 51267-23 may automatically select a printer that is online — and, in various implementations, offer to switch the selected printer back and troubleshoot the offline status.SYSTEM ARCHITECTURE
[0034] FIG. 1 is a block diagram of an example system for automatically mitigating user created errors. The system includes client device 104, solution module 132, ticket management module 148, and technician device 152. In some implementations, client device 104, solution module 132, ticket management module 148, and technician device 152 are located in different geographical locations. Client device 104 and technician device 152 may be a tablet, laptop, personal computer, or other electronic device. Client device 104 includes agent 108, which includes intervention module 112, recording module 116, ticket request interface 120, and recording analysis module 124.
[0035] Ticket request interface 120 includes a user interface for creating and submitting errors via tickets. In some implementations, ticket request interface 120 transmits tickets to analysis module 136, user actions database 140, and ticket management module 148. Recording module 116 monitors and records user inputs on client device 104 and the context of the user inputs (for example programs, applications, web pages, etc. and the associated user interfaces). In some implementations, user inputs include mouse movement inputs (up, down, left, right, etc.), mouse selection inputs (left, right, single, double clicks, etc.), keyboard inputs, touch sensitive interface inputs, gesture inputs, etc. In some implementations, the user inputs are captured via an operating system API. In some implementations, the user inputs are recorded as raw data (for example data that is not human-readable). Recording analysis module 124 includes a large language model (LLM) to analyze and generate a summary of the user inputs and the context. For example, recording analysis module 124 generates a summary of “the mouse moves to the comer of the application and clicks on the red ‘X’ close icon” from a set of data describing the user interface that was displayed and the exact coordinates of a mouse movement and input.
[0036] User actions database 140 stores summaries of user errors and the associated solution to each error (if a solution was found). In some implementations, user actions database 140 stores user actions that are associated with user errors. For example, actions that caused an error, actions within a threshold time before or after an error, and / or a threshold quantity of actions before or after a user error. In some implementations, a ticket transmitted by client device 104 is received by ticket management module 148. Based on an analysis of the ticket by analysis module 136, if no solution exists for the ticket, ticket management module 148 assigns the ticket to a technician. Technician device 152 includes ticket review interface 156 and remote control software 160. Ticket review interface 156 displays the ticket including the reported error, and a summary of the user actions that are associated with the user ticket. Using remote control software 160, technician device 152 connects to client device 104 to resolve the error associated with the ticket. In some implementations, the solution to the ticket is recorded by recording module 116 and analyzed by recording analysis module 124. The solution is then saved with the ticket and user actions in user actions database 140 and user tickets database 144. In someAttorney Docket No. 51267-23 implementations, the solution to a ticket is entered manually by a technician and the manually entered solution is interpreted by analysis module 136.
[0037] Analysis module 136 analyzes user actions, tickets, and solutions stored in user actions database 140 and user tickets database 144 to determine whether a solution is stored that corresponds to a current ticket from client device 104. In some implementations, if a solution exists for an error corresponding to a ticket, the solution is transmitted to client device 104 and executed by intervention module 112. In some implementations, recordings of user actions (for example, summaries of user actions) are analyzed by analysis module 136 when no user ticket exists. When no user ticket exists, analysis module 136 compares user inputs to user actions stored in user actions database 140 to determine whether the user inputs on client device 104 correspond to a set of actions that are associated with (or will lead to) an error. If the current actions match (or are similar - based on a similarity threshold - to stored actions), intervention module 112 intervenes. In some implementations, the solution requires approval (either by the user or the technician) before it can be executed. An approval message is transmitted to the user and / or technician as a one -click solution and documented with the ticket solution. In some implementations, intervention module 112 outputs a prompt corresponding to the set of user actions. In some implementations, the prompt includes instructions corresponding to actions to take to avoid creating the error state. In some implementations, intervention module 112 automatically executes a solution associated with the error state. In some implementations, the prompt is a displayed visual prompt, a haptic prompt, and / or an audible alert.FLOWCHARTS
[0038] FIG. 2 is a flowchart of an example method for recording and transmitting user errors. Control begins at 204 and starts recording via a recording module. In some implementations, recording begins in response to a user logging into a user account or in response to a client device powering on. In some implementations, the recording module is a ring buffer that records and saves user actions in a preceding interval (for example, the immediately previous 30 seconds, 1 minute, 10 minutes, etc.) In some implementations, the ring buffer size is based on a number of actions. In some implementations, the ring buffer persists while the device is powered off or the user account is not active. For example, recording module 116 pauses and actions in the buffer do not exit the buffer until new actions are recorded. At 208, control determines if a user ticket has been created. If a ticket has been created, control transfers to 212. If no ticket has been created, control remains at 208. At 212, control reviews user actions that occurred before (and, in some implementations, after) the user ticket was created. At 212 control determines which recorded actions correspond to the user created ticket (for example, which user actions created the error associated with the user ticket or user actions that are an attempt to resolve the error). At 216 the relevant actions and the ticket are packaged together. At 220, the package is transmitted to the backend for analysis and control ends.
[0039] FIG. 3 is a flowchart of an example method for receiving, cataloging, and storing user errors. At 304, control determines if a user-created ticket has been received. If no ticket has beenAttorney Docket No. 51267-23 received, control remains at 304. If a user-created ticket has been received, control transfers to 308. At 308, control receives a package (such as the package created in 216) including the ticket and telemetry data from the client device associated with the ticket. At 312, control correlates the package contents with stored packages that include similar tickets and / or errors. At 316 control correlates the package contents with stored packages that include similar actions. At 320, control adds the package to the action and ticket database and control ends.
[0040] FIGS. 4A-4B are a flowchart of an example method for automatically mitigating user created errors. At 404 control begins and a recording starts (for example, via a recording module and in response to a user log in). At 408 control determines whether a user interface (UI) interaction has been identified. If no user interaction has been identified, control remains at 408. If a user interaction has been identified, control transfers to 412. At 412, control determines whether the UI interaction corresponds to an error. In some implementations, determining whether the UI interaction corresponds to an error includes summarizing the raw interaction data via a machine learning model and comparing the summarized data to a set of user actions and error data associated with the set of user actions. If the UI interaction does not correspond to an error, control returns to 408. If the UI interaction corresponds to an error, control transfers to 416. In some implementations, an interaction or set of interactions corresponds to an error if a threshold quantity of interactions of a set of user inputs match a second set of inputs that are associated with an error. At 416, control alerts a user (by outputting a prompt) that further action will likely result in an error or that an error has occurred. In some implementations, the further user input is ignored after the prompt is outputted. For example, if steps A, B, C, and D are associated in an error state, the system may alert the user after steps A, B, and C have been performed. In some implementations, whether the UI interaction corresponds to an error is determined by a machine learning model. At 420, control determines if a user input corresponding to an override of the alert has been detected. If no override input has been detected, control transfers to 428. If an override input has been detected, control transfers to 436.
[0041] At 436, control allows additional user input and continues to record user input and to monitor the client device for error. At 440, control determines whether an error has been caused by the user input(s). If an error has been detected, control transfers to 428. If no error has been detected, control transfers to 408. In some implementations, control remains at 440 for a set interval of time, for a set number of new user inputs, and / or until an expected input is detected (for example, an input known to cause an error and / or an input associated with mitigating an error is detected). Continuing with the previous example, control may remain at 440 until step D is detected (resulting in a detected error) or steps E and F are detected, which mitigates any potential error.
[0042] At 428, a package is created that includes the user actions and the error. At 432, the package is transmitted to a backend that includes storage of user actions, user tickets, user errors, solutions, and other data. At 444, control determines whether a solution that corresponds to the error is available. If no solution is available, control transfers to 452. At 452 a ticket isAttorney Docket No. 51267-23 created (so that the issues can be manually addressed via a technician) and control returns to 408.
[0043] If a solution is available, control transfers to 448. At 448 a ticket is created and the solution is executed. In some implementations, an alert is transmitted to the user and / or technician to request approval to execute the solution. At 456, control determines whether the error is resolved. If the issue is resolved, control transfers to 460 and the ticket is marked as resolved. If the error is not resolved, control transfers to 464 and the error is marked for additional technician review before control returns to 408.CONCLUSION
[0044] The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. In the written description and claims, one or more steps within a method may be executed in a different order (or concurrently) without altering the principles of the present disclosure. Similarly, one or more instructions stored in a non-transitory computer-readable medium may be executed in a different order (or concurrently) without altering the principles of the present disclosure. Unless indicated otherwise, numbering or other labeling of instructions or method steps is done for convenient reference, not to indicate a fixed order.
[0045] Further, although each of the embodiments is described above as having certain features, any one or more of those features described with respect to any embodiment of the disclosure can be implemented in and / or combined with features of any of the other embodiments, even if that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with one another remain within the scope of this disclosure.
[0046] Spatial and functional relationships between elements (for example, between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including “connected,” “engaged,” “coupled,” “adjacent,” “next to,” “on top of,” “above,” “below,” and “disposed.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the above disclosure, that relationship encompasses a direct relationship where no other intervening elements are present between the first and second elements as well as an indirect relationship where one or more intervening elements are present between the first and second elements.
[0047] As noted below, the term “set” generally means a grouping of one or more elements. However, in various implementations a “set” may, in certain circumstances, be the empty set (in other words, the set has zero elements in those circumstances). As an example, a set of search results resulting from a query may, depending on the query, be the empty set. In contexts whereAttorney Docket No. 51267-23 it is not otherwise clear, the term “non-empty set” can be used to explicitly denote exclusion of the empty set — that is, a non-empty set will always have one or more elements.
[0048] A “subset” of a first set generally includes some of the elements of the first set. In various implementations, a subset of the first set is not necessarily a proper subset: in certain circumstances, the subset may be coextensive with (equal to) the first set (in other words, the subset may include the same elements as the first set). In contexts where it is not otherwise clear, the term “proper subset” can be used to explicitly denote that a subset of the first set must exclude at least one of the elements of the first set. Further, in various implementations, the term “subset” does not necessarily exclude the empty set. As an example, consider a set of candidates that was selected based on first criteria and a subset of the set of candidates that was selected based on second criteria; if no elements of the set of candidates met the second criteria, the subset may be the empty set. In contexts where it is not otherwise clear, the term “non-empty subset” can be used to explicitly denote exclusion of the empty set.
[0049] In the figures, the direction of an arrow, as indicated by the arrowhead, generally demonstrates the flow of information (such as data or instructions) that is of interest to the illustration. For example, when element A and element B exchange a variety of information but information transmitted from element A to element B is relevant to the illustration, the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is transmitted from element B to element A. Further, for information sent from element A to element B, element B may send requests for, or receipt acknowledgements of, the information to element A.
[0050] In this application, including the definitions below, the term “module” can be replaced with the term “controller” or the term “circuit.” In this application, the term “controller” can be replaced with the term “module.” The term “module” may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); processor hardware (shared, dedicated, or group) that executes code; memory hardware (shared, dedicated, or group) that is coupled with the processor hardware and stores code executed by the processor hardware; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.
[0051] The module may include one or more interface circuits. In some examples, the interface circuit(s) may implement wired or wireless interfaces that connect to a local area network (LAN) or a wireless personal area network (WPAN). Examples of a LAN are Institute of Electrical and Electronics Engineers (IEEE) Standard 802.11-2020 (also known as the WIFI wireless networking standard) and IEEE Standard 802.3-2018 (also known as the ETHERNET wired networking standard). Examples of a WPAN are IEEE Standard 802.15.4 (including the ZIGBEE standard from the ZigBee Alliance) and, from the Bluetooth Special Interest GroupAttorney Docket No. 51267-23(SIG), the BLUETOOTH wireless networking standard (including Core Specification versions 3.0, 4.0, 4.1, 4.2, 5.0, and 5.1 from the Bluetooth SIG).
[0052] The module may communicate with other modules using the interface circuit(s). Although the module may be depicted in the present disclosure as logically communicating directly with other modules, in various implementations the module may actually communicate via a communications system. The communications system includes physical and / or virtual networking equipment such as hubs, switches, routers, and gateways. In some implementations, the communications system connects to or traverses a wide area network (WAN) such as the Internet. For example, the communications system may include multiple LANs connected to each other over the Internet or point-to-point leased lines using technologies including Multiprotocol Label Switching (MPLS) and virtual private networks (VPNs).
[0053] In various implementations, the functionality of the module may be distributed among multiple modules that are connected via the communications system. For example, multiple modules may implement the same functionality distributed by a load balancing system. In a further example, the functionality of the module may be split between a server (also known as remote, or cloud) module and a client (or, user) module. For example, the client module may include a native or web application executing on a client device and in network communication with the server module.
[0054] Some or all hardware features of a module may be defined using a language for hardware description, such as IEEE Standard 1364-2005 (commonly called “Verilog”) and IEEE Standard 1076-2008 (commonly called “VHDL”). The hardware description language may be used to manufacture and / or program a hardware circuit. In some implementations, some or all features of a module may be defined by a language, such as IEEE 1666-2005 (commonly called “SystemC”), that encompasses both code, as described below, and hardware description.
[0055] The term code, as used above, may include software, firmware, and / or microcode, and may refer to programs, routines, functions, classes, data structures, and / or objects. Shared processor hardware encompasses a single microprocessor that executes some or all code from multiple modules. Group processor hardware encompasses a microprocessor that, in combination with additional microprocessors, executes some or all code from one or more modules. References to multiple microprocessors encompass multiple microprocessors on discrete dies, multiple microprocessors on a single die, multiple cores of a single microprocessor, multiple threads of a single microprocessor, or a combination of the above.
[0056] The memory hardware may also store data together with or separate from the code. Shared memory hardware encompasses a single memory device that stores some or all code from multiple modules. One example of shared memory hardware may be level 1 cache on or near a microprocessor die, which may store code from multiple modules. Another example of shared memory hardware may be persistent storage, such as a solid state drive (SSD) or magnetic hard disk drive (HDD), which may store code from multiple modules. Group memoryAttorney Docket No. 51267-23 hardware encompasses a memory device that, in combination with other memory devices, stores some or all code from one or more modules. One example of group memory hardware is a storage area network (SAN), which may store code of a particular module across multiple physical devices. Another example of group memory hardware is random access memory of each of a set of servers that, in combination, store code of a particular module. The term memory hardware is a subset of the term computer-readable medium.
[0057] The apparatuses and methods described in this application may be partially or fully implemented by a special-purpose computer created by configuring a general-purpose computer to execute one or more particular functions embodied in computer programs. Such apparatuses and methods may be described as computerized or computer-implemented apparatuses and methods. The functional blocks and flowchart elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.
[0058] The computer programs include processor-executable instructions that are stored on at least one non-transitory computer-readable medium. The computer programs may also include or rely on stored data. The computer programs may encompass a basic input / output system (BIOS) that interacts with hardware of the special -purpose computer, device drivers that interact with particular devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.
[0059] The computer programs may include: (i) descriptive text to be parsed, 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. As examples only, source code may be written using syntax from languages including 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®, Visual Basic®, Lua, MATLAB, SIMULINK, and Python®.
[0060] The term non-transitory computer-readable medium does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave). Non-limiting examples of a non-transitory computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).
[0061] The term “set” generally means a grouping of one or more elements. The elements of a set do not necessarily need to have any characteristics in common or otherwise belong together.Attorney Docket No. 51267-23The phrase “at least one of A, B, and C” should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean “at least one of A, at least one of B, and at least one of C ” The phrase “at least one of A, B, or C” should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR.
Claims
Attorney Docket No. 51267-23CLAIMS1. A method comprising: receiving an indication of a first error state on a target device, wherein the first error state is associated with a first set of user inputs; summarizing, via a machine learning model, the first set of user inputs; reviewing a first solution including: in response to a determination that the first solution resolves the first error state: automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database; and in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database; detecting, via a recording module on a target device, a second set of user inputs; generating, via the machine learning model, a summary of the second set of user inputs; determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state; and in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.
2. The method of claim 1 wherein the prompt is outputted before the target device has entered the first error state.
3. The method of claim 1 wherein outputting the prompt includes at least one of: displaying a user interface element, outputting an auditory alert, or outputting a haptic alert.
4. The method of claim 1 wherein: summarizing the second set of user inputs includes interpreting, via the machine learning model, a context of the second set of user inputs, and interpreting the context includes at least one of: interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.Attorney Docket No. 51267-235. The method of claim 4 wherein determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of: the first set of user inputs, the first error state, and the first solution.
6. The method of claim 1 further comprising, in response to the determination that the second set of user inputs corresponds to the first error state, blocking additional user input associated with the first error state.
7. The method of claim 1 further comprising: starting a recording session, wherein: the recording session runs on the target device, the recording session records user interactions on the target device, and the user interactions include the first set of user inputs and the second set of user inputs.
8. The method of claim 7 further comprising: receiving a user ticket associated with a second error state on the target device; in response to receiving the user ticket: generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state; generating a package including the user ticket and the third set of user inputs; and adding the package to a package database, wherein adding the package to the package database includes: correlating the user ticket with a second ticket, wherein: the second ticket is associated with a third error state, and the second error state is similar to the third error state; and correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.
9. The method of claim 1 wherein the prompt includes at least one of:Attorney Docket No. 51267-23 instructions associated with a solution for the first error state, and a warning that the first error state has been detected.
10. The method of claim 1 wherein the prompt includes a second user interface element, that when selected, automatically performs a task associated with the first error state, wherein: the task avoids an error associated with the first error state, the task is based on a previous task performed on the target device, the task is based on a previous task performed on a second target device, and the task is based on the second set of user inputs.
11. The method of claim 1 further comprising, in response to the determination that the second set of user inputs corresponds to the first error state, automatically performing a task to prevent an error associated with the first error state.
12. A system comprising: memory hardware configured to store instructions; and processor hardware configured to execute instructions stored by the memory hardware, wherein the instructions include: receiving an indication of a first error state on a target device, wherein the first error state is associated with a first set of user inputs; summarizing, via a machine learning model, the first set of user inputs; reviewing a first solution including: in response to a determination that the first solution resolves the first error state: automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database; and in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database; detecting, via a recording module on a target device, a second set of user inputs; generating a summary, via the machine learning model, of the second set of user inputs; determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state; andAttorney Docket No. 51267-23 in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.
13. The system of claim 12 wherein: the prompt is outputted before the target device has entered the first error state, outputting the prompt includes at least one of: displaying a user interface element, outputting an auditory alert, or outputting a haptic alert; and summarizing the second set of user inputs includes: interpreting, via the machine learning model, a context of the second set of user inputs, wherein interpreting the context includes at least one of: interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.
14. The system of claim of claim 13 wherein determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of: the first set of user inputs, the first error state, and the first solution.
15. The system of claim of claim 14 wherein the instructions include: starting a recording session, wherein: the recording session runs on the target device, the recording session records user interactions on the target device, and the user interactions include the first set of user inputs and the second set of user inputs; receiving a user ticket associated with a second error state on the target device; in response to receiving the user ticket: generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state;Attorney Docket No. 51267-23 generating a package including the user ticket and the third set of user inputs; and adding the package to a package database, wherein adding the package to the package database includes: correlating the user ticket with a second ticket, wherein: the second ticket is associated with a third error state, and the second error state is similar to the third error state; and correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.
16. The system of claim 12 wherein the prompt includes a second user interface element, that when selected, automatically performs a task associated with the first error state, wherein: the task avoids an error associated with the first error state, the task is based on a previous task performed on the target device, the task is based on a previous task performed on a second target device, and the task is based on the second set of user inputs.
17. A non-transitory computer-readable medium storing processor-executable instructions, wherein the instructions include: receiving an indication of a first error state on a target device, wherein the first error state is associated with a first set of user inputs; summarizing, via a machine learning model, the first set of user inputs; reviewing a first solution including: in response to a determination that the first solution resolves the first error state: automatically executing the first solution on the target device, and storing the first set of user inputs, the first error state, and the first solution in a database; and in response to a determination that the first solution does not resolve the first error state, reviewing a second solution stored in the database; detecting, via a recording module on a target device, a second set of user inputs; generating a summary, via the machine learning model, of the second set of user inputs; determining, based on the summary of the second set of user inputs, whether the second set of user inputs corresponds to the first error state; and in response to a determination that the second set of user inputs corresponds to the first error state, automatically outputting a prompt to a user via the target device.Attorney Docket No. 51267-2318. The non-transitory computer-readable medium of claim 17 wherein: the prompt is outputted before the target device has entered the first error state, outputting the prompt includes at least one of: displaying a user interface element, outputting an auditory alert, or outputting a haptic alert; and summarizing the second set of user inputs includes: interpreting, via the machine learning model, a context of the second set of user inputs, wherein interpreting the context includes at least one of: interpreting a user interface associated with the second set of user inputs, and interpreting a user interaction with the user interface.
19. The non-transitory computer-readable medium of claim 18 wherein determining whether the second set of user inputs corresponds to the first error state includes comparing the context of the second set of user inputs to a context of: the first set of user inputs, the first error state, and the first solution.
20. The non-transitory computer-readable medium of claim 17 wherein the instructions include: starting a recording session, wherein: the recording session runs on the target device, the recording session records user interactions on the target device, and the user interactions include the first set of user inputs and the second set of user inputs; receiving a user ticket associated with a second error state on the target device; in response to receiving the user ticket: generating an analysis of the user interactions, and based on the analysis of the user interactions, generating a third set of user inputs that includes user interactions that are associated with a creation of the second error state; generating a package including the user ticket and the third set of user inputs; andAttorney Docket No. 51267-23 adding the package to a package database wherein adding the package to the package database includes: correlating the user ticket with a second ticket, wherein: the second ticket is associated with a third error state, and the second error state is similar to the third error state; and correlating the third set of user inputs with a fourth set of user inputs that are similar to the third set of user inputs.