Obviousness

Obviousness Analysis of U.S. Patent No. 9,503,421 under 35 U.S.C. § 103

This analysis evaluates whether the invention claimed in U.S. Patent No. 9,503,421 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, March 17, 2014. An invention is considered obvious if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious to a PHOSITA. This analysis relies on combining teachings from multiple prior art references, for which there must have been a reasoned motivation to combine.

The central inventive concept of US 9,503,421, as defined in independent claims 1 and 11, is a specific architecture for automating security workflows. This architecture is characterized by three key elements working in concert:

1. A "work flow template" that defines a general sequence of security functions.
2. The use of "abstract tasks" within the template, which describe what to do (e.g., "scan host for vulnerabilities") rather than the device-specific command for how to do it.
3. A "device engine" that acts as a translation layer, converting these abstract tasks into specific, executable commands for designated security devices, which may come from different manufacturers.

The primary argument for obviousness is that combining a known automated security workflow system with well-established principles of software abstraction to solve the known problem of multi-vendor device management would have rendered the claimed invention obvious.

Combination 1: IBM (2011/0173685 A1) in view of General Principles of Software Abstraction

• Primary Reference: U.S. Pub. No. 2011/0173685 A1 to IBM ("IBM '685")

  • Teachings: IBM '685 explicitly discloses "Security event and threat management with automated workflow." It provides the foundational teaching of a system that, in response to a security event, automatically executes a predefined workflow of tasks to manage the threat. This reference establishes the core concept of chaining security tasks together for an automated response, a central pillar of the '421 patent. The analysis assumes, as is common in such systems, that IBM '685 may not explicitly detail a method for handling devices from multiple different manufacturers with different command sets within a single, abstract workflow definition.

• The Missing Element: The specific architecture of a "work flow template" with "abstract tasks" that are then translated by a "device engine." IBM '685 teaches the workflow, but not necessarily this specific implementation of a flexible, multi-vendor abstraction layer.

• Motivation to Combine: The background of the '421 patent itself identifies the problem to be solved: "tasks conducted by different security devices may require different parameters... Even the same task may require different parameters when it is conducted by security devices from different manufacturers." (Col. 1, ll. 40-44). A PHOSITA in 2014, tasked with implementing the automated workflow system taught by IBM '685 in a real-world enterprise network, would inevitably face this exact problem of heterogeneity. Enterprise networks commonly use security appliances (firewalls, scanners, IPS) from a variety of vendors.

  To solve this known problem, the PHOSITA would have been motivated to turn to one of the most fundamental principles of software engineering: abstraction. Creating an abstraction layer (an Application Programming Interface or API) with a corresponding set of "drivers" or "adapters" is the standard, textbook solution for making a single software system control multiple, different hardware or software subsystems.

  • The "work flow template" is a logical name for a reusable, abstracted workflow definition.
  • The "abstract tasks" are the functions defined in that abstract API (e.g., scan(), block_ip()).
  • The "device engine" is the implementation of the adapter/driver pattern, containing the logic to translate the generic scan() call into the specific command-line instruction or API call required by a Fortinet scanner, a Palo Alto Networks firewall, or a Cisco IPS.

  Therefore, the claimed invention would have been an obvious implementation of the system taught in IBM '685. A PHOSITA would have been motivated to apply these standard software design patterns to make IBM's workflow concept practical and scalable in a typical, multi-vendor environment, leading directly to the claimed architecture.

Combination 2: Trend Micro (2013/0091557 A1) or Cisco (2008/0134331 A1) in view of the same General Principles

• Primary Reference: U.S. Pub. No. 2013/0091557 A1 to Trend Micro ("Trend Micro '557") or U.S. Pub. No. 2008/0134331 A1 to Cisco ("Cisco '331")

  • Teachings: Both of these references teach the concept of security "orchestration." Trend Micro '557 discloses a "threat management system having an orchestration engine," and Cisco '331 describes a "security orchestration system" that coordinates actions using "workflows." The term "orchestration" itself implies the coordination of disparate elements. These references provide a strong foundation by teaching a centralized engine responsible for managing workflows across multiple security components.

• The Missing Element & Motivation to Combine: The argument follows the same logic as with the IBM '685 reference. An "orchestration engine," by its very definition, must be able to "conduct" or communicate with the different "instruments" in its "orchestra"—in this case, security devices from various vendors. A PHOSITA building the "orchestration engine" taught by Trend Micro or Cisco would immediately confront the need for a common language or a translation mechanism. Applying the standard abstraction/adapter design pattern is not an inventive leap, but a predictable design choice to achieve the stated goal of orchestration in a heterogeneous network. The result of this predictable design choice is the architecture claimed in US 9,503,421.

Conclusion on Obviousness

While the prior art cited during prosecution does not appear to anticipate the claims of US 9,503,421 in a single reference, the claims are arguably obvious under 35 U.S.C. § 103. The foundational concept of automated security workflows was well-established by references such as IBM '685, Trend Micro '557, and Cisco '331. The key contribution of the '421 patent—its specific template/abstraction/translation architecture—represents the application of a routine, well-understood software engineering principle (abstraction via APIs and adapters) to solve a known and explicitly stated problem in the field (managing multi-vendor security devices). A Person Having Ordinary Skill in the Art in 2014 would have been motivated to combine these concepts to create a more flexible, scalable, and maintainable SIEM system, arriving at the claimed invention with a reasonable expectation of success.