Invalidity dossier

US 7684400

Logarithmic time range-based multifield-correlation packet classification

Current assignee: Tahoe Research Ltd

Added 9/24/2026, 4:55:02 PM

At a glanceNo PTAB challengesNo litigation on fileSoftware Technology & Computing Systems (T)

Active provider: DeepSeek · deepseek-v4-flash

Auto-generating section 1 of 2: Extensions…

Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.

Patent summary

Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.

✓ Generated

I'll search for this patent's records and any 2026 litigation activity.

Now let me check for 2026 litigation/CAFC activity specifically.

A couple more checks for any active litigation or PTAB/CAFC proceedings.

Summary — US 7,684,400 B2

Search scope note: I ran targeted searches against indexed USPTO/Google Patents, FreePatentsOnline, Justia, Unified Patents, and Docket Alarm/PTAB material. I found no CAFC 2026 docket, appeal, or district-court action naming U.S. Patent 7,684,400 as an asserted patent. Every hit for the number was as a cited reference (prior art / IDS entry) in other parties' patents and PTAB proceedings (e.g., Centripetal Networks IPRs). I cannot rule out a very recent or unindexed filing, but there is no search evidence of 2026 Federal Circuit activity for this number. Treat the litigation-absence finding as "no evidence found," not as an affirmative negative.


Bibliographic data (from the authoritative full text at patents.google.com/patent/US7684400/en)

Field Value
Patent number US 7,684,400 B2
Title "Logarithmic time range-based multifield-correlation packet classification"
Application no. US 10/216,051
Filing date 2002-08-08
Pre-grant publication US 2004/0028046 A1, published 2004-02-12
Issue/grant date 2010-03-23
Inventors Priya Govindarajan; Chun Yang Chiu; David M. Durham
Original assignee Intel Corporation (assignment recorded 2002-10-09, effective 2002-09-12)
Current assignee Tahoe Research, Ltd. (assignment from Intel effective 2022-07-18, recorded 2022-08-15)
Legal status Active; adjusted expiration 2026-12-02 (per Google Patents legal-status data)
Claims 26 total
Family members DE 10393053 B4; GB 2408169 B; HK 1073026 B; WO 2004/015937 A2; AU 2003261356 A1 (abandoned)

Identifier discrepancies to flag (not auto-corrected): Unified Patents' record for US-7684400-B2 lists a priority date of 2002-08-07, a grant date of 2010-03-22, and expiration 2026-12-01, whereas Google Patents lists 2002-08-08, 2010-03-23, and 2026-12-02. These one-day differences likely reflect time-zone/legal-status-table artifacts rather than substantive disagreement, but I am reporting them as found.

Abstract

"Classification of network data packets includes a determination sets of one or more filter-identifiers where each set is associated with a respective data-packet classifier field. A result-set of filter-identifiers may be derived based on an intersection of the filter-identifier sets."


Independent claims in plain language

There are six independent claims: 1, 8, 10, 16, 18, and 24. Claims 10/16 are article-of-manufacture versions of claims 1/8 respectively; claim 18 is an apparatus version of claim 1; claim 24 is a system version of claim 1. So substantively there are two distinct inventions.

Claim 1 — Method (filter-identifier + bit-mask correlation)

  • Create a filter-identifier for a packet-header field based on its filter elements. The filter-ID is expressly not the policy-ID (the policy-ID is what names a policy applicable to packets with given field entries).
  • Label each specified field entry as either a range-based value (a multi-value range) or an exact value.
  • Build a bit mask where one bit corresponds to each filter element: set to a first logical value if that element is range-based, a second, different logical value if it is exact.
  • Build one set of filter-IDs per filter element.
  • Output a result-set from the intersection of those per-element filter-ID sets.

Claim 8 — Method (two policy-ID sets per tree node)

  • Create a tree of node values, one node per endpoint value of each policy-ID's ranges.
  • Store a first set of policy-IDs at a node: these apply to packets whose classifier field exactly matches that node value (the spec calls this the "exact-match set").
  • Store a second set of policy-IDs at the same node: these apply to packets whose field value lies between that node and the next higher node (the "range-based set").
  • Claim 9 (dependent) specifies that the second set is derived as the set intersection of the first set and the first set at the next higher node — this is the pre-computation that happens at policy-install time rather than per-packet.

Claim 10 — Article of manufacture (machine-readable medium)
Recites a non-transitory machine-readable medium with instructions performing the claim 1 sequence: generate the filter-ID (distinct from the policy-ID), characterize entries as range-based or exact, generate the bit mask, set bits to the first/second logical values, determine per-filter-element sets of filter-IDs, and produce an intersection-based result-set.

Claim 16 — Article of manufacture (machine-readable medium)
The claim 8 sequence in instructions form: generate tree node values from policy-ID endpoint values; associate the exact-match first set with a node; associate the range-based second set (values between that node and the next higher node). Claim 17 adds the intersection-derived second set per claim 9.

Claim 18 — Apparatus
A network interface adapter plus four (through claim 19, five) separately claimed circuitry elements:

  • first circuitry — generate the filter-ID distinct from the policy-ID;
  • second circuitry — characterize entries as range-based/exact, generate the bit mask, set its bits to the first/second logical values;
  • third circuitry — determine per-filter-element sets of filter-IDs;
  • fourth circuitry — produce the intersection-based result-set.
    Note the mixed drafting (gerund phrases "characterizing/generating/setting" within an apparatus claim) — this is unusual claim language that could invite a §112 clarity challenge, though I express no opinion on validity.

Claim 24 — System
A network plus a network device communicatively coupled to it, the device having a processor and instructions causing the same claim 1 functional sequence.

Independent-claim family pattern

The dependent claims copy the same limitations across the method/article/apparatus/system families, adding in parallel: filter-ID↔policy-ID association (2, 11, 19, 25); the select-a-search-ID / search-the-other-sets / add-if-found-elsewhere iteration (3, 12, 20, 26) and its repetition until a set is exhausted (4, 13); hierarchical ordering with searching from highest to lowest value (5, 14, 21); and picking the lowest of the per-set maximum filter-IDs as the initial search-ID and the next-highest-not-exceeding value thereafter (6–7, 14–15, 22–23).

Technical gist (why the patent matters)

The disclosure teaches classifying packets against range-based (not just exact/wildcard) filter fields while keeping per-field lookup near O(log n). It does this two ways: (a) pre-computing per-node exact-match and range-based policy-ID sets in red-black-tree nodes so intersection work is done at install time, and (b) assigning bit-masked filter-IDs that are sorted and intersected as ordered sets, letting the classifier skip logically non-applicable filter-IDs and avoid the O((log n)·n) worst case (see FIGS. 8–11 worked examples, and the "12-policy / 2-filter-element" walkthrough yielding result set {P4(132), P9(73)}).

Uncertainty declaration: All bibliographic and claim content above is taken from the authoritative full patent text supplied and corroborated by third-party indexes. The only material uncertainties are (i) the one-day date discrepancies noted above, (ii) the exact current post-2026-12-02 status if the term is later adjusted or a terminal disclaimer is filed, and (iii) any 2026 CAFC docket activity, for which I found no evidence and therefore make no assertion.

Generated 9/29/2026, 5:22:13 PM

Cases on file (0)

Specific litigation cases in our database that name US patent 7684400. The free-form analysis below may also discuss cases beyond this list.

No cases on file mention this patent. Upload a CSV or add a case manually in Admin → Manage litigation cases.

Litigation summary

Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.

✓ Generated

I'll search for litigation involving US patent 7684400.

Let me search the litigation portals and other sources more specifically.

Let me search a few more targeted sources.

Litigation Search Results: US Patent No. 7,684,400

Answer: No litigation involving US 7,684,400 was found.

Based on my searches of the Unified Patents litigation portal (portal.unifiedpatents.com), the Docket Alarm database, and general web sources, I could not identify any district court, ITC, or Federal Circuit (CAFC) litigation in which US Patent No. 7,684,400 has been asserted. The patent does not appear in any publicly indexed infringement complaint, and no CAFC appeal docketing the patent number was located.

