US 9118602

I'll search for this specific patent number and any associated CAFC dockets.

Let me dig into the CAFC appeal dockets and PTAB proceedings tied to this patent.

Let me verify the companion IPR and check for any 2026 appellate activity.

US 9,118,602 B2 — Summary

Caveat on sourcing: I could not directly query USPTO PatentCenter/PAIR or PACER in this session. The bibliographic data below comes from the Google Patents full text for US9118602B2 provided in the record (https://patents.google.com/patent/US9118602/en) and from third‑party docket aggregators (Justia dockets, cafc.uscourts.gov, ex‑parte/AI‑lab CAFC trackers, GreyB/IPVerse, PatSnap). Where those sources are incomplete or conflict, I flag it.

Bibliographic data

Prosecution chain: This patent is a continuation of Ser. No. 13/116,696 (now US 8,537,682), filed 2011‑05‑26, which is a continuation of Ser. No. 11/123,801 (now US 7,974,202), filed 2005‑05‑06.

Abstract (verbatim)

"A method for processing data packets in a communication network includes establishing a path for a flow of the data packets through the communication network. At a node along the path having a plurality of aggregated ports, a port is selected from among the plurality to serve as part of the path. A label is chosen responsively to the selected port. The label is attached to the data packets in the flow at a point on the path upstream from the node. Upon receiving the data packets at the node, the data packets are switched through the selected port responsively to the label."

Plain‑language overview of the independent claims

The patent has three independent claims — claims 1, 15 and 26 (claims 2–14 depend from 1; 16–25 depend from 15; claim 26 stands alone).

Claim 1 — Method (LAG port selection encoded into an MPLS label).
A first MPLS/LAG switch assigns one physical port of a Link Aggregation Group (LAG) to a network tunnel, where that port satisfies the tunnel's bandwidth requirement and has a "port serial number." The switch dedicates a sub‑set of bits in a data packet label to encode that port serial number into the label, then sends the label upstream to a preceding node. When the switch later receives a data packet carrying that label from the preceding node, it forwards the packet to a second MPLS/LAG switch via the very port whose serial number is encoded in the label. (Note: the claim literally recites "second MSPLS/LAG switch" — an apparent typographical artifact I am reproducing rather than correcting per your instruction.)

Claim 15 — Apparatus.
An apparatus (in the LAG downstream of a preceding node, in an MPLS network using RSVP‑TE provisioning) comprising:

• a processor configured to (a) assign a single physical LAG tunnel port that meets the tunnel's bandwidth requirement and has a port serial number, (b) dedicate a sub‑set of bits in a data packet label to encode that port serial number, and (c) publish the label upstream; and
• a mapper configured to receive a data packet from an upstream node, detect the label in the packet, and — if the label is present — send the packet to the second MPLS/LAG switch via that single physical tunnel port.

Claim 26 — Method (explicit request/label‑request variant).
A method analogous to claim 1 but expressly reciting: the first MPLS/LAG switch receives a request message from the upstream preceding node requesting tunnel configuration and requesting a data packet label for the tunnel, the request specifying a bandwidth requirement; the switch assigns a single physical LAG port that meets the specified bandwidth requirement (port having a serial number); dedicates a sub‑set of label bits to encode the serial number; sends the label to the preceding node; receives a packet bearing that label; and forwards it to a second "MSPLS/LAG" switch via that port.

Dependent‑claim concepts worth noting (representative, not exhaustive): RSVP‑TE PATH message with a LABEL_REQUEST object (cl. 3); service properties — guaranteed/peak bandwidth, class of service (cl. 4–5); port‑selection strategies of "maximum available bandwidth" (cl. 6) or "minimum sufficient bandwidth" (cl. 7); mapping function / bit extraction vs. lookup‑table retrieval (cl. 8–10); backup‑port failover and revert (cl. 11–12); and LSR/network‑processor implementations (cl. 13, 23–24). Notably, the issued claim 1 does not literally recite a "selecting" step (the pre‑grant publication's version did); the issued language uses "assigning."

Litigation / PTAB / CAFC activity (searched)

PTAB (inter partes reviews) tied to this family:

• IPR2023‑00839 — Arista Networks, Inc. v. Corrigent Corporation, filed 2023‑04‑18, respondent patent 9,118,602 (application 13/969,520, Tech Center 2400); institution decision 2023‑12‑07; status Final Written Decision – Appealed (termination date listed as 2024‑12‑03). Source: GreyB/IPVerse case page.
• IPR2023‑00447 — listed on the Google Patents family page for US9118602 as a PTAB case with a Final Written Decision. Uncertainty: my retrieved sources did not confirm the specific patent challenged in IPR2023‑00447; it is associated with this family, but I could not independently verify it targets 9,118,602 specifically (sibling family members such as US 8,427,953 exist). Treat the IPR2023‑00447↔'602 linkage as family‑level, not confirmed patent‑specific.

CAFC dockets I located (all filed in 2025, not 2026):

District court matters noted on the family page: W.D. Tex. case 6:22‑cv‑00396 and D. Del. case 1:22‑cv‑00497.

On the "2026 CAFC dockets" request: I did not find any CAFC appeal docketed in 2026 that specifically names US 9,118,602. The three appeals above are 2025 dockets. It is possible a 2026 entry exists (e.g., further briefing or a decision in 25‑1424/25‑2036) that my sources did not surface, so I cannot state definitively that no 2026 activity exists. Also note a discrepancy to be careful about: a PatSnap blog post characterizes the 25‑1021 appeal as concerning US9118602B2, but the court's own order states the appeal is from PTAB No. IPR2023‑00447, and the only IPR I could affirmatively tie to '602 is IPR2023‑00839 (Arista). I therefore treat the '602↔25‑1021 linkage as unverified.

Bottom line: US 9,118,602 is a 2015‑issued Orckit/Corrigent continuation directed to selecting a single LAG member port per MPLS tunnel and encoding that port's serial number in the MPLS label so all traffic for the tunnel is steered to that port. It is now expired (adjusted expiration 2025‑08‑16). The family has drawn multiple IPRs and CAFC appeals (25‑1021 dismissed by agreement in Feb 2025; 25‑1424 and 25‑2036 pending as of the last dockets I could retrieve).

I'll search for litigation involving US patent 9118602 using multiple sources.

Let me dig deeper into the specific cases identified.

Litigation Involving U.S. Patent No. 9,118,602 (US9118602B2)

Patent identification (as verified against the authoritative patent text): U.S. Patent No. 9,118,602 B2, "Tunnel Provisioning with Link Aggregation," application No. 13/969,520, filed 2013‑08‑17, priority date 2005‑05‑06, granted 2015‑08‑25, inventor Ronen Solomon, original assignee Orckit Corrigent Ltd., current assignee Corrigent Corp. The patent ties to a family (ID 37393963) that also includes U.S. Patent Nos. 7,974,202; 8,537,682; 8,427,953; and later continuations. Status listed as Expired – Lifetime (adjusted expiration 2025‑08‑16).

Yes — there is known litigation, in three forums: district court, the PTAB, and the Federal Circuit.

1. District Court Litigation

a) Corrigent Corporation v. Cisco Systems, Inc.

Cisco's JMOL argument centered on the claim limitation requiring the first MPLS/LAG switch to "dedicat[e] a sub‑set of bits in a data packet label … to encode said port serial number of said single physical tunnel port." Cisco argued Corrigent's expert did not opine that Cisco's physical port serial numbers are encoded in any data label. Note that in this same case the court dismissed the '369 and '485 patents on the pleadings under 35 U.S.C. § 101; the '602 patent was the one that proceeded to trial.

b) Corrigent Corporation v. Arista Networks, Inc.

This is the Delaware case listed on the patent's own litigation record (link: portal.unifiedpatents.com/litigation/Delaware District Court/case/1:22-cv-00497).

c) Corrigent Corporation v. Dell Technologies Inc. and Dell Inc. (related)

• Jurisdiction: U.S. District Court for the District of Delaware
• Case No.: 1:22‑cv‑00496‑RGA (related to the Arista case)
• Filed: April 19, 2022
• This case was filed in the same April 2022 campaign as the Cisco and Arista suits, asserting the same Orckit‑Corrigent networking patent portfolio (including link‑aggregation subject matter). Caveat: I could not directly confirm from the retrieved docket that the '602 patent specifically was asserted against Dell — the patent's own litigation record lists only the Arista Delaware case (1:22‑cv‑00497). I flag this as not fully verified rather than asserting it.

2. PTAB (Inter Partes Review) Proceedings on the '602 Patent

a) Cisco Systems, Inc. v. Corrigent Corporation — IPR2023‑00447

b) Arista Networks, Inc. v. Corrigent Corporation — IPR2023‑00839

Both IPRs reached Final Written Decision. I did not retrieve the substantive holding of either FWD (i.e., whether claims were cancelled or upheld); I therefore cannot state the outcome on the merits with confidence.

3. Federal Circuit Appeals

The patent's litigation record lists three Court of Appeals for the Federal Circuit cases: 25‑1021, 25‑1424, and 25‑2036.

