Invalidity dossier

US 9749249

Pseudowire protection using a standby pseudowire

Current assignee: K.Mizra LLC

Added 9/28/2026, 7:34:13 PM

At a glanceNo PTAB challenges1 lawsuit on fileasserted by K.Mizra LLCSoftware Technology & Computing Systems (T)

Active provider: DeepSeek · deepseek-flash

Patent summary

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

✓ Generated

Patent Overview — US 9,749,249 B2

Title: "Pseudowire protection using a standby pseudowire"

Inventor: Ping Pan

Assignee / ownership per the supplied source: Original assignee Brixham Solutions Ltd; listed "Current Assignee" is K Mizra LLC. (Transfers listed in the text—e.g., to Global Innovation Aggregators LLC and K. Mizra LLC, and the 2014 assignment from Hammerhead Systems, Inc.—are referenced only as bibliographic entries, not analyzed here.)

Key dates: Priority date 2005-02-14; application US 14/050,078 filed 2013-10-09; published as US 2014/0105002 A1 on 2014-04-17; granted/publication date 2017-08-29. Legal status shown as "Expired – Lifetime," with anticipated expiration 2026-02-14.

Purpose: Pseudowires—emulations of native services (ATM, Frame Relay, Ethernet, TDM, SONET, SDH) over networks such as MPLS or IP—typically have no or only limited protection, and schemes like SONET APS or Ethernet Link Aggregation do not span multiple physical media types. MPLS Fast Reroute provides only limited protection: alternate tunnels can have less bandwidth, and existing protocols give no way to decide which data gets priority, so mission-critical data may be dropped.

Plain-language scope: A Pseudowire protection configuration parameter is sent to a destination node; a Pseudowire configuration acknowledgment is received; and, if establishment is allowed, the Pseudowire is established as a standby Pseudowire protecting one or more primary Pseudowires. When a primary Pseudowire fails (e.g., congestion or equipment failure), traffic designated for it is switched to the standby Pseudowire. The disclosure treats single-hop and multi-hop (multi-autonomous-system) systems, using LDP-based connections, plus a configuration parameter structure, priorities during switchover, and preemption (FIGS. 1A–6).

Not established by the excerpt: The full text of the claims is not supplied, so exact claim scope cannot be stated; the excerpt omits the remainder of the description beginning at FIG. 2 process 200. Litigation, ownership validity, and prior art are neither researched nor analyzed here.

Source: https://patents.google.com/patent/US9749249/en

Generated 10/16/2026, 11:21:15 AM

Cases on file (1)

Group view →

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

Litigation summary

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

✓ Generated

I'll research litigation involving US 9,749,249. Let me run several searches.

I found a key case. Let me dig deeper into the specifics.

Let me check for additional cases and the current status/outcome.

Note on my tools: my searches cut off at the step limit, so I could not fully pull the live PACER docket or the Unified Patents case page for this case. The following reflects what the search results actually returned; where something is unverified I say so.

Litigation involving U.S. Patent No. 9,749,249

Bottom line

Only one litigation is known to involve the '249 patent — the K.Mizra v. Nokia action in the Eastern District of Texas. That matches the Google Patents "Family has litigation" entry for US9749249B2, which points to exactly one case: Texas Eastern District Court, case 2:24-cv-00974 (Unified Patents litigation ID).

Google Patents also flags a Darts-IP "first worldwide family litigation" entry, but the only concrete US case number it identifies is the same E.D. Tex. 2:24-cv-00974 matter.


Case 1 — K.Mizra LLC v. Nokia Corporation, Nokia Solutions and Networks Oy, and Nokia of America Corporation