What the searches did return

1. Unified Patents patent record (not litigation)

  • The Unified Patents portal has a record page for the patent: US-7684400-B2 – "Logarithmic Time Range-based Multifield-correlation Packet Classification." https://portal.unifiedpatents.com/patents/patent/US-7684400-B2
  • This is a bibliographic/portfolio record only. Notably, the record lists:
    • Original Assignee: Intel Corp
    • Current Parent Company: Tahoe Research Ltd
    • Status: "Likely Sold"
  • No litigation section or case entries are associated with this patent on that page.

2. Docket Alarm hit — a false positive worth flagging

  • A Docket Alarm document (Exhibit 1002, file history of US Patent No. 9,565,213) contains a reference table listing "7684400 … Govindarajan et al." That document is part of IPR2018-01512 (Inter Partes Review of U.S. Pat. No. 9,565,213, a Centripetal Networks patent). US 7,684,400 appears there only as a cited prior-art/background reference, not as an asserted patent. I did not treat this as litigation involving the '400 patent.

3. Ownership/transactional activity (not litigation)

  • Intel transferred a portfolio of roughly 5,000 patents (about 3,419 US patents) to Tahoe Research, Ltd. (an IPValue Management affiliate) in 2022 — consistent with the assignment to Tahoe Research, Ltd. recorded for the '400 patent effective 2022-07-18.
  • Samsung Electronics reportedly took a broad license to Intel-origin patents held by Tahoe Research (news reports, ~mid-2025). This is licensing, not litigation, and no source ties US 7,684,400 specifically to any enforcement action.
  • A September 2026 NPE suit (Powerwatch Systems LLC v. Nanya Technology, E.D. Tex., filed ~2026-09-24) asserts US 7,281,079 and US 7,432,731 — both also Intel/Tahoe-origin patents — but neither is US 7,684,400, so that case is not litigation involving this patent.

Caveats on completeness

  • I do not have live access to PACER for a full docket-keyword sweep, and RPX Insight's paywalled litigation records were not retrievable in this session. Some very recent (2026) complaints could exist that are not yet indexed by the free sources searched.
  • The patent is legally active with an adjusted expiration of 2026-12-02, so it remains enforceable for a short window — but "active status" is not evidence of litigation.

Bottom line

On the available public record, US Patent No. 7,684,400 has not been asserted in any known litigation. Its only relevant recent activity is the 2022 assignment to Tahoe Research, Ltd. and associated portfolio licensing — not enforcement.

If you need a court-verified negative, I'd recommend a direct PACER/RPX Insight "patent number" docket search, since those authoritative databases were not fully queryable here.

Generated 9/29/2026, 5:22:14 PM

Proceedings on file (0)

All PTAB activity →

AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.

No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.

PTAB challenges

AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.

✓ Generated

Proceedings overview

Zero AIA trial proceedings have ever been filed against US 7684400 — the USPTO Open Data Portal / PTAB structured feed returns no IPR, PGR, or CBM for this patent, and targeted web searches surfaced no petition, institution decision, or Final Written Decision naming 7684400 as the challenged patent. Breakdown by status: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0. The defensive posture this gives a defendant is "the patent is PTAB-untested, so nothing is canceled — but nothing is confirmed valid either." You cannot point to a canceled claim to defeat a demand; conversely, the patent owner cannot point to a PTAB win. There is no § 315(e)(2) estoppel on file against anyone, and the entire prior-art universe remains available to you. One non-PTAB fact dominates the strategy: per the structured record, the patent is active but expires 2026-12-02 (adjusted expiration), i.e., roughly two months from today.

No proceedings to itemize

Because the canonical structured list is empty, there are no {PROCEEDING_NUMBER} — {Petitioner} v. {Patent Owner} entries to report. Reporting the absence is the finding; I will not invent docket numbers, panels, or claim dispositions.

What the searches did surface is only evidence that 7684400 is cited as prior art by other parties — not evidence that it was itself challenged:

Direct verification points, both of which come back empty for this patent:

Strategic summary

Claim status. Claims 1–26 all stand untested and unamended. There is no certificate of cancellation, no adverse judgment, no certificate of correction narrowing them, and no statutory disclaimer on this record. Claims 1 and 10 are the method/article claims built on the filter-identifier-plus-bit-mask generation; claim 8 and claim 16 are the two-set (exact-match / range-based) tree claims; claim 18 is the apparatus claim and claim 24 the system claim. Every one of those reads on the specification's Figures 2–13 approach. For a defendant, this means there is no "safe" claim to design around by default and no invalidity shortcut already adjudicated — but also that no claim has been blessed by an Article III or APJ tribunal, so validity is genuinely open.

Estoppel landscape. Because nobody has filed an IPR/PGR against 7684400, § 315(e)(2) estoppel is not in play — there is no petitioner or privy barred from raising anything. You can assert all prior art, including art that a hypothetical prior petitioner "raised or reasonably could have raised." Practically the more important estoppel constraint runs the other way: the patent owner's statements in other litigations (this patent sits in the Intel → Tahoe Research portfolio alongside heavily litigated Centripetal-adjacent networking patents) could supply prosecution-history or IPR-record disclaimers, so pull the full file wrapper and the family members (WO2004015937A2, DE10393053B4, GB2408169B, HK1073026B) before locking a claim-construction position. Note also the FRAND/prosecution-history angle: the patent issued from US10/216,051 (filed 2002-08-08, priority 2002-08-08) with no intervening reexamination or reissue in the record, so the claims are frozen in their original form.

Pattern signals. No repeat petitioner, no defensive aggregator in the chain, no PTAB appeal history — because there is no proceeding at all. The "well-asserted patents attract IPRs" heuristic cuts sharply here: an 24-year-old patent (filed 2002-08-08) that has never once been IPR'd despite being cited in five-plus third-party IPR file histories suggests it was never asserted with enough commercial bite to justify the filing fee, or that the relevant art is old enough that § 102(b) art is abundant and cheap to find. Both readings favor a defendant.

Recommended next steps

  • Lead with the expiration date. Per the structured record the patent's adjusted expiration is 2026-12-02. As of today (2026-09-29) that leaves approximately nine weeks of enforceable term. Any injunction demand is effectively moot at the pleadings stage, and damages exposure is capped at pre-expiration acts within the § 286 six-year lookback (i.e., acts from 2020-09-29 forward). Get an independent term/PTA calculation confirmed before relying on this.
  • No FWD exists to quote. There is no final written decision, no claim-level cancellation, and no Federal Circuit appeal — so there is nothing to cite in a motion to stay or a § 282 invalidity contentions chart as an adjudicated disposition. Say that plainly to your client rather than implying PTAB success.
  • IPR is not a practical defense here. Even if you filed tomorrow, a petition cannot reach an FWD before the 2026-12-02 expiration, given the ~3-month pre-institution window plus the § 316(a)(11) one-year statutory deadline from institution. The realistic post-grant lever, if any, is ex parte reexamination (claims 1–26, art under § 102/§ 103), which has no estoppel and is not subject to the AIA trial clock — but even that will not resolve before expiry.
  • Verify the negative yourself before you rely on it. Run the patent number through PTAB E2E and the PTAB Decisions search (links above) and re-check the ODP feed, since ODP ingest lags and a recently filed petition could be unindexed. If a petition does appear, it will be captioned {Petitioner} v. Tahoe Research, Ltd. (assignee of record since 2022-08-15, per reel/frame 061175/0176) — the same entity that now holds the Intel networking portfolio.
  • Flag for the record: I found no litigation docket, no assertion campaign, and no damages demand involving 7684400 in the sources searched. If your client received a demand letter citing this patent, that assertion is the only data point of its kind and is worth reporting back — it materially changes the "never asserted" heuristic above.

Confidence note: High confidence that no AIA trial proceeding exists for US 7684400 as of the structured data's ingest date, corroborated by independent web searches. I did not find any PTAB document — petition, institution decision, FWD, settlement, or CAFC appeal — for this patent, and I have not stated one.

Generated 9/29/2026, 5:22:26 PM

