US 7227842

I'll search for current information on this patent, including any 2026 litigation activity.

Let me run a couple more targeted searches to check for any 2026 litigation activity.

Search Results — US Patent 7,227,842

Searches performed: US patent 7227842, US7227842 CAFC 2026 docket, "7227842" patent litigation 2026, "7,227,842" Federal Circuit appeal.

Important caveat on the 2026 docket request: I found no CAFC 2026 docket, appeal, or other 2026 judicial proceeding involving U.S. Patent 7,227,842. My searches returned unrelated 2026 Federal Circuit activity (e.g., Clear Imaging Research LLC v. Google LLC, No. 2026-1485; Ascendis Pharma v. BioMarin) and unrelated patents/patent numbers. I cannot confirm the existence of any 2026 litigation for this patent, and I am explicitly flagging that rather than inferring one. Notably, the patent's recorded legal status is "Expired – Fee Related, adjusted expiration 2025-02-16," which would limit the practical window for infringement suits in 2026. If a specific 2026 docket exists, it did not surface in these searches; a direct PACER/CAFC docket query would be needed to confirm.

---

Bibliographic Summary (per the authoritative patent text provided)

Related applications cited in the patent: provisional 60/249,627 (Nov. 16, 2000, "Fast Route Lookup with Configurable Processor and Compressed Routing Table"); utility 09/780,895 (now U.S. 6,888,838); provisional 60/264,667 (Jan. 25, 2001); utility 10/032,379. Also incorporated by reference: U.S. Patents 6,477,683, 6,701,515, 6,477,697, and 7,036,106.

---

Abstract (as issued)

"A novel solution for fast packet classification includes a novel data structure to store classifier rules which enables fast packet classification, which structure employs bitmaps for each field of the incoming packet for which classification is desired. A fast packet classification algorithm using the novel data structure allows the matching rule with the highest priority to be quickly obtained. A novel rule update algorithm allows new classifier rules to be added into the data structure incrementally. In one practical implementation of a classification engine employing the structures and algorithms of the present invention, a configurable processor with customized instructions is used to accelerate packet classification."

---

Plain-Language Overview of the Claims

The patent has 3 claims total; Claim 1 is the sole independent claim. Claims 2 and 3 depend from Claim 1.

Claim 1 — the independent claim (packet classification method).
It covers a method with two intertwined threads:

1. Classification/matching thread: Receive a packet; use a processor to match multiple packet fields against N classification rules. For each field, the method: (a) associates "equivalent IDs" with respective field values; (b) associates a respective bitmap with each equivalent ID, where the bitmap indicates which classification rule(s) match; and (c) determines the bitmap for the value of the field actually present in the packet.

2. Rule-management ("rudimentary interval") thread:

   • Determine the possible range of values for a field and identify it as a first rudimentary interval with associated endpoints.
   • Parse a classification rule to get its matching range; identify its upper and lower ends.
   • Compare those upper/lower ends against the endpoints of the rudimentary interval.
   • Create up to two new rudimentary intervals based on the "case result" of that comparison.
   • Associate adjusted endpoints with the first and the up-to-two new intervals in accordance with the case result, so as to facilitate classification based on the packet's actual field value within the matching range.
   • Prepare to forward the packet using the packet classifying rule.

In plain terms: you match on a per-field bitmap basis, and you maintain the rule database by splitting/merging "rudimentary intervals" as rules are added (the four cases described in the spec as Cases 1–4).

Claim 2 (dependent on Claim 1). Adds the step of associating bitmaps with each of the first and up-to-two new rudimentary intervals, the bitmaps indicating whether the rule is matched within that interval. (This ties the interval bookkeeping to the bitmap data structure of Claim 1.)

Claim 3 (dependent on Claim 1). Adds an incremental update path for a new rule: parse a new rule to get a new matching range; identify its new upper/lower ends; compare them against the already-adjusted endpoints of the existing intervals; create up to two additional rudimentary intervals based on the case result of that new comparison; and associate adjusted endpoints with certain intervals accordingly. (Essentially, the recursive rule-update algorithm applied to subsequent rules.)

---

Contextual / Supporting Details from the Specification

• Data structure: For each field, three tables are maintained — a Rule Information Base (RIB) table, a Bitmap (BMP) table, and an Endpoints (EP) table. The RIB stores an "eqID" (equivalent ID) indexing into the BMP table of N-bit bitmaps. The EP table stores lower/upper endpoints per rudimentary interval and is used only for rule add/delete (not for classification), so it can live in slower external memory.
• Bound: Number of rudimentary intervals is upper-bounded by 2N+1 for N rules (each new rule adds at most two intervals).
• IP address handling: 32-bit fields use a hierarchical 16/K structure (RIB_T1/RIB_T2) with a marker bit and K value; smaller fields use flat RIB tables.
• Configurable-processor implementation: Preferred implementation uses an Xtensa configurable processor (Tensilica) with custom instructions — LOAD_PKT, T1_LOOKUP, T2_LOOKUP, BMP_INTERSECTION, GET_EQID, SELECT_RULE. The patent reports 16 cycles typical / 30 cycles worst-case per five-field classification, and OC48 wire-speed with two 200 MHz processors.
• Parallelism: FIGS. 8–9 describe shared-memory (dispatcher + multiple processors) and distributed-memory (one processor per field) architectures.

---

Uncertainty Notes

• The CAFC 2026 docket item you requested could not be verified by these searches. No 2026 appellate proceeding for 7,227,842 was found. Treat any assertion of a 2026 CAFC docket as unconfirmed unless checked directly against PACER or the CAFC docket system.
• The bibliographic data above is taken from the authoritative full patent text you supplied (Google Patents rendering of US7227842B1). General web hits corroborate the title, inventors (Ji et al.), issue date (June 5, 2007), and application number 10/133,689.
• Google Patents labels the legal status an "assumption and not a legal conclusion"; likewise, priority-date and assignee listings are flagged as assumptions. I have reported them as recorded rather than independently verified.

I'll research litigation involving US patent 7227842. Let me search multiple sources.

Initial results show no direct litigation hits. Let me search more targeted sources.

Let me search the patent litigation portals directly.

Findings: Litigation involving US Patent 7,227,842

Based on my searches of patent-litigation sources (Unified Patents litigation portal, Docket Alarm, RPX Insight, CourtListener/PACER-derived materials, and general web search), I found no evidence of any litigation involving US Patent 7,227,842.

No cases identified

I was unable to locate any district court complaint, ITC Section 337 investigation, PTAB proceeding (IPR/PGR/CBM), or CAFC appeal in which US 7,227,842 is a patent-in-suit or otherwise at issue. Accordingly, I cannot provide plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome — because no such case appeared in the sources searched.

What the searches actually returned (and why these are NOT litigation)

Every appearance of "7227842" in the results was a prior-art / citation reference, not an assertion or challenge:

