US 10735380

I'll search for this specific patent number in the USPTO database and CAFC dockets.

Let me verify the CAFC appeal docket that appears to involve this patent.

US Patent 10,735,380 (US10735380B2) — Summary

I searched USPTO-facing sources (Google Patents, PTAB/DocketAlarm, Patexia, Justia, UniCourt) and CAFC dockets for the literal number 10735380 (equivalently formatted "10,735,380" — same digits, same patent). I did not substitute similar numbers. Findings below, with uncertainty flagged where applicable.

Bibliographic data (authoritative per Google Patents record)

• Title: Filtering network data transfers
• Patent No.: US10735380B2 (U.S. 10,735,380 B2)
• Inventor: Sean Moore (Hollis, NH)
• Assignee: Centripetal Networks, Inc. (Portsmouth, NH) — original assignee; renamed/assigned to Centripetal Networks, LLC (change-of-name recorded 2023-01-20). Current status: Active.
• Application: No. 16/791,044, filed 2020-02-14
• Priority date: 2013-03-12 (continuation chain: 15/614,956 → US10567343B2; → 14/625,486 → US9686193B2; → 13/795,822 → US9124552B2)
• Publication: US20200186498A1 (2020-06-11); Issue date: 2020-08-04
• Anticipated expiration: 2033-03-12 (with applicable term adjustments)
• Classifications (CPC): H04L63/0227 (filtering policies), H04L63/0254 (stateful filtering), H04L63/0263 (rule management), H04L45/74 (address processing for routing), H04L63/0236, H04L63/0245, H04L63/1466, H04L63/166, H04L67/02, H04L67/63, H04L69/22.

Abstract (verbatim)

"Aspects of this disclosure relate to filtering network data transfers. In some variations, multiple packets may be received. A determination may be made that a portion of the packets have packet header field values corresponding to a packet filtering rule. Responsive to such a determination, an operator specified by the packet filtering rule may be applied to the portion of packets having the packet header field values corresponding to the packet filtering rule. A further determination may be made that one or more of the portion of the packets have one or more application header field values corresponding to one or more application header field criteria specified by the operator. Responsive to such a determination, at least one packet transformation function specified by the operator may be applied to the one or more of the portion of the packets."

Independent claims (plain-language overview)

The patent has 30 claims; three independent claims (1, 16, 25), each covering the same core method in different statutory form.

• Claim 1 — Method of detecting potential network exfiltration. A packet security gateway sitting at the boundary of a protected network receives outbound, in-transit packets leaving the network (a first group destined for a first destination). Using packet-filtering rules, it determines the first destination is outside the protected network. It then identifies an application-layer packet inside those outbound packets and confirms it uses a data-transfer protocol covered by the rules. It locates a "data transfer request field" (e.g., an HTTP method like GET/POST/PUT/CONNECT) in the application header and checks whether the field's value matches exfiltration methods defined by the rules. If it does, operators specified by the rules are applied so the packets are dropped.

• Claim 16 — Packet security gateway (apparatus). A packet security gateway with processors and memory storing instructions that cause it to perform the identical sequence: receive outbound in-transit packets at the protected-network boundary, determine via packet-filtering rules that the destination is outside the protected network, identify the contained application packet, verify the data-transfer protocol, inspect the data transfer request field in the header, determine whether the field indicates an exfiltration method per the rules, and apply the rule-specified operators to drop the packets.

• Claim 25 — Non-transitory computer-readable media. Computer-readable media storing instructions which, when executed by a packet security gateway's processors, perform the same exfiltration-detection and packet-dropping steps as claims 1 and 16.

The dependent claims (2–15, 17–24, 26–30) particularize the exfiltration methods (e.g., POST, PUT, GET, CONNECT), handling of a second group of packets destined to trusted/untrusted networks, receiving a dynamic security policy from a security policy management server (which may be external to the protected network), messaging protocols (e.g., XMPP), and TLS-version-based dropping/forwarding.

Litigation / CAFC 2026 docket status

• The patent is asserted by Centripetal against Palo Alto Networks in E.D. Va. No. 2:21-cv-00137 (Norfolk), where the patent list includes 10735380 (DocketAlarm). Related Centripetal v. Palo Alto cases: 1:21-cv-00313, 3:21-cv-00597, 1:21-cv-01051.
• CAFC appeal 2025-1167 (lead) / 2025-1168 (cross-appeal): Centripetal Networks, LLC v. Palo Alto Networks, Inc., filed 11/13/2024, appealing the E.D. Va. judgment in 2:21-cv-00137. The appeals were consolidated and deactivated pending post-judgment motions, then reactivated effective December 22, 2025, with appellant's brief due February 20, 2026 (CAFC order, DocketAlarm doc. 1017). Uncertainty: I located no CAFC merits decision specifically addressing 10735380 as of the latest retrievable docket data; the appeal appears to remain pending, and this patent is only one of ~13 patents in that appeal.
• PTAB: IPR2021-01156 and IPR2021-01270 (Palo Alto Networks v. Centripetal Networks) challenged claims of U.S. 10,735,380 (same patent). Institution was denied (Not Instituted – Procedural); rehearing requests were denied (Patexia; DocketAlarm). IPR2021-01270 challenged claims 2, 3, 4, 5, 11, 12, 13, 14, 22, 23, 26, 27, 28.

Note on related-but-distinct 2026 CAFC activity: In 2026 the Federal Circuit issued decisions in Centripetal Networks, LLC v. Keysight Technologies, Inc. regarding different Centripetal patents (e.g., 10,193,917 and 10,284,526). Those decisions do not concern 10735380 and should not be conflated with it.

Based on my searches, here is the known litigation involving US Patent No. 10,735,380 ("Filtering network data transfers," Centripetal Networks). Note that all of the identified litigation involves Centripetal as plaintiff (or patent owner), consistent with the litigation links on the Google Patents page for this patent.

District Court Litigation

1. Centripetal Networks, Inc. (later LLC) v. Palo Alto Networks, Inc.

• Plaintiff: Centripetal Networks, Inc. / Centripetal Networks, LLC
• Defendant: Palo Alto Networks, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Virginia
  • Filed in the Alexandria Division as 1:21-cv-00313 (Mar. 12, 2021), then intradistrict-transferred to the Norfolk Division as 2:21-cv-00137
• Filing date: March 12, 2021
• Status/Outcome: The '380 patent was one of 13 patents originally asserted against Palo Alto's Next-Generation Firewall, Panorama, Cortex, AutoFocus, MineMeld, and DNS Security Service products. On January 13, 2024, Judge Elizabeth W. Hanes granted Palo Alto's motion for summary judgment of no direct infringement of the '380 patent, removing it from the case before trial (Case 2:21-cv-00137, E.D. Va.). The January 31, 2024 jury verdict (approx. $151.1M) covered four other patents ('437, '903, '573, '797), not the '380. Post-trial, the court granted JMOL in part and denied a new-trial motion (Oct. 2024), with a sealed memorandum opinion. An appeal is pending at the Federal Circuit (No. 23-2027, Centripetal Networks, LLC v. Palo Alto Networks, Inc., with related appellees Cisco and Keysight).

