US 7246173

The initial searches returned no results. Let me try broader queries.

US Patent 7,246,173 — Summary

Bibliographic data (from the authoritative Google Patents record provided, consistent with USPTO records found via search)

Abstract: "A method and methodology are provided for classifying Internet Protocol (IP) data in a packet switch network. Data may be received at a first node and classified based on source routing information of said data. The source routing information may be provided within LSRR/SSRR of IPv4 data or may be provided within a routing header of IPv6 data."

What the invention does (plain language): In RSVP (Resource Reservation Protocol) QoS environments, packets that use IPv6 routing headers or IPv4 LSRR/SSRR source routing carry the next intermediate router's address in the IP destination address field until source routing is fully consumed. That causes routers to classify the packet against the wrong RSVP session (the session is keyed to the final destination address). The patent fixes this by classifying the packet based on an entry in the source-routing header (specifically, the last destination address in the routing list) instead of the destination address field in the IP header, so packets receive their reserved QoS even mid-route.

Independent claims (6 total) — plain-language overview

• Claim 1 (method, IPv6/header-generic): A method of classifying IP data sent from a source to a destination in a packet-switched network: receive the data at a first node, where the data includes a header listing at least one intermediate node to be visited en route to the destination; then classify the data at that first node based on an entry in that header (rather than the IP destination field).
• Claim 5 (method, IPv4-specific): Same method as claim 1, except the header entry used for classification is provided within the IPv4 LSRR (loose source and record route) or SSRR (strict source and record route) option.
• Claim 13 (router, means-plus-function): A router with means for receiving IP data at a first node (the data having a header listing at least one intermediate node) and means for classifying the data at the first node based on an entry in that header.
• Claim 17 (router, means-plus-function, IPv4): Same as claim 13, except the classifying entry is provided within the IPv4 LSRR/SSRR option.
• Claim 25 (router, structural): A router with a receiving device for receiving the IP data at a first node (data having a header listing at least one intermediate node) and a processor device coupled to the receiving device for classifying the data at the first node based on an entry in that header.
• Claim 30 (router, structural, IPv4): Same structure as claim 25, except the classifying entry is provided within the IPv4 LSRR/SSRR option.

Dependent claims add details such as: classification based on the last destination address field of the routing header (claims 4, 16, 28); classification based on the last address in LSRR/SSRR (claims 7, 19, 32); resource reservation (RSVP) steps (claims 9–10, 21–22, 34–35); storing source-routing information in memory (claims 11, 23, 36); and forwarding to a second node for re-classification (claims 12, 24, 37).

Litigation / CAFC 2026 docket notes

