Obviousness

The obviousness of US patent 9686193 under 35 U.S.C. § 103 can be analyzed by identifying combinations of prior art references that would render its claims, particularly the independent claims (e.g., Claim 1), obvious to a person having ordinary skill in the art (POSITA) at the time of the invention (priority date March 12, 2013).

The core inventive concept of US9686193, as described in its abstract and detailed description, revolves around a two-stage network data transfer filtering process implemented by a Packet Security Gateway (PSG). This process involves:

1. A first stage where packets are filtered based on network and transport layer header information (e.g., a "5-tuple" of protocol type, source IP, source port, destination IP, and destination port) against a set of packet filtering rules.
2. A second stage where, for packets matching certain criteria in the first stage, further filtering is performed by inspecting application header field values (e.g., specific HTTP methods like GET, PUT, POST, DELETE, CONNECT, or Transport Layer Security (TLS) protocol versions). Based on these application-layer inspections, different "operators" (e.g., ALLOW, BLOCK, or other packet transformation functions) are applied. The primary goal articulated is to prevent "exfiltrations" or other cyber attacks that might otherwise appear as normal network behavior.

Let's consider the elements of Claim 1, which generally describes a method for filtering packets:

• Receiving a plurality of packets, comprising a first and second portion.
• For the first portion:
  • Determining if it corresponds to criteria specified by packet-filtering rules configured to prevent a particular type of data transfer from a first network to a second network.
  • Applying a first operator (specified by rules) configured to drop packets associated with that particular data transfer.
  • Dropping these packets.
• For the second portion:
  • Determining if it does not correspond to the criteria of the preventative rules (and is destined for a third network).
  • Applying a second operator (without applying the specific preventative rules for the first-to-second network transfer) configured to forward packets not associated with the particular data transfer toward the third network.
  • Forwarding these packets.

The specification clarifies that the "particular type of data transfer" is typically identified via application-layer inspection (e.g., HTTP PUT/POST for exfiltration).

Prior Art References for Obviousness Analysis:

From the "Citations" section of US9686193B2, the following references are highly relevant:

1. US20030154399A1 (Zuk): Titled "Multi-method gateway-based network security systems and methods".

   • Teaching: This patent discloses a "multi-method gateway" capable of receiving packets and applying "multiple different methods of security" to them based on rules and packet characteristics. Crucially, it explicitly teaches "content inspection of the packets" as one such security method, which can be applied to "selected packets that meet specified criteria." The overall goal is to enhance network security.
   • Relevance to Claim 1: Zuk provides the conceptual framework for applying various security methods, including deep packet inspection (DPI)/content inspection, based on rules to selected traffic, aligning with the two-stage filtering described in US9686193.

2. US20020186683A1 (Buck): Titled "Firewall gateway for voice over internet telephony communications".

   • Teaching: Buck describes a "firewall gateway" that incorporates both a traditional "firewall for filtering packets according to a security policy" and an "application layer gateway (ALG)" coupled to the firewall. The ALG is specifically used for application-level understanding and processing (e.g., for VoIP signaling channels).
   • Relevance to Claim 1: Buck offers a concrete architectural implementation for combining basic packet filtering (by a firewall) with application-layer processing (by an ALG) within a single gateway to enforce security policies. This directly addresses the two-stage filtering concept.

Obviousness Argument: Combination of Zuk (US20030154399A1) and Buck (US20020186683A1)

A POSITA at the time of the invention would have been motivated to combine the teachings of Zuk and Buck to arrive at the claimed invention in US9686193.

Motivation for Combination:
A POSITA, concerned with improving network security and preventing sophisticated cyber attacks like data exfiltration (a known problem discussed in the background of US9686193), would seek to implement more granular control over network traffic.

