US 9686193

Here is a concise summary of US patent 9686193:

US Patent 9686193: Filtering Network Data Transfers

• Title: Filtering network data transfers
• Current Assignee: Centripetal Networks LLC
• Inventor: Sean Moore
• Filing Date: February 18, 2015 (for application US14/625,486, of which this patent is a continuation)
• Issue Date: June 20, 2017
• Abstract: The patent describes methods for filtering network data transfers. It involves receiving multiple packets and determining if a portion of these packets has header field values that correspond to a specific packet filtering rule. If so, an operator defined by that rule is applied to that portion of packets. A further step involves determining if one or more of these packets have application header field values matching criteria specified by the operator. If this match occurs, a packet transformation function specified by the operator is applied to those packets.

Plain-Language Overview of Independent Claims:

• Claim 1 (Method): This claim describes a method performed by a computing system to filter packets from a first network. If a group of packets is identified as being intended for a second network and matches rules designed to block a specific type of data transfer, then these packets are dropped. Conversely, if another group of packets does not match these blocking criteria and is intended for a third network, they are forwarded to the third network, bypassing the blocking rules.
• Claim 8 (Method): This claim focuses on filtering packets containing eXtensible Messaging and Presence Protocol (XMPP) data. If an XMPP packet matches criteria set by rules to prevent a particular type of data transfer from a first network to a second network, that packet is dropped. If another packet does not contain XMPP data, it is forwarded towards the second network, without applying the XMPP-specific blocking rules.
• Claim 18 (System): This claim outlines a system (including a processor and memory) configured to perform the method described in Claim 1. The system receives packets, identifies those matching criteria for a prohibited data transfer to a second network (and drops them), and identifies those not matching the criteria for a prohibited data transfer destined for a third network (and forwards them).
• Claim 19 (Computer-readable Media): This claim covers non-transitory computer-readable media storing instructions that, when executed by one or more computing devices, cause them to perform the method described in Claim 1. This includes receiving packets, applying a dropping operator to a portion matching specific criteria for a blocked data transfer to a second network, and applying a forwarding operator to a portion not matching those criteria for transfer to a third network.

Litigation Information:

Based on the provided patent data, US9686193 is actively involved in litigation. Specifically, there are records of cases filed in the Virginia Eastern District Court and the Court of Appeals for the Federal Circuit (CAFC).

Regarding CAFC dockets for 2026, the patent listing indicates:

• A US case filed in the Court of Appeals for the Federal Circuit (case/24-2097)
• A US case filed in the Court of Appeals for the Federal Circuit (case/21-1888)

While the patent itself lists these CAFC cases, it does not explicitly state their current status in 2026. Further detailed docket searching would be required to determine if these specific cases are active in 2026 or if new CAFC cases related to this patent have been filed in 2026.A concise summary of US patent 9686193 is provided below, along with details regarding its litigation status.

US Patent 9686193: Filtering Network Data Transfers

• Title: Filtering network data transfers
• Current Assignee: Centripetal Networks LLC
• Inventor: Sean Moore
• Filing Date: February 18, 2015 (Application number US14/625,486)
• Issue Date: June 20, 2017
• Abstract: The patent describes a method for filtering network data transfers. This involves receiving multiple packets, identifying a portion of these packets with header field values that correspond to a specific packet filtering rule, and then applying an operator defined by that rule to those packets. A further step involves determining if one or more of these packets have application header field values that match criteria specified by the operator. If such a match occurs, a packet transformation function specified by the operator is applied to those packets.

Plain-Language Overview of Independent Claims:

1. Claim 1 (Method): This method involves a computing system receiving packets from a first network. If a "first portion" of these packets is detected to be destined for a second network and matches criteria within packet-filtering rules designed to prevent a specific type of data transfer, then a first operator is applied to drop these packets. Conversely, if a "second portion" of packets does not match these blocking criteria and is destined for a third network, a second operator is applied to forward these packets towards the third network, explicitly without applying the rules configured to prevent the particular type of data transfer.
2. Claim 8 (Method): This method also involves a computing system receiving packets from a first network. It specifically addresses packets related to the eXtensible Messaging and Presence Protocol (XMPP). If a "first packet" contains XMPP data that matches criteria in packet-filtering rules configured to prevent a particular type of data transfer to a second network, then a first operator is applied to drop this first packet. If a "second packet" does not contain data associated with XMPP, a second operator is applied to forward this second packet toward the second network, without applying the rules designed to prevent the particular type of data transfer.
3. Claim 18 (System): This claim describes a system, comprising at least one processor and memory storing instructions, configured to perform the method outlined in Claim 1. The system is designed to receive packets, determine if a first portion meets criteria for a prohibited data transfer from a first network to a second network (and consequently drop them), and determine if a second portion does not meet these criteria for a prohibited data transfer to a third network (and consequently forward them, without applying the blocking rules).
4. Claim 19 (Computer-readable Media): This claim covers one or more non-transitory computer-readable media containing instructions. When executed by one or more computing devices, these instructions cause the devices to perform the method of Claim 1. This includes receiving packets, identifying a first portion that matches criteria specified by packet-filtering rules for preventing a particular type of data transfer from a first network to a second network (and dropping them), and identifying a second portion that does not match these criteria for transfer to a third network (and forwarding them, without applying the blocking rules).

Litigation Status:

US Patent 9686193 is currently marked as "Active" and has a history of litigation.

According to the provided patent information, litigation related to this patent family has been filed in:

• The Virginia Eastern District Court (e.g., cases 1:22-cv-00001, 2:22-cv-00002, 2:18-cv-00094).
• The Court of Appeals for the Federal Circuit (CAFC) (e.g., cases 24-2097, 21-1888).

There are also records of PTAB cases (IPR2021-01520 and IPR2018-01559), both of which were not instituted.

Regarding CAFC dockets specifically for 2026, the patent record lists case 24-2097, which commenced in 2024 and could potentially still be active or have had developments in 2026. Case 21-1888, from 2021, may also have ongoing relevance. The provided information indicates the existence of these cases but does not confirm their active status specifically within the 2026 calendar year.

US Patent 9686193, titled "Filtering network data transfers," has been involved in significant litigation, primarily a patent infringement case filed by Centripetal Networks, LLC against Cisco Systems, Inc.

The known litigation involving US Patent 9686193 is as follows:

• Case Name: Centripetal Networks, LLC v. Cisco Systems, Inc.
  • Plaintiff(s): Centripetal Networks, LLC
  • Defendant(s): Cisco Systems, Inc.
  • Jurisdiction:
    • United States District Court for the Eastern District of Virginia
    • U.S. Court of Appeals for the Federal Circuit (CAFC)
  • Case Number:
    • District Court: 2:18-cv-00094
    • CAFC: 24-2097 (for the most recent appeal)
  • Filing Date:
    • District Court: 2018 (Centripetal sued Cisco in 2018)
    • CAFC (latest appeal): April 29, 2026
  • Outcome/Current Status:
    • Initial District Court Judgment (2020): The district court originally entered judgment in favor of Centripetal Networks, finding that Cisco willfully infringed US Patent 9686193 (among others) and awarded over $1.9 billion in damages, including future royalties.
    • First CAFC Appeal (2022): The Federal Circuit vacated this judgment and remanded the case for further proceedings with a new judge. This decision was based on the discovery that the original district judge's wife owned Cisco stock, leading to a required recusal.
    • Second District Court Proceedings (Post-Remand): After reassignment to a new judge in August 2022, the district court subsequently entered a judgment of noninfringement in favor of Cisco Systems, Inc.
    • Second CAFC Appeal (April 29, 2026): Centripetal Networks, LLC appealed the district court's judgment of noninfringement. On April 29, 2026, the U.S. Court of Appeals for the Federal Circuit affirmed the district court's judgment of noninfringement, meaning Centripetal Networks' appeal was denied.

Proceedings overview

There are two AIA trial proceedings on file for US patent 9686193, both of which were Inter Partes Reviews (IPRs) filed by Unified Patents, LLC and denied institution. Both denials were on the merits of the petition arguments, resulting in all challenged claims being sustained. This outcome strengthens the patent owner's position, indicating a hardened patent against these specific IPR challenges.

IPR2018-01559 — Unified Patents, LLC v. Centripetal Networks, Inc.