Ownership chain (2)

Asserters network →

Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.

  1. 2002-09-12 · recorded 2002-10-09 · reel 013374/0275 · Assignment

    Chun Yang Chiu; David M. Durham; Priya GovindarajanIntel Corporation

  2. 2022-07-18 · recorded 2022-08-15 · reel 061175/0176 · Assignment

    Intel CorporationTahoe Research, Ltd.

    transfer-to-asserter

Assignment history

Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.

✓ Generated

I'll verify the assignment chain and check for assertion activity before writing up.

Key finding: Tahoe Research Ltd. is an IPValue Management Group licensing entity. Let me check for assertion activity on this specific patent and the correspondent of record.

Let me check for any litigation on this patent and the recording correspondent for the Tahoe transfer.

Inventors

Inventor Employer at filing Basis
Priya Govindarajan Intel Corporation Named assignor on reel 013374/0275; assignment runs to Intel
Chun Yang Chiu Intel Corporation Same assignment record
David M. Durham Intel Corporation Same assignment record

All three executed the assignment to Intel on 2002‑09‑12 (recorded 2002‑10‑09, reel 013374/0275), the standard employee‑invention assignment. The patent (US 7684400 B2, "Logarithmic time range‑based multifield‑correlation packet classification") was filed 2002‑08‑08 and issued 2010‑03‑23.

Unusual patterns: none detectable. I found no evidence that any inventor left Intel within 12 months of filing, and no reissue, continuation‑in‑part, or later inventor‑initiated assignment involving these three names. Note that two Google Patents / Unified Patents metadata fields disagree trivially on dates (Google: priority 2002‑08‑08, issue 2010‑03‑23, expiry 2026‑12‑02; Unified Patents portal: priority 2002‑08‑07, grant 2010‑03‑22, expiry 2026‑12‑01) — this is a time‑zone/format artifact and does not affect ownership.

Original assignee

Intel Corporation (Santa Clara, California), the entity named on the issued patent.

  • Line of business: operating semiconductor designer/manufacturer (microprocessors, chipsets, networking silicon, connectivity). It is a public company (NASDAQ: INTC).
  • Did it ship a product embodying the claims? Not established from the record. The claimed subject matter — range‑based multi‑field packet classification using balanced binary trees and filter‑ID set intersection — is consistent with Intel's networking‑silicon line of that era (e.g., IXP network processors), but nothing in the patent, its file history as surfaced, or the assignment record identifies a specific commercial product. I will not assert embodiment without evidence.
  • Current status: operating, in the middle of a large restructuring/patent‑pruning program; not in bankruptcy. Its relevant status here is as the former owner: Google Patents (fetched 2026‑09‑24) lists Tahoe Research Ltd as current assignee, i.e., Intel no longer holds this patent.

Assignment timeline

Two post‑filing assignment events are recorded. The Assignment Center record itself was not directly queryable from here; the entries below are grounded in the Google Patents legal‑events rendering of the USPTO assignment data and independently corroborated for the 2022 link via Espacenet INPADOC (event date 2022/08/15, effective date 20220718, new owner "TAHOE RESEARCH, LTD., IRELAND", "REEL/FRAME:061175/0176").

  • 2002‑09‑12 (executed) / recorded 2002‑10‑09 — Reel 013374/0275

    • Conveyance: Assignment
    • Assignor: Chun Yang Chiu; David M. Durham; Priya Govindarajan (individual inventors)
    • Assignee: Intel Corporation (California)
    • Correspondent: not available in the sources I could reach. Google Patents renders the reel/frame and parties but not the recording correspondent, and my search for the reel string returned only INPADOC legal‑status data. I am flagging this as unknown rather than guessing.
    • Context: ordinary employee‑invention assignment at filing — this is the original assignment, not a transfer.
  • 2022‑07‑18 (executed) / recorded 2022‑08‑15 — Reel 061175/0176

    • Conveyance: Assignment
    • Assignor: Intel Corporation
    • Assignee: Tahoe Research, Ltd. (Ireland)
    • Correspondent: not available in the sources I could reach (same limitation as above). Note that the recor­ding‑agent identity is exactly the kind of data the Assignment Center UI exposes; a manual screen in the Assignment Center is required to populate it.
    • Context: portfolio monetization / transfer‑to‑licensing vehicle. This is one asset in a bulk conveyance of ~4,900–5,000 Intel patents (3,419 US patents) announced 2022‑08‑08 to IPValue Management, Inc. IPValue stated the portfolio was transferred to "Tahoe Research Limited, a newly formed company within the IPValue Management Group," which would license it to IPValue's licensee network (IPValue press release, https://www.ipvalue.com/news/ipvalue-acquires-a-major-patent-portfolio-from-intel). IAM reported the same deal on 2022‑08‑08 (https://www.iam-media.com/organisations/intel). This is not an Intel affiliate — Tahoe sits under IPValue, not under Intel.