• The patent is being actively enforced by IOT Innovations LLC (an Empire IP LLC plaintiff; portfolio originally from Intellectual Ventures). It appears in multiple district-court complaints, e.g., IoT Innovations LLC v. BH Security d/b/a Brinks Home (E.D. Tex., 2:24-cv-00219 and later 2:26-cv-00204), IoT Innovations LLC v. D-Link Corporation (E.D. Tex., 2:25-cv-01009, consolidated into lead case 2:25-cv-1135), and IoT Innovations LLC v. Lutron Electronics (S.D. Fla., 0:25-cv-60483).
• CAFC 2026 docket found: IoT Innovations LLC v. Lutron Electronics Co., Inc., No. 26-1297 (Fed. Cir.), appeal docketed December 31, 2025 (briefing extended; appellant's opening brief due April 16, 2026). The underlying Lutron complaint asserts the '173 patent (52 claims) among others, so this CAFC appeal is the relevant 2026 Federal Circuit matter involving this patent. Uncertainty: I could not confirm from the search results the specific issues on appeal or whether the '173 patent remains part of the appeal as opposed to the other asserted patents; the district-court docket would need PACER confirmation.

Caveats: I did not access the USPTO's own database directly (searches returned the Google Patents mirror of the USPTO record and Justia/docket sources). The bibliographic data matches the authoritative patent text provided. I could not independently verify the full CAFC 2026 docket for the '173 patent specifically beyond case 26-1297, and the "expired" status means any enforcement relates to past damages rather than ongoing injunctive relief.

The initial searches surfaced several IoT Innovations LLC cases. Let me now verify each docket number and identify which ones actually assert the '173 patent, using the Unified Patents portal and docket databases.

Confirmed the TP-Link and Lutron cases assert the '173 patent. Now let me verify the other dockets listed in the Google Patents record (2:24-cv-00704, 9:23-cv-81528, 2:25-cv-01135, 2:25-cv-01009, and the others) to determine which assert the '173 patent and their status.

I've reached the step limit for searches, so I'll compile the verified findings and flag what remains unverified.

Known Litigation Involving US Patent 7,246,173 (as of April 26, 2026)

Verified cases (confirmed from dockets/complaints that the '173 patent is asserted)

1. IoT Innovations LLC v. TP-Link Corporation PTE. Limited (f/k/a Big Field Global Pte. Limited) et al.

• Case No.: 2:24-cv-00219
• Court: E.D. Texas (Texarkana Division), Judge Rodney Gilstrap / Magistrate Roy S. Payne
• Filed: March 28, 2024
• Plaintiff: IOT Innovations LLC
• Defendants: TP-Link Lianzhou Co., Ltd.; TP-Link Corporation Ltd; TP-Link Corporation PTE. Limited (f/k/a Big Field Global Pte. Limited); Big Field International Limited; TP-Link Technologies Co., Ltd.; TP-Link International Ltd.
• '173 patent: Yes — complaint Exhibit C is "Evidence of Use Regarding U.S. Patent No. 7,246,173" (also asserted '224, '798, RE44,191, and others). Prayer for relief seeks damages and injunction as to the '173 patent.
• Status: Closed per Ex Parte/Unified Patents docket trackers; waivers of service executed April 2024. Final disposition not confirmed (no judgment/settlement terms located), but the case is no longer active.

2. IoT Innovations LLC v. ecobee Technologies ULC

• Case No.: 2:24-cv-00729
• Court: E.D. Texas, Judge Rodney Gilstrap / Magistrate Roy S. Payne
• Filed: September 6, 2024
• Plaintiff: IOT Innovations LLC
• Defendant: ecobee Technologies ULC d/b/a ecobee (British Columbia)
• '173 patent: Yes — asserted with claims 1 and 2 (per complaint analysis), alongside nine other patents.
• Status: Dismissed with prejudice on March 5, 2025 (~180 days after filing) — consistent with a negotiated settlement; both parties to bear their own costs and fees (per PatSnap/Ex Parte docket summaries).

3. IoT Innovations LLC v. Snap One LLC (later amended to add ecobee Technologies ULC)

• Case No.: 2:24-cv-00704
• Court: E.D. Texas, Judge Rodney Gilstrap / Magistrate Roy S. Payne
• Filed: ~August 28, 2024 (complaint docketed 8/28/2024)
• Plaintiff: IOT Innovations LLC
• Defendants: Snap One, LLC (Resideo); First Amended Complaint (11/26/2024) added ecobee Technologies ULC as defendant
• '173 patent: The original complaint's exhibits (7,165,224; 7,280,830; 7,379,464; 8,085,796; 8,401,571; 8,972,576; RE44,742) did not include the '173 patent. However, the First Amended Complaint (filed 11/26/2024) asserts claims 1 and 2 of the '173 patent (per Ex Parte complaint analysis), which is why the Google Patents record links this case to the '173 patent.
• Status: Open/pending as of late 2024 (answers and counterclaims filed Nov.–Dec. 2024). No final outcome located in this session.

4. IoT Innovations LLC v. Lutron Electronics Co., Inc.

• Case No.: 0:25-cv-60483
• Court: S.D. Florida, Judge Melissa Damian / Magistrate Jared M. Strauss
• Filed: March 12, 2025
• Plaintiff: IoT Innovations LLC
• Defendant: Lutron Electronics Co., Inc.
• '173 patent: Yes — complaint Exhibit A is "Evidence of Use Regarding Infringement of U.S. Patent No. 7,246,173"; complaint also asserts 7,280,830, 7,408,872, 7,974,260, 7,974,266, 8,401,571, and RE44,742 against Lutron's smart-home platform (RadioRA 3, HomeWorks QSX, Ketra, Vive, Athena, Hyperion, apps).
• Status: Terminated in S.D. Fla. — transferred. On March 30, 2026, Judge Damian granted Lutron's motion to transfer venue (also denying Lutron's motion to dismiss), ordering transfer to the Central District of California and closing the S.D. Fla. case. (PatSnap and PACER Monitor both confirm the 3/30/2026 transfer order.)
• Related appeal: The earlier analysis identified CAFC appeal No. 26-1297 (docketed December 31, 2025) in the Lutron dispute; note the S.D. Fla. transfer order post-dates that appeal docketing, so the appeal posture should be re-checked on PACER — I could not confirm in this session whether the '173 patent specifically remains live on appeal.

Correction to prior summary

My earlier summary incorrectly identified case 2:24-cv-00219 as "IoT Innovations LLC v. BH Security d/b/a Brinks Home." The verified docket (Justia/PACER) shows 2:24-cv-00219 is the TP-Link case described above. The Brinks Home/Monitronics case (2:23-cv-00016, E.D. Tex., filed 1/13/2023) asserts RE44,191, 8,401,571, 8,085,796, and 7,474,667 — it does not assert the '173 patent. Any "2:26-cv-00204 BH Security" case from the earlier summary remains unverified and should not be relied on.

Cases listed on the Google Patents record as involving the '173 patent but NOT verified in this session

The Google Patents page for US7246173B2 carries litigation links to the following additional dockets that I could not independently confirm (search steps exhausted). They may involve the '173 patent, its continuation 7,974,266, or other portfolio patents:

• 1:22-cv-00730 (D. Del.) — parties/patents unverified
• 2:23-cv-00177 (E.D. Tex.) — parties/patents unverified
• 1:23-cv-12528 and 1:24-cv-11057 (D. Mass.) — possibly related to the IoT Innovations v. SimpliSafe campaign (lead 1:23-cv-10352), but '173 assertion not confirmed
• 9:23-cv-81528 (S.D. Fla.) — parties/patents unverified
• 2:25-cv-00239 (E.D. Tex.) — confirmed via Justia as IoT Innovations LLC v. Resideo Technologies, Inc. et al. (35 U.S.C. § 271); '173 assertion not confirmed
• 2:25-cv-00333, 2:25-cv-00352 (E.D. Tex.) — parties/patents unverified
• 2:25-cv-01009 (E.D. Tex.) — believed to be the D-Link case consolidated into lead case 2:25-cv-01135; '173 assertion not confirmed in this session

Bottom line

Confirmed litigation asserting US 7,246,173: four district-court actions, all brought by IOT Innovations LLC (an Empire IP LLC NPE; assignee chain Nokia → Spyder Navigations → Intellectual Ventures I → IV Assets 189 → IOT Innovations). Two are resolved (TP-Link — closed; ecobee — dismissed with prejudice 3/5/2025), one is pending (Snap One/ecobee, 2:24-cv-00704), and one was transferred to C.D. Cal. on 3/30/2026 (Lutron, 0:25-cv-60483), with a related CAFC appeal (No. 26-1297) docketed 12/31/2025 whose current scope I could not verify. Several additional dockets linked to this patent on Google Patents remain unverified, and I recommend PACER confirmation before relying on them. Note the patent expired (adjusted expiration ~July 27, 2024), so any enforcement is limited to pre-expiration damages.

Proceedings overview

Zero AIA trial proceedings on file. The USPTO Open Data Portal (ODP) returns no IPR, PGR, or CBM proceedings for US 7,246,173, and targeted web searches (including "7,246,173 IPR," "7246173 PTAB," and Unified Patents/RPX queries) surfaced no petition, institution decision, or Final Written Decision against this patent — the only PTAB-adjacent activity in the portfolio is Unified Patents' ex parte reexamination of a different IoT Innovations patent (8,085,796), filed 2025-05-16. The bottom-line defensive posture: the patent is completely untested before the PTAB — all 37 claims remain in force as issued, so no claim-level PTAB ammunition exists for a defendant; validity attacks must be mounted in district court (or via ex parte reexamination), and enforcement is in any event limited to pre-expiration damages because the patent expired ~2024-07-27.

No proceedings on file

(No IPR / PGR / CBM docket numbers exist to report)

• Type: None — no Inter Partes Review, Post-Grant Review, or Covered Business Method review has been filed against US 7,246,173.
• Canonical source: The structured "PTAB proceedings on file" block (USPTO ODP API, most recent ingest) states verbatim: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest."
• Corroboration: Web searches on 2026-08-24 for "7,246,173" inter partes review, "7246173" IPR PTAB, "7,246,173" IPR2023/IPR2024/IPR2025, and Unified Patents "7246173" returned no PTAB petition or decision. The only results were district-court litigation records (all brought by IOT Innovations LLC, the Empire IP LLC NPE that acquired the patent via Nokia → Spyder Navigations → Intellectual Ventures I → IV Assets 189 → IOT Innovations in 2022) — e.g., TP-Link (2:24-cv-00219), ecobee (2:24-cv-00729), Snap One/ecobee (2:24-cv-00704), Lutron (0:25-cv-60483, transferred to C.D. Cal. 2026-03-30; CAFC appeal No. 26-1297 docketed 2025-12-31 — a district-court appeal, not a PTAB appeal), D-Link (2:25-cv-01009, consolidated into lead 2:25-cv-01135), Savant Systems (1:24-cv-11057), and Signify (2:26-cv-00736). None of those dockets reflect an IPR.
• Why this is unsurprising: (1) The patent's adjusted expiration is ~2024-07-27 — the first IoT Innovations complaints (Monitronics, 2:22-cv-00432, filed 2022-11-04) preceded expiration, and IPR practice against an expired patent is rarely cost-effective because only past damages are at stake. (2) 35 U.S.C. § 315(b)'s one-year bar means defendants served with complaints in 2022–2023 are now time-barred from petitioning. (3) Under the USPTO's 2025 "settled expectations" guidance, institution is discretionarily denied for patents roughly six years or older, which this 2007 patent plainly is.
• Defensive value: Neutral-to-negative for defendants — there is no PTAB win to cite, but equally no estoppel burden has been created. The patent's validity has never been tested in any AIA trial, so it is "untested," not "hardened."

Strategic summary

Claim status: 0 of 37 canceled, 0 of 37 sustained, 37 of 37 untested. No IPR has ever been instituted on US 7,246,173, so all six independent claims (1, 5, 13, 17, 25, 30) and all 31 dependent claims remain exactly as issued. There is no PTAB claim-construction ruling, no FWD, no amended-claim set, and no estoppel running against any petitioner. A defendant cannot say "claims 1–4 were canceled" — that would be fabrication; the accurate statement is that the claims have never faced an AIA validity challenge.

Estoppel landscape: clean, and the door is mostly closed by time, not estoppel. Because no trial was instituted, § 315(e)(2) estoppel attaches to nobody. However, the practical window for IPR has largely shut: any defendant served with an IoT Innovations complaint before ~mid-2025 is now outside the § 315(b) one-year bar, and the Director's 2025 centralization of institution authority plus the "settled expectations" guidance makes institution on a 2007-era, expired patent highly unlikely even for newly sued defendants. For defendants still within the § 315(b) window (e.g., newly added parties in the 2025–2026 wave such as D-Link, Signify, Resideo 2:25-cv-01217), a § 102/§ 103 petition on the RFC 1812 (Baker, 1995) and RFC 2460 (Deering/Hinden, 1998) references — both already cited as prior art during prosecution and in the file wrapper's non-patent citation list — remains theoretically available but faces strong discretionary-denial headwinds.

Pattern signals. (1) No serial petitioner: no entity has filed even one IPR, so there is no repeat-petitioner pattern. (2) Patent owner aggressiveness: IOT Innovations is an Empire IP LLC vehicle that has filed 30+ cases across roughly 30 dockets since 2022 (TP-Link, ecobee, Snap One, Lutron, Somfy, SimpliSafe, Savant, D-Link, Resideo, Signify, BH Security, Nice/Fibar, Generac), and it has litigated aggressively — including the Lutron sanctions dispute and a CAFC appeal (No. 26-1297) — but it has not had to defend any PTAB trial. (3) Defensive-aggregator engagement: Unified Patents has taken notice of the portfolio and filed an ex parte reexamination against sibling patent 8,085,796 (filed 2025-05-16) rather than an IPR — consistent with the calculus that IPR is unattractive here (expiration, § 315(b) bars, discretionary-denial risk) while reexamination remains viable. (4) Expiration: Google Patents' legal-status record shows "Expired – Lifetime," adjusted expiration 2024-07-27 — meaning any recovery is confined to damages for pre-expiration conduct; no injunction is possible.

Recommended next steps

• Accept that PTAB is not a live lever. Do not commission an IPR petition budget or search for FWDs to cite — none exist, and the USPTO ODP confirms no AIA trial has ever been docketed for US 7,246,173. If opposing counsel implies otherwise, the burden is on them to produce a proceeding number; none exists.
• If you are a newly-sued defendant still within the § 315(b) one-year window (e.g., served after mid-2025), evaluate a § 102/§ 103 IPR on the prosecution-cited art (RFC 1812; RFC 2460) before committing resources, but model the discretionary-denial risk under the Director's 2025 "settled expectations" guidance — this 2007 patent is a poor IPR candidate on those metrics.
• Route validity attacks through district court. With no estoppel and no PTAB record, the full arsenal is available: § 101 (abstractness of a packet-classification method), § 112 (the means-plus-function claims 13–24 invite a Williamson structure analysis — the specification's "processor device" disclosure is thin), and § 102/§ 103 over the RSVP/routing-header art cited in the file wrapper (RFC 1812, RFC 2460, and the Fankhauser et al. 1998 draft, "RSVP Support for Mobile IP Version 6 in Wireless Environments").
• Consider ex parte reexamination as the administrative alternative. Unified Patents' 2025 reexamination of the portfolio's 8,085,796 patent shows this is the venue the defensive community actually uses for this portfolio; reexamination is not subject to § 315(b) or the IPR discretionary-denial regime, and it can be requested even against an expired patent where past damages are in play.
• Litigate the expiration angle hard. The patent expired ~2024-07-27; demand letters and complaints covering only post-expiration conduct should be met with a motion to dismiss / summary judgment on the temporal scope, and discovery should focus on the date of any accused acts relative to expiration.
• Monitor two things: (1) the CAFC appeal in IoT Innovations v. Lutron, No. 26-1297 (appellant's opening brief due 2026-04-16 per the 2026-02-20 extension order) — though it concerns district-court rulings, a win for Lutron on claim scope could redound to the '173 patent's other defendants; and (2) the Unified Patents reexamination of 8,085,796 — a rejection there would signal examiner receptivity to the same Nokia-era art for '173.

Bottom line: There is no PTAB history to exploit and none to fear — the patent has survived no IPRs because none were ever filed. Your defense must be built in district court, on the merits and on the expiration date, not on a PTAB record that does not exist.

Ownership Chain Analysis — US 7,246,173

Source caveat up front: The reel/frame numbers and dates below come from the USPTO assignment records as mirrored in the Google Patents legal-events feed (the authoritative patent text supplied with this task). I attempted to pull the correspondent of record for each reel/frame from the USPTO Assignment Center, but my searches returned no additional assignment detail and hit the search step limit. Correspondent names are therefore marked "not independently verified" throughout — I have not fabricated them. The reel/frame numbers themselves are from the official record and should be treated as reliable; the correspondents need a direct Assignment Center lookup to complete this picture.

Inventors

Pattern note: Both inventors assigned their rights to Nokia Corporation on 2001-11-14 (recorded 2001-11-15), a routine employer assignment. Neither inventor shows a fast-departure signal within 12 months of filing that would hint at an early portfolio fire-sale; the divestiture happened at the corporate level six years later (see timeline).

Original assignee

• Entity named on the issued patent: Nokia Inc. (Google Patents "Original Assignee" field). The recorded 2001 assignment, however, runs to the Finnish parent, Nokia Corporation (reel 012310/0632) — the standard subsidiary/parent pattern; Nokia Inc. is the US arm of Nokia Corporation.
• Line of business: Major telecom/networking equipment vendor. Nokia operated an IP router product line (Nokia IP Series, via its Nokia Internet Communications division) at the time the invention was made; the claims concern RSVP/QoS classification in routers, which sits squarely in that business.
• Did they ship a product embodying the claims? Plausible but not verified. I found no product sheet confirming that a specific shipped Nokia router implemented the claimed "classify based on the last entry in the source-routing header" logic. The invention reads as a standards-facing fix for RSVP-over-IPv6/IPv4 source routing, consistent with Nokia's router and protocol work — but I will not assert a specific shipped product without a source.
• Current status: Operating. Nokia Corporation remains a major operating company (post-Alcatel-Lucent merger). The '173 patent, however, left Nokia in 2007 and no longer has any connection to Nokia's operations.

Assignment timeline

All entries below are from the USPTO assignment record as mirrored in the Google Patents legal-events feed. Correspondents are not independently verified (see caveat above) — this is the one data field this analysis could not confirm.

• 2001-11-14 (executed) / recorded 2001-11-15 — Reel 012310/0632

  • Conveyance: Assignment of Assignors' Interest (inventor → employer)
  • Assignor: Franck Le; Haihong Zheng
  • Assignee: Nokia Corporation
  • Correspondent: not independently verified
  • Context: Routine assignment of the invention from the two Nokia researchers to Nokia's Finnish parent at filing.

• 2007-03-22 (executed) / recorded 2007-08-07 — Reel 019660/0120

  • Conveyance: Assignment
  • Assignor: Nokia Corporation
  • Assignee: Spyder Navigations L.L.C. (Delaware)
  • Correspondent: not independently verified
  • Context: Nokia's strategic divestiture of a patent portfolio to an Intellectual Ventures-affiliated holding LLC — the point where an operating company's patent became NPE inventory. (This is the largest tell in the chain: six years after issuance, Nokia moved the patent into the IV ecosystem rather than keeping it in products.)

• 2011-07-18 (effective) / recorded 2011-07-22 — Reel 026637/0611

  • Conveyance: Merger
  • Assignor: Spyder Navigations L.L.C.
  • Assignee: Intellectual Ventures I LLC (Delaware)
  • Correspondent: not independently verified
  • Context: Internal IV reorganization — Spyder Navigations, one of IV's many holding LLCs, merged into Intellectual Ventures I LLC, consolidating the portfolio under IV's primary licensing entity.

• 2022-07-21 (recorded) — Reel 060585/0188

  • Conveyance: Assignment
  • Assignor: Intellectual Ventures I LLC
  • Assignee: Intellectual Ventures Assets 189 LLC (Delaware)
  • Correspondent: not independently verified
  • Context: IV's portfolio-divestiture machinery — IV moved the patent into a numbered "Assets" LLC, the standard staging step before IV sells older patents to third-party monetization vehicles.

• 2022-07-28 (effective) / recorded 2022-08-02 — Reel 060698/0395

  • Conveyance: Assignment
  • Assignor: Intellectual Ventures Assets 189 LLC
  • Assignee: IOT Innovations LLC (Texas)
  • Correspondent: not independently verified
  • Context: Transfer-to-asserter — the patent left the IV ecosystem entirely and landed in the Texas LLC that has since filed 30+ infringement cases. This is the final link in the chain and the current assignee per the USPTO record and Google Patents.

No other recorded assignments (no security agreements, releases, corrections, or licenses) appear in the legal-events feed for this patent. If the Assignment Center shows additional non-Google-mirrored records, they were not visible to this analysis.

Timeline diagram

timeline
    title Ownership of US 7246173
    2001 : Filed by Nokia Inc
         : Inventors assign to Nokia Corp
    2007 : Patent issued
         : Nokia assigns to Spyder Navigations LLC
    2011 : Spyder merges into Intellectual Ventures I
    2022 : IV I assigns to IV Assets 189
         : IV Assets 189 assigns to IOT Innovations
         : First IOT Innovations suit filed

NPE / troll-pattern signals

1. Shell-entity transfer — present. Nokia Corporation (operating company) → Spyder Navigations L.L.C. (reel 019660/0120, a Delaware IV holding LLC) → Intellectual Ventures I LLC → Intellectual Ventures Assets 189 LLC (reel 060585/0188, numbered single-purpose LLC) → IOT Innovations LLC (reel 060698/0395, Texas LLC with no products). The chain consists of licensing-only LLCs from the 2007 Nokia transfer onward. This is evidenced by the recorded conveyances themselves, not just naming.

2. Known asserter in the chain — present. Two links qualify: Intellectual Ventures I LLC (reel 026637/0611) is a canonical NPE on RPX/Unified Patents asserter lists, and IOT Innovations LLC (reel 060698/0395) is a high-frequency plaintiff — per the verified dockets in the prior litigation summary, it has filed 30+ cases since 2022 across E.D. Tex., S.D. Fla., D. Mass., and D. Del. (TP-Link 2:24-cv-00219, ecobee 2:24-cv-00729, Snap One 2:24-cv-00704, Lutron 0:25-cv-60483, D-Link 2:25-cv-01009, etc.).

3. Repeat correspondent across the chain — unclear. I could not access the Assignment Center correspondent field in this session; no correspondent names for reels 012310/0632, 019660/0120, 026637/0611, 060585/0188, or 060698/0395 were verifiable from the sources available. This is a data gap, not a negative finding — do not treat the chain as clean until a direct USPTO lookup confirms whether one attorney/firm recurs across the 2022 links. (Recommendation: run each reel/frame at assignmentcenter.uspto.gov — that is the single highest-value verification step left.)

4. Cascading transfers — present. Reel 060585/0188 (recorded 2022-07-21) and reel 060698/0395 (recorded 2022-08-02) are two consecutive assignments 12 days apart through chained IV Assets entities ending at the litigating LLC — the classic IV divestiture cascade pattern (IV I → numbered Assets LLC → assertion vehicle). The 2007→2011 Spyder→IV I merger (reel 026637/0611) is the same family's internal-reorg cascade.

5. Pre-litigation transfer — present, with a nuance. The IOT Innovations acquisition (effective 2022-07-28, recorded 2022-08-02, reel 060698/0395) preceded the first IOT Innovations portfolio-wide complaints (Monitronics, 2:22-cv-00432, filed 2022-11-04) by roughly 3 months — well inside the 6-month window for the portfolio campaign. Strictly for the '173 patent itself, the first complaints asserting it came later (TP-Link, 2:24-cv-00219, filed 2024-03-28; Snap One amended complaint 2024-11-26; Lutron 0:25-cv-60483 filed 2025-03-12), so the transfer was arranged to enable assertion of the portfolio, with '173 rolled out in later waves.

6. Bankruptcy fire-sale — not present. Nokia never entered Chapter 7/11; the 2007 Spyder Navigations transfer (reel 019660/0120) was a strategic sale/licensing deal to IV, not a bankruptcy liquidation (contrast Kodak/Nortel).

7. Privateering — not present. No SEC filing, EFF/Patent Progress coverage, or other evidence surfaced showing Nokia directing IOT Innovations to sue its competitors on Nokia's behalf. The 2007 Nokia→IV transfer and the 2022 IV→IOT sale read as straight monetization, not privateering. (The caveat: the 2007 Nokia–IV deal was a close commercial relationship, but "close relationship" is not privateering evidence.)

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at IOT Innovations LLC, an asserting NPE. No RPX, AST, LOT Network, Unified Patents, or OIN link exists at the end of the chain.

Verdict

NPE — high confidence.

Four signals support this: (1) the patent moved from operating company Nokia to the Intellectual Ventures shell complex (reels 019660/0120, 026637/0611); (2) the chain ends at IOT Innovations LLC, a verified high-frequency plaintiff (30+ cases since 2022, per the dockets in the litigation summary), via the IV divestiture cascade (reels 060585/0188 and 060698/0395, recorded 12 days apart); and (3) the final transfer (effective 2022-07-28) was followed by first infringement filings within ~3 months for the portfolio, evidencing acquisition-for-assertion. The current assignee is a Texas licensing LLC with no products, and the patent expired ~2024-07-27, so enforcement is damages-only — classic NPE posture. The one unresolved item is correspondent verification (signal 3), which does not change the verdict given the strength of the other four.

Verification link: https://assignment.uspto.gov/patent/index.html#/patent/search (search "7246173") and https://assignmentcenter.uspto.gov/ — reels to check: 012310/0632, 019660/0120, 026637/0611, 060585/0188, 060698/0395.

The Justia record confirms the cited-reference list. Now let me search for the remaining cited references to verify their details.

Two more verified. Let me search the remaining references.

I have reached the search-step limit, but I have sufficient verified data to compile the prior-art analysis. Below is the full § 102 assessment, flagging precisely which references were verified by live search this session versus which rely on training data (per the operating rules).

Prior Art Analysis — US Patent 7,246,173 ("Method and apparatus for classifying IP data")

1. Verification of the cited-reference record

Searching for patent 7246173 (no auto-correction; no similar numbers returned) surfaced the Justia mirror of the USPTO record, which confirms the examiner-cited reference list on the face of the patent. The record (Justia, patent 7246173) lists eight U.S. patents, one PCT publication, and three non-patent references:

Non-patent literature (also on the face of the patent):

• Fankhauser et al., "RSVP Support for Mobile IP Version 6 in Wireless Environments," Internet Draft, Nov. 1998, pp. 1–22.
• RFC 2460, Deering & Hinden, Internet Protocol, Version 6 (IPv6) Specification, IETF, Dec. 1998, pp. 1–39.
• RFC 1812, Baker, Requirements for IP Version 4 Routers, IETF, Jun. 1995, pp. 1–175.

Verification confidence: US 6,157,955; 6,212,185; 6,262,983; and 6,272,540 were independently verified this session via full-text search results (patent PDFs / Google Patents / EveryPatent). US 6,401,117; 6,421,730; 6,452,915; 6,674,760; and WO 99/59303 are confirmed as cited on the face of the '173 patent (Justia record) but their full text was not re-fetched this session — descriptions below for those five rely on training data and are marked accordingly.

2. The claims to test against (element structure)

The six independent claims break into two method claims and four router claims:

• Claim 1 (method, generic): (a) receiving data at a first node, the data comprising a header comprising a list of at least one intermediate node to be visited on a way to the destination apparatus; and (b) classifying said data at said first node based on an entry in said header.
• Claim 5 (method, IPv4): same as claim 1, except the entry is provided within LSRR or SSRR of IPv4 data.
• Claim 13 / 25 (router, generic): means-for / structural receiving device + classification based on an entry in the header listing intermediate nodes.
• Claim 17 / 30 (router, IPv4): LSRR/SSRR variant.
• Key dependent refinements: classification based on the last destination address field (claims 4, 16, 28–29); resource reservation/RSVP (claims 9–10, 21–22, 34–35); storing source-routing information (claims 11, 23, 36); forwarding to a second node for re-classification (claims 12, 24, 37).

The dispositive limitation for § 102 is element (b): classifying based on an entry in a header that lists at least one intermediate node — i.e., the source-routing header (IPv6 routing header / IPv4 LSRR/SSRR), not the IP destination address field.

Because the '173 patent was filed 2001-04-16 (pre-AIA), pre-AIA § 102(a), (b), and (e) govern. All nine references and the three NPL items predate the filing date, so the temporal bases are available (with the caveat noted per reference where § 102(b)'s one-year bar date of 2000-04-16 is not met).

3. Per-reference § 102 analysis

US 6,157,955 B1 — Narad et al., "Packet processing system including a policy engine having a classification unit" (Intel; filed 1998-06-15; issued 2000-12-05) — verified

Description: A general-purpose programmable packet-processing platform (the NetBoost architecture) separating classification from action. A Policy Engine receives packets via media access controllers and a Classification Engine (a microprogrammed processor) parses protocol headers, performs hash lookups, and classifies packets according to application-specific policies (QoS/CoS, security, management); actions (pass/drop/encapsulate) execute on a Policy Processor. Claim 1 of '955: "a policy engine coupled to said bus bridge to classify packets according to at least one of a plurality of application-specific classification policies."

§ 102 mapping: Discloses receiving IP data at a node and classifying it — but the classification is based on arbitrary extracted header fields against policies, not on an entry in a header that lists intermediate nodes to be visited (no source-routing-header entry is used as the classification key). It therefore does not anticipate claim 1, 5, 13, 17, 25, or 30. At most it anticipates the generic "receiving and classifying" preamble/backdrop of claims 1/13/25 — not a legally sufficient anticipation of any complete claim. Verdict: no claim anticipated.

US 6,212,185 B1 — Steeves et al., "Multiple network address resolution" (Nortel; filed 1998-10-14; issued 2001-04-03) — verified

Description: Address resolution between a primary (broadcast) network and secondary NBMA networks (ATM). A routing node embeds "additional address information" (secondary-path addresses) into the IPv4 header option field (Option Type / Option Length / Option Data) and IPv6 header, so downstream nodes can discover secondary path connections without NHRP/NARP servers. The patent explicitly discusses IPv4 header options, source-route nodes, and updating header checksums when the option data is modified.

§ 102 mapping: This is the only cited reference that deals with placing routing-related address lists in the IP header options (adjacent to LSRR/SSRR territory), and it involves nodes processing a packet header at intermediate hops. However, its purpose is address discovery for path setup — it does not disclose classifying the packet (e.g., for RSVP session/QoS matching) based on an entry in that header. No disclosure of session classification, resource reservation, or using the final address in the option list as the classification key. Verdict: no claim anticipated.

US 6,262,983 B1 — Yoshizawa et al., "Programmable network" (Hitachi; filed 1998-09-08; issued 2001-07-17) — verified

Description: A programmable network node comprising a program processor (executes per-flow packet-processing programs), a routing processor, and a packet classification unit that analyzes each input packet and routes packets belonging to a flow to the program processor while other packets go to the routing processor. Flow classification uses a flow classification table keyed on header fields (addresses/ports); processing-history information is propagated to other nodes.

§ 102 mapping: Directly discloses element (a) — receiving data at a first node — and element (b) in its most generic form: classifying data at the node based on packet-header information. But the classification key is the standard 5-tuple flow (addresses/ports) in a flow table, not an entry in a source-routing header listing intermediate nodes. The "list of at least one intermediate node to be visited" limitation is absent. Verdict: no claim anticipated — though it is the strongest cited reference on the generic "node receives packet → classifies → forwards" method skeleton.

US 6,272,540 B1 — Yadav et al., "Arrangement and method for providing flexible management of a network" (Intel; filed 1998-12-31; issued 2001-08-07) — verified

Description: Network management via a Network Management Database (NMD) of <condition, action> queries distributed to remote components. A packet classification engine at the remote component determines fields of a received packet (IP header, TCP ports, data-description fields), matches them against condition components (e.g., "IF source IP address is User A AND description field is Urgent"), and executes the corresponding action (e.g., copy to users, set priority). The figures explicitly show a "PACKET CLASSIFICATION ENGINE DETERMINES FIELDS OF PACKET → MATCHING THE FIELDS OF PACKET TO A CONDITION → EXECUTE ACTION → FORWARDING PACKET TO ITS DESTINATION."

§ 102 mapping: Like '955, discloses receiving and classifying a data packet at a node based on header fields, with actions including priority/QoS marking. But the fields used are the standard IP/TCP header fields and data fields — no routing header listing intermediate nodes, and no classification based on an entry in such a header. Verdict: no claim anticipated.

US 6,401,117 B1 — Narad et al., "Platform permitting execution of multiple network infrastructure applications" (Intel; filed 1998-06-15; issued 2002-06-04) — training-data only, not re-verified

Description: Same NetBoost family as '955 — a hardware/software platform permitting multiple network infrastructure applications (classification/action separation, policy engine, classification engine, ring-based buffer management) to execute concurrently. Filed the same day as '955 by the same inventors; essentially a sibling disclosure of the same platform.

§ 102 mapping: Same as '955: generic packet classification platform, no source-routing-header-entry classification. Verdict: no claim anticipated (subject to full-text confirmation, which is expected to mirror '955).

US 6,421,730 B1 — Narad et al., "Programmable system for processing a partitioned network infrastructure" (Intel; filed 1998-06-15; issued 2002-07-16) — training-data only, not re-verified

Description: Third member of the Intel NetBoost family — programmable processing of a partitioned network infrastructure, with classification engines and policy processing partitioned across modules.

§ 102 mapping: Same analysis as '955/'401,111: classification is policy-driven on extracted header fields, not on source-routing-header entries. Verdict: no claim anticipated (subject to confirmation).

US 6,452,915 B1 — Jorgensen, "IP-flow classification in a wireless point to multi-point (PTMP) transmission system" (Malibu Networks; filed 1998-07-10; issued 2002-09-17) — training-data only, not re-verified

Description: Classifies IP flows at a wireless base station in a PTMP system — identifies flows by header information and applies QoS treatment (bandwidth allocation, scheduling) per flow. Cited by the examiner with an asterisk (considered but not applied).

§ 102 mapping: Discloses flow classification tied to QoS treatment — relevant to the purpose of the '173 claims (QoS for flows) — but classification is on conventional flow identifiers, not on an entry in a source-routing header. Verdict: no claim anticipated.

US 6,674,760 B1 — Walrand et al., "Method and system for implementing end-to-end QoS in packet-switched networks" (Extreme Networks; filed 1999-09-28; issued 2004-01-06) — training-data only, not re-verified

Description: End-to-end QoS in packet-switched networks — bandwidth reservation/allocation along a path, with network nodes classifying and policing traffic to enforce QoS.

§ 102 mapping: Closest cited reference to the RSVP/resource-reservation context of the '173 specification (claims 9–10, 21–22, 34–35 add reservation steps). But the '173 invention's point of novelty is that classification is keyed to the final destination entry in the routing header (so mid-route packets match the reserved session). Nothing in the training-data description of '760 discloses classifying based on a routing-header entry rather than the IP destination field. Verdict: no claim anticipated on the available information; worth a full-text check because it is the most contextually similar to the RSVP-over-source-routing problem.

WO 99/59303 A2 — Telia AB, "A communications network or an IP-network which incorporates a packet classifier" (priority 1998-05-14; published 1999-11-18) — training-data only, not re-verified

Description: A communications/IP network incorporating a packet classifier — a classifier element that inspects packets (headers) and classifies them, likely for service/QoS differentiation.

§ 102 mapping: A generic packet-classifier disclosure. As with '955/'540, it may disclose the receiving-and-classifying skeleton but not classification based on a header entry listing intermediate nodes. Verdict: no claim anticipated on available information.

4. Non-patent references — the most technically on-point prior art

RFC 2460 — Deering & Hinden, "Internet Protocol, Version 6 (IPv6) Specification" (IETF, Dec. 1998; § 102(a)/(b) available)

Description: The IPv6 base specification. Defines the IPv6 Routing header (Section 4.4), including the Type 0 routing header format: Next Header, Hdr Ext Len, Routing Type, Segments Left, and the address list (Address[1]…Address[n]) — where the last entry is the final destination. Defines the semantics that the IP destination address field carries the next intermediate node's address while Segments Left > 0 — exactly the phenomenon the '173 patent identifies as Condition B.

§ 102 mapping: RFC 2460 alone discloses the structural header element (a) of claims 1/13/25 and the IPv6 dependent claims 2–4, 14–16, 26–29 (header comprising a list of intermediate nodes; segments-left field; last destination address field). It does not disclose classifying data at a node based on an entry in that header — RFCs describe protocol format and router forwarding behavior, not RSVP session classification. Verdict: anticipates the header-structure limitations only; does not anticipate any complete claim. It is, however, the single most important reference for the IPv6 claim limitations and pairs naturally with the Fankhauser draft for a § 103 combination.

RFC 1812 — Baker, "Requirements for IP Version 4 Routers" (IETF, Jun. 1995; § 102(a)/(b) available)

Description: IPv4 router requirements. Specifies router handling of IP options, including Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) — the option format (type, length, pointer, route data), the rule that the destination address field holds the next hop in the source route while the pointer ≤ length, and the final destination residing at the end of the route data. This is the IPv4 counterpart to RFC 2460 and directly documents the Condition A phenomenon.

