US 7454792

I'll verify this against live sources before summarizing.

Let me run additional targeted searches on litigation and the Federal Circuit docket.

One more check for PTAB proceedings or asserted-case dockets.

US 7,454,792 B2 — Verification Summary

Record identification (from the authoritative patent text; IDs interpreted literally)

Provenance: The '792 patent is a divisional of 10/291,095, filed 2002-11-07 (which issued as US 7,454,499 B2), and its sibling divisional 10/930,392 issued as US 7,451,489 B2. Foreign family members include EP1558937B1, JP2006506853A, KR101111433B1, CN100443910C, AR042020A1, AU2003290674A1, and WO2004045126A2.

Assignment chain (per Google Patents reassignment records): 3COM CORPORATION → TippingPoint Technologies, Inc. (2008-05-29) → Hewlett-Packard Company (2010-07-06) → Hewlett-Packard Development Company, L.P. (2010-07-30) → Hewlett Packard Enterprise Development LP (2015) → Trend Micro Incorporated (2016-08-23). Note: the 2008 TippingPoint entry is recorded with 3Com as assignor, and the "current assignee" field carries both Trend Micro Inc. and HP Inc. — I am reporting these as listed rather than reconstructing the true chain.

Abstract (as published)

An active network defense system that monitors and blocks traffic in an automated fashion, placed in-line with the packet traffic data flow as part of the network infrastructure so that every passing packet can be inspected and manipulated. An algorithmic filtering operation applies statistical threshold filtering to the data flow to identify threats existing across multiple sessions; a trigger filtering operation applies header and content match filtering to identify threats within individual sessions. Threatening packet traffic is blocked and threatening sessions are terminated. Suspicious traffic is extracted from the data flow for further examination with more comprehensive content matching plus asset risk analysis. A flow control mechanism controls the passage rate for packets through the data flow.

Independent claims — plain language

The grant contains four independent claims: 1 and 15 (system), 8 and 19 (method).

Claim 1 — Normalizing packet filter (system). A normalizer sits in-line in the packet data flow, examines each received packet against a particular implementation of a protocol or standard, detects packets that do not adhere to that implementation, and modifies those packets to enforce adherence — outputting a normalized data flow. A packet handler, also in-line with the normalized flow, determines whether packets are "of interest" and blocks those from entering a protected network. (In short: in-line protocol/standard conformance enforcement plus a gatekeeper that drops packets.)

Claim 8 — Method version of claim 1. The same three steps: normalizing (detect non-adherence + modify to enforce adherence, producing a normalized flow), determining whether packets in the normalized flow are of interest, and blocking those determined packets from entering the protected network.

Claim 15 — Extraction + second-tier filter + asset-aware risk assessor (system). A trigger filter examines each packet against a first set of filtering criteria to sort traffic into good, bad, and suspicious packets, with the suspicious packets extracted from the data flow. A filter then compares the extracted suspicious packets against a second set of filtering criteria — where the second criteria include an identification of the network assets threatened by certain suspicious traffic — and identifies certain suspicious packets for further investigation. A risk assessor examines those identified packets against the threatened-asset identification and issues an alert only if the protected network actually contains at least one of the threatened assets. (In short: two-stage screening where the second stage is asset/vulnerability-aware.)

Claim 19 — Method version of claim 15. Examines each packet against a first criteria set (good/bad/suspicious), extracts suspicious packets, defines a second criteria set including an identification of threatened network assets, examines the extracted suspicious packets against it, assesses risk against the threatened-asset identification, and issues the alert when the protected network includes at least one threatened asset.

Selected dependents: claims 2/9 (fragment reassembly enforcement), 5/12 (decode encoded — e.g., hex/Unicode — packets), 3–4/6–7/10–11/13–14 (trigger filter detects threat in reassembled/decoded packet; handler blocks packet or terminates session), 16/20–21 (asset database; compares threatened assets and their characteristics against stored asset list), 17/22 (packet handler drops bad traffic, admits good traffic, passes suspicious packets up), 18/23 (returns non-threatening suspicious packets back to the flow).

⚠️ Literal-text caution: Claim 22 as rendered on Google Patents recites "(b) allowing entry of the good Waffle packets into the protected network." Read literally, the claim contains that term; it is almost certainly an OCR/transcription artifact for "good traffic packets" (compare claim 17). I am flagging it rather than silently correcting it, and the authoritative USPTO grant document should be checked before relying on claim 22's exact wording.

Litigation / docket check — US 7,454,792

