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 this patent's prior-art record. Let me run several targeted searches in parallel.

Let me pull details on the most relevant individual references cited on the '380.

Prior-Art Analysis — US 10,735,380 ("Filtering Network Data Transfers")

Scope, method, and hard limits (read first)

I searched for the literal identifier 10735380 / US10735380B2 (no substitution of similar numbers). What follows is built from (a) the citation list reproduced on the face of the patent (the "(56) References Cited" / "Citations (267)" block), and (b) the prior-art record developed in the two IPRs against this exact patent (IPR2021-01156, IPR2021-01270) and the related Centripetal-family proceedings.

Three limits I will not paper over:

1. The citation list is truncated in every source I could reach. The '380 carries 267 citations. The Google Patents page text supplied for this analysis reproduces only the first ~30 (alphabetically, ending at US20030105976A1); the DocketAlarm copy of the patent PDF (Ex. 1001 in IPR2021-01156) shows the same early portion and cuts off around US 7,721,084. I therefore cannot give a complete reference-by-reference table for all 267 items. I give you the full-detail treatment for every citation I can verify, and I flag the remainder as unrecovered rather than fabricating titles/dates.

2. Only ~60 of the 267 entries are recoverable with title + date. The rest (roughly US 7,7xx–8,8xx and the second half of the pre-grant publications) are alphabetically later and were not retrieved. I list the confirmed ones and name the unrecovered block explicitly.

3. Anticipation (§ 102) vs. obviousness (§ 103) is the crux here. A § 102 rejection requires one reference disclosing every limitation of a claim as arranged in the claim. Based on the record, no cited reference is a clean anticipatory reference for independent claims 1/16/25, and I say so plainly below rather than force-fitting one. The substantive prior-art risk to this patent is § 103 (analyzed in the earlier Obviousness section and cross-referenced at the end).

Legal framework note (matters for the cited references' date treatment): the '380's effective filing date is 2013-03-12, which is before the AIA's 2013-03-16 first-to-file cutoff, so pre-AIA 35 U.S.C. §§ 102/103 apply (this is exactly the framework Palo Alto used in its petitions, which state that "all references to §§102/103/112 are to pre-AIA 35 U.S.C."). That makes the critical date for § 102(b) 2012-03-12. Every reference in the visible list predates that by roughly a decade, so essentially the entire cited list is § 102(b) printed-publication/patent art.

---

Table 1 — U.S. patent document citations confirmed on the face of US 10,735,380

Dates shown as earliest priority (listed) → publication. "§ 102 candidacy" states the claims the reference could be mapped against in a single-reference challenge, and then states the disqualifying gap — because in every case a gap exists.

* = earliest listed date in the Google Patents "prior art date" column; verify against the front page of each reference.

Unrecovered block (US 7,7xx–8,8xx and remainder): US 7,792,775 (Matsuda); US 7,814,158 (Malik); US 7,814,546 (Strayer et al.); US 7,818,794 (Wittman); US 7,849,502 (Bloch et al.); US 7,913,303 (Rouland et al.); US 7,954,143 (Aaron); US 8,004,994; US 8,009,566; US 8,037,517; US 8,042,167; US 8,117,655; US 8,156,206; US 8,176,561; US 8,219,675; US 8,271,645; US 8,306,994; US 8,207,029; US 8,331,234; US 8,422,391; US 8,495,275; US 8,510,821; US 8,726,379; US 8,806,638; US 8,832,833; US 8,856,926, and others through the 267th entry. I did not retrieve these titles/dates and will not guess them.

---

Table 2 — U.S. pre-grant publication citations (the substantive ones), with § 102 mapping

These are the entries from the front of the citation list most likely to carry application-layer/protocol-method teachings relevant to the '380's claims.

---

Table 3 — Foreign patent documents cited

(The two AU documents are almost certainly family members of related third-party applications rather than independent art; verify before relying.)

---

Table 4 — Non-patent literature cited / in the IDS of record

These are not "patent citations," but they are the references the examiner was actually given, and they are the substantive prior art that matters to claims 1/16/25.

---

The most relevant prior art — ranked, with the § 102 verdict

1. Sourcefire 3D System User Guide v4.10 (NPL; listed on the '380 at code (56), p. 4). Most relevant by far. Discloses the architecture the claims recite (boundary device → 5-tuple rule match → content/rule-option match → drop/pass action). Verdict: cannot anticipate claims 1/16/25 — it never discloses a "data transfer request field," and its content matching is generic rather than exfiltration-method-specific. It is the primary § 103 reference (see below and the earlier Obviousness section). Note the family history: the Board found claims 1–21 of the related '552 patent (same specification) unpatentable over Sourcefire (IPR2018-01436 FWD; aff'd 847 F. App'x 869 (Fed. Cir. 2021)), while in IPR2018-01559 the Board declined to institute on the '193 patent precisely because Sourcefire did not disclose an "operator distinct from a packet-filtering rule… configured to drop packets associated with a particular type of data transfer" — the very second-stage limitation that the '380's claims 1/16/25 also require. That asymmetry is the key § 102/§ 103 fault line.

2. US 2003/0035370 A1 (Brustoloni). Most relevant patent citation for the application-layer core: HTTP-request inspection and method-based filtering/blocking. Verdict: does not anticipate 1/16/25 — no outbound-from-protected-network framing, no "outside the protected network" determination, no exfiltration characterization. Best § 103 partner for Sourcefire or as the primary reference in a fallback combination.

3. US 6,279,113 B1 (Vaidya / Internet Tools). Most relevant content-inspection patent citation (payload signature matching). Verdict: supplies 1c–1d only; no anticipation.

4. US 6,147,976 A (Shand / Cabletron). Cleanest 5-tuple boundary-filter citation (1a–1b, 1g). Verdict: no anticipation (network layer only).

5. RFC 2616. Supplies the "data transfer request field" and the GET/POST/PUT/CONNECT values. Verdict: no anticipation — a protocol specification cannot disclose the claimed filtering method.

Everything else in the visible list (Coss, Beebe, Kenworthy, Wiegel, Syvänne, Secui.Com, Bluefire, Buck, Broadcom, Anderson, Eder, EP 1006701, EP 1313290, and the ~30 unexamined US 7,6xx–7,7xx entries) is general firewall/intrusion-detection/policy-management art. None is directed to application-protocol request-method filtering or to exfiltration detection, and each is missing at least elements 1e–1g or 1a–1b.

---

Bottom line on § 102

• No cited reference anticipates claims 1, 16, or 25. The claims require the conjunction of (a) an outbound, in-transit packet leaving a protected network, (b) a rule-based determination that the destination is outside that network, (c) identification of an application packet and its data-transfer protocol, (d) identification of a data transfer request field in the application header, (e) a determination that the field's value is a network exfiltration method, and (f) rule-specified operators that drop the packet. Every reference I could verify satisfies only a proper subset of (a)–(f). The single-reference requirement of § 102 is therefore not met.
• The closest calls are Sourcefire (architecture) and Brustoloni (HTTP method). Even viewed generously, Sourcefire lacks (d)/(e) and Brustoloni lacks (a)/(b)/(e).
• Where the real risk lies is § 103 — Sourcefire in view of RFC 2616 (and RFC 2246/5246 for the TLS-version dependents; a messaging reference for the XMPP dependents 14/23/28). That combination theory is the one the Board accepted against the same-specification '552 patent, and it is the theory Palo Alto advanced in IPR2021-01156/01270. The Board never reached it on the merits here — those petitions were denied at institution on 2022-01-24 under § 325(d) (Advanced Bionics), because Sourcefire had been "previously presented to the Office" via IDS with no material examiner error shown. So the '380's claims survived on procedure, not on the merits.
• The "exfiltration method" limitation is the pivot. It is the one limitation for which I found no anticipatory teaching anywhere in the cited record; the '380's own specification describes the HTTP-EXFIL operator's behavior as the conventional allow-GET/block-POST-PUT pattern, which is why this limitation should be read functionally and why it is vulnerable to § 103 rather than immune to it.

---

Verification gaps and flagged discrepancies (do not cite without checking)

1. ~207 of the 267 citations were not recoverable. Every US 7,7xx–8,8xx entry and the tail of the pre-grant publications and foreign documents remain untitled/undated in my sources. Pull the full "(56) References Cited" block from the granted patent PDF (US 10,735,380, p. 4 and continuations) or from PTAB E2E (IPR2021-01156, Ex. 1001) to complete the list.
2. Number-format inconsistencies across sources — reported literally, not corrected:
   • US 6,971,028 B1 vs. 7,971,028 B1 (both listed 11/2005).
   • US 7,710,888 B2 vs. 7,710,885 B2.
   • US 7,222,269 / 7,225,269 and 7,222,260 variants for the Watanabe reference.
   • US 6,662,235 B1 vs. 6,662,253 B1.
   • US 7,227,842 B1 vs. 7,237,842 B2; US 7,143,438 vs. 7,116,438 / 7,152,240 / 7,145,208 variants.
     These are OCR/transcription artifacts in the reproduced front pages; confirm each against the individual reference's own front page before using it in a filing.
3. US 3,219,675 (Ivershen / Columbian Carbon, 1965) appears on the face of the patent but is a chemical-process reference with no nexus to packet filtering. It is almost certainly an erroneous citation. Reported as it literally appears.
4. I could not retrieve titles/dates for US 6,611,875 (Chopra et al.), US 6,662,235 (Callis et al.), US 6,826,694 (Dutta et al.), US 6,907,042 (Oguchi), US 7,089,581 (Nagai), US 7,095,716 (Ke), US 7,107,613 (Chen), US 7,152,240 (Copeland), US 7,185,368 (Copeland III), US 7,215,637 (Ferguson), US 7,225,269 (Watanabe), US 7,227,842 (Ji), US 7,237,267, US 7,263,099 (Wood), US 7,296,288 (Hill), US 7,299,353 (Le Pennec), US 7,331,061 (Ramsey), US 7,478,429 (Lyon), US 7,499,412 (Matityahu), US 7,539,186 (Turley), US 7,610,621 (Govindarajan), US 7,684,400 (Ilnicki), US 7,721,084 (Salminen). One search returned an unrelated "Chopra" registration (US 9,182,932, website printing / US 11,276,028, delivery logistics), confirming the ambiguity — I have not attributed any of those unrelated documents to the '380's citation of "Chopra et al."
5. Sourcefire as a "printed publication" is settled for this family: the Federal Circuit affirmed public accessibility on 2021-03-10 (847 F. App'x 869). Centripetal's cert petition (US S. Ct. No. 21-193) challenging that holding does not alter the PTAB/CAFC record; treat Sourcefire as qualifying § 102(b) art.
6. Li and "XMPP: The Definitive Guide" are not citations of record on the '380. They entered the record only through the 2021 IPRs. Do not describe them as "cited on the '380."

Cross-reference / consistency check with the earlier-generated sections: this analysis is consistent with the earlier Patent summary and PTAB sections (both IPRs denied at institution 2022-01-24 under § 325(d), no FWD, no claim canceled) and with the earlier Obviousness section (Sourcefire + RFC 2616 as the strongest § 103 ground). The only point I would sharpen against the earlier Obviousness analysis: its fallback "Combination A" treating Brustoloni as a § 102-style HTTP-filter teaching should be understood as § 103 art only — Brustoloni's device protects servers from inbound requests, whereas claim 1 requires dropping outbound packets leaving a protected network toward an outside destination, so Brustoloni cannot anticipate even under a broad, functional reading of the "exfiltration method" limitation.

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.