§ 102 mapping: Discloses the LSRR/SSRR structure recited in claims 5–7, 17–19, 30–32 (entry provided within LSRR/SSRR; last destination address field). Does not disclose classifying data based on the last address in the route data for QoS/session purposes. Verdict: anticipates the IPv4 header-structure limitations only; does not anticipate any complete claim.

Fankhauser et al., "RSVP Support for Mobile IP Version 6 in Wireless Environments" (Internet Draft, Nov. 1998; § 102(a)/(b) available)

Description: The closest prior art to the problem the '173 patent solves. Discusses Resource Reservation Protocol (RSVP) operation over IPv6 in mobile/wireless environments, including the interaction of RSVP session objects (DestAddress, ProtocolId, DestPort) with IPv6 routing headers. This is the reference most likely to contain any pre-2001 teaching of how RSVP session classification should treat the routing header's address list.

§ 102 mapping: If — and only if — the draft teaches classifying an RSVP flow based on the final destination in the IPv6 routing header (rather than the IP destination field), it would be a genuine § 102(a)/(b) anticipation candidate for claim 1 (and method claims generally) and for claims 9–10 (reservation steps). I could not verify the draft's full text this session; the examiner cited it, which suggests it was considered but not applied as an anticipation reference. Verdict: strongest potential § 102 candidate for claim 1 — requires full-text confirmation before asserting anticipation.