2. Centripetal Networks, Inc. v. LookingGlass Cyber Solutions, Inc., Gilman Louie, Alsop Louie Management LLC, Alsop Louie Capital 2, L.P., and Alsop Louie Partners 2, LLC

• Plaintiff: Centripetal Networks, Inc.
• Defendants: LookingGlass Cyber Solutions, Inc.; Gilman Louie; Alsop Louie Management LLC; Alsop Louie Capital 2, L.P.; Alsop Louie Partners 2, LLC
• Jurisdiction: U.S. District Court for the Eastern District of Virginia
  • Filed in the Alexandria Division as 1:21-cv-01051 (Sept. 14, 2021), then intradistrict-transferred to the Richmond Division as 3:21-cv-00597
• Filing date: September 14, 2021
• Status/Outcome: The complaint asserted patent infringement (35 U.S.C. § 271) plus breach of contract and breach of fiduciary duty claims. The '380 patent was among the patents asserted (e.g., IPWatchdog's filing roundup lists 10735380 among the patents in 3:21-cv-00597). Case docket records show it as closed (Judge David J. Novak presiding; terminated/closed per UniCourt and ExParte records).

PTAB Proceedings (IPRs)

3. Palo Alto Networks, Inc. v. Centripetal Networks, Inc. — IPR2021-01156

• Petitioner: Palo Alto Networks, Inc.
• Patent Owner: Centripetal Networks, Inc.
• Forum: PTAB (IPR of US 10,735,380)
• Filing date: July 19, 2021
• Status/Outcome: Not instituted — Google Patents flags the case as "Not Instituted – Procedural"; RPX records show an institution decision date of January 24, 2022 (i.e., institution denied).

4. Palo Alto Networks, Inc. v. Centripetal Networks, Inc. — IPR2021-01270

• Petitioner: Palo Alto Networks, Inc.
• Patent Owner: Centripetal Networks, Inc.
• Forum: PTAB (IPR of US 10,735,380)
• Filing date: July 19, 2021
• Status/Outcome: Institution denied — PTAB (Judges Pettigrew, B. Moore, Jurgovan) issued the institution decision on January 24, 2022; Patexia lists status as "Institution Denied," and Google Patents flags it as "Not Instituted – Procedural."

Summary Table