• Cisco Systems, Inc. v. Corrigent Corp., No. 2025‑1021 (Fed. Cir.): Reported as dismissed. Per a PACER‑based analysis, the parties agreed to a voluntary dismissal under Fed. R. App. P. 42(b), each side bearing its own costs; no merits adjudication and no precedential effect. Cisco was the appellant challenging the underlying patentability determination. Per that record, Corrigent retained the '602 patent without it being formally affirmed or struck down at the Federal Circuit.
• Nos. 2025‑1424 and 2025‑2036: Listed on the patent's litigation record, but I could not retrieve party names, origin, filing dates, or dispositions. I flag these as not confirmed.

Summary Table

Notes, Caveats, and Confidence

• High confidence: The existence and key parameters of Corrigent v. Cisco (6:22‑cv‑00396), Corrigent v. Arista (1:22‑cv‑00497), IPR2023‑00447, IPR2023‑00839, and the Federal Circuit 25‑1021 dismissal.
• Lower confidence / not verified: (i) whether the '602 patent was asserted against Dell in 1:22‑cv‑00496; (ii) the substantive merits outcome of either IPR Final Written Decision; (iii) the parties and dispositions of Fed. Cir. Nos. 25‑1424 and 25‑2036; (iv) the final judgment outcome in the W.D. Tex. case (the docket evidence shows a post‑trial JMOL motion, but I did not retrieve the verdict or the court's ruling on JMOL).
• I did not find any litigation involving the '602 patent outside the U.S., and none of the retrieved sources showed the patent asserted by a party other than Corrigent Corporation.

Primary sources consulted:

• Google Patents, US9118602B2 (patent text and litigation record): https://patents.google.com/patent/[US9118602](/patent/US9118602)/en
• IPverse/PTAB case pages: https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2023-00447 and https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2023-00839
• CourtListener, Corrigent Corp. v. Cisco Systems, Inc., W.D. Tex. 6:22‑cv‑00396 (Doc. 345, JMOL): https://storage.courtlistener.com/recap/gov.uscourts.txwd.[1169926](/patent/1169926)/gov.uscourts.txwd.1169926.345.0.pdf
• Unified Patents litigation portal (Delaware case 1:22‑cv‑00497; W.D. Tex. case 6:22‑cv‑00396): as cited on the patent page
• Patsnap Eureka litigation analysis (Fed. Cir. 25‑1021 dismissal): https://www.patsnap.com/.../cisco-v-corrigent-corp-federal-circuit-appeal-dismissed-patsnap/
• Ex Parte / UniCourt dockets for 1:22‑cv‑00497 and 1:22‑cv‑00496 (D. Del.)
• RPX Insight news summary of the April 2022 Corrigent filing campaign: https://insight.rpxcorp.com

If you need me to attempt to fill the gaps (IPR FWD holdings, the W.D. Tex. verdict/JMOL ruling, and the two unidentified Federal Circuit appeals), I can search further on those specific dockets.

I'll verify the PTAB record against the structured data and third-party dockets.

Now let me pin down the two Final Written Decisions and the appellate outcomes.

Let me confirm FWD panels, the claim-level outcomes, and the current status of the pending appeal.

Proceedings overview

Source conflict to flag up front: The structured "PTAB proceedings on file" block (USPTO Open Data Portal) returns zero AIA trial proceedings for US 9,118,602. That is wrong — the public PTAB record shows two instituted inter partes reviews, both of which ran to Final Written Decision. (Likely cause: the ODP ingest for this application number — 13/969,520 — is stale or failed; the trials are indexed in PTAB E2E, PTAB Decisions, and the CAFC dockets.) I am therefore reporting off the PTAB E2E/PTAB document record and the CAFC orders, and I flag this as a contradiction with the canonical block rather than silently overriding it.

Count: 2 proceedings — 0 claims invalidated, all 26 claims sustained, 0 settlements, 0 institution denials, 1 FWD affirmed-by-dismissal, 1 FWD on appeal.
Both IPRs (Cisco's IPR2023‑00447 and Arista's IPR2023‑00839) were instituted and lost on the merits by the petitioner; no claim of the '602 patent was canceled. The patent, however, expired 2025‑08‑16 and was separately held not infringed as a matter of law in W.D. Tex. (JMOL, 2025‑01‑16). Defensive posture: this is a hardened-but-expired patent — the invalidity record is petitioner-hostile, but a defendant's cheapest exit is non-infringement/expiry, not a third IPR.

IPR2023‑00447 — Cisco Systems, Inc. v. Corrigent Corporation