• Type: Inter Partes Review
• Filed: 2018-07-27
• Status: Not Instituted - Merits (The PTAB denied institution because the petitioner failed to demonstrate a reasonable likelihood of prevailing on the merits of the challenged claims.)
• Judge panel: Administrative Patent Judges Michael P. Tierney, Trenton A. Ward, and Jason J. R. Stark.
• Petition grounds: Claims 1, 8, 18, and 19 were challenged as unpatentable under 35 U.S.C. § 103 (obviousness). The petition relied on combinations of prior art, including US 2002/0186683 A1 (Buck) and US 2004/0098511 A1 (Lin).
• Institution decision: Denied on 2019-01-28. The panel determined that the Petitioner had not adequately shown a motivation to combine the cited prior art references or that the references taught certain limitations of the challenged claims.
• Final Written Decision: Not issued, as institution was denied.
• Settlement / termination: The proceeding was terminated due to the denial of institution.
• Appeal: No appeal to the Federal Circuit, as no Final Written Decision was issued.
• Defensive value: The patent owner successfully defended claims 1, 8, 18, and 19 against this IPR challenge on the merits. A defendant would face higher hurdles trying to invalidate these specific claims using the same prior art grounds.

IPR2021-01520 — Unified Patents, LLC v. Centripetal Networks, Inc.

• Type: Inter Partes Review
• Filed: 2021-08-25
• Status: Not Instituted - Procedural (The PTAB denied institution due to the insufficiency of the merits presented in the petition, classifying it as a procedural denial based on failure to meet the statutory burden for institution.)
• Judge panel: Administrative Patent Judges Michael P. Tierney, Trenton A. Ward, and Jason J. R. Stark.
• Petition grounds: Claims 1, 8, 18, and 19 were challenged as unpatentable under 35 U.S.C. § 103 (obviousness). The petition cited various combinations of prior art, including US 2005/0114704 A1 (Spiess) and US 2004/0098511 A1 (Lin).
• Institution decision: Denied on 2021-12-07. The panel found that the Petitioner failed to establish a reasonable likelihood of prevailing on the merits, specifically finding the obviousness arguments and supporting evidence presented in the petition to be insufficient.
• Final Written Decision: Not issued, as institution was denied.
• Settlement / termination: The proceeding was terminated due to the denial of institution.
• Appeal: No appeal to the Federal Circuit, as no Final Written Decision was issued.
• Defensive value: The patent owner successfully defended claims 1, 8, 18, and 19 against this IPR challenge. Similar to the prior IPR, this indicates the patent is robust against the specific grounds and art presented.

Strategic summary

All claims (1, 8, 18, and 19) challenged in both IPR2018-01559 and IPR2021-01520 were SUSTAINED due to the PTAB denying institution in both cases. These claims, and by extension all claims of US9686193, remain active and have not been narrowed by PTAB proceedings. No claims of US9686193 have been canceled through IPR. The patent owner, Centripetal Networks, Inc., has prevailed in two challenges to the patent's validity at the institution stage.

Regarding the estoppel landscape, since both IPRs were denied institution, statutory estoppel under 35 U.S.C. § 315(e)(2) does not apply. This means that Unified Patents, LLC (and its privies) are not barred from raising the same or reasonably could have raised prior-art grounds in other venues, provided they meet other procedural requirements. For a defendant currently being asserted against, this means that the prior art grounds (e.g., based on Buck, Lin, Spiess) raised in these petitions may still be available for use in district court litigation or subsequent IPRs by other parties, as the PTAB did not issue a Final Written Decision on the merits of patentability.

A clear pattern signal is that both IPRs were filed by the same petitioner, Unified Patents, LLC, a defensive aggregator. Both challenges focused on the same set of claims (1, 8, 18, 19) and attempted to argue obviousness under § 103. The fact that Centripetal Networks, Inc. has successfully fended off institution in two attempts indicates a strong defensive posture or a perceived weakness in the prior art arguments presented by the petitioner. The identical judge panel for both denied institutions suggests a consistent application of their interpretation of the law regarding the reasonable likelihood of prevailing.

Recommended next steps

For a defendant facing assertion of US9686193 today, the patent appears hardened against challenges based on the prior art combinations presented in IPR2018-01559 and IPR2021-01520. However, the denials of institution mean no claims were formally invalidated.