1. IDS/prior-art citations in other patents' file histories. The number appears in Information Disclosure Statements and search histories in unrelated prosecutions — e.g., an IDS listing "7227842 B1 2007-06-05 Ji et al." and EAST search-history excerpts in PTAB exhibits for IPR2018-01512 (Cisco, re: US 9,565,213) and IPR2021-01152 / IPR2021-01520 (Palo Alto Networks v. Centripetal Networks). These are citations to the '842 patent as background art only; the patents under review in those proceedings are different patents.

2. The patent's own bibliographic pages (Google Patents, Golden wiki). The Google Patents record lists 3 claims, inventors Hongbin Ji and Michael Carchia, original/current assignee Tensilica Inc., priority date 2001-04-24, and legal status "Expired – Fee Related" (adjusted expiration 2025-02-16). None of this reflects litigation.

3. Its "Cited By" list. Google Patents shows ~104 third-party/examiner citations to the '842 patent (e.g., Cisco, Juniper Networks, Samsung, IBM, Broadcom, 3Com, Wake Forest University patents). Being cited by later patents is not litigation; it only shows the patent is relevant prior art in the packet-classification field.

None of the district-court complaints surfaced (Oplus v. Sears/JVC, Signify v. Menard, Intellectual Ventures v. American Airlines, Stratasys v. Bambu, Canon toner-cartridge ITC actions, etc.) assert the '842 patent. They involve unrelated patents with similar-suffix numbers such as 6,239,842 ("the '842 Patent" in the Oplus and Cathx cases) — a different patent that must not be conflated with 7,227,842.

Important caveats on confidence

• I could not directly retrieve a Unified Patents or Docket Alarm "litigation" listing keyed to US-7,227,842; several targeted queries were truncated or returned no on-point litigation records.
• I have no high-confidence affirmative evidence that litigation exists, but absence of search results is not proof of absence. Litigation databases (RPX/Unified/PTAB portals) are the definitive sources and should be queried directly with the exact patent number 7227842 / 7,227,842 to confirm.
• Practically, this patent is an expired Tensilica (now Cadence) software/microprocessor-era patent with only 3 claims and a 2025 adjusted-expiration date, which is consistent with it never having been a serial-assertion vehicle.

Bottom line: No litigation involving US patent 7,227,842 was identified. If any exists, it did not appear in the sources and queries I was able to run, and I recommend a direct Unified Patents (portal.unifiedpatents.com/litigation/caselist) and PTAB/CourtListener search on the exact number to confirm before relying on this negative finding.

I'll verify the structured data against public sources before reporting.

Let me check the PTAB patent-specific and Unified Patents portals for any records.

One more confirmation pass targeting PTAB-specific databases and the patent's own Google Patents "PTAB" section.

Proceedings overview

Total AIA trial proceedings on file against US 7,227,842: 0. The USPTO Open Data Portal returns no IPR, PGR, or CBM involving this patent as the challenged patent, and independent web searching (PTAB E2E/PTACTS, Docket Alarm PTAB dockets, RPX/Unified Patents portals, and IPR petition literature) surfaces no petition, no institution decision, no Final Written Decision, and no Federal Circuit appeal arising from such a trial. Bottom line for a defendant: there is no IPR-based estoppel, no claim-cancellation judgment, and no PTAB record to wield — but that cuts both ways. The patent has never been validity-tested by the Board, so the absence of IPRs is not a sign it is hardened; it is a sign the patent was never worth attacking at scale. What actually neutralizes it is simpler: per the structured data, the patent's legal status is "Expired - Fee Related, expires 2025-02-16" and the term has run, so no defendant can infringe it going forward.

Because the canonical list is empty, the per-proceeding template below is populated with a null result and the corroborating/negative evidence, rather than proceedings that do not exist.

---

(no proceedings) — no Petitioner v. Tensilica, Inc.

• Type: N/A — no Inter Partes Review, Post-Grant Review, or Covered Business Method review identified.
• Filed: N/A
• Status: N/A. For reference, the patent's own legal status per the structured data is verbatim: "Expired - Fee Related, expires 2025-02-16", with an "Adjusted expiration" legal event dated 2025-02-16. Application 10/133,689 was filed 2002-04-23, claims priority to provisional 60/286,262 filed 2001-04-24, and issued as US 7,227,842 B1 on 2007-06-05.
• Judge panel: N/A — no panel ever convened on this patent.
• Petition grounds: N/A. No claim of US 7,227,842 (claims 1, 2, 3) has ever been challenged under § 102, § 103, or § 112 in an AIA trial.
• Institution decision: N/A — no § 314(a) or § 324(a) determination exists.
• Final Written Decision: N/A — no claim has been canceled or sustained by the Board.
• Settlement / termination: N/A.
• Appeal: N/A — no CAFC docket traceable to a PTAB trial on this patent.
• Defensive value: Two independent defenses exist without touching the merits: (1) the patent is expired as of 2025-02-16, so there is no forward-looking infringement exposure; and (2) because no IPR was ever filed, there is no § 315(e)(2) estoppel, no adverse claim-construction record, and no Board-issued cancellation to rely on. Any demand letter asserting claims 1–3 of this patent is asserting claims that expired more than a year before today's date (2026-09-30).

Negative-evidence check (what I looked for and did not find)

• No IPR/PGR/CBM docket. Searches of PTAB-side databases and petition repositories returned no case with US 7,227,842 as the patent under review.
• Citations ≠ challenges. US 7,227,842 appears in PTAB records only as a cited reference in other parties' Information Disclosure Statements and file-history exhibits (e.g., Docket Alarm exhibit compilations in IPR2018-01512, IPR2021-01152, and IPR2021-01520 show "7227842 B1 | 2007-06-05 | Ji et al." as an IDS entry). It is also cited as background in unrelated later filings, e.g. the Chinese family member CN102546388B discusses "US7227842" in its background section. Being cited is not being challenged.
• False positives flagged — do not rely on these. Web results containing a "'842 patent" refer to different patents, not US 7,227,842: (a) Greenthread's '842 patent, challenged in IPR2023-01243 and IPR2024-00016 by MPS and others; (b) the Express Mobile '842 patent referenced in the Google/Facebook v. Express Mobile IPR2021-01455 line of cases. Likewise, an ex parte reexamination certificate that surfaced in search (US 5,784,584 C2) belongs to an unrelated Moore patent, not to 7,227,842. None of these involve the Tensilica patent.
• Unified Patents / defensive aggregator. No Unified Patents (or similar aggregator) proceeding against this patent was found. The patent does not appear on the Unified Patents portal as a challenged asset based on available search returns.
• Caveat. ODP ingest can lag on very old or never-filed matters. My conclusion is that nothing was filed, not merely that nothing is indexed; the searches above returned zero petitions, which is consistent with the ODP null result. If you need certainty for a litigation hold, pull the complete file wrapper for application 10/133,689 through Patent Center and confirm the "Reviews/Trials" tab is empty: https://patentcenter.uspto.gov.