• Type: Inter Partes Review (35 U.S.C. §§ 311–319)
• Filed: 2023‑01‑10 (Corrigent's Fourth Notice of IPR in W.D. Tex. 6:22‑cv‑00396 states "On January 10, 2023, Cisco Systems, Inc. filed a petition"; GreyB/IPVerse lists the filing date as 2023‑01‑11). Challenged U.S. Patent No. 9,118,602, App. 13/969,520, Tech Center 2400.
• Status: Final Written Decision (per IPVerse structured data); termination date 2024‑08‑06. Gloss: trial completed; no claim held unpatentable; Cisco appealed and then walked away from the appeal.
• Judge panel: Not confirmed in the sources I retrieved. (I did not locate the FWD panel roster; do not rely on a panel list for this one without pulling Paper 5.)
• Petition grounds (from the Petition and Patent Owner's demonstratives):
  • Ground 1 — § 103(a) over Raz (U.S. Patent No. 7,466,697, "Link multiplexing mechanism utilizing path oriented forwarding") for claims 1‑13, 15‑24 and 26.
  • Ground 2 — § 103(a) over Raz + Ferguson (U.S. Patent No. 7,277,386) + knowledge of a POSA for claims 1‑26.
  • Statutory basis was § 103(a) only; no § 112 or § 102 ground asserted.
• Institution decision: Instituted 2023‑08‑08 (Paper 8). The FWD resolved both grounds on the merits, which indicates both were instituted (an institution denial would not have been appealable, yet Cisco appealed both determinations).
• Final Written Decision: Entered 2024‑08‑06 (Paper 30). All challenged claims survived. Per Cisco's own Notice of Appeal (2024‑10‑01), the FWD held:
  • "The Board's determination that Petitioner has not shown by a preponderance of the evidence that claims 1‑13, 15‑24 and 26 … are unpatentable under 35 U.S.C. § 103(a) in view of Raz"; and
  • "The Board's determination that Petitioner has not shown by a preponderance of the evidence that claims 1‑26 … are unpatentable under 35 U.S.C. § 103(a) in view of the combination of Raz … and Ferguson."
  • Additional appealed issues: "the Board's interpretation of Raz and/or Ferguson" and "the motivation to combine Raz and Ferguson."
  • Patent Owner's winning theory (as reflected in its demonstratives): Raz concerns allocating bandwidth of processors (subports) within an LSR, whereas the '602 claims concern links between MPLS/LAG switches; Raz's multiplexing is "the opposite of a LAG" (inverse multiplexing), so Raz would be inoperable for its intended purpose if modified; and Cisco's Petition/Reply failed to explain how Raz would be modified in view of Ferguson to meet all limitations. The Board found the petitioner's conclusory "bandwidth" motivation insufficient (citing ActiveVideo Networks v. Verizon, 694 F.3d 1312, 1327–28).
• Settlement / termination: None. This was a merits loss, not a settlement.
• Appeal: Yes — CAFC No. 25‑1021, Cisco Systems, Inc. v. Corrigent Corp., from PTAB No. IPR2023‑00447 (notice of appeal filed 2024‑10‑01; docketed 2024‑10‑04). Disposition: DISMISSED under Fed. R. App. P. 42(b), order dated 2025‑02‑14, nonprecedential, "each side shall bear their own costs," mandate issued same day. No merits ruling. Order: https://www.cafc.uscourts.gov/opinions-orders/25-1021.ORDER.2-14-2025_2468569.pdf
• Defensive value: This is the more important of the two proceedings for a defendant, because it went to a full merits FWD on the Raz/Ferguson art and the patent won — and Cisco abandoned the appeal rather than press it. Any new petition built on Raz alone or Raz+Ferguson is (a) already litigated, and (b) collaterally estopped for Cisco and its privies.

IPR2023‑00839 — Arista Networks, Inc. v. Corrigent Corporation

• Type: Inter Partes Review
• Filed: 2023‑04‑18 (one day before Arista's § 315(b) one‑year bar ran, per the institution decision). Challenged U.S. Patent No. 9,118,602, App. 13/969,520, Tech Center 2400.
• Status: Final Written Decision – Appealed (IPVerse/GreyB; ai-lab ex parte tracker lists outcome "Patentable"); termination date 2024‑12‑03.
• Judge panel: Charles J. Boudreau (panel), joined by Christopher L. Ogden and Kristen L. Droesch — per the institution decision, Paper 9 (2023‑12‑07), and Banner Witcoff's PTAB highlight ("Boudreau, joined by Droesch and Ogden").
• Petition grounds: § 103(a) obviousness. Ground 1 — RFC 3209 (RSVP‑TE) + Raz; Ground 2 — the same combination augmented with Ferguson. The institution decision confirms that "of the challenged claims, claims 1, 15, and 26 are independent claims." ⚠️ I could not verify the exact challenged-claim set (e.g., 1‑26) directly from the FWD; the petition's grounds track the Cisco petition's art, and I report the claim range as unconfirmed rather than asserting it.
• Institution decision: Instituted 2023‑12‑07 (Paper 9). Reason: the Board rejected Patent Owner's General Plastic discretionary-denial argument — the second petition was filed only ~3 months after Cisco's, before the patent owner's preliminary response and before the Cisco institution decision; the Board found no evidence of "road-mapping," no "substantial relationship between Arista and Cisco," and no "unfair gamesmanship" (while noting the Arista petition "borrow[ed] extensively" from Cisco's, including identical exhibit numbering for RFC 3209, Raz, and Ferguson). As to the merits, Arista's petition was materially narrower than Cisco's: it started from RFC 3209 as the primary reference and used Raz only for the label‑encoding and LAG teachings, rather than arguing Raz taught everything.
• Final Written Decision: Issued 2024‑12‑03. No challenged claim was held unpatentable — third-party trackers record the outcome as "Patentable." The record is consistent with the Board carrying forward its earlier skepticism of the Raz/Ferguson combination: in its demonstratives, Patent Owner argued "the Board had similar concerns in the prior proceeding, and here the record is worse for Arista on Ground 2," and criticized Petitioner for failing to "specifically explain how the combined teachings of Raz and Ferguson would satisfy individual claim elements." ⚠️ I was not able to read the FWD text itself (only the institution decision, POR/sur-reply demonstratives, and the oral‑hearing transcript), so I do not quote the FWD's claim‑level disposition table. Do not attribute specific per-claim findings to the FWD without pulling it.
• Settlement / termination: None. Merits loss.
• Appeal: Yes — CAFC No. 25‑1424, Arista Networks, Inc. v. Corrigent Corp., from PTAB No. IPR2023‑00839 (appeal docketed 2025‑02‑06; notice received 2025‑02‑04). Docket activity retrieved: Rule 31 certified list received 2025‑03‑19; entries of appearance, docketing statements, certificates of interest filed 2025‑02‑20 (Eliot Williams/Jeremy Taylor/Katherine Burgess for Arista; James Nuttall/Christopher Suarez/Katherine Cappaert for Corrigent). No merits disposition located in my sources; an ai‑lab CAFC tracker still shows "Decision —" with "Pending Judge Assignment." Docket: https://dockets.justia.com/docket/circuit-courts/cafc/25-1424
• Defensive value: Same art as IPR2023‑00447, different primary reference (RFC 3209) and a more plausible framing — and it still failed. The combination of "RFC 3209 as primary + Raz for label encoding" is now a twice-rejected theory on this record. Estoppel for Arista (and its privies) attaches from the 2024‑12‑03 FWD.

Strategic summary

Claim status. Zero claims of US 9,118,602 have been canceled. Both IPRs ended with findings that the petitioner failed to show unpatentability: IPR2023‑00447 held that claims 1‑13, 15‑24 and 26 were not shown obvious over Raz, and that claims 1‑26 were not shown obvious over Raz + Ferguson; IPR2023‑00839 held the challenged claims patentable over the RFC 3209/Raz(/Ferguson) theory. So the complete claim set 1‑26 remains SUSTAINED (as to the art litigated), and there are no UNTESTED claims in the sense of never being challenged — but note that no IPR ever reached a § 102 ground or any § 112 ground, so those remain untested. The practical caveat: the patent expired 2025‑08‑16 (adjusted expiration; status "Expired – Lifetime"), which caps past damages and forecloses injunctive relief.

Estoppel landscape. Under § 315(e)(2), Cisco and its privies are estopped as to any ground raised or that reasonably could have been raised in IPR2023‑00447 (estoppel crystallized on the 2024‑08‑06 FWD; the voluntary FRAP 42(b) dismissal on 2025‑02‑14 did not disturb the FWD). Arista and its privies are likewise estopped from the 2024‑12‑03 FWD in IPR2023‑00839, notwithstanding the pending 25‑1424 appeal. For a new defendant, nothing is estopped personally, but the record is deeply unfavorable: Raz alone, Raz+Ferguson, and RFC 3209+Raz have all been rejected. The genuinely open ground is § 102 (anticipation) and non-Raz/Ferguson art, plus § 112 — but with the patent expired, the ROI on a new IPR is poor.

Pattern signals. Two different hardware competitors (Cisco, then Arista) filed parallel, overlapping petitions against the same patent within ~3 months of each other, coordinating exhibit numbering; the Board refused to apply General Plastic to knock out the second (Arista) petition, finding no substantial relationship between the two petitioners. The patent owner (Corrigent) pursued its appeals defensively and effectively — Cisco's appeal was dismissed on the parties' joint agreement in Feb 2025, and Arista's remains pending. No defensive aggregator was involved: the "Unified Patents" attribution on the Google Patents page is a data-licensing credit under CC BY 4.0, not a party or petitioner — the earlier summary's "Petitioner: Unified Patents PTAB Data" line should not be read as an entity that filed anything. Separately (non-PTAB): CAFC 25‑2036, Corrigent Corp. v. Cisco Systems, Inc., from W.D. Tex. 6:22‑cv‑00396, docketed 2025‑08‑21 — that is a district-court appeal, not a PTAB appeal.

Recommended next steps

• If you are a defendant facing assertion of the '602 patent: the strongest defenses are not IPR-based. In W.D. Tex. 6:22‑cv‑00396, the court granted Cisco's Rule 50(a) JMOL of no infringement on 2025‑01‑16 after a Jan 13–16, 2025 jury trial; Cisco then moved for entry of final judgment on 2025‑02‑10 (Corrigent did not oppose the form of judgment and reserved appeal rights). Cisco's JMOL brief argues the accused products (Nexus 7000, Catalyst 9000, ASR 9000) do not "dedicate a sub‑set of bits in a data packet label … to encode said port serial number of said single physical tunnel port of the LAG," the very limitation the applicant added to overcome prior art during prosecution. The JMOL brief (Dkt. 345) is here: https://storage.courtlistener.com/recap/gov.uscourts.txwd.[1169926](/patent/1169926)/gov.uscourts.txwd.1169926.345.0.pdf — quote the prosecution-history admission ("the reason the Patent Office allowed the claims in the first place," citing PTX008) in any claim chart response.
• If you want the FWD texts to cite: pull IPR2023‑00447, Paper 30 (2024‑08‑06) and IPR2023‑00839, Paper 29/30 (2024‑12‑03) from PTAB E2E — IPR2023‑00447 proceedings: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1550891](/patent/1550891) · IPR2023‑00839 proceedings: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1553919](/patent/1553919). I have not verified the 00839 FWD's per-claim table, so cite it only after reading it.
• Pending appellate milestone to watch: CAFC 25‑1424 (Arista v. Corrigent) — briefing ran off the certified list received 2025‑03‑19; check CourtListener/PACER for a merits opinion or Rule 36. (A companion appeal, 25‑2036, Corrigent v. Cisco, from the W.D. Tex. judgment, is also live.)
• Bottom line for a demand letter: if Corrigent (now Corrigent Corporation, per the 2022 assignments) asserts claims 1‑26 today, the claims are not invalidated — but they are expired, have been twice upheld only against the same Raz/Ferguson art, and were held not infringed as a matter of law at the only trial to reach the merits. That is a licensing posture, not a litigation threat.

I'll research the assignment record for US 9,118,602 across the USPTO Assignment Center, Google Patents legal events, and corporate filing records.

Strong leads. Let me pull the specific assignment records and correspondents.

Assignment Record — US 9,118,602 B2 ("Tunnel provisioning with link aggregation")