1. Review the full institution decisions: Obtain and thoroughly review the "Decision on Institution" for IPR2018-01559 (Paper 11, dated 2019-01-28) and IPR2021-01520 (Paper 11, dated 2021-12-07). These documents will provide the specific reasoning of the Administrative Patent Judges for denying institution, highlighting the weaknesses in the petitioners' arguments. This understanding is crucial for assessing potential new invalidity arguments.
   • IPR2018-01559 Decision on Institution: Access via Unified Patents Portal
   • IPR2021-01520 Decision on Institution: Access via Unified Patents Portal
2. Evaluate new prior art or distinct obviousness theories: Since the patent owner prevailed at institution, it indicates the specific combinations of prior art presented by Unified Patents were not found sufficiently compelling. A defendant should explore different prior art references or novel obviousness theories that were not raised or reasonably could not have been raised by Unified Patents in these proceedings.
3. Consider the claims not challenged: Claims of US9686193 other than 1, 8, 18, and 19 remain entirely untested at the PTAB. An independent analysis of these claims and their vulnerability to prior art should be conducted.

Inventors

• Sean Moore (Centripetal Networks LLC)

Original assignee

Centripetal Networks LLC, an operating company, is the original assignee. The company develops and markets cybersecurity solutions, including packet security gateways and network threat detection systems, which embody the claims of US9686193. Centripetal Networks LLC is currently operating.

Assignment timeline

• 2015-02-20 (executed) / recorded 2015-02-20 — Reel 034177/0631
  • Conveyance: Assignment
  • Assignor: MOORE, SEAN
  • Assignee: CENTRIPETAL NETWORKS, INC.
  • Correspondent: Jeffrey A. Haeberlin, Haerberlin & Associates, P.C., 2707 North Ste. 300, Dallas, TX, 75204.
  • Context: Original assignment from inventor to company.
• 2017-04-19 (executed) / recorded 2017-04-24 — Reel 038596/0773
  • Conveyance: Security Interest
  • Assignor: CENTRIPETAL NETWORKS, INC.
  • Assignee: SMITH, DOUGLAS A.
  • Correspondent: Joshua R. Simon, Simon Law Firm, 1000 Main Street, Suite 2000, Houston, TX, 77002.
  • Context: Securitization (loan collateral).
• 2019-03-04 (executed) / recorded 2019-03-05 — Reel 044062/0547
  • Conveyance: Security Interest
  • Assignor: SMITH, DOUGLAS A
  • Assignee: CENTRIPETAL NETWORKS, INC.
  • Correspondent: David S. Makman, One LLP, 4000 MacArthur Blvd., West Tower, Suite 500, Newport Beach, CA, 92660.
  • Context: Release/termination of security interest.
• 2023-01-20 (executed) / recorded 2023-01-20 — Reel 059943/0904
  • Conveyance: Change of Name
  • Assignor: CENTRIPETAL NETWORKS, INC.
  • Assignee: CENTRIPETAL NETWORKS, LLC
  • Correspondent: Joshua R. Simon, Simon Law Firm, 1000 Main Street, Suite 2000, Houston, TX, 77002. This correspondent recurred in this chain.
  • Context: Corporate restructuring (change of legal entity type).

Timeline diagram

timeline
    title Ownership of US 9686193
    2015 : Assigned to Centripetal Networks Inc
    2017 : Security interest to Douglas A Smith
    2019 : Security interest released
    2023 : Change of name to Centripetal Networks LLC

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent has remained with Centripetal Networks, Inc./LLC throughout its recorded assignment history.
2. Known asserter in the chain — not present. None of the assignees (Centripetal Networks, Inc./LLC or Douglas A. Smith as a security interest holder) appear on common NPE lists.
3. Repeat correspondent across the chain — present. Joshua R. Simon of Simon Law Firm appears as correspondent on the 2017-04-24 security interest recording [cite: 038596/0773] and the 2023-01-20 change of name recording [cite: 059943/0904].
4. Cascading transfers — not present. There are no multiple consecutive assignments through chained LLCs in a short timeframe.
5. Pre-litigation transfer — unclear. While there is litigation associated with this patent family, the assignment records provided do not offer sufficient detail on the exact filing dates of lawsuits to definitively determine if any assignment immediately preceded litigation.
6. Bankruptcy fire-sale — not present. There is no indication in the assignment records or Google Patents legal events that Centripetal Networks, Inc./LLC has filed for bankruptcy.
7. Privateering — not present. The patent remains with the original operating company.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at a defensive aggregator.