• I found no Federal Circuit appeal, and specifically no CAFC 2026 docket, naming US 7,454,792. I could not confirm any appellate activity for this patent.
• The only litigation-related hit located is not a suit asserting the '792 patent: in Centripetal Networks, Inc. v. Keysight Technologies, Inc. and Ixia, E.D. Va. No. 2:17-cv-00383-HCM, the defendants' Identification of Prior Art (dated July 5, 2018) lists "7,454,792 (Cantrell)" among prior-art references, alongside TippingPoint Unity One 200 and its manual (see https://www.docketalarm.com/cases/PTAB/IPR2022-01199/... and the mirrored exhibits). In other words, the '792 patent appears in that record as cited prior art, not as an asserted patent.
• The number also appears only incidentally in USPTO petition/prosecution search-string dumps (e.g., ptacts.uspto.gov petition 1558605 document).
• Consistent with the status field, the patent expired 2024-01-09 ("Expired – Lifetime"), so it could not have been asserted in a 2026 action; any 2026 docket appearance would have to be historical (e.g., an appeal of a long-pending case) rather than a new assertion.
• No PTAB IPR, PGR, or reexamination record for 7,454,792 surfaced in my searches. I cannot rule one out, but I found no evidence of one.

Uncertainties I want to be explicit about

1. I did not directly query PACER, the CAFC's own docket system, or USPTO PatentCenter/PTAB APIs — my litigation and PTAB conclusions rest on web-indexed documents, so a 2026 CAFC docket entry could exist that I did not surface. Treat "no CAFC 2026 activity found" as not located, not as proven absent.
2. There is a claim-set discrepancy across the family record: the Justia rendering of publication US2005/0028013 (https://patents.justia.com/patent/20050028013) shows claims numbered 40–49 (e.g., claim 40 "normalizer… enforce conformance to certain predefined standards"), which are broader than granted claims 1–23, while Justia's page for the granted patent (https://patents.justia.com/patent/7454792) shows claims 1–23 matching the grant. I attribute this to claim amendment during prosecution and/or to how the family's publications are indexed, but I have not verified which document those 40–49 claims belong to.
3. The "current assignee" display (Trend Micro Inc. and HP Inc.) is Google's own disclaimer-laden field; the recorded 2016 assignment to Trend Micro Incorporated appears to be the last link in the chain, but I did not verify present ownership from USPTO Assignment records directly.
4. All bibliographic values above come from the supplied patent text (Google Patents) and are internally consistent; the abstract and claim language quoted are from that record.

I'll search for litigation involving US patent 7454792.

Let me search more targeted litigation sources.

Let me try a few more targeted searches.

Summary of Findings: Litigation Involving US Patent 7,454,792

Bottom line: I could not identify any litigation — district court, Federal Circuit, ITC, or PTAB — specifically asserting or challenging US Patent No. 7,454,792. Based on the searches I was able to run, no case appears to have this patent named as a patent-in-suit.

What the patent is (for identification purposes)

To be clear that I'm looking at the correct patent and not a similar number:

Litigation search results

• No district court cases (PACER) naming US 7,454,792 as a patent-in-suit were surfaced.
• No Federal Circuit appeals involving this patent were surfaced.
• No PTAB proceedings (IPR/PGR/CBM) challenging this patent were surfaced.
• No ITC Section 337 investigations were surfaced.

Important caveat on a search "hit" you may encounter

A web search for the string "7454792" returns a CourtListener hit in Robert Weissman v. Clearview AI, Inc. (7th Cir., No. 25-1673). This is a false positive. Interpreting the identifier literally: [7454792] there is the CM/ECF docket-entry number on the Seventh Circuit docket (document #24-1, entered 05/28/2025), not US Patent 7,454,792. It has nothing to do with this patent. Similarly, a Brazilian state commercial-registry filing (SINREM/JUCEC) shows an unrelated company "ALINE BORGES DIAS LTDA" bearing registration number 7454792 — also unrelated.

Why the absence is plausible

This patent is a hardware/software network-intrusion-defense patent owned first by TippingPoint, then passed through Hewlett-Packard (3Com → HP → HPE) and finally to Trend Micro (2016 assignments). It expired in January 2024. TippingPoint's patents were generally used defensively/portfolio-wise rather than in a high-volume assertion campaign, and the family here is more of a defensive portfolio asset than a known PAE-litigation vehicle. That is consistent with — though not proof of — the absence of litigation.

Honest limitations

I want to be explicit about what I could and could not verify, rather than overstate:

1. I could not directly query the Unified Patents litigation portal, PACER, or Docket Navigator for this specific patent number in structured form during this session — my tool access returned general web results, not a structured case list filtered to the exact patent. The searches did not surface any case, but a negative web-search result is weaker evidence than a direct PACER/Docket Navigator report.
2. A definitive negative would require running the exact number in:
   • PACER / CourtListener RECAP (party and patent-number search),
   • Unified Patents Portal – Litigation caselist (https://portal.unifiedpatents.com/litigation/caselist) and PTAB caselist,
   • Docket Navigator and RPX Insight,
   • USPTO Patent Center / Assignment and the patent's "Litigation" tab.
3. It is also possible any assertion occurred but settled or was dismissed pre-service with minimal public docket footprint, or was litigated only on the foreign counterparts (EP1558937, KR101111433, CN100443910, JP2006506853) where I found no evidence of proceedings either.

Recommendation

If you need a certified negative for a clearance, invalidity, or diligence opinion, I'd recommend I (or you) run the exact number 7,454,792 (and its family members 7,454,499 and 7,451,489) through PACER/Docket Navigator and the Unified Patents Portal directly, since this patent's family is the more likely litigation target than the '792 patent alone. Based on the information available to me now, however, the answer is that no litigation is known involving US Patent 7,454,792.

I'll research this systematically. Let me start with searches on the patent number and PTAB proceedings.

Proceedings overview

Total AIA trial proceedings on US 7,454,792: 0. The structured USPTO Open Data Portal "PTAB proceedings on file" block for this patent — the canonical source — reports no IPR, PGR, or CBM proceeding. No web-search result surfaced a proceeding against this patent either. Because there is no proceeding to report, there is nothing to break down by status (active / claims invalidated / claims sustained / settled / institution denied); the count is zero across every category.

Bottom-line defensive posture. There is no PTAB record that has canceled any claim of the '792 patent — but that cuts against a defendant in one narrow sense and for the defendant in a much bigger one:

• No IPR has been filed, so no claim of 7,454,792 has been canceled, narrowed, or held unpatentable by the Board, and a § 315(e)(2) estoppel record does not exist to work from. If your opponent sends a demand letter citing claims 1–9 or 15–23, there is no ready-made "the PTAB already killed these claims" defense.
• However, the patent is expired. The Google Patents legal-status record for US 7,454,792 shows "Expired – Lifetime, expires 2024-01-09," with an "Adjusted expiration" event dated 2024-01-09. As of today (2026-10-01) the patent term has run. An expired patent cannot support injunctive relief or an ongoing-royalty theory; a defendant facing assertion today is realistically looking at, at most, a past-damages claim limited by the six-year lookback of 35 U.S.C. § 286 (and further exposed to § 287 marking / notice defenses). That is a far more potent defense posture than any IPR outcome would have given you.

Proceedings

None on file. I found no AIA trial proceeding — IPR, PGR, or CBM — naming US 7,454,792 as the challenged patent. I decline to invent a proceeding number, panel, or disposition to fill this section; there is nothing to report at claim-level granularity because the Board has never construed or invalidated a claim of this patent.

What the searches did surface (context, not a proceeding against the '792 patent)

• The '792 patent has been used by defendants as prior art in an unrelated litigation, not as the challenged patent. In Centripetal Networks, Inc. v. Keysight Technologies, Inc., No. 2:17-cv-00383-HCM (E.D. Va.), Defendants Keysight and IXIA's "Identification of Prior Art" (dated 2018-07-05) lists item "7,454,792 (Cantrell)" among the prior-art references, alongside the TippingPoint UnityOne 200 system and its manual. See https://www.docketalarm.com/cases/PTAB/IPR2022-01199/Keysight_Technologies_Inc._v._Centripetal_Networks_Inc/docs/07-22-2022-Patent_Owner/Exhibit-2008-Ex_2008.pdf. That is a district-court invalidity contention about someone else's patent, not a PTAB trial on the '792 patent.
• The TippingPoint family is litigated, but the AIA trials in that space concern Centripetal's patents, not TippingPoint's. The IPR2022-01199 (Keysight v. Centripetal) and IPR2022-00182 (Palo Alto Networks v. Centripetal) records found in search cite the TippingPoint IPS device as prior art. The TippingPoint patents themselves are not the challenged patents in those proceedings. See https://www.docketalarm.com/cases/PTAB/IPR2022-01199/Keysight_Technologies_Inc._v._Centripetal_Networks_Inc/.
• One search hit — a PTAB petition document referencing "7454792" in a keyword/prior-art string (a petition search-report exhibit) — reflects the '792 patent being cited as a reference in a different party's IPR, not being challenged.

Strategic summary

Which claims are canceled / sustained / untested. Because no AIA trial has ever been instituted on this patent, all claims are untested at the PTAB: independent claims 1, 8, 15, and 19, and their dependents (2–7, 9–14, 16–18, 20–23), stand exactly as granted on 2008-11-18, with no Board-issued cancellation, no adverse final written decision, and no certificate. There is no "surviving-claims" list to build around because no claims were ever removed. The validity risk in this patent lives entirely in Article III, not at the Board.

Estoppel landscape. § 315(e)(2) estoppel is a non-issue here: no IPR/PGR was filed by anyone, so no petitioner (or privy) is barred from raising any ground. Symmetrically, a defendant today cannot lean on an estoppel record built by someone else to narrow the fight. Any invalidity defense you want to run — § 102, § 103, § 112 — is fully available to you in district court, subject only to the ordinary rules (e.g., § 282, and the estoppel effects of your own prior litigation, if any). If you file an IPR, you would be the first petitioner and would face no § 325(d)/Fintiv "second bite" baggage from this patent's history.

Pattern signals. There is no repeat-petitioner pattern and no defensive-aggregator involvement on this patent — no Unified Patents, no RPX-style IPR. The patent's owner-of-record trajectory is: TippingPoint Technologies Inc. (original assignee) → Hewlett-Packard entities → Trend Micro Incorporated (assignments recorded 2016-07-20 and 2016-08-23), with the current-assignee field also listing HP Inc. The absence of any IPR is itself the signal: this is an expired, low-assertion-life patent that never attracted a validity challenge at the Board, so there is no favorable PTAB precedent to inherit.

Recommended next steps

1. Lead with expiration, not with IPR. As of 2026-10-01 the '792 patent's term has ended (recorded expiration 2024-01-09; source: https://patents.google.com/patent/US7454792/en). Confirm the expiration and any terminal-disclaimer / maintenance-fee history on USPTO PatentCenter before responding to any demand. If the patent is in fact expired, the assertion cannot support forward-looking relief, and past damages are cabined by § 286's six-year window and subject to § 287 notice/marking defenses.
2. Verify the no-PTAB-activity conclusion at the source before relying on it. I could not complete an exhaustive PTAB E2E / Patent Trial and Appeal Board End-to-End docket sweep within this session; the ODP block plus targeted web searches support "no proceedings," but for a filing-critical decision, pull USPTO PTAB E2E (https://ptacts.uspto.gov/ptacts/) and search by patent number, and confirm the same for the two family members US 7,454,499 (parent, filed 2002-11-07) and US 7,451,489 (sibling divisional, filed 2004-08-31), since a challenge to a sibling could bear on the same subject matter.
3. If you do challenge validity, the Board is fresh ground. With no prior petitioner, no § 325(d) or General Plastic/Fintiv stacking problem exists on this patent. An IPR would be a first-instance filing — but weigh it against the expiration reality: an IPR on an expired patent is permitted (Phillips claim construction applies), yet it may be a poor use of budget if the past-damages exposure is already small or time-barred.
4. Treat the Centripetal/Keysight prior-art identification as a research lead, not a proceeding. The defendants there listed "7,454,792 (Cantrell)" (Ex. 2008, 2018-07-05). If you need art to attack a related patent, that identification and the TippingPoint UnityOne 200 system may be a starting point — but do not represent it as a PTAB result against the '792 patent; it is not one.

Caveat on completeness: I was unable to run the full set of targeted queries I intended (further searching was cut off by a step limit). The ODP structured data and the searches performed both point to "no PTAB activity on file," and I found no contrary evidence — but I have not independently confirmed the entire PTAB docket for this patent and its two family members. Flag any proceeding you locate that the ODP ingestion has not yet indexed; I found none.

I'll research the assignment record for US Patent 7,454,792 across the USPTO Assignment Center and cross-reference other sources.

Let me try more targeted searches for the assignment records.

Let me try to locate the specific reel/frame records and correspondents of record.

Assignment & Ownership Reconstruction — US 7,454,792 B2

Patent: US 7,454,792 B2 — "Active network defense system and method"
App. 10/930,922 (filed 2004-08-31), divisional of 10/291,095 (filed 2002-11-07) → issued as US 7,454,499. Sibling divisional US 10/930,392 → US 7,451,489. Issued: 2008-11-18. Status: Expired – Lifetime (adjusted expiration 2024-01-09).

Source/limitation note up front. The USPTO Assignment Center (https://assignmentcenter.uspto.gov/, legacy https://assignment.uspto.gov/patent/index.html) could not be queried in structured form with the tools available in this session — my searches returned general web results, not the reel/frame-level record. I therefore reconstructed the chain from the USPTO-derived legal-events data reproduced on Google Patents (https://patents.google.com/patent/US7454792/en, "Legal Events"), which reflects recorded assignment/merger events but does not display reel/frame numbers or the correspondent of record. I did not retrieve reel/frame numbers or correspondents, and I will not invent them. Those two fields are the weakest link in this reconstruction and are flagged throughout.

---

Inventors

Six named inventors, per the issued patent front page:

Pattern check: No unusual departure pattern indicating a pre-fire-sale exodus. Filing predates the 3Com acquisition, so all six were TippingPoint employees at filing. The lead inventor (Willebeek-LeMair) stayed through the acquisition and was promoted to 3Com CTO — the opposite of the "all inventors gone within 12 months" red flag. Several co-inventors later surface on successor security-startup patents (normal industry churn, not a portfolio-liquidation tell).

Minor discrepancy flagged: the Google Patents front page lists six inventors (including Willebeek-LeMair); a third-party aggregator page listing this patent shows only the five co-inventors because Willebeek-LeMair is that page's subject. Treat the patent text (six inventors) as authoritative.

---

Original assignee

TippingPoint Technologies, Inc., Austin, Texas — original assignee on the issued patent.

• Business: Network security hardware/software; a pioneer of the in-line Intrusion Prevention System (IPS) market (UnityOne product line, later "TippingPoint IPS"). It was a public company (Nasdaq: TPTI) and shipped a commercial product embodying the claimed architecture — the patent describes TippingPoint's own in-line, ASIC-accelerated deep-packet-inspection design.
• Status: No longer independent. Acquired by 3Com Corporation (announced Dec 13, 2004; completed Jan 31, 2005, ~$430–442M cash at $47/share), operated as "TippingPoint, a division of 3Com." 3Com itself was acquired by Hewlett-Packard (April 2010, ~$2.7B). The TippingPoint security business was then sold by HP/HPE to Trend Micro (announced Oct 2015, ~$300M; completed 2016). The "TippingPoint Technologies, Inc." entity was absorbed into the 3Com/HP corporate structure.

---

Assignment timeline

Derived from the recorded legal events on Google Patents (USPTO assignment data). Reel/frame could not be retrieved — shown as "n/r" rather than fabricated.

• Recorded 2008-05-29 — Reel n/r (not retrieved)

  • Conveyance: Assignment of assignors' interest ("see document for details")
  • Assignor: 3Com Corporation → Assignee: TippingPoint Technologies, Inc.
  • Correspondent: n/r (not retrieved)
  • Context: Internal corporate reorganization / corrective recording. Flag: the recorded direction (3Com → TippingPoint) runs opposite to the 2005 acquisition direction and to the 2010 "3Com → HP merger" step; this is anomalous and likely a re-recording or a data-ordering artifact — I cannot resolve it without the underlying document. Do not treat the direction as established.

• Executed/recorded 2010-07-06 — Reel n/r

  • Conveyance: Merger
  • Assignor: 3Com Corporation → Assignee: Hewlett-Packard Company
  • Correspondent: n/r
  • Context: HP's acquisition of 3Com (2010) effected as a merger; IP vests in HP by operation of law.

• 2010-07-30 — Reel n/r

  • Conveyance: Assignment of assignors' interest
  • Assignor: TippingPoint Technologies, Inc. → Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: n/r
  • Context: Internal reorg — HP consolidating subsidiary IP into its central IP-holding entity (HP Development Co.).

• 2015-10-28 — Reel n/r

  • Conveyance: Assignment
  • Assignor: Hewlett-Packard Development Company, L.P. → Assignee: Hewlett Packard Enterprise Development LP
  • Correspondent: n/r
  • Context: Internal reorg — the Hewlett-Packard split (HP Inc. / HPE, effective Nov 2015); IP allocated to HPE.

• 2015-11-09 — Reel n/r

  • Conveyance: Assignment of assignor's interest
  • Assignor: Hewlett-Packard Development Company, L.P. → Assignee: Hewlett Packard Enterprise Development LP
  • Correspondent: n/r
  • Context: Second recording of the same HP→HPE reorg (duplicate/curative recording, ~12 days after the first).

• 2016-07-20 — Reel n/r

  • Conveyance: Assignment of assignors' interest
  • Assignor: Hewlett Packard Enterprise Development LP → Assignee: Trend Micro Incorporated
  • Correspondent: n/r
  • Context: Strategic divestiture — Trend Micro's acquisition of the TippingPoint network-security business from HPE; the patent went with the business.

• 2016-08-23 — Reel n/r

  • Conveyance: Assignment of assignors' interest
  • Assignor: Trend Micro Incorporated → Assignee: Trend Micro Incorporated
  • Correspondent: n/r
  • Context: Intra-entity / change-of-name recording within Trend Micro (same name on both sides).

Not shown in the legal-event list: the original inventor→TippingPoint assignment (which would have been recorded 2002–2005). Its absence from the displayed events is itself notable and is not explained by the data I could retrieve.

---

Timeline diagram

timeline
    title Ownership of US 7454792
    2002 : Priority application filed by TippingPoint
    2004 : Divisional application filed
    2005 : 3Com acquires TippingPoint
    2008 : Patent issues
         : 3Com records assignment to TippingPoint
    2010 : 3Com merges into Hewlett-Packard
         : TippingPoint assigns to HP Development
    2015 : IP moves to Hewlett Packard Enterprise
    2016 : HPE sells TippingPoint unit to Trend Micro
    2024 : Patent expires

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present. Every link is an operating company or its internal IP-holding arm: TippingPoint Technologies, Inc. → 3Com → Hewlett-Packard → Hewlett-Packard Development Co. (HP's IP subsidiary) → Hewlett Packard Enterprise Development LP → Trend Micro. No "IP / Licensing / Holdings / Ventures" licensing-only LLC, no registered-agent-service address, no single-purpose Delaware/Texas shell.

2. Known asserter in the chain — not present. No link matches any public NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, Round Rock, etc.). The terminal assignee, Trend Micro Incorporated, is a large operating security vendor.

3. Repeat correspondent across the chain — unclear (not determinable). I could not retrieve the correspondent of record for any recording, so I cannot test for a recurring recording attorney/firm. This signal is unresolved, not "not present." Because the chain runs through four in-house/house-counsel corporate IP departments (3Com, HP, HPD, HPE, Trend Micro), recurrence would be expected and, even if present, would not by itself indicate NPE activity.

4. Cascading transfers — weak/benign. The 2015-10-28 and 2015-11-09 recordings are two filings ~12 days apart for the same HP→HPE reorg — a duplicate/curative pair, not a chain of distinct shells. The 2010-07-06 and 2010-07-30 filings are likewise two steps of one HP consolidation. No <24-month chain of entity-to-entity hops with shared principals.

5. Pre-litigation transfer — not present. Consistent with the companion litigation analysis (no litigation identified asserting US 7,454,792), there is no assignment within six months of any infringement suit. The last transfer (Trend Micro, 2016) is ~9 years pre-expiration with no associated suit.

6. Bankruptcy fire-sale — not present. No Chapter 7/11 assignor in the chain. The 3Com→HP and HPE→Trend Micro transitions were strategic M&A/divestiture, not insolvency sales.

7. Privateering — not present on the record. The closest event is HP/HPE selling the TippingPoint business (and its patents) to Trend Micro — a sale of an operating product line to an operating company, with the patents traveling with the business. There is no evidence the patents were spun into an assertion vehicle to sue HP's competitors; my searches surfaced no SEC filing or press coverage indicating that.

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at an operating vendor (Trend Micro). The only "neutralization" is expiration (2024-01-09), not aggregation.

Cross-check consistency: The signals above are consistent with the companion litigation findings (no district court / ITC / PTAB matter found; the CourtListener "7454792" hit is an unrelated Seventh Circuit docket-entry number). Note that TippingPoint IPS products do appear in unrelated third-party PTAB prior-art exhibits (e.g., Centripetal/Keysight IPR2022-01199), but that use is as prior art, not as assertion of the '792 patent.

---

Verdict

Operating-company assertion (with an explicit caveat).

The entire recorded chain (2008 → 2016) is composed of operating companies and their internal IP-holding subsidiaries — TippingPoint Technologies, Inc. → 3Com → Hewlett-Packard → HP Development Co. → Hewlett Packard Enterprise Development LP → Trend Micro Incorporated (recorded 2016-07-20) — with zero shell entities, zero known asserters, no bankruptcy, and no defensive aggregator. The patented in-line IPS architecture is the design lineage of the commercially shipped TippingPoint IPS line, which the current owner still sells; but I must state plainly that the "assertion" prong is unproven — I found no litigation asserting US 7,454,792 (no suit, no ITC action, no PTAB challenge), and the patent expired 2024-01-09. On the evidence available, this is not an NPE/troll chain; it is a normal operating-company ownership history that ends with a strategic product-line divestiture.

Caveat on verdict selection: the provided taxonomy has no bucket for "operating-company-owned, non-asserting, non-aggregator." "Operating-company assertion" fits the ownership facts (operating owner that ships an embodying product) but not the litigation prong; "Defensive / non-asserting" fits the neutralization fact (expiration) but its defined trigger — a defensive aggregator — is absent. I selected the option whose primary criterion (operating-company ownership/practice) is actually satisfied, and flag the mismatch rather than overstate.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search "7454792" or the family 7,454,499 / 7,451,489; legacy mirror https://assignment.uspto.gov/patent/index.html) — and Google Patents legal events — https://patents.google.com/patent/US7454792/en#legalEvents. Retrieving the reel/frame numbers and correspondents of record from the Assignment Center is the single most valuable next step, since it would (a) confirm the anomalous 2008-05-29 direction and (b) definitively resolve the repeat-correspondent signal.

I'll search for the USPTO record and the cited references for US 7,454,792.

Let me pull the patent's front-page "References Cited" section from the USPTO/patentimages record.

Bottom line up front

I have to be straight with you about a hard limitation, because the alternative is inventing citations.

The authoritative US 7,454,792 record I was given does not contain the patent's "References Cited" (backward-citation) section. The Google Patents rendering in the supplied text includes only a forward citation table ("Cited By (27)") plus a Google-generated "Prior art keywords" list (packets, packet, data flow, suspicious, network) — not the examiner's/USPTO front‑page "U.S. Patent Documents" list. My live searches on the patent number returned the same page, plus unrelated search-string dumps, and I could not retrieve the front page of the patentimages PDF (its "References Cited" box) before running out of tool steps.

Because of that, I cannot responsibly list "each patent citation for 7454792" and map claims to them under § 102 without fabricating reference numbers and dates — which your operating rules explicitly forbid. Below I give you (1) everything I can verify from the record, (2) the citation data that exists but is forward (and therefore cannot anticipate), and (3) a concrete gap list and method to close it.

---

1. Confirming the record (from the authoritative text, IDs interpreted literally)

This matches the identification already established in the earlier sections; nothing here contradicts them.

---

2. The citation data that IS in the record — and why it is NOT § 102 art

Everything the supplied record actually lists as "citations" is forward citing art ("Cited By (27)"). A forward citation postdates the '792 patent and therefore cannot be prior art under § 102 (it is evidence of the patent's own cited-by footprint, not of what the examiner relied on to reject). The forward list (as far as the record shows; the table is truncated in the supplied text at 27 total, ~15 visible):

§ 102 impact: none. All fifteen postdate 2002‑11‑07. They are relevant only as later art showing the field's direction, not as anticipatory references.

---

3. Documented art relationships I can verify (family / incorporated references)

These are real and appear in the '792 specification, but note the caveat that follows:

• Ser. No. 10/291,095, filed 2002‑11‑07 — the parent (issued as US 7,454,499 B2; pre‑grant pub. US 2004/0093513 A1, which is the publication with the near-identical specification returned in my search).
• Ser. No. 10/930,392, filed 2004‑08‑31 — sibling divisional (issued as US 7,451,489 B2).
• Ser. No. 10/136,889, filed 2002‑04‑30, "NETWORK SECURITY SYSTEM INTEGRATION" (incorporated by reference).
• Ser. No. 10/217,862, filed 2002‑08‑12, "MULTI-LEVEL PACKET SCREENING WITH DYNAMICALLY SELECTED FILTERING CRITERIA" (incorporated by reference).

§ 102 caveat (important): A reference must be "by another" to anticipate. US 7,454,499, US 7,451,489 and US 7,454,792 name the same inventive entity (Cantrell, Willebeek‑LeMair, Cox, McHale, Smith, Kolbly) and claim the same 2002‑11‑07 priority. Siblings in the same family with a common inventive entity are not § 102 prior art against one another, and their shared specification (and the two incorporated applications) is not anticipatory § 102 art for that reason.

---

4. One unverified lead I will not present as fact

A search hit placed the row US7454792B2 | 2002‑11‑07 | 2008‑11‑18 | Tippingpoint Technologies, Inc. | Active network defense system and method on the Google Patents page for US 6,477,651 B1, "Intrusion detection system and method having dynamically loaded signatures." If that row sits in that patent's "Cited By" table, it would mean the '792 patent cites US 6,477,651 B1 — i.e., a genuine backward reference with a 2002‑11‑05 issue date (two days before the priority date), which would make it § 102(b) art on its face.

I am flagging this as a lead only. I could not confirm whether the row is a backward citation, a "Similar Documents" entry, or a rendering artifact. Do not treat it as verified.

---

5. Why I am not giving you a claim‑by‑claim § 102 map

A defensible § 102 mapping requires the actual front‑page reference list (or an IDS/892) and the text of each reference. I do not have the list, and I could not fetch it. Mapping "claim X anticipated by reference Y" without having seen Y would be fabrication.

For orientation, here is the structure such a mapping would take against '792's independent claims:

• Claims 1 / 8 (normalizer + block): need art teaching in‑line comparison against a particular implementation of a protocol/standard, modification to enforce adherence (fragmentation reassembly → claim 2/9; hex/Unicode decoding → claim 5/12), and blocking.
• Claims 15 / 19 (good/bad/suspicious sort + asset‑aware second filter + risk assessor): need art teaching a first‑stage classifier splitting traffic three ways, extraction of suspicious packets, a second criteria set that expressly includes an identification of threatened network assets, and an alert conditioned on the protected network actually containing a threatened asset (asset‑database tie‑in under claims 16/20–21).

Those combinations are the likely novelty loci, and the reason the field's ordinary intrusion‑detection references (signature‑only, passive) would generally support § 103 rather than clean § 102 anticipation of claims 15/19.

---

6. To close the gap, retrieve the authoritative citation list from any one of these

1. patentimages.storage.googleapis.com PDF for US 7,454,792 — the front page "(56) References Cited / U.S. Patent Documents" box (the exact box my searches surfaced for a different patent, US 9,744,302).
2. USPTO Patent Center / Public PAIR for application 10/930,922 — Image File Wrapper, Form PTO‑892 (List of References Cited by Examiner) and the applicant's IDS.
3. FreePatentsOnline / Espacenet / DEPATISnet "View the full list of cited documents" panel for US7454792B2.
4. LexisNexis TotalPatent / Derwent citation export filtered to "Citations (backward)."

I'd suggest running the patent number literally as 7454792 / US7,454,792B2 through those tools — a general web search keeps returning the same truncated Google page and false positives (e.g., the CourtListener "7454792" hit, which is a CM/ECF docket‑entry number, not this patent).

If you can paste the front‑page "References Cited" table (or the PTO‑892), I will produce the full per‑reference breakdown you asked for — full citation, publication/filing date, brief description, and the specific claims each reference potentially anticipates under § 102 — immediately.

I'll first try to recover the actual prior-art citation record for this patent, since the page text supplied to me does not include a distinct "Prior Art" (backward-citation) section — only the incorporated-by-reference applications and the forward "Cited By" list.

The Google Patents page for '792 as supplied contains no backward "Citations" list, so let me try to recover the examiner-cited references from the family's foreign search reports and the US file.

Obviousness Analysis — US 7,454,792 B2 under 35 U.S.C. § 103

0. Threshold notes before the analysis

A. The "Prior Art section" of this page does not exist as a section. The authoritative text supplied for US 7,454,792 (https://patents.google.com/patent/US7454792/en, fetched 2026-09-24) contains no backward "Citations"/"References Cited" list — no examiner-cited US patent documents, no cited foreign documents, no cited non-patent literature. What the page does contain that bears on prior art is limited to:

• a "Prior art keywords" field (packets; packet; data flow; suspicious; network) — a search-field signal, not a reference;
• the "Applications Claiming Priority" / "Related Parent Applications" tables (the family);
• the CROSS-REFERENCE paragraph in the description, which incorporates by reference two earlier-filed, co-pending applications;
• the "Cited By (27)" list, which is forward-looking and therefore not prior art by date.

I was unable to retrieve the examiner's cited-reference list in the searches available to me (I hit the tool-step limit mid-query). I am therefore not reporting a fabricated "prior art list." Instead, Section 2 below states exactly what prior art is grounded in this page, and Section 2B states what I am supplying from field knowledge with an explicit confidence rating.

B. Governing law. Priority date 2002-11-07; application filed 2004-08-31 as a divisional under §121 of Ser. No. 10/291,095. Because the application was filed before 2013-03-16, pre-AIA § 103(a) and pre-AIA §§ 102(a)/(b)/(e) apply, including the pre-AIA § 103(c) common-ownership proviso. This matters enormously here (Section 6). Under MPEP practice the § 102(b) one-year bar reaches back to the parent's filing date, i.e. a ~2001-11-07 critical date for public-use/on-sale/printed-publication art.

C. Practical posture. The patent is Expired – Lifetime, adjusted expiration 2024-01-09 (per the page). A § 103 challenge today is retrospective (e.g., for a diligence/validity opinion on the family, or as defensive prior art). The prior "Litigation summary" section already established the '792 was never located as a patent-in-suit; it appears in Centripetal Networks v. Keysight/Ixia, E.D. Va. 2:17-cv-00383, only as cited prior art in Defendants' Identification of Prior Art (July 5, 2018).

---

1. The claims to be analyzed (recap, not repeat)

From the earlier "Independent claims — plain language" section, the four independents reduce to two inventive cores:

Notable: no granted claim recites the flow controller / throttling that the abstract and specification emphasize (see the description's flow control functionality 80). The claim set is markedly narrower than the disclosed embodiment. This is consistent with the claim-set discrepancy already flagged in the earlier summary (the pre-grant publication rendering shows claims 40–49; the grant shows 1–23). One caution carried forward: claim 22 as rendered reads "good Waffle packets" — treat that as a transcription artifact, not a claim term (also confirmed by the Google Patents "Concepts" list on this very page, which indexes the literal string 235000012773 waffles).

---

2. The prior-art universe

2A. Prior art grounded in the supplied page itself

(i) Applicant admissions in the '792 specification itself. These are usable as prior art under In re Nomiya / MPEP 2129. The page states, verbatim:

• *"One packet modification concept of some importance is the notion of normalization. Normalization is the process of enforcing adherence to a particular implementation of a protocol or standard."* — i.e., the applicant concedes that the claim-1 core concept of the normalizer was known.
• *"a popular intrusion detection system evasion technique exploits the variation in the ways target systems handle fragmentation… Some systems reassemble overlapping fragments with the first overlapping packet's data, others reassemble with the last packet's data."* — concedes fragment-overlap evasion was known.
• "two known active response mechanisms implemented by intrusion detection systems are: (a) session sniping…; and (b) firewall updating…" — concedes in-line/active response was known.
• "the current state of the prior art … utilizes a software-based intrusion detection system which is implemented on a general purpose processor" — concedes software IDS was the baseline.
• "normalization may require that all coded (for example, Hex or Unicode) packets be decoded first" — frames decoding as conventional, supporting deps 5/12.

(ii) Two earlier-filed applications incorporated by reference (the CROSS-REFERENCE paragraph):

US 6,983,323 / US 2004/0030776 A1 is the single most material reference against Core B, because it discloses exactly the architecture the earlier summary attributes to claim 15. Verbatim from the published application:

"In a first level 12 (also referred to as a triggering or detection level), a corresponding first filter 14 receives packet traffic 16 and screens that received traffic against a first set of filtering criteria 18. A portion 20 … that passes … is output … A portion 22 … which does not pass … is forwarded on for further examination by a second level 24 … The second level 24 (also referred to as a confirmation or catch level) implements a corresponding second filter 26 … A portion 30 … passes the second set of filtering criteria 28 and is output …"

"The first set of filtering criteria 18 are implemented as a triggering mechanism to allow for relatively high speed examination … where limited processing capability filtering is used with a design to catch substantially all suspicious traffic, understanding that the filter 14 will inevitably erroneously additionally capture some benign traffic (i.e., accuracy is relatively low …) … this first level 12 screening implicates header field compares and trigger content searches …"

"…Dynamic adjustments may be made to the first and second filtering criteria to achieve better overall packet filtering performance. For example, load is measured and the filtering criteria adjusted to better balance load between the hierarchical filtering actions."

That is: extraction of the failing/suspicious portion (claim 15's extracted), a second criteria set (claim 15's second set of filtering criteria), return of the non-threatening portion (claim 23's returning those other ones…), and even the "dynamically selected filtering criteria" concept that the '792 describes for its translation functionality 60 / suspicion alert 170 feedback loop.

(iii) The TippingPoint UnityOne 200 product and its manual. Confirmed on the record as prior art identified by Defendants in Centripetal v. Keysight: https://www.docketalarm.com/cases/[PTAB](/ptab)/IPR2022-01199/Keysight_Technologies_Inc._v._Centripetal_Networks_Inc/docs/07-22-2022-Patent_Owner/Exhibit-2008-Ex_2008.pdf (items 5 and 6: "TippingPoint Unity One 200"; "TippingPoint Unity One 200 manual"), and the "UnityOne™ Intrusion Prevention Appliances Data Sheet," 2003 is cited as a reference in US 10,893,066 (https://patentimages.storage.googleapis.com/42/56/d6/295afb9dea9837/US10893066.pdf). Critical date caveat: the data sheet is dated 2003, i.e. after the 2002-11-07 priority date, so it is not §102(b) art against these claims unless it is paired with evidence of an earlier public use/sale of the appliance (see §2C).

(iv) The forward "Cited By (27)" list — not prior art by date. Its value here is corroborative context: US 2006/0161983 A1 (Cothrell, "Inline intrusion detection," 2005) and US 2007/0097976 A1 (Wood, "Suspect traffic redirection," 2005) show that within a few years the industry was independently arriving at the same "in-line + suspect traffic redirection" architecture — relevant to § 103's "known technique" and, arguably, to the lack of unexpected results. One item deserves a footnote: US 8,117,639 B2 (Rocksteady Technologies, priority 2002-10-10) predates the '792 priority by ~4 weeks, but its publication (WO 2004/034229 A2, 2004-04-22) postdates it, so it is not §102(a)/(b) art on this face.

2B. Prior art supplied from field knowledge (with confidence ratings)

I could not verify these by search in this session; I am labeling confidence rather than asserting them as record facts. All are pre-2002-11-07 unless noted.

2C. What is conspicuously missing from the record

No third-party, pre-2002-11-07 US patent appears on this page at all. For a pre-AIA § 103 challenge the load-bearing references would have to be printed publications (Handley 2001, Ptacek 1998, Roesch 1999) plus the applicant's own product/manual, not the family patents — because of § 103(c) (next section). This is, I suspect, precisely why Keysight's prior-art identification in the Centripetal case leaned on "TippingPoint Unity One 200" + "manual" rather than on TippingPoint's patents.

---

3. Level of ordinary skill in the art (POSITA), as of 2002-11-07

A POSITA would hold a B.S. in EE/CS (or equivalent) plus ~2–4 years in network security/network-element design, and would be familiar with: TCP/IP internals including IP fragmentation and TCP session state; signature- and anomaly-based IDS (Snort, SRI/NetRanger-era products); stateful-inspection firewalls; the Ptacek/Newsham evasion literature; hardware/ASIC or network-processor packet pipelines running at line rate; and enterprise asset/vulnerability management tooling. The '792 specification's own framing ("multi-gigabit range… millisecond latencies typical of switches and routers") corroborates that the artisan was expected to reason at the switch/router data-plane level.

---

4. Grounds of rejection — Core A (claims 1–14)

Ground 1: Handley 2001 + Shwed (stateful-inspection firewall) → claims 1 and 8; further in view of Ptacek 1998 → claims 2 and 9

Motivation. (a) Both references concern network elements emplaced at the same topological point (the choke point between untrusted and protected networks), so combining them is a mere aggregation of two known in-line functions on one platform — the classic KSR "combination of prior art elements according to known methods to yield predictable results." (b) Handley et al. supply the reason: an in-line device that later makes blocking decisions cannot know how end hosts reassemble fragments, so an upstream normalizer removes the ambiguity the blocker would otherwise have to guess at — this is an explicit, articulated motivation, not hindsight. (c) The '792 specification itself asserts the combination's advantage ("by sitting in-line and intercepting all packets, the active network defense system … can perform normalization by reassembling fragments using a set algorithm and forwarding reassembled packets") — an advantage that follows predictably from co-locating the two functions.

Dependent claims 2/9 (fragment reassembly enforcement). Ptacek/Newsham document the overlap-ambiguity problem; Handley et al. prescribe "reassemble with a set algorithm." Alternatively, US 6,983,323's trigger filter + Snort's fragment preprocessor supply the reassembly mechanism. Motivation: defeating the known overlap evasion. But see §6 — US 6,983,323 is family art and may be § 103(c)-disqualified.

Ground 2: Ground 1 + signature-based detection (Vaidya / Snort) → claims 3–4, 6–7, 10–11, 13–14; and decoding art → claims 5, 12

• Claims 3–4 / 10–11 (trigger filter detects threat in a reassembled packet; handler blocks packet or terminates session). Vaidya and Snort supply header/content signature matching; Shwed supplies packet dropping; session termination is the "session sniping" mechanism the '792 specification itself admits was a known IDS response ("sending a TCP reset request to the TCP session end-points"). A POSITA combining an in-line blocker with a known IDS alert would trivially map "alert → RST" to "detection → terminate session." Any such system-level claim 4/11 recites the result of a known response mechanism, applied to a normalized/reassembled packet.
• Claims 5, 12, 6–7, 13–14 (decoding encoded — e.g., Hex/Unicode — packets; detect threat in the decoded packet). Prior art: protocol/application-layer decoders as standard IDS components (Snort preprocessors; HTTP/DNS/SMTP decoders), plus the well-documented Unicode/hex encoding evasion of web servers around 2000–2001 (the IIS Unicode directory-traversal class of attacks). The motivation is stated in the specification's own normalization rationale: decode first so the matching criteria cannot be evaded by encoding. The "trigger filter" element comes from Vaidya/Snort, and the block/terminate element from Shwed. Note that the '792 spec lists HTTP/DNS/SMTP/SNMP/FTP decoding and "hex and unicode decoding" among its own processing functions — an admission that these were conventional tools of the trade.

---

5. Grounds of rejection — Core B (claims 15–23)

Ground 3: US 6,983,323 (US 2004/0030776 A1) + asset/vulnerability-assessment art (US 5,892,903 / scanner art) → claims 15 and 19

Motivation. (a) Design incentive / finite solution set. US 6,983,323's second stage exists to increase accuracy at the cost of throughput. A POSITA optimizing that stage would naturally ask "is this signature even applicable to a host on my network?" — a discrete, predictable improvement. (b) False-positive reduction. The '792 specification frames the entire problem as separating true threats from the "inevitable" false positives of line-rate screening; an asset database directly attacks that problem, and the vulnerability-scanning art was the known tool for knowing what a network contains. (c) KSR "known technique to improve a similar device in the same way" — asset-aware filtering was already used in vulnerability management; applying it inside a second-stage filter is not an architectural leap. (d) Industry pressure: Code Red (2001), Nimda (2001) and the run-up to Slammer (Jan 2003) made "signature fired but no vulnerable host present" a headline operational problem; the '792 spec admits IDS false positives/response attacks as motivators.

Ground 4: Ground 3 + asset-database art → claims 16, 17, 18, 20, 21, 22, 23

• 16, 20, 21 (asset database; compare threatened assets, and their characteristics, against a stored list). Vulnerability-assessment products maintain exactly such host/service/OS/version inventories; the '792 spec itself concedes the source: "This data may be collected in any one of a number of well known ways, including, for example, the use of a separate, perhaps prior art, vulnerability assessment scanner device." That is an admission that the asset database is prior art — a very strong position for a challenger.
• 17, 22 (drop bad, allow good, pass suspicious up). US 6,983,323's three output paths (pass-20, pass-30, reject-32) plus Shwed's drop action. The '792 spec's own action set object ("permit, deny, log, block, terminate") shows these actions were conventional. (Claim 22's "good Waffle packets" is the transcription artifact flagged earlier.)
• 18, 23 (return non-threatening suspicious packets to the data flow). Inherently taught by US 6,983,323: "A portion 30 of the received traffic (failing portion) 22 passes the second set of filtering criteria 28 and is output from the screening engine 10 to join the packet portion 20." That is literally "returning those other ones of the suspicious packets back to the data flow."

---

6. ⚠️ The decisive legal caveat: pre-AIA § 103(c) may disqualify the best reference

This is the most important point in the analysis and it cuts against the challenger.

• US 6,983,323 / US 2004/0030776 A1 bears the assignee TippingPoint Technologies, Inc. (confirmed on the EP 1 540 502 A1 record) — the same entity as the '792's original assignee ("TippingPoint Technologies Inc," per the page's assignment table). Its § 102(e) date is its 2002-08-12 filing date, which predates the '792 priority date, and it qualifies as "by another" only because the inventive entities differ slightly (the earlier summary lists John McHale among the '792 inventors; the EP 1 540 502 inventor list is Cantrell, Willebeek-LeMair, Cox, Kolbly, Smith — no McHale).

• Under pre-AIA § 103(c), subject matter that qualifies as prior art only under § 102(e), (f) or (g) and that was commonly owned at the time the invention was made "shall not preclude patentability under this section." Because both the '792 and US 6,983,323 were TippingPoint Technologies, Inc. subject matter, a challenger using US 6,983,323 as a § 103 reference must either (i) prove common ownership did not exist in Nov 2002, or (ii) overcome § 103(c) by another route (e.g., § 103(c)(2) after the 2004 amendments, which apply to applications filed on or after 2004-12-10 — note the '922 divisional was filed 2004-08-31, i.e. before that amendment's effective date).

• The 10/136,889 ("Network security system integration") reference presents the mirror-image problem. The EP record associates US 7,359,962 B2 with assignee 3Com Corporation, not TippingPoint. If so, it was not commonly owned with the '792 in Nov 2002 (3Com acquired TippingPoint in 2005; the assignment table shows "Assignors: 3COM CORPORATION" only in 2008–2010 records), meaning the § 103(c) safe harbor would not shield it — and it would be available as § 102(e) art. However, I have not verified the 10/136,889 ↔ 7,359,962 linkage, and the ownership history is genuinely murky (the page's own chain has HP Development Company assigning 3Com-sourced interests). This is a fact a challenger must nail down with USPTO Assignment records.

• Practical consequence: the cleanest § 103 route around Core A and Core B is third-party printed publications + the applicant's own UnityOne product/manual, not the family patents. For the UnityOne appliance, the § 102(b) critical date is ~2001-11-07; the 2003 data sheet therefore needs corroborating evidence of earlier public use, sale, or an earlier manual revision.

---

7. Teaching-away and counter-arguments the challenger must address

1. Ptacek & Newsham (1998) arguably teach away from normalization. They reasoned that a detector cannot know how the destination reassembles, and therefore that normalizing is the wrong fix. Handley et al. (2001) squarely rebut this and advocate the in-line normalizer; so as of the 2002-11-07 critical date there is no subsisting teaching away. A challenger should present the two together and argue the artisan would follow the 2001 paper over the 1998 one. If a defendant relied on Ptacek/Newsham alone, the '792 would likely survive — worth noting because the '792 specification cites the fragmentation-overlap problem in exactly the Ptacek/Newsham framing and then asserts normalization as its improvement.
2. "Extraction" vs. "forwarding." A patent owner could argue claim 15's extracted from the data flow implies removal from the main in-line path (the '792's out-of-line threat verifier), whereas US 6,983,323 forwards the failing portion within the screening engine. Expect a claim-construction fight over whether "extracted" requires physical out-of-line diversion. The specification's "out-of-line" language ("the packet traffic is being handled away from the main data flow 14") supports the patent owner here — but the claim does not import "out-of-line," which cuts for the challenger.
3. No claim covers the algorithmic filter or flow controller, so the specification's strongest-sounding differentiators (multi-session statistical correlation; throttling) are irrelevant to validity of these 23 claims and should not be over-weighted in either direction.
4. Secondary considerations. TippingPoint/UnityOne commercial success and industry adoption of line-rate IPS are the most plausible objective indicia, but nexus is weak as to these claims: the claims recite an in-line normalizer + gatekeeper, and a two-stage asset-aware filter — not the hardware ASIC/TSE parallel pattern-matching engine that the specification touts as the advance over software IDS. The earlier sections established no litigation, no PTAB proceeding, and no evidence of copying or industry praise with nexus. Also note the product-manual and GWDG test report material (https://gwdg.de/en/about-us/gwdg-reports/gwdg-bericht-70.pdf) postdate the priority date by years and cannot establish pre-2002 objective evidence.

---

8. Bottom line

Overall: the '792's granted claims read on a fairly predictable 1998–2001 arc — evasion literature (1998) → in-line normalization proposal (2001) → hierarchical screening (TippingPoint's own 2002-08-12 filing) → asset-aware confirmation. Core A (claims 1–14) is highly vulnerable to third-party art. Core B (claims 15–23) is vulnerable only if the challenger can (a) defeat the § 103(c) common-ownership shield on US 6,983,323, or (b) substitute the TippingPoint UnityOne 200 product + manual with pre-2001-11-07 corroboration, and then pair it with vulnerability-assessment art.

---

9. Confidence, limitations, and contradictions flagged

Contradictions / gaps I am flagging rather than papering over:

1. No "Prior Art" section exists on the supplied page. The page's prior-art-relevant content is limited to the Prior art keywords field, the incorporated-by-reference applications, and the forward Cited By list. Any analyst claiming to have used a "Prior Art section" of this page is inventing one. I have identified what is actually there.
2. Date inconsistency in the task prompt: the operating header says today is 2026-10-01; the task body says April 26, 2026. Not material to the analysis, but noted.
3. Reference-number confidence: US 6,983,323, US 2004/0030776 A1, EP 1 540 502 A1, the KR family page, the UnityOne identification, and the 2003 UnityOne Data Sheet are verified in this session's search results. Handley 2001, Ptacek/Newsham 1998, Roesch 1999, US 5,835,726, US 6,279,113, US 6,321,338, US 5,991,881, US 5,892,903 are named from field knowledge and were NOT verified this session — verify each number/title/citation before filing anything that depends on it. I explicitly did not invent any citation.
4. The 10/136,889 ↔ US 7,359,962 linkage is unverified and the 3Com-vs-TippingPoint ownership question it raises is important to the § 103(c) analysis.
5. Claim 22 "good Waffle packets" is a literal-text artifact on the Google Patents rendering; the "Concepts" index on the same page literally lists waffles, confirming the artifact propagates. Do not construe the claim on that string.
6. Prior "Litigation summary" conclusion stands: no district court, ITC, Federal Circuit, or PTAB proceeding was located asserting or challenging the '792. This § 103 analysis therefore has no adjudicated record to compare against — it is a paper analysis only.