Sourcing note / limitation (read first). I could not open assignmentcenter.uspto.gov or assignment.uspto.gov directly in this session, so I could not read the Assignment Center abstract of title screen-by-screen. What follows is reconstructed from (a) the Google Patents legal-events panel for US9118602B2 (which mirrors USPTO assignment records as "Assigned to…" events), and (b) USPTO PTAB exhibits in the Corrigent IPRs that reproduce USPTO assignment abstracts verbatim with reel/frame numbers and correspondence fields (ptacts.uspto.gov/.../petitions/1553870 and .../petitions/1553764). The PTAB exhibits are for the Orckit portfolio — I can confirm the 2016 purchase agreement expressly lists application 14/834,480 (the direct continuation of the '602, now US 9,590,899), so the 2016 recording certainly covers this family, but I could not confirm, field-by-field, that every portfolio reel below denominates 9,118,602 specifically. Where the '602-specific reel/frame is missing I say so rather than guess. Correspondent names were not retrievable — the PTAB "CORRESPONDENCE DATA" block was truncated in the excerpt. That is an explicit gap, not a finding of "no correspondent."

Inventors

Unusual pattern observed: there is only one inventor, and he is not a party to any later transfer. Trial testimony in the related Corrigent litigation (E.D. Tex., gov.uscourts.txed.216428.324) records that "the inventors on these patents will not receive any monies from licensing or this lawsuit" and that Orckit‑Corrigent itself received nothing — i.e., the inventors were fully divested and have no economic interest in the asserted portfolio. That is consistent with a portfolio that was separated from the inventing entity entirely.

Original assignee

Orckit‑Corrigent Ltd. (originally Orckit Communications Ltd., Tel Aviv, Israel; NASDAQ/TASE ticker ORCT). Google Patents lists the assignee at issue as "Orckit Corrigent Ltd"; the family page also shows the 2014 record as ORCKIT‑CORRIGENT LTD.

• Primary line of business: telecom networking equipment — packet transport network (PTN) switches / MPLS‑TP and TDM‑migration gear for carriers.
• Did it ship a product embodying the claims? Yes. Orckit‑Corrigent's IPR papers state the portfolio was "practiced by its products, notably, the CM‑4000 product family … CM‑4140, CM‑4206, CM‑4314T/4314 … and the CM‑401x portfolio … CM‑4011, CM‑4012, CM‑4013" (ptacts.uspto.gov/.../petitions/1550831). These are MPLS/Ethernet switches — the exact art class of the '602 (LAG member-port selection in an MPLS/LSR switch). The claims were written by the operating vendor, not by an NPE.
• Current status: Defunct / bankrupt. Debt restructuring ("creditors' arrangement") in Israel in 2012, then liquidation/bankruptcy proceedings from mid‑2015; Wikipedia (Orckit‑Corrigent) records "Defunct 2015 — Fate: Bankrupted." The Orckit corporate website went to financial run‑off in 2021 and was gone by 2022.

Assignment timeline

Chronological. Rows split into (A) '602-specific records (Google Patents legal events) and (B) portfolio-level recorded assignments from the USPTO PTAB chain-of-title exhibit. Reel/frame given where retrieved; where the '602-specific reel is not retrievable I say "reel not retrieved."

1. 2014‑02‑03 (recorded) — Reel not retrieved

• Conveyance: Assignment (inventor → company)
• Assignor: Ronen Solomon
• Assignee: Orckit‑Corrigent Ltd.
• Correspondent: not retrieved.
• Context: Original inventor assignment perfecting title in the operating company.

2. 2013‑03‑18 (executed and recorded) — Reel 030034/0366

• Conveyance: Security Agreement
• Assignor: Orckit Communications Ltd.
• Assignee: Hudson Bay IP Opportunities Master Fund, LP (New York)
• Correspondent: not retrieved.
• Context: Securitization — the operating company pledged its patent portfolio as collateral to a patent‑monetization fund. First sign the portfolio was being treated as a financing asset, not a product‑protection asset. (Portfolio-level record; '602‑specific inclusion not independently confirmed.)

3. 2013‑07‑23 (executed) / recorded 2013‑07‑26 — Reel 030885/0117

• Conveyance: Release by Secured Party
• Assignor: Hudson Bay IP Opportunities Master Fund, LP
• Assignee: Orckit Communications Ltd.
• Correspondent: not retrieved.
• Context: Release of the 2013 security interest — the collateral was cleared shortly after the debt restructuring, freeing the portfolio for sale. (Portfolio-level record.)

4. 2016‑04‑25 (executed) / recorded 2016‑05‑11 — Reel 038541/0984 (Google Patents shows the '602 event recorded 2016‑05‑09; family page lists assignee Orckit IP, LLC)

• Conveyance: Assignment
• Assignors: Orckit Communication Ltd. (under Creditors' Arrangement), Orckit‑Corrigent Ltd., and Corrigent Systems Ltd. (jointly "Assignor")
• Assignee: Orckit IP, LLC — a Delaware LLC, address 874 Walker Road, Suite C, Dover, DE 19904‑2778, mailing address 831 Beacon Street #307, Newton, MA 02459
• Correspondent: not retrieved (correspondence block truncated in exhibit).
• Context: Bankruptcy / insolvency fire‑sale. The assignment agreement recites a Purchase Agreement dated 2015‑11‑30 between the insolvent Orckit entities and Orckit IP, LLC. The assignor was represented by the court‑appointed trustee ("Lior Dagan, Adv. (Trustee)"). Total property count on the recorded instrument: 13 (including application 14/834,480, the '602's continuation). This is the pivotal transfer — the operating company's estate sold the patents to a newly formed licensing LLC.

5. 2018‑04‑26 (executed) / recorded 2018‑05‑03 — Reel 045708/0435

• Conveyance: Assignment
• Assignor: (Orckit IP, LLC — implied by the round‑trip)
• Assignee: Blackbird Tech LLC (Massachusetts)
• Correspondent: not retrieved.
• Context: Transfer to a well‑known serial NPE. (⚠ This reel appears in an Orckit patent's PTAB chain-of-title; I could not confirm it denominates 9,118,602. Treat as portfolio‑level, not '602‑specific.)

6. 2019‑01‑09 (executed) / recorded 2019‑01‑13 — Reel 048067/0604

• Conveyance: Assignment (assignment back)
• Assignor: Blackbird Tech LLC
• Assignee: Orckit IP, LLC (Massachusetts)
• Correspondent: not retrieved.
• Context: Reverse transfer — the patent(s) came back to Orckit IP. Round‑trip through an NPE in <12 months. (Portfolio‑level; '602‑specific inclusion not confirmed.)

7. 2021‑12‑31 (executed) / recorded 2022‑07‑18 — Reel 060539/0804 *(Google Patents shows the '602 event 2022‑04‑14, assignee Nahum Communication N.T.B. Ltd., assignor Orckit IP, LLC)*

• Conveyance: Assignment
• Assignor: Orckit IP, LLC
• Assignee: Nahum Communication N.T.B. Ltd. (Israel)
• Correspondent: not retrieved.
• Context: Cascading transfer — portfolio pushed into an Israeli entity shortly before the first infringement suits.

8. 2022‑04‑14 (recorded) — Reel not retrieved (Google Patents legal event)

• Conveyance: Assignment
• Assignor: Nahum Communication N.T.B. Ltd.
• Assignee: Corrigent Corporation
• Correspondent: not retrieved.
• Context: Transfer into the current asserting entity (Corrigent Corporation), coinciding with the filing of the 2022 district‑court cases.

9. 2022‑06‑15 (executed) / recorded 2022‑07‑19 — Reel 060544/0799 (⚠ conflict — see below)

• Conveyance: Assignment
• Assignor: Nahum Communication N.T.B. Ltd.
• Assignee: Orckit IP, LLC (Massachusetts)
• Correspondent: not retrieved.
• Context: Reverse transfer back to Orckit IP.

CONTRADICTION FLAGGED. The two independent sources disagree on where the chain terminates in 2022. Google Patents legal events send the '602 Orckit IP → Nahum → Corrigent Corporation (both recorded 2022‑04‑14). The USPTO PTAB chain-of-title exhibit for the Orckit portfolio shows Orckit IP → Nahum (reel 060539/0804, exec. 2021‑12‑31) and then a reverse Nahum → Orckit IP (reel 060544/0799, exec. 2022‑06‑15). It is likely that different family members went to different vehicles (Corrigent Corporation vs. a return to Orckit IP) as part of one 2022 restructuring, and/or that recorded reels predate Google's summarised "reassignment" dates. I cannot resolve this from the retrieved data. Anyone relying on this must pull the '602‑specific reel/frame from the Assignment Center before quoting a current owner.

Timeline diagram

timeline
    title Ownership of US 9118602
    2005 : Filed by Orckit Corrigent Ltd
         : Inventor Ronen Solomon
    2013 : Security interest to Hudson Bay IP fund
         : Release of security interest
    2015 : Issued to Orckit Corrigent Ltd
         : Orckit enters Israeli liquidation
    2016 : Portfolio sold to Orckit IP LLC
    2018 : Transfer to Blackbird Tech LLC
    2019 : Transfer back to Orckit IP LLC
    2021 : Orckit IP transfers portfolio to Nahum
    2022 : Transfer to Corrigent Corporation
         : Suits filed against Cisco and Arista

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT.
Reel 038541/0984 (exec. 2016‑04‑25) moved the portfolio from the operating Orckit entities to Orckit IP, LLC, a Delaware LLC at 874 Walker Road, Suite C, Dover, DE 19904‑2778 — a registered-agent/corporate-services address, with a Newton, MA mailing address. Orckit IP does not appear to ship any product; the assignor's products (CM‑4000/CM‑401x) stayed with the insolvent operating company. Name suffix "IP", single-purpose LLC, no commerce.

2. Known asserter in the chain — PRESENT (with one caveat).

• Orckit IP, LLC is a documented high-volume plaintiff (the asserted entity behind the W.D. Tex. 6:22‑cv‑00396 and D. Del. 1:22‑cv‑00497 suits, and the patent owner responding in Arista v. Corrigent, IPR2023‑00839). It is not on the "classic" list you named but is a well-known 2020s campaign vehicle.
• Hudson Bay IP Opportunities Master Fund, LP (reel 030034/0366, 2013) is a patent-monetization financing fund — its appearance as secured party is a monetization-financing tell.
• Blackbird Tech LLC (reel 045708/0435, 2018) is a well-known serial NPE — but this reel is portfolio-level, not confirmed for the '602.
• Caveat: the 2022 assignee Corrigent Corporation reuses the name of the historic operating business; naming alone is not evidence, so I do not count the name itself.

3. Repeat correspondent across the chain — UNCLEAR / NOT RETRIEVED.
This is the single most diagnostic field you asked for (shells change, the recording attorney doesn't) and I could not obtain it. The PTAB exhibit reproduces an "ASSIGNMENT AGREEMENT" with a "CORRESPONDENCE DATA" section, but the attorney/firm name was truncated in the retrieved text on every reel I saw (038541/0984, 030034/0366, 030885/0117, 045708/0435, 048067/0604, 060539/0804, 060544/0799). Action item: open each reel in the Assignment Center and read the "Correspondent" field — if one attorney/firm recurs across 2016, 2018, 2019, 2021 and 2022, that is a strong recurrence finding I currently cannot make.

4. Cascading transfers — PRESENT.
At least four recorded hops in roughly six years: Orckit entities → Orckit IP, LLC (2016) → Blackbird Tech LLC (2018) → Orckit IP, LLC (2019) → Nahum Communication N.T.B. Ltd. (exec. 2021‑12‑31) → Corrigent Corporation / back to Orckit IP (2022). The 2018→2019 and 2021→2022 pairs are round‑trips (out to a licensor and back), a pattern typical of financing, co‑investment, or standing/venue housekeeping rather than genuine corporate succession.

5. Pre‑litigation transfer — PRESENT.
The Nahum/Nahum‑back transfers execute 2021‑12‑31 and 2022‑06‑15, and the district‑court cases follow in 2022 (W.D. Tex. 6:22‑cv‑00396 and D. Del. 1:22‑cv‑00497, both listed on the '602 family page). The 2022 recorded reels therefore land within roughly six months of the first suits — the classic re‑papering of title right before assertion.

6. Bankruptcy fire‑sale — PRESENT.
This is the clearest signal in the file. Orckit's Israeli creditors' arrangement (2012) and liquidation (2015), the Purchase Agreement dated 2015‑11‑30, and the trustee‑fronted assignment executed 2016‑04‑25 (reel 038541/0984) constitute a court‑supervised insolvency sale of the portfolio to Orckit IP, LLC. Litigation testimony (E.D. Tex. txed.216428.324) records that "Orckit IP purchased all of Orckit‑Corrigent's patents … through those proceedings."

7. Privateering — UNCLEAR, with supporting colour.
Two facts point toward ex‑management acquiring the estate's patents for a licensing campaign rather than a third‑party buyer: (i) trial testimony in gov.uscourts.txwd.1169926.304 identifies Izhak Tamir (Orckit's co‑founder/CEO) as the person who funded the Orckit IP purchase ("he was the source of that 1.35 million"), and that in 2020 he bought the trustee's residual rights; (ii) testimony in txed.216428.329 records that "Orckit IP joined forces with Mr. Pitcock … for 15 percent of any proceeds … he'd start filing lawsuits," with "Orckit IP gets 42 percent of anything that may be awarded." These are adversary characterizations from opposing counsel's cross‑examination, so I treat them as colour, not proof. But they describe a classic contingency‑fee assertion arrangement layered on top of a bankruptcy acquisition.

8. Defensive aggregator (anti‑NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at an asserting entity (Corrigent Corporation / Orckit IP). Note the irony: the defendants in this family's PTAB proceedings (Cisco, Arista) are the ones using Unified Patents‑style IPR challenges — the patent was being attacked, not neutralized by purchase.

Verdict

NPE — high confidence.

Justification: the record shows an operating telecom vendor (Orckit‑Corrigent, maker of the CM‑4000/CM‑401x PTN switches that practised these claims) selling its patents out of Israeli insolvency to a purpose‑built Delaware licensing LLC, Orckit IP, LLC, via the trustee‑fronted assignment at reel 038541/0984 (exec. 2016‑04‑25), followed by cascading and round‑trip transfers through Blackbird Tech LLC (reel 045708/0435) back to Orckit IP (reel 048067/0604) and then to Nahum Communication N.T.B. Ltd. (reel 060539/0804, exec. 2021‑12‑31) and Corrigent Corporation — landings that fall within ~6 months of the 2022 infringement suits (W.D. Tex. 6:22‑cv‑00396; D. Del. 1:22‑cv‑00497). That is at least four independent NPE signals (bankruptcy fire‑sale, shell‑entity transfer, cascading transfers, pre‑litigation transfer), and the 2013 Hudson Bay IP Opportunities security interest (reel 030034/0366) shows the portfolio was being treated as a monetization asset even before insolvency. Two gaps keep me from calling it "certain": the correspondent field is unretrieved, and the 2022 terminal owner is contradicted between sources (Corrigent Corporation vs. a return to Orckit IP, LLC).

Verification links:

• Assignment Center search for this patent: https://assignmentcenter.uspto.gov/ (search by patent number 9118602) — also indexed at https://assignment.uspto.gov/patent/index.html
• USPTO PTAB chain‑of‑title exhibit (reel/frame data quoted above): https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1553870](/patent/1553870)/download-documents?artifactId=9naXBSbhRhwpbvO9r2kAPgCMROxP8jvxlkaZ5VQM5czvVxXJTtD28z4
• USPTO PTAB exhibit showing the INPADOC assignment table with reels 060544/0799 and 060539/0804: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1553764](/patent/1553764)/download-documents?artifactId=aCAAVoMSQIFz60tWvXEipKT25qGRuOv0p5ALphnibaHLoWFGY0gPPzI
• Google Patents legal events for US9118602B2: https://patents.google.com/patent/US9118602/en
• Trial testimony on the Orckit IP acquisition and assertion economics: https://storage.courtlistener.com/recap/gov.uscourts.txed.[216428](/patent/216428)/gov.uscourts.txed.216428.329.0.pdf and https://storage.courtlistener.com/recap/gov.uscourts.txwd.[1169926](/patent/1169926)/gov.uscourts.txwd.1169926.304.0.pdf

I'll research the prior art citations for US 9,118,602. Let me start with several searches to gather authoritative data.

Let me research the specific cited references in detail.

Prior‑Art Analysis — U.S. Patent No. 9,118,602 B2 ("Tunnel Provisioning With Link Aggregation")

Sourcing note / caveat (please read first). I was unable to query USPTO PatentCenter/PAIR directly in this session. The bibliographic data and the citation list below are taken from the authoritative full text of US9118602B2 provided in the record (https://patents.google.com/patent/US9118602/en), which includes the face‑of‑patent citation list, plus the IPR/PACER/court materials surfaced in the earlier sections and in this search. Where a reference's content is described from a source other than the '602 text itself (e.g., the reference's own patent page), I say so. The "prior art" below is the set the patent itself cites (its "Citations (6)" list plus references incorporated by reference), augmented by the references the PTAB used in the 2023 IPRs, which are the most probative art actually applied against these claims.

0. Identification of the target patent

Because the '602 family has an earliest priority of 2005‑05‑06, it is governed by pre‑AIA 35 U.S.C. § 102/103. The § 102(b) critical date is therefore 2004‑05‑06; references published after that date but before 2005‑05‑06 qualify only under § 102(a) (and/or § 102(e) via their U.S. filing dates), and a U.S. application published after 2005‑05‑06 can still be § 102(e) art as of its own U.S. filing date.

1. The nine references of record (what the '602 patent itself cites)

The '602 patent's own face lists six examiner‑cited references ("Citations (6)"), and the specification expressly incorporates two further documents by reference in the Background section. All identifiers are reproduced literally.

(A) The six face‑of‑patent citations

(B) References expressly incorporated by reference in the '602 specification

(C) Not part of the '602 record — the two references that actually drove the IPRs

These are in the family's citation history and were the grounds in the 2023 IPRs against the '602:

Additional background references appearing in the family's citation history that are topically on point (for the broader landscape, not the '602's own face): US 2003/0174706 A1 (Broadcom, transparent LAN over MPLS); US 7,633,394 / US 7,697,525 (Corrigent, hash‑based multi‑homing; multicast over LAG); US 7,336,605 B2 (Corrigent, "Bandwidth allocation for link aggregation").

2. Reference‑by‑reference analysis (description + claims potentially implicated)

Important framing. The independent claims 1, 15 and 26 each require the conjunctive limitation of "dedicating a sub‑set of bits in a data packet label … to encode said port serial number of said single physical tunnel port" and (in claim 1/26) sending that label to a preceding node. Under § 102 a single reference must disclose every element. None of the six face citations does so cleanly; in every case the art is a § 103 combination proposition. I flag that explicitly with each entry rather than overstating anticipation.

1) US 2003/0020976 A1 — Krishnaswamy (port interconnection discovery)

• Full citation: U.S. Patent Application Publication 2003/0020976 A1, "Method and apparatus for automatic port interconnection discovery in an optical network."
• Dates: published 2003‑01‑30; priority 2001‑07‑18.
• Description (from the reference's own record): concerns automatically discovering the physical interconnection/topology of ports in an optical network (management‑plane discovery), not packet forwarding or label assignment.
• § 102 analysis: No anticipation of any claim of the '602. It is general background on identifying/tracking ports; it does not disclose a LAG, MPLS label encoding of a port serial number, or tunnel provisioning. If cited at all against the claims, it would at most be peripherally relevant to "port serial number" identification language and cannot teach the label‑encoding limitation.

2) US 2004/0107285 A1 — Science Applications International Corp. (VPN secure link)

• Full citation: U.S. Patent Application Publication 2004/0107285 A1, "Method for establishing secure communication link between computers of virtual private network."
• Dates: published 2004‑06‑03; priority 1998‑10‑30.
• Description: establishing secure/encrypted communication links between computers over a virtual private network.
• § 102 analysis: No anticipation. This is VPN‑security art. It shares only the generic notion of a "tunnel"/secure link. It does not disclose link aggregation, LAG port selection, bandwidth‑based port assignment, or label‑encoded port identity. It is at best § 103 background showing tunnels were known.

3) US 2005/0083928 A1 — Cisco/Sivabalan (re‑routing MPLS TE LSPs within a link bundle) — the closest of the face citations

• Full citation: U.S. Patent Application Publication 2005/0083928 A1 (corresponding to WO 2005/043928 A3 and EP 1676451 B1), "Transparent re‑routing of MPLS traffic engineering LSPs within a link bundle."
• Dates: published 2005‑04‑21; priority 2003‑10‑20 (US 10/689,385); PCT filed 2004‑09‑23.
• Description: MPLS Traffic Engineering LSPs run over a "link bundle" of multiple component links between two nodes. A local admission‑control mechanism at the bundle‑originating node selects a "primary" component link that satisfies the LSP's bandwidth requirement (and one or more "secondary" component links as backups), swapping the LSP to a secondary component link upon failure without signaling the head‑end, with component‑link info preconfigured in the label forwarding table for fast switchover. Functionally this is the LSP analogue of selecting a single member of a LAG and providing backup/failover.
• Claims potentially implicated (as a § 103 base, not a § 102 anticipation):
  • Claim 1 & 26, first limitation ("assigning a single physical tunnel port … that meets a bandwidth requirement"): Sivabalan's bandwidth‑qualified primary component‑link selection.
  • Claims 4–7 (service properties; max/min‑sufficient bandwidth selection): the admission‑control selection on available bandwidth.
  • Claims 11–12 and 22 (backup port; failover; revert): Sivabalan's primary/secondary component links and local switchover.
  • Claims 13/23 (LSR), 14/25 (bundle = "single logical port").
  • But Sivabalan does not disclose the "sub‑set of bits in a data packet label encoding the port serial number." That is precisely why the applicant overcame the Examiner's Sivabalan‑based rejection (see § 4).

4) US 2005/0090275 A1 — General Motors (active wireless data channel select)

• Full citation: U.S. Patent Application Publication 2005/0090275 A1, "Active wireless data channel select mechanism."
• Dates: published 2005‑04‑28; priority 2003‑10‑23.
• Description: a mechanism for actively selecting a wireless data channel among available channels.
• § 102 analysis: No anticipation. This is wireless channel‑selection art, cited as generic "select one of several channels/ports" background. It has no MPLS, no LAG, no label‑encoding teaching, and cannot map to the label‑encoding or fabric‑switching limitations.

5) US 2005/0125490 A1 — Ramia (handling MPLS labels) — the second key combination reference

• Full citation: U.S. Patent Application Publication 2005/0125490 A1, "Device and method for handling MPLS labels" (granted as US 7,174,427 B2, 2007‑02‑06).
• Dates: published 2005‑06‑09; priority 2003‑12‑05 (§ 102(e) art only, as of 2003‑12‑05).
• Description (from the reference's own record): MPLS label‑stack handling using an Incoming Label Mapping (ILM) table (and Next‑Hop Label Forwarding Entry table). Describes that a downstream MPLS node determines/distributes labels upstream to the requesting node; that MPLS labels identify a Forwarding Equivalence Class (the same path); that labels can be unique to a particular interface/port; and that a received label is looked up (e.g., in the ILM table) to determine the outgoing interface/label.
• Claims potentially implicated (as part of a § 103 combination with Sivabalan):
  • Claim 2 / claim 26 (request message requesting a label; downstream node returns label upstream).
  • Claims 9 and 20 ("inserting into said data packet label a set of bits which identify said tunnel port"; mapper extracts the bits).
  • Claims 10 and 21 (storing the label with a port identifier in memory/lookup table and retrieving it by label — Ramia's ILM‑table lookup).
  • Claims 8 (mapping function).
  • Ramia supplies the "label is distributed upstream from the downstream node" and "label carries port/interface identity" concepts that Sivabalan lacks — but not, on its face, a bandwidth‑selected LAG member or dedicating specific label bits to encode that port's serial number.

6) US 7,983,286 B2 — Rekhter / Juniper (transparent LAN segment service) — the face citation most relevant to the "label carries port info" idea

• Full citation: U.S. Patent 7,983,286 B2, "Edge devices for providing a transparent LAN segment service and configuration such edge devices."
• Dates: granted 2011‑07‑19; appl. 12/329,858 filed 2008‑12‑08; benefit of provisional 60/325,344 filed 2001‑09‑26 (parent issued as US 7,463,639). Under pre‑AIA § 102(e) its effective date is ~2001‑09‑26.
• Description (from the reference's own record): provisioning Transparent LAN Segments (TLS) over a transport network. Notably it advertises/signals to other provider‑edge devices, for a given port, a set of "TLS‑port‑label" information — the edge‑device identifier, the TLS identifier, a port identifier, and label information (label base, label offset, label range) — so that receiving PEs update their Layer‑2 forwarding tables. A given logical port belongs to one TLS, and label information is tied to ports.
• Claims potentially implicated (as a § 103 combination element):
  • Claim 1 / claim 26 ("sending … the data packet label … to a preceding node") and claim 15 ("publish said packet label upstream") — Rekhter teaches distributing port‑associated label information to other nodes.
  • Claim 15 "publish said packet label upstream."
  • The general notion that a label carries port identity that other nodes use to forward.
  • Gap: Rekhter is about LAN‑segment tunneling and MAC learning, not about MPLS LAG‑member selection on a bandwidth basis, and not about dedicating label bits to a physical tunnel port serial number of an aggregated group. It is a § 103‑style adjunct, not an anticipation.

(B‑1) US 2002/0110087 A1 — Zelig (efficient setup of label‑switched connections)

• Incorporated by reference by the '602. Describes carrying Layer‑2 (Ethernet) services through label‑switched network tunnels. § 102: No anticipation of any claim; background only (tunnel establishment for L2 services).

(B‑2) US 2004/0228278 A1 — "Bandwidth allocation for link aggregation"

• Incorporated by reference by the '602. Ensures sufficient LAG bandwidth to meet service guarantees despite load fluctuation/failure. § 102: No anticipation; background on LAG bandwidth reservation — relevant only to the bandwidth‑selection and backup elements (claims 4–7, 11–12, 22).

3. The art the PTAB actually applied (most probative for claims 1/15/26)

The two 2023 IPRs used RFC 3209 + US 7,466,697 (Raz) — not the face citations — as the primary attack, which tells you where the real § 102/§ 103 exposure lives:

• IETF RFC 3209 (RSVP‑TE, Dec. 2001): the '602 itself cites and incorporates it. In IPR2023‑00839 (Arista v. Corrigent) the Board found RFC 3209 discloses/renders obvious "assignment of a physical interface to a network tunnel (an LSP)" by an MPLS LSR, and that bandwidth can be allocated to the LSP via RSVP reservations (per the institution decision reproduced at bannerwitcoff.com, https://bannerwitcoff.com/wp-content/uploads/2023/12/IPR2023-00839.pdf). This maps to claim 1's "assigning … a single physical tunnel port … that meets a bandwidth requirement" and to claims 4–5.
• US 7,466,697 B1 — Raz (Atrica Israel): discloses assigning one "subport" of an Ethernet LAG to a network tunnel and an algorithm for allocating sub‑port bandwidth. In IPR2023‑00839 the Board was "persuaded that the combined teachings of RFC 3209 and Raz support Petitioner's contentions" for the "assigning … single physical tunnel port of a LAG" limitation of claim 1.
• US 2005/0083928 (Sivabalan) + US 2005/0125490 (Ramia): the same pairing the Examiner used during original prosecution.

The novelty‑critical limitation in all three independent claims — the dedication of a sub‑set of label bits to encode the port's serial number, with that label sent upstream to and received back from the preceding node — is what the record shows the applicant relied on to distinguish Sivabalan+Ramia. That is the fulcrum on which any § 102/103 challenge turns.

4. § 102 / § 103 mapping table (summary)

5. Prosecution‑history payoff (why this matters)

The '602's parent and grandparent file histories (quoted in the IPR exhibits, e.g. https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1553919](/patent/1553919)/…) show the Examiner rejected claims over Sivabalan (US 2005/0083928) in view of Ramia (US 2005/0125490), and further in view of Kompella et al., and that the applicant overcame those rejections by adding (i) "dedicating a sub‑set of bits of said data packet label to encode said port serial number of said physical tunnel port," and (ii) the "sending … a message comprising said data packet label to a preceding node [and] receiving … a data packet comprising said data packet label" limitations. Map that to the issued claims and the § 102 question is answered: Sivabalan and Ramia, individually or together, were the closest art but were not anticipatory, and the surviving patentability hook is the bit‑encoding / label‑round‑trip (upstream label request → downstream label with encoded port → downstream data packet steered by that port).

6. Bottom line and confidence

• Most relevant prior art: (1) US 2005/0083928 A1 (Cisco/Sivabalan) — bandwidth‑qualified selection of a single member link of a bundle, with backup; (2) US 2005/0125490 A1 (Ramia) — upstream label distribution and label/port association; (3) US 7,983,286 B2 (Rekhter/Juniper) — advertising port‑associated label information to peer nodes; and, most probatively, the IPR ground pair IETF RFC 3209 and US 7,466,697 B1 (Raz). None of the six face citations, standing alone, anticipates any of claims 1, 15 or 26; each is relevant only in a § 103 combination, because none discloses the "dedicate a sub‑set of bits of the data‑packet label to encode the port serial number" + label round‑trip limitations.
• High confidence: the six face citations and their dates (from the '602's own record); the two incorporated references; the fact that Sivabalan+Ramia were the Examiner's § 103 combination and were overcome by the bit‑encoding amendment; RFC 3209 and Raz being the IPR2023‑00839 Ground‑1 references.
• Lower confidence / not independently verified in this session: the exact disclosure pin‑cites within US 2003/0020976, US 2004/0107285 and US 2005/0090275 (I described these from the citation titles and general field knowledge, not from a page‑level read of each reference); and the precise claim numbers rejected over each reference at each prosecution stage (the mapping in § 5 comes from IPR exhibit quotations, which I have treated as reliable but which are party submissions).
• Recommended next step to close gaps: pull the full text of the six face citations and the '202/'682 file wrappers from USPTO PatentCenter/PAIR (https://patentcenter.uspto.gov) to confirm the examiner's exact claim‑by‑claim rejections, and confirm whether US 7,983,286 B2 was cited for its § 102(e) 2001‑09‑26 date. I could not do so in this session.

Primary URLs used: Google Patents US9118602B2 (https://patents.google.com/patent/US9118602/en); Cisco/Sivabalan US2005/0083928A1 and WO2005/043928A3 / EP1676451; Ramia US2005/0125490A1 (granted US 7,174,427 B2); Rekhter US7983286B2; IPR2023‑00839 institution decision (bannerwitcoff.com PDF); IPR exhibits on PTAB (ptacts.uspto.gov).

I'll research the specific prior-art grounds, including the PTAB petitions that challenged this patent, since those petitions identify real § 103 combinations.

§ 103 Obviousness Analysis — U.S. Patent No. 9,118,602 B2

Analyst note on sourcing. This analysis builds on the earlier sections (bibliographic data, claim summaries, litigation). Per the current task I use (a) the prior-art section of the patent page itself — the examiner "Citations (6)" list, the two publications named in the Background, and the "Family Cites Families (113)" list — and (b) the actual § 103 grounds pleaded in the two IPRs that challenged this patent, which I located in the PTAB record. Material I could not verify is flagged.

Two prior caveats are now resolved:

• The earlier summary flagged "IPR2023‑00447 ↔ '602" as unconfirmed. It is confirmed. Cisco's petition in IPR2023‑00447 is captioned "OF U.S. PATENT NO. 9,118,602," challenges "Claims 1‑26," and is the Cisco appeal docketed as Fed. Cir. 25‑1021 in the order at https://www.cafc.uscourts.gov/opinions-orders/25-1021.ORDER.2-14-2025_2468569.pdf. Both IPRs target US 9,118,602.
• The earlier note that "PatSnap characterizes 25‑1021 as concerning US9118602B2 but the court order says IPR2023‑00447" — there is no contradiction: IPR2023‑00447 is the '602 IPR. Both statements are correct.

I. Governing framework

Because the earliest priority date is 2005‑05‑06 (via Ser. No. 11/123,801), the claims are governed by pre‑AIA 35 U.S.C. § 103(a). Obviousness is measured under Graham v. John Deere — scope/content of the prior art, differences between the claims and the art, the level of ordinary skill, and secondary considerations — as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (a combination is obvious where the elements were "known in the art," the combination is "of familiar elements according to known methods," and yields no more than "predictable results").

Person of ordinary skill (POSITA). The parties litigated this with experts Dr. Rouskas and Dr. Akl. A reasonable definition (and the one implicit in the petitions) is a person with a B.S. in electrical engineering or computer science (or equivalent) plus roughly 3–5 years of experience designing/operating packet-switched networks, including working knowledge of MPLS (RFC 3031, RSVP‑TE/RFC 3209), Ethernet switching, and IEEE 802.3ad link aggregation. I did not retrieve a stipulated construction, so this is a reasoned estimate, not a quote.

II. Claim scope: where the § 103 fight actually is

The patent has three independents — claim 1 (method), claim 15 (apparatus), and claim 26 (method with express request/label‑request) — plus dependents 2‑14 and 16‑25. The claim elements that are not the controversy (all conceded in the specification as known) are:

• MPLS tunneling and RSVP‑TE PATH/RESV provisioning with a LABEL_REQUEST object (Background ¶¶ citing RFC 3031, RFC 3209).
• Ethernet LAG as a set of parallel physical links joined into one logical link under IEEE 802.3ad (Background; '602 col. 2).
• Per‑port bandwidth allocation in a LAG to meet service guarantees — expressly described and incorporated by reference in the '602 Background (citing US 2004/0228278 A1, "Bandwidth Allocation for link Aggregation").

The contested core (the point on which Cisco prevailed at JMOL, Tr. 308‑314 / Dkt. 345) is the limitation:

"dedicating a sub-set of bits in a data packet label prepared by the first MPLS/LAG switch to encode said port serial number of said single physical tunnel port of the LAG into the data packet label" (claim 1, and identically claims 15 and 26).

So a § 103 analysis must (i) show each blocking element was known, and (ii) supply a rational motivation to combine them into the specific "port‑index‑in‑label‑bits" architecture.

III. The prior art of record

IV. Element‑by‑element mapping of claim 1

Every element has a named, analogous, same‑field disclosure. That is the first prong of KSR.

V. Proposed § 103 grounds

Ground A — Raz alone (Cisco's Ground 1 in IPR2023‑00447)

Cisco argued claims 1‑13, 15‑24, 26 unpatentable over Raz (with POSA knowledge). The theory: Raz discloses an LSR whose Ethernet physical data ports are aggregated into a LAG, with a tunnel "subport" allocated per LSP and bandwidth reserved to it, and label provisioning that ties a label to the allocated subport. Combine with the admitted‑prior‑art RSVP‑TE/LAG background and the 802.3ad ordering rule, and a single port per tunnel selected on bandwidth, identified by the label, is the natural implementation.

Strength: Raz is the closest single reference — it sits squarely at the MPLS‑LAG intersection and uses the subport/LSP vocabulary the claims use. Weakness (and Corrigent's central rebuttal): Raz's aggregation is within an LSR (internal subports), whereas the claims recite LAG ports between two MPLS/LAG switches. The Board's institution decision in the parallel Arista IPR reflects skepticism about reading Raz as a between‑switches LAG without more. Whether Raz alone reaches every claim is therefore contested; Grounds B/C below cure that gap.

Ground B — Raz + Ferguson (Cisco's Ground 2; Arista's Ground 2 adds RFC 3209)

This is the strongest pleaded combination and the one I would lead with.

• Raz supplies the LAG‑of‑Ethernet‑physical‑ports in an MPLS node, per‑LSP port assignment, and bandwidth reservation to the assigned port.
• Ferguson supplies the missing bridge to between‑switches operation and supplies limitation (c) directly: Ferguson distributes MPLS packets across "parallel physical interconnects of an aggregated link" by using allocated ranges of MPLS labels, and expressly states the technique "may be readily applied to internal parallel data paths within a device" and vice‑versa — i.e., it teaches the two‑way portability of the label‑driven aggregation mechanism between intra‑device paths and inter‑device aggregated links.
• RFC 3209 supplies the provisioning machinery (PATH + LABEL_REQUEST out; RESV + LABEL back) that limitation (d) recites.
• 802.3ad / Bruckman supply the frame‑ordering motivation to pin a conversation (here, a tunnel) to one port.

Motivation to combine (the why, per KSR):

1. Same problem, same field. All three references target the same problem — ensuring sufficient, deterministic bandwidth for high‑speed packet streams carried over MPLS using aggregated links. The petitions put it exactly this way ("all three references are directed to solving the problem of ensuring enough bandwidth…").
2. Express cross‑application teaching. Ferguson itself says its aggregated‑link, label‑range distribution technique works equally "within a device" — supplying the very bridge Corrigent says is missing from Raz. That converts Corrigent's "different problem/different locus" argument into a taught‑away‑from‑the‑argument problem: Ferguson teaches toward the combination.
3. Design‑choice / predictable result. Applying known LAG technology to an LSR‑to‑LSR interconnect instead of to an internal path is a design choice with a predictable benefit (more usable bandwidth than a single high‑speed link). The Board's prior reasoning and Cisco's reply stressed exactly this: a single high‑speed link has a bandwidth ceiling, and a POSITA would know a LAG is the standard alternative when more usable bandwidth is needed.
4. Nested known techniques. Bandwidth‑based port selection (Sivabalan/Bruckman/Raz) + label‑based port mapping (Ferguson) + RSVP‑TE signaling (RFC 3209) are each individually known, and step (c) — putting a port index into a label and decoding it downstream — is one of a small, finite set of predictable ways to make a downstream switch steer a labeled flow to a chosen member link.

Counterargument (Corrigent's, as reflected in the record): Raz allocates processor/subport bandwidth within an LSR, not link bandwidth between LSRs; the petition, Corrigent argued, offered mere conclusory "could be applied between LSRs" reasoning without explaining how the combination meets each limitation — and the PTAB (per Corrigent's sur‑reply) had "similar concerns" in the earlier Cisco proceeding. This is the crux on which the outcome turned.

Ground C — Sivabalan + Bruckman + Ferguson (an all‑examiner‑cited/admitted‑art combination)

If one prefers references that either appear on the '602's own face or are incorporated by the specification — which strengthens the "admitted prior art" framing — combine:

• Sivabalan (US 2005/0083928) for limitation (b): per‑LSP local admission control that assigns the LSP to a specific member link satisfying the LSP's bandwidth requirement, plus failover/revert (mapping to dependent claims 11‑12, e.g., swapping a failed component link for another in the bundle).
• Bruckman (US 2004/0228278) — named and incorporated by the '602 itself — for per‑link bandwidth allocation in an IEEE 802.3 LAG and for header‑hashing to map frames to member links (mapping to claim 8's "mapping function" and to the hashed-embodiment in the spec).
• Ferguson for the label‑bits‑encode‑port limitation (c) and the inter‑switch distribution.
• 801.3ad ordering rule (via Bruckman/Background) as the reason to keep an entire tunnel on one port and to make the label deterministically identify that port.

Why a POSITA combines these: Sivabalan and Bruckman solve the two halves of the same bandwidth‑on‑aggregated‑links problem (choosing a link that satisfies the flow's bandwidth requirement; allocating bandwidth across LAG members); Ferguson supplies the label‑as‑selector mechanism for the chosen path; RSVP‑TE is the standard signaling to carry the chosen label back upstream. None is more than the predictable use of a prior‑art element for its known function.

Ground D — Zelig + Bruckman/802.3ad + Ramia

• Zelig (US 2002/0110087) establishes carrying Ethernet/L2 services through label‑switched tunnels (the "Ethernet‑over‑MPLS" premise of the claims).
• Bruckman/802.3ad establish LAG mapping and ordering.
• Ramia (US 2005/0125490 A1), "Device and method for handling MPLS labels," is examiner‑cited and would be the natural reference for label construction/handling (potentially including label‑bit allocation). I could not retrieve its text, so I present this ground as conditional: it is obvious only if Ramia (or an equivalent) discloses label‑field/bit manipulation. Flagged as unverified.

VI. Dependent claims

Once claim 1 falls, the dependents largely fall with it, because each recites a conventional implementation or an admitted‑prior‑art feature:

• Cl. 3–5 (RSVP‑TE PATH + LABEL_REQUEST; guaranteed/peak bandwidth, CoS): directly RFC 3209 + the '602 Background/service‑property discussion.
• Cl. 6 (max available bandwidth) and Cl. 7 (minimum sufficient bandwidth): the specification's own two CAC strategies; both are routine load‑balancing heuristics, and Bruckman discusses exactly these trade‑offs.
• Cl. 8–10 (mapping function / bit extraction / lookup table): Bruckman's hash function (bit extraction) and the ordinary alternative of a lookup table — two predictable implementations of one concept.
• Cl. 11–12 (backup port; failover and revert): Sivabalan's link‑bundle protection (primary/secondary component link with bandwidth‑based selection and revert) and 802.3ad's protection mechanism.
• Cl. 13, 23–24 (LSR; network processor): admitted conventional hardware in the '602 itself ("implemented using a network processor").
• Cl. 14, 25 (treating the ports as a single logical port): the definition of a LAG in 802.3ad and Bruckman.

Claim 15 (apparatus) and claim 26 (method with express request + bandwidth requirement) track claim 1 with processor/mapper and request‑message framing; the same combinations apply, with Ferguson mapping to the "processor … publish said packet label upstream" and "mapper … detect said label" limitations.

VII. Motivation to combine — consolidated KSR rationales

1. Known elements, known methods. MPLS + RSVP‑TE, Ethernet LAG (802.3ad), per‑port bandwidth CAC (Bruckman/Sivabalan/Raz), and label‑based packet distribution (Ferguson) are all separately known; combining them yields only their predictable aggregate.
2. Same field / same problem. Every reference is in packet networking and addresses bandwidth reservation and deterministic forwarding over aggregated links.
3. Express teaching / "applicable to both" statement. Ferguson affirmatively teaches that its label‑range‑based distribution across aggregated‑link physical interconnects also applies to internal parallel paths — and the corollary the petitioner drew is that Raz's subport techniques likewise extend to links between LSRs.
4. Design choice with predictable result. Substituting a LAG for a single high‑speed link between nodes is a routine capacity choice; the benefit (increased usable bandwidth) is predictable.
5. Frame‑ordering constraint forces the architecture. 802.3ad requires all frames in a conversation over the same member port; since an MPLS label uniquely identifies a tunnel/flow, a POSITA is led directly to (i) pin the tunnel to one port and (ii) make the label deterministically encode/select that port — the essence of the claims.
6. Finite, predictable implementations of the selection step. Hash‑and‑extract (Bruckman), inverse‑hash (the '602's own FIG. 4 method), or label‑bit embedding (Ferguson) are a small, enumerated set, so selecting one is not inventive.
7. Reasonable expectation of success. All components were mature and interoperable by 2005 (RFC 3209/3031 predate priority by years; 802.3ad is 2002), so a POSITA would expect the combination to work.

VIII. The strongest non‑obviousness arguments (and how they cut)

• "Raz is intra‑device; the claims are inter‑switch." The real dispute. Ferguson's express "readily applied to internal … and vice versa" teaching is the counterweight. A tribunal that credits Ferguson as teaching inter‑device as well as intra‑device aggregation would likely find the combination reasonable; one that treats Raz as confined to internal subports could find a gap — which is precisely how the Board apparently viewed Ground 2 in the parallel proceeding (Corrigent's sur‑reply notes the Board had "similar concerns").
• "Ferguson uses label ranges/values, not a dedicated sub‑set of bits encoding a serial number." Ferguson's "allocated ranges of MPLS labels" is a label‑space selection, arguably not the literal "sub‑set of bits … encode said port serial number." This is the claim‑construction fault line (and mirrors the JMOL limitation on which the district court case turned). A narrow construction ("literal physical port serial number encoded in a designated bit field") narrows the § 103 exposure; a broad construction ("label encodes/bears the port identity") makes the combination clearly obvious.
• No secondary considerations in the record I retrieved. I found no evidence of unexpected results, long‑felt need, or a copy‑nexus. The patent's survival of the IPRs (see §IX) could be characterized as evidence of non‑obviousness, but only if tied to a nexus — I did not verify any such record.

IX. Record check — what actually happened at the PTAB (and a caveat)

• IPR2023‑00447 (Cisco v. Corrigent, US 9,118,602): instituted 2023‑08‑08; Final Written Decision (termination 2024‑08‑06). Cisco then appealed (Fed. Cir. 25‑1021), and the appeal was dismissed under Fed. R. App. P. 42(b) by the nonprecedential order dated 2025‑02‑14, each side bearing its own costs.
• IPR2023‑00839 (Arista v. Corrigent, US 9,118,602): instituted 2023‑12‑07; Final Written Decision (termination 2024‑12‑03); status "Final Written Decision – Appealed" (Fed. Cir. 25‑1424).

Caveat I must state plainly: I did not retrieve the substantive holdings of either FWD (which claims, if any, were cancelled vs. upheld). I therefore cannot state the merits outcome. Note only an inference one could draw: the petitioners (Cisco, Arista) were the appellants, which is consistent with the patent owner having prevailed (at least in part) — but that is an inference from party posture, not a verified holding, and an appeal by a petitioner is also consistent with a mixed outcome. Treat any "the claims survived" statement as unproven until the FWDs are read.

X. Conclusion and confidence

Bottom line. Under KSR, the subject matter of claims 1, 15 and 26 is reasonably susceptible to a § 103 challenge based on:

1. Raz + Ferguson + RFC 3209 + 802.3ad/Bruckman (the IPR2023‑00447 Ground 2 formulation, and Arista's Ground 2) — the strongest combination, because Ferguson both supplies the inter‑device bridge and the label‑driven port‑distribution limitation.
2. Raz alone (IPR2023‑00447 Ground 1) — plausible but contested, hinging on whether Raz's intra‑LSR subport aggregation can be read onto inter‑switch LAG ports.
3. Sivabalan + Bruckman + Ferguson — an attractive all‑examiner‑cited / admitted‑art variant, since Bruckman is named and incorporated in the '602 itself.

The decisive variable is claim construction of the "dedicating a sub‑set of bits … to encode said port serial number" limitation. Read narrowly (literal port serial number in a designated bit field), the obviousness case weakens and depends on Ramia/label‑handling art I could not verify. Read broadly (the label deterministically carries/identifies the selected port), the combination is compelling.

Confidence levels.

• High: the reference set, the claimed elements, the pre‑AIA framework, and the identification of the bit‑encoding limitation as the crux.
• Medium: that the IPR grounds, as pleaded, would have succeeded — because the PTAB's institution‑stage skepticism about the Raz‑to‑between‑switches leap, and Corrigent's "conclusory motivation" attack, are documented in the record, and the FWDs were appealed rather than accepted as final by the petitioners.
• Low / unverified: (i) the merits outcomes of both FWDs; (ii) the disclosure of the examiner‑cited Ramia reference; (iii) whether any secondary‑considerations evidence supports non‑obviousness; (iv) the current status of Fed. Cir. 25‑1424 and 25‑2036. I did not fabricate any of these; each is flagged rather than asserted.

Primary sources used: Google Patents US9118602B2 (patent text, citations, family data) — https://patents.google.com/patent/US9118602/en ; PTAB documents for IPR2023‑00447 and IPR2023‑00839 (petitions/sur‑replies identifying Raz, Ferguson, RFC 3209, RFC 3031, Bruckman) — https://ptacts.uspto.gov/ptacts/... ; CAFC order 25‑1021 — https://www.cafc.uscourts.gov/opinions-orders/25-1021.ORDER.2-14-2025_2468569.pdf ; US 2005/0083928 A1 / US 7,345,994 and US 2004/0228278 A1 full texts; W.D. Tex. Dkt. 345 (JMOL).