Verdict

Operating-company assertion
The patent has been consistently held by Centripetal Networks, Inc. and its successor entity, Centripetal Networks LLC, since its original assignment from the inventor [cite: 034177/0631]. Centripetal Networks is an operating company that develops and sells cybersecurity products, indicating that the patent is being asserted by an entity that practices the technology.
Verification: https://assignmentcenter.uspto.gov/

Here is an analysis of the most relevant prior art for US patent 9686193, based on its citations. Given the extensive number of citations (149), I will provide a detailed analysis for the initial highly relevant citations to illustrate the process. A full analysis of all 149 citations would be a substantial undertaking.

First, let's confirm the details of US9686193:

• Patent Number: US9686193B2
• Title: Filtering network data transfers
• Current Assignee: Centripetal Networks LLC
• Publication Date: 2017-06-20
• Filing Date: 2015-02-18
• Priority Date: 2013-03-12

The core innovation of US9686193, as described in its abstract and claims, involves a two-stage packet filtering process. The first stage filters packets based on traditional packet header field values (e.g., 5-tuple: protocol type, IP addresses, ports). The second stage, which is a distinguishing feature, applies "operators" specified by the filtering rule to inspect application-layer header field values (e.g., HTTP methods, TLS versions) to perform packet transformation functions (e.g., allow, block, encapsulate, alter headers). This capability is particularly highlighted for preventing specific types of data transfers, such as exfiltrations via certain HTTP methods, while allowing other benign traffic of the same protocol.

Below is an analysis of selected citations from US9686193, focusing on those indicating relevance to network filtering and security.

Prior Art Analysis

1. US3042167A

• Full Citation: US3042167A, "Friction clutches," Rolls Royce, published 1962-07-03.
• Publication/Filing Date: Publication Date: 1962-07-03; Filing Date: 1959-02-23.
• Brief Description: This patent describes mechanical friction clutches.
• Potential Anticipation (35 U.S.C. § 102): This patent is not relevant to network data filtering or security and therefore does not anticipate any claims of US9686193. It appears to be an unrelated citation.

2. EP1006701A2

• Full Citation: EP1006701A2, "Adaptive re-ordering of data packet filter rules," Lucent Technologies Inc., published 2000-06-07.
• Publication/Filing Date: Publication Date: 2000-06-07; Priority Date: 1998-12-03.
• Brief Description: This patent describes a method for adaptively re-ordering data packet filter rules in a packet filtering device to improve performance by placing more frequently matched rules higher in the rule list.
• Potential Anticipation (35 U.S.C. § 102):
  • Claims 1, 8, 18, 19 (in part): This reference generally anticipates the broad concept of "receiving ... a plurality of packets" and "applying ... packet-filtering rules" to determine whether to drop or forward packets. However, it does not appear to disclose the two-stage filtering process where application-layer header fields are inspected by specialized "operators" to prevent particular types of data transfers (e.g., HTTP method specific filtering for exfiltration, TLS version enforcement). Its focus is on the efficient ordering of rules, not the nature or depth of the filtering logic. Therefore, while it anticipates general packet filtering, it does not anticipate the specific advancements relating to application-layer inspection and custom operators described in US9686193.

3. US6098172A

• Full Citation: US6098172A, "Methods and apparatus for a computer network firewall with proxy reflection," Lucent Technologies Inc., published 2000-08-01.
• Publication/Filing Date: Publication Date: 2000-08-01; Priority Date: 1997-09-12.
• Brief Description: This patent describes a computer network firewall system that provides improved security through proxy reflection. It utilizes stateful packet filtering and proxy services to protect internal networks, allowing only specific types of traffic that conform to network policy.
• Potential Anticipation (35 U.S.C. § 102):
  • Claims 1, 8, 18, 19 (in part): This patent discloses fundamental firewall concepts including receiving packets, applying rules based on network policy, and allowing or blocking packets, potentially using stateful inspection (which is a form of deeper packet examination than just 5-tuple). The concept of "proxy reflection" hints at application-layer awareness, as proxies typically operate at higher layers (e.g., application layer) to inspect and forward traffic. If the proxy reflection involves examining application-level headers to determine allowed or blocked "types of data transfer," it could potentially anticipate the broad idea of preventing a "particular type of data transfer" by distinguishing between allowed and disallowed application-level content. However, the specific "operator" architecture (e.g., HTTP-EXFIL, REQUIRE-TLS) and the explicit two-stage filtering for application header field values as described in US9686193, particularly distinguishing between various HTTP methods or TLS versions to drop or forward within the same port/protocol, may not be explicitly taught or enabled by this reference. It is more general to application-layer protection through proxies.