---

Strategic summary

Claim status: no claim of US 7,227,842 has been CANCELED, SUSTAINED, or TESTED by the PTAB. The patent carries three claims: claim 1 (independent, method for packet classification with rudimentary-interval creation and endpoint adjustment), claim 2 (dependent — associating bitmaps with each of the first and up to two new rudimentary intervals), and claim 3 (dependent — recursive parsing/comparison of a new rule against adjusted endpoints). All three stand exactly as issued; none was narrowed by amendment in an AIA trial, and there is no reissue or reexamination certificate of record for this patent. The relevant "narrowing" here is temporal, not adjudicative: the term ended 2025-02-16, leaving no enforceable window after that date.

Estoppel landscape: empty. § 315(e)(2) estoppel attaches only to a petitioner who obtains a Final Written Decision, and there is no such petitioner. Consequently, every prior-art ground — including § 102 and § 103 combinations built on the very references the patent itself distinguishes (Gupta et al., "Packet Classification on Multiple Fields," Proc. ACM SIGCOMM, September 1999; the bit-parallelism, tuple-space, hierarchical-trie, and TCAM literature described in the Background; and the nP7120, IBM Rainier, and ClassiPI network-processor systems described at col. 2), plus the four commonly owned Tensilica patents incorporated by reference (U.S. Pat. Nos. 6,477,683; 6,701,515; 6,477,697; 7,036,106) — remains fully available in district court and the ITC. There is also no § 325(d) or § 315(b) baggage because no trial was ever instituted. If a defendant nonetheless wants a Board ruling (e.g., to defeat a legacy damages theory covering pre-2025-02-16 conduct), note that IPRs against expired patents are permitted, but the Board construes expired claims under the Phillips framework rather than the Phillips-vs-appendix debate, and PGR is unavailable because this is a pre-AIA patent (priority 2001-04-24, well before the 2013-03-16 AIA cutoff). CBM would also be a poor fit — the patent is directed to packet-classification hardware/software, a technological invention, not a "covered business method."

Pattern signals. No serial-petitioner pattern (there is no petitioner at all). No patent-owner appellate aggressiveness (Tensilica/Cadence never appealed a Board judgment on this patent, because none exists). No defensive aggregator activity. The only notable pattern is ownership change: Tensilica, Inc. was acquired by Cadence Design Systems, Inc. in March 2013, so any current assertion would run through Cadence — and, critically, through a 1998-priority-line patent family whose only asserted-term protection has now lapsed. The low assertion profile plus expiration is the signature of an asset that was monetized through product/EDA licensing rather than litigation, which is consistent with a patent that never drew an IPR.

---

Recommended next steps

1. Lead with expiration, not invalidity. If you hold a demand letter citing claims 1–3 of US 7,227,842, the dispositive response is the legal status: "Expired - Fee Related, expires 2025-02-16." As of today (2026-09-30), that date is past. Confirm the expiry and any fee/term-adjustment details in the file wrapper (application 10/133,689) at https://patentcenter.uspto.gov and in the Google Patents legal-status record at https://patents.google.com/patent/US7227842/en.
2. Bound your actual exposure window. Damages can only reach conduct before 2025-02-16 (and virtually always only after the patent issued on 2007-06-05, plus the six-year § 286 lookback). Ask opposing counsel to identify the asserted claims and the accused products and the dates of the accused conduct. If the letter is touting ongoing royalties, it is citing a dead patent.
3. There is no PTAB milestone to track. No institution decision deadline, no statutory one-year FWD date, no oral hearing, no CAFC appeal. Do not budget for a trial-stage PTAB timeline — there isn't one. If you nonetheless elect to file an IPR against an expired patent, budget the § 315(b) one-year clock from service of any complaint and expect Phillips claim construction.
4. Preserve the invalidity record you can still build. Because no estoppel exists, commission an invalidity analysis against the Background-acknowledged art (Gupta SIGCOMM 1999; the referenced TCAM and tuple-space approaches; the Rainier/ClassiPI/nP7120 network processors) for defensive use against any pre-2025-02-16 damages theory. Do not assume the Board has blessed any of it — it hasn't.
5. Verify the null result directly. The absence of PTAB activity is my finding, not a fabricated negative. Re-run it at the Board's own docket (https://ptacts.uspto.gov/ptabs/public-informations/search, search patent number 7227842) and against the file wrapper's Reviews/Trials tab before you commit the "no IPR" position in a brief or a stipulation.

I'll research the assignment record for US 7227842 before assembling the report.

Ownership & Assignment Analysis — US 7,227,842 B1

"Fast IP packet classification with configurable processor"
Application 10/133,689 · Filed 2002-04-23 · Issued 2007-06-05 · Priority 2001-04-24 (prov. 60/286,262)
Legal status: Expired — Fee Related; adjusted expiration 2025-02-16

Verification caveat (read first)

I could not retrieve the actual reel/frame images from the USPTO Assignment Center in this research session. The Assignment Center / Patent Assignment Search is a query-gated interface that my available tooling (web search) does not render as indexable content. Every reel/frame number, correspondent name, and execution date below is either (a) drawn verbatim from the authoritative Google Patents record supplied in the brief, or (b) marked explicitly as unverified. I have not fabricated any reel/frame entry. Where the record is silent, I say so.

---

Inventors

Unusual-pattern check: Not determinable. Both inventors executed an assignment of rights to Tensilica on 2002-04-23 (the filing date), which is the ordinary employee-obligation-to-assign pattern for a Silicon Valley SIP company, not a distress signal. I found no evidence of either inventor departing Tensilica within 12 months of filing, and I found no evidence of the opposite. Ji is also a named inventor on the related Tensilica filing US 7,274,697 ("Fast IP route lookup with 16/K and 16/Kc compressed data structures," app. 10/032,379, filed 2001-12-21), which places him inside the same Tensilica networking-IP group. That is a continuity signal, not a departure signal.

---

Original assignee

Tensilica, Inc. — Santa Clara, California (later San Jose, CA).