5. Bottom-line § 102 assessment

Honest conclusion: None of the nine cited references — on the verified record — is a clean single-reference § 102 anticipation of any independent claim, because none discloses the core limitation of classifying IP data at a node based on an entry in a header that lists at least one intermediate node (the source-routing-header-entry classification). The cited art collectively provides:

1. The exact header structures (RFC 2460 for IPv6 routing headers; RFC 1812 for IPv4 LSRR/SSRR) that the claims recite;
2. Generic packet classification at nodes (Intel '955/'117/'730/'540, Hitachi '983, Telia WO'303, Malibu '915); and
3. The QoS/RSVP context (Extreme '760, Fankhauser draft).

That combination maps cleanly onto a § 103 obviousness theory (RFC 2460 + Fankhauser for the IPv6 claims; RFC 1812 + '760/'955 for the IPv4 claims), and any § 102 argument would have to be built on the Fankhauser draft or a full-text reading of WO 99/59303 or '667,4760 — none of which I can responsibly assert as anticipating without pulling the full text, which I flag as the required next verification step (IETF draft archives for Fankhauser; Espacenet/patent PDFs for WO 99/59303 and US 6,674,760).

Obviousness Analysis Under 35 U.S.C. § 103 — US 7,246,173 ("Method and apparatus for classifying IP data")

Scope note: This section analyzes the patent's claims for obviousness using the prior art identified in the patent's own record (the "Citations," "Patent Citations," "Non-Patent Citations," and "Family Cites" sections of the Google Patents record supplied with the task). It builds on the prior sections (summary, litigation, PTAB, assignment history) and does not repeat them. The patent expired ~2024-07-27, which is irrelevant to the technical obviousness question but relevant to remedy (damages only) if this analysis is used in litigation. No IPR has ever been filed (see PTAB section), so this § 103 case would be made in district court or ex parte reexamination.

1. Executive summary

US 7,246,173 solves a narrow, well-documented interoperability problem: in RSVP QoS environments, a packet that is still traversing a source route (IPv6 routing header with Segments Left ≠ 0, or IPv4 LSRR/SSRR with pointer ≤ length) carries an intermediate node's address in the IP header's Destination Address field. Because RSVP sessions are keyed to the final destination address, the router misclassifies the packet and the reserved QoS is not applied. The claimed fix: classify the packet based on an entry in the source-routing header — specifically the last (final-destination) address in the routing list — instead of the IP header's Destination Address field.

Every element of that fix was known before the April 16, 2001 filing date:

• RFC 2460 (Dec. 1998) — the IPv6 specification itself — discloses the Type 0 routing header, the Segments Left field, the swap algorithm that places intermediate addresses in the IP Destination Address field, and expressly teaches that when a routing header is present, "the Destination Address … is that of the final destination," which "at the originating node … will be in the last element of the Routing header" (§ 8.1). In other words, the primary reference already teaches that the final destination is found in the last entry of the routing header.
• RFC 1812 (Jun. 1995) — IPv4 router requirements — discloses the LSRR/SSRR option structure and the same destination-swap semantics, with the real destination as the last address in the route data field.
• Fankhauser et al., "RSVP Support for Mobile IP Version 6 in Wireless Environments" (Nov. 1998) — cited by the examiner — discloses that RSVP sessions are identified by the triple (destination address, protocol id, destination port), and explicitly identifies the "issue of matching RSVP flow state with the data packets belonging to that flow at intermediate routers" when the outer IP header destination differs from the flow's true destination, including solutions implemented at intermediate routers.
• US 6,674,760 (Extreme Networks; effective prior-art date 1999-09-27) and WO 99/59303 (Telia; published 1999) disclose router-resident packet classifiers that inspect header fields to identify end-to-end connections and allocate QoS.
• US 6,452,915 (Malibu; effective filing date 1998-07-10) discloses an IP-flow classifier that parses both IPv4 and IPv6 header fields, is RSVP-aware (PATH/RESV, SESSION objects), and classifies QoS based on source/destination addresses and ports.

Conclusion: All 37 claims, including all six independent claims (1, 5, 13, 17, 25, 30), are vulnerable under § 103. The strongest case is on the dependent claims that require classification based on the last destination address field of the routing header (claims 4, 16, 28) or of LSRR/SSRR (claims 7, 19, 32) — because RFC 2460 § 8.1 and the RFC 1812 source-route semantics disclose precisely that location. The broadest claims (1, 13, 25) are also obvious because "classifying based on an entry in said header" is disclosed by the combination of a known routing-header structure and known header-based classifiers. The fix is a classic KSR "combination of familiar elements according to known methods" yielding predictable results — extracting the final-destination address from the source-route list, a concept already present in the standards.

2. Legal framework and person of ordinary skill

Framework. Obviousness under § 103 is assessed under Graham v. John Deere (1966): (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) secondary considerations. Under KSR Int'l Co. v. Teleflex (2007), a combination is obvious when a PHOSITA would have had a reason to combine known elements in a way that yields predictable results; rigid "teaching, suggestion, motivation" (TSM) formalism is rejected. The combination need not be found in a single reference. Because the patent issued July 17, 2007 (after KSR, decided April 30, 2007), the KSR framework governs any district-court analysis of these claims.

PHOSITA. A person of ordinary skill in the art (as of April 2001) would have: a B.S. in computer science, electrical engineering, or equivalent; 2–4 years of experience implementing IP routers or protocol stacks; working knowledge of IPv4 (RFC 791, RFC 1812) and IPv6 (RFC 2460) header formats and options; and familiarity with QoS architectures, particularly RSVP/IntServ (RFC 2205) and packet classification. The references below are all squarely within this field — packet classification, routing, and QoS — so the analogous-art requirement is comfortably met.

3. Claim inventory (for cross-reference)

4. Prior-art inventory (from the patent's record; verified where indicated)

All references below predate the April 16, 2001 filing (US 6,674,760 and US 6,452,915 via § 102(e) effective dates), so each is available as prior art.

Background knowledge incorporated by the patent itself: RSVP (RFC 2205, Sept. 1997) — the patent's own Detailed Description defines the session object as (DestAddress, ProtocolId[, Destport]), the filter spec, and the TCSB classification procedure. RFC 2205 is referenced by the Fankhauser draft and is the background a PHOSITA would bring to any RSVP implementation; it is properly used as common knowledge in the combination (not as the sole basis).

5. Element-by-element obviousness analysis

5.1 Combination A (primary, IPv6): RFC 2460 + RSVP (RFC 2205/Fankhauser) → claims 1–4, 8–12 (and mirrored dependents 14–16, 20–24, 26–29, 33–37)

Why a PHOSITA would combine: RFC 2460 (the protocol standard a router vendor must implement) and RFC 2205/RSVP (the QoS protocol the same vendor must implement for IntServ) are used together in every RSVP-over-IPv6 deployment. The Fankhauser draft — an IETF working-group document squarely in the field — already flags that RSVP flow classification at intermediate routers breaks when the outer-header destination diverges from the session destination, and already proposes intermediate-router-side fixes. RFC 2460 § 8.1 supplies the missing fact: the final destination is always recoverable from the last routing-header element. The claimed invention is nothing more than pointing the RSVP classifier at that known location. This is the archetypal KSR combination: known elements (routing header structure; RSVP session classification) combined according to their known functions to fix a known problem, with a predictable result.

5.2 Combination B (primary, IPv4): RFC 1812 + RSVP (RFC 2205) + a classifier (US 6,674,760 / WO 99/59303) → claims 5–7 (and 17–19, 30–32)

Why combine: RFC 1812 mandates IPv4 router handling of source-route options; RFC 2205/RSVP mandates session classification by final destination. US 6,674,760 and WO 99/59303 disclose the classifier that performs the classification at the node. The mismatch the patent identifies (IP Destination Address = next router, not final destination, while pointer ≤ length) is directly derivable from RFC 1812's own processing rules, and the fix — using the last address in the route data — is the natural application of RSVP's session semantics to the structure RFC 1812 defines. Same predictable-result logic as Combination A.

5.3 Combination C (classifier-centric): US 6,452,915 (Malibu) + RFC 2460/RFC 1812 → claims 1, 5, 13, 25 (independent claims, IPv4 and IPv6)

US 6,452,915 discloses an IP-flow classifier that (a) resides in a network node; (b) parses both IPv4 and IPv6 packet fields; (c) classifies flows and QoS based on source/destination addresses and ports; and (d) is RSVP-aware (PATH/RESV, SESSION objects). The only missing piece is the specific field to use for classification when a routing header/source-route option is present — and that piece is supplied by RFC 2460 § 8.1 (last routing-header element = final destination) and RFC 1812 (last route-data address = final destination). Modifying Malibu's classifier to read the last routing-header address (rather than the IP Destination Address) when Segments Left ≠ 0 is a routine, predictable programming change for a PHOSITA — the kind of "simple substitution of one known element for another" that KSR expressly holds obvious.

5.4 Router claims 13, 17, 25, 30 — hardware elements

• Claim 25 (structural): "receiving device" — disclosed by WO 99/59303 (classifier "in an end system or a router"), US 6,674,760 (node with input ports/interfaces), and US 6,452,915 (base station/CPE with receiver); "processor device … for classifying" — disclosed by the same references' classifier/policy engine (US 6,157,955's classification unit; US 6,674,760's classifier in communication with switch/queuing logic). Applying the last-address classification logic (Combinations A/B) to that known hardware is obvious.
• Claims 13/17 (means-plus-function): the "means for receiving" and "means for classifying" correspond to the same input-interface/classifier structures; the specification's own disclosed structure (receiving device + processor device, claims 25/30) is conventional router hardware. There is no novel hardware; the claims add only the obvious classification rule.

5.5 Dependent claims — risk ranking

6. Motivation-to-combine (KSR analysis)

1. Same field / analogous art. All references concern IP packet handling, routing, classification, and QoS — the identical field. RFC 2460, RFC 1812, RFC 2205, and the Fankhauser draft are standards/drafts that router vendors implement together; US 6,674,760, WO 99/59303, and US 6,452,915 are the commercial embodiments of that same field.

2. Known problem, expressly identified in the art. The Fankhauser draft (Nov. 1998) explicitly describes the "flow-mismatch" failure — RSVP state at intermediate routers not matching data packets because the outer-header destination differs from the session's real destination — and proposes intermediate-router-side remedies. The patent's problem (source routing, rather than mobility, causing the same header-vs-session divergence) is a direct analogue; a PHOSITA would treat Fankhauser's flow-mismatch discussion as teaching the general problem class.

3. Known solution ingredient already in the primary reference. RFC 2460 § 8.1 does not merely describe the routing header; it affirmatively instructs that the "final destination" of a packet carrying a routing header "will be in the last element of the Routing header." Any engineer implementing a per-packet function that needs the final destination (checksums, and by extension flow classification) has the RFC pointing at the last routing-header entry. The step from "use last routing-header element for checksum pseudo-header" to "use last routing-header element for RSVP classification" is a trivial, predictable application of an existing teaching.

4. Predictable result, no new functionality. The claimed method produces exactly what the prior-art combination promises: correct matching of a source-routed packet to its RSVP session. There is no unexpected technical effect, no new protocol, no new hardware.

5. Design incentive. RSVP's entire purpose is delivering QoS; a router vendor (Nokia, Cisco, Extreme, Intel — the assignees of the cited art) implementing RSVP over IPv6/IPv4 with source routing would be motivated to make classification work, and the fix costs nothing (read the last address instead of the Destination Address field). This satisfies the "reasonable expectation of success" and "design need" prongs of KSR.

6. No teaching away. Nothing in RFC 2460, RFC 1812, or the classifier patents suggests the routing header's last address should not be used for classification; to the contrary, RFC 2460 § 8.1 endorses treating the last element as the operative final destination. The Fankhauser draft proposes end-node and intermediate-node RSVP modifications but does not disparage intermediate-router-side classification fixes — indeed its § 3.1.2 "Solving the Routing Problem at Intermediate Nodes" endorses exactly that locus of solution.

7. Secondary considerations: none in the record. There is no evidence of long-felt need, unexpected results, commercial success, or copying attributable to the claimed feature. The three most probative references (RFC 1812, RFC 2460, Fankhauser) were cited by the examiner during prosecution, confirming they were known and contemporaneous — which cuts against any argument that the solution was non-obvious at the time.

7. Anticipated patent-owner rebuttals and responses

8. Strengths and weaknesses of the obviousness case

Strongest positions (for a defendant/validity challenger):

• Claims 4/16/28 and 7/19/32 (last destination address field): RFC 2460 § 8.1 and RFC 1812 source-route semantics disclose the last-entry-is-final-destination teaching almost literally. A § 103 case here is very strong; a § 102 anticipation case on claim 4 may also be arguable if Telia/Malibu's classifier is read as classifying on routing-header content (though § 103 is the safer theory).
• Independent claims 1/5/13/17/25/30: the broad "entry in said header" language is easily met by the combination; the hardware is conventional.

Weakest positions (need more evidence):

• The full text of RFC 1812's source-route section was not re-verified this session (search limit hit) — the patent's own Background corroborates the LSRR/SSRR semantics, but a rigorous brief should quote RFC 1812 § 4.2.2.x directly.
• US 6,674,760's 2004 grant date could confuse a court until the § 102(e) effective date (1999-09-27 priority) is established; the challenger should file the priority-chain evidence early.
• Claim 1's "classifying … based on an entry in said header" is so broad that it may invite a § 101/§ 112 analysis as an alternative attack (see PTAB section recommendation), but under § 103 it is comfortably covered.

9. Recommended lead combinations (for a petition or expert report)

1. RFC 2460 + Fankhauser (with RFC 2205 as background) → claims 1–4, 8–12, 13–16, 20–24, 25–29, 33–37 (IPv6 side).
2. RFC 1812 + RFC 2205/RSVP (with WO 99/59303 or US 6,674,760 as the classifier) → claims 5–7, 17–19, 30–32 (IPv4 side).
3. US 6,452,915 + RFC 2460/RFC 1812 → independent claims 1, 5, 13, 17, 25, 30 (classifier-centric; US 6,452,915 already parses IPv4/IPv6 and RSVP objects, so the delta is only the last-address extraction).
4. US 6,674,760 + RFC 2460/RFC 1812 → QoS-reservation-dependent claims 9–10, 21–22, 34–35.

10. Caveats and verification gaps

• RFC 1812 section-level citation: I verified RFC 1812's existence, date, and citation in the file wrapper, and the patent's own text describes LSRR/SSRR semantics consistent with RFC 1812; I could not retrieve the RFC 1812 source-route section text before the search limit. Quote the specific section (approximately § 4.2.2.3, "Source Route Options") from the authoritative IETF text before relying on it.
• § 102(e) dates: US 6,674,760 (priority 1999-09-27) and US 6,452,915 (provisional 1998-07-10) were granted after the '173 filing date but are effective prior art by virtue of earlier filing dates; this must be explained to a court.
• Anticipation not analyzed in depth: I focused on § 103 per the task. Claim 4 (last destination address field, IPv6) may also be anticipatable by RFC 2460 § 8.1 read with a known classifier, but a single-reference § 102 case is weaker because RFC 2460's § 8.1 usage is checksum-specific; the § 103 combination is the stronger path.
• No PTAB record exists (see prior section) — this analysis has never been tested in an IPR, so there is no estoppel and no FWD to align with; district-court or ex parte reexamination is the venue.

Bottom line: The claimed invention is a narrow, standards-driven fix whose components — the routing header's last-address-as-final-destination (RFC 2460 § 8.1), the RSVP session-classification keyed to the final destination (RFC 2205/Fankhauser), and router-resident header-based classification (US 6,674,760, WO 99/59303, US 6,452,915) — were all known before April 2001. A PHOSITA had every reason to combine them and every expectation of success. All 37 claims are vulnerable under § 103, with the last-destination-address dependent claims the most clearly obvious.