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 11/06/2025. Claims 1-15, 17, 19, 23-26 are currently pending of which claims 1-15, 17, 19 and 23-26 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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15, 17, 19, 23-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claims recite a hyper-scale cloud environment comprising an application installed on the hyper-scale cloud environment which is software per se. The claim is directed toward an environment comprising an application thus the whole of the alleged environment comprises the application, i.e. software. An environment is not one of the statutory classes of processes, machines, manufactures, and compositions of matter and software in and of itself is also not one of the four statutory classes. The specification does not describe or support any statutory machine, manufacture, process or matter for the application. Thus the claims recite an environment comprising solely an application(i.e. software). Thus claims 1-15, 17, 19, 23-26 are directed to software per se.
Response to 1.132 Affidavits
The applicant’s submission of declarations under 1.132 has been considered. Declarations under 1.132 include the categories of:
Unexpected results-
Commercial Success-
Long-Felt Need and Failure of Others-
Inoperability of References-
Skepticism of Experts-
Copying by Others-
It appears that the only declaration corresponding to such categories include Commercial Success made on page 5 of the affidavit. The remainder of the arguments correspond to arguments of non-analogousness of cited references and alleged deficiencies of the art the teach the claims. Such arguments will be addressed a presented even though non strictly associated with declaration under 1.132.
The applicant alleges in a page 2 of the affidavit that the citing of Fighel is improper, and it appears that the applicant is alleging non-analogous art on the basis that Fighel and the instant application is directed toward different purposes. The applicant alleges that Fighel is directed toward resolution of operational bottlenecks in the business processes of a network whereas the instant application is directed toward a cybersecurity system. The examiner contends that the MPEP 2141.01 establishes analogous art can be established based on the prior art being in the same field of endeavor as the invention. In this case Fighel is directed toward executing scripts, including playbooks to resolve network events. The instant application is directed toward the use of playbooks to resolve security events. While the instant application may be directed more precisely to security events, both Fighel and the instant application are more generally directed toward resolution of events in a network using automated actions(scripts, playbooks), Thus Fighel is in the same field of endeavor as the instant application, is analogous and the combination with Cristofl and Zavesky is proper..
The applicant argues on page 3 of the affadvit that Cristofl is non-analogous because the Cristofl describes a manual oversite system in contrast to an automatic system of the instant application. Again, the examiner contends that the MPEP 2141.01 establishes that analogousness can be established by being the same field of endeavor as the invention. The instant application is directed toward the use of playbooks to resolve security events. Cristofl is also directed toward a system for resolution of network events including security events using playbooks. Thus, Cristofl is in the same field of endeavor as the instant application, is analogous and the combination with Fighel and Zavesky is proper.
The applicant further argues on page 3 of the affidavit against the combination of Fighel/Cristofl and Zavesky because the applicant alleges Zavesky is directed toward a different operational phase and have different fundamental requirements. The examiner contends that Zavaesky is analogous to the invention as required by the MPEP to establish obviousness to combine. The instant application is directed toward the use of playbooks to resolve security events. Cristofl is also directed toward a system for resolution of network events including security events using playbooks. Thus, Cristofl is in the same field of endeavor as the instant application, is analogous and the combination with Fighel and Zavesky is proper. The applicant further argues that Zavetsky does not remedy the deficiencies of the primary references because the applicant alleges Zavesky contains no teaching of :
- Capturing system state before making changes;
- Storing original configurations for later restoration;
- Generating rollback procedures; and
- Executing restoration operations.
The examiner is unpersuaded that such arguments supports a basis that Zavetsky is deficient because such elements are not recited by the claims, thus such arguments are moot since they are not required by the claims
The applicant further argues on page 4 of the affidavit that the three references are completely unrelated problems in different technical domains. The examiner contends that the test for analogousness is not whether the references are analogous to each other but whether they are analogous to the invention. As discussed above all three references are in the same field of endeavor as the invention, thus the references are analogous.
The applicant argues on page 4 of the affidavit that the combination of Fighel. Cristofl and Zavetsky relies upon hindsight reasoning. MPEP 2145 establishes with respect to the applicant allegation of hindsight reasoning: Applicants may argue that the examiner’s conclusion of obviousness is based on improper hindsight reasoning. However, “[a]ny judgment on obviousness is in a sense necessarily a reconstruction based on hindsight reasoning, but so long as it takes into account only knowledge which was within the level of ordinary skill in the art at the time the claimed invention was made and does not include knowledge gleaned only from applicant’s disclosure, such a reconstruction is proper.” In re McLaughlin, 443 F.2d 1392, 1395, 170 USPQ 209, 212 (CCPA 1971). In this case the examiner contends that one of ordinary skill at the time of the invention would be aware of various systems and methods as describe in Fighel, Cristofl and Zavesky of event/incidents resolution using playbooks. Thus the combination relies on knowledge of one of ordinary skill in the art at the time of the invention. No improper hindsight is relied upon by the examiner.
The applicant alleges on page 5 of the affidavit that system is adopted by TD Synnex and Tech Data ANZ… alleging commercial success as the basis for an argument against the examiner’s rejection. The examiner has considered and contends that such a declaration is insufficient. The applicant provides a mere declaration of commercial success, no evidence is provided that would lead an examiner to conclude by a preponderance of the evidence that the claims of the invention are patentable.
Thus in consideration of the applicant’s declaration the examiner is not persuaded of the allowability of the claims under such declarations.
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.
Claim 1-6, 15, 19, 23 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel US 2018/0114234, further in view of Cristofl US 2021/0117251 and Zavesky US 2019/0342187.
Regarding claim 1, Fighel teaches a hyper-scale cloud environment comprising :
an application installed on the hyper-scale cloud environment, the application comprising a remediation playbook comprising at least one remediation having at least one action for a standard control(system provides a computing system that is able to detecting events and correlate events to remediation scripts such as playbooks, ¶84),
[0084] In one particular implementation, the remediation action database 910 can utilize Ansible Playbooks. A remote execution model over secure shell (SSH) is used to execute the procedure on each host, or by executing a set of API instructions on the infrastructure, such as Amazon Web Services Public Cloud provider, Google Cloud, Microsoft Azure Cloud or any other public or private cloud service (such as Cloud Foundry, OpenStack and others) as long as they support Application Protocol Interface (API). By providing a single repository and exposing it based on remediation key words, systems and actions, anyone can search for a specific use case and find a relevant playbook or remediation script. A contributor can share from his own experience by writing a remediation script according to a pre-defined template, and uploading it to the shared repository. It is then possible for the system to index each key word and action term from the pre-defined template, and make it available for execution by anyone. Sharing the system and remediation knowledge increases remediation reliability and decreases execution errors.
a configuration interface for configuring a response level and(GUI/voice interface allows user to set response levels… i.e. a high level cpu level triggers reboot server, ¶s47,116)
[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.
[0116] In some instances, a customer can place a telephone call to a business' customer service line, and that telephone call can be handled either by a live operator, by an interactive voice response application, or by combinations of both where interactive voice response application directs a customer to an appropriate customer service agent. In addition, customers can provide customer feedback via email messages, text messages, or by interacting with an online graphical user interface maintained by the business. Customer feedback can also be provided in various other ways, such as in-person visits, and via regular mail, as is well known to those of ordinary skill in the art.
a listener which, in use, receives an alert from a SIEM of the Hyper-scale cloud environment, identifies the remediation using the alert and implements the action of the remediation depending on the response level(production environment assistant that monitors (i.e. listens ) for events/anomalies determines the proper remediation to perform where such determination is based on a level threshold being exceed, ¶s38,72,138)
[0038] Each of the above discussed elements of the production environment assistant 100 are discussed in more detail below. In addition, FIGS. 11-17 illustrate the steps of various methods that would be performed by the elements of the production environment assistant 100 to monitor a client's production environment, determine when issues or problems have arisen, report on those problems or issues, as well as take remedial action.
[0072] If the analysis unit 512 ultimately concludes that a problem or issue is occurring or may be occurring within a client's production environment, the analysis unit indicates that an “incident” has occurred. The term “incident” is a broad term which is intended to apply to any type of activity, trend, occurrence or event which could be viewed as an issue or problem for a client's production environment. Incidents can be raised once a specific condition has been confirmed by the evaluation unit 500. A condition can be an Anomaly detected, a specific metric calculation or data point that is above or below a threshold, an event (such as a new code deployment, a new scaling activity detected or a configuration change detected), a complicated computation such as rate of change, or even a combination between all of the above. Incidents can be analyzed as well and take into account for the next evaluation cycle.
[0138] The information stored in the correlations database 1822 can be used in the future to help determine whether specific types of anomalous events may be occurring within a production environment when certain types of customer feedback are received for that production environment. For example, the correlations database 1822 may include information that indicates when a first type of anomalous event occurs, a first type of customer feedback is likely to be received. If the production environment begins to receive that first type of customer feedback, the receipt of that first type of customer feedback could indicate that the first type of anomalous event may be occurring within the production environment. System operators could then check to determine if that potential anomalous event is occurring. If so, an appropriate remediation action could be taken to solve the problem. In other instances, automated systems may be in place to check for the existence of one or more types of anomalous events within a production environment when certain types of customer feedback are received for that production environment.
causes a computer device to carry out a method, the method is configured for: sentence structure string matching to convert natural language remediation instructions to playbook actions, whereby verbs and nouns identified from the natural language remediation instructions by the using sentence structure string matching are converted into actions and settings respectively(user verbal or textual requests are processed by natural language engines and identify verbs(ie. Actions restart/increase) and nouns(i.e. setting such as 50% cpu server 123) to translate user intended action into a remediation action where such remediation action include generating and executing playbooks, ¶s47,84,95)
[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.
[0084] In one particular implementation, the remediation action database 910 can utilize Ansible Playbooks. A remote execution model over secure shell (SSH) is used to execute the procedure on each host, or by executing a set of API instructions on the infrastructure, such as Amazon Web Services Public Cloud provider, Google Cloud, Microsoft Azure Cloud or any other public or private cloud service (such as Cloud Foundry, OpenStack and others) as long as they support Application Protocol Interface (API). By providing a single repository and exposing it based on remediation key words, systems and actions, anyone can search for a specific use case and find a relevant playbook or remediation script. A contributor can share from his own experience by writing a remediation script according to a pre-defined template, and uploading it to the shared repository. It is then possible for the system to index each key word and action term from the pre-defined template, and make it available for execution by anyone. Sharing the system and remediation knowledge increases remediation reliability and decreases execution errors.
[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).
Fighel teaches creation and execution of playbooks via natural language processing of user requests. Fighel does not teach prompting the user for settings and thus does not teach
prompting a user via the configuration interface to provide a setting for at least one converted playbook action,
wherein the application further comprises a reverse playbook associated with the playbook
and mappings between controls of the remediation playbook and the further remediation playbook so that, when an action of the remediation playbook is implemented, an associated action of the further remediation playbook is identified using the mapping and subsequently implemented
Christofl in the same field of endeavor as the invention teaches a system for creation and execution of playbooks. Christofl teaches prompting a user via the configuration interface to provide a setting for at least one converted playbook action(configured playbooks that prompt user for one or more setting(i.e. update network settings), ¶s 998,1011, 1032)
[0998] The management of IT environments often further includes responding to various types of incidents that occur over time and which may be identified from analyses of data generated by IT components in those environments, as described above. Such incidents can include security-related incidents (such as viruses, network-based attacks, and the like), IT operations-related incidents (for example, hardware failures, software bugs, and so forth), 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.
[1011] In some embodiments, an IT and security operations application 1702 includes a playbooks manager 1726 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 1702. At a high level, a playbook is a customizable computer program that can be executed by an IT and security operations application 1702 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 1702 and use of digital playbooks are provided elsewhere herein.
[1032] In some embodiments, a prompt block is associated with various properties that can be configured by a user using a visual playbook editor including, for example, configurations indicating a prompt approver, a required response time, a message prompt, and a response type. The assignment of a prompt approver indicates an individual user or user role (e.g., administrator, engineer, manager) that is to receive the prompt to be acted upon during execution of the corresponding playbook. A required response time indicates an amount of time that an assigned approver or set of approvers have to complete the prompt, for example, by accessing the prompt and providing any requested information or otherwise performing actions specified by the prompt. A message prompt is information that is displayed to a user when the user accesses an assigned prompt (for example, a message prompt can be presented as part of a GUI interface element displayed to a user accessing an assigned prompt). A response type indicates a type of acceptable response that can be provided by a user to successfully complete the prompt (for example, a yes/no response, a numerical value response, a text-based response, or a response from an enumerated list of options).
wherein the application further comprises a reverse playbook associated with the playbook and(playbooks can include actions to rollback(i.e. reverse) setting/parameters to applications ¶s 376,1010)
[0376] Moreover, the query system manager 502 can handle resource management, creation, assignment, or destruction of search heads 504 and/or search nodes 506, high availability, load balancing, application upgrades/rollbacks, logging and monitoring, storage, networking, service discovery, and performance and scalability, and otherwise handle containerization management of the containers of the query system 214. In certain embodiments, the query system manager 502 can be implemented using Kubernetes or Swarm. For example, in certain embodiments, the query system manager 502 may be part of a sidecar or sidecar container that allows communication between various search nodes 506, various search heads 504, and/or combinations thereof.
[1010] In some embodiments, to execute actions against IT assets in tenant networks and elsewhere, an IT and security operations application 1702 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 1702 (via an on-premises action broker 1720) uses one or more connectors 1722 to translate the commands into the one or more processes or languages necessary to implement the action at one or more particular IT assets 1714. For example, a user might provide input requesting the IT and security operations application 1702 to remove an identified malicious process from multiple computing systems in the tenant network 1710A, 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 1702 can send an action request to an on-premises broker 1720, which then uses one or more connectors 1722 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 1724).
and mappings between controls of the remediation playbook and the further remediation playbook so that, when an action of the remediation playbook is implemented, an associated action of the further remediation playbook is identified using the mapping and subsequently implemented (execution of a playbook include playbooks that rollback applications to a previous version/configuration to state of the application, executions of the action blocks/nodes of a playbook implement the reverting of changes ¶s 376, 1020,1040, playbooks define actions in abstractions such that connectors, i.e. mapping can be defined that translate command/action into different IT environments/standards. )
[0376] Moreover, the query system manager 502 can handle resource management, creation, assignment, or destruction of search heads 504 and/or search nodes 506, high availability, load balancing, application upgrades/rollbacks, logging and monitoring, storage, networking, service discovery, and performance and scalability, and otherwise handle containerization management of the containers of the query system 214. In certain embodiments, the query system manager 502 can be implemented using Kubernetes or Swarm. For example, in certain embodiments, the query system manager 502 may be part of a sidecar or sidecar container that allows communication between various search nodes 506, various search heads 504, and/or combinations thereof.
[1010] In some embodiments, to execute actions against IT assets in tenant networks and elsewhere, an IT and security operations application 1702 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 1702 (via an on-premises action broker 1720) uses one or more connectors 1722 to translate the commands into the one or more processes or languages necessary to implement the action at one or more particular IT assets 1714. For example, a user might provide input requesting the IT and security operations application 1702 to remove an identified malicious process from multiple computing systems in the tenant network 1710A, 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 1702 can send an action request to an on-premises broker 1720, which then uses one or more connectors 1722 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 1724).
[1020] In some embodiments, an IT and security operations application 1702 defines many different types of “actions,” which are high-level, vendor- and product-agnostic primitives that can be used throughout the IT and security operations application 1702. Actions generally represent simple and user-friendly verbs that are used to execute actions in playbooks and manually through other user interfaces of the IT and security operations application 1702, where such actions are performed against one or more assets in an IT environment. In many cases, a same action defined by the IT and security operations application 1702 can be carried out on assets associated with different vendors or configurations via action translation processes performed by various “connectors” of the platform, as described in more detail elsewhere herein. Examples of actions that may be defined by an IT and security operations application 1702 include a “get process dump” action, a “block IP address” action, a “suspend VM” action, a “terminate process” action, and so forth.
[1040] 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 1736 and in association with one or more user accounts) and run by the IT and security operations application 1702 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 1702 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 1702 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 1702 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 1702.
and mappings between controls different standards to allow for automatic and continuous compliance with multiple standards without need for human intervention(playbooks execute actions and execute connectors to translate actions in various IT environments allowing for automatic actions to be performed, such as automated remediation of security issues, ¶s1010.1011).
[1010] In some embodiments, to execute actions against IT assets in tenant networks and elsewhere, an IT and security operations application 1702 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 1702 (via an on-premises action broker 1720) uses one or more connectors 1722 to translate the commands into the one or more processes or languages necessary to implement the action at one or more particular IT assets 1714. For example, a user might provide input requesting the IT and security operations application 1702 to remove an identified malicious process from multiple computing systems in the tenant network 1710A, 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 1702 can send an action request to an on-premises broker 1720, which then uses one or more connectors 1722 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 1724).
[1011] In some embodiments, an IT and security operations application 1702 includes a playbooks manager 1726 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 1702. At a high level, a playbook is a customizable computer program that can be executed by an IT and security operations application 1702 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 1702 and use of digital playbooks are provided elsewhere herein.
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 Christofl’s system for natural language based creation and execution of playbooks with playbooks that can prompt users for setting and execute steps to revert or reverse configuration changes as taught by Christofl. The reason for this modification would be to resolve network anomalies caused by prior misconfiguration.
The combination of Fighel/Christofl does not specifically teach the application configured for generating the reverse playbook and thus does not teach wherein the application is configured for ascertaining an application configuration and configuring the reverse playbook accordingly to restore an application according to the application configuration after implementation of the playbook, the reverse playbook storing the application configuration for reinstating all or part of an original configuration, the application further comprising a further remediation playbook and mappings between controls of the remediation playbook and the further remediation playbook so that, when an action of the remediation playbook is implemented, an associated action of the further remediation playbook is identified using the mapping and subsequently implemented. Zavesky in the same field of endeavor as the invention teaches a system for automated network orchestration. Zavesky teaches wherein the application is configured for ascertaining an application configuration and configuring the reverse playbook accordingly to restore an application according to the application configuration after implementation of the playbook, the reverse playbook storing the application configuration for reinstating all or part of an original configuration, the application further comprising a further remediation playbook ( the system after creation of a playbook allow configuring of new plays in addition to a playbook, such additional plays include maintaining prior configurations/states of a VNF(i.e. network application service) within the playbook to perform rollbacks if modification made by playbook results in undesired results, ¶64) .
[0062] In some embodiments (but not necessarily all embodiments), at 262 a playbook is searched to identify known VNF modifications which may address the performance issue. For example, various performance issues or classes of performance issues (e.g., related to a specific KPI) can include machine-calculated or administrator defined solutions (e.g., from previous fixes, calculated based on scenarios, provided by vendors or customers) to utilize in replicated environments for testing under current service loading. Plays (e.g., modified VNFs or VNF configurations) from the playbook can be identified (e.g., instantiate all plays, select particular plays based on context) and applied to replicated VNFs as described herein. If shattering at 258 was completed, plays can likewise be shattered into play constituents for matching to virtual constituents of the shattered functions, thereby allowing solutions to mix-and-match possible modifications for a candidate modification applied to a given replica VNF. The playbook can be supplemented with new plays, such as where a new solution is calculated through mathematics or network analysis; where an operator provides a new solution; or where shattering creates a combination defining a new play not yet stored in the playbook. The playbook can also store a current state before modifications are committed to a production VNF or production environment to provide instantaneous or on-demand rollback capability if a modification does not yield intended results or changed circumstances justify removal of the modified state (e.g., prior to making further modifications, modifications not needed based on current loading).
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/Cristofl with playbook generation system that captures of the state of a configuration before a playbook modification within the playbook. The reason for this modification would be to allow for easy creation of rollback playbooks that can rollback service misconfigurations.
Regarding claim 2, Fighel teaches wherein the response level is automatic wherein the application automatically implements the action(automatic remediation can be performed in response to a level such as high cpu , ¶47).
[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.
Regarding claim 3, Fighel teaches wherein the response level is alert wherein the application generates an alert.
[0045] The goal of collecting and analyzing client communications is to determine if a problem or issue has arisen within a client's production environment. To that end, the communications analysis unit 218 can search client communications for certain key words that are associated with a particular issue or problem. If one or more key words that relate to a specific type of problem or issue is found in the client communications, the communications analysis unit 218 is able to send that information to the evaluation unit 500 for deep correlation with other signals received by the system. It may send a notification about the potential issue or problem to a system administrator, or possibly to other elements of the production environment assistant so that a more detailed check could be performed, or so that remedial action can be taken.
Regarding claim 4, Fighel teaches wherein generating the alert comprises interfacing an alerting platform via an API.
[0097] FIG. 11 illustrates steps of a method which is performed to obtain data from a client's production environment and to store that data into one or more data queues. The method 1100 begins and proceeds to step S1102 where data reported by APIs installed on a client's production environment is received by the passive collection unit 202 of the data collection unit 200. The received data can include data points and events. Those data points and events can relate to individual elements of computer equipment, networking equipment, and also software applications which are running on the client's production environment. As noted above, the received data could also include business-related data such as financial data or traffic data.
Regarding claim 5, Fighel does not teach wherein generating the alert comprises generating a series of alerts using an escalated contact list. Christofl in the same field of endeavor as the invention teaches a system for creation and execution of playbooks. Christofl teaches wherein generating the alert comprises generating a series of alerts using an escalated contact list(workflows implemented using playbooks can include escalation and alerts to sets of user with certain roles, ¶1046).
[1046] In some embodiments, the workbook template configuration interface 2000 includes a set of workbook information options 2002, including fields for entry of a workbook name and workbook description, an interface element that can be used to set the current workbook as a default workbook, and an interface element that can be used to designate whether users are required to create a note upon completion of workbook tasks. In some embodiments, the workbook template configuration interface 2000 further includes a phases definition panel 2004. The example shown in FIG. 20 illustrates the definition of a single phase; however, a workbook template generally can include any number of separate phases as desired by the user. As illustrated in FIG. 20, the phases definition panel 2004 include a field 2008 for entry of a phase name and an add task button 2010 used to add tasks to the phase. In FIG. 20, an example “Data Breach” workbook template includes a phase named “Escalate to accountable system owners.” The phase named “Escalate to accountable system owners” includes three tasks: a task 2006A named “Identify accountable system owners,” a task 2006B named “Notify accountable system owners,” and a task 2006C named “Setup collaboration channels.” Each of the tasks 2006A-2006C includes fields for the task name and the owner (e.g., a user who can be designated as being responsible for the associated task), and a selector button to designate that a notification should be sent upon completion of the task. In response to selecting a specific task within a phase, the workbook editor displays additional options for the corresponding task. As illustrated in FIG. 20, selected task 2006A includes a field for entry of text for a description of the task, in addition to options to add or remove executable actions and playbooks. The set of executable actions associated with task 2006A includes the track_active_directory_admin_users playbook, as well as individual actions, including run query, list oncalls, get oncall, get system attributes, get user attributes, get users, and ask 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 with playbooks that can issue escalation of notification such escalation to a set of users. The reason for this modification would be to implement known practices and procedures in security IT support(SIEM) problem ticket resolution.
Regarding claim 6, Chrisofl further teaches wherein the response level as approval wherein the application receives an approval response prior implementing the action(workflow implementing playbooks can include user approvals to perform remediations, ¶s1013,1057).
[1013] In some embodiments, an incident management service 1728 is responsible for obtaining incidents, either directly from various data sources in tenant networks or directly based on data ingested by the data intake and query system 108 via the gateway 215. In some embodiments, the mission control service 1708 provides user interfaces to users of the application, among other processes described herein. Using these user interfaces, users of the IT and security operations application 1702 can perform various application-related operations, view displays of incident-related information, and can configure administrative settings, license management, content management settings, and so forth. In some embodiments, an artifact information service 1732 manages artifacts associated with incidents received by the application, where incident artifacts can include information such as IP addresses, user names, file hashes, and so forth. In some embodiments, a threat intel service 1730 obtains data from external or internal sources to enable other services to perform various incident data enrichment operations. As one non-limiting example, if an incident is associated with a file hash, a threat intel service 1730 can be used to correlate the file hash with external threat feeds to determine whether the file hash has been identified as malicious. In some embodiments, a file storage service 1734 enables other services to store incident-related files, such as email attachments, files, and so forth. In some embodiments, an OAR service 1716 performs a wide range of OAR capabilities such as action execution (via an action manager 1718), playbook execution (via a playbooks manager 1726), scheduling work to be performed (via a scheduler 1740), user approvals and so forth as workflows (via a workflows manager 1742), and other functionality and described herein.
[1057] As indicated above, an IT and security operations application, such as the SPLUNK PHANTOM™ application, enable users, including security analysts and system administrators, to manage IT environments. Traditionally, these users interact with IT and security operations applications at a workstation or desktop computer via a web browser, command-line interface, or other desktop application. However, users cannot always be available at their workstation or computer, which can result in inefficiencies in how IT and security operations applications execute workflows and/or playbooks that require a user response or interaction. For example, if an incident remediation workflow requires input from an administrator before the workflow can progress, and the administrator is currently unable to access a workstation to know that his or her input is needed and to provide the requested input, the execution can be stalled until he or she becomes available, a substitute user is located, or a default action is performed. Because modern IT environments can involve a large number of devices and software components and quickly moving threats, any such delays in responding to an incident or event can have significant repercussions.
Regarding claim 15, Christofl teaches wherein the interface retrieves and displays remediation documentation associated with the alert(metric associate with the event as well as the steps of the playbook are displayed on dashboard, ¶s1014).
[1014] FIG. 22 illustrates an example of a “mission control” interface of an IT and security operations application (e.g., IT and security operations application 1702) displaying information related to an occurrence of an incident in an IT environment according to some embodiments. In some embodiments, the mission control interface 2200 displays one or more executable actions for responding to the incident as part of a workbook that is generated based on the identified incident. The mission control interface 2220 shown in FIG. 22 includes, for example, an event information panel 2202, a tasks panel 2204, a set of suggested executable actions 2206 associated with a particular task, and a head-up display (HUD) panel 2208.
Regarding claim 19, Christofl teaches wherein the reverse playbook is configured to partially restore the application configuration(rollback application to earlier configuration/version, ¶285).
[0285] The indexing system manager 402 can handle resource management, creation/destruction of indexing nodes 404, high availability, load balancing, application upgrades/rollbacks, logging and monitoring, storage, networking, service discovery, and performance and scalability, and otherwise handle containerization management of the containers of the indexing system 212. In certain embodiments, the indexing system manager 402 can be implemented using Kubernetes or Swarm.
Regarding claim 23, Fighel teaches wherein the application is configured for referencing other playbooks and natural language instructions associated therewith to identify configuration setting structures when converting the natural language remediation instructions into the playbook actions(extract nouns and values i.e. 50% CPU, ¶95).
[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).
Regarding claim 24, Fighel teaches wherein the playbook periodically implements the at least one action.
[0039] FIG. 2 illustrates various elements of a data collection unit 200 which can be part of a production environment assistant 100. The data collection unit 200 includes a passive collection unit 202, which receives data reported from the various systems of a client's production environment. The data reported to the passive collection unit 202 may be reported via various APIs that are installed in the client's production environment. Alternatively, or in addition, a dedicated agent could be installed on client servers or networking equipment. Such an agent could utilize the one or more separate API collection methods. The APIs are configured to periodically or continuously report various items of information regarding operations on the client's production environment.
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Paradakar 2022/0075936.
Regarding claim 7, Fighel/Cristopfl/Zavesky do not teach wherein the application monitors the implementation of the action to determine if the action fails. Paradakar in the same field of endeavor as the invention teaches a system network issue analysis and resolution. Paradakar teaches wherein the application monitors the implementation of the action to determine if the action fails(monitor if action resolved issue and if not execute another action, ¶43).
[0043] FIGS. 3A and 3B show a first example of combining two triaging trees in accordance with exemplary embodiments. FIG. 3A shows triaging trees 302, 304 that correspond to the same problem, denoted pr.sub.1. In this example, the triaging tree 302 includes one symptom, sy . The triaging tree 302 depicts that a first action, ac.sub.1, was taken, which results in a first response/result, R.sub.1. In this example, R.sub.1 fails to resolve the issue as indicated by the node labeled with an F. Triaging tree 302 also depicts that a second action, ac.sub.2 is taken, which results in a second response/result, R.sub.2. The second action results in a corresponding resolution as indicated by the node labeled Re.sub.2. The node labeled with R represents a resolution action which resolved the problem pr.sub.1.
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/Cristofl/Zavesky with playbooks that implement triage decision tree. The reason for this modification would be to provide remediation that can adapt and implement multiple remediation actions mimicking the action of a network administrator in troubleshooting network issues.
Regarding claim 8, Paradakar teaches wherein the application generates an alert if the action fails(a response/result that issue was not resolved is an alert of failure, ¶43).
[0043] FIGS. 3A and 3B show a first example of combining two triaging trees in accordance with exemplary embodiments. FIG. 3A shows triaging trees 302, 304 that correspond to the same problem, denoted pr.sub.1. In this example, the triaging tree 302 includes one symptom, sy . The triaging tree 302 depicts that a first action, ac.sub.1, was taken, which results in a first response/result, R.sub.1. In this example, R.sub.1 fails to resolve the issue as indicated by the node labeled with an F. Triaging tree 302 also depicts that a second action, ac.sub.2 is taken, which results in a second response/result, R.sub.2. The second action results in a corresponding resolution as indicated by the node labeled Re.sub.2. The node labeled with R represents a resolution action which resolved the problem pr.sub.1.
Regarding claim 9, Paradakar teaches wherein the application implements a further action if the action fails(monitor if action resolved issue and if not execute another action, ¶43).
[0043] FIGS. 3A and 3B show a first example of combining two triaging trees in accordance with exemplary embodiments. FIG. 3A shows triaging trees 302, 304 that correspond to the same problem, denoted pr.sub.1. In this example, the triaging tree 302 includes one symptom, sy . The triaging tree 302 depicts that a first action, ac.sub.1, was taken, which results in a first response/result, R.sub.1. In this example, R.sub.1 fails to resolve the issue as indicated by the node labeled with an F. Triaging tree 302 also depicts that a second action, ac.sub.2 is taken, which results in a second response/result, R.sub.2. The second action results in a corresponding resolution as indicated by the node labeled Re.sub.2. The node labeled with R represents a resolution action which resolved the problem pr.sub.1.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Goyal US US 2016/0381075.
Regarding claim 10, the combination of Fighel/Cristofl/Zavesky do not teach wherein the standard is CIS. Goyal in the same field of endeavor as the invention teaches a system for manage and orchestration of cloud based services. Goyal teaches wherein the standard is CIS.
[0076] In the illustrated example of FIG. 10, the example host requirement identifier 1004 identifies any assessment policy requirements established by the example host environment 150. For example, the example host environment 150 may require that any container image (e.g., the example container image 110) to be assembled for execution as a container in the host environment 150 must be compliant with a specific assessment policy and/or a specific type of assessment policy. For example, the host environment 150 may require that any container image to be assembled for execution as a container in the host environment 150 must be compliant with the Payment Card Industry Data Security Standard (PCI-DSS). In some examples, the host environment 150 may identify more than one assessment policy and/or type of assessment policy that the example container image 110 must comply with in order for the host environment 150 to execute a corresponding container. For example, the host environment 150 may require that any container image to be assembled for execution as a container in the host environment 150 must be compliant with the Payment Card Industry Data Security Standard (PCI-DSS) and must also be compliant with the Center for Internet Security (CIS) standard. In the illustrated example of FIG. 10, the example host requirement identifier 1004 obtains and/or receives any assessment policy requirements from the example host environment 150 that are applicable to determining whether the example container image 110 is compliant for use in connection with the example host environment 150.
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/Cristofl/Zavesky playbooks with playbooks that execute actions to implement best practices according to CIS as taught by Goyal. The reason for this modification would be to implement a secure and reliable network deployments.
Regarding claim 11, the combination of Fighel/Cristofl/Zavesky do not teach wherein the standard is PCI- DSS. Goyal in the same field of endeavor as the invention teaches a system for manage and orchestration of cloud based services. Goyal teaches wherein the standard is PCI- DSS.
[0076] In the illustrated example of FIG. 10, the example host requirement identifier 1004 identifies any assessment policy requirements established by the example host environment 150. For example, the example host environment 150 may require that any container image (e.g., the example container image 110) to be assembled for execution as a container in the host environment 150 must be compliant with a specific assessment policy and/or a specific type of assessment policy. For example, the host environment 150 may require that any container image to be assembled for execution as a container in the host environment 150 must be compliant with the Payment Card Industry Data Security Standard (PCI-DSS). In some examples, the host environment 150 may identify more than one assessment policy and/or type of assessment policy that the example container image 110 must comply with in order for the host environment 150 to execute a corresponding container. For example, the host environment 150 may require that any container image to be assembled for execution as a container in the host environment 150 must be compliant with the Payment Card Industry Data Security Standard (PCI-DSS) and must also be compliant with the Center for Internet Security (CIS) standard. In the illustrated example of FIG. 10, the example host requirement identifier 1004 obtains and/or receives any assessment policy requirements from the example host environment 150 that are applicable to determining whether the example container image 110 is compliant for use in connection with the example host environment 150.
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/Cristofl/Zavesky playbooks with playbooks that execute actions to implement best practices according to CIS as taught by Goyal. The reason for this modification would be to implement a secure and reliable network deployments.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Saxena US 2019/0327271.
Regarding claim 12, Fighel/Cristofl/Zavesky do not teach wherein the standard is AWSTM Foundational Security StandardTM. Saxena in the same field of endeavor as the invention teaches a system for orchestration of containerized comping services. Saxena teaches wherein the standard is AWSTM Foundational Security StandardTM.
[0138] Other examples of best practices policies are compliance policy checklists such as those outlined in “CIS Amazon Web Services Foundations,” v 1.20, updated May 23, 2018, which is hereby incorporated by reference in its entirety. Similar benchmarks exist for other cloud platforms such as Microsoft Azure and Google Cloud Platforms. Cybersecurity best practices are also specified by the Center for Internet Security, which publishes CIS benchmarks for various operating system, servers, cloud providers, devices, etc.
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/Cristofl/Zavesky playbooks with playbooks that execute actions to implement best practices according to AWS foundation best practices as taught by Saxena. The reason for this modification would be to implement a secure and reliable network deployments.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Gupta US 2021/0194773 A1.
Regarding claim 13, Fighel/Cristofl/Zavesky does not teach wherein the application generates alerts until each alert is remediated. Gupta ins the same field of endeavor teaches a system for remediation of network environments. Gupta teaches wherein the application generates alerts until each alert is remediated(measure, alert, remediation loop performed until failure is resolved, ¶18, claim15).
[0018] The systems and methods of the present disclosure can facilitate the process of automated remediation (a measure-alert-act loop). According to some embodiments, the method includes receiving one or more definition of actions associated with each remediation of a plurality of issues for at least one device in a network fleet; and automatically converting each definition of the one or more definitions of the actions associated with each remediation into automated flows in a pipeline language for pipelined execution across the network. The system can handle converting the definitions of action to one or more fleet-wide parallel, distributed, fault-tolerant, event-driven, scalable, secure, and automated flows. (Further details and examples concerning fault-tolerant pipeline command sequence execution can be found in U.S. patent application Ser. No. 16/684,001, filed Nov. 14, 2019 entitled “Fault-tolerant execution of command pipeline steps”, which is incorporated by reference herein in its entirety.) Once converted, the flows can be run across thousands or millions of managed resources. This approach can be used to monitor customer systems against desired behavior and take actions in response to detected anomalies. This approach can also allow handling various failures, missing network messages, out of order delivery, changing definitions, additions/removals of parts of the fleet, and so forth. In some embodiments, this handling is done proactively by preventing issues based on a rate of metric change in normal behavior before these issues arise.
15. The method of claim 1, wherein at least some of the received feedback indicates a failure, the failure being automatically remediated by repeating the measure-alert-act loop until the failure has been remediated.
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/Cristofl/Zavesky playbooks with playbooks that issue alerts until remediation is successful as taught by Gupta. The reason for this modification would be to encourage resolution of network issues by constantly reminding a administrator that a issue is unresolved.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Burke US 10,261,849.
Regarding claim 14. Fighel/Cristofl/Zavesky does not teach wherein at least one of the playbook and the at least one remediation is categorized as intrusive or nonintrusive depending on its effect on performance or availability of an application. Burke being the same field of endeavor as the invention teaches a system network service analysis and remediation. Burke teaches wherein at least one of the playbook and the at least one remediation is categorized as intrusive or nonintrusive depending on its effect on performance or availability of an application.
[(46) In some embodiments, intrusivity is a measure of the impact of a remediation on total system availability. The least intrusive measure may be a method (e.g., remediation instructions) that is fastest to return a troubled service to availability. In some embodiments, the least intrusive may be a method that involves a piecemeal remediation, such restarting services one at a time in a cluster and validating the restarted service works (e.g., is operatively available for use) before restarting the next service in the cluster. In some aspects, the remediation server 100 may improve its error conditioning through back propagation of previously determined and applied remediations, in conjunction with any predefined error conditioning. Col 6 Lines 40- 52]
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/Crstofl/Zavesky with determining the intrusiveness of a method of remediation as taught by Burke. The reason for this modification would be to mitigate the effects of remediation actions on network users.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 above, and further in view of Hollis US 2018/0270109 .
Regarding claim 17, Fighel/Cristofl/Zavesky do not teach wherein the playbook comprises an action to close a port and the reverse playbook comprises an action to open the port. Hollis in the same field of endeavor as the invention teaches a system for security vulnerability remediation. Hollis teaches wherein the playbook comprises an action to close a port and the reverse playbook comprises an action to open the port.
[0055] Based on the scanning results, the configuration setting analyzer 102 may determine whether ports are misconfigured. A misconfigured port may include a port that is supposed to be one of open, closed or blocked, but is not. For example, a misconfigured port may be a port that is open, contrary to a security policy. For example, if a port is configured for Character Generator Protocol (CHARGEN), Network Time Protocol (NTP), Domain Name System (DNS), or Internet Control Message Protocol (ICMP), and is an open port, it may be considered security vulnerability for its susceptibility to reflection network attacks. Also, SSH and Telnet ports that are open may be considered a network configuration setting error. These types of configured ports may be considered network configuration setting errors, and the ports may be closed to reduce security vulnerabilities.
[0057] At 404, the network interfaces determined to be incorrectly responding to network traffic may be remediated, such as by reconfiguring an open port to be a closed port, or by reconfiguring a closed port to be an open port, or by reconfiguring an ACL, or by correcting an ACL that may not be operational due to a software bug through a software update and/or a reboot. The remedial actions may be executed by the automated remediator 103.
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/Cristofl/Zavesky with playbook action that include closing a port and a playbook reverse action to open a port as taught by Hollis. The reason for this modification would be to mitigate the effects of network attacks by closing ports that are vulnerable network points and opening port at the cessation of network attack.
Claims 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Fighel/Cristofl/Zavesky as applied to claim 1 and 24 above, and further in view of Deaguero 2020/0067952.
Regarding 25, Fighel/Cristofl/Zavesky do not teach wherein the at least one action at least one of makes and tests a backup. Deaguero in the same field of endeavor as the invention teaches a system for responding to network incidents. Deaguero teaches wherein the at least one action at least one of makes and tests a backup(playbooks used for network backups and confirmation of network backups, ¶s 240,241).
[0240] At block 1812, in one or more of the various embodiments, the one or more NMCs may be arranged to compare the investigation activity to the one or more investigation playbooks. In one or more of the various embodiments, NMCs may be arranged to evaluate if the investigator followed the guidance of the investigation profiles or the investigation playbook. For example, if the investigation profile prescribed four actions in a particular order, the NMCs may track if the investigator performed the four actions in the prescribed order. Likewise, if the investigator was using an investigation playbook, the NMCs may track if the investigator performed the actions included in the playbook.
[0241] In some embodiments, the actual investigation activity performed by the investigator may be compared to the activity the investigator may report having performed. For example, if the investigator reports that a database backup was performed before debugging the database as part of the investigation of the anomaly, the investigation activity monitored by the NMCs may confirm that the database backup was actually performed.
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/Cristofl/Zavesky with playbook action that includes creating and confirm creation of backups as taught by Deaguero. The reason for this modification to provide fault recovery/restoration as commonly practiced computing deployments.
Regarding 26, Fighel/Cristofl do not teach, wherein the at least one action automatically restores a backup. Deaguero in the same field of endeavor as the invention teaches a system for responding to network incidents. Deaguero teaches one action automatically restores a backup.
[0243] In some embodiments, the report information may indicate that the investigator is not performing some or all of the actions recommended or prescribed by investigation playbooks or investigation profiles. Likewise, the reports may indicate that an investigation playbook is incorrect or inadequate for the anomaly that was being investigated. Accordingly, in some embodiments, organizations may determine if their current investigation playbooks are sufficient or whether they need to be updating. For example, in some embodiments, a low scoring investigation may represent a poorly designed investigation playbook rather than a poorly performing investigator.
[0255] Also, for example, in some embodiments, performance impacting actions may include actions that degrade host or network performance, such as, bulk copying, database dumps, backups, restoring from backups, brute force text searches, ad-hoc queries into production databases, queries or searches of unstructured data stores, accessing remote entities or systems having limited bandwidth or computing power, or the like.
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/Cristofl with playbook action that includes restoring of backups as taught by Deaguero. The reason for this modification to provide fault recovery/restoration as commonly practiced computing deployments.
Applicant Remarks
The applicant’s amendments have overcome prior rejection under 35 USC 112 1st ¶ over new claimed matter.
The applicant argues in page 8 and 9 of the remarks that the combination of Fighel in view of Cristofl and Zavesky are improper because the applicant alleges the problems of the cited references do not overlap over the claim invention. It appears that the applicant is arguing that the prior art is non-analogous because they do not solve the same problem. The examiner contends that analogousness of the prior art is established based on the prior are references being the same field of endeavor as the invention. In this case all three references are directed toward use of playbooks to resolve network events/incidents and the invention is similarly directed to the field of resolution of security events using playbooks. Thus the prior art references are analogous and the rejection is proper.
The applicant further argues on page 9 of the remarks that Zavesky fails to teaches:
automated remediation and configuration restoration responsive to detected incidents;
reverse playbook architecture enabling restoration of pre-incident configurations;
cross-standard compliance orchestration enabling mapping across multiple frameworks
Such limitations are not recited in the claim thus such are not required to be taught by the references. Such argument are moot in light of scope of the claims.
The applicant further argues on pages 9 and 10 of the remarks that there is not motivation to combine indicated in any of the references that one should be incorporated into the other references. The examiner contends that the motivation to combine is clearly indicated in the rejection with the knowledge of one of ordinary skill in the art. Motivation to combine need not be explicit in the references and may rely on the knowledge of one of ordinary skill in the art.
The applicant argues on pages 10 of the remarks that the combination of Fighel. Cristofl and Zavesky would not be predictable or straightforward yielding an un workable architecture with conflicting operational scopes. Such arguments are mere conclusionary remarks. The examiner contends that the modification to the system of Fighel to add a interface that allows entry of parameters is within the skill of one od ordinary skill. Adding the functionality of allowing parameters to be entered does not render Fighel inoperable but rather makes an improvement the system of Fighel. Similarily, Zavesky teaches of a method of capturing states for on-demand rollback capability and provides a specific method of generating a reverse playbook(rollback of a configuration to prior state) as taught by Cristopl. Modifying Fighel/Cristopfl with a particular way the generate a reverse playbook is within the skill of one or ordinary skill. Such an additional would lead to the predictable result of a reverse playbook generated by capturing the state of a system before a modification.
The applicant further argues on page 10 of the remarks that no motivation to combine is provided by the references. The examiner contends that the motivation to combine is clearly indicated in the rejection with the knowledge of one of ordinary skill in the art. Motivation to combine need not be explicit in the references and may rely on the knowledge of one of ordinary skill in the art.
The applicant further argues on page 10 that impermissible hindsight present in the rejection. The examiner contends that the combination of Fighel in view of Cristofl and Zavesky as applied to claim 1 relies on knowledge of one of ordinary skill in the art at the time of the invention. No improper hindsight is relied upon by the examiner.
Conclusion
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