• Line of business: Semiconductor intellectual property (SIP) cores — the configurable Xtensa processor architecture, HiFi audio/voice DSPs, and the FLIX variable-length instruction encoding. Founded 1997 by Chris Rowen (a MIPS Technologies co-founder).
• Did they ship a product embodying the claims? Yes, in the SIP-core sense. The patent's own specification is the evidence: claim 1 is directed to a packet classification method, and the preferred embodiment expressly configures a Tensilica Xtensa processor with six custom instructions (LOAD_PKT, T1_LOOKUP, T2_LOOKUP, BMP_INTERSECTION, GET_EQID, SELECT_RULE). Tensilica's commercial product was the licensable Xtensa core plus its customization toolchain, and the specification reports that 200+ licensees had shipped ~2 billion Tensilica IP cores by 2013. This is an operating company's product-enabling patent, not an abstract asset.
• Current status: Acquired — no longer independent. Cadence Design Systems announced the acquisition on 2013-03-11 for ~$380M in cash and completed it in April 2013 (Cadence's FY2013 Form 10-K states the Tensilica acquisition closed 2013-04-22; cash outlay at closing was ~$326M, with Tensilica holding ~$30M of cash as of 2012-12-31). Tensilica today is a Cadence subsidiary/brand. Tensilica was never in bankruptcy.
• Notable status note: The patent itself lapsed for failure to pay maintenance fees, with an adjusted expiration of 2025-02-16. Whatever entity holds it today has stopped paying to keep it alive.

---

Assignment timeline

The authoritative record shows exactly one recorded assignment event post-filing, and it is the original employee→company assignment:

• 2002-04-23 (executed) / recorded 2002-04-23 — Reel/frame not displayed in the sources I could reach (Google Patents legal-events row marks it "reassignment" with no reel/frame text in the fetched page)

  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNOR'S INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Michael Carchia; Hongbin Ji (as individuals)
  • Assignee: Tensilica, Inc.
  • Correspondent: Not retrievable. I could not pull the correspondent of record for this recording. Therefore I cannot run the recurrence check the brief asks for (repeat-player attorney across the chain). Flagging this as a gap, not as a clean result.
  • Context: Original employee assignment — the ordinary inventor-to-employer conveyance executed on the filing date.

• 2013-04-22 (corporate close) — No assignment recording verified at USPTO

  • Conveyance: Merger / stock acquisition (Cadence Design Systems, Inc. acquired Tensilica, Inc.) — this is a corporate event documented in Cadence's SEC filings, not a reel/frame I confirmed at the Assignment Center
  • Assignor: Tensilica, Inc. → Assignee: Cadence Design Systems, Inc. (by operation of the acquisition)
  • Correspondent: not determinable (no recording verified)
  • Context: Internal corporate acquisition / integration. Even if recorded, this is a reorg-and-absorb transaction, not a transfer to an asserter. Note that Google Patents still lists "Current Assignee: Tensilica Inc," which is consistent with either a bulk merger recording that Google's entity resolver did not re-key, or with no assignment ever having been recorded for this patent. I cannot distinguish these two possibilities on the evidence I retrieved.

No other recorded assignments found. No assignment to any LLC, holding company, licensing vehicle, or defensive aggregator appears anywhere in the record I could reach. This is a genuine finding: the patent appears never to have left the Tensilica/Cadence corporate family by recorded assignment.

---

Timeline diagram

timeline
    title Ownership of US 7227842
    2001 : Provisional filed by Tensilica inventors
    2002 : Utility application filed
         : Inventors assign to Tensilica Inc
    2007 : Patent issues to Tensilica Inc
    2013 : Cadence acquires Tensilica Inc
    2025 : Patent expires for unpaid maintenance fees

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
No licensing-only LLC ever appears in the chain. The only recorded assignee is Tensilica, Inc., a genuine SIP-core operating company with a licensable product. No "IP / Patents / Licensing / Holdings / Ventures" suffix assignee, no registered-agent address, no single-purpose Delaware or Texas LLC. (Absence of any post-issuance recording is the relevant fact here — see signal 4.)

2. Known asserter in the chain — NOT PRESENT.
Neither Tensilica, Inc. nor Cadence Design Systems, Inc. appears on any of the reference NPE lists in the brief (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) or in the Unified Patents / RPX high-frequency-plaintiff directories I searched. Both are established operating companies: Tensilica a SIP vendor, Cadence a NASDAQ-listed EDA and IP company (CDNS).

3. Repeat correspondent across the chain — UNCLEAR / NOT DETERMINABLE.
There is only one candidate recording (2002-04-23), and its correspondent of record did not surface in the materials I retrieved, so the recurrence test cannot be run. I will not guess at a firm name. To close this out properly, the reel/frame for the 2002-04-23 assignment should be pulled directly at the Assignment Center and the correspondent field read off the recorded cover sheet. One appearance would not be a finding in any event — the brief is correct that the signal is recurrence, and there is no second link here to recur against.

4. Cascading transfers — NOT PRESENT.
The opposite pattern holds: zero consecutive LLC-to-LLC hops. In 23+ years since issuance (2007 → present) there is no recorded assignment at all. Chained shell transfers in <24 months do not occur; here there are no transfers at all.

5. Pre-litigation transfer — NOT PRESENT.
I found no infringement suit naming US 7,227,842 as an asserted patent. The patent appears in litigation/PTAB dockets only as cited prior art — e.g., in the file-history exhibits of Palo Alto Networks v. Centripetal Networks (IPR2021-01152, Ex. 1002, citing the patent at entry 13) and in the '213 patent file history in IPR2018-01512. Being cited as prior art is not assertion. A pre-litigation transfer signal therefore has no anchor event.

6. Bankruptcy fire-sale — NOT PRESENT.
Tensilica was acquired in a solvent all-cash transaction (~$326M at close, ~$30M cash on hand pre-close); it never filed Chapter 7 or 11. No Kodak/Nortel/Polaroid-style proceeding touches this chain.

7. Privateering — NOT PRESENT.
No evidence that Cadence or Tensilica transferred this patent to an NPE to assert against competitors. Cadence's Tensilica acquisition was a product-roadmap and IP-portfolio acquisition (per its own 10-K, the rationale was "expanded our design IP offerings"), and I found no SEC disclosure, Patent Progress, or EFF coverage tying this patent to an assertion campaign.

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates (to the extent it terminates anywhere) inside Cadence — an operating company — and then the patent died of non-payment rather than being neutralized by a defensive aggregator.

Aggravating context worth noting (not an NPE signal): The patent is classified in H04L45/54 (organization of routing tables) and H04L47/2441 (QoS relying on flow classification), i.e., core router/switch packet-classification art. It lapsed on 2025-02-16 for failure to pay maintenance fees. Patent families that go abandoned for fee non-payment are typically ones the owner has determined carry no licensing or defensive value — the practical inverse of an assertion-ready asset.

---

Verdict

Insufficient data — more precisely, documented as a single, unbroken operating-company chain, with the Assignment Center reel/frame layer unverified.

The only recorded conveyance I could establish is the 2002-04-23 inventor→Tensilica, Inc. assignment executed on the filing date, with Michael Carchia and Hongbin Ji as assignors. From there the patent passed (if at all) only by way of Cadence's 2013-04-22 acquisition of Tensilica — a corporate event evidenced by Cadence's FY2013 Form 10-K and its 2013-03-11 acquisition announcement, not by a reel/frame I confirmed. No NPE, licensing LLC, or aggregator ever appears, no assertion campaign naming this patent exists (it surfaces only as cited prior art in unrelated IPRs), and the patent expired for non-payment of maintenance fees on 2025-02-16. I am explicitly declining to call this "NPE — moderate confidence" off a single unverified link and an unretrieved correspondent field.

To complete this file (the two open gaps, in priority order):

1. Pull the reel/frame for the 2002-04-23 recording at https://assignment.uspto.gov/patent/index.html (search patent 7227842) and record the conveyance and correspondent fields verbatim — this closes the signal-3 recurrence test.
2. Query the same search for assignee "Tensilica" / "Cadence Design Systems" around 2013-04 to determine whether the Tensilica→Cadence transfer was ever recorded against this specific patent. Google Patents' persistence of "Current Assignee: Tensilica Inc" suggests it may not have been, which would make this chain a clean one-hop file.

Verify at: https://assignment.uspto.gov/patent/index.html (patent number 7227842) · cross-check https://patents.google.com/patent/US7227842/en legal events · https://www.sec.gov for Cadence CDNS 10-K FY2013 (Tensilica acquisition, 2013-04-22).

I'll research the prior art citations for US 7,227,842. Let me run several targeted searches.

I found that the '842 patent has a "Patent Citations (15)" list. Let me dig into the specific cited references.

Preliminary note on scope and what I could actually retrieve

Before the analysis, one important honesty flag required by the operating rules: the authoritative full text you supplied does not contain the patent's front‑page "References Cited" (Patent Citations) section. Google Patents renders that section separately, and my searches surfaced only a truncated fragment indicating a "Patent Citations (15)" list associated with US 7,227,842 — but I was unable to retrieve the 15 actual entries, and I was likewise unable to pull a live USPTO PatentCenter "References Cited" table. That fragment is also ambiguous: the "Patent Citations (15)" heading appeared adjacent to US7227842B1 inside a different patent's page (US 8,379,639 / US 2012/0310941), so it may belong to that page rather than to the '842 record.

I therefore will not fabricate the examiner‑cited prior‑art list. Below I (1) give you what the '842 record does document as cited references, (2) separate true prior art from non‑prior‑art "Cited By" material, and (3) provide the §102 framework and a preliminary relevance mapping — all explicitly labeled by confidence.

I also note the strict instruction: searches returned results for similar‑suffix numbers (e.g., US 6,239,842, "the '842 Patent" in unrelated Oplus/Cathx and Canon matters) which are a different patent and are not conflated here.

---

1. The record for US 7,227,842 (confirmed)

Because the application was filed in 2002 (pre‑AIA, before 2013‑03‑16), the governing novelty statute is pre‑AIA 35 U.S.C. §102, principally:

• §102(b) — patents or printed publications more than one year before the U.S. filing date, i.e. before 2001‑04‑23;
• §102(a) — knowledge/use by others in the U.S., or patents/printed publications before the invention date;
• §102(e) — U.S. patents/applications "by another" with earlier effective filing dates.

---

2. References the '842 record itself documents

2.A — Cross‑referenced / incorporated‑by‑reference applications (not examiner prior art)

These are recited in the CROSS‑REFERENCE section and the custom‑instruction paragraph. They are commonly owned Tensilica family material, incorporated by reference, not "references cited against" the patent:

2.B — Patents incorporated by reference for enabling the configurable processor

The '842 text states: "techniques described in U.S. Pat. Nos. 6,477,683, 6,701,515, 6,477,697 and U.S. Pat. No. 7,036,106, all commonly owned by the present assignee and incorporated herein by reference."

• US 6,477,683; US 6,701,515; US 6,477,697; US 7,036,106 — Tensilica, Inc.
• Confidence: medium‑low on titles and exact dates. I was not able to retrieve these four records' titles/filing/issue dates in this session, and I won't invent them. They are cited only for how to implement an Xtensa configurable processor with customized instructions — i.e., processor‑generation/enabling art, not packet‑classification art.

2.C — Non‑patent literature cited in the specification

1. Pankaj Gupta and Nick McKeown, "Packet Classification on Multiple Fields," Proc. ACM SIGCOMM '99, Cambridge, MA, Aug. 30–Sep. 3, 1999, pp. 147–160 (also ACM SIGCOMM Computer Communication Review, vol. 29, no. 4, Oct. 1999; DOI 10.1145/316194.316217). Confirmed via ACM DL, SIGCOMM program, and DBLP.

   • The '842 patent expressly credits this paper for the "equivalent identifier (eqID)" concept ("the concept of equivalent identifier is introduced in Gupta et al.…").

2. Tuple‑space search — the specification's background says "Packet classification using tuple space search is given in additional efforts." The corresponding art is V. Srinivasan, S. Suri, G. Varghese, "Packet Classification Using Tuple Space Search," Proc. ACM SIGCOMM '99, pp. 135–146 (confirmed via DBLP/SIGCOMM program). The patent does not give a formal citation, so I mark the linkage as inferred but well‑grounded.

---

3. What is NOT prior art: the "Cited By" list (104 entries)

Google Patents reports ~104 "Cited By" references (Cisco, Juniper, Samsung, IBM, Broadcom, 3Com, Wake Forest, Panwar/Juniper, etc.). These are later patents that cite '842 as background art. Because they post‑date the '842 priority date, they cannot anticipate or render obvious claims 1–3 under §102/§103. I include this only to prevent them being mistaken for prior art. (The prior sections of this analysis correctly flagged the IDS/citation appearances in IPR2018‑01512 and IPR2021‑01152/01520 as background citations, not assertions.)

---

4. Preliminary §102 relevance mapping (tentative — requires element‑by‑element verification)

Bottom line on anticipation: On the material I can actually document, no single reference appears to anticipate Claim 1 in full, because Claim 1 uniquely couples (a) per‑field eqID/bitmap matching with (b) the rudimentary‑interval creation and endpoint‑adjustment logic. The closest art — Gupta & McKeown (SIGCOMM '99) — speaks to the classification half only. Claims 2 and 3 (bitmap association with new intervals; the incremental new‑rule update) appear to have the strongest novelty over the documented art. This is a preliminary view, not a formal invalidity opinion.

---

5. Explicit uncertainty and recommended verification

1. The 15 front‑page "Patent Citations" were not retrieved. Do not treat any list of examiner‑cited references as complete. The definitive sources are:
   • USPTO PatentCenter / Patent Application 10/133,689 "References Cited" and the issued patent front page;
   • the patentimages.uspto.gov / storage.googleapis.com PDF of US7227842B1 (front page lists "U.S. Patent Documents" cited);
   • Google Patents → US7227842B1 → "Patent Citations" (the count is reported as 15, but I could not confirm the entries or that the heading belongs to the '842 page).
2. Titles/dates for US 6,477,683; 6,701,515; 6,477,697; 7,036,106 were not verified in this session — they are asserted only as Tensilica, commonly owned, configurable‑processor references, exactly as the '842 text describes them.
3. US 7,274,697's issue date (2007‑09‑25) and the 10/032,379 linkage come from a third‑party inventor index (radaris) and from the '842 text; treat the date as search‑sourced, not USPTO‑confirmed.
4. §102 mapping is preliminary. Pre‑AIA §102(e) requires a reference "by another"; because Tensilica family members share inventors/assignee with '842, several of the cross‑referenced applications may be disqualified as §102(e) art and are better characterized as family/incorporated‑by‑reference material than as anticipating prior art.
5. No auto‑correction applied: patent numbers, application numbers, and dates are reproduced exactly as found; where a source (e.g., Golden wiki) rendered the app number as "101336890," that is a rendering artifact and was not used.

If you can supply the patentimages/USPTO front‑page PDF or a PatentCenter export for 10/133,689, I can complete the element‑by‑element §102 chart against the full 15‑reference "References Cited" list.

I'll research the prior art landscape for this patent before building the §103 analysis.

Let me ground the key prior-art references more precisely.

Obviousness Analysis — U.S. Patent No. 7,227,842 B1

Under 35 U.S.C. § 103(a) (pre‑AIA, application filed April 23, 2002)

---

0. Scope note and assumptions (read first)

The user asked me to "use the results from the Prior Art section of this page." The authoritative record supplied for this patent is the Google Patents rendering of US7227842B1 (https://patents.google.com/patent/US7227842/en). That rendering contains no dedicated "References Cited" (Patent Citations) field — only a "Cited By (104)" list, which is post‑dating art and therefore not prior art to the '842 patent (it is only evidence of the crowdedness of the field). The only prior art that the '842 specification itself identifies is:

Because the generic background descriptions are identifiable in the open literature, I have mapped them to the specific references a POSITA would have found, and I flag each mapping. Where I map a generic statement to a named paper, I am inferring, and I say so. All page/URL citations are given so the reader can verify.

---

1. Legal framework applied

• Pre‑AIA §103(a): obvious if the differences between the claimed subject matter and the prior art are such that the subject matter as a whole would have been obvious at the time of invention to a POSITA. Graham v. John Deere factors: (1) scope/content of prior art; (2) differences; (3) PHOSITA level; (4) secondary considerations.
• KSR Int'l v. Teleflex (2007): a combination of known elements is obvious where the improvement is the "predictable use of prior art elements according to their established functions"; motivation may come from "design incentives," "market forces," "common sense," or the "finite number of identified, predictable solutions." This case was decided one week after the '842 patent issued, but its reasoning applies to the pre‑AIA statute.
• §103(c) common-ownership carve-out (as amended, applicable to applications filed on/after Nov. 29, 1999 — which includes the '842 application): subject matter that is commonly owned and qualifies as prior art only under §102(a), (b), (c), (e), (f), or (g) may not be used in a §103 rejection. This is material here — see §7.
• MPEP 2143.01: a claim to a mere aggregation of known functions is obvious if the combination does no more than each element does separately; conversely, a rejection must explain the functional interaction where the claim recites one. Here there is interaction (the interval/endpoint bookkeeping feeds the bitmap structure used by the matcher), so the rejection must articulate it — which I do in §4–6.

---

2. Person of ordinary skill in the art (PHOSITA) and critical date

Critical date: April 24, 2001 (provisional 60/286,262 priority; the '842 record's stated priority). References must pre‑date the actual invention date, not merely April 24, 2001, but I use April 24, 2001 as the conservative outer bound.

PHOSITA: a B.S. in EE/CS (or equivalent) plus 2–5 years' experience in high‑speed packet forwarding / network‑processor design, or an M.S. plus 1–2 years, with working familiarity with (a) packet‑classification algorithms (linear search, tries, grid‑of‑tries, cross‑producting, tuple‑space search, bit‑vector/bit‑parallel schemes) and (b) extensible/configurable processor design (designer‑defined instructions). This is the level of skill the '842 specification presupposes when it discusses the tradeoff "between query time and memory size" and lists TCAM, network processors, and product examples.

---

3. Claim scope (for this analysis only)

Per the previously generated section (which I do not repeat), the patent has 3 claims, claim 1 independent. For §103 purposes I break claim 1 into elements 1a–1j:

• 1a receiving a packet;
• 1b matching, using a processor, a plurality of fields against N rules, including, per field:
  • 1b1 associating equivalent IDs with respective field values;
  • 1b2 associating a respective bitmap with each equivalent ID, the bitmap indicating a matching rule;
  • 1b3 determining the bitmap for the packet's field value;
• 1c determining a possible range of field values;
• 1d identifying that range as a first rudimentary interval with associated endpoints;
• 1e parsing a rule to determine a matching range for the field;
• 1f identifying upper/lower ends of the matching range;
• 1g comparing the upper/lower ends against the endpoints of the first rudimentary interval;
• 1h creating up to two new rudimentary intervals based on the case result of the comparison;
• 1i associating adjusted endpoints with the first and up‑to‑two new intervals; and
• 1j preparing to forward the packet using the rule.

Critical observation for §103: The issued claims recite only "a processor" and contain no limitation to a configurable processor, an Xtensa core, or any of LOAD_PKT/T1_LOOKUP/T2_LOOKUP/BMP_INTERSECTION/GET_EQID/SELECT_RULE. The "configurable processor with customized instructions" appears only in the title/abstract/specification. A POSITA cannot rescue the claims with unclaimed specification subject matter. The obviousness battleground is therefore 1b (eqID + bitmap matching) and 1c–1i (rudimentary‑interval creation/update).

---

4. The prior art

Reference A — Gupta & McKeown, "Packet Classification on Multiple Fields," ACM SIGCOMM '99

https://dl.acm.org/doi/abs/10.1145/316194.316217 · http://conferences2.sigcomm.org/sigcomm/1999/papers/session4-3.html

Expressly admitted prior art by the '842 specification ("the concept of equivalent identifier is introduced in Gupta et al."). This is RFC (recursive flow classification). As the paper states in the retrieved text:

"Each of the parallel lookups yields an output value that we will call eqID."
"we assign a class bitmap (CBM) for each CES indicating which rules in the classifier contain this CES… This bitmap has one bit for each rule in the classifier. For example, E0… will have the CBM 101000_b…"
"…we wish to thank Andrew McRae at Cisco Systems for independently suggesting the use of bitmaps in storing the colliding rule set…"

Discloses: 1b1 (eqID per field/chunk value), 1b2/1b3 (bitmap of matching rules per equivalence class, used to compute the final match), the multi‑field matching architecture, and priority selection of the best matching rule.

Does not disclose: incremental insertion of a new rule by splitting existing intervals — RFC is a precomputed multi‑stage table; the paper itself treats updates as a weakness.

Reference B — Lakshman & Stiliadis, "High‑Speed Policy‑Based Packet Forwarding Using Efficient Multi‑Dimensional Range Matching," ACM SIGCOMM '98

https://dl.acm.org/doi/abs/10.1145/285243.285283 · http://conferences2.sigcomm.org/sigcomm/1998/tp/abs_17.html

This is the reference the '842 background is most likely pointing to with "a scheme based on bit‑parallelism to find the right tradeoff between query time and memory size." (Inference — flagged.)

Lakshman & Stiliadis project the ranges of all rules on each dimension onto the field's number line, partitioning it into non‑overlapping intervals ("elementary intervals"); each interval carries a bit vector with one bit per rule; the packet's field value selects the interval, its bit vector is ANDed across dimensions, and the highest‑priority set bit identifies the matching rule.

Discloses: 1c (possible range of values), 1d (a first interval with lower/upper endpoints), 1b2 (bitmap with a bit per rule indicating coverage), 1b3 (bitmap selected by the packet's field value), 1h in substance (partitioning/merging intervals as the rule set is defined), 1i (interval endpoint bookkeeping), 1j (forward per the matched rule). It is, in substance, the rudimentary‑interval + bitmap model.

Does not disclose (with certainty): the eqID indirection — i.e., storing, per interval‑lookup entry, an index into a separate deduplicated bitmap table rather than the bitmap itself. That memory‑compression step is Reference A's contribution.

Reference C — Srinivasan, Varghese, Suri & Waldvogel, "Fast and Scalable Layer Four Switching," ACM SIGCOMM '98

https://dl.acm.org/doi/10.1145/285237.285282

Discloses: (i) converting filter ranges into prefixes by expansion (the standard range‑to‑prefix technique), (ii) grid‑of‑tries and cross‑producting, and (iii) explicit discussion of update cost as a design axis. Importantly, the same authors' later work is the tuple‑space paper the '842 background admits ("Packet classification using tuple space search is given in additional efforts"), and tuple‑space search is the canonical scheme selected for its fast incremental update capability.

Reference D — Srinivasan, "A Packet Classification and Filter Management System," IEEE INFOCOM 2001 (program dated April 22–26, 2001)

Indexed at https://www.semanticscholar.org/author/V.-Srinivasan/23633340

The indexed abstract states it presents "an incremental update algorithm based on maintaining an event list that can be applied to many of the previously presented filter matching schemes which did not support incremental updates."

⚠️ Date caveat — this is the weakest link in the chain. The publication window (April 22–26, 2001) brackets the provisional filing date (April 24, 2001) by ±2 days. Whether it is §102(a) art depends on the applicants' actual invention date. I therefore treat Reference D as corroborating, not load‑bearing, and rest claim 3 on the general incremental‑update motivation (Reference C's updates discussion + tuple‑space search, both admitted/known) plus routine interval‑insertion technique. If a §103 rejection were to rely on D alone for claim 3, expect a swear‑behind / prior‑invention dispute.

Reference E — Standard computational‑geometry interval/segment‑tree technique (e.g., Bentley & Ottmann, Algorithms for Reporting and Counting Geometric Intersections, IEEE Trans. Comput. 1979; Computational Geometry, Springer 1985 — both cited in the modern literature indexed at https://www.mdpi.com/1999-4893/15/8/285)

Discloses the technique, not the application: inserting a new interval [L,U] into an ordered set of existing intervals [Bi,Ei] requires exactly four exhaustive relationships — L==Bi & U<Ei; L==Bi & U≥Ei; L>Bi & U<Ei; L>Bi & U≥Ei — each resolved by trimming one endpoint and splitting into at most two intervals. These are the '842 "Cases 1–4." A POSITA implementing any interval‑indexed structure necessarily implements this logic.

Reference F — Admitted prior art network processors (MMC nP7120, IBM Rainier, PMC‑Sierra ClassiPI) and configurable‑processor art (Tensilica U.S. 6,477,683 / 6,477,697 / 6,701,515 / 7,036,106)

https://patents.google.com/patent/US6477683B1/en

Discloses: a programmable processor "network application specific processor" capable of program execution, and (for the Tensilica patents) adding designer‑defined, application‑specific instructions to a configurable processor — i.e., exactly the unclaimed "configurable processor with customized instructions" implementation detail. These are the natural candidates for 1a's "using a processor." See §7 for the common‑ownership problem with the Tensilica patents.

---

5. Element‑by‑element mapping and proposed combinations

5.1 Combination #1 — Primary: B (Lakshman & Stiliadis '98) + A (Gupta & McKeown '99)

Motivation to combine A with B (KSR‑compliant):

1. Same field, same problem, same solution class. Both references attack multi‑field packet classification at gigabit line rates using bit vectors/bitmaps; a POSITA would treat them as the two leading members of one known design family.
2. Addressing a recognized deficiency of B. Storing a full N‑bit vector at every EI for every field is memory‑prohibitive (the (2N+1)·N bound is discussed in the '842 spec itself). Gupta's eqID indirection — assigning a single index to each distinct bitmap pattern and storing the bitmaps once in a separate table — is a recognized memory‑compression technique whose benefit is squarely predictable and whose application to B's EIs requires no change in the principle of operation. The '842 background itself concedes the governing tradeoff: "there is a tradeoff between query time and memory size," and that the prior art used bit‑parallelism "to find the right tradeoff." That concession is the motivation.
3. Predictable result / finite solutions. KSR: where the prior art discloses a finite number of identified, predictable solutions (store the vector inline vs. store an index to a deduplicated vector table), choosing the memory‑efficient one is obvious.

Result: Combination #1 discloses elements 1a–1j and claim 2. Claim 1 would have been obvious.

---

5.2 Combination #2 — B + A + C (Srinivasan '98) — tightens the range/hierarchy elements

Reference C supplies the rule → matching range parsing (1e) in the exact prefix/range‑expansion form the '842 spec uses (e.g., prefix 38.170.141 → range, >1023 → [1024, 65535]), and supplies the update‑cost design axis. Motivation: C is by overlapping authors and the same community as B, addresses the identical "least‑cost matching filter at gigabit speeds" problem, and its range‑expansion technique is the standard front‑end for any range‑based classifier. Combining A+B+C yields an even cleaner obviousness showing for 1e and for the rule‑management thread generally.

---

5.3 Combination #3 — B + A + C + D (for claim 3)

For claim 3 (iteratively adding a new rule and re‑splitting intervals), D teaches "an incremental update algorithm… that can be applied to many of the previously presented filter matching schemes which did not support incremental updates." Motivation:

• The '842 spec itself admits the need: "to support per‑flow queuing, a new rule may be created once a new connection is established… new rules will be added quite frequently," and dynamic ACLs "may undergo frequent changes on the order of hundreds of changes per second." That is an express, admitted design incentive (KSR prong: "market forces/design incentives").
• Once that need is identified, applying the routine interval‑insertion logic of E (the four exhaustive cases of [L,U] vs. [Bi,Ei]) to B's EIs is a predictable, mechanical step: exactly the kind of "combination of familiar elements according to known methods" that KSR holds obvious.

Result: claim 3 would have been obvious over B + A + C + D, with D corroborated by C's/tuple‑space's update discussion.

---

5.4 "Obvious to try" and the §112‑style drafting observation

Claim 1 recites classification (1a–1b, 1j) and rule‑database maintenance (1c–1i) in a single method claim. Both halves were independently known; the only glue is that both operate on the same interval/bitmap data structure. Under KSR, "if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious." Here the "similar device" is the same classifier, and the "technique" (interval splitting with endpoint bookkeeping) is the standard way to keep an interval‑indexed structure current. The claim therefore reads on a predictable combination of two known functions on a shared, known data structure, with the combination achieving no result beyond the sum of its parts. The functional interaction the examiner would have to articulate is: rule additions must update the very interval→bitmap mapping that the matcher later consults. That interaction is inherent in B's structure and is why the combination is more than a mere aggregation — but it is still obvious, because B's EIs are already defined by rule bounds and therefore already change whenever the rule set changes.

---

6. Element‑by‑element gap analysis — what the strongest references don't say

No single reference anticipates claims 1–3 — A lacks interval splitting; B lacks eqID indirection; D lacks the classification structure. The case is an obviousness case, not an anticipation case.

---

7. Two defenses the patentee would raise (and my assessment)

(a) The §103(c) common‑ownership carve‑out. The Tensilica patents (6,477,683; 6,477,697; 6,701,515; 7,036,106) and the earlier Tensilica applications (60/249,627; 09/780,895 → US 6,888,838; 60/264,667; 10/032,379) are commonly owned with the '842 patent (all Tensilica, and the record shows Tensilica as original/current assignee). Because the '842 application was filed on/after Nov. 29, 1999, the amended §103(c) applies, and any of that material that qualifies as prior art only under §102(a), (b), (c), (e), (f), or (g) cannot be used in a §103 rejection. Likewise the '842 specification's incorporation‑by‑reference of those items does not convert them into usable prior art.
Effect: A durable §103 rejection should not be anchored on Tensilica's own configurability patents. It is anchored on A, B, C, D, E (Gupta & McKeown; Lakshman & Stiliadis; Srinivasan et al.) — all third‑party prior art not subject to §103(c). The Tensilica patents remain useful only as background evidence of what a POSITA knew and/or if the patentee ever tried to import the configurability limitation into the claims (which it cannot do now, since the issued claims omit it).

(b) "The specific four‑case recursive update is novel." The patentee would argue the recursive, memory‑access‑minimizing update (and the spec's admitted optimization of choosing which side gets the new eqID) is non‑obvious. Assessment: this is a real but narrow argument. The algorithmic taxonomy of four cases is dictated by the four exhaustive ways a closed interval can intersect another, i.e., it is forced once the EI data structure is chosen (E). The optimization (give the new eqID to the smaller side to minimize RIB writes) is the kind of optimization a POSITA applies routinely. But if claim 3 were construed to require the recursive re‑invocation with modified endpoints [Ei+1, U] as a specific ordered algorithm, the patentee has a colorable non‑obviousness argument because no single reference has been shown (in the record I can verify) to disclose that precise recursion. Expect the rejection for claim 3 to turn on whether D is held to be §102(a) art — see the ±2‑day date caveat.

---

8. Secondary considerations (objective indicia)

I found no evidence of nexus‑bearing objective indicia that would rebut the prima‑ facie case:

• No litigation was identified involving the '842 patent (per the previously generated litigation section, and my own searches confirm only citation/prior‑art appearances). Lack of assertion activity is weak‑to‑neutral evidence.
• No commercial‑success / licensing‑nexus evidence keyed to the claimed interval/bitmap subject matter (as opposed to the broader Xtensa product line) is present in the record. Tensilica's 2002/2006 press activity (http://blog.tensilica.com/2006/05/key-tensilica-configurable-processor.html; https://semiiphub.com/news/tensilica-secures-patents-covering-automatic-generation-configurable-extensible-processors) concerns U.S. 6,477,683, a different patent and different subject matter — not the '842 claims.
• No unexpected results are shown: the 16‑cycle/30‑cycle performance figures and the "OC48 with two 200 MHz processors" statement are in the unclaimed specification, and even if imported they would be the predictable consequence of the known eqID/dedup memory reduction — a KSR "predictable result," not an unexpected one.

---

9. Conclusion

Bottom line: Claims 1 and 2 of US 7,227,842 are strongly vulnerable to a §103(a) rejection over Lakshman & Stiliadis (SIGCOMM '98) in view of Gupta & McKeown (SIGCOMM '99) — with Srinivasan et al. (SIGCOMM '98) for the range‑parsing elements — because the references are in the same field, address the identical problem, and the eqID/bitmap indirection of Gupta combined with the elementary‑interval/bit‑vector structure of Lakshman & Stiliadis is a predictable improvement addressing the very memory‑vs‑query tradeoff the '842 specification admits. Claim 3 is also vulnerable, but the showing leans on an incremental‑update reference whose publication date straddles the priority date; a durable claim‑3 rejection should be built on the admitted need for fast updates plus routine interval‑insertion technique, or on a second corroborating update reference obtained from a full search.

---

10. Explicit uncertainties / honesty flags

1. "Prior Art section" provenance. The record I was given contains no examiner‑citation list for the '842 patent. I constructed the reference set from (i) the one reference the '842 spec expressly names (Gupta & McKeown '99), (ii) the generic background descriptions (which I infer correspond to Lakshman & Stiliadis '98 and Srinivasan et al. '98 — inference, not certainty), and (iii) independently verified third‑party publications. If the page you are working from lists different specific prior art, my element mapping should be re‑run against that list.
2. Reference D's date (Srinivasan, A Packet Classification and Filter Management System, INFOCOM 2001, program April 22–26, 2001) is within ±2 days of the April 24, 2001 provisional. I have flagged this wherever it matters and have not treated it as dispositive.
3. Lakshman & Stiliadis' exact data structures. I am confident about the elementary‑interval + bit‑vector projection scheme, but I have not verified whether they store the bit vector inline or via an index; that specific point determines whether B alone reaches element 1b1, and I have assumed B does not (hence the need for A). Verifying the full SIGCOMM '98 text would sharpen the mapping.
4. No litigation/PTAB history regarding the '842 patent was found; none is assumed. The patent's recorded status is "Expired – Fee Related" (adjusted expiration 2025‑02‑16), which is consistent with the absence of assertion activity.
5. I have not auto‑corrected any identifiers; "7227842," "7,227,842," "60/286,262," "09/780,895," "6,888,838," "6,477,683," "6,477,697," "6,701,515," and "7,036,106" are reproduced exactly as given.