No further assignment is recorded for US 7684400. As of the Google Patents fetch on 2026‑09‑24 the current assignee is still Tahoe Research Ltd, and the Unified Patents portal entry for US‑7684400‑B2 (https://portal.unifiedpatents.com/patents/patent/US-7684400-B2) shows Original Assignee "Intel Corp," Parent Company "Tahoe Research Ltd," Current Assignee blank, and flags the asset "Likely Sold."

Timeline diagram

timeline
    title Ownership of US 7684400
    2002 : Filed by Intel inventors
         : Inventors assign to Intel Corp
         : Reel 013374 frame 0275
    2010 : Patent issued
    2022 : Intel transfers portfolio to IPValue unit
         : Assignee becomes Tahoe Research Ltd
         : Reel 061175 frame 0176
    2026 : Patent reaches adjusted expiry

NPE / troll-pattern signals

1. Shell-entity transfer — present.
Evidence: reel 061175/0176, executed 2022‑07‑18, recorded 2022‑08‑15, moves the patent from Intel Corporation (an operating manufacturer) to Tahoe Research, Ltd., a company IPValue itself describes as "a newly formed company within the IPValue Management Group" existing to license the acquired portfolio. IPValue is a Santa Clara IP‑licensing business; the entity holds no products. Caveat against over‑reading the name: "Tahoe Research" carries none of the "IP / Holdings / Ventures" suffixes the brief flags, and it is an Irish entity rather than a single‑member Delaware/Texas LLC — the finding rests on the disclosed function (newly formed licensing vehicle for a bulk divestiture), not on naming.

2. Known asserter in the chain — present.
Tahoe Research Ltd is not on the enumerated list, but its parent group is squarely in the monetization/assertion business: RPX's April 2022 Essentials guide names IPValue Management among the "targeted IP investment firms" that fund NPE litigation (https://conferences.law.stanford.edu/ip-law-and-the-biosciences-conference/wp-content/uploads/sites/120/2022/09/RPX-Essentials-Quick-Guide-to-Third-Party-Litigation-Funding.pdf), and IAM reported that IPValue's entities had filed 32 litigation actions since 2008. The assertion pattern is now concrete: on 2026‑09‑24 Powerwatch Systems sued Nanya in the Eastern District of Texas on US 7,281,079 and US 7,432,731 — two patents from the same Intel→Tahoe portfolio — after Tahoe pushed them through Southfork IP Holdings in Aug‑Sep 2026 (report: https://zdnet.co.kr/view/?no=20260928015236). Tahoe Research Ltd is therefore an assertion‑capable owner, even though this particular patent has not been asserted.

3. Repeat correspondent across the chain — unclear / insufficient data.
I have two chain links and zero correspondent records: neither Google Patents nor the INPADOC legal‑status record exposes the recording correspondent, and searching reel 061175/0176 surfaced only the INPADOC event data. A recurrence finding is impossible on this record. This is the single biggest data gap in the chain and the item to resolve with a manual Assignment Center pull.

4. Cascading transfers — not present for this patent.
US 7684400 shows exactly one post‑issuance hop (Intel → Tahoe, 2022) and has sat at Tahoe for over four years. Contrast the sibling assets US 7,281,079 / US 7,432,731, which Tahoe → Southfork IP Holdings → Powerwatch Systems moved in roughly two months (Aug‑Sep 2026) ahead of the Nanya complaint. The cascading pattern exists in the portfolio but has not been applied to this patent.

5. Pre‑litigation transfer — not present.
No infringement action naming US 7684400 was found. The 2022 transfer predates the 2026 Powerwatch campaign by ~4 years, and US 7684400 was not part of it. The Docket Alarm hits for the string "7684400" are the patent appearing in other parties' exhibits (IDS/claim‑chart material in the Cisco v. Centripetal and Centripetal‑related IPR filings) — citations, not suits. Practical point: the patent's adjusted expiration is 2026‑12‑02, roughly two months out, so an assertion campaign on this asset is commercially implausible now.

6. Bankruptcy fire‑sale — not present.
Intel did not file Chapter 7 or 11, and this was a negotiated portfolio divestiture (IPValue characterized it as extending an existing licensing arrangement with Intel), not a court‑supervised asset sale. Intel's motives were reported as cost avoidance, de‑risking, and monetizing non‑core IP while funding AI/advanced‑manufacturing filing, per trade coverage of the Aug 2022 deal.

7. Privateering — present at the portfolio level.
Intel, an operating company highly critical of NPEs, placed ~5,000 patents with IPValue's newly formed entity, which monetizes them against the industry — with Samsung taking a defensive license in June 2025 via IPValue affiliate Longitude Licensing (https://www.ipvalue.com/news/ipvalue-affiliate-licenses-samsung-to-patent-portfolio-acquired-from-intel) and IPValue‑linked Powerwatch Systems suing Nanya in Sept 2026. The economic‑participation detail (whether Intel retains a back‑end share of recoveries) is reported only by secondary commentary (Techdirt, https://www.techdirt.com/company/tahoe-research-limited/), not by filings, so I treat the "Intel takes a royalty cut" element as unconfirmed; the transfer‑to‑monetizer structure itself is confirmed.

8. Defensive aggregator — not present.
The chain terminates at Tahoe Research, Ltd., a licensing/monetization entity. It does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Unified Patents appears in this file only as a data source (its patent portal page), not as an owner. The asset is not neutralized.

Verdict

NPE — high confidence.

Two strong, independently documented signals: (i) a shell/vehicle transfer from an operating manufacturer to a licensing-only company — Intel → Tahoe Research, Ltd., executed 2022‑07‑18 and recorded 2022‑08‑15 at reel 061175/0176, a newly formed IPValue Management Group entity that IPValue itself describes as a portfolio‑licensing vehicle; and (ii) a monetization/assertion‑driven parent — RPX lists IPValue Management as a third‑party funder of NPE litigation, and IPValue‑affiliated entities have both licensed defensively (Samsung, June 2025) and sued (Powerwatch Systems v. Nanya, E.D. Tex., filed 2026‑09‑24). The counterweight is specific to this asset: US 7684400 has no recorded onward transfer, no identified lawsuit, and reaches adjusted expiry on 2026‑12‑02, so it is an unassertable‑in‑practice tail asset rather than a live campaign patent. The correspondent field is empty on both links, which is the one gap a manual Assignment Center pull should close.

Verification links:

Caveat on sourcing: I was unable to execute a query directly against the Assignment Center interface; reel/frame, dates, parties, and conveyance types above are taken from the Google Patents legal‑events rendering of the USPTO assignment records, with the 2022 entry corroborated by Espacenet INPADOC. Both correspondent entries are genuinely unknown to me — I have deliberately not inferred an attorney or firm name, and any correspondent‑recurrence analysis must wait on a direct Assignment Center pull.

Generated 9/29/2026, 5:22:49 PM

Prior art

Earlier patents, publications, and products that may anticipate or render the claims unpatentable.

✓ Generated

I'll verify the USPTO record and examine the prior-art references cited on the face of US 7,684,400.

Let me pull details on the references with the strongest §102 potential — particularly the bit-mask references and the two-field classification patents.

Let me verify a couple of the strongest candidates and confirm the USPTO record directly.

Prior-Art Analysis — US 7,684,400 B2

"Logarithmic time range-based multifield-correlation packet classification"


0. Scope, method, and a flagged discrepancy

Search performed: USPTO-facing records reachable in this session — the USPTO front-page image of the granted patent (patentimages.storage.googleapis.com/.../US7684400.pdf, which reproduces the official "(56) References Cited" block, the "(45) Date of Patent: Mar. 23, 2010," the "(21) Appl. No.: 10/216,051" and the "26 Claims, 11 Drawing Sheets" lines), Google Patents' US7684400B2 record, and Unified Patents' US-7684400-B2 record ("Patent Art (35) / Non-Patent Literature (4)"). I was not able to complete a live Patent Center / Patent Public Search file-wrapper query before exhausting my tool budget, so the underlying examiner's rejection record (which reference was used against which claim, under §102 vs. §103) is not directly verified. Treat the claim mappings below as my analytical assessment, not as a report of the examiner's actual rejections.

⚠️ Date discrepancy to flag: this task states the current date as April 26, 2026. My operating context and the previously generated sections of this analysis are dated 2026-09-29 / 2026-09-24. I am not resolving this silently — it is flagged here. It does not affect the prior-art analysis, since all cited art predates the 2002 filing.

Builds on prior sections (not repeated): bibliographic table, ownership (Intel → Tahoe Research, Ltd., effective 2022-07-18), the Unified Patents one-day discrepancies (2002-08-07 vs. 2002-08-08; 2010-03-22 vs. 2010-03-23; 2026-12-01 vs. 2026-12-02), the six-independent-claim structure (1, 8, 10, 16, 18, 24), and the litigation-absence finding. All of that is carried forward unchanged and no contradiction was found.


1. Legal framework applied (this matters for every row below)

US 7,684,400 was filed 2002-08-08, so pre-AIA 35 U.S.C. §102 governs. Because the application was filed before 2003-03-15 and never appears to have been substantively reexamined, no AIA §102(a)(1)/(a)(2) analysis applies.

Practical consequences for the citations:

Subsection Trigger Critical date here
§102(a) patented/published/known or used before applicant's invention ≤ 2002-08-08 (publication practice commonly uses filing date)
§102(b) patented or published more than 1 year before US filing before 2001-08-08
§102(e) described in a US patent or US pre-grant publication that was filed before applicant's filing date (pre-AIA §102(e), incl. the 2000-11-29 amendment), regardless of its later publication reference's filing/priority date < 2002-08-08

Two hard rules I applied literally:

  1. Anticipation requires every limitation in a single reference, arranged as claimed. A reference that discloses, say, only the set-intersection step cannot anticipate claim 1, which also requires the range/exact characterization and the per-element bit mask.
  2. Anything filed after 2002-08-08 is simply not §102 prior art to this patent. Three cited documents fail this test (see §5).

2. Bottom line up front

No citation on the face of US 7,684,400 is a clean §102 anticipation of any of the 26 granted claims. The two closest calls are the Lucent/Lakshman–Stiliadis interval-bitmap family (US 6,289,013 and US 6,341,130) against claim 8 (and its mirrors 16, plus dependents 9/17), because those references pre-compute, per interval endpoint, the set of filter rules that survive into that interval — structurally the same idea as the claimed "range-based set." They still miss claim 1's bit-mask limitations entirely.

The Broadcom bit-mask family (US 2002/0152209 A1 and EP 1 227 630 A2) is the most relevant art to the bit-mask element of claims 1/10/18/24, but its mask is a hash/bit-extraction key, not a per-field range-vs-exact flag mask — which is the actual point of novelty. It reads as §103 art, not §102.

Two references are of unusually high interest on timing rather than on completeness: US 2002/0023080 A1/EP 1 180 882 A2 (NTT, published 2002-02-20/21) and US 2004/0022243 A1 (Jason, filed 2002-08-05 — three days before the '400 application).


3. Full citation list with per-reference §102 assessment

All 35 patent documents from the "Patent Citations (35)" block. "Pub/Issue" is the document's own publication or grant date; "Filed/Prio" is its filing or priority date. §102 rating is my assessment of exposure; claim numbers are granted-patent numbers (1–26).

# Citation Filed / Priority Pub / Issue Assignee (as listed) Brief description §102 exposure (my assessment)
1 US 6,041,053 A 1997-09-18 2000-03-21 Microsoft Packet classification via a trie-indexed hierarchy forest that accommodates wildcards §102(b) art. Low. Only tangentially reaches cl. 8/16 (node/forest structure); no policy-ID sets, no bit mask
2 US 5,956,721 A 1997-09-19 1999-09-21 Microsoft Classifying network packets processed in a network stack §102(b) art. Background only; no claim reads on its disclosure
3 US 6,341,130 B1 prov. 1998-02-09; filed 1998-09-02 2002-01-22 Lucent (Lakshman & Stiliadis) Two-field filter: projects rules onto one dimension as power-of-two prefixes, decomposes overlapping segments into non-overlapping intervals in the other, associates the highest-priority filter rule with each interval, then matches packet fields to table entries §102(b) art. Highest-ranked §102 candidate for claim 8 (also 16; 9/17 as derivations). Moderate on claim 1's intersection step, but no bit mask ⇒ no anticipation of cl. 1/10/18/24
4 US 6,289,013 B1 prov. 1998-02-09; filed 1998-03-02 (app. 09/145,433) 2001-09-11 Lucent (Lakshman & Stiliadis) Bit-vector (BV) packet filter: rules projected per dimension onto non-overlapping intervals; each interval gets a bitmap of the rules overlapping it; at run time the per-dimension interval bitmaps are intersected ("create an intersection of all interval bitmaps") and the rule is read off the leading set bit §102(b) art. Strongest single reference in the set. Its interval-bitmap intersection is the closest art to cl. 1's "sets … associated with a respective filter element … intersection" and to cl. 8's interval-surviving rule set. Again no range/exact bit mask, so no strict anticipation of cl. 1/10/18/24; best §103 primary reference
5 US 6,522,632 B1 1998-05-06 2003-02-18 Avici Systems Efficient prefix search apparatus/method §102(a)/(e) art. Low. Prefix-trie art only
6 WO 1999/059303 A2 1998-05-14 1999-11-18 Telia AB (Publ) Communications/IP network incorporating a packet classifier §102(a)/(b) printed publication. Background architecture only
7 US 6,157,955 A 1998-06-15 2000-12-05 Intel Packet processing system with a policy engine having a classification unit §102(b) art. Enables the "policy"/"policy-identifier" vocabulary of claims 1/8, but discloses no filter-identifier, bit mask, or two-set node structure
8 US 6,691,168 B1 1998-12-31 2004-02-10 PMC-Sierra High-speed network rule processing §102(a)/(e) art. Low–moderate; rule-Table/action art
9 US 6,594,268 B1 1999-03-11 2003-07-15 Lucent Adaptive routing for QoS packet networks §102(e) art. Low. Policy/QoS routing, not filter-ID intersection
10 US 6,798,788 B1 1999-11-24 2004-09-28 Advanced Micro Devices Determining policies for Layer-3 frame fragments in a network switch §102(e) art. Low–moderate; policy determination, no tree/node sets
11 EP 1 128 609 A2 1999-12-13 2001-08-29 Ascend Communications Packet classification engine §102(a) art (pub. after the 2001-08-08 §102(b) line, so (a) only). Moderate; engine-level disclosure
12 US 6,587,463 B1 1999-12-13 2003-07-01 Ascend Communications Packet classification engine (US counterpart of #11) §102(e) art. Moderate, same disclosure family
13 WO 2001/059702 A1 2000-02-08 2001-08-16 Xstream Logic Wire-speed multi-dimensional packet classifier §102(a) art (published 2001-08-16 — eight days after the §102(b) line; not §102(b)). Moderate
14 US 2002/0023089 A1 2000-02-24 2002-02-21 Woo, Thomas Y. Modular packet classification §102(a) and §102(e) art. Moderate
15 WO 2001/071982 A1 2000-03-20 2001-09-27 AT&T Corp. Service selection in a shared access network using policy routing §102(a) art. Low; policy routing, not classification data structures
16 DE 100 58 443 A1 2000-03-22 2001-10-04 Industrial Technology Research Inst. (Hsinchu) Method for classifying data packets §102(a) art. Moderate; DE counterpart of #17
17 US 6,778,984 B1 2000-03-22 2004-08-17 Industrial Technology Research Inst. Flexible and high-performance packet classification algorithm §102(e) art. Moderate — algorithmically closest of the "algorithm" references, but no bit-masked filter-IDs
18 WO 2002/015469 A2 2000-08-14 2002-02-21 Advanced Micro Devices Apparatus and method for packet classification §102(a) art. Moderate
19 WO 2002/015521 A1 2000-08-17 2002-02-21 Redback Networks Packet classification with a multi-level data structure §102(a) art. Moderate–high vs. cl. 8/16 (multi-level tree of classifier entries)
20 EP 1 180 882 A2 2000-08-17 2002-02-20 Nippon Telegraph & Telephone Packet classification search device and method §102(a) art. Moderate–high; published 2002-02-20 for the 2002-08-08 filing
21 US 2002/0023080 A1 2000-08-17 2002-02-21 Nippon Telegraph & Telephone Same disclosure as #20 §102(a) + §102(e) art. Moderate–high; the US publication form of #20
22 WO 2002/015488 A1 2000-08-17 2002-02-21 Redback Networks Packet classification with multiple answer sets §102(a) art. Notable for cl. 8/16 — "multiple answer sets" is the closest naming match to the claimed first set / second set pair per node. Technically distinct (answer-set lookup vs. exact-match/range-based sets)
23 US 2002/0095421 A1 2000-11-29 2002-07-18 Koskas, Elie Ouzi Organizing data / processing queries in a database system §102(a)/(e) art. Low; general database query mechanics
24 US 2002/0181480 A1 2001-01-22 2002-12-05 Puleston, Ian Using a balanced tree as the base for a routing table §102(e) art. Moderate vs. cl. 8/16 — the '400 specification itself builds on red-black balanced binary trees, so this art is squarely on the disclosed data structure
25 US 2002/0152209 A1 2001-01-26 (prov. 60/264,065) 2002-10-17 Broadcom Classifying packet flows with a bit mask: a mask constructor selects bit locations; the mask is an extraction/hash function producing a query key that indexes a refined rule table §102(e) art. Most relevant art to the bit-mask element of cl. 1/10/18/24 — but the mask extracts bit positions, it does not encode range-vs-exact per field. Best used under §103, not §102
26 EP 1 227 630 A2 2001-01-26 2002-07-31 Broadcom Same disclosure as #25 §102(a) art (published 2002-07-31, before the 2002-08-08 filing). Same limitation as #25: hash-mask, not range/exact flag mask ⇒ §103, not anticipation
27 US 2002/0159466 A1 2001-02-14 2002-10-31 Rhoades, John Lookup engine §102(e) art. Moderate; lookup-engine mechanics
28 US 2003/0231630 A1 2001-08-30 2003-12-18 Messenger, Brian Scott High speed data classification system §102(e) art. Moderate
29 US 2003/0120622 A1 2001-09-21 2003-06-26 Nurmela, Kari Data packet filtering §102(e) art. Moderate
30 US 2004/0008634 A1 2002-05-31 2004-01-15 Rangarajan, Vijay Enhanced tree bitmap data structures for longest-prefix match §102(e) art. Moderate vs. cl. 8/16 (tree + bitmap per node)
31 US 2004/0258061 A1 2002-07-03 2004-12-23 Sahni, Sartaj Kumar Prefix partitioning for dynamic router tables §102(e) art. Moderate; partitioning/ordering of search structures (relevant to the ordering limitations of cl. 5–7/13–15/21–23)
32 US 2004/0022243 A1 2002-08-05 2004-02-05 Jason, James L. Data packet classification §102(e) art. Highest-interest timing reference: filed three days before the '400 application. If it discloses the range/exact characterization or the per-node two-set structure, it is the only cited document in the same technical micro-window
33 US 7,554,980 B1 2002-10-18 2009-06-30 Alcatel Lucent Packet classification using relevance scoring NOT §102 prior art — filed ~10 weeks after the '400 filing date. Cite only as post-art context
34 US 7,382,777 B2 2003-06-17 2008-06-03 IBM Implementing actions based on packet classification and lookup results NOT §102 prior art — filed ~10 months after
35 US 7,317,723 B1 2004-02-03 2008-01-08 Cisco Technology Action-based termination of multidimensional lookup NOT §102 prior art — filed ~18 months after

Cross-reference note: the Granted patent lists 35 patent documents; the litigated-file-history IDS excerpts surfaced in the earlier search (the Centripetal IPR exhibits) list "7684400" only as a cited reference number inside other parties' IDS/EAST search histories (e.g., IPR2018-01512, IPR2018-01443). That is consistent with the 35-document front page and adds nothing new.


4. Non-patent literature of record (4 references)

All four are §102(b) printed publications (2002 retrieval dates, i.e., before the 2002-08-08 filing), and all four go to the red-black balanced binary tree foundation the specification expressly relies on ("One implementation of the packet classification employs a red-black balanced binary tree created for each filter element type"):

Ref Citation as of record Retrieved §102 exposure
NPL-1 CS 660: Combinatorial Algorithms — Red-Black and B trees, San Diego State Univ., http://www.eli.sdsu.edu/courses/fall95/cs660/notes/RedBlackTree/RedBlack.html 2002-02-19 §102(b). Low — supports the tree structure underlying cl. 8/16 only
NPL-2 "Meeting traffic demands with next-generation Internet infrastructure", http://www.siliconacesss.com/news/Lightwave-may-01.html 2003-04-09 §102(a)/(b) candidate (retrieved after filing; publication date itself unverified). Background on multi-field classification demand only
NPL-3 Red-Black Tree Operation, http://swww.ee.uwa.edu.au/~plsd210/ds/red-black-op.html 2002-02-19 §102(b). Low — tree insertion/deletion mechanics
NPL-4 Red-Black Tree, http://swww.ee.uwa.edu.au/~plsd210/ds/red-black.html 2002-02-19 §102(b). Low — tree definition

Caution: NPL-2 as transcribed contains an apparent URL typo ("siliconacesss"); per the operating rule I am not auto-correcting it. I could not independently verify NPL-2's underlying publication date, and its stated retrieval date (2003-04-09) is after the '400 filing — so it may be an IDS entry rather than a §102 reference. NPL-1/3/4 are the four "Red-Black" references that account for the "Non-Patent Literature (4)" count on the record.


5. Claim-by-claim summary of §102 exposure

Claim group Substance Best §102 candidate(s) Strict anticipation?
8, 16 (+9, 17) Tree of endpoint node values; exact-match first set + range-based second set (values between a node and the next-higher node) US 6,289,013 B1 and US 6,341,130 B1 (Lucent) — pre-computed interval rule sets surviving between endpoints. Secondary: WO 2002/015488 A1 ("multiple answer sets"), US 2002/0181480 A1, US 2004/0008634 A1 Closest of the whole set, but the Lucent family stores interval bitmaps/pointers to a highest-priority rule, not two policy-identifier sets, and is two-dimensional only. Not a clean anticipation
1, 10, 18, 24 (independent) Filter-ID ≠ policy-ID; range-based vs. exact characterization; bit mask with one bit per filter element set to first/second logical value; per-element filter-ID sets; intersection result set US 2002/0152209 A1 / EP 1 227 630 A2 (Broadcom bit mask) for the mask element; US 6,289,013 B1 for the per-element set intersection No. No single reference discloses the range/exact-flag bit mask. Broadcom's mask is a hash extraction key; the Lucent patents use interval bitmaps indexed by rule, not by field-type flag
2, 11, 19, 25 (filter-ID ↔ policy-ID) Associating each filter-ID with a policy-ID US 6,157,955 A (Intel policy engine); US 6,289,013 B1 No — routine combination
3–4, 12–13, 20, 26 (iterative search-ID) Select search-ID from one set, search the others, add if found in all, repeat until a set is exhausted US 6,289,013 B1 (bitmap AND across dimensions is the analogous operation) No — the ordered "highest-not-exceeding" walk (cl. 6–7/14–15/22–23) is not disclosed
5–7, 14–15, 21–23 (ordering) Hierarchical ordering; search high→low; initial search-ID = lowest of each set's maximum; subsequent = next-highest not exceeding US 2004/0258061 A1 (Sahni, prefix partitioning/ordering) No
18–23 (apparatus) Network interface adapter + "first … ninth circuitry" Same art as cl. 1 family No. (Also note the §112 drafting concern already flagged in the earlier section — gerund phrases inside an apparatus claim — which is independent of the prior art.)

6. What I checked and could not confirm

  1. Which references the examiner actually applied, and under which subsection. The front-page (56) block establishes that 35 patent documents and 4 NPL items were considered; it does not establish that any was the basis of a §102 rejection. Given that none is a clean anticipation of claim 1, my working conclusion is that the examiner's rejections (if any) ran through §103 or the cited art served to establish the state of the art. This is an inference, not a verified finding.
  2. US 2004/0022243 A1 (Jason) — the single most interesting reference on timing (filed 2002-08-05). I identified it and its dates but could not retrieve and read its full disclosure within this session. Anyone running a validity analysis should read this one first.
  3. EP 1 227 630 A2's exact publication date for §102 purposes. Espacenet shows an A3 (search-report) publication of 2003-08-13 and an A2; Google Patents gives 2002-07-31 for the A2. If the A2 published 2002-07-31 it is §102(a) art; I used that date as listed and did not auto-correct it.
  4. Whether the three post-dating documents (#33–35) reached the front page via applicant IDS during the 2002–2010 prosecution rather than examiner citation. Google's asterisk convention ("cited by examiner") and the fact that all three post-date the '400 filing are in tension. I report the dates literally and flag the tension rather than resolving it.

7. Ranked answer to "the most relevant prior art"

  1. US 6,289,013 B1 — Lakshman & Stiliadis, Lucent Technologies; prov. 1998-02-09, filed 1998-03-02, issued 2001-09-11. Per-dimension non-overlapping intervals, a rule bitmap per interval, and a runtime intersection of those bitmaps to yield the applicable rule. Closest art to the claim 1 intersection architecture and to the claim 8 range-surviving set. §102(b) art; best classified as §103 primary reference. → cl. 8/16 (best), cl. 1/10/18/24 (partial)
  2. US 6,341,130 B1 — same inventor pair, Lucent; prov. 1998-02-09, filed 1998-09-02, issued 2002-01-22. Two-field version; highest-priority rule associated with each non-overlapping interval. → cl. 8/16
  3. US 2002/0152209 A1 and EP 1 227 630 A2 — Broadcom; prio. 2001-01-26 (prov. 60/264,065), pub. 2002-10-17 / 2002-07-31. Bit-mask-driven packet classification (mask = bit-extraction/hash key). → cl. 1/10/18/24, bit-mask limitation only; §103
  4. WO 2002/015488 A1 — Redback Networks; 2000-08-17 → pub. 2002-02-21. "Multiple answer sets." → cl. 8/16 naming-level relevance
  5. US 2004/0022243 A1 — Jason; filed 2002-08-05, pub. 2004-02-05. Nearest-in-time filing. → unassessed pending full-text review
  6. US 2002/0023080 A1 / EP 1 180 882 A2 — NTT; 2000-08-17 → pub. 2002-02-20/21. Packet classification search device/method. → moderate
  7. US 2002/0181480 A1 — Puleston; 2001-01-22 → pub. 2002-12-05, §102(e). Balanced tree as routing-table base — directly parallel to the '400's red-black-tree implementation. → cl. 8/16
  8. US 6,157,955 A — Intel; 1998-06-15 → 2000-12-05, §102(b). Policy engine with classification unit — supplies the "policy-identifier" concept the claims distinguish themselves from. → cl. 1/8 background

Not §102 prior art at all (filed after 2002-08-08): US 7,554,980 B1 (2002-10-18), US 7,382,777 B2 (2003-06-17), US 7,317,723 B1 (2004-02-03).

Explicit uncertainty declaration: I did not locate an examiner's notice of allowance or rejection paper, an IDS form from the '400 file, or a verified record of which of these 35 references was applied against which claim. The claim-level mappings above are reasoned inferences from the references' own disclosures as retrieved, and I state no opinion on the validity of US 7,684,400.

Generated 9/29/2026, 5:23:36 PM

Obviousness

Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.

✓ Generated

I'll ground this analysis in the actual cited prior art. Let me verify the key references in parallel.

Good grounding. Let me verify a few more of the cited references.

Obviousness Analysis — US 7,684,400 B2 under 35 U.S.C. § 103

Builds on the prior Patent summary and Litigation summary sections above; I do not repeat the bibliographic table, abstract, or claim-family mapping. Claim text is cited by number; reference content is drawn from the "Patent Citations (35)" / "Non-Patent Citations (4)" listing on the US7684400B2 page, verified against the sources fetched this session where noted.

Date inconsistency flagged: This task states "Current Date: April 26, 2026," while my operating context says 2026-09-29. The analysis below is date-agnostic except where it matters; I have not reconciled the two.

Prosecutorial caveat up front: Every reference discussed below appears on the face of US 7,684,400 (front-page "Patent Citations" / "Non-Patent Citations"), i.e., all were of record. That means at least some were considered by the examiner and not applied to reject the claims. I did not retrieve the file wrapper / prosecution history in this session, so I cannot tell you which of these were discussed in an office action, which were merely IDS submissions, and what (if anything) the applicant argued. This is a prima facie / hypothetical § 103 analysis, not a prediction of how an examiner or the PTAB would rule.


1. Level of ordinary skill and the governing framework

POSITA (hypothetical, as of the 2002-08-08 priority date): a B.S. in EE/CS plus ~2–3 years, or an M.S. plus ~1 year, in network processor / router data-path design, with working familiarity with: multi-field packet classification algorithms (tries, bit-vector/"Lucent bit vector" schemes, decision trees, TCAMs); balanced binary search trees (the patent's own non-patent citations are red-black tree tutorials — SDSU CS 660, UWA red-black-op.html — confirming this is baseline skill); and hardware/software implementations of longest-prefix and range lookups at wire speed.

Framework: Graham v. John Deere (scope/content of prior art; differences; PHOSITA level; secondary considerations), with KSR Int'l v. Teleflex for motivation ("predictable use of prior art elements according to their established functions," "design incentives," "market demand"). Where combinations are asserted, I identify the reason a POSITA would have combined.


2. The cited art, bucketed by the claim limitation it supplies

'400 limitation Closest cited art (from the page) Verified this session?
Per-field range decomposition; lookup in logarithmic rather than log^(D−1)-ish time US 6,341,130 B1 (Lakshman/Stiliadis, Lucent, filed 1998-09-02, granted 2002-01-22) ✅ Google Patents / Indiana DLI text
Bit map / bit-vector intersection across fields to correlate rules US 6,778,984 B1 (ITRI; DE 10058443 A1; priority 2000-03-22) ✅ uspto.report + Google citation record
Bit mask derived from a rule set; key extraction; rule-set division tree US 2002/0152209 A1 / EP 1 227 630 A2 (Broadcom; prov. 60/264,065, 2001-01-26) ✅ EPO publication server + Google Patents + FPO
Answer sets + answer indexes; AND of indexes then AND of blocks; "not exhausted" iteration US 6,529,508 B1 / WO 02/015488 A1 (Redback; Li, Ng, Terry, Lee; prov. 1999-02-01) ✅ full claim 1 text retrieved
Tree-based multi-field search with node-associated rule information EP 1 180 882 A2 / US 2002/0023080 A1 (NTT; JP priority 2000-08-17); US 6,041,053 (Microsoft); US 6,522,632 (Avici) Partial (EP '882 text ✅; '053/'632 title-level only)
Balanced-tree lookup of prefix/range keys US 2002/0181480 A1 (Puleston, 2001-01-22); red-black tree NPL citations Title/bibliographic level
Multi-level / multiple-answer-set classification data structures WO 02/015521 A1 (Redback); US 2002/0023089 A1 (Woo); US 2004/0258061 A1 (Sahni, 2002-07-03) Title-level only — see caveat §6
Policy engine / classification unit; classifier + lookup actions US 6,157,955 (Intel); US 6,587,463 / EP 1 128 609 (Ascend) Not retrieved

Availability screen (important, and not previously flagged): three items on the citation list post-date the 2002-08-08 priority date and therefore are not §102 prior art to this patent: US 7,317,723 (Cisco, priority 2004-02-03), US 7,382,777 (IBM, priority 2003-06-17), and US 7,554,980 (Alcatel Lucent, priority 2002-10-18). Do not build a §103 ground on them for a 2002 priority date. By contrast, US 2004/0022243 A1 (Jason, priority 2002-08-05 — three days before) is potentially available as §102(e) art premised on its earlier effective filing date.


3. The two independent inventive concepts, and the grounds against each

Ground 1 — Claims 1, 2, 10, 11, 18, 19, 24, 25 (filter-ID + per-field bit mask + set intersection)

Primary: US 6,778,984 (ITRI). Expressly: divide the input key into sub-keys; for each sub-key value, compare against each rule's corresponding sub-key field and store the comparison as a bit map where 1 = match ("rule vector"); then logically AND the retrieved rule vectors across all sub-keys to produce the conformed rule vector; then a priority encoder selects the winning rule. That is, element-for-element: determine respective sets of identifiers, each set associated with a respective filter element (§ determining respective sets…), and produce a result-set based on an intersection of the sets (§ producing a result-set…). The only gap is the negative limitation that the identifier be "different from a policy-identifier" and the specific bit-mask-encodes-range-vs-exact convention.

Secondary: US 2002/0152209 / EP 1 227 630 (Broadcom). Expressly: a mask constructor builds a bit mask ("extraction function"; "the extraction function is a hash function, in particularly a bit mask") from the rule set; a key extractor applies that mask to the packet to form a packet key that is used to look up a refined rule table. The key is, by construction, a datum distinct from the rule identity that the lookup ultimately returns — which is materially the claim's "filter-identifier is different from a policy-identifier." Broadcom also discloses a rule set division tree and a search tree (its FIGS. 4–5), i.e., ordered hierarchical arrangement of the keyed structures.

Motivation to combine (KSR): both references are in the identical field (multi-field packet classification for routers/switches), address the identical problem (rule-set growth makes per-packet lookup memory-bound), and their combination is a substitution of one known keying/addressing mechanism (Broadcom's mask-derived key) into another known correlation engine (ITRI's per-field bitmap AND). The claimed result — faster per-field lookup with reduced search space — is the stated function of each reference, so the combination is "the predictable use of prior art elements according to their established functions." Broadcom's own stated objective ("select a relatively small set of bits to uniquely identify the packets satisfying a packet classification rule") supplies the design incentive to encode field-related information in the mask itself, which is the bridge to claim 1's range/exact bit.

Honest weakness: the range-vs-exact semantics of the mask bit is an argument by analogy, not a verbatim disclosure. Broadcom's mask bits index bit locations, not field properties. A rigorous ground here needs either (a) a Broadcom passage tying the mask to per-field granularity, or (b) a third reference teaching per-rule/per-field flagging of "port/range wildcarding" conventions. I did not locate such a passage in the material I retrieved, so I rate this element met only by a secondary-evidence-supported inference, not by direct disclosure.

Ground 2 — Claims 3, 4, 12, 13, 20, 26, and 5–7/13–15/21–23 (iterative search-ID selection; ordered high-to-low searching)

Primary: US 6,529,508 / WO 02/015488 (Redback). Its claim 1 recites, in sequence: obtain answer sets of flags per parameter (one flag per rule); obtain answer indexes (one flag per block of the answer set, TRUE if any flag in the block is TRUE); AND the answer indexes to identify blocks that could contain matches; AND the identified blocks to find the matched rule. Claim 1's own dependent logic plus the specification's "has not exhausted" language maps directly onto '400 claim 4/12/20/26 ("iteratively repeating… until a last filter-identifier in any set is reached") and onto the hierarchical-ordering limitation of claim 5/13/21 (the block hierarchy is the hierarchy; the AND is performed block-to-leaf).

Supplement: US 6,341,130 (Lucent). Orders entries by prefix length / interval and identifies the "solution interval" by a predetermined metric (longest prefix, shortest prefix, or priority) — supplying the ordered traversal and the "which entry wins" resolution. Also US 2002/0181480 (Puleston) for using a balanced tree as the base structure, and the red-black tree NPL for the tree mechanics themselves.

Motivation: Redback's express purpose is to avoid examining every bit of every answer set — "the AND operation on the answer indexes… identif[ies] those blocks which could contain bits corresponding to matched rules." That is exactly '400's stated goal of "skipping logically non-applicable filter-IDs… to remove the randomness that could cause O((log n)*n) worst case performance." A POSITA optimizing set intersection would adopt block/level ordering plus high-to-low scanning as a matter of routine algorithmic design (the same technique as intersecting sorted lists, and the sort/merge and binary-tree NPL on the patent's face confirms it is routine).

Claims 6–7 / 14–15 / 22–23 (select the lowest of the per-set maximum filter-IDs as the initial search-ID; thereafter the next-highest not exceeding the current search-ID): this is the standard k-way sorted-list intersection / merge algorithm applied to the filter-ID sets. Given dependent claim 5's hierarchical ordering (itself sourced above), the selection rule is the textbook way to drive a descending intersection — the sort-order NPL citations and the patent's own presentation of it as a mechanical enumeration support "routine, predictable" characterization.

Ground 3 — Claims 8, 9, 16, 17 (two policy-ID sets per tree node: exact-match set + range-based set, the latter = intersection with the next-higher node's first set)

This is the second, structurally distinct invention, and it needs a different primary.

Primary candidates:

  • US 6,341,130 (Lucent) — precomputes, for each non-overlapping interval (i.e., each endpoint-to-endpoint span), the set of filter rules applicable in that span, with a pointer to the highest-priority rule. The "which rules apply to values between endpoint k and endpoint k+1" concept is Lucent's table row; claim 9's intersection-derivation is then a mathematical identity (the rules covering an open interval are exactly those covering both its endpoints).
  • US 2002/0023089 (Woo) and US 6,041,053 (Microsoft) — recursively subdivided filter sets / trie-indexed hierarchy, i.e., node values that each carry the set of filters matching that subdivision. This is structurally "a set of policy-identifiers associated with a node value."
  • EP 1 180 882 / US 2002/0023080 (NTT) — node/group-associated "search related information" and "number of searches information" stored alongside grouped rule fields; a tree structure for packet classification search.
  • US 6,522,632 (Avici) and US 2002/0181480 (Puleston) — node-value trees and prefix search.
  • WO 02/015521 / WO 02/015488 (Redback) — "multi-level data structure" and "multiple answer sets," i.e., per-node/per-level collections of matching rules.

Motivation: the '400 specification itself concedes the baseline — "One implementation of the packet classification employs a red-black balanced binary tree created for each filter element type" — and cites public red-black tree references. Building a red-black tree over the endpoint values of each policy range is therefore admitted prior art. Once a POSITA has (i) a tree whose nodes are policy endpoints (Lucent/Avici) and (ii) the concept of storing the matching rule set at a node (Lucent/Woo/Microsoft), pre-computing the intersection of adjacent nodes' sets at install time is an optimization whose entire benefit is stated in the reference art's own framing: Lucent '130 explicitly weighs O(log^(D−1) n) time with O(n) space against O(log n) time with O(n^D) space, i.e., it teaches the field that logarithmic-time, low-space multi-field lookup is the design goal. KSR makes the "do the intersection once at install rather than per packet" step a predictable optimization.

Note on claim 9/17's dependency: deriving the second set by intersection of the node's first set and the next-higher node's first set is the definition of the range-based set; the only question is when it is computed. Moving a computation from run-time to install-time is the classic non-inventive optimization.


4. Would the cited art collectively teach the claims? Summary table

Claim(s) Prima facie §103 strength Principal combination Main vulnerability
1, 10, 18, 24 Moderate–strong ITRI '984 + Broadcom '209/EP '630 (± Redback '508) The range/exact bit-mask semantics is by analogy; also the express "different from policy-identifier" negative limitation
2, 11, 19, 25 Strong Broadcom '209 (refined rule table maps key → rule) + any of the above Low
3–4, 12–13, 20, 26 Strong Redback '508 answer-index/block AND + "not exhausted" loop Low
5, 13, 21 Strong Redback '508 block hierarchy; Lucent '130 prefix/interval ordering; Puleston '480 balanced tree Low
6–7, 14–15, 22–23 Moderate–strong k-way sorted-list intersection driven by claim 5's ordering (Redback + sorting NPL) Requires accepting "routine algorithm" characterization
8, 16 (and 9, 17) Moderate Lucent '130 (+ Woo '089 / Microsoft '053 / NTT '882 / Avici '632 / Redback WO '521) on the admitted red-black-tree base Lucent uses a table, not a tree with two sets per node; the two-set-per-node architecture is not verbatim disclosed
Article/apparatus/system variants Mirrors the above Same combinations Claim 18's mixed gerund drafting ("characterizing/generating/setting" inside an apparatus claim) is a §112 clarity exposure independent of §103 — flagged in the earlier summary, restated here only as a cross-reference, not re-argued

5. Secondary considerations

From the Litigation summary above: the patent was assigned from Intel to Tahoe Research, Ltd. (effective 2022-07-18) as part of a ~3,419-US-patent portfolio, and Samsung reportedly took a broad license to Intel-origin Tahoe patents (~mid-2025). For a §103 secondary-considerations argument, this evidence is weak to negligible: a bulk portfolio license gives no probative nexus to this patent's subject matter, and no public record ties any specific payment, praise, or industry copying to the '400's particular bit-mask/filter-ID technique. There is no evidence found of a long-felt need, failure of others, or unexpected results evidenced by the applicant. No IPR, PGR, or reexam of the '400 was found (only its appearance as a cited reference inside Centripetal-related materials). Conclusion: no meaningful secondary-considerations counterweight on the public record.


6. Explicit uncertainties and limits on this analysis

  1. File history not retrieved. I did not pull the '400's prosecution history, so I do not know which of these references were actually applied, argued, or distinguished. The fact that the claims issued over a record containing all of them is itself a data point a defendant/examiner would have to explain.
  2. Several references characterized at title/bibliographic level only. I was unable to retrieve full text this session for US 6,289,013, US 6,157,955, US 6,041,053, US 6,522,632, US 6,587,463 / EP 1 128 609, WO 02/015521, WO 01/059702, and US 2002/0023089. My statements about those are limited to their titles and the bibliographic entries on the US7684400B2 page. Any ground relying on them needs their specifications read first.
  3. The strongest single-reference attack is on the scope of claim 1, not on a combination. ITRI '984 alone covers the "sets per field + AND intersection" core; the bit-mask framing is what remains. If a Broadcom passage or a third reference makes the range/exact bit explicit, Ground 1 becomes substantially stronger — I did not find that passage in what I retrieved.
  4. Claim 8's two-set-per-node architecture is the least-attacked element on this record; the closest art is analogous (Lucent's table rows, Redback's per-level answer sets) rather than identical.
  5. I make no assertion on validity, infringement, or enforceability. This is a technical §103 analysis on the cited art, not a legal opinion. Claim 18's §112 exposure and any §101 characterization of claim 1 are noted but not analyzed here.

Generated 9/29/2026, 5:23:16 PM

Extensions

Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Not generated yet. Click Generate to call the active LLM provider with the configured prompt.

Keep exploring

Other patents in Software Technology & Computing Systems (T)

See all Software Technology & Computing Systems (T) patents →