US 7478429

I'll verify the patent record and check for any 2026 litigation activity.

Let me check the claim set and confirm whether any 2026 court docket references this patent.

US 7,478,429 B2 — Verification & Summary

Sources consulted: Google Patents full-text record (https://patents.google.com/patent/US7478429/en), Justia Patents claim text (https://patents.justia.com/patent/7478429), uspto.report grant record, and general web/USPTO-adjacent searches. I did not auto-correct any identifier — 7,478,429 is reported exactly as retrieved.

---

1. Bibliographic Data

Uncertainty note: The Google Patents record does not expose a verified inventor residence or a full assignment chain beyond the two recorded events (2004-10-01 assignment to Prolexic; 2015-04-28 merger into Akamai). I did not independently confirm the merger instrument.

---

2. Abstract (as published)

A system and method is disclosed for detecting and/or mitigating an overload condition from one or more first computers, such as a distributed denial of service (DDoS) attack, viral attack, or the like, targeting one or more of a plurality of second computers located on a network. While one or more DDoS attacks are mitigated, a meter, detection apparatus, software, or method, detects the condition being mitigated in a data cleaning center, and provides an alert or notification regarding the mitigated attack.
Another preferred embodiment relates … to a domain name server. A network connection is provided for receiving one or more DNS requests … A preferred embodiment includes a processor for providing a response to the one or more DNS requests … if more than a threshold number of duplicate DNS requests are received.
Another preferred embodiment relates … to a networked computer system that uses a redirection module to divert data until it is deemed to be clean.

This is a single-patent abstract covering several distinct embodiments (meter-based detection, DNS protection, redirection), which matters for claim-scope reading.

---

3. Plain-Language Overview of the Independent Claims

Confidence caveat up front: The Google Patents full text I retrieved was truncated immediately after the Detailed Description (it cuts off at "Referring now to FIG. 2…") and does not include the claims section. The claim language below is drawn from the Justia Patents claim excerpt, which shows dependent claims numbered through at least 45. I could not verify claims 1–24, so the list of independent claims below is likely incomplete. Independent claims I can positively identify from retrieved text:

Claim 25 — Independent method claim (meter-based detection)

A method for detecting/mitigating an attempted overload condition, comprising:

• a network connection receiving a volume of data D_in over a time period P_in from first computers on a network;
• one or more attack mitigation modules detecting data (directed to second computers) that "bears one or more characteristics determined to be associated with attempted overload conditions," and producing a volume of clean data D_out over P_out (with P_out recited as equal to P_in — the retrieved text contains an apparent typographical recursion, "P_out is equal to the time period, P_out");
• the attack mitigation modules remove the suspect data at least before the meter has detected the presence of the mitigated overload condition attempt — i.e., cleaning precedes detection, not the other way around.

Plain language: Build a scrubbing center. Measure traffic in and traffic out. Strip out the attack traffic first; only afterward decide, by comparing in-rate vs. out-rate, that an attack was in fact occurring.

Claim 42 — Independent system claim

A system for detecting an attempted overload condition targeting one or more of a plurality of networked computer systems, comprising the networked-computer-side counterpart of the above (with claim 43 specifying that at least one attack mitigation module resides at the application layer — a notable point, since the patent's stated novelty is attacking detection above the network/transport layers where prior art operated).

Plain language: The apparatus version of claim 25, expressly locating mitigation logic at the application layer (HTTP-level inspection) rather than only at OSI layers 3–4.

Claim 44 — Independent claim (labeled "method" in the text)

A method substantially paralleling claim 25, reciting:

• detection producing clean data D_out over P_out = P_in;
• detection occurring if D_out ÷ P_out is substantially less than D_in ÷ P_in; and
• removal of the suspect data occurring at least before detection of the mitigated overload attempt.

Plain language: Same subtractive idea, but it expressly states the arithmetic test — if the cleaned outbound rate is materially lower than the inbound rate, you have detected a mitigated attack.

Quote-integrity flag: Claim 45 as retrieved reads "The system of claim 44, wherein detecting data…" — referring to claim 44 as a system even though claim 44 is captioned a method. This is reproduced literally from the retrieved claim text; it may be a drafting/typographical defect in the patent. Do not treat this as a corrected identifier.

Note on dependent-claim scope (verified from retrieved text): Claims 28–31 cover caching variants (D_cache added back into the comparison; thresholds; "greater than 0"); claims 32–36 cover first/second-computer and network-type recitations; claims 37–38 cover proxy services and proxy load balancing; claims 39–41 cover the three specific application-layer signatures (duplicate HTTP GET counting, User-Agent alphabetical-character check, Host header existence check).

Additional independent claims likely in claims 1–24 (UNVERIFIED)

The specification's Summary of Invention discloses at least five further standalone inventions that are strong candidates for independent claims I could not retrieve: (a) duplicate-GET-command threshold detection; (b) User-Agent header character check; (c) Host header presence check; (d) CR/LF vs. CRLF line-break validation; (e) the redirection module that sends initial packets to a third computer and, once deemed clean, redirects subsequent packets directly to the second computer to eliminate proxy latency. Treat this as inference, not confirmed claim text.

---

4. Technical Gist (non-legal summary)

• Architecture: A "data cleaning center" (100) as a stand-alone network node: core edge aggregation router → core router with inbound ACL sanity check → meter → attack mitigation modules (chained over a local fiber "attack mitigation pipe" 150) → load balancer → reverse proxy servers → back out to the network. Optional distribution router/backbone (158) links multiple cleaning centers for load sharing and failover; OSPF is mentioned for rerouting around failed modules.
• Core detection principle: Continuously compare D_in/P_in against D_out/P_out; a materially lower outbound rate implies attack traffic was scrubbed. Latency L, caching (D_cache), and normalization across unequal P_in/P_out are expressly addressed.
• Named commercial hardware referenced (as examples only): Juniper M40/M-series, Foundry BigIron 4000 / NetIron 800/400, Radware WSD, Dell PowerEdge, Top Layer Attack Mitigator IPS 2800/5500.
• DNS embodiment (FIGS. 9–10): a separate high-speed processor (902) in front of the DNS server checks port 53, performs RFC sanity checks and valid-domain checks, tracks per-source/per-domain hit counts, and services duplicate-flood requests itself when a threshold is exceeded — then hands traffic back to the DNS server when the count subsides.
• Anti-latency embodiment (FIG. 8): human-verification techniques (cookie-write test; CAPTCHA-style distorted-image challenge) determine whether traffic is from a real browser before letting it bypass the scrubbing center.

---

5. Litigation / Docket Search Result (2026)

No 2026 CAFC docket or 2026 USPTO proceeding specifically naming patent 7,478,429 was found in my searches. Reporting this explicitly rather than inferring:

• Searches for "7478429" + CAFC/2026 and Prolexic/Akamai litigation returned no case referencing this patent.
• The only hits for the string "7478429" outside patent databases were prior-art citation lists in unrelated IPR/PGR file histories (e.g., the file history of US 9,565,213 in IPR2018-01512, and a Centripetal/Palo Alto Networks IPR exhibit), where 7,478,429 appears only as a cited reference, not as the challenged patent.
• A CAFC decision surfaced in results — Akamai Technologies, Inc. v. MediaPointe, Inc. (Nov. 2025, §112(b) indefiniteness of "optimal") — involves Akamai but is not about 7,478,429; do not conflate it with this patent.
• Practical implication: with an adjusted expiration of 2025-06-25 and legal status "Expired – Lifetime," this patent is past term and would be an unlikely candidate for new infringement assertion, which is consistent with the absence of 2026 docket activity.

If you need authoritative confirmation of current docket status, the reliable primary sources are the USPTO Patent Trial and Appeal Board (PTAB) API, the USPTO Patent Public Search / PatentCenter record for US 10/956,721, and PACER / CourtListener for the Federal Circuit — I have no live authenticated access to those in this session, so I am flagging the negative result as "not found in searched sources," not as "confirmed no litigation."

I'll search for litigation involving US patent 7478429.

Let me search more specifically for litigation involving this patent's owners and the patent number.

Let me search targeted litigation databases and specific case names.

Litigation Search Results for U.S. Patent 7,478,429

Bottom line: I did not find any litigation involving U.S. Patent 7,478,429 in the sources I was able to search.

I want to be explicit and careful here rather than fabricate case details. Per your instructions, I treated the number literally (7,478,429) and did not auto-correct it to any similar-looking number.

What I searched

• General and targeted web searches for "7478429 patent litigation," "7,478,429 patent infringement lawsuit," and case/docket phrasing.
• Searches combining the patent number with its provenance (Prolexic Technologies, the original assignee; Akamai Technologies, the current assignee via merger; inventor Barrett Lyon).
• Searches aimed at litigation aggregators (Unified Patents portal, PACER/CAFC-oriented results, Docket Alarm, CourtListener).

What I found (and why it is NOT this patent)

Every hit that contained the string "7478429" turned out to be either:

1. The patent appearing only as a cited prior-art reference in other matters — e.g., a Sun Microsystems patent (JP2011527043A) and the file history of U.S. Patent 9,565,213 (docketalarm.com/.../IPR2018-01512) both list "7478429" merely as a citation, not as an asserted patent.
2. Unrelated patents with superficially similar numbers that the search engine surfaced — e.g., the Realtime Data/IXO family (6,624,761; 7,161,506; 7,400,274; 7,417,568; 7,714,747), the Sable Networks cases (6,954,431; 8,243,593, etc.), MPH Technologies v. Apple (7,937,581), and Collision Communications v. Samsung (7,463,703; 7,920,651; 7,593,492; 6,947,505). None of these involve 7,478,429, and I am flagging them only so you can see they are decoys, not matches.

To the extent any of those results mention "429," they refer to entirely different patents (e.g., a Ford patent exhibit labeled "375, 854, 748, 429"). I did not treat any of them as the patent in question.

Relevant patent facts (from the authoritative patent record)

• Patent: U.S. 7,478,429 B2 — "Network overload detection and mitigation system and method"
• Inventor: Barrett Lyon
• Original assignee: Prolexic Technologies, Inc.; current assignee: Akamai Technologies, Inc. (merger recorded 2015-04-28)
• Filing/priority date: 2004-10-01; granted: 2009-01-13
• Status: Expired – Lifetime (adjusted expiration 2025-06-25)
• Family includes: US 2006/0075491 A1, WO 2006/039529 A2, and related filings

Caveats / confidence level

• Confidence that no litigation exists: low-to-moderate. My searches were not exhaustive, and my tool access was cut off before I could query the Unified Patents litigation caselist, PACER, or CourtListener dockets directly. It is entirely possible a suit exists that my searches did not surface.
• I have no independent recollection of any specific case asserting 7,478,429, so I will not invent a plaintiff, defendant, jurisdiction, case number, or outcome.

Recommended next steps to confirm

1. Unified Patents Portal – Litigation Caselist/PateL: search the exact number 7,478,429 as an "asserted patent."
2. USPTO Patent Litigation Docket / Patent Examination Data (Assignment + Litigation): search by patent number and by assignee (Prolexic Technologies; Akamai Technologies).
3. PACER and CourtListener/RECAP: run a docket-text search for "7,478,429."
4. Docket Alarm / Darts-ip / Lex Machina: filter by patent number.

If a suit exists, it would most plausibly involve Prolexic Technologies, Inc. as plaintiff (pre-2015) or Akamai Technologies post-merger, but I found no evidence of that and will not assert it as fact.

If you'd like, I can re-run focused queries against those specific databases (Unified Patents portal, CourtListener, PACER) in a follow-up pass.

I'll verify the canonical "no proceedings" result against public sources before answering.

Proceedings overview

Zero. The USPTO Open Data Portal (ODP) structured block provided in this task is the canonical source, and it reports no AIA trial proceedings on file for US 7,478,429 — no IPR, no PGR, no CBM. My independent web searches found nothing that contradicts that: every occurrence of the string "7478429" in PTAB-adjacent documents is the patent appearing as a cited prior-art reference in someone else's file history, not as a challenged patent (e.g., Cisco Ex. 1002, the file history of US 9,565,213 in IPR2018-01512, where a 2016 examiner search-history string lists "7478429"; and a Sun Microsystems/Japanese prosecution citation). Those are decoys — the patent is a citation, not a subject.

Bottom-line defensive posture: For a defendant today, there is no PTAB record to lean on — no claim has ever been canceled, and no Panel has ever construed a term of this patent. The absence is not evidence of patent strength; it is consistent with two other facts in the record: (1) the patent expired (adjusted expiration 2025-06-25, legal status "Expired – Lifetime"), and (2) my prior litigation pass found no assertion of this patent. A patent that was never asserted attracts no IPR petition. So the accurate framing is "untested and now expired," not "hardened by surviving IPR." Do not let an adversary (or your own client) characterize the empty PTAB docket as a validity endorsement.

---

(No proceedings to list)

There are no {PROCEEDING_NUMBER} entries to render. Per the instruction "Don't fabricate proceeding numbers," I am deliberately not creating any, and I am not populating the per-proceeding template (type / filed / status / panel / grounds / institution / FWD / settlement / appeal / defensive value) with invented or inferred content. No Final Written Decision exists, so there is no claim-level disposition to quote, no panel to name, and no CAFC appeal to link.

Negative-result confidence: moderate-to-high, with one caveat.

• High confidence in the structured result — that is the ODP ingest.
• The caveat: I could not directly query PTAB E2E / PTAB API, Docket Alarm, or Unified Patents' caselist in this session. Older CBM/PGR filings from the 2013–2020 window are the most plausible place for an unindexed proceeding to hide, though a CBM petition on a DDoS-mitigation patent would be a poor statutory fit (the claims are not "used in the practice, administration, or management of a financial product or service"), so I rate that unlikely.

---

Strategic summary

Claim status: everything is UNTESTED. No claim of US 7,478,429 — not claim 25, not claim 42, not claim 44, and not the likely independents in claims 1–24 flagged in the prior summary — has ever been addressed by the Board. There is no canceled-claim list and no sustained-claim list. Any statement such as "claims 1–5 have been canceled" would be false. Note the cross-reference to the earlier section: that section already flagged claim 45 as reading "The system of claim 44" where claim 44 is captioned a method claim — an apparent drafting defect that, absent any Board construction, remains exactly that: an unresolved drafting issue, not an adjudicated indefiniteness holding.

Estoppel landscape: there is none, and it cuts both ways. Because no IPR/PGR ever reached a final written decision, § 315(e)(2) estoppel has never attached to anyone with respect to this patent. For a defendant being asserted against today:

• You are not barred from raising any § 102/§ 103 ground in district court — the full prior-art universe is open, including art that would have been IPR-eligible.
• Conversely, you get no free head start from an earlier petitioner's work product, no Board claim constructions to borrow, and no invalidation record to cite.
• IPR is nonetheless a poor vehicle for this patent now. The adjusted expiration date is 2025-06-25, i.e., the patent is past term as of the current date (2026-09-30). Practically: the patent owner can no longer recover for ongoing infringement, pre-suit damages are time-barred beyond the § 286 six-year lookback, and the Director's 2025-era discretionary-denial practices (the "settled expectations" line of decisions keyed to patent age, plus the parallel-litigation bars) make institution on a 2004-priority, expired patent an uphill request. If you need an invalidity adjudication at all, district court is the live forum, not the PTAB.

Pattern signals: none. There is no repeat petitioner, no serial-filer dynamic, no defensive aggregator (Unified Patents or similar) in the chain with respect to this patent, and no PTAB appeal activity — because there was never a trial to appeal. Do not import the Akamai-adjacent PTAB noise you will find in search results: the Limelight/Akamai IPRs (e.g., IPR2018-00309 on US 8,484,319; IPR2018-00359 on US 8,458,769; the Akamai v. Limelight § 103 appeals) involve different Akamai patents, and Akamai Technologies, Inc. v. MediaPointe, Inc., No. 2024-1571 (Fed. Cir. 2025-11-25) is a § 112(b) indefiniteness case about US 8,559,426 / 9,426,195. None of these touch 7,478,429. The current assignee (Akamai, via the 2015-04-28 merger with Prolexic) being IPR-savvy says nothing about this patent's history.

One substantive point a defendant can still use. The patent's family members — US 11/241,470 (pub. US 2006/0075084 A1), US 12/251,723 (pub. US 2009/0037592 A1), and US 13/734,104 (pub. US 2013/0145464 A1) — are separate patents/applications with separate expiration dates, and the record does not show that any of them was ever IPR-challenged either. If a demand letter cites the family rather than the '429 specifically, the "check the right patent number and the right expiry" analysis must be redone per asset; do not assume the 2025-06-25 date governs a continuation.

---

Recommended next steps

1. Do not assert an IPR-based defense. There is no FWD to cite and no estoppel record to exploit. If opposing counsel represents that "the PTAB already invalidated the relevant claims," demand the proceeding number and the FWD — because on the current record none exists.
2. Confirm the empty docket at the primary source before relying on it in a brief or an opinion letter:
   • PTAB E2E / PTAB API: https://ptacts.uspto.gov/ptabweb and the USPTO Open Data Portal (the source of the canonical block in this task)
   • Patent record for US 10/956,721: https://patents.google.com/patent/US7478429/en and https://uspto.report/patent/grant/7,478,429
   • CourtListener (for CAFC/PTAB appeals): https://www.courtlistener.com
3. Pivot the defense to the forum that is actually available. With the patent expired (2025-06-25) and no PTAB history, the operative questions are (a) whether any asserted claim family member is still in force, (b) § 286 damages limits on any expired-claim theory, and (c) district-court invalidity under § 102/§ 103/§ 112(b) — the last of which is where the claim-45 "system of claim 44" defect flagged earlier becomes a live argument rather than a historical footnote.
4. Treat the negative as provisional, not final. This is a "not found in searched sources" result, not a certification of no proceedings. An unindexed or very old CBM/PGR remains the theoretical gap; if the stake justifies it, a paid Docket Alarm or Lex Machina pull on the exact string "7,478,429" is the cleanest closure.

Sources cited: Google Patents record for US 7,478,429 (https://patents.google.com/patent/US7478429/en); uspto.report grant page (https://uspto.report/patent/grant/7,478,429); Cisco Ex. 1002 (file history of US 9,565,213) in IPR2018-01512, citing "7478429" as prior art (https://www.docketalarm.com/cases/PTAB/IPR2018-01512/); Patterson Sheridan Federal Circuit summary, week ending 2025-11-28, Akamai v. MediaPointe, No. 2024-1571. No USPTO Final Written Decision involving US 7,478,429 is cited because none exists on the current record.

I'll research the assignment record for US 7,478,429, starting with the USPTO Assignment Search and related sources.

Let me search more specifically for the assignment reel/frame records and correspondent details.

Let me try to locate the specific reel/frame numbers and correspondent of record from the assignment database.

Assignment & Ownership Reconstruction — US 7,478,429 B2

Source-access limitation (stated up front, per instructions): I could not open the USPTO Patent Assignment Search interface directly (no authenticated session), and my searches for the underlying reel/frame records returned no indexed reel/frame numbers or correspondent names for this patent. The two events below are confirmed from the Google Patents "Legal Events / Reassignment" record (https://patents.google.com/patent/US7478429/en) and cross-checked against Akamai's own SEC filings for the merger. I am not fabricating reel/frame numbers or correspondent names that I could not retrieve; the gaps are flagged explicitly rather than filled.

---

Inventors

• Sole-inventor signature: The original assignment (see below) shows a single assignor, "LYON, BARRETT," executed on the same day the application was filed (2004-10-01). Because the invention was assigned to his own company on the filing date, the classic "inventors bolt within 12 months of filing" fire-sale precursor does not appear here — there was no gap between filing and assignment.
• Post-filing pattern (moderate confidence, flagged): Lyon is a serial security entrepreneur who subsequently founded/led other companies (e.g., 3Crowd, Defense.Net). I cannot confirm the exact date he departed Prolexic from the sources available, so I am not asserting a departure-timing finding. For a single-inventor patent this factor is low-signal anyway.

---

Original assignee

• Entity on the issued patent: Prolexic Technologies, Inc. (Delaware corporation; HQ Hollywood, Florida).
• Business: A DDoS mitigation provider — a genuinely operating company, not a holding vehicle. It ran a global network of traffic scrubbing centers and a 24/7 Security Operations Center, i.e., it commercially practiced the "data cleaning center / clean-data" architecture claimed in this patent (the patent's own FIG. 1–3 describe that service). Strong evidence the claims were embodied in a shipped service.
• Status: Acquired — not dissolved in bankruptcy. Akamai Technologies, Inc. acquired 100% of Prolexic via a reverse subsidiary merger (Panther Acquisition Corp. merged into Prolexic, which survived as a wholly-owned Akamai subsidiary). Deal announced 2013-12-02; closed 2014-02-18; Akamai paid ~$337.1M in cash to equityholders at closing (headline valuation ~$370M), plus a $50.4M indemnity escrow. Source: Akamai 8-K/press release (https://www.ir.akamai.com/static-files/bd3aaa5a-725e-41db-a862-005e6f4cad3c). Prolexic remains an Akamai product brand today.

---

Assignment timeline

Two recorded reassignment events appear in the patent record. Reel/frame numbers and the correspondent of record were not retrievable from my sources and are marked "not retrieved" rather than invented.

• 2004-10-01 (executed) / recorded 2004-10-01 — Reel not retrieved

  • Conveyance: Assignment (recorded as "ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: Lyon, Barrett
  • Assignee: Prolexic Technologies, Inc.
  • Correspondent: not retrieved (would be Prolexic's patent prosecution/recording counsel of record; not exposed in the indexed record I could access)
  • Context: Founder-to-company assignment executed concurrently with filing — ordinary startup IP housekeeping, not a fire-sale.

• Recorded 2015-04-28 — Reel not retrieved (merger transaction itself closed 2014-02-18; the USPTO recordation lags the closing by ~14 months — flagged as a date discrepancy between the SEC-reported closing and the recorded assignment)

  • Conveyance: Merger ("MERGER (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Prolexic Technologies, Inc.
  • Assignee: Akamai Technologies, Inc.
  • Correspondent: not retrieved (not exposed in the indexed record I could access)
  • Context: Post-acquisition internal reorg — the acquired operating subsidiary's IP rolls up into the public-company parent (Akamai). Not an NPE transfer.

No further recorded assignments (no security interests, no licensing LLC, no re-assignment) surfaced after the 2015 merger recordation. For a patent that expired 2025-06-25, that is consistent with Akamai holding it to term.

---

Timeline diagram

timeline
    title Ownership of US 7478429
    2004 : Filed and assigned to Prolexic
    2009 : Patent granted
    2014 : Prolexic acquired by Akamai
    2015 : Merger recorded at USPTO
    2025 : Patent expired

---

NPE / troll-pattern signals

---

Verdict

Operating-company assertion — with the "assertion" prong absent.

The ownership chain is Lyon → Prolexic Technologies, Inc. (2004-10-01, "ASSIGNMENT OF ASSIGNORS INTEREST") → Akamai Technologies, Inc. (merger, recorded 2015-04-28). Both assignees are operating companies that commercialized the claimed technology — Prolexic ran the scrubbing-center architecture of FIGS. 1–3, and Akamai still sells the Prolexic DDoS-mitigation service — so this is a product-practicing operating-company-held patent, not an NPE acquisition. Zero NPE signals are present, and the patent expired 2025-06-25 ("Expired – Lifetime"), which explains the absence of any assertion. The single most important caveat: reel/frame numbers and the correspondent of record for both events were not retrievable, so signal #3 (repeat correspondent) could not be tested and should be verified directly.

Verify via: USPTO Assignment Center — search by patent number 7,478,429 (https://assignmentcenter.uspto.gov/) or the legacy index (https://assignment.uspto.gov/patent/index.html). Pull the reel/frame and "Correspondent" field for both events to close the gaps above.

Confidence: high on the two assignees and their operating status (corroborated by Google Patents reassignment events + Akamai SEC filings); low on reel/frame and correspondent identity, which I did not retrieve and did not invent.

I'll search for the patent record and its cited prior-art references. Note: the system date is 2026-09-30 while this task states April 26, 2026 — I'll flag that discrepancy but proceed.

Let me try to retrieve the actual "References Cited" list for this patent from patent databases.

Let me try to locate the front-page "References Cited" list specifically.

I hit my tool-step limit before I could pull the front-page "References Cited" list itself. Rather than pad the gap with invented citations, here is what I could verify, what I could not, and a properly grounded §102 framework for the parts of the record I can actually stand behind.

Two date/record flags before the substance

1. This task states "Current Date: April 26, 2026," while my operating system clock reads 2026-09-30, and the authoritative Google Patents fetch I was given is timestamped 2026-09-30T14:05:41Z. I proceed on the 2026-09-30 fetch and flag the inconsistency rather than silently reconciling it.
2. This task also says "the USPTO database." I do not have authenticated access to USPTO Patent Public Search / PatentCenter in this session. My confirmation comes from Google Patents (which mirrors USPTO bibliographic data) and the WIPO/PCT record. I say so explicitly rather than implying I queried a USPTO API.

---

1. USPTO-record confirmation for exactly 7,478,429

I searched the literal string 7478429. The record I can confirm (consistent with the earlier sections, not repeated in full):

I did not return or blend similar numbers. I specifically discarded a search decoy — US 3,747,842 A (Grubb) — that surfaced only because it contains the digit string "3747842," which is not 7,478,429 and is unrelated (a 1973 French/European filing). I flag it only so you can see it was excluded, not treated as a match.

---

2. The critical limitation on this task, stated plainly

The task asks me to "look at each patent citation for 7,478,429" and map each one to claims under §102. I was unable to retrieve the enumerated "References Cited" (front-page) list for this patent in this session.

• Google Patents' full text of 7,478,429 (the authoritative copy I was given) is truncated before the front page reference list and does not expose the "(56) References Cited" section.
• The WIPO/PCT counterpart record (patents.google.com/patent/WO2006039529A3/en) renders headers reading "Patent Citations (40)" and "Cited By (286)", but the individual rows did not populate in my search retrieval. So I can confirm the aggregate counts (≈40 patent citations of record in the WIPO family; ≈286 forward "cited by" references) but not the identity of those 40 documents.
• I could not reach Justia, FreePatentsOnline's citation table, patentimages PDF page 1, or uspto.report's citation list before my step budget was exhausted.

Consequently I will not name specific patent numbers and assert they are "the citations for 7,478,429." Doing that would be fabrication. Every "X is cited in 7,478,429" statement on a public search hit that looked like a match (e.g., the string "7478429" inside the EAST search history of US 9,565,213 in IPR2018-01512, and in the file history exhibit of docketalarm.com/.../IPR2018-01512) is this patent appearing inside a search string / prior-art citation list of a different patent — the reverse direction. It tells you 7,478,429 is used as a reference by others, not what 7,478,429 itself cites.

---

3. Family / self-citations I can verify (with the §102 caveat for each)

These are the only "774,8429-adjacent" documents I could positively confirm. Note carefully: none is §102 prior art against 7,478,429, and I say why.

The SIP/VOIP documents (RFC 1889; RFC 2198; RFC 2543; RFC 3261–3265) and the mention of U.S. Pat. No. 6,728,728 appear in the CIP specification text (a pattern-recognition citation), not in the 7,478,429 text I was given. I therefore do not attribute them to 7,478,429's front page.

---

4. §102 framework grounded in the authoritative text I do have

Since I cannot enumerate the cited references, the defensible analytic move is to start from the patent's own admitted prior art — an applicant admission in the Background is usable as prior art and is fully quoted in the copy I was given — and then state what a single anticipating reference would have to disclose for each claim cluster.

4a. The patent's own admitted prior art (Background of the Invention)

The specification states prior systems "individually used or proposed different tools or software, sometimes in the form of so-called firewalls," including:

• "systems that detect half-open connections" (SYN-flood era);
• "systems that compare headers of packets to specific, known flood attack headers";
• "systems that monitor data packet flow that is above average or that exceed various thresholds";
• systems that "require identification of the source computers … as well as the target, to compare duplicate source and target values to threshold values at the network or lower layers of the OSI model."

It also expressly concedes the "broadcast amplification"/"smurf attack" and DDoS/DoS taxonomy are old. Any one of these admitted techniques, if it also taught the claimed ordering or the application-layer checks, would be the §102 target. The patent's stated point of novelty is precisely what those systems did not do.

4b. Claim clusters and the single-reference disclosure each requires

Anticipation standard reminder: under §102 a single reference must disclose every element as arranged in the claim. The most §102-fragile elements here are (1) the "removal before detection" ordering in claims 25/42/44 — a reference that detects first and mitigates second would not anticipate, only support §103 — and (2) the specific header-signature tests in claims 39–41 and the unverified 1–24, which are narrow enough that only a close reference disclosing that exact check could anticipate.

4c. Where the §102 answer most plausibly lives (field map, not a citation list)

Because I cannot name the 40 cited documents, I give you the search coordinates an examiner would have used, all of which fall in the pre-2004-10-01 window:

• Traffic-scrubbing / "cleaning center" architectures with in-vs-out rate comparison (the D_in/D_out÷P_in/P_out core) — the strongest §102 candidates for claims 25/42/44.
• Application-layer HTTP anomaly filtering (User-Agent / Host / line-break sanity, GET-flood counting) — candidates for claims 39–41 and unverified 1–24.
• DNS flood / rate-limiting front-ends with hit-count diversion — candidate for the DNS cluster (FIGS. 9–10).
• Reverse-proxy diversion with human-verification gating (cookie write; CAPTCHA) — candidate for the FIG. 8 redirection cluster.
  I am deliberately not printing patent numbers here, because in this session I could not verify which of them sit on 7,478,429's front page, and a wrong attribution would be worse than an acknowledged gap.

---

5. What I can state with high confidence vs. what I cannot

High confidence

• US 7,478,429 B2's bibliographic facts (§1) and that it is expired (adjusted expiration 2025-06-25), so it is a poor candidate for current assertion.
• The WIPO/PCT counterpart record reports ≈40 patent citations of record and ≈286 forward citations — but individual identities were not retrievable.
• The US 2006/0075084 A1 document is a same-family CIP, hence not §102 art against this patent.
• The patent's own Background admits firewall / half-open-connection / header-comparison / flow-threshold prior art; those admissions are the safest §102 anchors I can quote.

Cannot state / explicitly withheld

• The identity of the ~40 patent citations on the front page of US 7,478,429.
• Any claim-by-claim "Reference X anticipates claim Y" mapping, because that requires the enumerated list plus the full claim text (claims 1–24 remain unverified per the prior section).
• Whether any particular NPL (RFCs, etc.) is of record in this patent versus only in the CIP/relatives.

---

6. Targeted next steps to close the gap (in priority order)

1. USPTO Patent Public Search / PatentCenter, application 10/956,721 → "References Cited." This is the authoritative list; export the 56/57 blocks.
2. patentimages PDF page 1–2 of US 7,478,429 (patentimages.storage.googleapis.com/.../US7478429.pdf) — the "(56) References Cited" grid sits on the front page and was the one page I could not render.
3. Global Dossier / Espacenet for EP 1812867 — the EPO search report for the family will show the examiner's X/Y/A categories, which is the fastest proxy for which cited references actually threaten which claims.
4. Cross-check the retrieved list against the independent-claim clusters in §4b to produce the definitive per-reference §102 table.

If you can paste the front-page "References Cited" list (or let me re-run the search), I will complete the requested per-reference table — full citation, publication/filing date, one-line description, and the specific claim(s) each reference potentially anticipates under §102 — using the verified claim numbers rather than the currently unverified claims 1–24.

I'll attempt to retrieve the prior-art citation list associated with this record before analyzing, since the fetched page text did not include a formatted "Citations / Cited By" table.

Let me try to pull the actual "References Cited" table for this patent from patent databases.

Let me try to retrieve the patent's own front-page "References Cited" list.

Obviousness Analysis — U.S. Patent No. 7,478,429 B2 (35 U.S.C. § 103)

Building on the bibliographic record and claim identification already generated. Not repeating those sections.

---

0. Threshold Evidence Caveat — What the "Prior Art" Section of This Record Actually Contains

I must flag this explicitly rather than paper over it (operating rule: state uncertainty rather than fabricate).

The fetched Google Patents record for US 7,478,429 did not expose a formatted prior-art citation table. What the page actually contains under its "Prior art" headings is:

• "Prior art keywords": data, divided, computers, overload condition, time period — these are Google's algorithmically-extracted keyword tags, not a references-cited list.
• Classifications (CPC H04L63/1408, H04L63/1416, H04L63/1458 — DDoS countermeasures), which indicate the examiner's field of search but identify no reference.

The page's "Citations" (56) and "Cited By" (65) tables — the actual prior-art section — do not appear in the retrieved text; the record truncates in the Detailed Description (at "Referring now to FIG. 2…"). My follow-up searches recovered documents in which 7,478,429 is itself a cited reference (e.g., the IDS listing "7478429 B2 — 2009-01-13 — Lyon" in the file history exhibits of IPR2018-01444 (Cisco Ex. 1002), IPR2022-01199 (Keysight Ex. 1002-4), and IPR2021-01520 (Palo Alto v. Centripetal Ex. 1002), and the "$1,000" search-string listings in the 9,565,213 file history of IPR2018-01512). Those confirm the patent's role as prior art to others; they do not reveal what the examiner cited against it. I also hit a tool step limit before completing retrieval.

Accordingly, this §103 analysis is grounded in (a) the applicant-admitted prior art appearing in the specification itself — which is record evidence and citable under MPEP § 2129 — and (b) well-established prior art of record in the field as of the 2004-10-01 priority date, each identified by ordinary bibliographic description (RFC, paper, or product) so you can verify. Where I am not certain of a specific reference's bibliographic detail, I say so. Do not treat any reference below as confirmed-examiner-cited.

---

1. Legal Standard and Level of Ordinary Skill

Framework (Graham v. John Deere, 383 U.S. 1 (1966); KSR Int'l v. Teleflex, 550 U.S. 398 (2007)): (1) scope and content of the prior art; (2) differences between prior art and claims; (3) level of ordinary skill; (4) secondary considerations. Obviousness may be established by (A) combining prior-art elements according to known methods to yield predictable results; (B) simple substitution of one known element for another; (C) use of a known technique to improve a similar device in the same way; (D) applying a known technique to a known device ready for improvement; (E) "obvious to try"; and (F) design incentives/market forces (KSR; MPEP § 2143).

Level of ordinary skill (POSITA), as of October 2004: a person with a bachelor's degree in computer science/electrical engineering (or equivalent) and approximately 2–4 years of experience in network security and/or network operations, including familiarity with: TCP/IP, HTTP/1.1 (RFC 2616), router ACLs, traffic-monitoring tools (NetFlow, sFlow), L3/L4 firewalls and intrusion-prevention appliances, reverse proxies, web caching, and load balancers. This is a routine-engineering, commercially crowded art — a factor that favors obviousness under KSR.

Decision support: Nothing in my search results indicates a 2026 PTAB or court validity challenge to this patent; combined with the "Expired – Lifetime / adjusted expiration 2025-06-25" status already reported, this analysis is therefore academic/defensive rather than litigation-driven. Note the practical consequence: expired claims cannot be infringed, which is consistent with (though not proof of) the absence of assertion activity.

---

2. Claim Scope Assumptions

Per the prior section, I can positively identify independent claims 25, 42 (with 43), and 44 (with 45) and dependents 28–41. Claims 1–24 were not retrievable and remain unverified — the specification's Summary discloses at least five additional standalone inventions (duplicate-GET counting; User-Agent character check; Host-header check; CR/LF validation; redirection module) that are strong candidates for claims 1–24, and the DNS embodiment (FIGS. 9–10). This analysis covers the verified claims and the disclosed embodiments likely mapped to claims 1–24, and flags the latter as inference.

Two scope observations that shape the §103 analysis:

1. The "meter-based detection" claims (25, 44) recite detecting the mitigation, not the attack. The meter compares D_out/P_out to D_in/P_in and concludes an attack "has been mitigated" when the outbound rate is "substantially less." This is a measurement/differential-accounting invention layered on a filtering pipeline.
2. The drafting defects previously flagged (claim 25's apparent "P_out is equal to … P_out" recursion; claim 45 reciting "the system of claim 44" when claim 44 is captioned a method) are reproduced literally and are not corrected here. Claim 45's defect in particular would likely be resolved by a § 112(b) analysis, which can broaden or narrow effective claim scope for § 103 purposes — an important caveat.

---

3. Applicant-Admitted Prior Art (Record Evidence, MPEP § 2129)

The specification names and endorses the following as pre-existing, commercially available, or conventional — these are admissions:

This is decisive context: the applicant concedes that pre-2004 commercial appliances performed application-layer, deep-packet HTTP inspection with pre-configured DoS/DDoS signatures, and that threshold/rate-based flood detection was known. The claim 39–41 subject matter (duplicate GET counting, User-Agent check, Host-header check) sits squarely within the admitted IPS 5500 capability set ("normalized deep packet and multi-packet HTTP URL matching and wildcard checking"). That admission alone substantially undercuts the non-obviousness of the application-layer dependent claims.

---

4. Element-by-Element Prior-Art Mapping

I identify art by descriptor (not fabricated numbers). Confidence is noted.

---

5. Proposed Grounds of Rejection (Combinations and Motivation)

Ground 1 — Rate-monitored inline scrubber (targets claims 25 and 44)

Combination: Traffic-scrubbing/clean-pipe architecture (Riverhead/Cisco Guard-class, or the applicant-admitted Top Layer inline IPS placed in a filtered pipeline) in view of flow-based volume measurement (NetFlow/sFlow per RFC 3176).

Why obvious: Both elements are in the same field (network operations/DoS defense) and are commonly co-located — scrubbers and routers already expose ingress/egress byte counters. Placing a measurement point at ingress and egress of a scrubber is a simple substitution/known-technique step yielding the predictable result of a scrubbed-traffic rate differential. Motivations: (i) operators must periodically quantify scrubbing effectiveness and provision link capacity; (ii) alerting on effective mitigation is a natural operational need; (iii) the two meters share hardware already present. That the meter concludes "mitigated" when D_out/P_out is "substantially less" than D_in/P_in is the arithmetically necessary result of subtracting removed attack traffic — i.e., the claim recites the consequence of inline filtering, not a new mechanism (KSR rationales (A) and (C)).

The critical "removal before detection" ordering (25(c), 44(d)) is the weakest pillar of patentability: any inline filter that sits upstream of the egress measurement tap must filter before the tap reads. The applicant essentially claims the physical ordering forced by the disclosed architecture. Reordering known steps without a new technical result is an obvious design choice (cf. MPEP § 2144.04; In re Kuhle, 526 F.2d 553 (CCPA 1975) — mere sequence change absent new result).

Ground 2 — Backscatter/differential accounting as the detection metric (targets claim 44's arithmetic, and 28–31)

Combination: Ground 1 in view of Moore/Voelker/Savage, "Inferring Internet Denial-of-Service Activity" (2001), and general threshold-based anomaly detection.

Why obvious: The backscatter paper established that DoS activity can be inferred from differential traffic volumes on the wire. Applying that known inference technique to the ingress/egress of a scrubber yields the claimed D_in/P_in vs. D_out/P_out test with the known refinement of a baseline-derived threshold to avoid false positives — a routine tuning step the spec itself describes as conventional ("threshold value is determined from historical averages … during normal, non-attack time"). Adding cache-served bytes (D_cache) to the egress side (claims 28–31) is nothing more than correct bookkeeping for a caching proxy, which the applicant admits ("some of the data … is cached after it is cleaned").

Ground 3 — Application-layer HTTP misbehavior filtering (targets 39–41 and 43)

Combination: RFC 2616 HTTP/1.1 requirements (Host mandatory; User-Agent defined) in view of the applicant-admitted Top Layer IPS 5500 deep-packet HTTP URL/header matching and known proxy header-normalization.

Why obvious:

• Host-header existence check (claim 41): RFC 2616 § 14.23 already required Host in HTTP/1.1 requests and directed servers to reject non-compliant ones. Enforcing a protocol-mandated field at a filtering proxy is a predictable use of a known technique to reject malformed/attack traffic.
• User-Agent alphanumeric check (claim 40): Blocking requests with blank/garbage User-Agent strings is the same class of rule-based content filtering standard in security products; the applicant admits common viral attacks send non-alphabetical/blank UA entries — i.e., the problem, and its fix, were known.
• Duplicate-GET threshold (claim 39): Caching proxies already keyed requests by URL; counting duplicates and thresholding them is routine, and hashing to accelerate duplicate detection is admitted standard database practice in the spec itself ("hash, or reduction, function"). The IPS 5500's admitted "multi-packet HTTP URL matching" anticipates the detection logic.
• Motivation: KSR rationale (F) — market forces drove filtering up the stack precisely because spoofing at L3/L4 (a problem the spec admits) let attackers evade lower-layer detectors. The spec's own background states prior art left "higher levels of the OSI model … vulnerable"; that is an express design incentive to apply known HTTP filters at the application layer.

Ground 4 — Proxies and load balancing (targets 37–38, 43)

Combination: Ground 3 in view of LVS/LocalDirector/F5/BIG-IP-type load balancing (or the applicant-admitted Radware WSD) and reverse proxies.

Why obvious: Reverse proxies and load balancers for a server farm were ubiquitous by 2004; distributing scrubbed traffic across multiple reverse proxies and load-balancing them is a known technique applied to a similar system for the same purpose (fault tolerance/scalability), with predictable results.

Ground 5 — Redirection anti-latency embodiment (targets likely claims 1–24, UNVERIFIED)

Combination: HTTP 3xx redirects / DNS redirection (RFC 2616) in view of known "send initial traffic to a screening proxy, then direct traffic to the origin once cleared" workflows (standard in reverse-proxy/security-proxy setups).

Why obvious: Redirecting a client to an alternate host (www ↔ www*n*) and letting subsequent traffic bypass the proxy once verified is a predictable variation on known proxy-redirection. The applicant's own latency discussion is an admission that the latency problem was known; the cookie-write test and CAPTCHA-style challenges were known browser-vs-bot discriminations (the spec cites Yahoo!'s then-current human-verification challenge by name).

---

6. Anticipation Alternative (§ 102)

For the narrowest independent claims, consider whether a single clean-pipe/scrubbing reference discloses all elements. A traffic-scrubbing system that measures ingress and egress and filters inline may anticipate claim 25 if its documentation describes the rate comparison. In practice, the meter-as-detector framing probably makes pure anticipation harder than § 103 — most scrubber art describes filtering but may not expressly recite the D_in/P_in vs. D_out/P_out comparison as a detection act. Hence § 103 is the more robust theory, and the strongest single-reference argument is that the claim recites the inherent arithmetic consequence of filtering (anticipated under In re King, 801 F.2d 1324 (Fed. Cir. 1986), if necessarily present).

---

7. Anticipated Applicant Rebuttals and Responses

---

8. Confidence, Gaps, and Verification Steps

• Confidence the verified claims are obvious over the art described: moderate-to-high, driven chiefly by (i) the applicant's own admissions (Top Layer IPS, ACL filtering, caching, hashing), (ii) RFC 2616's Host requirement, and (iii) the KSR-friendly, crowded nature of the art.
• Primary gap: I could not retrieve 7,478,429's own "References Cited / Cited By" tables, so the specific examiner-cited art is unknown to me in this session. Do not cite any reference above as "cited by the examiner."
• Unverified claims 1–24 (likely the DNS and redirection independent claims): my §103 reasoning for those is inference-based and must be re-run against the actual claim text.
• Drafting defects (claim 25's P_out recursion; claim 45's "system of claim 44") will materially affect claim scope; a § 112(b) analysis should precede any final § 103 opinion.

To close the gap, run: (1) Google Patents / Espacenet "Citations" and "Cited By" tables for US 7,478,429; (2) USPTO PatentCenter file wrapper for App. 10/956,721 (PTO-892/1449 forms); (3) the family members' file histories (US 11/241,470; 12/251,723; 13/734,104), which may carry the DNS/redirection claims and their own cited art; and (4) the sibling EP1812867 EPO search report (European search reports often identify art the U.S. examiner did not).

Sources grounding this analysis: Google Patents record for US 7,478,429 (https://patents.google.com/patent/US7478429/en); the specification passages quoted above; RFC 2616 (HTTP/1.1, 1999); RFC 3176 (sFlow, 2001); RFC 1035 (DNS, 1987); Moore, Voelker & Savage, "Inferring Internet Denial-of-Service Activity," USENIX Security 2001; IPR file-history exhibits showing "7478429 … Lyon" as a cited reference (IPR2018-01444, IPR2022-01199, IPR2021-01520) and the 9,565,213 file-history search listing (IPR2018-01512), all via docketalarm/ptabdata/ptacts.