DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 03/11/2026. Claims 1-20 are pending of which claims 1-3, 5-11, 13-17 and 19-20 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claims as amended recite. ” and based on determining that telemetry data for the organization does not match the at least one of the one or more documents and the one or more cybersecurity appliances, generating a second response to the first utterance that at least indicates a subset of the one or more documents”, The specification provides no support for a second response performed in response to telemetry data not matching the organization. The specification does not describe a second response. The specification does not describe a second response to documents not matching an organization that includes displaying a subset of the documents. Parts of the specification regarding no matching documents being identified are directed toward generating prompt for creating incident tickets. Thus, there being no support for such limitation the examiner contends claims 1, 9, and 15 fail the 112 1st ¶ for new matter. Claims 2-8 10-14 and 16-20 are rejected based on their dependence of claims 1, 9 and 15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4, 9, 10, 12 , 15, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel US 2018/0114234 and further in view of Sridhar US 2021/0344576,
Regarding claims 1, 9, and 15 , Fighel teaches a method, non-transitory CRM and apparatus comprising: based on a first utterance of a user, prompting a first language model with task instructions to rephrase the first utterance of the user and extract a first intent and intent category of the first intent(input received via voice interface(i.e. utterance ) is received an analyzed using machine learning engines(models) that determine intent of the input with respect to a problem type/action(intent category) that needs to be resolved), ¶s46,47,66,90 most relevant terms are extracted from user prompt(i.e rephrasing the utterance) ¶95)
[0046] The communications analysis unit 218 could compare key words in client communications to information technology words that have known applicability in certain contexts. The goal of the analysis is to determine a client's intent and acts with respect to specific types of issues or problems. A dictionary of information technology or computer words could be consulted for this purpose. Moreover, the communications analysis unit 218 may build up such a dictionary or database of key words over time, where certain key words become associated with certain types of problems. Such a dictionary or database could be specific to a particular client, or it could have broader applicability to multiple clients. This type of historical knowledge can be highly valuable in identifying when a problem has reoccurred.
[0047] The communications analysis unit 218 may use Natural Language Processing (NLP) algorithms to first build a corpus of IT systems intents and IT systems assets. For example, an intent is an action that can be taken automatically or manually on a system. “Restart”, “Increase”, “Reboot”, “Shutdown”, “Delete”, “Add”, “Scale”, “Tune” are all examples for intents or actions that can be taken on an IT system. “CPU”, “Memory”, “Subnet”, “Network Interface”, “Garbage Collection”, “I/O”, “Disk” are all IT terms. Numbers and percentages, as well as nouns, are the bounding pieces creating the overall sentence semantics. For example, when a human is reporting via a computer messaging system: “Due to High CPU usage, I needed to restart server name: abc123” the communications analysis unit 218 analyzing the sentence would identify the key words such as “Due”, “High”, “CPU”, “Restart”, “abc123”. Identifying those key words and sending them to the evaluation unit 500, helps building causality and remediation connections between generic IT components which can be adapted for a specific environment or which can be used transitively in a broader IT systems environments.
[0066] The AI approach used by the analysis unit 512 utilizes knowledge obtained through the various events from the different IT monitoring solutions/sensors/agents, as well as from the end-user feedback. Reasoning is accomplished by applying rules to detect the semantics of the event, as well as generic models which rely on generic algorithms, rather than expert knowledge, to correlate events based on an abstraction of the system architecture and its components.
[0090] In addition to the text interaction, the user interface system 1000 supports other means of user interaction, such as via audio and video. A voice interface 1008 could receive user input in the form of voice questions or commands. The voice interface 1008 then interprets the user's spoken audio input and causes appropriate actions to occur. For example, the user could issue a spoken audio question, and the voice interface would then interpret the question, obtain an answer to the question, and provide that answer to the user. The answer could be provided as an audio answer, as a text based answer, as a graphical response provided on a user display screen, or as combinations of those response formats.
[0095] The video interface 1010 could also be used to cause a “character” or “persona” to be displayed on a user display screen. The character or persona might have an abstract human-like face, body or other depiction, and the character or persona would represent the production environment assistant 100 in user interactions. A system character or persona that interacts with a user could be customized to have a particular name or appearance. The user may then use the character or persona's name when asking a question or issuing a command. For example, a user could issue a request for information by saying “Sam, please identify all servers with over 50% CPU usage in my production system and report back after you have restarted them one after another.” Such a command contains the user's intentions (Identify, Report, Restart), nouns, metrics and specifics (production system).
identifying one or more first entities and first metadata for the user based, at least in part, on the first intent and the intent category(customer information, such a profile information(ie metadata) used to determine the intent and of the request and corresponding appropriate actions)
[0087] A user interface system is illustrated in FIG. 10. The user interface system 1000 is customizable and can adapt to various different user environments. A user customization unit 1002 determines how best to interact with a customer and his computing devices, and stores that user customization information in a user profile database 1004. The user customization information can include information about the specific devices and display screens which a user typically uses to interact with the production environment assistant 100. The user customization information can also include information about whether the user interacts via text, voice and/or video. Further, the user customization information can include information that allows the user interface system 1000 to adapt to specific user characteristics or traits, such as knowledge about a user's accent that must be taken into account when processing the user's voice commands. The information stored in the user profile database 1002 allows the user interface system 1000 to format information so that it can be effectively displayed on specific user computing devices, such as specific display screens, specific smartphones, tablets, and other mobile devices.
[0127] For example, in some embodiments the API within the production environment could examine and analyze individual items of customer feedback to determine a customer's intent in providing the customer feedback, as well as a desired outcome that the customer wishes to achieve by providing the customer feedback. In addition, the API could analyze individual items of customer feedback to determine a sentiment or emotional state of the customer when the customer left the item of customer feedback. All these individual items of information, the sentiment analysis, the intent and the desired outcome, can then be formatted into a data item for the customer feedback which is passed to the customer feedback receiving unit 1804.
Fighel teaches determinizing one ore more documents (i.e. playbooks) and Fighel further teaches gathering metric data(i.e. telemetry). Fighel does no teach use of the telemetry to identify playbooks thus Fighel does not teach determining whether one or more documents of an organization corresponding to the user match at least one of the one or more first entities, the first metadata, the first intent, and the intent category wherein the matching is according to at least one of semantic similarity and lexical similarity
based on determining that one or more documents of the organization match at least one of the one or more first entities, the first metadata, the first intent, and the intent category
determining whether telemetry data for the organization matches one or more cybersecurity appliances indicated in at least one of the one or more first entities and the first metadata for the user;
based on determining that the telemetry data for the organization matches the one or more cybersecurity appliances, generating a first response to the first utterance with a playbook agent;
and based on determining that telemetry data for the organization does not match the at least one of the one or more documents and the one or more cybersecurity appliances, generating a second response to the first utterance that at least indicates a subset of the one ore more documents;
Sridhar in the same field of endeavor as the invention teaches method and system for creating, querying and executing playbooks/workbooks to resolve network incidents. Sridhar teaches determining whether one or more documents of an organization corresponding to the user match at least one of the one or more first entities, the first metadata, the first intent, and the intent category wherein the matching is according to at least one of semantic similarity and lexical similarity(user’s query is processed to determine the particular workbooks/playbooks,(i.e. documents) associated with the user and the tenant of the user(i.e. organization), is used to retrieve applicable workbooks/playbooks for execution, determination is based on semantic interpretation of the query ¶s 587 1177-1178)
[0587] In some embodiments, the system 108 can use the syntax and semantics of a query to extract metadata from the query. For example, based on the known syntax of a query processing language, the system 108 can identify query commands and locations where information can be extracted, such as dataset names or identifiers, field names or identifiers, etc. Based on the syntax and semantics of the query, the system 108 can identify relationships between the datasets and fields of the query. Furthermore, the system 108 can iteratively parse the identified datasets to identify additional datasets, fields, relationships, etc. For example, the system 108 can use the dataset identifiers to identify and parse the corresponding dataset configuration records 604 to identify additional datasets, fields, and/or rules.
[1177] In some embodiments, at circle “5,” the IT and security operations application 1602 stores, in association with the user's account, the data related to the playbook 2710 for which the update was sent from the client device 2702. The stored data related to the playbook can include, for example, an identifier of the playbook, other playbook metadata, and can further include an indication that the playbook (or one or more portions thereof) is stored in the user's on-premises network 1610A. The playbook data can be stored in association with the user's account, for example, such that the user can view information about the playbook in various playbook management interfaces.
[1178] In some embodiments, at circle “6,” the IT and security operations application 1602 receives a request to execute the playbook. In some embodiments, a playbook is executed responsive to the IT and security operations application 1602 identifying one or more incidents that cause the playbook to be triggered automatically. As mentioned, an incident is a data structure representing incident data obtained from a tenant network, and is further associated with various events, artifacts, and other incident-related data. In some embodiments, incidents are stored in association with a tenant identifier (e.g., an identifier of an entity associated with one or more of tenant networks 1610A-1610N from which the data associated with the incident originated). Furthermore, in some embodiments, users can configure playbooks to be automatically triggered responsive to the IT and security operations application 1602 identifying one or more incidents of a particular type or that are associated with particular attributes. In other scenarios, a playbook can be executed responsive to a user manually selecting the playbook for execution, possibly relative to one or more user-identified incidents.
based on determining that one or more documents of the organization match at least one of the one or more first entities, the first metadata, the first intent, and the intent category(user’s query is processed to determine the particular workbooks/playbooks,(i.e. documents) associated with the user and the tenant of the user(i.e. organization), is used to retrieve applicable workbooks/playbooks for execution, ¶s 1177-1178)
determining whether telemetry data for the organization matches one or more cybersecurity appliances indicated in at least one of the one or more first entities and the first metadata for the user(logs, machine data, performance data and various other source of data(i.e. telemetry) regarding assets of a tenant are processed to determine asset targets for resolution/remediation implemented by execution of playbooks/workbooks, ¶s150, 1081, 1085, 1086 )
[0150] During operation, the data intake and query system receives machine data from any type and number of sources (e.g., one or more system logs, streams of network packet data, sensor data, application program data, error logs, stack traces, system performance data, etc.). The system parses the machine data to produce events each having a portion of machine data associated with a timestamp. The system stores the events in a data store. The system enables users to run queries against the stored events to, for example, retrieve events that meet criteria specified in a query, such as criteria indicating certain keywords or having specific values in defined fields. As used herein, the term “field” refers to a location in the machine data of an event containing one or more values for a specific data item. A field may be referenced by a field name associated with the field. As will be described in more detail herein, a field is defined by an extraction rule (e.g., a regular expression) that derives one or more values or a sub-portion of text from the portion of machine data in each event to produce a value for the field for that event. The set of values produced are semantically related (such as IP address), even though the machine data in each event may be in different formats (e.g., semantically-related values may be in different positions in the events derived from different sources).
[1081] In an embodiment, each of the IT assets 1614 in a tenant network can potentially serve as a source of incident data to an IT and security operations application 1602, an asset against which actions can be performed by the IT and security operations application 1602, or both. The IT assets 1614 can include various types of computing devices, software applications, and services including, but not limited to, a data intake and query system (which itself can ingest and process machine data generated by other IT assets 1614), a SIEM system, a REST client that obtains and/or generates incident data based on the activity of other IT assets 1614, software applications (including operating systems, databases, web servers, etc.), routers, intrusion detection systems and intrusion prevention systems (IDS/IDP), client devices (for example, servers, desktop computers, laptops, tablets, etc.), firewalls, and switches. The IT assets 1614 may execute upon any number separate computing device(s) and systems within a tenant network.
[1085] In some embodiments, to execute actions against IT assets in tenant networks and elsewhere, an IT and security operations application 1602 uses a unified security language that includes commands usable across a variety of hardware and software products, applications, and services. To execute a command specified using the unified language, in some embodiments, the IT and security operations application 1602 (via an on-premises action broker 1620) uses one or more connectors 1622 to translate the commands into the one or more processes or languages necessary to implement the action at one or more particular IT assets 1614. For example, a user might provide input requesting the IT and security operations application 1602 to remove an identified malicious process from multiple computing systems in the tenant network 1610A, where two or more of the computing systems are associated with different software configurations (for example, different operation systems or operating system versions). Accordingly, in some embodiments, the IT and security operations application 1602 can send an action request to an on-premises broker 1620, which then uses one or more connectors 1622 to translate the command into the necessary processes to remove each instance of the malicious process on the varying computing systems within the tenant network (including possible use of credentials and other information stored in the password vault 1624).
[1086] In some embodiments, an IT and security operations application 1602 includes a playbooks manager 1626 that enables users to automate actions or series of actions by creating digital “playbooks” that can be executed by the IT and security operations application 1602. At a high level, a playbook is a customizable computer program that can be executed by an IT and security operations application 1602 to automate a wide variety of possible operations related to an IT environment. These operations—such as quarantining devices, modifying firewall settings, restarting servers, and so forth—are typically performed by various security products by abstracting product capabilities using an integrated “app model.” Additional details related to operation of the IT and security operations application 1602 and use of digital playbooks are provided elsewhere herein.
based on determining that the telemetry data for the organization matches the one or more cybersecurity appliances, generating a first response to the first utterance with a playbook agent(display playbooks that are a best match(i.e prioritized ) for resolving the incident, ¶s 1122,1181)
[1122] Once a user has codified a playbook using a visual playbook editor or other interface, the playbook can be saved (for example, in a multi-tenant database 1636 and in association with one or more user accounts) and run by the IT and security operations application 1602 on-demand. As illustrated in the example playbooks above, a playbook includes a “start” block that is associated with source code that begins execution of the playbook. More particularly, the IT and security operations application 1602 executes the function represented by the start block for a playbook with container context comprising data about the incident against which the playbook is executed, where the container context may be derived from input data from one or more configured data sources. A playbook can be executed manually in response to a user providing input requesting execution of the playbook, or playbooks can be executed automatically in response to the IT and security operations application 1602 obtaining input events matching certain criteria. In embodiments where the source code associated with a playbook is based on an interpreted programming language (for example, such as the Python programming language), the IT and security operations application 1602 can execute the source code represented by the playbook using an interpreter and without compiling the source code into compiled code. In other examples, the source code associated with a playbook can first be compiled into byte code or machine code the execution of which can be invoked by the IT and security operations application 1602.
[1181] In some embodiments, execution of the playbook involves extracting the playbook code from the storage repository in the user's on-premises network 1610A, and using compute resources (e.g., physical servers, VMs, containers, etc.) to execute the playbook code. In some embodiments, a playbook engine is configured to dynamically extract portions of the playbook code and execute the code on demand as needed. For example, depending on a particular code flow of a given playbook execution, a playbook engine can extract the code associated with particular codeblocks of the playbook and execute those portions on demand, where the extracted and executed code can include blocks of custom code as described above. In some embodiments, execution of a playbook within an on-premises network 1610A can include storing data reflecting performance of the actions including, for example, data indicating searches queries that were executed, types of actions performed against assets related to an associated IT environment, indications of when the actions were performed, response information received from assets against which the actions were executed, an identifier of the user and associated tenant that requested the action, among other possible information. This information may be stored locally in the user's network and may also be sent to the IT and security operations application 1602 for storage as tenant data in a data store managed by the IT and security operations application 1602, data intake and query system 108, or both. Some portions of the data may be stored as metadata in association with the incident, in association with artifacts of the incident (for example, to indicate searches and actions performed involving particular IP addresses, file hashes, usernames, and so forth), in association with the user(s) and tenants performing the actions, and in association with possibly other data attributes stored across the IT and security operations application 1602.
and based on determining that telemetry data for the organization does not match the at least one of the one or more documents and the one or more cybersecurity appliances, generating a second response to the first utterance that at least indicates a subset of the one ore more documents(alternatively an playbooks may be displayed in arbitrary order, ¶1181)
[1181] In some embodiments, execution of the playbook involves extracting the playbook code from the storage repository in the user's on-premises network 1610A, and using compute resources (e.g., physical servers, VMs, containers, etc.) to execute the playbook code. In some embodiments, a playbook engine is configured to dynamically extract portions of the playbook code and execute the code on demand as needed. For example, depending on a particular code flow of a given playbook execution, a playbook engine can extract the code associated with particular codeblocks of the playbook and execute those portions on demand, where the extracted and executed code can include blocks of custom code as described above. In some embodiments, execution of a playbook within an on-premises network 1610A can include storing data reflecting performance of the actions including, for example, data indicating searches queries that were executed, types of actions performed against assets related to an associated IT environment, indications of when the actions were performed, response information received from assets against which the actions were executed, an identifier of the user and associated tenant that requested the action, among other possible information. This information may be stored locally in the user's network and may also be sent to the IT and security operations application 1602 for storage as tenant data in a data store managed by the IT and security operations application 1602, data intake and query system 108, or both. Some portions of the data may be stored as metadata in association with the incident, in association with artifacts of the incident (for example, to indicate searches and actions performed involving particular IP addresses, file hashes, usernames, and so forth), in association with the user(s) and tenants performing the actions, and in association with possibly other data attributes stored across the IT and security operations application 1602.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Fighel natural language processing of action intends by further implementing identifying playbooks based on metadata and telemetry data to identifying playbooks corresponding to a customer/tenant as taught by Sridhar. The reason for this modification would be to identify playbooks that are customized and specific to the tenant thus more likely to resolve security/network incidents.
Regarding claims 2, 10 and 16, Sridhar teaches identifying the playbook agent as matching the one or more cybersecurity appliances and at least one of the one or more first entities, the first metadata, the first intent, and the intent category;(analysis of the tenants(i.e. entities) and past incident data regarding security appliances(firewalls etc ¶1072) and identify remediations to security incidents, i.e. stop exfiltration command triggers playbooks to resolve data exfiltration, ¶s1154),
[1072] The management of IT environments often further includes responding to various types of incidents that occur over time and which may be identified from various analyses of the data generated by IT components in those environments, as described above. Such incidents can include security-related incidents (such as viruses, network-based attacks, etc.), IT operations-related incidents (for example, hardware failures, software bugs, etc.), or any other events that potentially impact the operation of an IT environment. Occurrences of such incidents can be flagged by the systems detecting the incidents and incident-related information may be provided to an administrator or other user for analysis and remediation. Once a possible solution to an incident is identified, the process for remediating such incidents can involve interacting with one or several assets within the IT environment. For example, in response to identifying a security-related issue involving an endpoint device, a system administrator might use security software to quarantine the endpoint device, interact with a firewall to update network settings, among other possible actions.
[1154] FIG. 20 illustrates an example workbook template review interface displaying information related to a defined workbook template according to some embodiments. For example, as illustrated in the workbook template review interface 2000 shown in FIG. 20, the phases of a created “Data Breach” workbook template include: a phase 2002A labeled “Escalate to accountable system owners,” a phase 2002B labeled “Stop the exfiltration,” a phase 2002C labeled “Remove persistent adversaries,” and a phase 2002D labeled “Assess impact.” Additional phases not pictured can include, for example, phases labeled “Report to appropriate stakeholders” and “Prevent future breaches.” As illustrated in FIG. 20, the tasks associated with the phase 2002B include: “Identify likely means of exfiltration,” “Determine mitigations and remediations,” and “Stop exfiltration”; the tasks associated with phase 2002C include: “Identify likely means of persistence” and “Removed identified persistence mechanisms”; and the task for phase 2002D include: “Measure the size and scope.” The workbook template review interface 2000 further displays, for each task, an indication of a number of actions and playbooks associated with the task, as well as an owner of the task, if any. A user can select an edit button 2004 to further configure the workbook template, if desired.
and generating the first response to the first utterance based on inputting features of at least one of the one or more first entities, the first metadata, the first intent, and the intent category into the playbook agent (base on analysis of query display associated playbooks associated with past it security remediation, ¶s1151,1154)
[1151] In some embodiments, an IT and security operations application 1602 further optimizes the presentation of executable actions and playbooks displayed in connection with workbook tasks. For example, instead of displaying the actions and playbooks associated with workbook tasks in an arbitrary order, the IT and security operations application 1602 can monitor and log the efficacy of each action and playbook over time and use such data to determine a prioritized order in which to display the actions/playbooks in a workbook (or determine whether to display particular actions or playbooks at all). For example, when an action associated with a task is executed, the IT and security operations application 1602 can monitor the action's execution and determine whether the action executed successfully (for example, if an action is configured to terminate a process running on an endpoint device, the IT and security operations application 1602 can determine whether the action was actually able to successfully connect to the endpoint device and terminate the process). This information can be collected over time and used, for example, to display actions/playbooks associated with various tasks in an order that reflects how successful each action/playbook historically has been in completing the task so that analysts can be guided to those actions/playbooks most likely to successfully complete a task. In some embodiments, this data can be collected and analyzed on a per-tenant basis and, in some embodiments, collected and analyzed across some or all tenants of the IT and security operations application 1602.
[1154] FIG. 20 illustrates an example workbook template review interface displaying information related to a defined workbook template according to some embodiments. For example, as illustrated in the workbook template review interface 2000 shown in FIG. 20, the phases of a created “Data Breach” workbook template include: a phase 2002A labeled “Escalate to accountable system owners,” a phase 2002B labeled “Stop the exfiltration,” a phase 2002C labeled “Remove persistent adversaries,” and a phase 2002D labeled “Assess impact.” Additional phases not pictured can include, for example, phases labeled “Report to appropriate stakeholders” and “Prevent future breaches.” As illustrated in FIG. 20, the tasks associated with the phase 2002B include: “Identify likely means of exfiltration,” “Determine mitigations and remediations,” and “Stop exfiltration”; the tasks associated with phase 2002C include: “Identify likely means of persistence” and “Removed identified persistence mechanisms”; and the task for phase 2002D include: “Measure the size and scope.” The workbook template review interface 2000 further displays, for each task, an indication of a number of actions and playbooks associated with the task, as well as an owner of the task, if any. A user can select an edit button 2004 to further configure the workbook template, if desired.
Regarding claims 4, 12 and 18, Sridhar teaches wherein the organization comprises a cybersecurity organization, wherein the first utterance is related to operations of a cybersecurity implementation for the user by the organization(analyze queries from tenant(organization) in a multi-tenant environment correspond to IT security operations to perform a corresponding playbooks to be executed, ¶945,1077)
[0945] At block 1210, the search head 504 combines the partial results and/or events received from the search nodes 506 to produce a final result for the query. In some examples, the results of the query are indicative of performance or security of the IT environment and may help improve the performance of components in the IT environment. This final result may comprise different types of data depending on what the query requested. For example, the results can include a listing of matching events returned by the query, or some type of visualization of the data from the returned events. In another example, the final result can include one or more calculated values derived from the matching events.
[1077] As an example of using the application environment 205, the IT and security operations application 1602 includes various custom web-based interfaces (e.g., provided by a front end service 1608) that may or may not leverage one or more UI components provided by the application environment 205. In this context, “mission control” refers to any type of interface or set of interfaces that enable users broadly to obtain information about their IT environments, configure automated actions, playbooks, etc., and perform other operations related to IT and security infrastructure management. The IT and security operations application 1602 may further include middleware business logic (including, for example, an incident management service 1628, a threat intelligence service 1630, an artifact service 1632, a file storage service 1634, and an orchestration, automation, and response (OAR) service 1616) implemented on a middleware platform of the developer's choice. Furthermore, in some embodiments, an IT and security operations application 1602 is instantiated and executed in a different isolated execution environment relative to the data intake and query system 108. As a non-limiting example, in embodiments where the data intake and query system 108 is implemented in a Kubernetes cluster, the IT and security operations application 1602 may execute in a different Kubernetes cluster (or other isolated execution environment system) and interact with the data intake and query system 108 via the gateway 215.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Fighel/Sridhar with implementation of the playbook determination methods to a multi-tenant IT security system as taught by Sridhar. The reason for this modification would be to implement determination of playbooks to resolve customer security problems.
Claims 3, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Sridhar as applied to claims 1, 9 and 15 above, and further in view of Garay US 2018/0307756.
Regarding claims 3, 11 and 17, Fighel/Sridhar teaches methods for analyzing customer request to identify playbooks to execute to resolve a customer’s problem but does teach and handling for when a playbook can not be identified. Thus Fighel/Sridhar do not teach based on determining at least one of that one or more second entities, second metadata, a second intent, and a second intent category for a second utterance do not match a playbook agent and do not match the documents for the organization and that the one or more second entities, the second metadata, the second intent, and the second intent category do not match the documents for the organization and the second metadata do not indicate one or more security appliances, generating a response to the first utterance prompting the user to create a ticket related to the first utterance. Garay in the same field of endeavor as the invention teaches a system for identifying resolutions from previous recorded action resolutions. Garay teaches determining that the one or more documents of the organization do not match at least one of the one or more first entities, the first metadata, the first intent, and the intent category and that the telemetry data for the organization does not match the one or more cybersecurity appliances indicated in at least one of the one or more first entities and the first metadata for the user ,generating a third response to the first utterance prompting the user to create a ticket related to the first utterance.(determine that a resolution could not be found and redirected the user toa ticketing system to creating a incident resolution ticket, ¶s 28-30)
[0028] In response to the server device receiving the series of actions (e.g., user commands and corresponding transaction steps) and incident data tracked and recorded by the customer instance (e.g., by an information collector of the customer instance), a database can be queried by the server device for resolution information related to other issues that are similar to the current issue. The actions that led to the occurrence of an incident can be referred to as path to pain point information. Therefore, the server device can provide resolution options for resolving the current issue based on the issue related information and historical information associated with the other issues. The historical information can include but is not limited to information regarding the client device and the customer instance, information regarding other client devices, and information regarding other customer instances. The historical information can also include information regarding the server device that is in communication with the client device or other server devices.
[0029] Once resolution information has been identified or generated, the resolution information can be sent back to the client device to resolve the issue. The incident or issue can be resolved automatically using the transmitted resolution information or can require manual implementation of the resolution information by the client device or third-party. The resolution information can be identified via a list of search results that is returned from the database query to provide the client device with recommendations (or resolution options) for resolving the current issue. If the list is empty or no list is returned because no applicable resolution options could be found, the client device could be redirected to a page on the customer instance to create and submit an incident report/ticket. The created incident report can include the path to pain related information and additional information that can be submitted.
[0030] In some implementations, the resolution information that is identified and transmitted to the client device for resolution of the current issue can be determined by comparing the pathways (i.e., path to pain points) taken by the client device up to the point that the issues occurred and the information associated with the pathways (e.g., user commands and corresponding transaction steps). The path to pain points can comprise all of or at least a portion of the information related to the reproduction of the issue which includes but is not limited to the path to pain point information including but not limited to the recorded actions (e.g., user commands and corresponding transaction steps), incident data including but not limited to error types, descriptions, and any additional information that is either recorded and/or submitted and utilized to identify/generate the resolution information.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Fighel/Sridhar with redirection of a user request to a ticketing system as taught by Garay. The reason for this modification would be to provide error handling when no playbook/solutions capable of resolving a problem are found.
Claims 5, 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Sridhar as applied to claims 1, 9 and 15 above, and further in view of Hudetz US 2024/0370479
Regarding claims 5, 13 and 19, Fighell/Sridhar does not teach ranking the one or more documents based on semantic and lexical similarity, wherein ranking one or more documents based on semantic similarity and lexical similarity comprises
ranking the one or more documents based on semantic similarity with at least one of the one or more first entities, the first metadata, the first intent, and the intent category to obtain a first ranking
ranking the one or more documents based on lexical similarity with at least one of the one or more first entities, the first metadata, the first intent, and the intent category to obtain a second ranking
and fusing the first ranking and the second ranking to obtain a third ranking as the ranking of the one or more documents based on a combination of semantic similarity and lexical similarity
Hudetz being reasonably pertinent to searching documents using semantic and lexical analysis. Hudetz teaches ranking the one or more documents based on semantic and lexical similarity, wherein ranking one or more documents based on semantic similarity and lexical similarity comprises(rank search results based on a combination lexical ranked first search results and then semantic re-ranking using semantic search, ¶155)
[0155] Another example of a pre-built engine that uses contextualized embeddings for content-based search is Azure Cognitive Search made by Microsoft® Corporation. Azure Cognitive Search utilizes semantic search, which is a collection of query-related capabilities that bring semantic relevance and language understanding to search results. Semantic search is a collection of features that improve the quality of search results. When enabled by the search manager 124, such as a cloud search service, semantic search extends the query execution pipeline in two ways. First, it adds secondary ranking over an initial result set, promoting the most semantically relevant results to the top of the list. For instance, the search manager 124 may use the lexical search generator 732 to perform a lexical full-text search to produce and rank a first set of search results 146. The search manager 124 may then use the semantic search generator 702 to perform a semantic search that does a semantic re-ranking, which uses the context or semantic meaning of a search query 144 to compute a new relevance score over the first set of search results 146. Second, it extracts and returns captions and answers in the response, which the search manager 124 can render on a search page to improve user search experience. The semantic search generator 702 extracts sentences and phrases from an electronic document 706 that best summarize the content, with highlights over key passages for easy scanning. Captions that summarize a result are useful when individual content fields are too dense for the results page. Highlighted text can be used to elevate the most relevant terms and phrases so that users can quickly determine why a match was considered relevant. The semantic search generator 702 may also provide semantic answers, which is an optional and additional substructure returned from a semantic query. It provides a direct answer to a query that looks like a question.
ranking the one or more documents based on semantic similarity with at least one of the one or more first entities, the first metadata, the first intent, and the intent category to obtain a first ranking(reranking to generating scoring based on semantics, ¶155 )
ranking the one or more documents based on lexical similarity with at least one of the one or more first entities, the first metadata, the first intent, and the intent category to obtain a second ranking(default scoring using lexical search to obtain first set of documents based on lexical similarity, ¶42)
[0042] While lexical searching can be a useful tool in many situations, it also has some limitations and potential problems. For example, lexical searching only looks for exact matches of the specified search terms, which means that it may miss relevant information that uses similar or related words or phrases. Lexical searching may also return false positives, or instances where the specified search terms appear in the text but are not actually relevant to the desired search results. This can happen, for example, if the search terms appear in a different context or with a different meaning than intended. Lexical searching may also miss instances of the search terms due to differences in spelling, punctuation, or word order. For example, if the search term is “color,” it may miss instances of “colour” or “colorful.” Some words or phrases may have multiple meanings, which can lead to ambiguity in lexical searching. For example, the word “bank” could refer to a financial institution or the side of a river. One particular challenge for lexical searching is that it does not capture or address contextual differences in words or phrases. The meaning of a word or phrase can depend on the context in which it appears. Lexical searching may miss or misinterpret instances of the search terms if it does not take into account the surrounding text or the overall meaning of the document.
and fusing the first ranking and the second ranking to obtain a third ranking as the ranking of the one or more documents based on a combination of semantic similarity and lexical similarity(re-ranking with semantics, ¶155)
[0155] Another example of a pre-built engine that uses contextualized embeddings for content-based search is Azure Cognitive Search made by Microsoft® Corporation. Azure Cognitive Search utilizes semantic search, which is a collection of query-related capabilities that bring semantic relevance and language understanding to search results. Semantic search is a collection of features that improve the quality of search results. When enabled by the search manager 124, such as a cloud search service, semantic search extends the query execution pipeline in two ways. First, it adds secondary ranking over an initial result set, promoting the most semantically relevant results to the top of the list. For instance, the search manager 124 may use the lexical search generator 732 to perform a lexical full-text search to produce and rank a first set of search results 146. The search manager 124 may then use the semantic search generator 702 to perform a semantic search that does a semantic re-ranking, which uses the context or semantic meaning of a search query 144 to compute a new relevance score over the first set of search results 146. Second, it extracts and returns captions and answers in the response, which the search manager 124 can render on a search page to improve user search experience. The semantic search generator 702 extracts sentences and phrases from an electronic document 706 that best summarize the content, with highlights over key passages for easy scanning. Captions that summarize a result are useful when individual content fields are too dense for the results page. Highlighted text can be used to elevate the most relevant terms and phrases so that users can quickly determine why a match was considered relevant. The semantic search generator 702 may also provide semantic answers, which is an optional and additional substructure returned from a semantic query. It provides a direct answer to a query that looks like a question.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Fighel/Sridhar with identifying playbooks based upon a combination of lexical(keyword) and semantic similarity analysis as taught by Hudetz. The reason for this modification would be to increase the accuracy and relevancy of playbooks to resolve the customer’s request.
Regarding claim 6, Hudetz teaches wherein generating the response comprises abstractive summary generation of content from the subset of highest ranked documents of the one or more documents to generate one or more summaries of the subset of highest ranked documents(summary/annotations of documents are display with ranking, ¶156)
[0156] In one embodiment, the semantic search generator 702 may implement Azure Cognitive Search to perform semantic searching and perform semantic ranking. Semantic ranking looks for context and relatedness among terms, elevating matches that make more sense given the search query 144. Language understanding finds summarizations or captions and answers within document content and includes them in the response, which can then be rendered on a search results page for a more productive search experience. Pre-trained models are used for summarization and ranking. To maintain the fast performance that users expect from search, semantic summarization and ranking are applied to a set number of results, such as the top 50 results, as scored by the default scoring algorithm. Using those results as the document corpus, semantic ranking re-scores those results based on the semantic strength of the match.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Sridhar/Hudetz as applied to claim 6 above, and further in view of Gruber US 2012/0265528.
Regarding claim 7, Fighel/ Sridhar/Hudetz do not teach wherein generating the response further comprises, generating one or more prompts to a second language model, wherein the one or more prompts comprise the one or more summaries and indications of tone and verbosity for the response; and prompting the second language model with the one or more prompts to obtain the response. Gruber being reasonably related to the use of natural language interpretation of user input teaches a system for processing user commands to a virtual assistant, Gruber teaches wherein generating the response further comprises, generating one or more prompts to a second language model, wherein the one or more prompts comprise the one or more summaries and indications of tone and verbosity for the response; and prompting the second language model with the one or more prompts to obtain the response(contextual information regarding tone and verbosity of user request are used to generate dialog responses, ¶s20-24, 358).
[0020] Context can be applied to a variety of computations and inferences in the operation of the virtual assistant. For example, context can be used to reduce ambiguity or otherwise constrain the number of solutions as user input is processed. Context can thus be used to constrain the solutions during various phases of processing, including for example and without limitation: [0021] Speech Recognition--receiving voice input and generating candidate interpretations in text, for example, "call her", "collar", and "call Herb". Context can be used to constrain which words and phrases are considered by a speech recognition module, how they are ranked, and which are accepted as above a threshold for consideration. For example, the user's address book can add personal names to an otherwise language-general model of speech, so that these names can be recognized and given priority.
[0022] Natural Language Processing (NLP)--parsing text and associating the words with syntactic and semantic roles, for example, determining that the user input is about making a phone call to a person referred to by the pronoun "her", and finding a specific data representation for this person. For example, the context of a text messaging application can help constrain the interpretation of "her" to mean "the person with whom I am conversing in text."
[0023] Task Flow Processing--identifying a user task, task steps, and task parameters used to assist with the task, for example, which phone number to use for the person referred to as "her". Again, the context of the text messaging application can constrain the interpretation of the phone number to indicate that the system should use the number currently or recently used for a text messaging conversation.
[0024] Dialog Generation--generating assistant responses as part of a conversation with the user about their task, for example, to paraphrase the user's intent with the response "OK, I'll call Rebecca on her mobile . . . " The level of verbosity and informal tone are choices that can be guided by contextual information.
[0358] During dialog response generation 500, assistant 1002 may paraphrase back its understanding of the user's intent and how it is being operationalized in a task. An example of such output is "OK, I'll call Rebecca on her mobile . . . " This allows the user to authorize assistant 1002 to perform the associated task automation, such as placing a call. In dialog generation step 500, assistant 1002 determines how much detail to convey back to the user in paraphrasing its understanding of the user's intent.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Fighel/Sridhar/Hudetz with a natural language processing models that analyze verbosity and tone of request to determine intent of a user request. The reason for this modification would be to improve determination of the intent of a user request.
Claims 8, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Sridhar as applied to claims1, 9 and 15 above, and further in view of Vukovic US 2025/0069595 .
Regarding claims 8, 14 and 20, Fighel/Sridhar does not teach wherein the first language model comprises a large language model, wherein the instructions to input the first utterance into the large language model comprise instructions to few-shot prompt one or more prompts as inputs to the large language model to obtain the first intent and the first intent category as output. Vukovic in the same field of endeavor teaches a large language model based playbook system. Vukovic teaches wherein the first language model comprises a large language model, wherein prompting the large language model comprise instructions to few-shot prompt one or more prompts as inputs to the large language model to obtain the first intent and the first intent category as output(prompt provided LLM for execution of playbooks, ¶s 4, 27,28,29).
[0004] In accordance with still other aspects of the disclosure, the method may further include identifying a control level for the runtime manager, wherein the control level defines the extent to which the runtime manager is to identify particular execution states in connection with the execution of the playbook by the LLM. Identifying the control level may further include selecting between at least a first level of higher control and a second level of lower control, and the runtime manager may identify more execution states under the first level of higher control than under the second level of lower control. If the control level is identified as a low level of control, instructing the large language model to execute the playbook comprises the large language model performing group of multiple instructions from the plurality of instructions without providing the runtime manager with an execution state in connection with the group of multiple instructions. In addition, identifying the control level may be based on a user selecting the control level from a plurality of potential control levels.
[0027] FIG. 2 is a representation of a type of instruction set that can be found within a playbook 200. These instructions may take the form of prompts that provide contextual information, commands to perform actions, or logic regarding conditional requirements for one or more instructions. These instructions may include human-readable natural language instructions, as well as specific calls to other applications, such as calls to one or more plug-ins. Playbook 200 of FIG. 2 provides a description of the types of instructions that
[0028] For example, the first instruction 202 of playbook 200 can take the form of a prompt that describes the goal of the overall task that is to be performed. This instruction 202 prompt may contain information about the context of the playbook's execution, including what is hoped to be achieved by the execution of the playbook, as well as information about the reason that the playbook is being executed. The goal identified in instruction 202 may be general or detailed, depending on the context that the playbook is to be used. For example, instruction 202 may state that “Your goal is to collect payments from customers.” Instruction 202 may also provide additional context of the goal, if the playbook has been designed for that particular context. For example, instruction 202 may state that “Your goal is to collect payments from customers who are more than a month late in making their payments.” Instruction 202 can be designed to provide enough information to a particular LLM that the LLM will be configured in response to instruction 202 to perform the remaining instructions of playbook 200 in the desired fashion.
[0029] Instruction 204 is a prompt that identifies the available actions within the given specifications of the application programming interface (“API”). Instruction 204 may include a plurality of generation instructions 205a-b that list available tools and available actions to be taken during execution of playbook 200. The instructions 205a-b may also include dynamically updated generation instructions. For example, the runtime manager may dynamically update variables or other parameters with specific data that has been obtained from the user or elsewhere. These dynamically updated parameters may be provided as generation instructions 205a-b that define the values of particular parameters.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Fighel/Sridhar with a LLM based interpreter as taught by Vukovic. The reason for this modification would be to apply a LLM based artificial intelligence system for determining and execute playbooks. Such a modification corresponding to a simple substitution of the CLIPS AI engine with a LLM based engine.
Applicant Remarks
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights