US 10659573

Summary — U.S. Patent 10,659,573 (US10659573B2)

Note on sourcing: The bibliographic data below comes from the authoritative Google Patents record for US10659573B2 (fetched 2026-08-30) included in the task materials, corroborated by Unified Patents and Justia records. I could not retrieve the full granted-claims text (the provided patent text truncates before the claims section), so the claim overview below is based on the published application (US20190394310A1, which corresponds to application 16/554,293 that issued as US10659573B2) as shown on Justia. Treat the exact granted claim language as unverified.

Bibliographic data

• Title: Correlating packets in communications networks
• Patent number: US10659573B2 (application no. US16/554,293)
• Assignee (original): Centripetal Networks LLC (later assignments show Centripetal Networks, Inc., and a 2023 change of name back to Centripetal Networks, LLC)
• Inventors: David K. Ahn; Peter P. Geremia; Pierre Mallett, III; Sean Moore; Robert T. Perry
• Earliest priority date: 2015-02-10 (chain: 14/618,967 → US9,264,370; 14/714,207 → US9,560,176; 15/413,947; then this continuation, filed 2019-08-28)
• Issue date: 2020-05-19
• Status: Active; anticipated expiration 2035-02-10
• Classifications: H04L69/22 (header parsing); H04L43/02, 43/026 (flow-identification monitoring); H04L43/12 (probes); H04L45/745 (address lookup/filtering); H04L47/10, 47/24, 47/32 (flow control/discard); H04L61/2567 (NAT traversal); H04L63/0227 (filtering policies); H04L43/0852/087 (delay/jitter); H04L43/106 (timestamps)

Abstract (verbatim)

"A computing system may identify packets received by a network device from a host located in a first network and may generate log entries corresponding to the packets received by the network device. The computing system may identify packets transmitted by the network device to a host located in a second network and may generate log entries corresponding to the packets transmitted by the network device. Utilizing the log entries corresponding to the packets received by the network device and the log entries corresponding to the packets transmitted by the network device, the computing system may correlate the packets transmitted by the network device with the packets received by the network device."

What the patent is about (plain language)

Endpoint communications are "flows" of related packets. A middlebox-type network device (e.g., a NAT device, proxy, or VPN/tunneling gateway) can rewrite or encapsulate packets in ways that obscure which flow a packet belongs to when viewed from outside that device. The patent places tap/packet-filtering devices on both sides of such a network device, logs packets received by the device (from a host in a first network) and packets transmitted by the device (toward a host in a second network), and then correlates the transmitted packets back to the received packets using the log data (header fields, ports, timestamps, encapsulated payloads, etc.). This re-association lets a correlator figure out, for example, which internal host was actually communicating with an external (possibly malicious) destination, generate alerts, and provision rules to drop offending traffic.

Independent claims (plain-language overview; from published application US20190394310A1, pending verification of granted text)

The publication shows three independent claim sets — a method claim (claim 1), a computing-device/system claim (claim 9), and a computer-readable-media claim (claim 17) — each with the same core steps:

1. Method claim (claim 1): Identify a plurality of packets received by a network device from a host in a first network; generate a first plurality of log entries for those received packets; identify a plurality of encrypted packets transmitted by the network device toward a host in a second network; generate a second plurality of log entries for those transmitted encrypted packets; and correlate the transmitted encrypted packets with the received packets based on both sets of log entries.
2. Computing device claim (claim 9): A device (memory + processors) that performs the same identification, log-generation, and correlation functions; dependent claim 10 adds provisioning of a first tap and a second tap with rules to identify the received and transmitted packets respectively; claim 15 adds determining the second-network host is malicious and generating drop rules; claim 16 adds generating a message identifying the first-network host.
3. Computer-readable media claim (claim 17): Non-transitory media with instructions causing a computing system to perform the same identify/log/correlate operations.

Dependent claims detail correlation techniques (comparing ports, network-interface identifiers, timestamps of receipt vs. transmission, and encapsulated/request data).

Caveat: I could not confirm whether the granted claims of the B2 patent are identical to the published application claims (e.g., the "encrypted packets" wording appears in the publication; amendment during prosecution is possible).

CAFC 2026 docket status (with uncertainty)

• The Google Patents family record lists CAFC appeals involving this patent family: 25-1167, 25-1168, and 26-1359 (the 26-xxxx number being a 2026 docket), plus district-court cases 2:21-cv-00137 and 1:21-cv-00313 (E.D. Va.), 1:22-cv-00001 and 2:22-cv-00002, and PTAB case IPR2021-01151 (petition not instituted on the merits).
• News coverage (Law360, April 2026) reports that a Federal Circuit panel heard argument on April 7, 2026 and, around April 29, 2026, affirmed a Virginia district court finding that Cisco did not infringe a trio of Centripetal cybersecurity patents (following vacatur of a multibillion-dollar judgment due to a judge's stock conflict). It is plausible 10659573 is among those three patents, but I could not verify the specific patent-to-docket mapping (the CAFC opinions/orders page I retrieved showed Centripetal decisions 24-1406 and 24-1416, which concern a different patent, US10,284,526, and an ITC matter).
• Other 2026 activity: a June 12, 2026 report that the PTAB again found a Centripetal Cisco-related patent invalid as obvious on remand — again, not confirmed to be 10659573 specifically.

If you need certainty on the granted claims or the exact CAFC docket (26-1359) scope, I'd recommend pulling the claims PDF from USPTO Patent Center (application 16/554,293) and the CAFC docket sheet directly.

I'll research the litigation record for US10659573 specifically, running several targeted searches.

Let me verify the appellate dockets and the current status of the E.D. Va. case, plus check for any other defendants.

Let me nail down the remaining docket numbers and defendants.

Litigation involving U.S. Patent No. 10,659,573 (US10659573B2)

Bottom line: Three federal district-court matters and one consolidated Federal Circuit appeal are confirmed to involve the '573 patent. All are Centripetal Networks enforcement actions. There is no record of the '573 patent being litigated by any party other than Centripetal as plaintiff, and no PTAB trial was ever instituted on it.

1. Centripetal Networks, Inc. v. Palo Alto Networks, Inc. — the principal case

Patent scope of the case. The '573 was one of 13 asserted patents in the original/amended pleading. Based on the docket record, the patents listed include 10,091,246; 10,503,899; 10,530,903; 10,542,028; 10,567,343; 10,567,413; 10,567,437; 10,659,573; 10,735,380; 10,749,906; 10,757,126; 10,785,266; and 10,931,797. Accused products were PAN's Next-Generation Firewall, Panorama, Cortex XDR/XSOAR/XSIAM, AutoFocus, MineMeld, and DNS Security products.

Procedural history relevant to the '573:

• May 2023 — After PTAB final written decisions invalidated six of the challenged patents ('028, '126, '413, '246, '906, '899), only the '437, '380, '903, '573, and '797 patents remained in active litigation.
• Jan. 2, 2024 — The court denied PAN's motion for summary judgment of non-infringement as to the "Correlation Patents" ('903, '573, '797 — same family), finding genuine disputes of material fact on (i) whether the accused products log transmitted packets and correlate them with received packets and (ii) whether a rule/indication is generated "responsive to" the correlating, including under the doctrine of equivalents.
• Jan. 31, 2024 (jury verdict) — The jury found PAN directly and literally infringed claim 1 and claim 9 of the '573 patent, and additionally found induced infringement of claim 1. Damages were awarded as a lump sum for the life of the patent: $37.875M per patent, with $151.1M total across the four surviving patents. The jury found no willfulness, and found that PAN had not shown the '903/'573/'797 claims were "well-understood, routine, and conventional."
• Oct. 2024 — PAN's motion for JMOL was GRANTED IN PART and DENIED IN PART; the motion for a new trial was DENIED. Critically, the Memorandum Opinion (ECF No. 970) was filed under seal, so which patents/claims/damages components were affected by the partial JMOL grant is not publicly established — I cannot confirm whether the '573 verdict survived intact.
• Dec. 19, 2025 — A further Memorandum Order issued (ECF No. 1016).

Status as of April 26, 2026: On appeal and pending. See § 4 below.

2. Companion E.D. Va. filing — Centripetal Networks, Inc. v. Palo Alto Networks, Inc., No. 1:21-cv-00313

Documents captioned "Case No. 1:21-cv-00313" appear on the Norfolk docket (2:21-cv-00137, ECF Nos. 7 and 10), which indicates the Alexandria filing was a companion/parallel complaint whose papers were carried into the Norfolk action. The Google Patents litigation metadata for this patent lists both 1:21-cv-00313 and 2:21-cv-00137 separately.

Caveat: I could not verify from the retrieved records whether 1:21-cv-00313 was voluntarily dismissed, transferred, or consolidated into 2:21-cv-00137. The two share the same parties and filing date, so they should be treated as one enforcement event pending confirmation on PACER.

3. Centripetal Networks, LLC v. Keysight Technologies, Inc. ("Keysight II")

Centripetal's Section 337 complaint in ITC Investigation No. 337-TA-1314 states verbatim: *"The PTAB denied institution for the '573 and '797 Patents and issued an institution decision for the '903 patent. The '573 Patent is also asserted in Keysight II."*

Status: The case was stayed, and Centripetal has moved to lift the stay and reopen the case (supported by a declaration from Kristopher Kastens of Kramer Levin). The elapsed-time status of that motion as of April 26, 2026 is unverified.

Two caveats on this case:

• A claim-chart analysis of the 2:22-cv-00002 complaint retrieved in this session discusses only the '370 and '917 patents (accusing Keysight's ATI/ThreatArmor/Vision One products), not the '573. The '573 assertion is documented in the ITC complaint, but the specific accused-product/claim mapping for '573 in Keysight II is not verified in the material I retrieved.
• The ITC investigation itself (337-TA-1314) asserts the '370, '917, and '526 patents — not the '573. The ALJ's Initial Determination found no violation, invalidating two asserted patents and finding a third patent-ineligible.

4. Consolidated Federal Circuit appeals — Nos. 2025-1167, 2025-1168, and 2026-1359

Status and chronology:

• The appeals were filed from the post-trial judgment in 2:21-cv-00137.
• Dec. 22, 2025 — The Federal Circuit reactivated the appeals (2025-1167, 2025-1168) under Fed. R. App. P. 4(a)(4) after the district court disposed of the last motion tolling appealability. The court set appellant's brief as due February 20, 2026.
• Jan. 20, 2026 — No. 26-1359 was docketed (Centripetal Networks, LLC v. Palo Alto Networks, Inc.).
• Feb. 3, 2026 — The court consolidated the appeals, designating 2025-1168 and 2026-1359 as cross-appeals with one set of briefs, and confirmed the appellant's opening brief due February 20, 2026. Counsel of record: Paul D. Clement, Matthew D. Rowen, Jeffrey C. Thalhofer, and Kyle R. Eiswald (Clement & Murphy) for Centripetal; William F. Lee, Mark C. Fleming, Arthur W. Coviello, Laura E. Powell, and Harry Hanson for PAN.

Status as of April 26, 2026: Pending. No merits decision has issued. The docket is open, and briefing was to have commenced with an opening brief due February 20, 2026. This resolves the earlier-flagged uncertainty: the three CAFC dockets on the Google Patents family record (25-1167, 25-1168, 26-1359) are the Palo Alto Networks appeal from 2:21-cv-00137, and the '573 patent is within the patents adjudicated at trial.

5. Unresolved / unverified docket

Centripetal Networks, Inc. v. [unknown], No. 1:22-cv-00001 (E.D. Va.) — This case number appears in the Google Patents litigation metadata for US10659573B2, but I hit the search-step limit before I could confirm the parties, the patents asserted, or the outcome. Do not assume it involves the '573 patent on the strength of the family-level metadata alone; confirm on PACER/Justia before citing.

6. Matters that do NOT involve the '573 patent (flagged to prevent misattribution)

These are frequently bundled with Centripetal coverage and are sometimes conflated with the '573 docket:

• Centripetal Networks, Inc. v. Cisco Systems, Inc., No. 2:18-cv-00094-HCM-LRL (E.D. Va.) — Filed 2018, before the '573 issued (2020-05-19), and asserted the '193, '205, '370, '722, '856, '176-family patents. The $2.75B verdict (Oct. 5, 2020), the Fed. Cir. vacatur for Judge Morgan's stock conflict (Centripetal Networks, Inc. v. Cisco Sys., Inc., 38 F.4th 1025 (Fed. Cir. 2022)), and Judge Hanes's Dec. 2023/June 2024 non-infringement rulings on remand concern those patents — not the '573. The Law360 article retrieved (April 7, 2026) describes Federal Circuit argument in that Cisco non-infringement appeal; the three patents at issue are not the '573.
• Centripetal Networks, Inc. v. Keysight Technologies, Inc. and IXIA, No. 2:17-cv-00383-HCM-LRL (E.D. Va.) — 2017 filing, predates '573 issuance.
• ITC Inv. No. 337-TA-1314 — asserts '370, '917, '526 only.
• IPR2022-00182 / 2022-01151 / 2022-01199 — the CAFC decision in Nos. 2022-00182 etc. (including Centripetal Networks, LLC v. Palo Alto Networks, Inc., 156 F.4th 1368 (Fed. Cir. 2025), which remanded to a new PTAB panel per a March 17, 2026 Director order) involves the '856 patent (rule-based network-threat detection for encrypted communications), not the '573.

7. Related administrative proceedings on the '573 (not "litigation," but material)

1. IPR2021-01151, Palo Alto Networks, Inc. v. Centripetal Networks, Inc. (P.T.A.B.) — Filed July 20, 2021; challenged claims 1–24 under § 103. Institution DENIED Feb. 16, 2022. No Final Written Decision; no claims canceled; no § 315(e)(2) estoppel. PAN's mandamus petition challenging the Director-review regime was denied in In re Palo Alto Networks, Inc., No. 22-145 (Fed. Cir. Aug. 16, 2022).

2. Ex parte reexamination 90/019,563 — Request filed July 1, 2024; granted by the USPTO (Examiner Roland G. Foster, Art Unit 3992) with a substantial new question of patentability raised affecting claims 1 and 9 of the '573 patent. A transmittal form for this reexamination was filed into the 2:21-cv-00137 docket (ECF No. 993), indicating coordination with the litigation. The current status of the reexamination and the identity of the third-party requester are not verified in the material I retrieved.

8. Contradictions with the previously generated sections

Per instructions, flagging two items explicitly:

1. The earlier "Patent summary" section states that "News coverage (Law360, April 2026) reports that a Federal Circuit panel heard argument on April 7, 2026 and, around April 29, 2026, affirmed a Virginia district court finding that Cisco did not infringe a trio of Centripetal cybersecurity patents." Today's date is April 26, 2026, so an April 29, 2026 decision could not yet exist; the retrieved Law360 report (published April 7, 2026) describes argument only. Additionally, that Cisco appeal concerns the '193-family patents, not the '573. The earlier section's "plausible" mapping of 10659573 to that trio should be treated as incorrect/unverified.

2. The earlier sections described CAFC Nos. 25-1167, 25-1168, and 26-1359 as "whose specific subject matter I could not verify." That gap is now closed: all three are the Palo Alto Networks appeal/cross-appeal from E.D. Va. 2:21-cv-00137, consolidated on February 3, 2026, and they do involve the '573 patent. There is accordingly no Cisco involvement in the 25-1167/25-1168/26-1359 dockets.

Summary table

No other litigation involving US10659573 was found. No ITC investigation, no NPE/third-party assertion, and no counterclaim litigation by any defendant asserting the '573 independently.

Sources: Docket Alarm (E.D. Va. 2:21-cv-00137, 2:22-cv-00002); Justia dockets (1:21-cv-00313); RPX Empower litigation report ("Virginia Jury Returns $151.1M Verdict for Centripetal Networks"); Casetext / valawyersweekly copies of the Jan. 2, 2024 summary-judgment opinion; Centripetal's ITC complaint in Inv. No. 337-TA-1314; Docket Alarm copy of the CAFC reactivation order (ECF 1017) and UniCourt docket for 26-1359; Patexia summary for IPR2021-01151; Docket Alarm copy of the Order Granting Ex Parte Reexamination, Control No. 90/019,563; Google Patents family/litigation metadata for US10659573B2 (https://patents.google.com/patent/US10659573/en); Law360 (Apr. 7, 2026).

Recommended verification: Pull the PACER docket sheets for 2:21-cv-00137, 1:21-cv-00313, 2:22-cv-00002, and 1:22-cv-00001, and the unsealed version of ECF No. 970 in 2:21-cv-00137, to (a) confirm whether the partial JMOL disturbed the '573 verdict, (b) resolve the 1:21-cv-00313 relationship, and (c) identify the parties in 1:22-cv-00001.

The structured block says no AIA proceedings are on file via ODP, but web search is already surfacing IPR2021-01151. Let me verify its details and look for any other proceedings on this patent.

I have solid confirmation of IPR2021-01151. Now let me verify the Federal Circuit mandamus outcome and check whether any other IPR was instituted on this patent (e.g., by Cisco/Keysight).

I've reached the search limit, but I have enough verified material to answer. One important flag up front: the structured "PTAB proceedings on file" block (ODP) shows zero AIA proceedings — but web search independently verifies one proceeding, IPR2021-01151, which the Google Patents litigation metadata for this patent also lists ("filed (Not Instituted - Merits)"). Treating the ODP ingest as incomplete on this point.

Proceedings overview

Total: 1 AIA trial proceeding surfaced for US 10659573 — IPR2021-01151, denied institution on the merits (never instituted, no Final Written Decision, no claims canceled, no settlement). All 24 claims remain in force, and because the proceeding ended at the institution stage, no § 315(e)(2) estoppel attaches and no claim-level validity findings were made — which cuts both ways: the patent has not been merits-hardened, but the one full-frontal IPR (all 24 claims, best-available art) failed to clear the "reasonable likelihood" bar, making a repeat IPR with the same art a poor bet for a defendant.

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

• Type: Inter Partes Review
• Filed: 2021-07-20
• Status: Institution denied — PTAB metadata labels it "Not Instituted - Merits," i.e., the Board did not find a reasonable likelihood that petitioner would prevail on any challenged claim, and the proceeding was closed without trial.
• Judge panel: Administrative Patent Judges Aaron W. Moore, Bryan F. Moore, and Stacey G. White (secondary-source listings; Patexia attributes the institution decision to APJ Stacey G. White). Note: I could not retrieve the institution decision's own text to confirm the authoring judge — flagging as unverified.
• Petition grounds: Challenged claims 1–24 (the entire patent) under 35 U.S.C. § 103 only:
  • Ground 1: Claims 1, 7–9, 15–17, 23–24 obvious over Paxton (US 2014/0280778) + Sutton (US 8,413,238) in view of Deschenes (US 2013/0262655).
  • Ground 2: Claims 2, 10, 18 obvious over Paxton + Sutton + Deschenes + McDonald (EP 2482522).
  • Ground 3: Claims 3–6, 11–14, 19–22 obvious over Paxton + Sutton + Deschenes + Ivershen.
  • Petitioner's theory: Paxton taught correlating packets across a NAT boundary via log data (payload hashes, timestamps); Sutton supplied the responsive security-action limitations (malware identification, rule generation, administrator notification); Deschenes taught correlating encrypted traffic using unencrypted header/timestamp data; McDonald supplied rule-provisioned "taps"/packet selectors; Ivershen addressed the remaining dependent-claim limitations.
• Institution decision: Denied 2022-02-16. I could not pull the full decision text, so I will not paraphrase the panel's reasoning beyond the verified "denied" outcome and the "Merits" label indicating the denial was based on the merits rather than a discretionary (Fintiv-type) ground. The denial covered all 24 challenged claims; no ground was instituted.
• Final Written Decision: None. Institution was denied, so no trial and no FWD issued. No claims were canceled; all 24 claims of the '573 patent remain intact.
• Settlement / termination: No settlement. The proceeding terminated at institution denial (case closed 2022-02-16).
• Appeal: Palo Alto did not directly appeal the institution denial (institution decisions are final and non-appealable, 35 U.S.C. § 314(d)). Instead, PAN sought Director rehearing of the non-institution decision; the USPTO refused to accept such requests, and PAN petitioned the Federal Circuit for a writ of mandamus — In re Palo Alto Networks, Inc., No. 22-145 (Fed. Cir. 2022) (panel: Dyk, Chen; Reyna concurring), filed 2022-04-19, decision 2022-08-16 (CourtListener, opinion PDF). The Federal Circuit denied mandamus, holding (precedentially) that the Director's delegation of institution decisions to the PTAB and the USPTO's policy of refusing party-requested Director review of non-institution decisions do not violate the Appointments Clause. No further appellate relief resulted.
• Defensive value: Mixed but net-positive for the patent owner. A sophisticated petitioner (Palo Alto, with Ropes & Gray) threw its best § 103 combination at all 24 claims and did not clear the institution threshold — that is a meaningful signal that this patent is not an easy IPR target. But because there is no FWD, there is no estoppel and no claim-by-claim validity determination a defendant can point to; a defendant facing assertion today cannot cite IPR2021-01151 as having "validated" any claim.

Sources: Patexia docket summary, Ex Parte PTAB case summary, Finnegan PTAB Blog, Justia CAFC docket for 22-145.

Strategic summary

Claim status of US 10659573. All 24 claims (independent claims 1 and 15, plus dependents 2–14 and 16–24) are SUSTAINED — by default, not by merits finding. No claim has ever been canceled in an AIA trial because no AIA trial was ever instituted. The only AIA challenge on the '573 — IPR2021-01151 — was denied institution on the merits. So the correct characterization is: 0 claims canceled, 24 untested-by-FWD, with one failed institution attempt on the full claim set. That is a weaker statement than "hardened by a FWD," but it is still the outcome a defendant must live with: the Paxton/Sutton/Deschenes/McDonald/Ivershen art cluster has been vetted at the PTAB and lost at the threshold.

Estoppel landscape. Because IPR2021-01151 was denied institution and never reached a final written decision, no § 315(e)(2) estoppel attaches — to Palo Alto, its privies, or anyone else. A defendant is not barred from raising the Paxton/Sutton/Deschenes combination again in district court or in a new petition. In practical terms, though, the art is now battle-tested and known to be insufficient at the PTAB threshold; a rational defendant would bring different, stronger art (e.g., art that more directly teaches log-based correlation of encrypted packets with rule-driven taps and responsive security actions) rather than recycle the denied combination. Also note the current USPTO posture (Director Squires, effective 2025-10-20): institution decisions are Director-controlled, institution rates have collapsed, and proposed rules would categorically bar institution where claims have already been found valid or where parallel litigation would outpace the IPR — so new IPR filings on this patent face an unusually hostile institution environment.

Pattern signals. Only one petitioner (Palo Alto Networks) has challenged this patent at the PTAB, and it filed the companion PGR2021-00108 against the closely related continuation patent US 10,931,797 (also denied institution, also covered by the same 22-145 mandamus). Centripetal (now Centripetal Networks, LLC/Inc.) is an aggressive litigant — the patent's family docket shows multiple E.D. Va. cases (e.g., 2:21-cv-00137 v. Palo Alto; 1:21-cv-00313; 1:22-cv-00001; 2:22-cv-00002) and Federal Circuit dockets 25-1167, 25-1168, and 26-1359 whose specific subject matter I could not verify — and Centripetal has separately pursued ITC domestic-industry theories on family patents. Unified Patents appears in the Google Patents litigation metadata only as the data source for the IPR2021-01151 listing, not as petitioner — do not attribute the proceeding to Unified. There is no defensive-aggregator petition on this patent on the record I found.

Recommended next steps

1. If you are a defendant considering an IPR on the '573: The prior-art combination from IPR2021-01151 is a known loser at institution. Do not refile Paxton/Sutton/Deschenes. You need new art plus a Sotera-style stipulation and a plan to survive the post-October-2025 Director-controlled institution regime (which now favors denial where parallel litigation will reach validity first). Pull the actual institution decision (Paper 8, IPR2021-01151, P.T.A.B. Feb. 16, 2022) from PTAB E2E before drafting anything — my search could not retrieve its full reasoning, and the panel's specific claim-construction or motivation-to-combine findings are exactly what a new petition must distinguish.
2. If you are a defendant relying on this proceeding in district court: Be precise — there is no FWD to quote, and no claim was held patentable. The only citable artifacts are (a) the institution denial (persuasive only, and arguably protected from evidentiary use as a non-final agency action) and (b) the Federal Circuit's In re Palo Alto Networks, No. 22-145 decision, which is about the Appointments Clause and Director review, not about the merits of the '573. Frame any argument as "the strongest available § 103 combination failed to persuade the PTAB," not as "the claims were validated."
3. Monitor the family dockets: The CAFC appeals 25-1167, 25-1168, and 26-1359 on the '573 family's litigation record, and the district-court cases (2:21-cv-00137, 1:21-cv-00313, 1:22-cv-00001, 2:22-cv-00002), may produce validity rulings or settlements that matter more than PTAB activity. Also watch whether any new IPR petition is filed against the '573 under the Squires regime — with institution effectively at ~4% since October 2025, the absence of new petitions is itself consistent with the current environment rather than proof of the patent's strength.
4. On the ODP gap: The USPTO Open Data Portal ingest shows no AIA proceedings for this patent, which conflicts with the verified record of IPR2021-01151. If you are relying on ODP data in a filing, reconcile this discrepancy (e.g., cite the PTAB case directly) rather than asserting "no PTAB activity" — an opponent will find IPR2021-01151 in five minutes.

Inventors

All five named inventors on US 10659573B2 — David K. Ahn, Peter P. Geremia, Pierre Mallett III, Sean Moore, and Robert T. Perry — were employees/officers of Centripetal Networks, Inc. (the original assignee) at the time the underlying application (US 14/618,967, filed 2015-02-10) was filed. Sean Moore was Centripetal's CTO; David Ahn was a co-founder/VP-level engineer. The 2023-01-20 recorded assignment (see below) confirms all five executed an "assignment of assignors' interest" to Centripetal.

Unusual pattern check: not present. The inventors did not depart and trigger a portfolio fire-sale; Ahn and Moore in particular remained with Centripetal through its major assertion campaigns (Cisco, Palo Alto Networks) years after filing.

Original assignee

Centripetal Networks, Inc. (renamed Centripetal Networks, LLC, Portsmouth, New Hampshire; earlier Herndon, Virginia). The issued patent's Google Patents "original assignee" field reads "Centripetal Networks LLC" only because of the later Inc.→LLC name change; at filing and issuance the entity was Centripetal Networks, Inc.

• Products: Yes — Centripetal ships network-security appliances (RuleEngine, CleanINTERNET, CleanICS, packet-filtering/threat-intelligence gateways) that embody the packet-correlation/filtering technology of this family.
• Line of business: Cybersecurity / network security gateway vendor (also a high-frequency patent plaintiff against direct competitors).
• Current status: Operating. Centripetal Networks, LLC remains active and has asserted this patent in E.D. Va. litigation (e.g., Centripetal Networks, LLC v. Palo Alto Networks, Inc., 2:21-cv-00137, which names US10659573 among 14 asserted patents; IPR2021-01151 against the family was not instituted).

Assignment timeline

I could not pull correspondent-of-record data directly from the USPTO Assignment Center in this session; reel/frame entries below are sourced from the Google Patents legal-events data for this patent and its same-family sibling US10931797 (identical chain — US10659573 is a continuation of 15/413,947 → 14/714,207 → 14/618,967). Verify reel/frame and correspondent at https://assignmentcenter.uspto.gov/ before relying on this in a filing.

• 2013-03-12 (effective) / recorded per family record — Reel 034992/0949

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Sean Moore (inventor)
  • Assignee: Centripetal Networks, Inc. (Virginia)
  • Correspondent: not retrievable from available sources
  • Context: Inventor-to-company assignment of family assets (partial; the other four inventors' assignment to Centripetal was recorded 2023-01-20 per the patent text).

• 2017-04-17 recorded — Reel 042056/0098

  • Conveyance: Security Interest
  • Assignor: Centripetal Networks, Inc.
  • Assignee: Douglas A. Smith (Texas) — an individual taking a security interest in the portfolio
  • Correspondent: not retrievable from available sources
  • Context: Portfolio-level security interest, roughly two years before Centripetal's first large assertion campaign against Cisco — consistent with litigation funding/lending secured against the patents; no assignee-LLC change.

• Reel 048492/0499 (date not fully retrievable from snippet)

  • Conveyance: Release or related interest (Douglas A. Smith / Centripetal Networks, LLC, New Hampshire appear on the record)
  • Context: Appears to be the release/termination of the 2017 Smith security interest after the Inc.→LLC conversion.

• 2022-10-17 executed / 2023-01-20 recorded — Reel 062446/0660

  • Conveyance: Change of Name
  • Assignor: Centripetal Networks, Inc.
  • Assignee: Centripetal Networks, LLC (New Hampshire)
  • Correspondent: not retrievable from available sources
  • Context: Pure corporate name change / conversion; no change in beneficial ownership.

• 2023-01-20 recorded (reel/frame not shown in available data)

  • Conveyance: Assignment of Assignors' Interest (confirmatory/re-recorded)
  • Assignor: David K. Ahn, Peter P. Geremia, Pierre Mallett III, Sean Moore, Robert T. Perry
  • Assignee: Centripetal Networks, Inc.
  • Context: Re-recordation of the inventors' original assignment to the company (the underlying 2015-era assignment), coincident with the name-change recordation.

No assignment to any third-party LLC, holding company, or NPE appears anywhere in the chain. The patent has never left the operating company.

Timeline diagram

timeline
    title Ownership of US 10659573
    2015 : Filed by Centripetal Networks Inc
    2017 : Security interest to Douglas Smith
    2020 : Patent issued
    2021 : First suit vs Palo Alto Networks
    2022 : Name change executed
    2023 : Name change recorded
         : Inventor assignment re-recorded

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent moved only via inventor→company assignment and an Inc.→LLC name change (reel 062446/0660; recorded 2023-01-20). No licensing-only LLC, registered-agent address, or single-purpose entity ever held it.

2. Known asserter in the chain — not present. Centripetal Networks is not on the Unified Patents / RPX NPE directories; it is an operating security vendor. It is a high-frequency plaintiff (Cisco, Palo Alto Networks), but against direct competitors with shipped products, which is operating-company assertion, not NPE licensing.

3. Repeat correspondent across the chain — unclear. Correspondent-of-record data was not retrievable from the sources available this session; I cannot confirm or exclude a recurring attorney. This is the one gap in the record and should be checked at the Assignment Center.

4. Cascading transfers — not present. Only four substantive events over eight years (2013 inventor assignment, 2017 security interest, 2022/2023 release + name change), all within the same operating company or with a single individual secured party.

5. Pre-litigation transfer — not present. The first suit asserting this patent (Palo Alto Networks, 2:21-cv-00137) was filed 2021-03-12, ~10 months after issuance and before any of the 2022/2023 recordings. The 2017 security interest to Douglas A. Smith predates the first family suit (Cisco, 2019) by two years and did not change ownership. No transfer occurred within six months of any filing.

6. Bankruptcy fire-sale — not present. Centripetal has not filed bankruptcy; no estate-sale conveyances exist.

7. Privateering — not present. No SEC or press evidence that Centripetal asserts on behalf of a third party; it sues its own competitors over its own product technology (e.g., its $2.75B Cisco verdict, later vacated on appeal, and its Palo Alto Networks actions).

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at Centripetal Networks, LLC, an operating company — not RPX, AST, LOT, Unified, or OIN.

Verdict

Operating-company assertion.

The assignment record (reel 034992/0949; 042056/0098; 062446/0660; 2023-01-20 recordings) shows the patent never left the hands of Centripetal Networks, Inc./LLC — an active cybersecurity vendor that ships packet-filtering gateways embodying the claims and asserts this patent in E.D. Va. against direct competitors (Palo Alto Networks, Cisco). The only quasi-financial event is the 2017 security interest to individual Douglas A. Smith (reel 042056/0098), which is consistent with litigation funding rather than an ownership transfer and was later released. No shell LLC, no cascading chain, no pre-suit transfer to an NPE, and no defensive-aggregator terminus — the assertion pattern is a practicing competitor suing competitors.

Verify the full record (including correspondents) at the USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search by patent 10659573) or https://assignment.uspto.gov/patent/index.html.

I'll research the USPTO record and cited references for US 10659573.

Let me get the actual front-page references cited for US10659573 and the reexamination art.

Let me retrieve the actual front page of US10659573B2 to get its exact "References Cited" list.

1. Record verification — US 10659573 (searched literally, no substitutes)

I did not return results for any similar number (e.g., 10,659,572, 10,659,574, 10,595,573). The chain above is corroborated by the '573's own family members (e.g., US2021/0203761A1, which recites "16/554,293 … now Pat. No. 10,659,573" — https://www.docketalarm.com/cases/[PTAB](/ptab)/PGR2021-00108/Palo_Alto_Networks_Inc._v._Centripetal_Networks_Inc/docs/08-03-2021-Petitioner/Exhibit-1030-US20210203761A1_Ahn.pdf).

2. Sourcing limitation you must know before relying on this

I could not retrieve the '573's own front page (56) "References Cited" box. The authoritative Google Patents text supplied for this task truncates before the Citations section, and my searches returned (a) the front pages of sibling family patents that share the identical specification (US9,560,176; US10,530,903; US10,931,797 — the last being a direct continuation of the '573), and (b) Unified Patents' "Patent Art (284)" list compiled for patent 10659573 itself (https://portal.unifiedpatents.com/patents/patent/10659573). Because a continuation's IDS is ordinarily carried forward and the specifications are identical, this is a good proxy — but it is a proxy, not the '573 front page. Verify against the issued PDF (USPTO Patent Center, application 16/554,293) before filing anything.

Also flagged: several snippets are OCR-degraded and disagree across sources (e.g., 6,484,261 vs. 6,484,761; 7,152,240 vs. 7,152,260; 7,215,637 vs. 7,215,631 vs. 7,215,657; 7,237,267 vs. 7,237,262; 7,710,888 vs. 7,710,885). I reproduce them as found rather than silently correcting (per the no-auto-correct rule); treat the digits as unreliable where flagged.

3. The cited-art record — complete list as retrieved

3a. U.S. patent documents (issue date; inventor)

6,098,172 (8/2000, Coss) · 6,147,976 (11/2000, Shand) · 6,226,372 (5/2001, Beebe) · 6,279,113 (8/2001, Vaidya) · 6,317,837 (11/2001, Kenworthy) · 6,484,261 [OCR conflict] (11/2002, Wiegel) · 6,611,875 (8/2003, Chopra) · 6,662,235 (12/2003, Callis) · 6,678,827 (1/2004, Rothermel) · 6,826,694 (11/2004, Dutta) · 6,907,042 (6/2005, Oguchi) · 6,971,028 (11/2005, Lyle) · 7,089,581 (8/2006, Nagai) · 7,095,716 (9/2006, Ke) · 7,107,613 (9/2006, Chen) · 7,143,438 (11/2006, Coss) · 7,152,240 [conflict] (12/2006, Green) · 7,185,368 (2/2007, Copeland III) · 7,215,637 [conflict] (5/2007, Ferguson) · 7,225,269 (5/2007, Watanabe) · 7,227,842 (6/2007, Ji) · 7,237,267 [conflict] (6/2007, Rayes) · 7,263,099 (8/2007, Woo) · 7,296,288 (11/2007, Hill) · 7,299,353 (11/2007, Le Pennec) · 7,331,061 (2/2008, Ramsey) · 7,478,429 (1/2009, Lyon) · 7,499,412 (3/2009, Matityahu) · 7,539,186 (5/2009, Aerrabotu) · 7,610,626 (10/2009, Turley) · 7,684,060 (3/2010, Govindarajan) · 7,710,888 [conflict] (5/2010, Ilnicki) · 7,721,084 (5/2010, Salminen) · 7,792,775 (9/2010, Matsuda) · 7,814,158 (10/2010, Strayer) · 7,818,794 (10/2010, Wittman) · 7,849,502 (12/2010, Bouland — Cisco IronPort) · 7,913,303 (3/2011, Aaron) · 7,954,143 (5/2011, Aaron) · 8,004,994 (8/2011, Parisi) · 8,037,517 (10/2011, Fulp) · 8,117,655 (2/2012, Spielman) · 8,176,561 (5/2012, Hurst) · 8,306,594 (11/2012, Ann) · 8,495,725 [conflict] (7/2013, Adam) · 8,726,379 (5/2014, Stianen) · 8,806,638 (8/2014, Mani) · 8,856,926 (10/2014, Narayanaswamy) · 8,935,758 (1/2015, Pandrangi) · US 2017/0359449 A1 (12/2017)

3b. U.S. patent application publications — from the Unified Patents "Patent Art (284)" list for 10659573 (priority date shown)

US 2004/0093513 A1 (2002‑11‑06, HP/Trend Micro, Active Network Defense System and Method) · US 2003/0154399 A1 (2002‑02‑07, Juniper, Multi-method Gateway-based Network Security Systems and Methods) · US 2005/0251570 A1 (2002‑04‑17, Secerno, Intrusion Detection System) · US 2005/0141537 A1 (2003‑12‑28, Intel, Auto-learning of MAC Addresses…) · US 2006/0048142 A1 (2004‑09‑01, Enterasys, System and Method for Rapid Response Network Policy Implementation) · US 2006/0136987 A1 (2004‑12‑19, Fujitsu, Communication Apparatus) · US 2006/0133377 A1 (2004‑12‑21, Fortinet, Integrated Header, State, Rate and Content Anomaly Prevention with Policy Enforcement) · US 2007/0056038 A1 (2005‑09‑05, Lok Tech, Fusion Intrusion Protection System) · US 2007/0240208 A1 (2006‑04‑09, Zyxel, Network Appliance for Controlling HTTP Messages…) · US 2008/0201772 A1 (2007‑02‑14, Marvell Israel, Deep Packet Inspection for Network Intrusion Detection) · US 2012/0084866 A1 (2007‑06‑11, Columbia University, Methods, Systems, and Media for Measuring Computer Security) · US 2010/0211678 A1 (2000‑11‑27, Verizon, External Processor for a Distributed Network Access System) · US 2011/0055916 A1 (2009‑08‑27, Great Wall Systems, Adaptive Packet Filtering) · US 2013/0254766 A1 (2012‑03‑20, Microsoft, Offloading Packet Processing for Networking Device Virtualization) · US 2013/… Logging Attack Context Data (2013‑07‑23) · US 2014/0259170 A1 (2012‑08‑22, Raytheon Foreground Security/Nightwing, Internet Security Cyber Threat Reporting System and Method) · US 2015/0128274 A1 (2013‑11‑03, Crypteia Networks, Identifying Infected Networks and Systems from Unknown Attacks)

3c. Foreign patent documents

EP 1864226 B1 (2005‑03‑27, Wake Forest University, Methods, Systems, and Computer Program Products for Network Firewall Policy Optimization) · AU 2005328336 B2 (9/2011) · AU 2006230171 B2 (6/2012)

3d. Non-patent literature on the family front pages

Greenwald et al., Designing an Academic Firewall: Policy, Practice, and Experience With SURF, SNDSS '96, IEEE, Stanford (1996) · J. Xu et al., Design and Evaluation of a High-Performance ATM Firewall Switch and Its Applications, IEEE JSAC 17(6):1190–1200 (June 1999) · A. Feldmann et al., Tradeoffs for Packet Classification, IEEE INFOCOM (2000) · A. Hari et al., Detecting and Resolving Packet Filter Conflicts, IEEE INFOCOM (2000) · Acharya et al., OPTWALL: A Hierarchical Traffic-Aware Firewall (2007) · Benecke, A Parallel Packet Screen for High Speed Networks (1999) · Blake et al., RFC 2475 (Diffserv, Dec. 1998) · Bellion, High Performance Packet Classification (undated) · Chen et al., Research on the Anomaly Discovering Algorithm of the Packet Filtering Rule Sets (2010)

Correction to a likely mis-attribution risk: An IDS exhibit I found (IPR2021‑01521, Ex. 2026) lists the '573 in its continuity chain but also cites a 2016 DomainTools report and May‑2019 Office Actions. Because those post-date the '573's 2019 filing and relate to a later continuation (17/177,572 → US11,683,401), do not attribute the DomainTools report or the 2019 Office Actions to the '573's prosecution record.

4. Analysis of the most relevant cited references and their § 102 exposure

Reminder of the § 102 standard: anticipation requires a single reference disclosing every limitation, arranged as claimed. None of the references below appears, on the record I can see, to disclose the full independent-claim combination (identify received packets → log → identify transmitted encrypted packets → log → correlate on the logs → responsive rule generation and provisioning of a packet-filtering device). So my § 102 ratings are, in most cases, limitation-level rather than claim-level.

4.1 US 8,219,675 B2 — System and Method for Correlating IP Flows Across Network Address Translation Firewalls (Netscout Systems Texas; priority 2009‑12‑10)

Closest art on the correlation concept: it correlates flow records on both sides of a NAT boundary. § 102 exposure: real but incomplete. It maps well onto the "identify received packets / identify transmitted packets / correlate based on log entries" cluster, and would be a serious § 102 threat if a single one of claims 1/9/17 were drafted without the encrypted-packet and the responsive-rule-provisioning steps — but those steps are present in the independent claims as I have them. Expect § 103, not § 102. (Note: this is the same reference the IPR petitioner called "Ivershen.")

4.2 US 7,721,084 B2 — Firewall for Filtering Tunneled Data Packets (Salminen; priority 2001‑11‑28)

Teaches inspecting and filtering encapsulated/tunneled (hence encrypted) packets at a firewall — directly on point for the "encrypted packets transmitted by the network device" and "data encapsulated in the packets" limitations. § 102 exposure: dependent-claim level. It is arguably anticipating as to any dependent claim reciting only tunneled/encapsulated-packet handling, but it does not disclose correlating two log sets.

4.3 US 7,849,502 B1 — Apparatus for Monitoring Network Traffic (Bouland, Cisco IronPort; priority 2006‑04‑28)

Rule-based identification/monitoring and logging of network traffic. § 102 exposure: low on its own (no transmit-side correlation), useful for the log-generation and rule-criteria limitations.

4.4 US 2015/0128274 A1 — Identifying Infected Networks and Systems from Unknown Attacks (Crypteia Networks; priority 2013‑11‑03) and US 2014/0259170 A1 — Internet Security Cyber Threat Reporting System and Method (Raytheon Foreground Security/Nightwing; priority 2012‑08‑22)

Both address identifying a malicious/compromised endpoint and reporting/threat-notification. § 102 exposure: these are the best candidates for the malicious-host determination and message identifying the first-network host limitations. If those limitations sit in an independent claim (the earlier section suggests a claim adding "determining the second-network host is malicious" and a further claim adding "generating a message identifying the first-network host"), neither reference is anticipating of the independent claim as a whole, but either could anticipate a claim drawn narrowly to the alerting step alone.

4.5 US 2004/0093513 A1 — Active Network Defense System and Method (HP/Trend Micro; priority 2002‑11‑06)

Responsive rule generation and drop-on-detection. § 102 exposure: dependent-claim level for the "generate rules … and provision a packet-filtering device" step; not anticipating of the correlation steps.

4.6 US 2006/0048142 A1 — System and Method for Rapid Response Network Policy Implementation (Enterasys; priority 2004‑09‑01) and US 2011/0055916 A1 — Adaptive Packet Filtering (Great Wall Systems; priority 2009‑08‑27)

Rapid policy/rule distribution to network enforcement points and adaptive rule sets — support the provisioning limitation. § 102 exposure: low-to-moderate at limitation level only.

4.7 US 2003/0154399 A1 — Multi-method Gateway-based Network Security Systems and Methods (Juniper; priority 2002‑02‑07) and US 2006/0133377 A1 — Integrated Header, State, Rate and Content Anomaly Prevention with Policy Enforcement (Fortinet; priority 2004‑12‑21)

Gateway security with header/state/content inspection and policy enforcement — background art for the network-device/gateway context. § 102 exposure: none for the independent claims.

4.8 US 8,842,391 B2 — Method, Media Gateway and Media Gateway Controller for Maintaining NAT Address Mapping Table (IP Edge; priority 2008‑04‑02) and EP 1864226 B1 (Wake Forest; priority 2005‑03‑27)

NAT mapping maintenance and firewall-policy optimization, respectively — the "network device alters the packets (NAT)" and "rule/policy" context. § 102 exposure: none at claim level.

Not on the face of the patent but in the same family's IPR record (worth noting because they are the strongest art actually assembled against the '573): US 2014/0280778 A1 (Paxton), US 8,413,238 B2 (Sutton), US 2013/0262655 A1 (Deschenes), EP 2 482 522 A1 (McDonald) — asserted in IPR2021‑01151, denied institution 2022‑02‑16. Of these, only the Netscout reference (US 8,219,675) appears in the patent's own cited-art list.

5. § 102 bottom line by claim group

No cited reference in the record I retrieved appears to anticipate any independent claim of US 10,659,573 under § 102. The cited art's realistic value is evidentiary for § 103 (combinations), which is consistent with the fact that the only PTAB challenge was pleaded entirely under § 103 and was denied institution.

6. Contradictions and gaps flagged

1. Claim-numbering conflict between the earlier generated sections. The Patent-summary section says the independent claims are 1, 9, and 17 (method / computing device / media) and separately says "all 24 claims (independent claims 1 and 15, plus dependents 2–14 and 16–24)." These cannot both be right. The parent US10,530,903 has 18 claims. Treat all claim numbers in this analysis as unverified; I have described claims by feature to avoid compounding the error.
2. Sourcing gap (material). I did not obtain the '573's own (56) box. Everything in § 3 is from sibling front pages sharing the specification and from the Unified Patents "Patent Art (284)" compilation for patent 10659573 itself (https://portal.unifiedpatents.com/patents/patent/10659573). A reference appearing in the Unified list is of-record art; a reference appearing only in a sibling's front page may or may not be on the '573.
3. Reexamination art not retrieved. Ex parte reexamination 90/019,563 (request filed 2024‑07‑01) was granted with a SNQ affecting claims 1 and 9, Art Unit 3992, Examiner Roland G. Foster — but the order's relied-upon references are in an attachment ("See the Decision") that I could not retrieve (https://www.docketalarm.com/cases/Virginia_Eastern_District_Court/2--21-cv-00137/Centripetal_Networks_Inc._v._Palo_Alto_Networks_Inc/docs/993/5.pdf). Because the order states the SNQ must be based on new, non-cumulative technological teaching, the reexamination art is by definition not the cited art analysed above — and is therefore the most important prior art to identify next.
4. ODP/PTAB conflict already noted in the earlier PTAB section: the structured ODP ingest shows zero AIA proceedings while IPR2021‑01151 is verified.

7. What to pull next (in priority order)

1. The '573 issued PDF front page and PTO‑892/PTO/SB/08 forms — USPTO Patent Center, application 16/554,293.
2. The reexamination order's attachment (references relied upon) in 90/019,563 — this is the only art the Office has affirmatively found to raise a new patentability question on claims 1 and 9.
3. The IPR2021‑01151 petition exhibits (Ex. 1004 Paxton, 1005 Ivershen, 1007 Sutton, 1008 Deschenes, 1009 McDonald) and Paper 8 (institution denial) for the Board's specific reasoning.

I'll research the prior art record for US10659573B2. The provided patent text truncates before the claims and citations sections, so I need to locate the prosecution's cited references and any IPR petition art.

The Unified Patents portal shows a "Patent Art (284)" list for US10659573B2, including US8219675B2 (Netscout — correlating IP flows across NAT firewalls) and US7721084B2 (firewall for filtering tunneled data packets). Let me dig deeper into that cited-art list and the IPR petition.

Excellent — I've found the key proceedings: IPR2021-01151 (Palo Alto Networks challenged all claims 1–24 with a detailed obviousness petition) and an ex parte reexamination (90/019,563) that was granted in 2024 raising a substantial new question of patentability on claims 1 and 9. Let me verify the identities of the primary references and get the reexamination's relied-upon art.

I have enough from the record to deliver the analysis. Note up front: the provided patent text truncated before the claims and the "Citations" (prior art) sections, so I pulled the prior-art record from the USPTO/PTAB and litigation record instead — specifically (a) the cited-art list for US10659573B2 on the Unified Patents portal, (b) the IPR2021-01151 petition (Palo Alto Networks v. Centripetal Networks), which challenged all 24 claims on §103 grounds and contains an element-by-element claim chart, and (c) the order granting ex parte reexamination 90/019,563 (July 2024 request) raising a substantial new question of patentability as to claims 1 and 9. Caveats on what I could not verify are flagged inline.

Obviousness Analysis — U.S. Patent 10,659,573 (US10659573B2) under 35 U.S.C. § 103

1. Legal frame and claim scope

The patent is AIA-governed (earliest priority date Feb. 10, 2015; the reexamination notice confirms AIA/FITF status), so § 103 as amended by the AIA applies. All references discussed below published/issued well before the priority date and are § 102(a)(1)/(2) prior art.

Based on the IPR2021-01151 petition's claim chart (which quotes the granted claims, unlike the published application I summarized earlier), independent claim 1 requires, in substance:

1. identifying a plurality of packets received by a network device from a host in a first network;
2. generating a first plurality of log entries corresponding to those received packets;
3. identifying a plurality of encrypted packets transmitted by the network device toward a host in a second network;
4. generating a second plurality of log entries for those transmitted encrypted packets;
5. correlating the transmitted encrypted packets with the received packets based on the two sets of log entries; and
6. responsive to the correlating, generating one or more rules configured to identify packets received from the first-network host, and provisioning a packet-filtering device with those rules.

System/media counterparts are claims 9 and 17. Dependent claims add: provisioning first/second taps with rules (claims 2, 10, 18); correlation techniques using ports/interface IDs/timestamps/encapsulated data (claims 3–6, 11–14, 19–22); determining the second-network host is malicious and generating messages identifying the first-network host (claims 15–16); etc.

2. Primary prior art references

Paxton (US 2014/0280778 A1) — A packet-correlation system that places "inside" and "outside" sensors on either side of a network boundary (e.g., a NAT or gateway), logs packets from both sides (payload hashes, timestamps, source addresses), and matches them to attribute packets to their true origin. The petition quotes: "The combination of identifiable inside and outside header data can serve as the identity of the packet" (¶22); matching MD5 payload hashes with inside/outside arrival times (¶23, Fig. 2); and "the ability to identify the true source of packet transmission through a boundary can provide significant benefits to network security… identify nodes that are infected with malicious content… attribution of malicious activity sensed at the edge of a network back to its original source" (¶30). Paxton expressly notes its system is "highly modular" and built on commodity hardware.

Sutton (US 8,413,238 B2) — A network-security system that monitors communications, identifies malicious activity (e.g., communications with darknet addresses), generates filtering/blocking rules, and provisions network devices to enforce them, with administrator/user notifications.

Deschenes (US 2013/0262655 A1) — Teaches analyzing/correlating encrypted traffic using unencrypted information (timestamps, TCP/IP-level header data) when payloads are unreadable — the gap-filler for the "encrypted packets" limitation of the independent claims.

Ivershen (US 8,219,675 B2, Netscout) — "System and Method for Correlating IP Flows Across Network Address Translation Firewalls"; correlates flows on both sides of a NAT firewall using flow records. (This is the same reference as US8219675B2 in the cited-art list; the petition identifies Ivershen = US 8,219,675.)

McDonald (EP 2 482 522 A1) — A correlation system using "packet selectors" (taps) on either side of a NAT, programmed with rules/selection criteria (e.g., TCP flags) to select a subset of packets for correlation — the gap-filler for the rule-provisioned tap limitations.

3. The IPR2021-01151 grounds — the primary § 103 combinations

The Palo Alto Networks petition (filed July 20, 2021; challenged claims 1–24) asserted three grounds, all under § 103:

Ground 1 — Paxton + Sutton + Deschenes

Element mapping (summary):

• Received-packet identification and first log entries: Paxton's inside sensor identifies packets received at the boundary device and logs them (payload hash, timestamp, SrcAddr).
• Transmitted encrypted-packet identification and second log entries: Paxton's outside sensor logs the corresponding outbound packets; Deschenes supplies the explicit teaching that the outbound packets may be encrypted and can still be identified and correlated via unencrypted header/timestamp data.
• Correlation: Paxton's matching of inside/outside hashes, timestamps, and header data (¶¶22–25) is exactly the claimed log-based correlation; Paxton even describes multi-packet correlation (Fig. 3).
• Responsive rule generation and provisioning: Paxton identifies infected nodes and attributes malicious activity to the true source but "leaves specific usage and remedial steps to a POSITA." Sutton supplies those steps: generating rules to identify/block further traffic from the offending first-network host, provisioning filtering devices, and notifying users/admins.

Why a POSITA would combine them: The references are in the same field (network security and traffic attribution) and solve complementary parts of one problem. Paxton is expressly designed to be "highly modular" and to be a "stable foundation for building tiered enterprise network architectures with an inherent capability for attribution of malicious activity" (¶30) — an invitation to add standard response components. A POSITA who detected malicious activity via Paxton's correlation would naturally add Sutton's well-known remedial rule-generation/provisioning to complete the security workflow, and would apply Deschenes's known technique for handling encrypted traffic because encryption was the ordinary, predictable state of enterprise traffic by 2015 (TLS everywhere). The result is the combination of known elements, each performing its known function, with predictable results — the classic KSR v. Teleflex situation.

Ground 2 — + McDonald (claims 2, 10, 18)

Claims 2/10/18 add first and second tap devices provisioned with rules to identify the received and transmitted packets respectively. Paxton's inside/outside sensors act as taps, but the petition argued that to the extent Paxton doesn't explicitly disclose provisioning the taps with selection rules, McDonald does: McDonald's "packet selectors" on either side of a NAT are explicitly programmed with selection criteria (e.g., packets with certain TCP flags) to pick a subset for correlation.

Motivation: Both Paxton and McDonald recognize that capturing/analyzing all traffic on high-bandwidth links is resource-intensive; McDonald's rule-based pre-filtering is a known performance technique. A POSITA seeking to scale Paxton's correlation to high-throughput enterprise links would adopt McDonald's rule-programmed selectors as a predictable efficiency improvement. This is a textbook combination of a known monitoring system with a known filtering mechanism to solve a known performance problem.

Ground 3 — + Ivershen (claims 3–6, 11–14, 19–22)

The dependent claims in this group recite specific correlation features — comparing ports, network-interface identifiers, timestamps (receipt vs. transmission), and encapsulated/request payload data. Ivershen (Netscout) discloses correlating IP flows across a NAT firewall using flow records, including transport-layer data and timing, which the petition used to fill any gaps in Paxton's correlation detail.

Motivation: Ivershen and Paxton are both flow-correlation-across-NAT systems; combining them is combining analogous references in the same art to supply implementation detail (e.g., which header fields and timing data to compare). A POSITA would consult Ivershen as the standard reference for NAT-flow correlation and would expect success because both systems use the same underlying approach (matching inside/outside records by header and timing data).

4. Additional combinations supported by the cited-art record

Beyond the IPR grounds, the 284-reference cited-art list on the Unified Patents record provides further obviousness building blocks that a challenger could deploy for specific limitations:

• Ivershen (US8219675B2) as a primary reference with Paxton — both are "correlate flows across a NAT/firewall" systems; a § 103 challenge could run Ivershen as the primary reference for the correlation steps and Paxton for the malicious-attribution/response context. This is a particularly strong pairing because Ivershen is earlier (filed Dec. 2009; issued 2012) and squarely on point.
• US 7,721,084 B2 ("Firewall for Filtering Tunneled Data Packets") — teaches inspecting/filtering encapsulated (tunneled) packets, supporting the "encrypted packets transmitted" and "data encapsulated in packets" dependent limitations (claims corresponding to the VPN/tunneling-gateway embodiment in the specification).
• US 7,849,502 B1 (Cisco IronPort, "Apparatus for Monitoring Network Traffic") and US 2006/0133377 A1 (Fortinet, integrated header/state/content anomaly prevention) — both teach rule-based identification and logging of network traffic, supporting the tap-provisioning and log-generation steps.
• US 2015/0128274 A1 (Crypteia, "Identifying Infected Networks and Systems from Unknown Attacks") and US 2014/0259170 A1 (Raytheon, cyber-threat reporting) — support the malicious-host determination, message generation, and notification steps (claims 15–16).
• US 2004/0093513 A1 (HP/Trend Micro, "Active Network Defense") — teaches responsive rule generation and packet dropping upon detection, corroborating Sutton's role in Ground 1.

A challenger could, for example, reformulate Ground 1 as Ivershen (primary) + Paxton + Sutton + Deschenes, or Paxton + Ivershen + US7721084B2 for the tunneled/encrypted-packet claims. None of these combinations requires any non-obvious reordering; they all use the references for their same-field, same-purpose teachings.

5. Motivation-to-combine analysis under KSR (summary)

Under KSR, obviousness can be shown by combining prior-art elements according to known methods, with predictable results, where a POSITA has a reason to combine. Here, for each pairing:

1. Same field / same problem: All primary references address network-traffic monitoring, flow/NAT correlation, or network security response. The patent's own Background concedes the problem (middleboxes obfuscating flow association) was a known one.
2. Complementary teachings: Paxton/Ivershen/McDonald/Deschenes cover detection and correlation (including encrypted traffic); Sutton covers response (rule generation + provisioning); each reference expressly leaves room for or invites the others' contributions (Paxton ¶30's modularity and its silence on remedial steps; McDonald's and Paxton's shared concern about capture cost).
3. Predictability: Correlating logs from two sides of a boundary device and then applying filtering rules to the attributed source were routine techniques. The "encrypted packets" limitation is not inventive — Deschenes shows it was known to correlate encrypted packets via timestamps/header data, and the specification's own embodiments (NAT, proxy, VPN gateway) are all standard middlebox functions.
4. No teaching away / no unexpected results: Nothing in the record suggests any reference teaches away from combining; the petition's expert declaration (Ex. 1003, Dr. Akl) mapped every claim element to the combination.

6. Countervailing considerations (be fair to the patent)

• Institution was denied in IPR2021-01151 (decision Feb. 16, 2022). The Board did not find a reasonable likelihood that the petitioner would prevail. This is not a merits holding of validity, but it is the only PTAB merits-adjacent outcome on these exact grounds, and any serious § 103 analysis must acknowledge it. The denial could reflect the Board's view that the petition's Paxton/Sutton/Deschenes mapping was deficient on specific limitations (e.g., the "encrypted packets" or "provisioning a packet-filtering device" steps), not that the claims are non-obvious as a matter of law.
• Ex parte reexamination 90/019,563 was granted (request filed July 1, 2024; order granting reexamination issued thereafter, Art Unit 3992, examiner Roland G. Foster), with the Office finding a substantial new question of patentability affecting claims 1 and 9 based on new, non-cumulative art. That means the Office itself believed at least one reference (or a new combination) from the request raised a real § 102/103 question on the independent claims. I could not retrieve the reexamination order's specific reference list from my searches, so I cannot name the art it relied on — but the grant is itself significant objective evidence that the independent claims are vulnerable under § 103.
• Secondary considerations: Centripetal could argue commercial success/licensing (it asserted the patent against Cisco and Palo Alto Networks) and long-felt need. But based on the Federal Circuit's treatment of Centripetal's RuleGATE secondary-indicia evidence in the related 9,124,552/9,160,713 litigation (rejecting industry-praise/commercial-success arguments for lack of nexus), courts in this family have been skeptical of such evidence unless it maps specifically to the claimed features. The patent-in-suit claims only the correlation + rule-provisioning method, not the full product.
• Litigation backdrop: The patent was asserted in E.D. Va. cases 2:21-cv-00137 and 1:21-cv-00313 (and 2022 cases), with related CAFC appeals (25-1167, 25-1168, 26-1359). A 2026 Federal Circuit decision affirmed a finding that Cisco did not infringe a Centripetal patent trio; I could not verify whether '573 was among them. The 2026 PTAB finding that a Centripetal Cisco-related patent was obvious (on remand) is also not confirmed to be this patent.

7. Conclusion

The strongest § 103 case against US10659573B2 is the IPR2021-01151 combination set: Paxton + Sutton + Deschenes for the independent claims (1, 9, 17) and their security-response dependents, + McDonald for the rule-provisioned tap claims, and + Ivershen for the correlation-detail dependents. The motivation-to-combine story is strong under KSR because the references are same-field, complementary, and — per Paxton's own disclosure — explicitly modular and aimed at a complete attribution-and-response security solution, with Deschenes supplying the routine handling of encrypted traffic. Supporting combinations from the cited-art record (Ivershen as primary; US7721084B2 for tunneled packets; Sutton/HP-Trend Micro for responsive rules; Crypteia/Raytheon for alerting) reinforce the conclusion.

Two caveats govern the confidence level of any invalidity conclusion: (1) the PTAB declined to institute IPR2021-01151, so these exact grounds have never been adjudicated on the merits; and (2) the granted ex parte reexamination (90/019,563) — whose relied-upon references I could not retrieve — indicates the independent claims face an active, Office-recognized patentability question as of the 2024–2026 timeframe. If the reexamination ultimately confirms obviousness of claims 1 and 9 over its new art, that would be the most authoritative § 103 determination available. For a definitive element-by-element chart, pull the IPR petition exhibits (Ex. 1004 Paxton, 1007 Sutton, 1008 Deschenes, 1005 Ivershen, 1009 McDonald) and the reexamination order from USPTO Patent Center/PTAB.