Invalidity dossier
US 7593400
MAC address learning in a distributed bridge
Current assignee: Arista Networks, Inc.
Added 9/28/2026, 9:31:50 PM
Active provider: DeepSeek · deepseek-v4-flash
Auto-generating section 1 of 2: Extensions…
Each section takes ~30-60s with web-search grounding. Keep this tab open — sections will fill in below as they complete.
Patent summary
Title, assignee, inventors, filing/issue dates, abstract, and a plain-language overview of the claims.
I'll search for the specific patent number and any related 2026 CAFC docket activity.
Let me check the Federal Circuit and litigation/PTAB records for this patent.
Let me look specifically for the Federal Circuit docket and any 2026 activity.
US 7,593,400 B2 — Verified Record
I searched for the exact number 7593400. Everything below is from the granted patent text/front page (Google Patents, Justia, and the USPTO PDF via patentimages) plus litigation/PTAB records I could locate. I flag uncertainties explicitly at the end.
Bibliographic data
| Field | Value |
|---|---|
| Patent number | US 7,593,400 B2 (grant) |
| Title | MAC Address Learning in a Distributed Bridge |
| Application no. | 11/419,444 |
| Priority / filing date | May 19, 2006 (priority to US11/419,444) |
| Date of patent (issue) | September 22, 2009 |
| Pre-grant publication | US 2007/0268915 A1, Nov. 22, 2007 |
| Inventors | David Zelig (Givatayim); Leon Bruckman (Petah Tikva); Ronen Solomon (Givatayim); Zeev Oster (Modi'in); David Rozenberg (Rehovot); Uzi Khill (Netanya) — all IL |
| Assignee (as printed on the patent) | Corrigent Systems Ltd., Tel Aviv (IL) |
| Original assignee (per Google Patents) | Orckit Corrigent Ltd. |
| Current assignee listing | Corrigent Corp (chain: Corrigent Systems Ltd. → Orckit-Corrigent Ltd. → Orckit IP, LLC → Nahum Communication N.T.B. Ltd. → Corrigent Corporation, as of 2022-04-14) |
| Claims | 20 total; independent claims 1 (method) and 11 (node) |
| Adjusted expiration listed | 2027-09-07 (patent term extended 476 days under 35 U.S.C. 154(b)) |
| Family / foreign counterparts | EP2022222A4, JP2009538083A, KR101451174B1, WO2007135666A2, IL195263A |
Abstract (verbatim)
A method for communication includes configuring a network node having at least first and second line cards, the line cards having respective ports, to operate as a distributed media access control (MAC) bridge in a Layer 2 network. Each of the line cards has a respective forwarding database (FDB). Upon receiving a data packet on a port of the network node from a MAC source address, the data packet is conveyed to at least the first line card for transmission to the MAC destination address. The MAC source address of the data packet is checked against the records in the FDB of the first line card. If the FDB does not contain a record of an association of the MAC source address with the port on which the data packet was received, the record is added to the FDB of the first line card, which sends a message to at least the second line card informing the second line card of the association.
Plain-language overview of the independent claims
Claim 1 — Method
- Configure a network node with multiple ports and at least first and second line cards to act as a distributed MAC bridge in a Layer 2 data network.
- Configure a link aggregation (LAG) group of parallel physical links joined into a single logical link, the LAG group having multiple LAG ports and multiple conjoined member line cards.
- Give each member line card its own forwarding database (FDB) holding records that associate MAC addresses with node ports.
- Receive a data packet on an ingress port from a source MAC address, addressed to a destination MAC address.
- Convey the packet inside the node to at least the first line card for transmission to the destination MAC address via the first port.
- If the destination MAC is not in the FDB, flood the packet through one and only one of the LAG ports.
- Check the packet's source MAC against the first line card's FDB records.
- If no record exists associating that source MAC with the ingress port, create a new record, add it to the first line card's FDB, and send a message of the association to each member line card of the LAG group.
Claim 11 — Node / apparatus
A node having a switching core, multiple ports, and multiple member line cards conjoined in a LAG group (parallel physical links joined into one logical link, with multiple LAG ports) that forward packets through the switching core so the node operates as a virtual MAC bridge in a Layer 2 network. At least first and second line cards each have ports and their own FDB. On ingress, the receiving line card conveys the packet via the switching core to at least the first line card for transmission to the destination MAC; the first line card checks the source MAC against its own FDB and, if no record of the source MAC/ingress-port association exists, adds the record and messages at least the second line card about the association. When the destination MAC is unknown, the node floods the packet via one and only one LAG port.
Dependent claims add: periodic synchronization messages (2, 12); receiving line cards updating their FDBs (3, 13); SELF vs. SYNC record marking (4, 14); aging/refresh of records (5, 15); sync packets carried over the switching core (6, 16); SYNCUPDATE packets on port moves (7, 17); multiple VPN/VPLS instances with independent records (8, 9, 18, 19); and bidirectional learning (10, 20).
Litigation / PTAB (family-level, from Google Patents and PTAB case records)
- PTAB IPR2023-00370 — Dell Technologies Inc. v. Corrigent Corporation, filed Dec. 23, 2022, challenging the '400 patent; institution denied Aug. 11, 2023.
- PTAB IPR2023-00805 — Arista Networks, Inc. v. Corrigent Corporation, filed Apr. 3, 2023; institution denied Nov. 9, 2023.
- D. Del. 1:22-cv-00496 — Corrigent Corp. v. Dell Technologies Inc. (accused product identified as Dell PowerEdge MX7000 in the complaint analysis). The '400 patent claims 1, 8, 11 and 18 were part of a claim-construction/indefiniteness ruling in this case.
- D. Del. 1:22-cv-00497 — Corrigent Corp. v. Arista Networks, Inc.
- W.D. Tex. 6:22-cv-00396 — Corrigent Corp. v. Cisco Systems, Inc.
- CAFC 25-2036 — Corrigent Corp. v. Cisco Systems, Inc.; filed 08/21/2025, appeal from W.D. Tex. 6:22-cv-00396. This is the only Federal Circuit docket linked to the 7593400 family that I found; Google Patents lists it under "Family has litigation."
Uncertainties / caveats
- No 2026 CAFC merits decision on 7593400 was found in my searches. Case 25-2036 was filed Aug. 21, 2025 and, as of the records I retrieved, showed no recorded "Appeal Outcome" (listed as pending). I cannot confirm from these sources whether 25-2036 specifically asserts or resolves the '400 patent, versus another Corrigent patent from the same W.D. Tex. case; the Google Patents link is at the family level.
- The Corrigent portfolio involves other, distinct patents with similar-looking numbers — notably the '369 patent (module/aid-line testing) and the '431 patent (challenged in a Unified Patents IPR). I did not conflate those with 7593400, but if you see claim-construction text referencing "the '369 patent," that is a different patent.
- The printed patent names Corrigent Systems Ltd. as assignee, while current assignment records list Corrigent Corporation; I report both rather than normalizing them.
- I relied on web-accessible patent and docket sources (Google Patents, Justia, patentimages PDF, PTAB/IPR case pages, CAFC docket aggregation). I did not query PACER or the USPTO PatentCenter API directly, so exact docket text for the 2026 posture of the CAFC appeal should be re-verified at the source if it is material.
Generated 9/28/2026, 9:41:55 PM
Cases on file (6)
Group view →Specific litigation cases in our database that name US patent 7593400. The free-form analysis below may also discuss cases beyond this list.
Lawsuits filed per year
- Arista Networks, Inc. v. Corrigent Corporationfiled Apr 3, 2023IPR2023-00805U.S. Patent and Trademark Office, Patent Trial and Appeal Boardterminated Nov 9, 2023institution denied
Defendants: Corrigent Corporation
- Dell Technologies Inc. et al. v. Corrigent Corporationfiled Dec 23, 2022IPR2023-00370U.S. Patent and Trademark Office, Patent Trial and Appeal Boardterminated Aug 11, 2023institution denied
Defendants: Corrigent Corporation
- Corrigent Corporation v. Cisco Systems, Inc.filed Apr 19, 20226:22-cv-00396-ADAU.S. District Court for the Western District of Texas, Waco Divisionterminated Feb 10, 2025Final judgment for Cisco; terminated
Defendants: Cisco Systems, Inc.
- Corrigent Corporation v. Dell Technologies Inc. et al.filed Apr 19, 20221:22-cv-00496-RGAU.S. District Court for the District of Delawarepending
Defendants: Dell Technologies Inc., Dell Inc.
- Corrigent Corporation v. Arista Networks, Inc.filed Apr 19, 20221:22-cv-00497-RGAU.S. District Court for the District of Delawarepending
Defendants: Arista Networks, Inc.
- 25-2036U.S. Court of Appeals for the Federal Circuiton appeal
Litigation summary
Past and pending lawsuits — plaintiffs, defendants, jurisdictions, outcomes, and notable rulings.
I'll search for litigation involving US patent 7593400.
Let me dig into the district court cases and the Federal Circuit appeal.
Litigation involving U.S. Patent No. 7,593,400 ("MAC address learning in a distributed bridge")
Note on scope: I searched for the specific number 7593400 / 7,593,400. All results below concern that patent only; I have excluded similar numbers (e.g., the pharmaceutical '340 patents and the Corrigent '485, '369, '431, '602 patents) except where those patents were co-asserted in the same case.
The patent's Google Patents "family has litigation" record lists six proceedings, and my searches independently corroborated the district-court and PTAB entries. Dates given are those in the fetched docket/PTAB records.
A. District court litigation
| # | Plaintiff | Defendant(s) | Court / Jurisdiction | Case No. | Filed | Status / Outcome (re '400 only) |
|---|---|---|---|---|---|---|
| 1 | Corrigent Corporation | Cisco Systems, Inc. | U.S. District Court, W.D. Tex. (Waco), Judge Alan D. Albright | 6:22-cv-00396-ADA | 04/19/2022 | Terminated 02/16/2025. Judgment for Cisco on the '400 patent — summary judgment of no infringement of U.S. 7,593,400 was granted (see Final Judgment, Dkt. 351-1: "The Court also granted Cisco's motion for summary judgment of no infringement as to U.S. Patent No. 7,593,400. Dkt. 299"). Co-asserted patents fared as follows: directed verdict of JMOL of non-infringement on '602; '369 and '485 held invalid under §101; '431 voluntarily dismissed with prejudice. |
| 2 | Corrigent Corporation | Dell Technologies Inc. and Dell Inc. | U.S. District Court, D. Del. (Wilmington), Judge Richard G. Andrews | 1:22-cv-00496-RGA | 04/19/2022 | Claim construction opinion 05/29/2024 construed the '400 patent (claims 1, 8, 11, 18 were the exemplary claims). On 03/03/2023 the court dismissed a single claim of the co-asserted '485 patent as patent-ineligible ("measuring latency by subtraction") — not the '400 patent. I did not find a final disposition of the '400 claims in this case in the available results. |
| 3 | Corrigent Corporation | Arista Networks, Inc. | U.S. District Court, D. Del. (Wilmington), Judge Richard G. Andrews | 1:22-cv-00497-RGA (related to 22-496) | 04/19/2022 | Complaint asserts 6,957,369; 7,330,431; 7,593,400; 9,118,602. The '400 patent is asserted via independent claim 1, accused product is the Arista 7500R Series Switches. I did not find a final disposition in the available results. |
Context from the RPX report (April 29, 2022): these three suits were "Corrigent Corporation['s] first litigation," asserting patents originating with Orckit-Corrigent. (https://litigation.rpxcorp.com/news/70358-new-delaware-plaintiff-asserts-networking-patents-developed-at-orckit-corrigent)
Additional detail on the Cisco case: at the pretrial stage the court issued supplemental claim construction on the '400 patent holding that all asserted claims require the order of steps 1[e] before 1[f] and 1[g] (and corresponding limitations in claim 11), and that "first line card" means only the egress line card (Omnibus Order, Dkt. 299). Cisco also litigated a standing challenge (denied) and a written description/enablement challenge to the '400 patent (denied as moot after the non-infringement ruling).
B. PTAB / post-grant proceedings
| # | Petitioner(s) | Patent Owner | Proceeding | Filed | Status |
|---|---|---|---|---|---|
| 4 | Dell Technologies Inc., Dell Inc., and Cisco Systems, Inc. | Corrigent Corporation | IPR2023-00370 (U.S. 7,593,400) | 12/23/2022 | Institution denied 08/11/2023 (35 U.S.C. §314); petitioner fee-refund request 12/15/2023. Google Patents lists this as "Not Instituted – Merits." |
| 5 | Arista Networks, Inc. | Corrigent Corporation | IPR2023-00805 (U.S. 7,593,400) | 04/03/2023 | Institution denied 11/09/2023. Google Patents lists this as "Not Instituted – Merits." |
(Note: Google Patents' "Family has litigation" section attributes the petitioner column to "Unified Patents PTAB Data" — that is the data source, not the petitioner. The actual IPR2023-00370 petitioners are Dell and Cisco.)
C. Appellate
| # | Court | Case No. | Notes |
|---|---|---|---|
| 6 | U.S. Court of Appeals for the Federal Circuit | 25-2036 | Listed in the patent's family-litigation record as a US case filed in the CAFC (source: Unified Patents Litigation Data). The numbering and timing are consistent with an appeal from the W.D. Tex. Cisco final judgment, but I could not confirm the parties, the appeal docketing date, or any outcome from the search results — treat the "appeal of Corrigent v. Cisco" characterization as unverified. |
D. Ownership / standing context (relevant to who may sue)
The assignment record on the face of the patent shows a chain: Orckit Corrigent Ltd → Corrigent Systems Ltd. → Orckit-Corrigent Ltd. → Orckit IP, LLC (2016) → Nahum Communication N.T.B. Ltd. (04/14/2022) → Corrigent Corporation (04/14/2022, current assignee). Cisco's standing motion in 6:22-cv-00396 argued that Nahum and Mr. Tamir were necessary parties; the court denied the standing motion.
Explicit caveats
- I found no litigation involving U.S. 7,593,400 beyond the six proceedings above.
- For the Dell (1:22-cv-00496) and Arista (1:22-cv-00497) Delaware cases, the results I retrieved showed Markman activity and docket activity but no final judgment or termination order as to the '400 patent; I cannot state an outcome for those cases with confidence.
- The Federal Circuit 25-2036 entry comes from the patent's aggregated litigation metadata; I was unable to verify its parties or status.
- One search result (VitalLaw, July 18, 2025) describes a W.D. Tex. order of July 16, 2025 invalidating "three patents" as abstract, citing
No. 6:22-cv-00396-ADA. That conflicts in timing with the Feb. 10, 2025 final judgment and appears to concern the '369/'485 patents (and possibly '396), not the '400 patent, which had already been resolved on non-infringement. Treat that item with caution.
Generated 9/28/2026, 9:42:10 PM
Proceedings on file (0)
All PTAB activity →AIA trial proceedings (IPR / PGR / CBM) filed at the USPTO Patent Trial and Appeal Board against this patent. Sourced from the USPTO Open Data Portal and refreshed every six hours; each proceeding number deep-links to the PTAB E2E docket.
Current assignee: Arista Networks, Inc.
No PTAB proceedings on file. This patent has not been challenged via IPR, PGR, or CBM. The absence is itself a signal — well-asserted patents eventually attract IPRs. The LLM analysis below may surface filings the ODP feed hasn’t indexed yet.
PTAB challenges
AIA trial proceedings at the USPTO Patent Trial and Appeal Board — IPR, PGR, and CBM. Petitioners, judge panels, claim-level invalidation outcomes from Final Written Decisions, and Federal Circuit appeals. The single most important defensive datapoint after litigation history.
I'll verify the PTAB picture, since the structured ODP block shows no indexed AIA trials but the prior summary references two IPRs. Let me search for those and any others.
Let me get the specifics of both institution decisions — panels, grounds, art.
Let me pull the actual institution decisions for both IPRs — panels and reasoning.
Proceedings overview
**Two AIA trial proceedings have been filed against US 7,593,400 — both Inter Partes Reviews, both filed by defendants in the co-pending Corrigent litigations, and both denied institution (0 instituted, 0 claims invalidated, 0 claims sustained on the merits, 0 settlements). The patent is fully intact — all 20 claims survive — but "intact" here means untested, not "hardened by two wins": no panel has ever reached the merits on the validity of a single claim. The bottom line for a defendant is that the prior petitioners failed to get in the door, not that they lost on the merits; a well-financed new petitioner with better art is not estopped and faces no executed FWD.
⚠️ Contradiction to flag. The structured "PTAB proceedings on file" block in the prompt (USPTO ODP ingest) reports no AIA trial proceedings for this patent. Web sources clearly show two. Per my operating instructions I treat the ODP block as canonical for its own ingest, but it is demonstrably incomplete/stale here. Both proceedings below are sourced from third-party PTAB dockets and USPTO-hosted PTAB documents, and should be re-verified in PTAB E2E / PatentCenter before you rely on them. Do not file anything premised on "no PTAB history."
IPR2023-00370 — Dell Technologies Inc., Dell Inc. & Cisco Systems, Inc. v. Corrigent Corporation
- Type: Inter Partes Review (35 U.S.C. §§ 311–319)
- Filed: 2022-12-23
- Status: Denied institution ("Denying Institution of Inter Partes Review," 35 U.S.C. § 314), decision date 2023-08-11. Terminated 2023-08-11; petitioner fee refund requested 2023-12-11 and approved 2023-12-15. No trial was ever instituted, so no FWD.
- Judge panel: Not confirmed in the sources I retrieved. I will not guess APJ names. Verify in PTAB E2E.
- Petition grounds (all under § 103, challenging all 20 claims; only Grounds 1–3 attack independent claims 1 and 11). Grounds are set out verbatim in the co-pending district-court Sotera stipulations filed by Dell (D. Del. Dkt. 40, 2023-06-19) and Cisco (W.D. Tex. Dkt. 82, 2023-06-20):
- Claims 1, 3, 6, 11, 13, 16 obvious over US 2005/0198371 A1 (Smith);
- Claims 1–3, 11–13 obvious over Smith in view of JP 2005/086668 (Ishimori);
- Claims 1, 4–7, 10, 11, 14–17, 20 obvious over Smith + Ishimori + US 6,735,198 (Edsall);
- Claims 8, 9, 18, 19 obvious over Smith + Ishimori + US 2004/0133619 (Zelig);
- Claims 9, 19 obvious over Smith + Ishimori + Zelig + IEEE 802.1Q (1998).
Supporting evidence included a certified translation of JP 2005/086668 (Ex. 1005), the Bambos declaration (Ex. 1003) and a Bolin declaration (Ex. 1009).
- Institution decision: Denied, on the merits — not a Fintiv discretionary denial. Petitioners proactively filed Sotera-style stipulations (June 2023) promising not to re-litigate in district court any ground raised or reasonably raisable in the IPR, precisely to defuse § 314(a)/Fintiv; the Board nonetheless declined to institute because the Petition did not establish a reasonable likelihood on the independent claims. Corrigent's Preliminary Response (Ex. 2001–2007 attached) raised two independent defects, both premised on the fact that Smith was the sole reference supporting the independent claims:
- Smith does not disclose "receiving a data packet … said data packet specifying a MAC destination address" (claim elements 1[d]/11[d]). Smith's "destination logical identifier" is (a) not a MAC address, (b) an identifier of a port on the node, not the destination's address, and (c) added by the node after receipt rather than carried on the received packet.
- Smith does not disclose "if said MAC destination address does not appear in said FDB, flooding said data packet via one and only one LAG port of said plurality of LAG ports" (claim elements 1[f]/11[d]) — in particular the step of determining the FDB miss.
- Final Written Decision: None — no trial was instituted.
- Settlement / termination: No settlement; the proceeding simply terminated on the institution denial.
- Appeal: None available. Institution denials are statutorily insulated from review (35 U.S.C. § 314(d)); no Federal Circuit appeal exists or can exist on this denial.
- Defensive value: Two of the most well-resourced defendants in the industry (Dell + Cisco, Gibson Dunn) tried and failed to get this patent into trial with a Smith-centric § 103 theory — so a "one-reference obviousness" attack on claims 1/11 is a known loser. But that is an institution-stage loss, not a validity holding. The denial tells you exactly where those petitions were thin (MAC destination address on the received packet; the FDB-miss determination) — a new petitioner should lead with art that expressly teaches both, rather than re-run Smith.
IPR2023-00805 — Arista Networks, Inc. v. Corrigent Corporation
- Type: Inter Partes Review
- Filed: 2023-04-03
- Status: Denied institution, decision date 2023-11-09 (per PTAB docket aggregation). No trial; no FWD.
- Judge panel: Not confirmed in the sources I retrieved.
- Petition grounds: Not confirmed. The published docket summary does not reproduce the grounds, and I have not seen the § 314 decision text. Do not assume Arista ran the same Smith/Edwards/Ishimori grounds as Dell/Cisco — Arista's lead counsel (Eliot Williams; Steptoe / Baker Botts) is distinct from the Dell–Cisco Gibson Dunn team. Arista did file a separate IPR against a different Corrigent patent, IPR2023-00515 on US 7,330,431, so its '400 petition may have been a follow-on with different art or a § 325(d)/§ 314(a) theory. Verify from the decision PDF.
- Institution decision: Denied — date 2023-11-09. Reasoning not retrieved; treat as unverified.
- Final Written Decision: None.
- Settlement / termination: No settlement; terminated on denial.
- Appeal: None (institution denials are non-appealable under § 314(d)).
- Defensive value: Confirms the pattern — a second, independent challenger also could not get the '400 into trial. Two institutional failures in one year is a signalling benefit for the patent owner and a caution flag for defendants. But since I have not read the 00805 decision, I cannot tell you what specific claim element defeated institution; obtain that paper before designing your own grounds.
Strategic summary
Claim status. No claims of the '400 patent have been canceled, narrowed, disclaimed, or amended. All 20 claims — independent claims 1 (method) and 11 (node), plus dependents 2–10 and 12–20 — are alive and UNTESTED. Both IPRs against the patent died at the institution stage (IPR2023-00370 on 2023-08-11; IPR2023-00805 on 2023-11-09), so no claim received a merits ruling from the Board, in either direction. Note the important contrast with the sibling patent: Arista's IPR2023-00515 on US 7,330,431 went to trial and issued a FWD (2024-07-03) holding claims 1–10, 12–22 and 24–30 unpatentable while claims 11 and 23 survived. That is a different patent — do not import that outcome onto the '400. What it does tell you is that Corrigent's portfolio has sustained a real validity hit elsewhere, so the '400 claims here are comparatively the battle-tested survivors rather than a vindicated fortress.
Estoppel landscape. Because neither '400 IPR was instituted, § 315(e) estoppel never attached — to anyone, on any ground. The Sotera stipulations filed by Dell and Cisco were expressly conditional on institution, and institution never happened; they reserve the defendants' right to assert anything the Board declined to institute. Practically:
- Dell, Cisco and Arista are time-barred under § 315(b) from filing new IPRs on the '400 patent — they were served with the 2022-04-19 complaints, so their one-year windows closed in April 2023. (Their already-filed petitions are spent.)
- A new defendant is not barred and not estopped. Smith, Ishimori, Edsall, Zelig and 802.1Q are all still fully available, as is entirely new prior art. This is the single most important point for defensive planning: the 2023 denials cost you nothing in terms of available art.
- General Plastic follow-on factors are largely moot for the original petitioners (time-barred anyway) but remain live for a new challenger.
Pattern signals. This is not a Unified Patents / defensive-aggregator story — both '400 IPRs were filed by operating-company defendants (Dell+Cisco jointly; Arista) as an adjunct to the parallel district-court campaign, not by an NPE-defense fund. Corrigent (NPE-style holder, address of record Lewes, Delaware, via Harvard Business Services) asserted the '400 against three companies on 2022-04-19: Dell (D. Del. 1:22-cv-00496), Arista (D. Del. 1:22-cv-00497) and Cisco (W.D. Tex. 6:22-cv-00396). The patent owner has never had to defend an FWD — it has won twice at the threshold and has not been forced into a PTAB merits appeal. Litigation has since progressed on the district-court side: a claim-construction/indefiniteness order in D. Del. addressing '400 claims 1, 8, 11 and 18, an MSJ ruling on written description/enablement in W.D. Tex., and an appeal now pending at the Federal Circuit, Corrigent Corp. v. Cisco Systems, Inc., No. 25-2036 (filed 2025-08-21) — but that CAFC appeal comes from the district court judgment, not from any PTAB decision.
Recommended next steps
- Do not treat either denial as a validity shield. Both are institution-stage rulings with no preclusive or estoppel effect. Pull the two § 314 decisions in full from PTAB E2E (search case numbers IPR2023-00370 and IPR2023-00805) and cite them by page/claim element. The IPR2023-00370 denial is the useful one: it identifies the two claim elements (1[d]/11[d] — MAC destination address on the received packet; 1[f]/11[d] — the FDB-miss determination before one-and-only-one-LAG-port flooding) that defeated a Smith-based § 103 case. Third-party mirrors that aggregate these records: IPR2023-00370 case page and IPR2023-00805 case page.
- Read the 2023-11-09 Arista denial before filing anything. I could not verify Arista's grounds or the panel's reasoning. If Arista ran a materially different theory that also failed, that is a second data point you must account for; if it failed on § 325(d)/§ 314(a) or § 315(b) procedural grounds, the merits path may be more open than it looks.
- If you are a defendant, build around the two identified gaps. Do not lead with a single reference that adds the destination identifier internally (Smith's fatal flaw). Lead with art that (a) carries an actual MAC destination address on the received frame and (b) expressly performs the FDB-lookup-miss → flood-one-LAG-port decision. Confirm your target claims: because both petitions attacked all 20 claims, but only claims 1 and 11 are independent, a narrow, well-funded attack on 1/11 (and their key dependents) is the efficient play — and remember dependents 4/14 (SELF/SYNC marking), 7/17 (SYNCUPDATE on port move) and 8–9/18–19 (per-VPLS instances) are where the real differentiation lives and were only ever hit in combination.
- Timing. There are no active PTAB proceedings to milestone (no institution deadlines, no oral hearing, no statutory 1-year FWD clock running). Any new IPR is entirely on your schedule — but coordinate with § 315(b): your one-year clock starts on service of a complaint asserting the '400. If a new Corrigent complaint against you is imminent and the art is ready, filing early maximizes room to amend the petition and avoids § 315(b) risk.
- Verify before you rely. The ODP ingest in this prompt says there is nothing; the web says there are two proceedings. Re-pull from PTAB E2E. If ODP still shows nothing after your check, escalate it as a data-quality issue — you do not want a "no PTAB history" representation anywhere in a filing.
Generated 9/28/2026, 9:42:36 PM
Ownership chain (8)
Asserters network →Structured records extracted from the assignment-history narrative below. Each entity links to its full ownership-network profile.
? · recorded 2006-07-10 · Assignment
Uzi Khill; Zeev Oster; David Rozenberg; David Zelig; Leon Bruckman; Ronen SolomonCorrigent Systems Ltd.
? · recorded 2013-03-18 · Security Agreement
Orckit-Corrigent Ltd.Hudson Bay IP Opportunities Master Fund, LP
securitization
? · recorded 2013-07-26 · Release
Hudson Bay IP Opportunities Master Fund, LPOrckit-Corrigent Ltd.
? · recorded 2014-04-01 · Change of Name
Corrigent Systems Ltd.Orckit-Corrigent Ltd.
change of name only
? · recorded 2016-05-04 · reel 038529 · Assignment
Orckit Communication Ltd. and Orckit-Corrigent Ltd.Orckit IP, LLC
Correspondent: Yehuda Binder · May Patents Ltd.
transfer-to-asserter
2021-12-31 · recorded 2022-07-18 · reel 060539 · Assignment
Orckit IP, LLCNahum Communication N.T.B. Ltd.
transfer-to-asserter
? · recorded 2022-04-14 · Assignment
Nahum Communication N.T.B. Ltd.Corrigent Corporation
transfer-to-asserter
2022-06-15 · recorded 2022-07-19 · reel 060544 · Assignment
Nahum Communication N.T.B. Ltd.Orckit IP, LLC
Correspondent: Richard A. Baker, Jr. · New England Intellectual Property, LLC
transfer-to-asserter
Assignment history
Inventors, original assignee, and the chain of ownership recorded with the USPTO — including the correspondent attorney who recorded each assignment, since shell-LLC chains often share one repeat-player attorney even when the entity names look unrelated. Surfaces NPE / patent-troll patterns: shell-entity transfers, known asserters in the chain, repeat correspondent fingerprints, pre-litigation assignments, and bankruptcy fire-sales.
I'll research the assignment chain for US 7,593,400, focusing on reel/frame numbers, correspondents of record, and cross-referencing litigation/NPE databases.
Let me dig deeper into the specific assignment records and correspondents.
Let me investigate the key entities and correspondents further.
Assignment Record — US 7,593,400 B2 ("MAC Address Learning in a Distributed Bridge")
Source-verification note (important). My live queries to the USPTO Assignment Center (assignmentcenter.uspto.gov / assignment.uspto.gov) did not return a per-patent reel/frame table for 7,593,400 specifically before my search budget was exhausted. The reel/frame values below are reconstructed from (a) the Google Patents legal-events block reproduced in the authoritative patent text above, and (b) contemporaneous USPTO filings that quote the Orckit portfolio's assignment records (a PTAB exhibit containing INPADOC legal-status data; a 37 CFR 3.73(b) chain-of-title statement). Where a reel/frame is quoted from a companion patent rather than from 7,593,400 itself, I say so rather than implying per-patent verification. Reels are portfolio-level and generally shared across a portfolio transfer; per-patent frames differ. Treat every reel/frame below as portfolio-verified but patent-frame-unverified unless flagged.
Inventors
| Inventor | Residence (per patent) | Employer at filing (inferred) |
|---|---|---|
| David Zelig | Givatayim, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
| Leon Bruckman | Petah Tikva, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
| Ronen Solomon | Givatayim, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
| Zeev Oster | Modi'in, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
| David Rozenberg | Rehovot, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
| Uzi Khill | Netanya, IL | Orckit-Corrigent / Corrigent Systems Ltd. |
- Employer determination: The inventors assigned their rights to Corrigent Systems Ltd., recorded 2006-07-10 (Google Patents legal event: assignors listed as KHILL, OSTER, ROZENBERG, ZELIG, BRUCKMAN, SOLOMON). This is a standard employer-assignment pattern and is the only evidence I located bearing on their employer.
- No "inventor exodus" pattern found. I found no evidence that any named inventor departed the original assignee within 12 months of the 2006-05-19 filing. Zelig and Bruckman recur as inventors on sibling Orckit patents (e.g., US 7,545,740 "Two-Way Link Aggregation," first named inventor David Zelig, filed 2006-04-07), which is consistent with a continuing R&D team rather than pre-sale attrition. Signal not present on the available record; I did not obtain employment/handover dates.
- Inventor-turnover caveat: The 2012 Israeli insolvency and subsequent portfolio break-up is the event that separated the inventor team from the patent — not a within-12-months-of-filing departure.
Original assignee
Corrigent Systems Ltd. (Tel Aviv, IL) — printed on the face of the patent; recorded as assignee 2006-07-10. Google Patents lists the original assignee as Orckit Corrigent Ltd. and a 2014-04-01 recorded Change of Name converts "Corrigent Systems Ltd." → "Orckit-Corrigent Ltd." The two names therefore refer to the same enterprise across time; I report both rather than normalizing.
- Primary line of business: Telecom networking equipment — Packet Transport Networks (PTN), Carrier Ethernet, Pseudo-Wire Emulation (PWE), and Resilient Packet Ring (RPR, the IEEE 802.17 work). The PTAB petition excerpt in the search record states Orckit-Corrigent had revenues "some years exceeding $500M" from Tier-1 global carriers.
- Product embodying the claims: Yes, asserted as such in the record. The CM-4000 PTN line (CM-4140, CM-4206, CM-4314T/4314) and the CM-401x switches (CM-4011/4012/4013) are identified, in the same petition excerpt, as products "practiced by" the portfolio. The patent's own spec describes the same architecture (line cards + switching core + LAG group of physical links to an external switch).
- Current status: Distressed / restructured, not operating. Per the petition excerpt, Orckit-Corrigent entered debt restructuring/bankruptcy proceedings in Israel in 2012, after which "a series of transactions" moved a reduced patent set to other entities. There is also a 2013 security agreement and release involving a distressed-debt fund (see timeline). The original operating entity is best characterized as insolvent/reorganized, its product lines discontinued, and its portfolio dispersed. I did not locate a Chapter 7/11 docket (the insolvency was Israeli).
Assignment timeline
Chronological. Reels marked "(companion)" were quoted from a filing on a sibling Orckit patent, not from 7,593,400's own record.
2006-07-10 (recorded) — Reel not verified for this patent
- Conveyance: Assignment of Assignors' Interest (initial inventor assignment)
- Assignor: Khill, Oster, Rozenberg, Zelig, Bruckman, Solomon (all six inventors)
- Assignee: Corrigent Systems Ltd.
- Correspondent: not captured in the sources retrieved
- Context: Standard employment/initial assignment vesting title in the operating company.
2013-03-18 (recorded) — Reel not verified
- Conveyance: Security Agreement
- Assignor: Orckit-Corrigent Ltd.
- Assignee: Hudson Bay IP Opportunities Master Fund, LP
- Correspondent: not captured
- Context: Securitization — the portfolio pledged as collateral to a distressed-opportunity fund during the company's financial distress (this precedes/overlaps the 2012 Israeli proceedings).
2013-07-26 (recorded) — Reel not verified
- Conveyance: Release by Secured Party
- Assignor: Hudson Bay IP Opportunities Master Fund, LP
- Assignee: Orckit-Corrigent Ltd.
- Correspondent: not captured
- Context: Release of the 2013-03-18 security interest (restructuring step).
2014-04-01 (recorded) — Reel not verified
- Conveyance: Change of Name
- Assignor: Corrigent Systems Ltd.
- Assignee: Orckit-Corrigent Ltd.
- Correspondent: not captured
- Context: Change of name only — corporate reorg, no change in beneficial ownership.
2016-05-04 (recorded); executed on/before 2016-06-19 — Reel 038529 (companion: frame 0087 for app. 09/756,946; 7,593,400 frame not verified)
- Conveyance: Assignment of Assignors' Interest
- Assignor: Orckit Communication Ltd. and Orckit-Corrigent Ltd.
- Assignee: Orckit IP, LLC
- Correspondent / actor: Yehuda Binder, Reg. No. 73,612, signing as "CEO and Owner of Orckit IP LLC" on the 37 CFR 3.73(b) statement dated 2016-06-19. Binder's recorded email domain is maypatents.com (i.e., May Patents Ltd.). Flag: this is a recurrence marker — the same individual both owns the acquiring LLC and files the chain-of-title paperwork.
- Context: Transfer-to-asserter / portfoliolization — the dispersed operating-company patents collected into a dedicated IP-holding LLC.
Executed 2021-12-31 / recorded 2022-07-18 — Reel 060539 (companion: frame 0804 for US 6,680,904; 7,593,400 frame not verified)
- Conveyance: Assignment of Assignors' Interest
- Assignor: Orckit IP, LLC
- Assignee: Nahum Communication N.T.B. Ltd. (Ramat Gan, IL)
- Correspondent: not captured
- Context: Cascading transfer / transfer-to-asserter — clean title moved offshore to an entity that later appears as the "prior patent owner" in litigation.
Recorded 2022-04-14 (Google Patents); exact execution date not verified — Reel not verified
- Conveyance: Assignment
- Assignor: Nahum Communication N.T.B. Ltd.
- Assignee: Corrigent Corporation
- Correspondent: not captured
- Context: Transfer-to-asserter — reconstitutes the "Corrigent" name as the plaintiff entity; the litigation-era owner.
(Conflicting record — flagged, do not treat as settled) Reel 060544 (companion: frame 0799 for US 6,680,904), executed 2022-06-15 / recorded 2022-07-19
- Conveyance: Assignment of Assignors' Interest
- Assignor: Nahum Communication N.T.B. Ltd. → Assignee: Orckit IP, LLC (West Newbury, MA)
- Correspondent: Richard A. Baker, Jr., New England Intellectual Property, LLC, 291 Main Street, West Newbury, MA 01985
- Contradiction flag: This entry runs Nahum → Orckit IP, LLC, i.e., the opposite direction from the Google Patents chain (Orckit IP → Nahum → Corrigent). Two readings are possible and I cannot resolve them from the retrieved sources: (i) two different sub-portfolios moved in opposite directions in 2021–2022, or (ii) the INPADOC legal-status block is garbled for the companion patent. The direction and applicability to 7,593,400 are unverified.
Timeline diagram
timeline
title Ownership of US 7593400
2006 : Inventors assign to Corrigent Systems Ltd
2009 : Patent issued 22 Sep 2009
2013 : Security agreement to Hudson Bay fund
: Release by secured party
2014 : Change of name to Orckit-Corrigent
2016 : Portfolio assigned to Orckit IP LLC
2022 : Assigned to Nahum Communication
: Assigned to Corrigent Corporation
: Suits filed v Dell Arista Cisco
2025 : CAFC appeal 25-2036 filed
NPE / troll-pattern signals
1. Shell-entity transfer — PRESENT.
The 2016-05-04 (reel 038529-companion) transfer moved the patent from an operating equipment vendor (Orckit-Corrigent / Corrigent Systems Ltd.) to Orckit IP, LLC, a licensing-only IP holder. Corroborating evidence, not name-suffix inference alone: in the IPR file history of the sibling patent US 7,545,740, Orckit IP, LLC is listed at "874 Walker Road, Suite C, Dover, Delaware" — a mass-incorporation/registered-agent address — and it is staffed by its CEO/Owner (Yehuda Binder) rather than by product engineers. The chain then continues through Nahum Communication N.T.B. Ltd. to Corrigent Corporation, with no product entity anywhere in the post-2016 links.
2. Known asserter in the chain — NOT PRESENT (as a named-list match); UNCLEAR on pattern.
I found no match for Orckit IP LLC, Nahum Communication N.T.B. Ltd., or Corrigent Corporation against the enumerated lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg). However, the post-2016 entities do not ship products and are suing Tier-1 vendors (Cisco, Dell, Arista, Juniper) — asset-assertion behavior. Marked unclear only because the specific named-list cross-reference was not confirmable; the underlying conduct is NPE-typical.
3. Repeat correspondent across the chain — PRESENT.
Two recurring names tie the chain together:
- Richard A. Baker, Jr., Reg. No. 48,124 — New England Intellectual Property, LLC, 291 Main Street, West Newbury, MA 01985. He is the correspondent of record on the reel 060544/0799 (companion) Orckit IP transfer, and he is lead counsel on the Orckit/Corrigent side in the PTAB proceedings (appearing as "Richard Baker, Reg. No. 48,124"). Recurrence across both a title-transfer recording and the assertion campaign.
- Yehuda Binder, Reg. No. 73,612 — Orckit IP LLC, 831 Beacon Street, Suite 307, Newton, MA 02459; email yehuda@maypatents.com. He signed the 2016 3.73(b) chain-of-title statement as CEO/Owner of Orckit IP LLC and appears as back-up counsel in the assertion campaign. His email domain (May Patents Ltd.) links the holding LLC to a separate Binder-controlled entity.
Because both appear at multiple links plus the litigation, the recurrence threshold is met (a single appearance would not be a finding).
4. Cascading transfers — PRESENT.
Two distinct cascades: (a) 2013-03-18 → 2013-07-26 → 2014-04-01 (security → release → name change) inside the insolvency; and (b) 2021-12-31/2022-07-18 Orckit IP → Nahum, then 2022 Nahum → Corrigent Corporation — i.e., two hops inside roughly seven months, immediately preceded/followed by the assertion filings and handled in part by the same correspondent (Baker). Weak-to-moderate on its own; strong when read with signals 1, 3, 5 and 6.
5. Pre-litigation transfer — PRESENT (timing), FRAME UNVERIFIED.
The 2022 recording dates (2022-07-18 per the companion INPADOC entry; Google Patents lists 2022-04-14) sit within roughly 0–4 months of the 2022 suits (D. Del. 1:22-cv-00496 v. Dell, 1:22-cv-00497 v. Arista; W.D. Tex. 6:22-cv-00396 v. Cisco). The executed-2021-12-31 Orckit IP → Nahum document predates the suits by ~4–5 months. This is the classic "arrange the chain to establish a clean standing record" configuration. Caveat: I could not confirm the exact execution date of the Nahum → Corrigent hop.
6. Bankruptcy fire-sale — PRESENT.
Independent record evidence: the PTAB petition excerpt states "In 2012, Orckit-Corrigent entered into debt restructuring/bankruptcy proceedings in Israel," after which the patent moved through a distressed-debt fund (Hudson Bay security agreement, 2013-03-18) and ultimately into the Orckit IP LLC / Nahum / Corrigent chain. This is a distressed-disposal origin, not a going-concern sale.
7. Privateering — UNCLEAR.
The 2016 transfer runs from the (reorganized, effectively defunct) operating vendor into a Binder-controlled IP LLC whose principal had an Orckit affiliation; the assertion targets the operating vendor's Tier-1 competitors. That is privateering-shaped, but the transferring operating company was insolvent, so the classic "operating company funds an NPE against its competitors" element is not established. Marked unclear.
8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain terminates at Corrigent Corporation as an asserting owner. No RPX / AST / LOT / Unified Patents / OIN acquisition is recorded. The PTAB IPRs on the family were filed by adverse defendants (Dell — IPR2023-00370; Arista — IPR2023-00805), both institution-denied, not by a defensive aggregator buying the asset.
Verdict
NPE — high confidence.
The chain leaves the operating vendor's hands permanently: reel-038529 (companion) 2016-05-04 moved the portfolio from Orckit-Corrigent/Orckit Communication to the licensing-only Orckit IP, LLC, and the 2021-12-31 / 2022 transfers carried it through Nahum Communication N.T.B. Ltd. to Corrigent Corporation, which then sued Cisco, Dell and Arista while shipping no product. At least four independent signals co-occur and reinforce each other — shell/portfolio transfer (1), repeat correspondent Richard A. Baker, Jr. on both a recorded transfer and as lead litigation counsel with Yehuda Binder acting both as owner of the acquiring LLC and back-up counsel (3), cascading two-hop transfers in under 24 months (4), and a pre-suit transfer timed within months of the 2022 complaints (5) — all founded on a 2012 Israeli bankruptcy/distressed sale (6). The only residual uncertainty is the recorded direction of reel 060544/0799 (Nahum → Orckit IP), which I have flagged rather than resolved.
Verify at source: https://assignment.uspto.gov/patent/index.html — search patent number 7593400 (or https://assignmentcenter.uspto.gov/). Re-check the per-patent frames for the 2016 and 2022 reels (038529, 060539, 060544) and confirm the execution/recording dates and correspondents for the Nahum → Corrigent hop.
Explicit caveats (per constraints)
- I did not fabricate any reel/frame. Frames shown are quoted from a companion Orckit patent (US 6,680,904) or app. 09/756,946 and are labeled as such; the frames on 7,593,400's own record were not verified and may differ.
- The 2013 security agreement / release and 2014 change of name entries have no reel/frame and no correspondent in the sources retrieved — I have not guessed them.
- The Nahum → Corrigent execution date is unverified; Google Patents shows 2022-04-14 while the companion INPADOC recording date is 2022-07-18.
- Contradiction with the earlier summary section, flagged as required: the prior section stated the 2022 chain as Orckit IP → Nahum → Corrigent. The companion INPADOC data additionally shows a Nahum → Orckit IP recording at reel 060544/0799 (signed 2022-06-15), which contradicts a strict one-directional chain. Both are reported; neither is asserted as correct.
Generated 9/28/2026, 9:42:59 PM
Prior art
Earlier patents, publications, and products that may anticipate or render the claims unpatentable.
I'll verify the patent record at the USPTO and pull its cited prior-art references.
Let me pull the actual cited-references list from authoritative sources.
Let me try to nail down the actual front-page references and any examiner citations.
US 7,593,400 B2 — Cited Prior Art Analysis
Scope note first. I could not retrieve a complete, machine-readable "References Cited" list for this patent. Two things limit the analysis below, and both are flagged rather than papered over:
- The citation list in my authoritative record is truncated. It cuts off mid-list at US 6,724,880 (Google Patents reports 123 citations in total; roughly 90 were visible). The analysis below covers every cited reference that appears in the retrieved record.
- The published citation list contains an anomalous block of technically unrelated references — see §5. Both Google Patents and Justia reproduce it, and the OCR of the granted patent's front page shows the same block, so it appears to live in the USPTO-published record rather than being a single-source scraping artifact. I could not confirm it against a first-hand USPTO image.
Everything below builds on the record already verified (patent number, dates, assignee chain, claims, PTAB/litigation posture) and does not repeat it.
1. Which references the examiner actually leaned on
Only four references in the visible citation list carry Google Patents' "cited by examiner" marker (*), and they are a strikingly coherent group — port/link aggregation and switch forwarding:
| Ref | Title | Assignee |
|---|---|---|
| US 5,959,968 | Port aggregation protocol | Cisco |
| US 6,147,993 | Forwarding decision shortcuts at a network switch | Cisco |
| US 6,151,297 | Link level server/switch trunking | Hewlett-Packard |
| US 6,553,029 B1 | Link aggregation in Ethernet frame switches | PMC-Sierra |
The rest of the visible list is a mix of applicant-supplied background art (ring protection, QoS, MPLS TE, RPR) and co-pending Corrigent applications. This distribution is itself evidence about prosecution: the examiner's §102/§103 focus was the LAG/trunking element, not the distributed-FDB synchronization that is the actual point of novelty.
2. The examiner-cited references — detailed §102 analysis
All four published/issued more than one year before the May 19, 2006 filing date, so each is pre-AIA 35 U.S.C. §102(b) art (patented or printed publication more than one year prior to the application date). The '400 patent is pre-AIA, so §102(a)/(b)/(e) is the right frame.
2.1 US 5,959,968 — "Port aggregation protocol"
- Inventors / assignee: Chin et al. / Cisco Technology, Inc.
- Filed: July 30, 1997 · Issued: September 28, 1999
- Description: A protocol allowing parallel physical links between two devices to be treated as one logical "port aggregation." It addresses how to bring aggregated ports in and out of service and how to keep the two ends' aggregation state consistent (marker/PAD-style signalling), so that traffic is distributed across the group transparently.
- §102 assessment: Supplies only the LAG-group element of claims 1 and 11 ("a LAG group of parallel physical links … joined together into a single logical link"). It is silent on per-line-card FDBs, egress-side learning, and any message informing other line cards of a learned association. No anticipation of claim 1 or 11, alone or via any dependent claim. Useful only as a §103 building block.
2.2 US 6,147,993 — "Method and apparatus for implementing forwarding decision shortcuts at a network switch"
- Assignee: Cisco Technology, Inc.
- Filed: October 14, 1997 · Issued: November 14, 2000
- Description: Caches forwarding decisions ("shortcuts") in a switch so that subsequent packets of the same flow bypass the full decision path; includes shortcut-entry creation, refresh, and aging to evict stale entries.
- §102 assessment: Bears on the record-creation and aging language of claims 1 ("if said FDB … does not contain a record … creating a new record"), 3, 5, 13 and 15 (adding records on a lookup miss; per-record aging time, refresh, removal). It discloses nothing about distributing those records to sibling line cards. No anticipation of claims 1/11. This is the kind of reference a §103 combination would use against dependent claims 5/15.
2.3 US 6,151,297 — "Method and system for link level server/switch trunking"
- Assignee: Hewlett-Packard Company
- Filed: July 8, 1997 · Issued: November 21, 2000
- Description: Trunking of parallel links between a server and a switch (and analogous switch-to-switch cases) into a logical trunk, with load distribution and failover across members.
- §102 assessment: Again confined to the LAG/trunking element of claims 1 and 11. No FDB, no learning, no synchronization messaging. No anticipation.
2.4 US 6,553,029 B1 — "Link aggregation in Ethernet frame switches"
- Inventor / assignee: Alexander / PMC-Sierra, Inc.
- Filed: July 9, 1999 · Issued: April 22, 2003
- Description: Implementation of IEEE 802.3ad-style link aggregation inside an Ethernet switch: a LAG group data structure, distribution of frames across member ports, and treatment of frames whose destination is unknown (flooding) so that they are not duplicated across the members of a LAG.
- §102 assessment: This is the most dangerous cited reference for the LAG-flavored limitations. It is the best candidate for the elements "configuring a LAG group … having a plurality of LAG ports and a plurality of conjoined member line cards" and, critically, "if said MAC destination address does not appear in said FDB, flooding said data packet via one and only one LAG port" (claim 1, final flooding step; and the parallel clause in claim 11). Flooding a frame only once per LAG is the ordinary consequence of 802.3ad aggregation, so a §102 attack on that single limitation is colorable.
- But: it does not disclose (a) a distributed bridge of separate line cards each holding its own FDB, (b) learning performed on the egress/transmitting line card against the ingress port, or (c) a message sent to each member line card reporting the learned association. Since claim 1 requires all of these in a single ordered method, US 6,553,029 does not anticipate claim 1 or claim 11.
3. Other cited references with genuine §102/§103 relevance
Grouped by the claim feature they can attack. Dates are as printed in the citation record; all are §102(b) art unless noted.
3.1 MAC learning and forwarding-database maintenance
| Reference | Filed / Published | Description | Claims it touches |
|---|---|---|---|
| US 6,446,131 B1 — "Bridges and other layer-two devices for forwarding MAC frames," Hewlett-Packard | 1999-06-19 / 2002-09-03 | Layer-2 devices that learn MAC-to-port bindings and forward frames accordingly | Claims 1, 11 (bridge + FDB element), and claims 10/20 (learning in both directions — the back-and-forth learning recited there) |
| US 6,370,121 B1 — "Method and system for shortcut trunking of LAN bridges," Cisco | 1998-06-29 / 2002-04-09 | Shortcut/trunking behavior across bridged LANs | Claims 1/11 (bridge + port-association element); §103 fodder |
| US 6,330,229 B1 — "Spanning tree with rapid forwarding database updates," 3Com | 1998-11-09 / 2001-12-11 | Rapid relearning/flush of FDB entries after a topology change | Claims 3/13 (FDB updated responsively to a received message), 5/15 (aging), and 7/17 (change-driven update propagation) |
| US 6,628,624 B1 — "Value-added features for the spanning tree protocol," Cisco | 1998-12-09 / 2003-09-30 | STP extensions including database flushing/notification behavior | Claims 3/13, 7/17 |
| US 6,032,194 — "Method and apparatus for rapidly reconfiguring computer networks," Cisco | 1997-12-24 / 2000-02-29 | Fast reconfiguration with BPDU exchange | Claims 7/17 (propagating a change to other nodes), and claims 2/12 (periodic protocol messages, by analogy) |
| US 6,678,241 B1 — "Fast convergence with topology switching," Cisco | 1999-11-30 / 2004-01-13 | Convergence/topology-change handling | Claims 7/17 |
3.2 VPLS / Pseudowire / Layer-2 VPN (the multi-instance claims)
| Reference | Filed / Published | Description | Claims it touches |
|---|---|---|---|
| US 6,205,488 B1 — "Internet protocol virtual private network realization using multi-protocol label switching tunnels," Nortel | 1998-11-13 / 2001-03-20 | L2/L3 VPN built over MPLS tunnels | Claims 8/18 (node as multiple virtual bridges, per-instance state) |
| US 6,339,595 B1 — "Peer-model support for virtual private networks with potentially overlapping addresses," Cisco | 1997-12-23 / 2002-01-15 | VPN peer model with per-VPN address spaces | Claims 8/18 |
| US 2002/0091795 A1 — "Method and system of aggregate multiple VLANs in a metropolitan area network," Yip | 2001-01-05 / 2002-07-11 | Aggregating VLANs across a metro network | Claims 8/18, and the VLAN/FID keying described in the '400 specification |
| US 2003/0074469 A1 — "Method and apparatus for transparent LAN-to-LAN connection between two customer locations through a RPR data transport network," Alcatel | 2001-10-15 / 2003-04-17 | Transparent LAN service over an RPR transport | Claims 8/9/18/19 (transparent LAN/VPLS emulation) |
None of these discloses per-VPN-instance, per-line-card FDBs synchronized by internal messages, which is what claims 8/9/18/19 actually require. They are §103 background.
3.3 Intra-node packet transport to line cards (claims 6/16)
- US 2001/0022786 A1 — "Receive processing for dedicated bandwidth data communication switch backplane," Wai King — 1998-04-20 / 2001-09-20.
- US 6,584,535 B1 — "Configurable serial interconnection," Cisco — 2000-01-31 / 2003-06-24.
- US 2002/0179720 A1 — "Method and apparatus for redundancy switching in line cards," Liva — 2001-05-30 / 2002-12-05.
These support the "packet switched through the switching core to another line card" element of claims 1/6/11/16, but none of them carries a learning-synchronization payload. They are the natural §103 partners for the internal-transport feature only.
3.4 Ring protection / line-card redundancy (background, not claim-mapped)
The visible list contains a large ring/protection family — e.g. US 5,159,595 (Northern Telecom, ring transmission, 1988-04-08 / 1992-10-27), US 5,307,353 (Fujitsu, fault recovery in a ring, 1990-05-09 / 1994-04-26), US 5,925,137 (NEC, alternate routing in a ring), US 6,249, 667 (Lucent, bidirectional MSPR restoration), US 6,256,292 (Nortel, self-healing line-switched ring), US 6,366,556 (Lucent, self-healing networks using virtual rings), US 6,449, etc. These bear on the standby-line-card / redundant-link embodiment described at the end of the '400 specification — an embodiment that is not claimed. They do not map onto claims 1–20 and should not be presented as anticipation art.
Similarly, the QoS/MPLS-TE references (US 6,466,985, US 6,664, etc., US 6,665,273, US 6,680,906, US 6,567,793) are background to the MPLS/RPR environment and have no claim-mapping value.
3.5 Co-pending Corrigent applications cited in the specification
- US 2003/0208618 A1 — "Fast failure protection using redundant network edge ports," Gal Mor et al. (application 10/036,518, filed 2002-01-07, published 2003-11-06). Cited in the '400 specification as the source of the dummy-packet/standby-line-card mechanism. Published >1 year before the '400 filing → §102(b) art, and potentially §102(e) art as a US application publication. Relevant only to the unclaimed protection embodiment, not to claims 1–20.
- US application 10/993,882 (filed 2004-11-19), referenced for RPR-related MAC learning. Because it is a US application, it can be §102(e) art only as to subject matter it discloses and only if its filing date precedes the '400's; it is cited for RPR-specific learning, again not for the LAG synchronization claimed.
4. Non-patent literature cited (printed publications, §102(a)/(b))
The specification expressly incorporates these, so they are "printed publications" for §102 purposes:
| Reference | Date | Relevance to claims |
|---|---|---|
| ANSI/IEEE Std 802.1D-2004, MAC Bridges | 2004 | The generic bridge model: FDB, source-address learning, flooding on unknown DA, aging, topology-change notification. Supplies the "baseline" of claims 1, 3, 5, 10, 11, 13, 15, 20 — but has no notion of line cards or of messaging learned associations between them. §102(b). |
| IEEE Std 802.3-2002, Clause 43 (link aggregation) | 2002 | The LAG-group element of claims 1/11; supports the "flood once per LAG" behavior. §102(b). |
| IEEE Std 802.1Q (VLANs) | 2003 ed. | The VLAN/FID keying in claims 8/9/18/19. §102(b). |
| Martini et al., "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks," IETF draft-ietf-pwe3-ethernet-encap-11 | Nov. 2005 | Pseudowire encapsulation; framing for a virtual bridge. Less than one year before the 2006-05-19 filing → not §102(b). Available only as §102(a) (printed publication before the applicant's invention date), which requires establishing an invention date after the draft's posting date — not something the '400 record settles. |
| Kompella et al., "Virtual Private LAN Service," draft-ietf-12vpn-vpls-bgp-06.txt (sic — identifier reproduced exactly as printed; the string is evidently a typographical variant of "l2vpn") | Dec. 2005 | VPLS architecture; claims 8/9/18/19. Same §102(a)-only status. |
| Lasserre et al., "Virtual Private LAN Services over MPLS," draft-ietf-12vpn-vpls-1dp-08.txt (sic) | Nov. 2005 | VPLS/PW signaling; claims 8/9/18/19. Same §102(a)-only status. |
I am flagging the "12vpn"/"1dp" strings as they appear rather than silently correcting them, per the literal-interpretation rule. Anyone building an invalidity chart should confirm the actual draft filenames and posting dates against the IETF archive before relying on them.
5. The anomalous citation block — flag this explicitly
A contiguous block of the citations attributed to US 7,593,400 in the published record is implantable-neurostimulation art with no plausible relationship to Layer-2 bridging:
- US 4,535,785 (van den Honert, nerve electrode, 1982-09-23 / 1985-08-20)
- US 4,602,624 (Naples et al., 1984-10-11 / 1986-07-29); US 4,628,942 (Sweeney et al.)
- US 4,702,254, US 4,867,164, US 5,025,807 (Zabara, "Neurocybernetic prosthesis")
- US 5,188,104, US 5,263,480, US 5,299,569, US 5,571,150 (Wernicke); US 5,215,086, US 5,335,657, US 5,540,730, US 5,707,400 (Terry Jr.); US 5,282,468 (Klepinski); US 5,199,430 (Fang); US 5,205,285 (Baker Jr.); US 5,755,750 (Petruska) — the Cyberonics family
This block is internally coherent as a neurostimulation reference list, which is what makes it look like cross-contamination of the USPTO-published record (or of the OCR both Google Patents and Justia rely on) rather than a random error. I am not treating these as prior art for 7593400. I also cannot rule out that the 123-citation count is inflated by this block, so the count should not be used as a completeness check. If this matters for a filing or an invalidity position, pull the front-page images from the USPTO PatentCenter/patentimages and count the references by hand.
A second caution already noted in the verified record continues to apply here: the portfolio contains other Corrigent patents with similar-looking numbers, and the "cited by" (forward-citation) lists — e.g. US 8,785,373, US 8,817,796, US 8,854,973, US 8,885,518, US 9,038,629 — are later art, not prior art, and must not be mixed into a §102 analysis.
6. Bottom line on anticipation
No reference cited against US 7,593,400 anticipates independent claim 1 or independent claim 11 under §102. The reason is structural, not evidentiary: every cited reference that touches MAC learning discloses learning in a monolithic bridge (802.1D, US 6,446,131, US 6,370,121), and every cited reference that touches aggregation discloses link-level distribution across a LAG (US 5,959,968, US 6,151,297, US 6,553,029, IEEE 802.3-2002 Cl. 43). None discloses the claimed pivot: learning on the transmitting line card against the ingress port, and then messaging that association to each member line card of the LAG group so that sibling cards that never saw the packet still hold a complete FDB (claims 1 and 11, with the LAG-identification feature of the specification).
The closest single-reference §102 candidate is US 6,553,029 B1 (PMC-Sierra), and it fails on three separate claim elements — the distributed per-line-card FDB, the egress-side learning, and the association message. That is consistent with the PTAB outcome in the verified record, where both IPRs directed at this patent (IPR2023-00370 and IPR2023-00805) were not instituted on the merits.
Where the cited art is useful is §103, claim-by-claim:
- Claims 1 / 11: US 6,553,029 (LAG + flood-once) in view of US 6,446,131 or 802.1D (learning/FDB) — but the sync-message limitation remains untaught by any cited reference. This is where a challenger would need art outside the citation record.
- Claims 2 / 12: US 6,032,194 (periodic protocol messaging) as a §103 adjunct — weak.
- Claims 3 / 13 / 5 / 15: US 6,330,229, US 6,628,624, US 6,147,993, and 802.1D (FDB update, refresh, aging) map well.
- Claims 4 / 14 (SELF vs. SYNC marking): no cited reference discloses this. The distinction between locally-learned and remotely-received records is the strongest claim-differentiating feature in the visible art set.
- Claims 6 / 16: US 2001/0022786, US 6,584,535, US 2002/0179720 for intra-node transport.
- Claims 7 / 17 (SYNCUPDATE on a port move): US 6,330,229, US 6,032,194, US 6,678,241 are the nearest, and all are weaker than the claim.
- Claims 8 / 9 / 18 / 19 (multiple VPLS instances): US 6,205,488, US 6,339,595, US 2002/0091795, US 2003/0074469, plus the 2005 VPLS drafts (subject to the §102(a) date problem in §4).
- Claims 10 / 20: US 6,446,131 and 802.1D for bidirectional learning.
7. Caveats I want on the record
- Completeness: the citation list I could read is truncated; ~30 of 123 entries were not visible, and I did not have web access to the remaining records of the list or to a first-hand USPTO front-page image. Treat §3 as "references visible in the retrieved record," not "all references cited."
- The neurostimulation block (§5) is unexplained. I have flagged it rather than silently deleting it, but I cannot certify that the remainder of the list is clean, nor that the 123 count is accurate.
- Date semantics: I used issue/publication dates for §102(b) status, not the priority dates Google Patents displays. The three IETF drafts (Nov./Dec. 2005) are inside the one-year window and are therefore §102(a) art at best — their exact posting dates and the applicant's invention date would both need to be established.
- Identifier fidelity: I have reproduced "draft-ietf-12vpn-…" and "…-1dp-08" exactly as printed in the patent rather than normalizing them.
- The 2026 posture of CAFC 25-2036 remains unverified (see the prior section); nothing in this prior-art analysis depends on it.
Generated 9/28/2026, 9:43:42 PM
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
I'll ground this analysis in the actual prior-art record for this patent before drawing conclusions.
Let me examine the key references, especially the one the EP examiner treated as the primary reference.
Let me locate the actual IPR grounds and the references cited in them.
Obviousness Analysis — U.S. Patent No. 7,593,400 B2 ("MAC Address Learning in a Distributed Bridge")
35 U.S.C. § 103 · Priority date 19 May 2006 · Pre-AIA framework (application filed before 16 Mar 2013)
Builds on the previously generated Patent Summary and Litigation Summary. I do not repeat the bibliographic and docket material there except where it is load-bearing for the obviousness question. One contradiction with the earlier sections is flagged in §7.5.
1. Why this patent has already been the subject of a § 103 fight — and what that does and does not tell us
The most probative evidence available on obviousness is not my own reconstruction; it is the invalidity record the defendants actually built. From the parties' own stipulations filed in W.D. Tex. 6:22-cv-00396 and D. Del. 1:22-cv-00496 (text at https://ptacts.uspto.gov/ptacts/public-informations/petitions/1550799/download-documents?artifactId=OK8h6Oj1o9HQOuHKTF_DkW_kOiiXc0jCRW1DZ31eDrmV8zRW6S_S_K4), IPR2023-00370 asserted five grounds, reported there verbatim as:
| Ground | Claims | Combination asserted |
|---|---|---|
| 1 | 1, 3, 6, 11, 13, 16 | U.S. Pat. App. Pub. 2005/0198371 ("Smith") |
| 2 | 1–3, 11–13 | Smith + Ishimori (Japanese Pat. App. No. 2005/086668) |
| 3 | 1, 4–7, 10, 11, 14–17, 20 | Smith + Ishimori + U.S. Pat. 6,735,198 ("Edsall") |
| 4 | 8–9, 18–19 | Smith + Ishimori + U.S. Pat. App. Pub. 2004/0133619 ("Zelig") |
| 5 | 9, 19 | Smith + Ishimori + Zelig + IEEE Std 802.1Q (1998) |
Source: IPR2023-00370 petition (https://ptacts.uspto.gov/ptacts/public-informations/petitions/1553870/download-documents?artifactId=doMPFYG6o9ICGYq3FbJSQ4KOtlFwT1MdJPtMkVabRscIr0VQC7sAwjk) and case record (https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2023-00370).
Critical framing, per the rules I am operating under: both IPRs were institution-denied (IPR2023-00370 on 11 Aug 2023; IPR2023-00805 on 9 Nov 2023), and the earlier sections correctly report this. A denial under § 314(a) is a finding that the petitioner did not establish a reasonable likelihood of prevailing on that record — it is not a holding that the claims are non-obvious, and it carries little stare decisis weight. Anyone reading the litigation summary as "the '400 patent survived an obviousness challenge" would be over-reading it. The correct inference is narrower: the record as developed by these particular petitioners, with these particular primary references and this particular claim-construction posture, did not clear the institution threshold.
2. Level of ordinary skill and the legal standard
POSITA (my construction, consistent with the petition's expert): a person with a bachelor's degree in electrical engineering or computer science and roughly 3–5 years of experience in data-network switching/bridging, or equivalent, familiar with IEEE 802.1D bridging (FDB learning, aging, flooding), 802.1Q VLANs, 802.3ad/Clause 43 link aggregation, and chassis/stacked switch architectures with a switch fabric and distributed line cards.
Standard: Graham factors; KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) — a combination of familiar elements yielding predictable results is likely obvious; the reason to combine may come from the problem the art was addressing; and the analysis may consider the inferences and creative steps a POSITA would employ. The patent's own specification supplies two § 103-relevant admissions that narrow the field sharply:
- MAC learning by associating a source MAC with the receiving port, and flooding on FDB miss, were known bridge behavior (Background, citing ANSI/IEEE Std 802.1D (2004)). "The bridge builds the forwarding database by means of a learning process, in which it associates the source MAC address of each incoming packet with the port on which the packet was received."
- Link aggregation as a single logical link with distributor/collector functions was known (Background, citing Clause 43 of IEEE Std 802.3 (2002)).
So the only genuinely contested subject matter is the distributed-synchronization layer: egress-side learning in a multi-line-card node, messaging learned associations to other line cards, LAG-aware flooding, and record-state marking.
3. The prior-art references
| Ref | Identity | Date (relative to 19 May 2006) | What it teaches, per the primary record |
|---|---|---|---|
| Smith | U.S. Pat. App. Pub. 2005/0198371 | Published 15 Sep 2005 → § 102(b) | Virtual network device with sub-units (line cards) each having forwarding engines; interface bundles treated as single logical links, with "one egress interface per interface bundle" selected for transmission; MAC notification messages sent to update forwarding engines in other sub-units; "Each packet sent between the virtual network device and the first network device is sent via only a one of the communication links." |
| Ishimori | Japanese Pat. App. No. 2005/086668 | JP filing 2005 → publication 2007-03-29 (see caveat §7.3) | Card-based forwarding with trunks; one representative port selected for transmission to avoid "flooding is constantly performed"; a "learn packet" generated at a predetermined timing, and "it is desirable to transmit the learn packet to all forwarding devices constituting this trunk"; aging of learning results. |
| Edsall | U.S. Pat. 6,735,198 B1 (Cisco), filed 21 Dec 1999, issued 11 May 2004 → § 102(b) | Line cards LC1–3 interconnected by a switch fabric; distributed forwarding tables per line card (entries keyed MAC:card,port, e.g. B:1,1) — literally records associating MAC addresses with ports; learning on the egress card ("creating/updating an entry of the L2 forwarding table with the source MAC address and its location (index) within the switch"); notification frame generated at the egress card to synchronize the peer table; a PI indicator asserted when an entry is learned through a port "as opposed to through the switch fabric"; DI comparison to detect a changed location. |
|
| Zelig | U.S. Pat. App. Pub. 2004/0133619 | Published 8 Jul 2004 → § 102(b) | Data communication network with multiple virtual bridges interconnected by virtual connections (VPN/VPLS instances). |
| Shimada '537 | U.S. Pat. App. Pub. 2005/0286537 A1 (Fujitsu), filed 14 Oct 2004, published 29 Dec 2005 → § 102(b) | L2 switch with VLAN+source-MAC learning; link aggregation ("a single logical transmission line where physical links are aggregated"); and — dispositive for one claim element — "a single transmission line is set to be used when a flooding frame is transferred to the transmission line where the links are aggregated." | |
| Shimada '602 | U.S. Pat. App. Pub. 2007/0058602 A1 (Fujitsu), US filed 29 Dec 2005, published 15 Mar 2007 | § 102(e) available (US filing predates 19 May 2006) despite later publication | Line-unit ("card") architecture with a backboard; ingress unit tags the internal frame header with receiving unit number + receiving port number; at the destination unit, the logic is literally "LEARN SOURCE MAC ADDRESS, RECEIVING UNIT NUMBER, AND RECEIVING PORT NUMBER"; flooding via a single trunk port ("0 indicates that port does not belong to trunk"; link-aggregate output selection). |
| IEEE Std 802.1D (2004), 802.3ad / Clause 43, 802.1Q (1998) | Standards | Pre-date | Bridge learning/aging/flooding; link aggregation; FID/VLAN-independence of filtering databases. |
The EPO's supplementary search report for the family member EP 2022222 A4 (http://data.epo.org/gpi/EP2022222A4) is an independent corroboration that these are the material references, and it grades them differently than the petitioners did:
[XYI] US 6735198 B1 (Edsall et al.)
[Y] US 2005/286537 A1 (Shimada)
[A] US 6788681 B1 (Hurren et al.)
A category X citation in EPO practice means the examiner regarded the reference as destroying novelty taken alone; Y indicates particular relevance in combination; A is mere background. In other words, the European examiner's primary reference was Edsall, not Smith — a materially different attack from the one that failed at the PTAB. I regard this as the single most important lead in this analysis. (I report the Hurren reference only as the examiner's category-[A] item; I have not independently verified its disclosure and do not rely on it.)
4. The factual crux: the art identified the same problem the '400 patent identifies
This is what converts a list of references into a KSR-compliant motivation-to-combine argument. The '400 patent's stated problem (Summary) is:
"LAG member selection … is typically performed on the ingress line card. In the absence of the synchronization method described above, other members in the LAG may not receive such packets for transmission, so that the FDB of the corresponding line cards will not be updated. When these line cards receive incoming packets, the result may be constant flooding, since the FDB is incomplete."
Three independent references state the identical problem, unprompted:
- Ishimori — "at each communication card … the learning results on the communication cards in the same trunk are not leveraged and 'flooding is constantly performed'"; solution: one representative port per trunk + a learn packet sent to all forwarding devices constituting the trunk.
- Shimada '537 — the aggregation arrangement where only one line in the trunk is used for flooding means the other line cards do not learn, so flooding repeats.
- Edsall — distributing forwarding tables "results in inherently inaccurate forwarding decision behavior," and software-based table synchronization "involves the latency associated with updating each of the distributed forwarding tables, along with the additional overhead consumed by the microprocessors."
Where the prior art articulates both the deficiency and the cure, motivation is not a matter of hindsight reconstruction; it is on the face of the references. KSR, 550 U.S. at 420 ("any need or problem known in the field and addressed by the patent can provide a reason for combining the elements in the manner claimed").
5. Element-by-element obviousness mapping of independent claim 1
(claim 11 tracks claim 1; I analyze claim 1 and note where 11 diverges)
| Claim 1 element | Primary disclosure | Corroboration / why combinable |
|---|---|---|
| [a] node with plurality of ports, ≥2 line cards, operating as a distributed MAC bridge in a Layer 2 network | Smith (virtual network device with sub-units/line cards); Edsall ("plurality of line cards (LC1–3) interconnected by a switch fabric"); Shimada '602 (line units + backboard) | '400 Background concedes 802.1D bridges and multi-card switch fabrics are conventional |
| [b] LAG group of parallel physical links joined into one logical link, with LAG ports and member line cards | Smith "interface bundles" with one egress interface selected; Shimada '537 aggregated links; IEEE 802.3ad/Clause 43 (admitted in '400 Background) | Smith expressly teaches bundles spanning sub-units, i.e. member line cards |
| [c] each member line card has its own FDB of MAC↔port records | Edsall — distributed forwarding tables FwdT1…FwdTn with MAC:card,port entries; Smith — per-sub-unit forwarding engines and MAC tables | Direct |
| [d] receive data packet on ingress port from a MAC SA, specifying a MAC DA | Edsall, Shimada '537, Shimada '602 | Direct |
| [e] convey the packet in the node to at least the first line card for transmission to the MAC DA via the first port | Edsall claim 1: "switching a frame from the ingress card to the egress card"; Shimada '602: internal frame header carries destination unit/port, "FORWARD FRAME TO BACKBOARD"; Smith: sub-unit selects egress interface per bundle | This element is the reason the "first line card" construction matters — see §7.1 |
| [f] if DA not in FDB, flood via one and only one LAG port | Shimada '537 abstract: "a single transmission line is set to be used when a flooding frame is transferred to the transmission line where the links are aggregated"; Ishimori: one representative port per trunk to stop "constant flooding"; Smith: one egress interface per bundle | Three independent teachings of the exact limitation — this is the element most vulnerable to a § 103 challenge |
| [g] check the MAC SA against the first (egress) line card's FDB records | Edsall: egress-card learning and PI/DI table checks; Shimada '602: learning is performed on the destination unit | Direct |
| [h] if no record of SA↔ingress-port, create the record, add it to the first card's FDB | Edsall: "if there is not a current entry," the engine "learn[s] the source address/index" by "creating/updating an entry of the L2 forwarding table with the source MAC address and its location (index)"; Shimada '602: "LEARN SOURCE MAC ADDRESS, RECEIVING UNIT NUMBER, AND RECEIVING PORT NUMBER" | Direct; the "create new record" language is met by Edsall's create/update branch |
| [i] send a message of the association to each member line card | Edsall: "generating a notification frame at the egress card" and "updating the ingress forwarding table … to thereby synchronize the ingress and egress forwarding tables"; Smith: MAC notification updates forwarding engines; Ishimori: "desirable to transmit the learn packet to all forwarding devices constituting this trunk" | Ishimori supplies the "each member line card" breadth that Edsall alone may not |
Dependent claims
| Claim | Disclosure |
|---|---|
| 2 / 12 (periodic sync at predefined times) | Ishimori: learn packet "generated at a predetermined timing under predetermined conditions"; the '400 spec's own periodic-SYNC scheme is a conventional design choice for keeping sync intervals shorter than aging |
| 3 / 13 (receiving card adds record if absent) | Edsall: flood-to-fabric "forces each forwarding engine associated with each egress card to either (i) update its current L2 forwarding table entry … or, if there is not a current entry, (ii) learn the source address/index"; Smith: "after being updated based on the MAC notification, the forwarding engines … now know the location of the device" |
| 4 / 14 (SELF vs SYNC marking) | Edsall's PI indicator — asserted for an entry learned through one of the ports "as opposed to through the switch fabric" — is a direct anticipation-style disclosure of distinguishing locally-learned from fabric-received records. The petitioners' petition expressly notes the examiner had already found Edsall disclosed this limitation during prosecution and that the applicant did not dispute it |
| 5 / 15 (aging + refresh + removal) | Ishimori aging process (also taught by Ishimori in conjunction with the learn packet); 802.1D aging is admitted prior art in the '400 Background |
| 6 / 16 (sync packet via switching core) | Edsall: notification frame conveyed over the switch fabric; Shimada '602: internal frame header over the backboard |
| 7 / 17 (SYNCUPDATE on port move) | Edsall: PI asserted and ingress DI ≠ egress DI → generate the notification frame; 802.1D topology-change/station-move handling; the '400 Background and spec treat station moves as the ordinary case |
| 8–9 / 18–19 (multiple VPN/VPLS instances, independent records, instance identified in the message) | Zelig (multiple virtual bridges / primary virtual connections) + 802.1Q (VLAN/FID partitioning) + Ishimori (message identifies the affected entity). See the § 103(c) problem in §7.4 |
| 10 / 20 (bidirectional learning) | Smith (learning flows both ways through sub-units); Shimada '602 (any card that receives the frame learns) |
6. Motivation to combine, stated in the form a PTAB or district court would require
Same field, same problem, same architecture. Smith, Ishimori, Shimada '537/'602 and Edsall are all multi-slot/multi-card L2 forwarding devices with a fabric or backboard, and all deal with MAC-learning consistency across cards. Smith, Ishimori and Shimada '537 each expressly handle link bundles/trunks/aggregation, and each expressly addresses the flooding inefficiency that arises when only one member of the bundle transmits. The '400 patent's stated problem is the same problem. KSR, 550 U.S. at 417–18.
Express inter-reference motivation. Shimada '537 supplies the aggregation-with-single-flood-port premise; Ishimori supplies the diagnosis ("flooding is constantly performed") and the remedy (one representative port plus a learn packet transmitted to all forwarding devices in the trunk); Smith supplies bundle-spanning sub-units with MAC notification to remote forwarding engines; Edsall supplies the egress-side learning and record-state marking with fabric-borne notification and the DI-difference trigger. Each reference supplies a piece the others lack, without any reference being modified in a way that would change its principle of operation.
Finite, predictable solutions. Once the POSITA accepts that ingress-side LAG selection starves peer cards of learning opportunities, the design space collapses to a small set: (a) learn on ingress and replicate to peers; (b) learn on egress and notify peers (Smith/Edsall/Shimada '602); (c) periodically push a learn packet (Ishimori). The '400 patent claims option (b)+(c) with a LAG-aware flood rule — a predictable selection within a small, enumerated set. KSR at 421.
Reasonable expectation of success. Every element is a table-management function implemented in existing per-card forwarding hardware/software. Edsall demonstrates the fabric is already available to carry control-type frames between cards; Ishimori's "learn packet" and Shimada '602's internally-tagged frame show the same thing. No new hardware class, no unpredictable physical result.
Design incentives independent of the patent. Reducing reliance on flooding conserves LAG bandwidth (the aggregate link is scarce); ensuring uniform FDB contents across LAG members is necessary for correct load balancing and for protection on link failure — the '400 spec itself ties this to the dummy-packet protection scheme of U.S. 2003/0208618 A1.
7. Where obviousness is strongest, weakest, and where I have to flag problems
7.1 Claim construction materially changes the § 103 analysis — and cuts both ways
The earlier sections report that in W.D. Tex. the court held (Omnibus Order, Dkt. 299) that asserted claims require step ordering [e] before [f] and [g], and that "first line card" means the egress line card. Consequences:
- Attackers' advantage: the construction aligns the claims with Edsall, whose express teaching is egress-card learning plus notification back to the ingress card, and with Shimada '602, whose express teaching is learning at the destination line unit. A petitioner who frames the ground around "learning happens on the card that transmits the packet" now has a cleaner mapping than the Smith-centric petition did.
- Attackers' disadvantage: the ordered-step construction means an invalidating combination must teach (i) egress transmission to the DA first, then (ii) the unknown-DA flood rule, then (iii) the SA check — and must not rely on an in-order-independent arrangement. A properly drafted ground must show the ordering. The Smith/Ishimori petition's mapping of steps [f]/[g] is exactly where a Sotera-style stipulation-free relitigation would be vulnerable.
7.2 The "one and only one LAG port" limitation is the patent's weakest point on this record
Three independent references (Smith's per-bundle egress interface; Ishimori's representative port; Shimada '537's single transmission line for flooded frames) teach it. If this limitation were the patent's distinguishing feature, the obviousness case would be very strong. That it did not carry the day at the PTAB is best explained by the Board's § 314(a) threshold and the specific petition record, not by any apparent deficiency in the art.
7.3 Chronology and availability caveats I must state explicitly
- Ishimori (JP App. No. 2005/086668). The petition identifies it only as a Japanese application. A foreign application is not itself § 102(a)/(b) art — pre-AIA § 102(a) requires a printed publication or patent, and a mere pending foreign application is neither. Availability therefore depends on the corresponding JP laid-open publication (kokai) having issued before 19 May 2006; the citation list associated with this family shows a JP publication dated 2007-03-29, which would be after the '400 priority date. Ishimori's status as prior art is thus the single most vulnerable link in the petitioners' chain and may itself explain the institution denials. A challenger should verify the actual kokai date from the JPO record before relying on Ishimori at all. I have not verified it and am flagging rather than asserting.
- Marconi / ITMI20051704A1 → US 7,929,545 B2 / US 2010/0085982 A1 ("Optimized synchronization of MAC address tables in network interconnection apparatuses," priority 15 Sep 2005) is superficially a perfect reference for claims 2/4/5/12/14/15. But it is, in my judgment, not available: its US filing date is 24 Aug 2006 (after 19 May 2006), its Italian publication and its US publication both post-date the '400 priority date, and pre-AIA § 102(e) does not give a reference the benefit of a foreign priority date (In re Hilmer). It should not be used. If a challenger intends to use it, that threshold issue must be briefed first.
- Shimada '602 (US 2007/0058602 A1) is, by contrast, available as § 102(e) art because its US filing date (29 Dec 2005) precedes 19 May 2006, even though it published 15 Mar 2007. Its disclosure is strikingly on-point for elements [e], [f], [g], [h] and [i]. I regard it as an under-used reference in the IPR record, and it is the reference I would build a fresh ground around.
7.4 The Zelig ground (claims 8–9, 18–19) has a statutory infirmity the petitioners may have overlooked
Grounds 4 and 5 rest on U.S. Pat. App. Pub. 2004/0133619 ("Zelig"). The quoted passage attributed to Zelig in the petition — "MAC bridges that implement the 802.1D standard allow MAC devices attached to physically separated LANs to appear to each other as if they were attached to a single LAN. A MAC bridge includes two or more MAC devices that interconnect the bridge ports to respective LANs" — tracks the '400 patent's own Background nearly verbatim, and the reference is attributed to Zelig, the same-named first inventor of the '400 patent, in the same corporate family (Corrigent). If Zelig '619 is in fact commonly owned with the '400 patent, then to the extent it qualifies as prior art only under § 102(e)/(f)/(g), pre-AIA § 103(c) disqualifies it for use in an obviousness combination. That would knock out Grounds 4 and 5 entirely and leave claims 8–9 and 18–19 unaddressed. I flag this as a hypothesis requiring verification of the '619 assignment record and the inventors' common ownership — I have not verified it here, and I state it as the most likely explanation for why these dependent claims would be the hardest to invalidate on the existing record.
7.5 A contradiction in the prior sections that I am flagging, not resolving
The earlier Patent Summary describes the W.D. Tex. outcome as a final judgment for Cisco with summary judgment of no infringement on the '400 patent (terminated 02/16/2025, citing Final Judgment Dkt. 351-1 and the reference in Dkt. 299). The earlier Litigation Summary simultaneously reports a VitalLaw item describing a 16 Jul 2025 W.D. Tex. order invalidating "three patents" as abstract in No. 6:22-cv-00396-ADA, and itself flags the timing conflict while guessing the item concerns the '369/'485 patents. For obviousness purposes this matters only in one respect: no court in the retrieved record has adjudicated the '400 patent's validity as a merits holding. The '400 patent left the Cisco case on non-infringement, which is orthogonal to § 103 and cannot be treated as a validity endorsement. I therefore treat all validity questions on the '400 as open.
7.6 Secondary considerations
I found no objective-indicia evidence in the retrieved record — no long-felt-need, failure-of-others, licensing-due-to-merits, or industry-praise evidence tied to the '400 claims. The patent's own specification frames the invention as solving a flooding-efficiency problem that the art had already articulated, which tends to weaken any nexus argument.
8. Bottom line
Strongest § 103 challenge (my recommendation, in descending confidence):
- Edsall + Shimada '537 — the EPO's own combination (EP search report: Edsall [XYI], Shimada [Y]). Covers claims 1, 3, 4, 6, 11, 13, 14, 16, 20 via egress-card learning + per-card distributed tables + notification frame over the fabric + PI-type record marking + single-flood-port link aggregation. This is the ground I would press, and it is materially different from the one the PTAB declined to institute.
- Edsall + Shimada '537 + Shimada '602 — adds the destination-unit learning of "SOURCE MAC ADDRESS, RECEIVING UNIT NUMBER, AND RECEIVING PORT NUMBER" and the internal-header unit/port tagging, shoring up elements [e], [g]–[i] against the "first line card = egress line card" construction, with § 102(e) availability secured by the 29 Dec 2005 US filing date.
- Smith + Ishimori + Edsall (Ground 3 as filed) plus IEEE 802.1D — strong on claims 1, 4–7, 10, 11, 14–17, 20, conditional on Ishimori's JP publication date being verified as pre-19 May 2006.
- Claims 8–9 / 18–19: 802.1Q + a non-commonly-owned multiple-VPN-instance reference. Ground 4/5 as filed is, in my assessment, likely disabled by pre-AIA § 103(c) if Zelig '619 is a commonly-owned Corrigent application — which the record strongly suggests.
Overall assessment (stated with my confidence level): On the technical merits, independent claim 1 and most dependents present a credible, likely-meritorious § 103 case, because (i) the '400 Background concedes the bridge- and LAG-level subject matter, (ii) the remaining distributed-synchronization subject matter is squarely disclosed by Edsall, Smith, Shimada '537/'602 and Ishimori, and (iii) three of those references expressly identify the same "constant flooding from incomplete peer FDBs" problem the patent claims to solve. The reason the patent is not already invalid is procedural and record-specific: both IPRs were institution-denied on the petitioners' chosen grounds, one of those grounds rests on a foreign application whose publication date I have been unable to verify as pre-critical-date, and the Zelig ground appears statutorily vulnerable. I would put the probability that a properly framed § 103 challenge prevails on claim 1 in the more-likely-than-not range, with the caveat that the ordered-step and "first line card = egress" constructions must be met head-on and that the Ishimori and Zelig availability questions are threshold issues that could dispose of the grounds entirely if decided the other way.
Where I do not have high confidence: (a) the JP kokai publication date for Ishimori (App. No. 2005/086668); (b) the common ownership status of US 2004/0133619 (Zelig) relative to the '400 patent for § 103(c) purposes; (c) the actual text and disclosure of the examiner's category-[A] reference US 6,788,681 (Hurren). Each of these should be verified against the primary source before being relied upon in a brief.
Generated 9/28/2026, 9:43:43 PM
Extensions
Patent term adjustments, term extensions, continuations, divisionals, family members, and expiration dates.
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Keep exploring
More patents asserted by Corrigent Corporation
- US 11316014A technical analysis of U.S. Patent 11,316,014 reveals the following details. A search of the Court of Appeals for the Federal Circuit (CAFC) dockets for 2026 did not yield any results for this patent number. Summary of U.S. Patent…
- US 8941708Summary of U.S. Patent 8,941,708 Title: Method, computer-readable storage medium, and apparatus for modifying the layout used by a video composing unit to generate a composite video signal Assignee: Cisco Technology, Inc. Inventor: Hakon…
- US 7359437US Patent 7359437, titled "Encoding method and system for reducing inter-symbol interference effects in transmission over a serial link," was filed on December 24, 2001, and issued on April 15, 2008. The original assignee was Silicon Image…
- US 7061859Here is a concise summary of US patent 7061859: Title: Fast protection in ring topologies Current Assignee: Quicker Connections LLC Inventors: Yossi Barsheshet Filing Date: August 30, 2001 Issue Date: June 13, 2006 Abstract: In a…
- US 8830293US patent 8830293, titled "Video superposition for continuous presence," was issued to Cisco Technology Inc. on September 9, 2014, from an application filed on May 26, 2009. The inventors are J. William Mauchly and Richard Thayer Wales…
- US 8441721US patent 8441721, titled "System and method of Raman amplifier pump control," was issued on May 14, 2013, from an application filed on December 30, 2009. The patent was originally assigned to Alcatel Lucent SAS and is currently assigned…
- US 9917856Here is a concise summary of US Patent 9917856: US Patent 9917856 Title: Rule-based network-threat detection for encrypted communications Assignee: Centripetal Networks LLC Inventors: David K. Ahn, Sean Moore, Douglas M. DiSabello Filing…
- US 9565213I'll search the USPTO database and CAFC dockets for this specific patent number. I have solid data on the patent itself. Now let me find the actual claim text and check for CAFC 2026 docket entries specific to this patent. US Patent…
Other patents in Software Technology & Computing Systems (T)
- US 7995589I'll verify details against current sources, including any CAFC docket activity, while treating the patent number literally. Let me check litigation history and any 2026 appellate activity more specifically. US Patent 7,995,589 —…
- US 7990984I'll search for authoritative information on this patent. Let me search for the CAFC docket activity and claim text. Let me get the full independent claim text and check for any 2026 CAFC activity on this patent. US 7,990,984 B2 — Summary…
- US 7047561I'll search for authoritative information on US 7,047,561, including any 2026 CAFC activity. Let me look specifically at the litigation history and any 2026 appellate activity. Let me check the 2018 appeal and confirm whether there is any…
- US 6791971I'll search for authoritative information on this patent, including any recent litigation activity. Let me check the specific litigation dockets and any 2026 activity. US Patent 6,791,971 (US6791971B1) — Summary Sourcing note: I relied…
- US 6772210I'll search for authoritative information on this patent number. Initial searches returned little. Let me refine. Let me check for any 2026 Federal Circuit activity specific to this patent. US Patent 6,772,210 — Research Summary Note on…
- US 6799210I'll search for current docket and status information on this specific patent number. Those searches returned unrelated results. Let me try more targeted queries. Search results on CAFC 2026 dockets and litigation Before the summary, a…
- US 5991389I'll run several searches in parallel to gather authoritative information on this specific patent number. Let me search specifically for the claim text and any 2026 litigation activity. US Patent 5,991,389 — Analyst Summary Caveat on scope…
- US 6798786I'll search for authoritative records on this specific patent. USPTO / docket search — US 6,798,786 Searches run against Google Patents (USPTO full-text mirror), the USPTO Official Gazette issue 1286-4 entry, the Unified Patents…
This patent in court (6)
6 tracked lawsuits name US 7593400.