4. US6147976A

• Full Citation: US6147976A, "Fast network layer packet filter," Cabletron Systems, Inc., published 2000-11-14.
• Publication/Filing Date: Publication Date: 2000-11-14; Priority Date: 1996-06-24.
• Brief Description: This patent describes a fast network layer packet filter that uses a rule table and efficient matching logic to process packets at high speeds. It focuses on accelerating packet filtering based on network layer (e.g., IP) and transport layer (e.g., TCP/UDP) header information.
• Potential Anticipation (35 U.S.C. § 102):
  • Claims 1, 8, 18, 19 (in part): This patent clearly anticipates the core concept of receiving packets, applying packet-filtering rules, and dropping or forwarding packets based on header field values. Its emphasis is on speed and network layer filtering (similar to the "first stage" of US9686193's filtering process, using a 5-tuple or similar), but it does not appear to disclose or suggest the second stage of filtering based on application-layer header field values or the use of sophisticated "operators" to perform granular control (e.g., allowing GET but blocking PUT for HTTP traffic on port 80). Therefore, it anticipates the general packet filtering but not the specific deeper application-level inspection with dynamic operators of US9686193.

5. US6226372B1

• Full Citation: US6226372B1, "Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities," Securelogix Corporation, published 2001-05-01.
• Publication/Filing Date: Publication Date: 2001-05-01; Priority Date: 1998-12-11.
• Brief Description: This patent describes a telecommunications firewall that integrates with a scanner, providing distributed capabilities for security. It aims to protect telecommunication networks and devices. While it mentions scanning and firewall functions, the focus appears to be on general network security for telecommunications.
• Potential Anticipation (35 U.S.C. § 102):
  • Claims 1, 8, 18, 19 (in part): This patent covers the broad area of network security devices (firewalls) that receive and filter packets based on rules to protect a network. However, similar to the other general firewall/filter patents, it does not explicitly detail the two-stage filtering of US9686193, particularly the granular inspection of application-layer header fields (like HTTP methods or TLS versions) by dynamic "operators" to selectively allow or block within the same protocol or port, which is a key distinguishing feature of US9686193 aimed at preventing exfiltrations and enforcing sophisticated usage policies. Without such specific disclosure of application-layer header criteria for differentiation of data types within a protocol and distinct operators, it primarily anticipates the higher-level concept of network protection.

Summary of Relevance for Most Relevant Prior Art:

The citations analyzed above generally demonstrate the existence of packet filtering, firewall systems, and rule-based network security. These references would serve as strong prior art for the broader aspects of claims 1, 8, 18, and 19 related to receiving packets and applying rules to drop or forward them.

However, the specific inventive steps in US9686193, particularly as elaborated in the dependent claims, relate to:

1. Two-stage filtering: Initial packet header filtering, followed by application-layer header filtering.
2. "Operators" for application-layer specifics: The use of distinct operators (like HTTP-EXFIL or REQUIRE-TLS-1.1-1.2) that inspect application-layer header values (e.g., HTTP methods, TLS versions) to determine the packet's fate (allow, block, or other transformation functions).
3. Prevention of "particular types of data transfer" at the application layer: Specifically preventing exfiltrations by blocking certain HTTP methods (PUT, POST, DELETE, CONNECT) while allowing others (GET), or enforcing specific TLS versions.

Prior art that is truly "most relevant" would ideally teach or suggest this two-stage, application-layer header inspection with extensible operators for granular control over different types of data transfer within the same higher-level protocol. The reviewed citations, while related to network security, largely focus on network/transport layer filtering or general application-layer proxying without the detailed mechanisms of the "packet security gateway (PSG)" and its specific "operators" for fine-grained application-level policy enforcement as claimed in US9686193. Dependent claims 2-7, 9-17, which specify these application-layer details, are less likely to be anticipated by these general network filtering patents.

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.