Prior art

Analysis of Prior Art for U.S. Patent 9,503,421

As part of the examination process before the U.S. Patent and Trademark Office (USPTO), several prior art references were cited against the application that matured into patent 9,503,421. These references represent the technological landscape at the time of the invention and were considered by the patent examiner to determine the novelty and non-obviousness of the claimed subject matter.

The core inventive concept of patent 9,503,421, particularly in its independent claims 1 and 11, resides in a Security Information and Event Management (SIEM) system that uses a "work flow template" containing "abstract tasks." A key component, the "device engine," translates these abstract tasks into specific, executable tasks for particular security devices. This allows for a flexible, vendor-agnostic approach to automating complex security procedures.

For a prior art reference to anticipate a claim under 35 U.S.C. § 102, it must disclose, either expressly or inherently, every element of that claim arranged as in the claim. The following is an analysis of the most relevant patent references cited by the USPTO examiner and their potential impact on the claims of the '421 patent.

Cited Prior Art and Potential Anticipation

1. U.S. Patent No. 8,613,083 (to D'Souza et al.)

• Full Citation: U.S. Patent No. 8,613,083 B1
• Filing Date: June 14, 2011
• Publication Date: December 17, 2013
• Brief Description: This patent describes a system for automated security assessment. It discloses generating a "testing workflow" that includes a series of security tests to be performed on network assets. The system can select appropriate testing modules based on the target asset's characteristics and then execute the workflow.
• Anticipation Analysis: While the '083 patent teaches the concept of an automated security "workflow" comprising multiple tasks, it does not appear to explicitly disclose the key elements of claim 1 of the '421 patent. Specifically, it does not describe a "work flow template" with "abstract tasks" that are then "translated" by a distinct "device engine" into device-specific commands. The workflows in D'Souza seem to be constructed from pre-defined, specific testing modules rather than being derived from a higher-level abstraction layer. Therefore, the '083 patent likely does not anticipate claim 1 or claim 11.

2. U.S. Patent Application Publication No. 2010/0192225 (to Poornachandran et al.)

• Full Citation: U.S. Patent Application Publication No. 2010/0192225 A1
• Filing Date: January 28, 2009
• Publication Date: July 29, 2010
• Brief Description: This publication details a security management system that automates responses to security events. It describes creating "workflows" or "playbooks" that define a sequence of actions to be taken. These workflows can be triggered by events and can interact with various security products from different vendors through adapters or connectors.
• Anticipation Analysis: The Poornachandran publication comes closer to the subject matter of the '421 patent. It discloses automated workflows interacting with multi-vendor devices via adapters. However, the description focuses on defining sequences of specific actions in its "playbooks." It does not explicitly teach the two-stage process of defining a generalized "work flow template" with "abstract tasks" and then using a "device engine" to perform a translation into specific tasks for designated devices. The abstraction and translation concept, which is central to claim 1, appears to be absent. Thus, this reference likely does not anticipate the claims.

3. U.S. Patent No. 8,539,584 (to Gribble et al.)

• Full Citation: U.S. Patent No. 8,539,584 B1
• Filing Date: September 28, 2009
• Publication Date: September 17, 2013
• Brief Description: This patent discloses a system for generating and managing security policies that can be enforced on a network. It describes using "templates" to create policies. These templates can contain variables that are later populated with specific values to create an enforceable policy instance. The system can then deploy these policies to various network devices.
• Anticipation Analysis: Gribble discloses the use of "templates" with variables to create specific policy instances. This bears some resemblance to the '421 patent's concept. However, Gribble's focus is on policy generation, not on the execution of a sequence of active security tasks (like scanning, testing, or blocking) in a workflow. Furthermore, it does not describe a "device engine" translating "abstract tasks" into commands. The template in Gribble is more for configuration management rather than for orchestrating a dynamic, multi-step security process as claimed in the '421 patent. Therefore, it is unlikely to anticipate claim 1 or claim 11.

4. U.S. Patent Application Publication No. 2013/0247182 (to Narayanan et al.)

• Full Citation: U.S. Patent Application Publication No. 2013/0247182 A1
• Filing Date: March 15, 2012
• Publication Date: September 19, 2013
• Brief Description: Narayanan describes a security orchestration system that uses "playbooks" to automate incident response. These playbooks define a series of steps and can integrate with third-party security tools. The system is designed to coordinate actions across different products to respond to a threat.
• Anticipation Analysis: Similar to Poornachandran ('225), this reference teaches automated, multi-step, multi-vendor security workflows ("playbooks"). It is highly relevant to the general field. However, it does not appear to disclose the specific inventive concept of claim 1: the creation of a generic "work flow template" with "abstract tasks" and the subsequent "translation" by a "device engine." The playbooks described in Narayanan appear to be defined with specific actions, even if they are executed on different vendor products. The critical abstraction layer claimed in the '421 patent is not explicitly taught. Consequently, this reference is unlikely to anticipate the claims.