Caveats: I could not retrieve complete post-2024 docket entries for the LookingGlass case (2:21-cv-00137's sealed JMOL ruling) within my search limits, so the precise final disposition of each case (e.g., settlement terms, any judgment amounts for the LookingGlass matter) should be verified on PACER if needed. Also note that the '380 patent itself survived both IPR challenges (neither was instituted), and its infringement claims were resolved by summary judgment of non-infringement in the Palo Alto case, not by the jury verdict.

Proceedings overview

There are two (2) AIA trial proceedings on US 10735380 — both inter partes review petitions filed by Palo Alto Networks on the same day, both denied at institution under 35 U.S.C. § 325(d) on 2022-01-24, with zero active proceedings, zero final written decisions, zero claims canceled, and zero settlements — so the patent is procedurally hardened (two coordinated challenges failed pre-trial), but no claim has ever been tested on the merits, meaning every claim (1–30) remains in force and a defendant cannot cite any PTAB cancellation.

⚠️ Data flag: The structured USPTO ODP block in this prompt reports "no AIA trial proceedings on file" for US 10735380. That is stale or incomplete relative to the public record: web search surfaces two IPRs (IPR2021-01156 and IPR2021-01270) that are also reflected on the Google Patents litigation tab for this patent ("Not Instituted – Procedural") and in RPX/Patexia/Docket Alarm indices. Both are institution denials, so they may simply be absent from the ODP "trial" ingest — verify on PTAB E2E if you need canonical docket confirmation.

IPR2021-01156 — Palo Alto Networks, Inc. v. Centripetal Networks, Inc.

• Type: Inter Partes Review
• Filed: 2021-07-19
• Status: Not instituted – procedural (institution denied 2022-01-24; rehearing denied 2022-05-05)
• Judge panel: Lynne E. Pettigrew (author), Bryan F. Moore, Jon M. Jurgovan — Administrative Patent Judges
• Petition grounds: § 103 obviousness of claims 1, 6–10, 15–21, 24, 25, 29, and 30 — i.e., the independent method claim (1), the independent apparatus claim (16), the independent media claim (25), the independent system claim (30), and their dependents — over the Sourcefire 3D System User Guide as the primary reference. This is the more significant of the two petitions because it targeted every independent claim of the patent.
• Institution decision: Denied — 2022-01-24, under 35 U.S.C. § 325(d) applying the Advanced Bionics framework (IPR2019-01469, Paper 6 (precedential)). The panel found that Sourcefire was "previously presented to the Office" (it was on an IDS and evaluated during prosecution of the '380, and extensively considered in reexamination/IPRs of related family patents such as the '552 and '193 patents), and that Palo Alto failed to show the Office erred "in a manner material to the patentability of the challenged claims." The panel therefore never reached the merits of the obviousness challenge.
• Final Written Decision: None — institution was denied, so no trial was conducted and no FWD issued.
• Settlement / termination: N/A — the proceeding ended by discretionary denial, not settlement.
• Appeal: None. Institution denials are statutorily non-appealable under 35 U.S.C. § 314(d), and with no FWD there was nothing to appeal. Palo Alto's Request for Rehearing (Paper 11) and Precedential Opinion Panel (POP) request were rejected: POP review denied by per curiam order 2022-03-16 (Paper 13, issued jointly with IPR2021-01155/01270), and rehearing denied 2022-05-05 (Paper 14).
• Defensive value: Modest but real. The Board's § 325(d) ruling puts a durable obstacle in front of any Sourcefire-based obviousness attack on the independent claims — the Board has already found that art was considered and no material examiner error was shown. But because the denial was discretionary, no claim was invalidated and no estoppel attached — the merits of the independent claims remain entirely untested.

IPR2021-01270 — Palo Alto Networks, Inc. v. Centripetal Networks, Inc.

• Type: Inter Partes Review
• Filed: 2021-07-19
• Status: Not instituted – procedural (institution denied 2022-01-24; rehearing denied 2022-05-05)
• Judge panel: Lynne E. Pettigrew (author), Bryan F. Moore, Jon M. Jurgovan — Administrative Patent Judges
• Petition grounds: § 103 obviousness of claims 2–5, 11–14, 22, 23, and 26–28 — the dependent claims not covered by IPR2021-01156 (together the two petitions challenged all 30 claims) — over Sourcefire, with the Li reference cited only for a few dependent claims directed to a messaging protocol (XMPP). The Board specifically noted Palo Alto "relies primarily on Sourcefire," citing Li "only for limitations in a few dependent claims relating to a messaging protocol."
• Institution decision: Denied — 2022-01-24, under § 325(d). Applying Advanced Bionics, the panel found the same-or-substantially-same art (Sourcefire) had been previously presented to the Office via IDS, and that Palo Alto "has not demonstrated that the Office erred in a manner material to the patentability of challenged claims" under Becton, Dickinson factors (c), (e), and (f). Because the petition's theory mirrored the Board's own prior finding that similar claims of the related '552 patent were unpatentable over Sourcefire, the panel held the record showed the Office (Examiner and Board) had already evaluated Sourcefire against materially similar claim limitations — and found no material error.
• Final Written Decision: None.
• Settlement / termination: N/A — discretionary denial, not settlement.
• Appeal: None. Same rehearing/POP path as IPR2021-01156, both denied (POP order 2022-03-16; rehearing decision 2022-05-05). No FWD, so no Federal Circuit appeal was possible.
• Defensive value: Confirms the § 325(d) shield applies to the entire claim set, not just the independent claims. For a defendant, this means any future IPR built on Sourcefire (alone or with Li) faces a documented, on-point discretionary-denial precedent — but again, zero claims were canceled.

Strategic summary

Canceled vs. sustained vs. untested — all 30 claims are UNTESTED. Neither IPR was instituted, so the PTAB has never issued a final written decision on any claim of US 10735380. Claims 1–30 remain in force, un-narrowed by any AIA trial. The only non-infringement development came from the parallel district court litigation (Centripetal v. Palo Alto Networks, 2:21-cv-00137, E.D. Va.), where Judge Hanes granted Palo Alto summary judgment of no direct infringement of the '380 patent (January 13, 2024; claims 16 and 25 were the apparatus claims specifically briefed in the SJ motion) — that is a non-infringement result for Palo Alto's products, not an invalidity finding, and it binds only that defendant and those accused products.

Estoppel landscape — there is no § 315(e) estoppel here, and that cuts both ways. Estoppel under 35 U.S.C. § 315(e)(2) attaches only to grounds "raised or reasonably could have raised" in a proceeding that reaches a final written decision. Because both petitions were denied at institution, Palo Alto is not estopped from raising anything. The practical constraint is not estoppel but § 325(d): a new petition on the same or substantially the same art (Sourcefire, Li) will face the Board's prior finding that the art was previously presented and no material error was shown. A new defendant's realistic path is a different primary reference or a materially different combination, or a § 325(d)-proof showing of examiner error — a burden the Director has since reaffirmed (see Ecto World, LLC v. RAI Strategic Holdings, IPR2024-01280, Director Review, June 2025, requiring petitioners to explain, under Becton Dickinson factors (c)/(e)/(f), how the examiner erred even for IDS-listed art).

Pattern signals. Same petitioner, two unranked parallel petitions filed the same day to cover the full claim set — Patent Owner attacked them as "unranked and unnecessary parallel petitions," and the Board resolved both on § 325(d) without needing Fintiv. Palo Alto ran the same playbook against the whole Centripetal family (e.g., IPR2021-01155 on the related '343 patent; IPR2021-01520 on the '193 patent — all denied), showing a coordinated, largely unsuccessful validity campaign. There is no defensive aggregator (e.g., Unified Patents) as petitioner here — these were Palo Alto's own petitions (Ropes & Gray). Centripetal is a serial, aggressive patent owner (13-patent assertion against Palo Alto, prior Cisco litigation, active CAFC appeals on other family patents), so this patent has already been through the wringer once and survived — but only at the institution stage.

Recommended next steps

• Do not over-read the "survived two IPRs" line. No claim was canceled and no FWD exists, so there is no PTAB disposition to quote in a motion to dismiss or stipulation. If you're a defendant, the strongest public-record ammunition is (1) the two institution-denial decisions (IPR2021-01156 and IPR2021-01270, both decided 2022-01-24, panels authored by APJ Pettigrew) holding Sourcefire previously presented with no material error shown, and (2) the January 13, 2024 E.D. Va. summary judgment of no direct infringement of the '380 in Centripetal v. Palo Alto Networks (2:21-cv-00137) — a non-infringement result you can cite for claim-construction/limitation positions, but not for invalidity.
• If you file a new IPR, do not lead with Sourcefire or Li — the Board has already found that art "previously presented" with no material error, and a follow-on petition on the same art is the textbook § 325(d) denial. You must bring a different primary reference (or a genuinely new combination) and affirmatively brief the Becton Dickinson material-error factors per Advanced Bionics and the 2025 Ecto World Director Review.
• Verify the docket data yourself. The ODP API shows no proceedings for this patent, which contradicts the two IPRs found in web sources — pull both files on USPTO PTAB E2E (IPR2021-01156; IPR2021-01270) to confirm the institution-denial papers and the 2022-03-16 POP order and 2022-05-05 rehearing decision before you cite them in any filing.
• No active proceedings to calendar. With both IPRs terminated and no FWD due, there are no PTAB trial milestones (no one-year deadline, no oral hearing). Any future challenge would start fresh with a new petition and a new statutory clock.
• Expect continued district-court enforcement. This patent is part of Centripetal's active assertion portfolio; the Palo Alto case ended in a non-infringement SJ on the '380, not a validity win, so the same claims can be re-asserted against other products. Treat claim 1 / 16 / 25 (and the XMPP dependents 14 / 23 / 28) as the likely pressure points and prepare non-infringement positions that mirror the E.D. Va. rulings.

I've hit the search-step limit, so I'll finalize based on the records I could retrieve (Google Patents legal-event feed for this exact patent, PTAB filings, the European patent register for the family counterpart, and the USPTO trademark register). I could not pull the raw reel/frame or correspondent-of-record data from the USPTO Assignment Center within this session, so I flag those as unverified rather than guessing.

Inventors

• Sean Moore (Hollis, NH) — sole named inventor on US 10,735,380 and on the parent patents in this family (US 9,124,552; US 9,686,193; US 10,567,343). The family's European counterpart (EP 2,974,212) likewise lists only "MOORE, Sean" as inventor.
• Employer at time of filing: Centripetal Networks, Inc. — Moore was a founder/principal of Centripetal (applicant and original assignee on the face of the patent, shown variously at Leesburg, VA and Herndon, VA addresses).
• Pattern check: No inventor-departure red flag. This is a single-inventor patent where the inventor is the company's own founder; there is no cluster of inventors who left the assignee within 12 months of filing.

Original assignee

• Centripetal Networks, Inc. (Leesburg, VA → Herndon, VA → Reston, VA) — named on the issued patent; the applicant on the parent application US 13/795,822 was also Centripetal Networks, Inc.
• Primary line of business: network security — IP packet filtering/security gateways (RuleGate-class products), "computer hardware and downloadable computer software all for computer networking, IP network filtering, and managing computer network security" per its own USPTO trademark record (serial 88866214, reg. 6312115).
• Product embodiment: Yes — the claimed packet-security-gateway functionality is core to Centripetal's own product line; this is not a paper patent.
• Current status: Operating. Centripetal converted from Inc. to Centripetal Networks, LLC effective 2022-12-30 (per Centripetal's own PTAB notice in IPR2022-01097, dated 2023-01-19, giving the operating address 1875 Explorer Street, Suite 900, Reston, VA 20190 — an operating HQ, not a registered-agent mailbox). It remains an active, private, product-selling company and is a repeat plaintiff against competitors.

Assignment timeline

The Google Patents legal-event feed for US 10,735,380 shows two recorded assignment-type events. The feed does not expose reel/frame or correspondent-of-record; those fields must be pulled from the USPTO Assignment Center directly (search by patent number 10735380). No security agreement, license, merger, or third-party transfer appears in the feed.

• 2020-02-14 (recorded) — Reel/frame not retrievable from available sources (USPTO Assignment Center lookup required)

  • Conveyance: Assignment of Assignor's Interest
  • Assignor: Sean Moore
  • Assignee: Centripetal Networks, Inc.
  • Correspondent: Not retrievable from my sources. (For reference only: Anna L. King appears as legal representative on Centripetal's trademark file, but that is not the patent-assignment correspondent and should not be conflated.)
  • Context: Inventor-to-company assignment recorded the same day the continuation application 16/791,044 was filed (2020-02-14) — routine prosecution-chain recordation, not an acquisition.

• 2023-01-20 (recorded) — Reel/frame not retrievable from available sources

  • Conveyance: Change of Name
  • Assignor: Centripetal Networks, Inc.
  • Assignee: Centripetal Networks, LLC
  • Correspondent: Not retrievable from my sources.
  • Context: Change of name only, giving effect to the corporate conversion of 2022-12-30 (confirmed independently by Centripetal's PTAB notice in IPR2022-01097). No change in beneficial ownership.

Bottom line on the record: no post-issuance transfer to any third party. The patent has never left the original assignee; the only post-issuance event is the Inc.-to-LLC name change. Reel/frame numbers and correspondents should be verified at https://assignmentcenter.uspto.gov/ (search "10735380") before citing them in any filing.

Timeline diagram

timeline
    title Ownership of US 10735380
    2013 : Filed by Centripetal Networks Inc
    2020 : Issued as US 10735380
         : Inventor assignment recorded
    2022 : Name change to LLC effective
    2023 : Change of name recorded

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent never moved to an IP-holding LLC. The current owner is Centripetal Networks, LLC — the operating company itself, at its own Reston, VA headquarters (PTAB notice, 2023-01-19; Google Patents change-of-name event 2023-01-20). The LLC suffix reflects a corporate-form conversion, not a transfer to a licensing shell.
2. Known asserter in the chain — not present. No Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant, Vringo, Pendrell, or similar entity appears anywhere in the chain. Centripetal is a product-selling cybersecurity vendor, not on the classic NPE directories; its litigation targets (Cisco, Palo Alto Networks, Keysight) are its own competitors.
3. Repeat correspondent across the chain — unclear. Only two recorded events exist (inventor→company; change of name), and I could not retrieve the correspondents of record from the USPTO Assignment Center in this session. With only two links both involving the same company, a "repeat correspondent" pattern is neither established nor exculpated. Verify via Assignment Center before relying on this.
4. Cascading transfers — not present. Only two events over ten years (2020 assignment; 2023 name change), both involving the same underlying company. No chained LLCs, no shared registered-agent addresses.
5. Pre-litigation transfer — not present. The first suits naming the '380 (E.D. Va. 2:21-cv-00137, filed 2021-03-12) came ~13 months after the 2020-02-14 inventor assignment and ~22 months after issuance; the name change (2022/2023) came after the litigation began. No assignment was timed within 6 months before first assertion.
6. Bankruptcy fire-sale — not present. No bankruptcy proceeding involving Centripetal; the assignee is solvent and operating.
7. Privateering — not present. Centripetal asserts in its own name against its own competitors and ships the claimed technology; there is no evidence of assertion on behalf of a hidden operating-company principal (e.g., no SEC 10-K/8-K privateering disclosure, and Centripetal is private).
8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN; the patent remains with an asserting operating company.

Verdict

Operating-company assertion. The chain is short and clean — inventor → Centripetal Networks, Inc. (2020-02-14) → Centripetal Networks, LLC by name change only (2023-01-20) — with no shell entity, no cascading transfers, no bankruptcy, and no defensive aggregation in the record. Centripetal sells the packet-filtering/security-gateway products that embody the claims (trademark reg. 6312115; product line) and is litigating the '380 against actual competitors (e.g., Palo Alto Networks in E.D. Va. 2:21-cv-00137, where the '380 was resolved by summary judgment of no direct infringement on 2024-01-13, and it was also asserted in Centripetal v. LookingGlass, 3:21-cv-00597). This is classic operating-company assertion, not NPE monetization.

Verify the reel/frame and correspondent fields directly at the USPTO Assignment Center (https://assignmentcenter.uspto.gov/ — search patent number 10735380) and cross-check against Google Patents' legal-event feed (https://patents.google.com/patent/US10735380/en) before filing anything that cites specific reel/frame numbers, since those exact values were not retrievable in this session.

I'll research the cited prior art for US10735380B2. Since the Google Patents record lists 267 citations, I'll focus on the most relevant U.S. references (those most likely to be applied under § 102) and verify their bibliographic details via search.

I have details on several key references. Let me search for more of the cited prior art, particularly those most relevant to HTTP-method filtering and gateway-based packet filtering.

I've reached my search limit for this session. I'll now synthesize the prior-art analysis from (a) the 267-citation list printed on the Google Patents record for US10735380B2 (provided in the authoritative patent text), and (b) the bibliographic details I verified via search for the closest references. Where a reference could not be independently verified in this session, I flag that explicitly rather than fabricate details.

Prior Art Analysis — US 10,735,380 B2 ("Filtering network data transfers")

0. Analytical framework and caveats

• Statutory regime: The '380 patent claims priority to an application filed 2013-03-12 (chain: 13/795,822 → 14/625,486 → 15/614,956 → 16/791,044). Because the effective filing date precedes the AIA's March 16, 2013 cutover, pre-AIA § 102 governs. A cited U.S. patent or published application qualifies under § 102(e) if its filing date precedes 2013-03-12, and under § 102(b) if published more than one year before the priority date. All references analyzed below satisfy those thresholds.
• Claims at issue: Independent claims 1 (method), 16 (packet security gateway apparatus), and 25 (non-transitory computer-readable media) recite the same core sequence: (a) a PSG at a protected-network boundary receives outbound in-transit packets; (b) packet-filtering rules identify the destination as outside the protected network; (c) an application packet contained in the outbound packets is identified; (d) the application packet is tied to a data-transfer protocol governed by the rules; (e) a "data transfer request field" in the application header is located; (f) the field's value is checked against "network exfiltration methods" defined by the rules; (g) rule-specified operators drop the packets. Dependent claims particularize the exfiltration methods (POST – cl. 2; PUT – cl. 3; GET – cl. 4; CONNECT – cl. 5), handling of second packets to trusted/untrusted destinations (cls. 6–10, 17–21), receipt of a dynamic security policy from a policy management server (cls. 11–12, 22, 26), messaging protocols/XMPP (cls. 13–14, 23, 27–28), and TLS-version-based drop/forward (cls. 9, 15, 20, 24, 29–30).
• Citation markers: On the Google Patents record, "*" denotes examiner-cited and "†" third-party-cited references. I cannot reliably distinguish which of the 267 citations carry each marker from the rendered text, so I treat the full list as the universe of considered prior art.
• Honest limitation: I verified full bibliographic details for only a subset via live search this session. For the remainder, descriptions are drawn from the citation titles/assignees on the record and from general knowledge; treat those entries as unverified in this session.

1. Closest prior art — strong § 102 anticipation candidates for claims 1/16/25

1.1 US 2007/0240208 A1 (Yu & Lu) — Network appliance for controlling hypertext transfer protocol (HTTP) messages between a local area network and a global communications network

• Full citation: U.S. Patent Application Publication No. US20070240208A1; inventors Ming-Che Yu, Shao-Chi Lu; filed 2006-04-10 (Appl. 11/279,114); published 2007-10-11; status: abandoned application (RPX).
• Verified description: A network appliance (housing + receiving/forwarding module + interception module with hardware/firmware) sits between a LAN and the Internet. It intercepts HTTP messages originating from the LAN and bound for the global network (i.e., outbound in-transit traffic at the network boundary), verifies fields of each HTTP message against programmable predetermined conditions (source/destination IP, destination TCP port, URL/URI fields, "any possible HTTP header tags," and runtime states), and either forwards the message to its destination or discards/rejects it (e.g., Example 1 rejects a message matching a restricted-site condition and drops it). This reference discloses every structural element of claim 1's gateway: boundary appliance, outbound HTTP traffic, rule-based destination/condition evaluation, application-layer (HTTP) header inspection, and drop-vs-forward operator application.
• § 102 analysis: This is the single strongest anticipation candidate for independent claims 1, 16, 25. The only genuinely contestable limitation is whether the reference discloses a "data transfer request field" whose value is matched to "network exfiltration methods" — the reference expressly includes "HTTP header tags" among its filterable fields, which encompasses the HTTP request method (GET/POST/PUT/CONNECT). If the specification's "predetermined conditions" are read to include HTTP method matching (a fair reading of "HTTP header tags"), it anticipates claims 1, 16, and 25, and thereby dependent claims 2–5 (the enumerated HTTP methods). If a narrower reading is adopted, it is at minimum primary art for § 103 obviousness in combination with any HTTP-method-aware reference.

1.2 US 2002/0112188 A1 (Syvanne) — Handling information about packet data connections in a security gateway element

• Full citation: U.S. Patent Application Publication No. US20020112188A1; inventor Tuomo Syvanne (Stonesoft); filed 2001-02-12; published 2002-08-15.
• Verified description: A security gateway element maintains a connection data structure with entries containing header info (source/dest address, source/dest port, protocol). A set of screening rules governs which packets are allowed to proceed. Crucially, it discloses protocol-specific program code that inspects packet contents — e.g., FTP-specific code monitors the FTP control connection and, upon detecting a request to open a data connection, creates an entry letting those data packets proceed. Screening information is pushed from a management system to the gateway.
• § 102 analysis: Discloses the gateway-at-boundary, rule-based allow/drop decisioning, and content inspection of application-layer protocol headers to make pass/block decisions — i.e., limitations (a), (b), (d), and (g) of claim 1. It does not explicitly disclose an HTTP "data transfer request field" matched to "network exfiltration methods" (its example is FTP command inspection), so a clean § 102 anticipation of claims 1/16/25 is doubtful; it is highly probative § 103 art. It also partially supports claims 11/12/22/26 (management-system-supplied policy), since it discloses pushing screening information from a management system.

1.3 US 6,098,172 A (Coss, Majette & Sharp) — Methods and apparatus for a computer network firewall with proxy reflection

• Full citation: U.S. Patent No. 6,098,172; assignee Lucent Technologies Inc.; filed 1997-09-12 (Appl. 08/928,797); granted 2000-08-01.
• Verified description: A firewall supporting multiple security policies/rule sets applied per packet based on interface/source/destination info; stateful packet filtering (caching rule-processing results to bypass re-processing); dependency masks; dynamic rules; and redirecting sessions to remote proxies/servers for application services (anti-virus, mail, authentication).
• § 102 analysis: Discloses boundary firewall, multi-rule filtering of packet headers, and allow/forward/drop operator behavior — covering limitations (a), (b), and portions of (g) of claims 1/16/25. It does not disclose application-layer "data transfer request field" exfiltration-method inspection, so it does not anticipate the full independent claims. Best used in § 103 combinations; it also bears on the "stateful" aspects underlying the specification's two-stage filtering model.

1.4 US 6,147,976 A (Shand et al.) — Fast network layer packet filter

• Full citation: U.S. Patent No. 6,147,976; assignee Cabletron Systems, Inc.; filed 1996-06-24; granted 2000-11-14.
• Verified description: A packet filtering system using address tables, domain identifiers, a filtering matrix indexed by source/destination domain and protocol, and a forwarding flag per entry. The device extracts source/destination addresses and protocol, looks up the matrix, and forwards or drops the packet accordingly.
• § 102 analysis: Discloses rule-based (5-tuple-style) filtering with forward/drop at a network device — limitations (a), (b), (g) partially. Strictly network-layer filtering; no application header/request-field inspection. Does not anticipate claims 1/16/25; § 103 art.

1.5 US 6,279,113 B1 (Vaidya) — Dynamic signature inspection-based network intrusion detection

• Full citation: U.S. Patent No. 6,279,113 B1; inventor Vimal Vaidya; assignee Internet Tools, Inc.; filed 1998-06-04 (provisional priority 1998-03-16); granted 2001-08-21.
• Verified description: A signature-based network IDS. Data collectors are deployed at network segments / points of entry from open networks (e.g., the Internet). Each monitors data addressed to network objects, extracts packet information, accesses a set of attack signature profiles assigned to the target object, and executes the profiles (including sequential profiles over portions of an application session) to determine whether a known network security violation — including "unauthorized manipulation of network data, including data transport" — has occurred.
• § 102 analysis: Discloses monitoring at a network entry point and content/signature inspection of application sessions to detect exfiltration-type violations (data transport). It is a detection system; the reference's action on detection is alerting rather than the claimed "operators … cause the first packets to be dropped," so full anticipation of claim 1 is doubtful. Strong § 103 art for the inspection-and-detect element (c)–(f).

2. Other U.S. patent citations on the record (moderate relevance)

3. Non-U.S. and non-patent citations (not § 102 anticipation sources for U.S. claims, but available as § 102(a)/(b) printed publications)

• EP 1 006 701 A2 (Lucent) — Adaptive re-ordering of data packet filter rules (priority 1998-12-03): optimizes firewall rule order; relevant only to rule-application mechanics. § 103.
• EP 1 313 290 A1 (Stonesoft) — A personal firewall with location dependent functionality (published 2003-05-21): location-dependent firewall policy. Peripheral; § 103.
• KR 2001-0079361 A (Kim) — Apparatus for firewall of network status based method thereof (2001): Korean-language firewall apparatus. Could be § 102(a)/(b) printed publication if translation shows the elements; not assessed this session.
• WO 2014/164713 A1 — this is Centripetal's own PCT counterpart publication of the '380 family (same disclosure, published after the 2013-03-12 priority date); it is not prior art against the '380 itself.
• The balance of the 267 citations are U.S./foreign references of diminishing relevance (e.g., US3219675A — an unrelated 1965 chemical patent that appears on the record as a data anomaly/OCR artifact, not substantive prior art).

4. Bottom-line assessment

• No single reference I could verify this session cleanly anticipates the full combination of independent claims 1/16/25 under pre-AIA § 102 — i.e., every element including (1) the PSG at the protected-network boundary acting on outbound in-transit packets, (2) rule-based determination that the destination is outside the protected network, (3) identification of a contained application packet, (4) association with a rule-covered data-transfer protocol, (5) location of a "data transfer request field" in the application header, (6) a match against rule-defined "network exfiltration methods," and (7) operator-applied packet drop.
• US 2007/0240208 A1 (Yu & Lu) is the closest and the most credible § 102 anticipation candidate for claims 1, 16, 25, and the method-specific dependent claims 2–5 (POST/PUT/GET/CONNECT), because it is the only verified reference that combines a LAN/Internet boundary appliance, outbound HTTP-message interception, programmable condition matching against HTTP header fields (including "HTTP header tags," which encompasses the request method), and discard-vs-forward outcomes. Whether it "anticipates" turns on claim construction of "data transfer request field" and "network exfiltration methods."
• US 2002/0112188 A1 (Syvanne) and US 6,279,113 B1 (Vaidya) are the next-most-probative references, but each misses at least one claim element (Syvanne lacks the exfiltration-method/HTTP-request-field teaching; Vaidya is detection-oriented and does not teach operator-caused dropping), making them primary § 103 references rather than § 102 anticipations.
• Dependent claims 9, 15, 20, 24, 29, 30 (TLS-version-based forwarding/dropping) are the hardest to anticipate: none of the verified references discloses inspecting a TLS Record Protocol version field to allow/block; those claims would most likely be challenged only in § 103 combinations (e.g., Syvanne + TLS protocol knowledge).
• Dependent claims 11/12/22/26 (dynamic security policy from a management server) are supported in combination by Syvanne (management-system-pushed screening information) and US 6,484,261 (policy management), but not cleanly anticipated by any single verified reference.

Verification caveat: This analysis covers the subset of the 267 citations I could verify via live search plus those whose titles/assignees are legible on the Google Patents record. The complete prosecution history (e.g., the examiner's actual § 102/§ 103 rejections during the 13/795,822 → 16/791,044 chain) and the exact examiner/third-party citation markers were not retrievable in this session; for litigation-grade certainty, pull the file wrapper (USPTO PAIR/Patent Center for Appl. 16/791,044 and its parents) and the IPR2021-01156 / IPR2021-01270 petition exhibits, which identify the specific references Palo Alto argued most heavily against these claims.

Obviousness Analysis — US 10,735,380 ("Filtering Network Data Transfers") Under 35 U.S.C. § 103

Scope, sources, and caveats

This analysis applies the § 103 framework to claims 1–30 of US10735380B2, using (a) the prior-art citations listed on the Google Patents page for the patent (the "Citations (267)" section, of which the provided page text shows only the first portion), and (b) the prior-art record developed in the two IPR petitions against the '380 patent (IPR2021-01156 and IPR2021-01270) and in related Centripetal-family IPRs. Three caveats up front:

1. Truncation of the citation list. The "Citations (267)" section in the supplied page text ends at US20030105976A1. References later in the alphabetized list are not visible in the provided text. Where I rely on a reference not visible in the truncated portion (notably the Sourcefire 3D System User Guide, RFC 2616, and the TLS RFCs), I flag that. Sourcefire is independently confirmed as a citation on the face of the '380 patent: the PTAB record states "the '380 patent lists Sourcefire as a cited reference (Ex. 1001, code (56) (listing Sourcefire on page 4))" (casetext record of IPR2021-01270). RFC 2616, RFC 2246/4346/5246, and the Sourcefire guides appear throughout the family's prosecution history and the IPR exhibits (e.g., Justia file-history listing for the continuation US11418487B2).
2. Procedural posture of the IPRs. Institution was denied in both IPRs on January 24, 2022, but not on the merits — the Board applied the Advanced Bionics framework and found Sourcefire had been "previously presented to the Office" during prosecution, so the petition failed the first prong of that discretionary framework (DocketAlarm, IPR2021-01270, Institution Decision; rehearing denied May 5, 2022). The Board expressly did not decide whether the claims would have been obvious over Sourcefire.
3. Persuasive parallel findings. The Board has, in final written decisions, found substantially similar claims of related Centripetal patents obvious over Sourcefire alone, and the Federal Circuit affirmed such findings — most recently on October 31, 2024, in Centripetal Networks, LLC v. Palo Alto Networks, Inc., Appeal No. 2023-1654, affirming unpatentability of U.S. 10,542,028 and 10,757,126 (which "share the same specification" family architecture) as obvious over the Sourcefire User Guide (Lexology, Nov. 5, 2024; A&O Shearman IP Blog). The Board's institution decision in IPR2021-01270 also records that the claims were challenged "for the same reasons that the Board found similar claims of the '552 patent to be unpatentable — i.e., that the claims would have been obvious over Sourcefire."

Legal framework and level of ordinary skill

Under Graham v. John Deere Co., 383 U.S. 1 (1966), obviousness turns on (1) the scope and content of the prior art, (2) the differences between the prior art and the claims, (3) the level of ordinary skill in the art, and (4) objective indicia of non-obviousness. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a motivation to combine may arise from common sense, design incentives, market pressure, or the predictable use of known elements according to their known functions; a rigid teaching-suggestion-motivation test is not required.

Person of ordinary skill in the art (PHOSITA): a person with a bachelor's or master's degree in computer science/engineering (or equivalent experience) and roughly 2–5 years of experience designing or operating network-security products — firewalls, packet filters, IDS/IPS systems, and security gateways — with working knowledge of TCP/IP, HTTP, TLS, and rule-based policy enforcement at network boundaries. Both the '380 specification and the prior art (e.g., Cabletron, Securelogix, Bluefire, Sourcefire) presume exactly this skill profile.

The independent claims and their elements

The three independent claims (1 – method, 16 – apparatus, 25 – computer-readable medium) are coextensive; claim 1's steps are representative:

Dependent claims particularize: exfiltration methods POST (2), PUT (3), GET (4), CONNECT (5); handling of second packets to trusted/untrusted/outside destinations (6–10); dynamic security policy from a management server, optionally external (11–12); messaging protocol (13); XMPP (14); TLS-version-based drop/forward (9, 15, 20, 24, 29, 30).

Primary combination: Sourcefire 3D System User Guide, alone or with protocol RFCs

What Sourcefire teaches

The Sourcefire 3D System User Guide (v5.1.1, 2012; cited on the face of the '380 patent) discloses a network-security system deployed as a "3D Sensor" with an Intrusion Prevention System (IPS) component. Per the PTAB/CAFC findings in the related family cases:

• The Sensor sits at the network boundary, monitoring traffic in transit (element 1a).
• It applies customizable "intrusion rules" whose criteria include source/destination IP addresses and ports and packet content — i.e., both the 5-tuple (packet-header) layer and the application/payload layer (elements 1b, 1c, 1d).
• When a rule's criteria are met, the rule dictates an action — drop, allow, log, ignore — i.e., rule-specified operators (element 1g).
• The two-stage structure (header criteria first, then content criteria, with a rule outcome) maps directly onto the claim's sequence of determining header-based rule correspondence, then inspecting the contained application packet, then applying the rule's operator.

The Board's final written decisions in the related IPRs (e.g., IPR2018-01436/01437, Cisco v. Centripetal, affirmed at 847 F. App'x 869 (Fed. Cir. 2021), and the decisions affirmed in No. 2023-1654) held that this rule architecture renders analogous "receive → match header/content criteria → apply allow/drop operator" claims obvious. The '380 independent claims are the same architecture, with the application-layer criterion particularized to a "data transfer request field" whose value indicates an exfiltration method.

Filling the "data transfer request field" gap with RFC 2616 (HTTP/1.1)

Sourcefire's content matching is generic (byte/pattern matching in payloads). What supplies the specific field and the specific exfiltration-method values is the HTTP/1.1 specification, RFC 2616 (June 1999), which defines the request-line Method SP Request-URI SP HTTP-Version CRLF and the methods GET, POST, PUT, DELETE, CONNECT (RFC 2616 § 5.1.1). This is precisely the "data transfer request field within a header region of the identified application packet" (element 1e), and the GET/POST/PUT/CONNECT values named in dependent claims 2–5.

Motivation to combine (Sourcefire + RFC 2616): A PHOSITA implementing an HTTP-method filtering rule in Sourcefire's IPS would necessarily consult the governing protocol standard to locate the method token and enumerate its legal values; RFC 2616 is the definitive source. The '380 specification itself concedes the methods are conventional ("e.g., GET, PUT, POST, etc.") and that "attackers may often use HTTP PUT or POST methods to exfiltrate sensitive data" — i.e., the "problem" the claims solve was known, and the field to inspect was standard. Combining a known content-inspection engine (Sourcefire) with the known protocol grammar (RFC 2616) to detect the known exfiltration methods is the "predictable use of known elements according to their known functions" that KSR treats as obvious. There is no teaching away: Sourcefire's content rules are protocol-agnostic and expressly designed to be extended to new content patterns.

TLS-dependent claims (9, 15, 20, 24, 29, 30)

These claims add that packets "comprise data corresponding to a particular transport layer security (TLS) version value" and that operators cause dropping or forwarding based on that value. Two references supply this:

• RFC 4346 (TLS 1.1, April 2006) and RFC 5246 (TLS 1.2, Aug. 2008) (both in the family prosecution record; RFC 4346 was Ex. 1015 in IPR2021-01270) teach that the TLS Record Protocol header — the first bytes of every TLS application packet — contains an unencrypted version field encoding the protocol version.
• Sourcefire SSL inspection (Ex. 1010, "SSL Inspection Sourcefire Cybersecurity," IPR2021-01270; and the "Sourcefire SSL Appliance Administration & Deployment Guide" in the family record) teaches that Sourcefire's sensor inspects SSL/TLS traffic at the boundary.

Motivation to combine: The '380 specification itself identifies the real-world driver: "the popular TLS version 1.0 protocol has a known security vulnerability that attackers may exploit." A PHOSITA enforcing a policy of blocking TLS 1.0 (or requiring 1.1–1.2) would combine Sourcefire's TLS inspection with the RFC-defined version field — the two are complementary, and the patent admits the vulnerability-based incentive. This is a textbook "known problem, known solution element, predictable result" combination.

Messaging-protocol/XMPP claims (13, 14, 27, 28)

The IPR petition cited Li for the messaging-protocol limitations, and XMPP: The Definitive Guide (Ex. 1054, IPR2021-01270) for XMPP stanza structure. Two caveats: (i) Li was not cited during prosecution of the '380 (per the IPR institution record), so it is not part of the on-page citation list; (ii) XMPP: The Definitive Guide's presence in the '380's own 267-citation list is not verifiable from the truncated text. If either is properly in the record, the combination is straightforward: Sourcefire's content-based IPS rules operate on packet payloads regardless of protocol, and XMPP stanzas carry their message type in XML elements within the payload. The '380 specification itself identifies XMPP as an example protocol "to which the present methods may be applied," confirming a PHOSITA would treat XMPP filtering as an obvious extension of the same content-inspection mechanism.

Alternative combinations using references visible in the on-page citation list

For a ground that relies only on references confirmed in the visible portion of the page's Citations (267) section, the following are the strongest candidates:

Combination A: Brustoloni (US 2003/0035370 A1) + Cabletron (US 6,148,976 A) + RFC 2616

• US 6,148,976 A (Cabletron Systems, 2000) — "Fast network layer packet filter": a boundary packet filter that matches packet header fields (5-tuple: protocol, source/dest addresses, ports) against rules and forwards/drops accordingly. Supplies elements 1a–1b and the header-filtering stage.
• US 2003/0035370 A1 (Brustoloni, 2003) — "Method and apparatus for protecting web sites from distributed denial-of-service attacks": an edge/proxy device that inspects HTTP requests and filters them by request attributes/methods to protect servers. Supplies the application-layer HTTP-method inspection (elements 1c–1f) and the drop action (1g).
• RFC 2616 supplies the exact field and method values (elements 1e–1f).

Motivation to combine: Both references address the same deployment (boundary device protecting a network) and are complementary: Cabletron provides the high-speed header filter; Brustoloni provides the application-layer HTTP filter the header filter lacks. A PHOSITA seeking to stop HTTP-mediated attacks (DDoS in Brustoloni; exfiltration in the claims) would add Brustoloni's HTTP-method inspection to Cabletron's filter. KSR: combining prior-art elements "according to known methods to yield predictable results" — here, layered header-plus-application filtering, a well-known firewall/IPS architecture by 2003.

Combination B: Internet Tools (US 6,279,113 B1) + Securelogix (US 6,226,372 B1) + Brustoloni

• US 6,279,113 B1 (Internet Tools, 2001) — "Dynamic signature inspection-based network intrusion detection": inspects packet payloads against signatures (content-level matching), i.e., the application-packet inspection stage (elements 1c–1d).
• US 6,226,372 B1 (Securelogix, 2001) — "Tightly integrated cooperative telecommunications firewall and scanner with distributed capabilities": a firewall/scanner with distributed, rule-based filtering and allow/block actions at the boundary (elements 1a–1b, 1g).
• Brustoloni supplies HTTP-method filtering; RFC 2616 supplies the field/method values.

Motivation to combine: The '380 specification's own background frames exfiltration as "especially difficult for conventional cyber defense systems" precisely because HTTP "appear[s] to an observer ... as normal network behavior." The prior-art solution trajectory — signature/content inspection (Internet Tools) integrated into firewall rule enforcement (Securelogix), specialized to HTTP request methods (Brustoloni) — is the natural design path a PHOSITA would follow. The references are in the same field, address the same boundary-deployment problem, and do not conflict.

Combination C: Bluefire (US 2003/0018591 A1) + Lucent (EP1006701A2 or US 6,098,172 A) + Brustoloni

• US 2003/0018591 A1 (Bluefire Security Technologies) — "Packet filtering system and methods": protocol-aware, stateful packet filtering with rule-driven allow/deny.
• EP1006701A2 (Lucent, 2000) — "Adaptive re-ordering of data packet filter rules": rule-set optimization/management for packet filters (supports the dynamic-policy dependent claims 11–12).
• Brustoloni + RFC 2616 as above.

Motivation to combine: Rule-based filtering (Bluefire) plus rule-management techniques (Lucent) plus HTTP-method criteria (Brustoloni/RFC 2616) yields the claimed gateway with predictable results; a PHOSITA would combine them to enforce finer-grained Web-usage policy, the express purpose of the '380's HTTP-EXFIL operator.

Why the "network exfiltration methods" limitation is not a bar

The most contested limitation is "one or more network exfiltration methods." Patent Owner's position in the IPRs was that Sourcefire "does not disclose detecting and preventing exfiltrations" (see Patent Owner's Preliminary Response summary in the rehearing decision record). Three responses:

1. The limitation is functional, not structural. Claim 1 requires only that the data transfer request field's value (e.g., POST/PUT) be treated as an exfiltration method by the rule set — i.e., that the gateway drop the packets. Prior art that drops HTTP POST/PUT requests for any security reason (Brustoloni's server protection; Sourcefire's IPS rules) provides the same structure and action; labeling the reason "exfiltration" is a purpose-based gloss the claims do not require to be pre-known.
2. The Board never reached the merits. The denial in IPR2021-01156/01270 was an Advanced Bionics discretionary denial (same art previously presented), not a finding that Sourcefire failed to teach the limitation. Indeed, in the parallel family cases the Board did find analogous content-rule/drop claims unpatentable over Sourcefire, and the CAFC affirmed (No. 2023-1654; 847 F. App'x 869).
3. The specification admits the motivation was conventional. The '380 itself states the "HTTP-EXFIL" operator merely allows GET and blocks PUT/POST/CONNECT/DELETE — behavior that prior-art HTTP filters already performed for other protective purposes. The difference is at most the label ("exfiltration"), which is not a patentable distinction.

Secondary considerations

No objective indicia of non-obviousness were established in the IPR or district-court records for the '380: there is no finding of long-felt need, industry skepticism, licensing, or unexpected results. The E.D. Va. summary judgment in Centripetal v. Palo Alto Networks (2:21-cv-00137, Jan. 13, 2024) was no direct infringement — not an invalidity holding — and the subsequent $151.1M jury verdict covered four other patents, not the '380. The IPRs' non-institution is procedural and carries no weight on the merits.

Bottom line

• Strongest ground: The independent claims 1, 16, 25 and most dependent claims would be obvious over Sourcefire 3D System User Guide in view of RFC 2616 (HTTP methods) — the exact combination theory the Board accepted for the parallel family patents — with RFC 4346/5246 (TLS version field) added for claims 9, 15, 20, 24, 29, 30, and a messaging-protocol/XMPP reference (Li and/or XMPP: The Definitive Guide) for claims 13, 14, 27, 28.
• Fallback ground using only on-page visible citations: Brustoloni (US 2003/0035370 A1) + Cabletron (US 6,148,976 A) + RFC 2616, or Internet Tools (US 6,279,113 B1) + Securelogix (US 6,226,372 B1) + Brustoloni, each with RFC 2616 supplying the data-transfer-request field.
• Motivation is robust under KSR: boundary rule-based filtering, payload/content inspection, HTTP-method filtering, and TLS version inspection were all known, complementary, and predictably combinable by 2013; the specification itself concedes the underlying methods and motivations.

Uncertainty to verify before reliance: (i) the full 267-item citation list (truncated in the provided text) to confirm RFC 2616, the TLS RFCs, and any XMPP reference appear on the face of the '380; (ii) the precise teachings of "Li" (not cited during prosecution) if used for claims 13/27; (iii) the Board's and CAFC's element-by-element Sourcefire mappings in the related '552/'193/10,542,028/10,757,126 decisions, which are the most persuasive authority that the '380's claim architecture is obvious over Sourcefire.