Field Detail
Plaintiff K.Mizra LLC (current owner of the '249 patent, per the complaint; K.Mizra is the assignee via Brixham Solutions Ltd. → Global Innovation Aggregators LLC → K.Mizra LLC)
Defendants Nokia Corporation; Nokia Solutions and Networks Oy; Nokia of America Corporation
Court / Jurisdiction U.S. District Court for the Eastern District of Texas, Marshall Division
Case No. 2:24-cv-00974-JRG
Filed November 25, 2024
Presiding Judge Judge Rodney Gilstrap
Cause of action Patent infringement, 35 U.S.C. § 271 (willful infringement alleged per RPX)
Status Open / pending as of the most recent docket activity I could see

Role of the '249 patent in this case: It is one of five patents-in-suit:

  • U.S. 9,485,176 ("Global IP-Based Service Oriented Network Architecture")
  • U.S. 10,735,320 ("Application Wire")
  • U.S. 9,264,354
  • U.S. 9,749,249 ("Pseudowire protection using a standby pseudowire")
  • U.S. 8,018,880

Per K.Mizra's Disclosure of Asserted Claims and Infringement Contentions (dated March 12, 2025), K.Mizra asserted claims 1–3, 5, 7–9, and 11–13 of the '249 patent, with an asserted priority date of February 14, 2005. (This is the face priority date of the '249 patent.)

Accused products (all patents collectively): Nokia network operations/SDN products (Digital Operations Center, Orchestration Center, Network Services Platform (NSP), Services Director) and Nokia router products (SR OS, BGP VPLS solution, 7750 SR and 7450 ESS series).

Key developments found:

  • Dec. 10, 2024 – Nokia moved for an extension to answer.
  • Jan. 6, 2025 – Nokia counsel appearances (Davison, Haynes, Stevens, Rubschlager).
  • Mar. 12, 2025 – K.Mizra served its infringement contentions.
  • 2025 – Nokia served Preliminary Invalidity Contentions as to all asserted claims, contending invalidity under 35 U.S.C. §§ 101, 102, 103, and/or 112.
  • Markman / claim construction ruling — the court issued a claim construction order addressing, inter alia, the '249 patent term "preemption of data [or network] traffic on the standby pseudowire." The court agreed with Nokia that preemption "requires traffic on the standby pseudowire and not merely a 'switch over' to that wire," but declined to limit "preemption" to merely "dropping" traffic, giving it plain and ordinary meaning. (The Justia copy of the order is captioned "E.D. Tex. 2026"; the document cites the '249 patent at 7:38–42.) The same order construed "Virtual Switch Instances (VSIs)" and "control plane that is external to the plurality of sites" for the '880 patent.
  • No final judgment or settlement has been identified. In a parallel IPR proceeding involving a different K.Mizra patent, a petitioner noted that the Nokia litigation had a trial setting, but warned that "Nokia and K.Mizra could settle their litigation … at any moment without notice." That corroborates that the case was still live and heading toward trial rather than resolved.

Outcome: None confirmed. The case appears still pending, with claim construction completed and trial scheduling in play.


Related K.Mizra litigation that does NOT involve the '249 patent

For completeness (and to explain why no other '249 case appears):

  • K.Mizra LLC v. Ciena Corporation, No. 1:24-cv-05442-SDG (N.D. Ga., filed Nov. 25, 2024). Patents-in-suit are U.S. 8,782,282, U.S. 9,485,176, and U.S. 10,735,320 — the '249 patent is not asserted here. Reported as closed 03/27/25 (Ciena's motion to dismiss rendered moot by an amended complaint; stayed in parallel IPR proceedings).
  • K.Mizra LLC v. Cisco Systems, Inc., 6:20-cv-01031-ADA (W.D. Tex.) — different patents.
  • K.Mizra LLC v. Google LLC (W.D. Tex. 1:25-cv-00236 and later 1:26-cv-00754) and Google LLC v. K.Mizra LLC (N.D. Cal. 3:25-cv-08107) — involve the '717/'120 and related patents, not '249.
  • K.Mizra LLC v. SonicWall, Inc., 1:25-cv-00047-RGA (D. Del.) and K.Mizra LLC v. Epson America, No. 8:25-cv-00027 (C.D. Cal.) — security-related patents ('705, '048), not '249.

None of the above assert U.S. 9,749,249.


Post-grant proceedings (not litigation, but relevant)

  • The Google Patents legal-events record for US9749249B2 shows a "Request for reexamination filed" with an effective date of 2025-11-13 and a docket entry dated 2026-01-27 ("RR" event). I could not confirm the requesting party or reexamination number from the search results, so treat the identity of the requester as unverified.
  • Separately, K.Mizra's '282 patent is subject to Ex Parte Reexamination No. 90/019,063 (filed May 15, 2025), and Ciena has filed IPRs including IPR2025-01362 against the '282 patent. These concern different patents, not the '249.

Other status notes on the '249 patent itself

  • Legal status: "Expired – Lifetime" per Google Patents; anticipated expiration 2026-02-14 (20 years from the Feb. 14, 2005 priority date).
  • Ownership chain of record: Hammerhead Systems, Inc. → Brixham Solutions Ltd. (2014) → Global Innovation Aggregators LLC (2017) → K.Mizra LLC (2020).

Caveats

  1. I could not directly query PACER or the Unified Patents litigation portal for the current docket (my tool session ended before I could retrieve those pages). The status above is based on the docket listings, the Justia docket entry (Document 124, claim construction order), and the IPR/invalidity filings that surfaced in search.
  2. "Open" is per RPX Insight (latest docket entry shown: 06/02/2025); later activity exists (the 2026 claim construction order), so the case is pending as of the most recent documents I could see, not necessarily as of today.
  3. If a later search of the live PACER docket or the Unified Patents portal shows additional cases (e.g., a co-pending case asserting the '249 patent), those should be added — but as of the sources retrieved, 2:24-cv-00974 is the only litigation involving U.S. 9,749,249.

Generated 9/28/2026, 7:42:58 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: K.Mizra LLC

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

PTAB challenges

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

✓ Generated

I'll verify the structured data against the public record before writing anything up.

Proceedings overview

Total AIA trial proceedings on US 9,749,249: zero. The structured "PTAB proceedings on file" block from the USPTO Open Data Portal is empty, and my independent web checks of PTAB/TrialTrack-style dockets surfaced no IPR, PGR, or CBM naming this patent — so the breakdown is 0 active / 0 invalidated / 0 sustained / 0 settled / 0 institution denials. Defensive posture: there is no IPR-based invalidity finding to hand you, and no § 315(e)(2) estoppel to leverage — but the absence of PTAB activity is largely explained by two facts that are better news for a defendant than any IPR would be: (1) the '249 patent is expired (anticipated expiration 2026-02-14, per the Google Patents legal-status data, and USPTO lists it "Expired - Lifetime"), and (2) it has been asserted in only one campaign, against Nokia, where the district court has already construed the key "preemption" limitation in a way that cuts against the patent owner. Do not assume "untested = hardened."


Proceedings on file

None. No AIA trial proceeding (IPR / PGR / CBM) has ever been instituted, filed, or terminated on US 9,749,249 according to the USPTO Open Data Portal record supplied, and no institutional or FWD documents for this patent appear in PTAB public dockets.

  • Type: N/A
  • Filed: N/A
  • Status: No PTAB activity on file
  • Judge panel / grounds / institution decision / FWD / settlement / appeal: N/A — there is no FWD to quote and no CAFC docket, because no trial was ever instituted.

I want to be explicit about what I checked, because several search hits look related but are not this patent:

  • IPR2025-01365 and IPR2025-01379 reference a different "'249 patent" — one that issued 2019-05-21, in the VoiceBox Technologies portfolio (petition material). That is not US 9,749,249. Do not cite it.
  • IPR2025-01437 (Google LLC v. K.Mizra LLC) is on US 9,516,048, a different K.Mizra patent (docket entry).
  • IPR2026-00254 (Google v. K.Mizra) is on US 8,144,717 (Docket Alarm).
  • IPR2021-00593 (Cisco v. K.Mizra) — FWD, Fed. Cir. vacatur/remand, and settlement — is on yet another patent in a different K.Mizra family.

None of these involve US 9,749,249. K.Mizra is a heavy PTAB defendant generally; it just has not been hit on this patent.

Collateral activity that matters more than a PTAB docket (not AIA trial proceedings)

1. Ex parte reexamination request — filed, outcome unconfirmed.
The Google Patents legal-events feed for US 9,749,249 shows a Request for Reexamination filed 2026-01-27, effective date 2025-11-13. This is a Central Reexamination Unit proceeding under 35 U.S.C. §§ 301–307, not a PTAB trial, so it does not appear in the PTAB proceedings list. I could not confirm whether the request was granted (a substantial new question of patentability found), what claims were challenged, the requester's identity, or the control number. Flagging it as a live item to verify in PatentCenter. If a reexam certificate has issued canceling claims, that would change the defensive picture materially.

2. District court litigation — the real battleground.

  • K.Mizra LLC v. Nokia Corporation, Nokia Solutions and Networks Oy, and Nokia of America Corp., No. 2:24-cv-00974 (E.D. Tex., Judge Rodney Gilstrap), complaint filed 2024-11-25 (docket; complaint, Ex. D is the '249 patent).
  • Asserted claims of the '249 patent: 1–3, 5, 7–9, and 11–13 (per Nokia's Preliminary Invalidity Contentions, set out in this filing). Asserted priority date: 2005-02-14.
  • Claim construction: the court rejected K.Mizra's attempt to equate "preemption" with mere "switchover," holding that "preemption of data [or network] traffic on the standby pseudowire" requires traffic on the standby pseudowire and not merely a "switch over" to that wire — while also rejecting Nokia's bid to limit preemption to "dropping" traffic, leaving the term at plain and ordinary meaning (K.Mizra v. Nokia, Dkt. 124). Net effect: narrower than K.Mizra wanted, but no lexicography windfall for Nokia.
  • Nokia's invalidity contentions assert that each asserted claim is invalid under one or more statutory bases (the contentions table is quoted in the same filing). No IPR followed from those contentions on this patent.

3. Litigation-history flag. Google Patents records this family as having litigation and links the Texas Eastern District case above, plus a Darts-IP "first worldwide family litigation" entry for family ID 43928307. No defensive aggregator (e.g., Unified Patents) petition on the '249 patent was found — the Unified Patents hits in my searches are database/portal pages, not petitions against this patent.


Strategic summary

Claim status: everything is UNTESTED at the PTAB. No claim of US 9,749,249 has been canceled, confirmed, or even instituted upon in an AIA trial. Claims 1–18 are all unadjudicated by the Board. The claims actually in play in litigation are 1–3, 5, 7–9, and 11–13; claims 4, 6, 10, and 14–18 appear to be unasserted so far. The only adjudicative narrowing on record is the E.D. Tex. claim construction of "preemption" (Dkt. 124), which requires actual traffic on the standby pseudowire. Separately, the term has run: with a 2006-02-14 non-provisional filing date and a 2026-02-14 anticipated expiration, the patent is expired as of today (2026-09-28), which caps exposure to back damages (subject to the six-year lookback under § 286) and moots injunctive relief entirely. Any pre-suit royalty analysis should be run on that basis, not on a going-forward royalty theory.

Estoppel landscape: no IPR estoppel exists on this patent. Because no IPR was instituted against the '249 patent, § 315(e)(2) estoppel never attached to anyone — no petitioner is barred from re-raising prior-art grounds, and you are not carrying a petitioner's estoppel burden from an earlier filing. That said, two real constraints apply instead of estoppel: (a) § 315(b) — an IPR petition must be filed within one year of service of a complaint alleging infringement of this patent; Nokia was served in late November 2024, so Nokia's own IPR window on the '249 patent closed around 2025-11-26, whereas a newly served defendant has a fresh one-year window; and (b) § 325(d) discretion, which the Board increasingly invokes where the same art or arguments were already before the Office (relevant if the pending ex parte reexam has considered your art). Because the patent is expired, an IPR remains legally available but the practical payoff is cost/settlement leverage rather than injunction avoidance.

Pattern signals. K.Mizra is a serial plaintiff that the PTAB bar knows well — Google has filed a series of IPRs against K.Mizra patents (US 9,516,048; US 8,144,717; others), and Cisco litigated K.Mizra's IPR2021-00593 through an FWD, a Federal Circuit vacatur/remand, and a post-institution settlement. K.Mizra has shown it will fight at the Board and in the Federal Circuit. What is notable here is what didn't happen: despite Nokia serving invalidity contentions and despite K.Mizra's other patents drawing IPRs, no petitioner has challenged the '249 patent at the PTAB, and instead an ex parte reexamination request (effective 2025-11-13) was the vehicle chosen — consistent with a patent old enough and expired enough that an IPR's cost/leverage calculus is poor. That is a meaningful contrast: on K.Mizra's other patents, defendants IPR and win; on this one, they reexam.


Recommended next steps

  • Verify the reexamination before doing anything else. Pull the file wrapper in PatentCenter for US 9,749,249 and confirm: the control number, whether a reexam was ordered, which claims are under reexamination, and whether any reexam certificate has issued. The structured legal-events data shows only "Request for reexamination filed 2026-01-27 (effective 2025-11-13)" — I could not confirm grant or outcome, so treat that as an open item, not a given. If claims 1–3, 5, 7–9, or 11–13 have been canceled by certificate, that defeats the live assertion and you should say so in your first responsive pleading.
  • Lead with expiration and the Dkt. 124 construction. The patent expired 2026-02-14; there is no injunctive exposure, and damages are back-looking only. Pair that with the court's holding that "preemption of data traffic on the standby pseudowire" requires traffic on the standby pseudowire and not merely a switch over to that wire (Dkt. 124) — a construction that narrows every asserted independent claim (1, 7, 12). Non-infringement positions built on "switchover without preemption of standby traffic" now have judicial support in the very case asserting this patent.
  • If you were served within the last year, preserve the IPR option now — but price it realistically. No prior IPR means no estoppel and no § 325(d) "same art, same arguments" problem if your art is fresh. File within the § 315(b) one-year window from service of the complaint; do not let the date drift. Note that an expired patent still supports IPR, but the Board applies a Philips-style construction to expired claims, and your real objective should be leverage and a § 315(e)(2) estoppel shield against the parallel district court case.
  • Do not cite the wrong '249. IPR2025-01365/IPR2025-01379 concern a 2019 VoiceBox patent numbered 7,594,249/its siblings, and IPR2025-01437 and IPR2026-00254 concern US 9,516,048 and US 8,144,717 respectively. Asserting that "the '249 patent has been IPRed" without the full number would be an easy and embarrassing error — anyone checking PTAB E2E will find nothing for 9,749,249, for the simple reason that nothing exists.
  • Monitor for a first-ever IPR. Given the patent's age and the pending reexam, the more likely near-term event is a reexam certificate, not institution of a trial. If your investigation is aimed at a post-2026 challenge, confirm the exact expiration date with any PTA/terminal disclaimer adjustments before assuming the term is fully run.

Bottom line: no PTAB proceedings on US 9,749,249 — zero. The absence is not because the patent is impregnable; it is because the patent expires (2026-02-14), has one active litigation campaign, and drew a reexamination request instead of an IPR. There is no FWD to quote and no claim to point at as "canceled."

Generated 9/28/2026, 7:43:14 PM

Ownership chain (3)

Asserters network →

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

  1. 2010-01-08 · recorded 2014-01-09 · reel 031933/0846 · Assignment

    HAMMERHEAD SYSTEMS, INC.BRIXHAM SOLUTIONS LTD.

    fire-sale

  2. 2017-06-27 · recorded 2017-08-16 · reel 043312/0218 · Assignment

    BRIXHAM SOLUTIONS LTD.GLOBAL INNOVATION AGGREGATORS, LLC

    transfer-to-aggregator

  3. 2019-12-24 · recorded 2020-01-13 · reel 051579/0773 · Assignment

    GLOBAL INNOVATION AGGREGATORS, LLCK.MIZRA LLC

    Correspondent: Daniel J. Friedman

    transfer-to-asserter

Assignment history

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

✓ Generated

I'll start by cross-referencing the assignment records and asserter directories.

Good material. Now let me pin down the bankruptcy, the correspondent firm, and the litigation date.

Inventors

Ping Pan — sole named inventor on US 9,749,249 B2 (application 14/050,078). Listed address at filing/publication: San Jose, CA. Employer at the time the invention was made: Hammerhead Systems, Inc. (Silicon Valley networking start-up). This is corroborated by Brixham's own motion in the N.D. Cal. Juniper litigation, which states that "Pan assigned the rights to the '652 patent to his employer, Hammerhead" (case 3:13-cv-00616, docket doc. 60). Pan is the most prolific inventor in the Brixham portfolio (9 filings per GoodIP), and he later appears as co-inventor with Richard Gitlin on Brixham's "Global IP-based service-oriented network architecture" family (e.g., US 9,485,176).

Unusual patterns: none established for the 12-month window. The 2005 provisional / 2006 non-provisional predate Hammerhead's bankruptcy by roughly four to five years, so inventor departure (if any) is not a "departed within 12 months of filing" pattern. The relevant abnormality here is company-side, not inventor-side — see the bankruptcy finding below. I could not locate any secondary-source evidence of individual inventor departures timed to the sale, so I am not asserting one.

Original assignee

Two entities have a claim to this label, and they should not be conflated:

  • Hammerhead Systems, Inc. — the true original owner at filing (the 2006 parent application 11/354,569 and the 2005 provisional 60/653,065). Hammerhead was an operating company: a well-funded Silicon Valley start-up (Kleiner Perkins-era service-provider networking) that built multi-service edge / service-delivery switch hardware for carrier networks. Per Brixham's own representation in the Juniper litigation, Hammerhead filed bankruptcy and its portfolio of 25 issued or pending applications was sold in the bankruptcy proceeding — Brixham bought it "for a total of $230,000." Status: bankrupt / liquidated (assets sold). I found secondary confirmation that Brixham sued Juniper in Feb 2013 "based on four router patents that it had purchased from former Silicon Valley start-up Hammerhead Systems, Inc. in a bankruptcy sale" (Irell & Manella case studies on the Brixham/Juniper IPRs).
  • Brixham Solutions Ltd. — the entity named on the face of the issued patent (Tortola, British Virgin Islands; per FPO assignee record for US 2014/0100502 A1). Brixham is a non-operating holding/asserting vehicle — a BVI company formed to acquire and monetize the Hammerhead portfolio. It shipped no product; it litigated. Status: still in existence as a licensing/assertion entity, though it divested much of the portfolio to Global Innovation Aggregators in 2017.

I did not find evidence that either Brixham or K.Mizra ever shipped a product embodying claims 1–18.

Assignment timeline

Sourcing note: I could not directly query the Assignment Center UI (no browser session), so the reel/frame numbers, execution and recording dates below come from the Google Patents legal-events mirror of the USPTO assignment dataset for this patent, corroborated where possible against a PTAB-hosted copy of the underlying assignment instrument. Treat reel/frame digits as accurate but verify at the Assignment Center before relying on them in a pleading.

  • 2010-01-08 (executed) / recorded 2014-01-09 — Reel 031933/0846

    • Conveyance: Assignment
    • Assignor: HAMMERHEAD SYSTEMS, INC.
    • Assignee: BRIXHAM SOLUTIONS LTD. (British Virgin Islands)
    • Correspondent: not surfaced in the sources I could access (Google Patents legal events do not expose correspondent names; I could not open the reel image). I am not going to guess at this.
    • Context: Bankruptcy fire-sale — purchase of the entire 25-asset Hammerhead portfolio out of Hammerhead's bankruptcy proceeding for ~$230,000; recorded only in 2014, alongside Brixham's Feb 2013 assertion campaign, consistent with a chain-cleaning recordation.
  • 2017-06-27 (executed) / recorded 2017-08-16 — Reel 043312/0218

    • Conveyance: Assignment
    • Assignor: BRIXHAM SOLUTIONS LTD.
    • Assignee: GLOBAL INNOVATION AGGREGATORS LLC (Delaware)
    • Correspondent: not surfaced in accessible sources.
    • Context: Transfer to an aggregation vehicle — Brixham moved multiple patents (this one, plus the "Application wire" family, US 9,843,509 / US 10,411,999) into a Delaware LLC holding structure; prosecution correspondence for Brixham/GIA patents was handled by BrainSpark Associates, LLC, Chandler, AZ (Customer No. 98618) — flagged because BrainSpark is the attorney of record shown on the US 2014/0105002 A1 publication, not a product company.
  • 2019-12-24 (executed) / recorded 2020-01-13 — Reel 051579/0773

    • Conveyance: Assignment ("Assignment of Patents and Patent Rights")
    • Assignor: GLOBAL INNOVATION AGGREGATORS, LLC (Delaware LLC)
    • Assignee: K.MIZRA LLC (Delaware LLC; principal place of business stated in the instrument as 2160 Century Park East #707, Los Angeles, CA 90067)
    • Correspondent: DANIEL J. FRIEDMAN, record address 420 Lexington Avenue, Suite 2400, New York, NY 10170; email DFRIEDMAN@CTSWLAW.COM; tel 212-586-5800. Flag: this correspondent recurs — the same Daniel J. Friedman / same Lexington Avenue address appears as correspondent on the GIA→K.Mizra batch recordings covering many sibling patents in the same bundle (e.g., US 8,670,331, US 8,548,324), i.e. a single repeat-player attorney filing the transfer paperwork for a whole NPE acquisition rather than a one-off. (Caveat: I verified this correspondent on the batch instrument covering this patent; I did not independently verify the correspondents on reels 031933/0846 and 043312/0218, so I am not asserting cross-chain recurrence for those two links.)
    • Context: Transfer-to-asserter — the instrument conveys "all causes of action and enforcement rights … including, without limitation, all rights to pursue damages, injunctive relief and other remedies for past and future infringement," i.e. an assertion-ready conveyance of a bulk patent bundle.

Non-assignment legal events worth pinning to this chain (not assignments): maintenance fees paid 2021-02-16 (4th yr) and 2025-02-18 (8th yr); request for reexamination filed, entered 2026-01-27, effective 2025-11-13 (Google Patents "Legal Events"); anticipated expiration 2026-02-14 (20 years from the 2006 parent 11/354,569).

Timeline diagram

timeline
    title Ownership of US 9749249
    2005 : Provisional filed by Hammerhead
    2006 : Non-provisional filed
    2010 : Hammerhead bankruptcy sale to Brixham
    2011 : Parent 7940652 patent issued
    2013 : Brixham sues Juniper in N D Cal
    2014 : Brixham assignment recorded
    2017 : Assigned to Global Innovation Aggregators
    2019 : Assigned to K Mizra LLC
    2024 : K Mizra sues Nokia in E D Tex
    2026 : Reexamination requested

(Note: the 2014 row reflects recordation of the 2010 executed assignment; I split execution from recording elsewhere rather than cramming both years into one row.)

NPE / troll-pattern signals

  1. Shell-entity transfer — PRESENT. Documented twice, on the reels themselves: Hammerhead Systems (operating company, in bankruptcy) → Brixham Solutions Ltd., a BVI entity with no products, reel 031933/0846 (exec 2010-01-08 / rec 2014-01-09), per Brixham's own admission that it was formed "to purchase the rights to a patent portfolio … during a bankruptcy proceeding"; then Brixham → Global Innovation Aggregators LLC, a Delaware single-purpose aggregation LLC, reel 043312/0218 (exec 2017-06-27); then GIA → K.Mizra LLC, a Delaware LLC whose recorded address is a Century Park East suite, reel 051579/0773 (exec 2019-12-24). Brixham's "IP/Licensing" posture is not merely inferable from its name — it is evidenced by its Feb 2013 N.D. Cal. infringement suit against Juniper.

  2. Known asserter in the chain — PRESENT. K.Mizra LLC is flagged as an NPE/PAE by the Unified Patents litigation portal ("Plaintiff Entity Type: NPE (Patent Assertion Entity)"; e.g., 8:25-cv-00027, 2025-01-06, C.D. Cal.) and appears in the Stanford NPE Litigation Database under the "Acquired patents" asserter category (e.g., K.Mizra v. NXP, 7:25-cv-00557, W.D. Tex.). Brixham Solutions Ltd. is itself an asserting owner (Brixham v. Juniper Networks, N.D. Cal. 3:13-cv-00616, filed Feb 2013), so two successive owners in the chain are asserters, not just the current one.

  3. Repeat correspondent across the chain — PRESENT (one link directly verified). Daniel J. Friedman, 420 Lexington Ave., Suite 2400, New York, NY 10170 (DFRIEDMAN@CTSWLAW.COM), is the correspondent of record on the GIA → K.Mizra transfer (reel 051579/0773, signed 01/13/2020), and the identical correspondent name/address recurs on the GIA→K.Mizra batch recordings for other patents in the same conveyance. That is recurrence in the acquirer's filing program rather than documented recurrence across all three links, so I have scoped this call deliberately. I was not able to verify a correspondent for reels 031933/0846 or 043312/0218.

  4. Cascading transfers — NOT PRESENT on timing. The two LLC-to-LLC links are ~30 months apart (Brixham→GIA effective 2017-06-27; GIA→K.Mizra effective 2019-12-24), which fails the "<24 months between consecutive chained-LLC transfers" test. Structurally the chain is a cascade (three successive holders), but the temporal element of this specific signal is not met, so I am not calling it.

  5. Pre-litigation transfer — NOT PRESENT for this patent. The K.Mizra assignment was executed 2019-12-24; the earliest suit I can document naming the '249 patent is the Texas Eastern District case 2:24-cv-00974 (2024, against Nokia). That gap is ~4–5 years, far outside the 6-month window. (K.Mizra's broader campaign against location and zero-trust patents began June 2021, ~18 months post-acquisition, but that concerns other patents, not this one.)

  6. Bankruptcy fire-sale — PRESENT (strongest single signal). Hammerhead Systems' portfolio of 25 issued/pending applications was sold out of bankruptcy for $230,000, as recited in Brixham's own motion quoted at N.D. Cal. 3:13-cv-00616 (docket doc. 60), and independently described by Irell & Manella as patents "that it had purchased from former Silicon Valley start-up Hammerhead Systems, Inc. in a bankruptcy sale." Reel 031933/0846 is the recording of that sale.

  7. Privateering — NOT PRESENT. Privateering requires the operating company to fund/benefit from an NPE asserting on its behalf. Here Hammerhead was liquidated and received a one-time $230K sale price; it had no continuing stake, and the subsequent assertion campaigns (Brixham v. Juniper; K.Mizra's campaigns) ran for the buyers' benefit, not Hammerhead's. Juniper is a former Hammerhead-adjacent networking competitor, but that coincidence is not evidence of sponsorship.

  8. Defensive aggregator — NOT PRESENT. The chain terminates at K.Mizra LLC, an active asserter, not at RPX, AST, LOT, Unified Patents, or OIN. Separately, note the reexamination request entered 2026-01-27 (effective 2025-11-13) — an adverse challenge to the patent, but a challenge is not a neutralizing acquisition, and no assignment accompanied it.

Verdict

NPE — high confidence.

The chain contains at least three strong, reel-cited signals: (i) a bankruptcy fire-sale origin — Hammerhead's 25-asset portfolio sold for $230,000, recorded at reel 031933/0846 (exec 2010-01-08), as recited in Brixham's own court filing; (ii) successive shell/licensing-only transfers from the operating company to Brixham Solutions Ltd. (BVI), then to Global Innovation Aggregators LLC (reel 043312/0218, exec 2017-06-27), then to K.Mizra LLC (reel 051579/0773, exec 2019-12-24), each an assertion-ready conveyance; and (iii) a documented asserter at the end of the chain, K.Mizra LLC, which Unified Patents classifies as an NPE/PAE and which has asserted this very patent (E.D. Tex. 2:24-cv-00974, 2024). Brixham's own Feb 2013 suit against Juniper confirms the second link was an asserting owner as well, so this is a two-asserter chain rather than a single late-stage flip. The two signals that do not fire — cascading transfers within 24 months and pre-litigation transfer within 6 months — are timing-based and fail on the actual dates, so they are not part of the basis for this verdict.

Verification link (Assignment Center, search by patent number 9749249): https://assignmentcenter.uspto.gov/ — underlying indexed record also reachable via https://assignment.uspto.gov/patent/index.html. Cross-checks used above: Google Patents legal events for US9749249B2 (https://patents.google.com/patent/US9749249B2/en), the K.Mizra assignment instrument as republished in PTAB filings (https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558294](/patent/1558294)/), Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist), and the Stanford NPE Litigation Database entry for K.Mizra LLC.

Confidence limits, stated plainly: I did not open the reel images for 031933/0846 or 043312/0218, so the correspondents on those two links are unknown to me — if the same attorney filed all three recordings, that would upgrade signal 3 from scoped to chain-wide, and that is the single highest-value thing to pull next. I also did not independently verify the full corporate name behind the ctswlaw.com domain.

Generated 9/28/2026, 7:43:47 PM

Prior art

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

✓ Generated

I'll research this systematically, starting with the USPTO record and then the cited prior art.

I have the authoritative citation list from the patent text. Let me now gather details on the most relevant references.

Prior-Art Analysis — US 9,749,249 B2 ("Pseudowire protection using a standby pseudowire")

A. Method, scope, and one inherited caveat

I worked from the authoritative full patent text you supplied (Google Patents fetch, 2026-09-28), which contains the complete front-page citation list: 51 U.S. patent references, 23 non-patent citations, and 1 patent-family citation. I cross-checked the identity of the number against the patent text and USPTO-hosted material (PTACTS/PTAB documents surfaced for the same technology). I did not have direct PatentCenter/PAIR or PACER access; I could not pull the actual examiner's PTO-892 forms or the § 102/§ 103 rejections and traversals from the file wrapper, so the "which claims it potentially anticipates" call below is my technical reading of each reference against the issued claim set, not a quotation of the examiner's grounds.

Inherited caveat carried forward (unresolved): the earlier-generated summary flagged a search-result snippet that tied "US-20040114595-A1" to K. Mizra LLC and the title "Pseudowire Protection Using a Standby Pseudowire." My searches reproduce that artifact (a Unified Patents page for US-20040114595-A1 lists assignee "K Mizra LLC" and the '249 title). This is a database conflation artifact — US 2004/0114595 A1 is Doukai's "Restoration and protection method and an apparatus thereof." I flag it rather than repeat it as fact, consistent with the operating rule to interpret identifiers literally.

Statutory framing. Earliest priority is 2005-02-14 (provisional 60/653,065). This is a pre-AIA case, so:

  • US patents/applications published are prior art under § 102(e) as of their filing date (if filed before the critical date);
  • printed publications are prior art under § 102(b) only if published more than one year before the 2006-02-14 filing of the parent (i.e., before ~2005-02-14), or under § 102(a) if before the 2005-02-14 priority.
  • Anything effective on or after 2005-02-14 is not § 102 art (notably the inventor's own "Pseudo Wire Protection" I-D of July 2006, and the March 2005 RFCs).

Given space, I give the full citation list with dates and a § 102 verdict column, then walk through the ~10 references that actually matter.


B. Tier 1 — References that come closest to anticipation

These are the ones to read first. Each is mapped to the elements of independent claims 1 / 7 / 12, whose collective gist is: (a) source detects an ack that its config data was accepted; (b) config data specifies priority, domain type, and standby mode; (c) domain type = single vs. multiple carrier networks; (d) establish standby PW per the standby mode/domain type; (e) decide whether to preempt traffic on the standby PW based on priority.

B1. US 2006/0047851 A1 — Voit et al. (Cisco Technology, Inc.)

"Computer network with point-to-point pseudowire redundancy" — filed 2004-08-25; published 2006-03-02. (§ 102(e) art as of 2004-08-25.)

  • Description: VPLS/VPWS network with provider-edge devices connected by PWs; discloses a primary/backup pseudowire arrangement across edge domains, with a bidding protocol to elect a primary n-PE for a single pseudowire path. Directly on point for pseudowire redundancy and selection of a standby path.
  • § 102 reading: Strongest single reference for the establish-a-standby-pseudowire concept. Claims 1, 7, 12 — the "standby pseudowire" and primary-protection concepts are taught. Falls short on (b)–(c): I see no teaching of a configuration parameter carrying a "domain type" field that distinguishes single vs. multiple carrier networks, nor of the acceptance-acknowledgment-driven establishment recited in (a)/(d). Therefore not a clean § 102 anticipation, but excellent § 103 fodder combined with B5.

B2. US 2006/0090008 A1 — Guichard et al. (Cisco Technology, Inc.)

"Pseudowire termination directly on a router" — filed 2004-10-21; published 2006-04-27. (§ 102(e) art as of 2004-10-21.)

  • Description: Pseudowire termination/stitching on routers; the same Guichard work was treated by third parties as disclosing multi-segment pseudowire protection via pre-computed backup paths and switching to a backup pseudowire on failure (see the PTAB/IPR petitions quoting Guichard in the '775-proceeding materials).
  • § 102 reading: Good on failure detection → switch to backup pseudowire (relevant to claims 2–4 dependents). Weaker on the priority/domain-type/standby-mode configuration trio of independent claims 1/7/12. Not anticipatory for the independent claims as issued.

B3. US 7,804,767 B1 — Owens et al. (Tellabs Operations, Inc.)

"Protection/restoration of MPLS networks" — priority 1999-10-25; filed 2000-10-25; granted 2010-09-28. (Examiner-cited — marked "*" in the record.)

  • Description: Working path + pre-negotiated protection path in an MPLS network; failure indication signals; protection-switch LSR reroutes traffic; explicitly states "a protection priority could be used as a differentiating mechanism for premium services." Introduces pre-negotiated/dedicated protection, dynamic vs. static, and priority-based resource displacement.
  • § 102 reading: Strong on (e) priority-based protection/preemption logic and on standby/protection-path establishment. But it protects MPLS LSPs, not pseudowires, and lacks the domain-type and acceptance-ack elements. Claims 1, 7, 12 are implicated conceptually; § 103 combination is the realistic route, likely paired with B1/B2 (pseudowire context) and B5 (domain concept).

B4. US 7,360,534 B1 — Cisco Technology, Inc.

"Method and system for stateful switch-over in a high-availability point to point system" — filed 2002-09-30; granted 2008-04-22. (Examiner-cited.)

  • Description: Stateful switch-over between active/standby in a point-to-point system — i.e., preserving state so traffic can be handed to the standby entity.
  • § 102 reading: Bears on the standby-mode / switchover aspects (claim 1 element "according to the standby mode"; dependent claims 2–3). Does not teach pseudowire-specific config or domain type. Not anticipatory; relevant to the cold/warm/hot standby concept later recited in claims 17/18.

B5. US 7,180,866 B1 — Chartre et al. (Nortel Networks Limited)

"Rerouting in connection-oriented communication networks and communication systems" — filed 2002-07-11; granted 2007-02-20. (Examiner-cited.)

  • Description: Domain-Based Rerouting (DBR) in a PNNI network: the network is a global domain subdivided into local domains; rerouting is performed within a reroute domain, and if the connection cannot be re-established in one domain, rerouting is requested in the other domain.
  • § 102 reading: This is the most relevant reference for the "domain type" limitation — but note the mismatch: Chartre's "domain" is a rerouting/PNNI hierarchy, whereas claim 1 requires "domain type indicates whether the node devices are coupled to a single carrier network or multiple carrier networks." That gap (parent-carrier/AS count) is the one the patentee leans on. Claims 1, 7, 12 implicated for the "domain" concept; not anticipatory.

B6. US 7,738,876 B2 — Cisco Technology, Inc. (Family citation)

"Inter-autonomous-system virtual private network with autodiscovery and connection signaling" — filed 2005-02-11 (one business day before the '249 priority); granted 2010-06-08.

  • Description: Inter-AS VPN with autodiscovery and signaling — i.e., establishing service connections across multiple autonomous systems / carrier networks.
  • § 102 reading: Listed as a family cite rather than an examiner cite, but it is chronologically the closest art to the "single carrier network vs. multiple carrier networks" limitation that distinguishes independent claims 1/7/12. Its 2005-02-11 filing is after the 2005-02-14 priority? — no: 2005-02-11 is before 2005-02-14, so it can be § 102(e) art. Worth pressing on.

C. Tier 2 — The full citation list with dates and § 102 impact

Below is every U.S. patent reference cited on the face of the '249, with its filing/publication (or grant) dates as they appear in the record and my § 102 assessment. "Tier-2 impact" is deliberately conservative: most of these are background or single-element references that, alone, cannot anticipate the issued independent claims.

# Citation Filed / Published Brief description Claims potentially implicated (§ 102)
1 US 2003/0002482 A1 (Kubler) 1995-10-05 / 2003-01-02 Hierarchical data collection network for packetized voice None realistic; background
2 US 5,920,705 A (Nokia IP) 1996-01-31 / 1999-07-06 Dynamically shifting between routing and switching packets None realistic
3 US 6,167,051 A (Toshiba) 1996-07-11 / 2000-12-26 Network node / packet transfer method Background
4 US 2003/0039237 A1 (Forslow) 1997-09-25 / 2003-02-27 Common access, packet- vs. circuit-switched services Background
5 US 6,347,088 B1 (Fujitsu) 1997-10-28 / 2002-02-12 Cell transmission with audio interworking Background
6 US 6,430,184 B1 (Top Layer) 1998-04-10 / 2002-08-06 High-speed pattern matching for packet switching Background
7 US 7,200,104 B2 (Cisco) 1999-01-15 / 2007-04-03 Restoring a virtual path in an optical network using 1+1 protection Claim 6 (1+1 protection scheme, "same traffic sent over two pseudowires / receiver selects one")
8 US 6,546,427 B1 (IBM) 1999-06-18 / 2003-04-08 Streaming multimedia with automatically switchable content sources Claims 2–3 (switchover) generally
9 US 6,813,271 B1 (Nortel) 1999-09-30 / 2004-11-02 ATM cell transmission in DVB Background
10 US 6,680,943 B1 (Nortel) 1999-10-01 / 2004-01-20 Establishing bi-directional communication sessions Background (setup/signaling)
11 US 6,574,477 B1 (Lucent) 1999-10-06 / 2003-06-03 Dynamic load balancing in wireless message processing Weak — priority/load
12 US 7,804,767 B1 (Tellabs) 1999-10-25 / 2010-09-28 See B3 1, 7, 12 (protective path + priority) — not anticipatory alone
13 US 6,665,273 B1 (Cisco) 2000-01-11 / 2003-12-16 Dynamically adjusting MPLS TE tunnel bandwidth Bandwidth/priority background
14 US 2001/0021175 A1 (Haverinen) 2000-03-13 / 2001-09-13 Load balancing in mobile IP Background
15 US 2001/0023453 A1 (Ericsson) 2000-03-15 / 2001-09-20 Method and arrangement for flow control Background
16 US 6,845,389 B1 (Nortel) 2000-05-12 / 2005-01-18 Broadband multi-user communication sessions Background
17 US 2002/0146026 A1 (Unitt) 2000-05-14 / 2002-10-10 Data stream filtering Background
18 US 6,621,793 B2 (Ericsson) 2000-05-22 / 2003-09-16 Application-influenced policy (QoS policy) Weak — policy/priority signaling
19 US 7,050,396 B1 (Cisco) 2000-11-30 / 2006-05-23 Automatically establishing differentiated-services treatment of flows Weak — priority/QoS field signaling
20 US 6,751,684 B2 (Owen) 2000-12-21 / 2004-06-15 Allocating bandwidth across point-to-point links Bandwidth/priority background
21 US 2002/0112072 A1 (Maple Optical) 2001-02-12 / 2002-08-15 Fast re-routing of data Claims 2–4 (reroute/switchover) generally
22 US 2002/0141393 A1 (Eriksson) 2001-04-02 / 2002-10-03 Concurrent use of multiple paths to an IP network Multi-path/standby concepts
23 US 2004/0114595 A1 (Doukai) 2001-04-19 / 2004-06-17 Restoration and protection method and apparatus Claims 2–4 (restoration/switchover) — see § D note
24 US 2004/0174865 A1 (O'Neill) 2001-06-26 / 2004-09-09 Messages/control for resource allocation & flow admission Weak — reservation/admission control
25 US 2003/0117950 A1 (Huang) 2001-12-26 / 2003-06-26 Link redial for mesh protection Claims 2–4 (protection switching) generally
26 US 7,180,866 B1 (Nortel) 2002-07-11 / 2007-02-20 See B5 (domain-based rerouting) 1, 7, 12 ("domain type") — not anticipatory
27 US 2005/0018605 A1 (Foote) 2002-07-22 / 2005-01-27 MPLS edge service extraction Background (MPLS/PW)
28 US 2006/0046658 A1 (Cruz) 2002-09-05 / 2006-03-02 Scheduling methods for wireless networks Background
29 US 7,363,534 B1 (Cisco) 2002-09-30 / 2008-04-22 See B4 (stateful switchover) Standby-mode aspects; claims 17/18 context
30 US 2005/0044262 A1 (Cisco) 2002-11-21 / 2005-02-24 Interconnecting heterogeneous L2 VPN applications Background (L2VPN/PW)
31 US 2004/0105459 A1 (Mannam) 2002-11-30 / 2004-06-03 MPLS over SONET/SDH/OTN at the GFP layer Background (PW over media)
32 US 2004/0133692 A1 (Hexago) 2003-01-07 / 2004-07-08 IPv6-over-IPv4 tunnel setup protocol Background (tunnel setup negotiation)
33 US 6,985,488 B2 (Ciena) 2003-01-15 / 2006-01-10 Transporting packet data over an optical network Background
34 US 2004/0156313 A1 (Hofmeister) 2003-02-03 / 2004-08-12 Data-flow ingress/egress admission control in a provider network Priority/admission-control background
35 US 2005/0237927 A1 (Kano) 2003-05-14 / 2005-10-27 Transmission apparatus Background
36 US 2004/0252717 A1 (Corrigent) 2003-06-13 / 2004-12-16 Multiprotocol media conversion Background
37 US 7,436,782 B2 (Alcatel-Lucent) 2004-03-25 / 2008-10-14 Full-mesh LSP / full-mesh T-LDP provisioning between PEs for L2/L3 VPNs Background (T-LDP provisioning of PWs)
38 US 2005/0220148 A1 (Delregno) 2004-04-05 / 2005-10-06 TDM communications over a packet-switched access network Background (TDM PW emulation)
39 US 2006/0002423 A1 (Rembert) 2004-06-30 / 2006-01-05 Direct interworking between PWs of different services Background (PW interworking)
40 US 2006/0018252 A1 (Alcatel) 2004-07-20 / 2006-01-26 Load balancing in a VPN Weak — load balancing
41 US 2006/0047851 A1 (Cisco) 2004-08-25 / 2006-03-02 See B1 (point-to-point PW redundancy) 1, 7, 12 — closest PW reference; still not anticipatory
42 US 2006/0090008 A1 (Guichard, Cisco) 2004-10-21 / 2006-04-27 See B2 (PW termination on router; backup PW) 1, 7, 12 + claims 2–4
43 US 2006/0146832 A1 (Cisco) 2005-01-05 / 2006-07-06 Transporting data using PWs over a bridged network Background (PWE/bridged)
44 US 2006/0233167 A1 (Alcatel) 2005-04-19 / 2006-10-19 Negotiation of datapath treatment for interworked traffic Post-priority (2005-04-19 > 2005-02-14) — not § 102 art
45 US 2007/0053366 A1 (Booth) 2005-09-08 / 2007-03-08 L2–L3 PW interworking Post-priority — not § 102 art
46 US 2007/0127479 A1 (Sinicrope) 2005-12-05 / 2007-06-07 Distributed pseudo-wire signaling Post-priority — not § 102 art
47 US 2007/0206607 A1 (Chapman) 2006-03-06 / 2007-09-06 Resource reservation and admission control for IP network Post-priority — not § 102 art
48 US 2008/0031129 A1 (Arseneault) 2006-08-07 / 2008-02-07 Smart Ethernet edge networking Post-priority — not § 102 art
49 US 7,697,528 B2 (Nortel) 2005-11-01 / 2010-04-13 Multilink trunking for encapsulated traffic Post-priority — not § 102 art
50 US 7,940,652 B1 (Brixham) 2005-02-14 / 2011-05-10 The '249's own parent patent Same family — not § 102 art (not "by another")
51 US 8,582,427 B2 (Brixham) 2005-02-14 / 2013-11-12 The '249's own parent patent Same family — not § 102 art
— US 7,738,876 B2 (Cisco) 2005-02-11 / 2010-06-08 See B6 (inter-AS VPN autodiscovery/signaling) 1, 7, 12 ("multiple carrier networks")

Note: the Google Patents page prints two overlapping lists ("Citations (50)" and "Patent Citations (51)"). The union is reflected above; the extra entry is a duplicate/ordering artifact, not a distinct reference.


D. Non-patent literature (also cited; § 102(b)/(a) candidates)

These matter because several are baseline standards against which the "config parameter" and "LDP signaling" limitations read.

Reference Date Relevance to the '249
Bryant & Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985 Mar. 2005 Defines PW architecture; post-priority technically, but the underlying I-D predates it
Martini et al., "Pseudowire Setup and Maintenance Using LDP," RFC 4447 Mar./Apr. 2005 (earlier drafts 2004) The LDP-based PW signaling underpinning claim 14 ("establishing using a label distribution protocol")
Andersson et al., "LDP Specification" (draft-ietf-mpls-ldp-06) Jan. 2001 (RFC 5036) The LDP session/Hello-adjacency framework described in the specification
Martini et al., "Dynamic Placement of Multi Segment Pseudo Wires" Jun. 2006 Multi-segment PW placement — post-priority
Martini et al., "Segmented Pseudo Wire" I-D Jul. 2007 Post-priority
Martini et al., Encapsulation Methods for Transport of {Ethernet/Frame Relay} over MPLS 2006 PW encapsulation background
Pan et al., "Pseudo Wire Protection" I-D Jul. 2006 Inventor's own draft — same-inventor, post-priority; not § 102 art but reveals the intended scope
Pan, "Dry-Martini: Supporting Pseudo-wires in Sub-IP Access Networks" I-D Jul. 2005 Inventor; post-priority
Metz et al., "Pseudowire Attachment Identifiers for Aggregation and VPN Autodiscovery" Feb. 2006 Attachment-identifier signaling — post-priority
Blake et al., "An Architecture for Differentiated Services" (RFC 2475) Dec. 1998 Diff-Serv priority/holding-vs-setup priority antecedent for the priority field
Braden et al., "Integrated Services in the Internet Architecture" (RFC 1633) Jun. 1994 Reservation/priority background
Rosen et al., "BGP-MPLS IP VPNs" Feb. 2006 Inter-AS VPN context — post-priority
Rosen et al., "PWE3 Congestion Control Framework" Mar. 2004 Congestion/bandwidth-overflow context for claim 4
Chen, "The LSP Protection/Restoration Mechanism in GMPLS" Oct. 2002 Protection/restoration switching model
Theimer et al., "Requirements for OAM Functionality in MPLS" Oct. 1999 OAM/fault detection background
Vasseur et al., PCE charter May 2007 Post-priority; not art
McPherson et al., PWE3 charter page Jun. 2007 Post-priority; not art
Shah et al., "ARP Mediation for IP Interworking of Layer 2 VPN" Jul. 2007 Post-priority; not art
Afferton et al., "Ethernet Transport Over Wide Area Networks" (IEEE Comm. Mag.) Mar. 2004 Metro Ethernet/PW transport background
Harry Newton, Newton's Telecom Dictionary (23rd ed.) Mar. 2007 Claim-construction aid ("pseudowire," "preemption" definitions)
Office Action dated Mar. 1, 2013 for U.S. Appl. No. 13/038,282 2013-03-01 This is the parent's prosecution — the single most useful document I could not retrieve; it would show the actual § 102/§ 103 grounds

E. Bottom line on § 102 anticipation

No citation in the '249 record appears to anticipate the issued independent claims (1, 7, 12) on its own. The reason is structural: independent claims 1/7/12 require the combination of (i) acknowledgment-gated establishment of the standby PW, (ii) a configuration parameter that specifies a domain type meaning single-vs-multiple carrier networks, and (iii) priority-based preemption of traffic on the standby PW. The cited art is strong on individual pieces —

  • PW redundancy / backup PW: US 2006/0047851 A1 (B1), US 2006/0090008 A1 (B2);
  • protection-path + priority: US 7,804,767 B1 (B3), US 7,180,866 B1 (B5);
  • standby-mode switchover: US 7,363,534 B1 (B4), US 7,200,104 B2;
  • multiple-carrier/inter-AS scope: US 7,738,876 B2 (B6), US 7,180,866 B1 (B5);
  • PW over LDP: RFC 4447 / LDP Specification;

— but none shows the specific "domain type" field in a PW protection configuration parameter, and none shows the acceptance-then-establish handshake as claimed. That is precisely the "gap" the patentee is relying on, and it is consistent with why the family twice survived to issuance (US 7,940,652 and US 8,582,427) and why the commercial dispute centers on claim construction ("preemption of data traffic on the standby pseudowire") rather than on anticipation.

Most likely intended rejection theory (had I the file wrapper): § 103, not § 102 — e.g., B1 or B2 (PW redundancy) in view of B3 (priority-driven protection switching) and/or B5/B6 (domain scope), optionally with RFC 4447 for LDP establishment.


F. Caveats and what I could not verify

  1. No PTO-892 / office-action text retrieved. My per-claim § 102 mapping is a technical reading, not the examiner's ground of rejection. The Mar. 1, 2013 Office Action for 13/038,282 (cited in the record) is the document that would settle this.
  2. "Cited by" vs. "relied upon." The record distinguishes examiner-cited (*) from third-party-cited (†) references; I treated US 7,804,767, US 7,180,866, US 7,363,534, US 2004/0133692, and US 2004/0156313 as examiner-cited based on the asterisk convention, but Google Patents' markings are not a legal conclusion.
  3. Dating caution. Several RFCs are dated March 2005, straddling the 2005-02-14 priority; only their earlier Internet-Draft versions would be § 102 art. Likewise US 2006/0233167, US 2007/0053366, US 2007/0127479, US 2007/0206607, US 2008/0031129, and US 7,697,528 were filed after the priority date and are not § 102 art against this patent.
  4. Family references are not prior art. US 7,940,652 B1 and US 8,582,427 B2 are the same-inventor/same-family parents; they cannot anticipate or render obvious the '249.
  5. The US 2004/0114595 (Doukai) / "K. Mizra" artifact noted in § A should be disregarded as a database conflation; the literal identifier resolves to Doukai's restoration/protection application.

Sources: authoritative full patent text (https://patents.google.com/patent/US9749249/en); https://patents.justia.com/patent/[9749249](/patent/9749249); Google Patents/Justia/Freepatentsonline pages for US 2006/0047851 A1, US 2006/0090008 A1, US 7,804,767 B1, US 7,180,866 B1, US 7,363,534 B1, US 7,738,876 B2, US 7,200,104 B2, US 8,130,637 B1, US 7,796,504 B1; USPTO PTACTS petition documents referencing Guichard et al. multi-segment pseudowire protection (IPR2020-01226 record).

Generated 9/28/2026, 7:43:48 PM

Obviousness

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

✓ Generated

I'll ground a few key prior-art references before building the § 103 analysis.

Flag before we start (contradiction in the record)

The operating rules for this session state today is 2026‑09‑28; the current task header states April 26, 2026. I flag this rather than silently pick one. It matters here only in that the reexamination "RR" legal event (effective 2025‑11‑13) and the E.D. Tex. claim‑construction order are both treated as already in the past under either date.

I also flag one methodological limit up front: this § 103 analysis is built from the prior‑art section of the Google Patents page for US9749249B2 (the 50‑/51‑entry "Patent Citations" list, the 23 "Non‑Patent Citations," the "Family Cites Families" entry, and the "Cited By" lists), supplemented by targeted web retrieval of the key references. I did not pull full specs of every reference; where I characterize a reference's disclosure it is from the abstract/claims/snippets actually retrieved, and I say so.


Obviousness of U.S. 9,749,249 under 35 U.S.C. § 103

1. Legal framework and the art‑relevant date

  • Pre‑AIA § 103 governs. The '249 patent's earliest effective filing is 2006‑02‑14 (US 11/354,569), claiming priority to provisional US 60/653,065 filed 2005‑02‑14. This predates the AIA first‑inventor‑to‑file regime.
  • The controlling date for prior‑art status is therefore on or about 2005‑02‑14. Anything published/filed after that date is not § 102 prior art absent § 102(e) grace‑style considerations — and this matters a great deal here, because a large fraction of the "Non‑Patent Citations" on this page post‑date the priority date and appear to have been cited during later prosecution/reexamination of the family (see § 2.3).
  • Graham factors apply: scope and content of the prior art; differences between prior art and claims; level of ordinary skill; secondary considerations.
  • KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) governs motivation. Relevant rationales: (A) combining known elements according to known methods to yield predictable results; (C) use of a known technique to improve a similar device in the same way; (D) applying a known technique to a known device ready for improvement; (E) "obvious to try"; (F) design incentives / market forces; (G) predictable variation. Critically, KSR also holds that where the specification admits a known problem and the improvement is a known technique for solving it, that is strong evidence of obviousness.
  • Claim construction cross‑reference: per the previously‑generated sections, the E.D. Tex. court construed "preemption of data [or network] traffic on the standby pseudowire" as requiring traffic on the standby pseudowire (not merely "a switch over" to it) but declined to narrow "preemption" to "dropping." This construction is dispositive‑adjacent to the § 103 question because, as shown below, the GMPLS/MPLS‑TE art is specifically about lower‑priority traffic riding on protection resources being preempted when the protection path activates — i.e., literally "data traffic on the standby pseudowire" being preempted.

Level of ordinary skill (proposed): a B.S. in EE/CS or equivalent plus 3–5 years' experience in carrier packet networking, including MPLS, LDP/RSVP‑TE, Layer‑2 VPNs/PWE3, and QoS/admission control. The inventor's own Background confirms these are the pertinent arts.


2. The prior‑art landscape from this page

2.1 The invention's core limitations

Stripped to essentials, independent claim 1 (and its apparatus/CRM twins, claims 7 and 12) requires:

  1. A source node device detects acknowledgement data confirming the destination accepted configuration data the source sent;
  2. That configuration data specifies three things for a standby pseudowire: a priority, a domain type (single carrier network vs. multiple carrier networks), and a standby mode;
  3. On acceptance, the standby PW is established in accordance with the standby mode and domain type;
  4. The node determines whether to initiate preemption of data traffic on the standby pseudowire based at least in part on the priority.

Note that the claimed "priority" is data used to decide preemption of the standby PW's traffic, and the claim does not tie the preemption to any particular comparison, threshold, or trigger. Claims 4/10 and 5/11 (bandwidth exceedance; standby‑priority‑vs‑primary‑priority) and claims 15 ("holding priority"/"setup priority") supply the specifics.

2.2 The core references (all pre‑2005‑02‑14 unless noted)

Ref (as listed on the page) Date What it teaches (per retrieved content) Maps to
US 2006/0047851 A1, Voit et al., Cisco — "Computer network with point‑to‑point pseudowire redundancy" prio. 2004‑08‑25; pub. 2006‑03‑02 Primary PW across an MPLS core plus first and second redundant PWs, with the redundant paths blocked when the primary path is available and unblocked in response to failure of the primary; PW setup between PE devices in a VPLS/VPWS context Standby PW concept; switchover on primary failure
US 7,733,876 B2, Cisco — "Inter‑autonomous‑system virtual private network with autodiscovery and connection signaling" prio. 2005‑02‑11 Distinguishes intra‑ vs inter‑AS VPN topologies and provides autodiscovery + connection signaling across autonomous systems "domain type" (single vs. multiple carrier networks)
US 7,804,767 B1, Tellabs — "Protection/restoration of MPLS networks" prio. 1999‑10‑25 Pre‑planned/pre‑reserved protection LSPs vs. full (post‑failure) rerouting; recovery‑resource activation Standby mode taxonomy; switchover
US 7,360,534 B1, Cisco — "Method and system for stateful switch‑over in a high‑availability point‑to‑point system" prio. 2002‑09‑30 Stateful hot switchover between redundant endpoints Hot standby
US 7,200,104 B2, Cisco — "Method for restoring a virtual path in an optical network using 1+1 protection" prio. 1999‑01‑15 1+1 protection (traffic duplicated; receiver selects) Protection scheme field
US 7,184,866 B1, Nortel — "Rerouting in connection‑oriented communication networks" prio. 2002‑07‑11 Rerouting/restoration in connection‑oriented networks Switchover/restoration
US 6,665,273 B1, Cisco — "Dynamically adjusting MPLS traffic engineering tunnel bandwidth" prio. 2000‑01‑11 MPLS TE bandwidth reservation, reservations at priority levels, admission/re‑reservation Priority + bandwidth‑driven preemption
US 2004/0156313 A1, Hofmeister — "…data flow ingress/egress admission control in a provider network" prio. 2003‑02‑03 Admission control in a provider network based on resource/priority policy Priority‑based admission/preemption
US 2004/0114595 A1, Doukai — "Restoration and protection method and an apparatus thereof" prio. 2001‑04‑19 Protection vs. restoration modes Standby modes
Chen, Z., "The LSP Protection/Restoration Mechanism in GMPLS," Oct. 2002 (examiner‑cited NPL) 2002‑10‑01 Surveys 1+1, 1:1, 1:N, (M:N) LSP protection/restoration; dedicated vs. shared recovery resources; extra‑traffic on shared protection resources; activation of the protection LSP on failure; signaling supports these Protection scheme field; standby resources carrying extra (lower‑priority) traffic
Braden et al., RFC 1633 (IntServ), Jun. 1994 1994 Integrated services architecture; admission control that admits/denies reservations based on available resources and priorities Priority‑based preemption rationale
Blake et al., RFC 2475 (DiffServ), Dec. 1998 1998 Packet classification into priority levels / classes, per‑hop behaviors, and drop precedence Traffic priority as a known technique
Anderson et al., "LDP Specification," Jan. 2001 2001 LDP session/Hello Adjacency machinery; Label Mapping messages as the affirmative response binding a label/FEC "acknowledgement data … accepted"; claim 14 (LDP)
Theimer et al., "Requirements for OAM Functionality in MPLS," Oct. 1999 1999 OAM/fault detection and protection requirements in MPLS Failure detection/switchover
Afferton et al., "Ethernet Transport Over Wide Area Networks," IEEE Comm. Mag., Mar. 2004 2004 Carrier Ethernet transport over packet‑aware metro networks; 1:1/1:N protection concepts Protection schemes
Rosen et al., "PWE3 Congestion Control Framework," Mar. 2004 2004 Congestion handling for PWs Bandwidth‑driven switchover/preemption

2.3 References that are not available as prior art (post‑date 2005‑02‑14) — flagged per the "interpret literally" rule

These appear in the NPL list but, on their stated dates, post‑date the '249 priority date and therefore cannot be relied on for § 103 against these claims:

  • Pan, "Pseudo Wire Protection," Jul. 2006 — this is the applicant's own later draft; it is the closest conceptual match to the '249 disclosure, but it is after the priority date. (Do not cite as prior art; cite only as evidence of what the field was doing.)
  • Pan, "Dry‑Martini…," Jul. 2005 (post‑dates).
  • Martini, "Dynamic Placement of Multi Segment Pseudo Wires," Jun. 2006; Martini, "Segmented Pseudo Wire," Jul. 2007; Martini, "Encapsulation Methods … Ethernet/Frame Relay Over MPLS," 2006.
  • Metz et al., "Pseudowire Attachment Identifiers…," Feb. 25, 2006.
  • Rosen et al., "BGP‑MPLS IP VPNs," Feb. 2006 (the predecessor RFC 2547 (1999) does predate, but it is not the document listed here).
  • Shah et al., Jul. 2007; Vasseur et al., May 2007; McPherson et al., Jun. 2007; Newton's Telecom Dictionary, Mar. 2007.
  • The "Office Action dated Mar. 1, 2013 for U.S. Appl. No. 13/038,282" is prosecution history, not prior art.

Borderline (handle with care): Bryant et al., RFC 3985 PWE3 Architecture (Mar. 2005) and Martini, "PW Setup and Maintenance Using LDP" (Mar. 2005) — the published versions post‑date 2005‑02‑14, though earlier Internet‑Drafts circulated before it. If relying on them, rely on the pre‑2005 draft versions or corroborate with Anderson LDP (Jan. 2001), which is squarely prior art.


3. No single reference anticipates — so the question is combination

On the face of the retrieved content, no single listed reference discloses all of: PW‑setup acknowledgment + a configuration parameter carrying priority and domain‑type and standby‑mode + establishment per standby mode/domain type + priority‑driven preemption of the standby PW's traffic.

  • Voit '851 comes closest on the protection architecture (primary + redundant PWs, block/unblock) but is silent on priority‑based preemption and on a domain‑type parameter.
  • Chen (2002) and the GMPLS recovery literature teach the protection taxonomies (1+1, 1:1, 1:N, M:N) and preemption of lower‑priority traffic occupying protection resources, but not PW‑specific configuration signaling.
  • RFC 3209‑style MPLS‑TE supplies setup/holding priority and preemption — and note claim 15's verbatim use of the terms of art "holding priority" and "setup priority," which are RFC 3209 constructs. That is effectively an admission that the priority mechanism the claims rely on is conventional in the MPLS art.
  • US 7,733,876 supplies the intra‑AS vs. inter‑AS distinction that maps to "domain type."

The claims therefore stand or fall on whether a POSITA would have combined these known teachings with a reasonable expectation of success — and the specification's own Background supplies most of the answer.


4. The specification's own admissions (KSR's "known problem / known technique")

The '249 Background expressly concedes:

  • Existing PW systems "typically provide no protection or very limited protection."
  • MPLS Fast Reroute backup tunnels "may have different bandwidth"; if the primary fails, "the amount of data that needs to be redirected through the second tunnel may exceed the capacity of the second tunnel."
  • "[E]xisting protocols typically do not provide a way of determining which data gets priority. Thus, certain mission‑critical data may be dropped while other less critical data may pass through."

The stated desideratum is "better Pseudowire protection and … more control during switchover" "without significant changes to existing protocols and devices."

This is the classic KSR posture: the inventor identified a known deficiency in the art (no prioritization during PW protection switchover) and applied a known solution (priority‑based preemption of lower‑priority traffic, long used in MPLS‑TE/RSVP, DiffServ, and GMPLS protection). Under KSR's "known technique to address a known problem" rationale, that is strong evidence of obviousness.


5. Ground 1 — the primary combination (claims 1–5, 7–11, 12–13, 15)

Combination: Voit '851 (primary PW redundancy) + US 7,733,876 (intra‑/inter‑AS signaling) + Chen (2002) (protection schemes; shared protection resources carrying preemptable low‑priority traffic) + RFC 3209‑style MPLS‑TE setup/holding priority preemption as evidenced in this record by US 6,665,273 and corroborated by RFC 2475 (Blake) and RFC 1633 (Braden) + Anderson LDP (2001) for the acknowledgment signaling.

5.1 Element mapping for claim 1

Claim 1 limitation Where taught Reasoning
"source node device comprising a processor" Voit '851 n‑PE devices 16/17, 18/19 (MPLS‑capable PE routers); Anderson LDP (LSRs) Routers are processor‑based network devices; § obvious
"detecting … acknowledgement data … configuration data sent … has been accepted" Anderson LDP: Label Mapping message is the affirmative binding response to a Label Request; Voit '851: PW setup across MPLS core with signaling between PEs PW setup inherently requires the far end to accept and confirm; LDP standardizes it
config data specifies priority RFC 3209 setup/holding priority (terms of art recited in claim 15); US 6,665,273 (reservations at priority levels); RFC 2475 (classes/precedence) Priority is the ordinary mechanism for controlling which traffic wins contention
config data specifies domain type (single vs. multiple carrier networks) US 7,733,876 (intra‑AS vs. inter‑AS autodiscovery/signaling); '249's own FIG. 1B discussion of single‑ vs multi‑carrier (multi‑hop) PWs The single‑/multi‑domain distinction was already recognized as requiring different handling
config data specifies standby mode Voit '851 (redundant PWs pre‑established but blocked until failure = a standby mode); Tellabs 7,804,767 (pre‑planned vs. on‑demand); US 7,360,534 (stateful/hot); US 2004/0114595 (protection vs. restoration) Cold/warm/hot is a labeling of the pre‑existing design space of pre‑provisioned vs. on‑demand protection
"establishing the standby pseudowire … in accordance with the standby mode and domain type" Voit '851 (redundant PWs established across the core); Chen (dedicated vs. shared protection path establishment); Anderson LDP Establishing a protection PW according to whether it is pre‑provisioned and whether it crosses domains is routine engineering
"determining whether to initiate a preemption of data traffic on the standby pseudowire based at least in part on the priority" RFC 3209: "If the requested bandwidth is available, but is in use by lower priority sessions, then lower priority sessions … MAY be preempted"; Chen/GMPLS: low‑priority extra‑traffic on protection resources must be preempted when the protection path activates; US 6,665,273 (priority‑level bandwidth and re‑reservation); RFC 2475 (priority/drop precedence) This is the exact scenario the '249 Background admits needs solving

Why this satisfies the construed "preemption" term. The E.D. Tex. construction reads on traffic already carried on the standby PW being displaced. The GMPLS "extra traffic" model (Chen; and the pre‑planned/shared‑mesh protection model described in Great detail in the retrieved literature) is precisely: the protection path carries lower‑priority extra traffic while idle and that extra traffic is preempted when the protection path is activated for a failed primary. That is preemption of data traffic on the standby pseudowire — not a bare "switch over." Under the court's refusal to narrow "preemption" to "dropping," even the softer "lower‑priority traffic yields" implementations meet the term.

5.2 Motivation to combine (Ground 1)

  1. Same field of endeavor — all references concern MPLS/packet transport protection and QoS. KSR Rationale (A)/(C).
  2. Common problem, common solution — the references address the very deficiency the '249 Background admits (uncontrolled switchover with insufficient backup bandwidth). KSR "known problem / known technique."
  3. The PW rides on the LSP/tunnel — since PWs are carried over MPLS tunnels/LSPs (Voit '851; Martini), and MPLS TE already provides an established preemption regime keyed on setup/holding priority (RFC 3209; US 6,665,273), applying that regime to the PW layer is the ordinary extension of a known technique to a similar structure. KSR Rationale (C).
  4. Reasonable expectation of success — LDP is explicitly extensible via TLVs (Anderson LDP; Martini), so adding protection‑related parameters to the PW signaling is a predictable, low‑risk modification; and the '249 Background states the goal is to avoid "significant changes to existing protocols and devices" — a strong signal the artisan would view the modification as routine.
  5. Design incentive / market forces — carriers offering PWs as a service (the '249 Background notes the shift from encapsulation to service) needed protection differentiated by customer importance; prioritizing by class is standard service design. KSR Rationale (F).

5.3 Mapping the dependent claims in Ground 1

Claim Limitation Where taught
2 / 8 / 13 Switchover from primary to standby Voit '851 (unblocking the redundant path on primary failure); Tellabs 7,804,767; US 7,184,866
3 / 9 Switchover in response to primary PW failure Voit '851 (literal: unblock redundant path "in response to a failure of the primary data path"); Theimer OAM
4 / 10 Preemption when primary traffic exceeds standby bandwidth RFC 3209 admission control ("requested bandwidth … in use by lower priority sessions … MAY be preempted"); US 6,665,273; Chen (shared recovery bandwidth); and the '249's own admitted FRR scenario
5 / 11 Switchover when standby priority is lower than primary priority RFC 3209 setup‑priority vs. holding‑priority comparison; US 6,665,273
14 Establish using LDP Anderson LDP Specification (Jan. 2001); Martini PWE3 setup/maintenance
15 Config specifies holding priority and/or setup priority RFC 3209 — and note these are ipso facto the claim's own terms of art

Claim 15 is the most exposed. "Holding priority" and "setup priority" are not the inventor's coinage; they are the RFC 3209 vocabulary. Reciting them back as claimed subject matter does not distinguish over the MPLS‑TE preemption regime that predates the priority date by roughly a decade.


6. Ground 2 — the protection‑scheme and standby‑mode dependent claims (claims 6, 17, 18)

Combination: Ground 1 + Chen (2002), US 7,200,104 (1+1), Afferton et al. (2004), and the GMPLS recovery taxonomy.

  • Claim 6 recites establishing per a protection type scheme of 1+1 / 1:1 / 1:N / M:N. Chen's Oct. 2002 thesis — an examiner‑cited reference — surveys exactly these LSP protection schemes (1+1, 1:1, 1:N, and shared/M:N), and US 7,200,104 claims 1+1 protection explicitly. The retrieved GMPLS recovery literature corroborates 1:N "extra‑traffic" and M:N protection as standardized concepts. Selecting among known protection schemes as a configurable mode is a predictable variation (KSR Rationale (G)).
  • Claims 17/18 recite cold / warm / hot standby modes as:
    • cold = standby selected from a set of functional PWs in response to the failure/preemption;
    • warm = standby established but not used to transport data until failure;
    • hot = standby pre‑established and maintained at both control‑plane and data‑plane prior to failure.
      These correspond directly to the pre‑planned / pre‑reserved‑but‑not‑activated / fully‑activated taxonomy of protection resources found in Chen, the GMPLS recovery analysis, and US 7,804,767 (pre‑planned rerouting vs. full rerouting), with US 7,360,534 supplying the "stateful hot switch‑over" and US 2004/0114595 supplying protection/restoration modes. The cold/warm/hot labels are a naming convention over an established resource‑commitment spectrum.

Motivation: the protection scheme and standby mode determine recovery speed vs. resource cost — a tradeoff the GMPLS recovery literature (Chen; the "Analysis of GMPLS‑based Recovery Mechanisms" material surfaced in the same field) frames explicitly. A POSITA optimizing a PW protection deployment would select among these known options based on the carrier's recovery‑time and resource constraints. KSR Rationale (F)/(G).


7. Ground 3 — the "domain type" limitation (folded into Ground 1)

"Domain type" is the limitation most likely to be contested, so I treat it separately.

  • The claimed content is narrow: a field that indicates whether the PW's nodes are in one carrier network or multiple. That is the intra‑domain vs. inter‑domain (intra‑AS vs. inter‑AS) distinction.
  • US 7,733,876 B2 (prio. 2005‑02‑11, three days before the '249 priority date) is titled "Inter‑autonomous‑system virtual private network with autodiscovery and connection signaling" and addresses precisely the signaling differences when VPN/PW connectivity crosses autonomous systems. As a U.S. patent with a filing date preceding 2005‑02‑14, it qualifies as § 102(e) art (subject to what it actually supports — flagging the three‑day margin as tight and worth verifying against the full text).
  • Corroboration that single‑ vs. multi‑domain PW handling was a recognized axis of differentiation appears in the '249's own FIG. 1B discussion and in the later MS‑PW/segmented‑PW NPL (post‑dating, so usable only as context, not as prior art).

Motivation: a carrier extending a protected PW across carrier boundaries must signal differently (per‑domain segments, autodiscovery, inter‑provider coordination) than within one network; encoding a domain‑type indicator so the intermediate/edge nodes "process single‑hop and multi‑hop Pseudowire differently" (the '249's own stated reason) is the natural, expected design response. KSR Rationales (C)/(F).

Caveat: this is the weakest‑grounded element if the patent owner can show that no pre‑2005‑02‑14 reference combines the domain‑type indicator with the protection‑configuration context. The § 103 response is that the claim recites only an indicator whose meaning is conventional and whose use (choosing establishment behavior) is the very reason the distinction existed.


8. Anticipated patent‑owner arguments, and responses

Patent owner argument Response
"No reference teaches priority‑based preemption of traffic already on the standby PW." The GMPLS protection/extra‑traffic model (Chen 2002; the GMPLS recovery literature) teaches exactly that lower‑priority traffic occupying protection resources is preempted when the protection path activates. Under the E.D. Tex. construction, that reads on "preemption of data traffic on the standby pseudowire."
"The references are directed to LSP protection, not PW protection; no motivation to migrate." PWs are carried inside LSPs/tunnels (Voit '851; the '249 Background itself frames PWs atop MPLS). Applying an LSP‑layer preemption mechanism at the PW layer is use of a known technique on an analogous, closely related structure. KSR Rationale (C).
"The domain‑type field is novel as a PW protection parameter." The claimed content of the field is only an indication of single vs. multiple carrier networks — a recognized network‑topology distinction (US 7,733,876). Claiming an indicator over a known distinction is a predictable variation.
"Cold/warm/hot standby modes are a novel taxonomy." The taxonomy maps onto the long‑recognized spectrum of pre‑provisioned vs. on‑demand protection resources (Chen; US 7,804,767; US 7,360,534; US 2004/0114595). Naming an existing spectrum is not inventive.
"Reference X alone doesn't disclose every element." Irrelevant under § 103. KSR permits combination; the question is whether the combined teachings render the claim obvious with a reasonable expectation of success — satisfied here.

Counter‑cautions (where the § 103 case is weaker):

  1. Several of the most conceptually on‑point NPL items (Pan, "Pseudo Wire Protection," Jul. 2006; the MS‑PW drafts) post‑date the priority date and cannot be used. A rigorous petition must anchor on pre‑2005‑02‑14 art.
  2. US 7,733,876's three‑day margin (2005‑02‑11 vs. 2005‑02‑14) should be verified, and its § 102(e) scope confirmed against its disclosure — if it does not in fact support the intra‑/inter‑AS signaling distinction as characterized, an alternative pre‑2005 source (e.g., RFC 2547, 1999) should be substituted, but note RFC 2547 is not the Rosen document listed on this page.
  3. The US 2006/0047851 (Voit) primary reference is an application publication with a 2004‑08‑25 priority — comfortably pre‑date. Good.
  4. No single reference is a "golden" PW‑protection‑with‑priority reference; the case is built on a 4‑ to 5‑reference combination, which increases the burden of articulating a clear motivation for each linkage. The strongest motivation anchor is the '249's own admitted problem statement, which should be quoted in any petition.

9. Secondary considerations

I found no evidence in the record of the classic objective indicia with nexus to the claims:

  • No assertion of commercial success attributable to the claimed priority‑preemption feature is documented in the sources reviewed.
  • No evidence of long‑felt need, industry praise, or failure of others specifically tied to the claims.
  • The licensing/litigation posture (K.Mizra asserting the patent) is a monetization signal, not evidence of non‑obviousness.
  • The reexamination request logged on the Google Patents legal‑events table ("Request for reexamination filed," effective 2025‑11‑13; "RR" entry dated 2026‑01‑27) is a signal that at least one third party believes there is art‑based reason to challenge the claims — but it is not itself evidence of invalidity, and I could not confirm the requester or the art at issue (consistent with the caveats in the previously‑generated sections).

Absent objective indicia, the § 103 analysis rests on the prior‑art teachings and motivations above.


10. Bottom line

Claims 1, 7, and 12 are likely obvious over the combination of:

  • US 2006/0047851 A1 (Voit, Cisco) for standby/redundant PW protection and failure‑triggered switchover;
  • Anderson et al., LDP Specification (Jan. 2001) for accepting/acknowledging PW binding (Label Mapping) and the LDP setup (claim 14);
  • US 7,733,876 B2 (Cisco) for the intra‑/inter‑AS ("domain type") distinction;
  • Chen, "The LSP Protection/Restoration Mechanism in GMPLS" (Oct. 2002), US 7,200,104 B2, and Afferton et al. (2004) for the 1+1/1:1/1:N/M:N protection schemes and for lower‑priority traffic on protection resources being preempted on protection activation; and
  • RFC 3209‑style MPLS‑TE setup/holding‑priority preemption (terms of art recited in claim 15; evidenced by US 6,665,273 and corroborated by RFC 2475 (Blake) and RFC 1633 (Braden)) for the priority‑driven preemption determination;

with the motivation supplied, in significant measure, by the '249 specification's own admitted problem (unequal backup bandwidth; no way to decide which traffic gets priority) — a textbook KSR "known technique to solve a known problem" posture.

Claim 15 (holding/setup priority) is the most clearly obvious given it recites standard MPLS‑TE vocabulary. Claims 2–5, 8–11, 13–14 follow from Voit, Tellabs, RFC 3209, and LDP. Claims 6, 17, 18 (protection schemes and cold/warm/hot standby) follow from Chen, US 7,200,104, Tellabs 7,804,767, US 7,360,534, and US 2004/0114595 as predictable variations within a known protection‑design space.

Highest‑risk element for the challenger is the "domain type" limitation (Ground 3), both because the pre‑2005‑02‑14 evidentiary margin for US 7,733,876 is only three days and because the combination of a domain‑type indicator within a protection‑configuration parameter must be shown to have been suggested. The strongest anti‑obviousness argument available to the patent owner is that the discrete combination — PW‑layer protection signaling that simultaneously carries priority, domain type, and standby mode and uses them to drive preemption of the standby's own traffic — lacks an express pre‑2005 teaching; the counter is that each component was independently known and the '249 Background supplies the motivation.


Explicit uncertainties in this analysis

  1. I characterized several references (Voit '851, Chen, Tellabs '767, US 7,733,876, US 7,360,534) from abstracts/claims/snippets and the retrieved Chen text, not from a full‑text review of each specification. Before filing any § 103 challenge, each mapping should be verified against the reference's actual disclosure, with pin cites to columns/lines or page numbers.
  2. I did not confirm the identity of the reexamination requester or the art at issue in the 2026 reexamination event; the ground(s) of that proceeding may overlap with or differ from the combinations proposed here.
  3. The priority‑date availability table (§ 2.3) is based on the dates printed on the Google Patents page; provisional/draft publication dates of the Internet‑Drafts may differ from the versions listed and should be verified before any draft is relied upon.
  4. This analysis is a technical assessment, not a legal opinion or a freedom‑to‑operate/invalidity opinion, and it does not account for claim amendments, certificates, or intervening rights that may have arisen in the family or in the pending reexamination.

Generated 9/28/2026, 7:44:34 PM

Extensions

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

Log in to generate
Not generated yet. Log in to request this analysis.

Derivative works

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

Log in to generate
Not generated yet. Log in to request this analysis.

Keep exploring

More patents asserted by K.Mizra LLC

Other patents in Software Technology & Computing Systems (T)

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

This patent in court (1)

1 tracked lawsuit name US 9749249.