• Zuk teaches the broad concept of a "multi-method gateway" that can apply various security methods, including "content inspection," to "selected packets" based on rules. This highlights the desirability of performing deeper inspection.
• Buck provides a practical and well-known architectural solution for performing both packet-level and application-level filtering within a network boundary device by combining a "firewall" (for initial packet filtering) with an "application layer gateway (ALG)" (for application-specific processing).

The motivation for combining these would be to achieve a comprehensive and efficient network security system. The POSITA would understand that:

• Initial screening by a traditional packet filter (as taught by Buck's firewall) is efficient for handling most traffic.
• For traffic that warrants deeper scrutiny (e.g., certain protocols or destinations, or for "particular types of data transfer" as broadly suggested by Zuk's "security methods" and "content inspection"), application-layer processing (as taught by Buck's ALG) is necessary to understand and control application-specific behaviors.

Application to Claim 1:

1. Receiving packets; determining correspondence to criteria specified by packet-filtering rules: Both Zuk's "multi-method gateway" applying security "based upon rules" and Buck's "firewall for filtering packets according to a security policy" clearly teach receiving packets and evaluating them against filtering rules.
2. Configured to prevent a particular type of data transfer: Zuk's emphasis on "multiple different methods of security" and "content inspection" directly supports the idea of preventing specific types of data transfers. Buck's firewall/ALG combination is designed to enforce security policies, inherently preventing undesirable transfers.
3. Applying operators (drop/forward): Dropping (blocking) and forwarding (allowing) packets are fundamental operations of any firewall or security gateway, explicitly or implicitly taught by both Zuk and Buck as outcomes of applying security rules/methods.
4. Two-tiered processing (first portion matches, second portion doesn't): Zuk explicitly states "content inspection can be applied to selected packets that meet specified criteria." This implies a first-stage filtering to select packets for a second, deeper inspection. Buck's architecture with a firewall feeding an ALG also represents this two-stage processing: the firewall initially filters, and only certain traffic passes to the ALG for application-level analysis.
5. "without applying the one or more packet-filtering rules configured to prevent the particular type of data transfer from the first network to the second network" for the second portion (to a third network): This reflects standard firewall policy behavior. Rules are typically specific to source/destination pairs and traffic types. If a packet is destined for a "third network" and doesn't match the criteria (especially application-layer criteria) that trigger the preventative rules for transfers to the second network, then those specific preventative rules would naturally not apply, and a different, potentially default "forward" operator would be used. This is a routine implementation choice for managing rule sets in a security gateway.

Obviousness of Dependent Claims (e.g., HTTP methods, TLS versions):

Dependent claims 9-17 specify that the "particular type of data transfer" is identified by inspecting HTTP methods (e.g., POST, PUT, DELETE, CONNECT for dropping; GET for forwarding) or TLS protocol versions.

• Motivation: Given the teachings of "content inspection" in Zuk and the use of an "application layer gateway (ALG)" in Buck, a POSITA would be motivated to use these capabilities to inspect specific application-layer fields. It was well-known in the art prior to 2013-03-12 that:
  • HTTP methods like POST, PUT, DELETE, and CONNECT could be leveraged for unauthorized data exfiltration or malicious modifications, while GET typically represents legitimate data retrieval. Therefore, inspecting and selectively blocking these methods to prevent exfiltration (as described in US9686193) would be an obvious security enhancement.
  • Older TLS versions (e.g., TLS 1.0) had known security vulnerabilities. A POSITA would be motivated to inspect the TLS version in HTTPS traffic and block connections using vulnerable versions while allowing more secure ones (e.g., TLS 1.1 or 1.2), as a standard security practice to mitigate known exploits.

Thus, the combination of Zuk's multi-method gateway concept and Buck's firewall with an application layer gateway architecture, coupled with the general knowledge in the art regarding common exploits via HTTP methods and TLS vulnerabilities, would have rendered the claims of US9686193 obvious. The specific selection of HTTP methods or TLS versions for filtering would be a routine design choice for a security administrator seeking to implement enhanced network security policies.