US 9264354

I'll search for authoritative sources on this patent, focusing on the specific number 9264354 and any 2026 litigation.

US 9,264,354 B2 — Summary

I searched for the exact number 9264354 and did not rely on near-number results. The authoritative text you supplied (Google Patents page fetched 2026-09-28) is the primary source below; I have flagged where I relied on secondary search results instead.

Bibliographic data (from the patent text)

Abstract: "Transferring data in a network is disclosed. Transferring includes receiving a Provider Backbone Transport (PBT) frame, identifying a plurality of location specific identifiers in the PBT frame, mapping the PBT frame to a service based at least in part on the plurality of location specific identifiers, formatting the PBT frame according to the service to obtain a service frame, and transferring the service frame to a network associated with the service."

Plain-language overview of each independent claim

Claim 1 (method). A provider edge device that sits between a Provider Backbone Bridge (PBB) network and an MPLS network: (a) reads a service instance identifier (I-SID) and a customer VLAN identifier (C-VID) from a frame; (b) looks those values up in service mapping data that pairs combinations of I-SID and C-VID values with particular services, and thereby determines which service the frame belongs to; (c) reformats the frame according to that service to produce a "service frame" (e.g., strips the 802.1ah/PBT header and/or wraps it with the appropriate service encapsulation). Note that the claim requires both the I-SID and the C-VID, and requires the mapping data to define associations for combinations of values.

Claim 9 (apparatus). The same functionality embodied in a provider edge device: a memory storing instructions plus a processor that identifies an I-SID and a C-VID in a frame, identifies the service from service mapping data keyed on combinations of those values, formats the frame into a service frame, and transfers the service frame between a PBB network device and an MPLS network device.

Claim 17 (computer-readable storage device). A non-transitory-style storage medium whose instructions cause a provider edge device to: determine an I-SID and a C-VID in a frame received from a PBB network device; determine the service from service mapping data defining associations between services and combinations of I-SID/C-VID values; format the frame into a service frame; and send the service frame to an MPLS network device.

Common thread: all three independent claims require the pair {I-SID, C-VID} as the lookup key into a provisioned mapping table, followed by service-specific reformatting. Dependent claims add: transfer to an MPLS network (3, 16, 18); optional S-VID or pseudowire ID as additional qualifiers (4, 11, 19); receipt from a PBB or PBT trunk device (5, 12); specific services such as VPLS, EVPL, PBT trunk, private IP, or public IP (6, 13, 20); PBT trunk identifier {B-DA, B-SA, B-VID} (7, 14); and dynamic updating of the mapping data (8, 15).

Litigation findings (with confidence levels)

• No CAFC (Federal Circuit) 2026 docket for 9264354 was found. My searches returned no appeal involving this patent number at the Federal Circuit. I cannot rule out a docket that is not publicly indexed, but I have no authoritative evidence of one — treat "no CAFC 2026 appeal" as my best finding, not a certainty.
• Family litigation of record (from the patent page): a US case in the Texas Eastern District Court, No. 2:24-cv-00974, and the Darts-IP "first worldwide family litigation" entry for family ID 39645068. This matches K.Mizra LLC v. Nokia Corporation et al., 2:24-cv-00974 (E.D. Tex., filed 2024-11-25, Judge Rodney Gilstrap), in which Nokia's preliminary invalidity contentions list U.S. Patent No. 9,264,354 ("the '354 Patent") among five asserted patents, with asserted claims 1–3, 5–6, 9–10, 12–13, 16–18, and 20 and an asserted priority date of January 25, 2007. (Source: Nokia preliminary invalidity contentions reproduced at ptacts.uspto.gov and the docket at dockets.justia.com.) This is a 2024 filing, not 2026.
• Other K.Mizra 2026 activity I encountered but could NOT tie to the '354 patent: K.Mizra LLC v. Google LLC, 1:26-cv-00754 (W.D. Tex., filed 2026-03-27); K.Mizra LLC v. MediaTek Inc., 2:26-cv-00253 (E.D. Tex., filed 2026-03-25); K.Mizra LLC v. Amazon.com, 1:26-cv-00316 (W.D. Tex., filed 2026-02-10); and the Google declaratory-judgment action Google LLC v. K.Mizra LLC, 3:25-cv-08107 (N.D. Cal.), which concerns U.S. Patents 8,144,717 and 8,438,120, not the '354 patent. I could not confirm that 9,264,354 is asserted in any of these 2026 cases, so I am not attributing them to this patent.

Uncertainty notes

• The Google Patents page itself warns that assignee and legal-status entries are assumptions, not legal conclusions. The "active / expires 2028-04-20" status is therefore indicative only.
• I found no USPTO PTAB proceeding (IPR/PGR) specifically for 9,264,354 in my searches; the IPR activity I saw (e.g., IPR2026-00254, IPR2024-01236) involved other K.Mizra patents (8,144,717; 10,331,379), and should not be attributed to the '354 patent.
• Patent numbers: I treated 9264354 literally throughout and excluded look-alikes such as 9,436,354, 9,345,354, 9,435,354, and 8,614,354.

I'll research litigation involving US 9264354. Let me run several targeted searches.

Let me dig deeper into the specific cases and any PTAB proceedings involving this patent.

Litigation involving US Patent No. 9,264,354 ("the '354 patent")

Important framing note: I interpreted the identifier literally as US 9,264,354, titled "Mapping PBT and PBB-TE traffic to VPLS and other services" (Brixham Solutions Ltd. / originally Hammerhead Systems, Inc.; now assigned to K.Mizra LLC). I excluded results for similar-but-different numbers (e.g., 9,264,354 is sometimes confused with unrelated patents, and the same K.Mizra campaign asserts several other Brixham/Hammerhead network patents such as 9,485,176; 10,735,320; 9,749,249; 8,018,880; 9,516,048; 8,234,705 — those are not this patent).

The one case I was able to confirm asserting the '354 patent

Sources: RPX Insight docket, 2:24-cv-00974; Nokia's Preliminary Invalidity Contentions (asserted-patent table listing 9,264,354); K.Mizra v. Nokia claim construction opinion (E.D. Tex. 2026); Google Patents family-litigation link for US 9,264,354.

Notes on related activity (not '354 suits)

• K.Mizra LLC v. Ciena Corporation, 1:24-cv-05442 (N.D. Ga.) — this is a K.Mizra suit in the same campaign, but reference in the related PTAB filing identifies US 10,735,320, not the '354 patent, as the asserted patent. I did not find the '354 patent asserted in the Ciena case.
• K.Mizra LLC v. Google LLC, 1:26-cv-00754 (W.D. Tex.) — same plaintiff; the "Notice of Inter Partes Review Filings" in that docket relates to a different K.Mizra patent (the '705 cloud-security patent), not the '354 patent.
• The Google Patents page for US 9,264,354 flags a "Family has litigation" entry pointing to the same Eastern District of Texas case 2:24-cv-00974 — consistent with the Nokia suit being the family's known litigation (its Darts-ip entry is likewise tied to family ID 39645068).

Caveats / confidence

• High confidence in the Nokia case details (case number, court, parties, filing date, '354 claim set, defendants' products).
• Lower confidence that this list is exhaustive. District-court and PACER data are not fully open, and I was unable to complete additional API/PTAB queries (I hit a search-step limit). I found no PTAB inter partes review, PGR, or ITC Section 337 action specifically challenging or asserting the '354 patent in the searches I ran, but I cannot rule one out — please verify against PACER, the PTAB E2E/PatentCenter "related matters" listings, and Darts-ip family 39645068 before relying on this as complete.
• No pre-K.Mizra litigation was identified; the '354 patent appears to have been asserted only after the patents moved from Hammerhead Systems → Brixham Solutions → Global Innovation Aggregators → K.Mizra LLC.

I'll verify the canonical "no PTAB activity" finding with targeted searches before drafting.

Proceedings overview

Total AIA trial proceedings on U.S. Patent No. 9,264,354: zero. The canonical structured block ("PTAB proceedings on file," sourced from the USPTO Open Data Portal) returns no IPR, PGR, or CBM for this patent, and my independent web searches — on the patent number, on the title, and on the K.Mizra/Figueira '354 family — surfaced no petition, institution decision, Final Written Decision, or appeal naming 9,264,354. The breakdown is therefore: active 0, claims invalidated 0, claims sustained 0, settled 0, institution denied 0.

Defensive bottom line for a defendant: the opposite of "hardened" and the opposite of "claims are dead." All 20 claims of the '354 patent — including independent claims 1, 9, and 17 — are untested at the PTAB. There is no FWD to point to, no cancellation to exploit, and no § 315(e)(2) estoppel to inherit. What that means practically: you have a clean runway to file (no § 325(d) "same or substantially the same art" problem, no time-bar inherited from a privy's petition), but you also get no free ride — if you want claim 1 dead, you have to kill it yourself. Note also that the prior generation of this analysis already reached the same conclusion ("no USPTO PTAB proceeding (IPR/PGR) specifically for 9,264,354"), so the two sources are consistent — I flag no contradiction.

Because there are no proceedings to walk through, the sections below instead map what the searches did return (so you can see I checked) and where the validity fight is actually happening.

No proceedings to report — near-misses checked and excluded

These are the K.Mizra-adjacent PTAB matters that surfaced in search. None of them involve 9,264,354. I list them so a defendant is not misled by search noise:

• IPR2025-01437 — Google LLC v. K.Mizra LLC. Concerns U.S. Patent 8,948,448-family subject matter described in the papers as "the '048 Patent" (Patent Owner's Request for Discretionary Denial, Paper 7, P.T.A.B. 2025-11-23, arguing Fintiv factors). Not the '354 patent. Fintiv brief
• IPR2024-01240 — Silicon Motion Inc. v. K. Mizra LLC, filed 2024-08-13; instituted 2025-03-05; terminated 2025-03-14 on a post-institution joint motion to terminate due to settlement under 35 U.S.C. § 317 / 37 C.F.R. § 42.74. Different patent. This one is worth knowing as a pattern signal (see below), but it is not this patent.
• Cisco Systems, Inc. v. K.Mizra LLC (PTAB, filed 2021-03-15; Fed. Cir. No. 22-2290, decided 2024-08-16) — concerns U.S. Patent No. 8,234,705, not '354. The Federal Circuit vacated and remanded the Board's motivation-to-combine analysis. Again: not this patent.
• Excluded look-alikes: the "9,436,354" hits in search results (Samsung IPR2020-00737, Kanuu Pty) are a different patent number. I did not attribute them to 9,264,354. Per my operating rules I treated "9264354" literally.

Search caveat: the absence of PTAB activity is a negative finding. It is corroborated by two independent sources (the ODP structured list and web search), but a proceeding so recent that it has not yet been indexed by either could have escaped. The practical check before you rely on this is a docket-number search on PTAB E2E / Patent Center for the patent number, which I cannot query directly here.

Where validity is actually being litigated (non-PTAB)

Because there is no PTAB track, the only public validity record on this patent is in district court:

• K.Mizra LLC v. Nokia Corporation, Nokia Solutions and Networks Oy, and Nokia of America Corporation, No. 2:24-cv-00974-JRG (E.D. Tex., Judge Rodney Gilstrap). Per Nokia's Preliminary Invalidity Contentions (filed after K.Mizra's 2025-03-12 infringement contentions), K.Mizra asserts U.S. Patent 9,264,354 ("the '354 Patent"), claims 1–3, 5–6, 9–10, 12–13, 16–18, and 20, with an asserted priority date of 2007-01-25. Nokia contends the asserted claims are invalid under §§ 101, 102, 103, and 112. Source: Nokia preliminary invalidity contentions
• Federal Circuit: there is no CAFC appeal of any PTAB FWD on 9,264,354, because no FWD exists. Any CAFC docket touching this patent would have to arise from the E.D. Tex. case, and I found none.

Note the asserted-claim set: claim 4, 7, 8, 11, 14, 15, and 19 are unasserted. Claims 4/11/19 (S-VID or pseudowire ID qualifiers), 7/14 (PBT trunk ID {B-DA, B-SA, B-VID}), and 8/15 (dynamic mapping-table update) are therefore both untested at the PTAB and unasserted in the copending litigation — a useful gap if you are building a design-around or a § 112/§ 103 challenge.

Strategic summary

Claim status: everything is UNTESTED. No claim of 9,264,354 has been canceled, confirmed, or even reviewed at the PTAB. All 20 claims — independent claims 1, 9, and 17 and their dependents — stand as issued. The subject-matter contrast with the prior generation of this analysis is worth stating plainly: a defendant here cannot say "claim 1 is dead, the assertion is sanction-bait." You can only say "no one has ever tried, so the ground is unbroken." That cuts both ways. On the one hand, you avoid the § 325(d) hurdle of persuading the Board that "the same or substantially the same prior art or arguments previously were presented to the Office" (35 U.S.C. § 325(d)) — the fatal problem for serial petitioners. On the other, you get no benefit from an earlier panel's claim constructions, no roadmap of what the Board thinks "location specific identifier" or "service mapping data" means, and no free invalidity judgment to cite under § 282.

Estoppel landscape is empty — in your favor and against you. Because there is no IPR "that results in a final written decision," 35 U.S.C. § 315(e)(2) estoppel never attached to anyone. No petitioner or privy is barred from raising any § 102/§ 103 ground, and there is no Petitioner's-grounds pool you would be duplicating. Conversely, you inherit no one else's work product. Two timing traps do apply: (i) § 315(b) bars a petition filed more than one year after the petitioner (or a real party in interest or privy) is served with an infringement complaint — Nokia was served in the 2:24-cv-00974 case filed 2024-11-25, so Nokia's own one-year IPR window has already closed; and (ii) § 315(a)(1) bars an IPR filed by a party that previously filed a civil action challenging validity. A newly sued 2026 defendant still has a full one-year window.

Pattern signals. The patent owner, K.Mizra LLC, is a serial assertion entity and an experienced IPR defendant — it litigated Cisco v. K.Mizra to the Federal Circuit, and it settled Silicon Motion v. K. Mizra (IPR2024-01240) out from under an instituted trial in March 2025. Read that pattern in a defensive light: K.Mizra is willing to settle mid-trial rather than let an FWD issue. That is arguably the single most actionable observation in this report — a credible, well-funded petition on the '354 patent creates settlement leverage before any FWD, precisely because the owner has shown it will terminate rather than bank a loss. There is no defensive aggregator in the chain for this patent: I found no Unified Patents, RPX, or other aggregator petition targeting 9,264,354. Note also the "Family has litigation" flag on the patent page plus the Darts-IP "first worldwide family litigation" entry for family ID 39645068 — the family (including siblings US 8,619,784 and US 9,832,042) is being monetized, so a challenge to '354 has family-wide implications. K.Mizra's new 2026 filings (e.g., K.Mizra v. Twingate, 1:26-cv-00925 (D. Del., filed 2026-07-28), asserting 8,234,705) show the campaign is still expanding — the risk that you get asserted is live, not historical.

Expiry runway. The patent's adjusted expiration is 2028-04-20 (per the patent page; treat as indicative only). An IPR petition filed now would draw an institution decision roughly six months out, and an FWD within the statutory 12 months of institution — i.e., landing before expiry. If you are weighing PTAB versus district-court-only invalidity, you have enough runway for a full trial, but not much slack for a second, improved petition after a denial.

Recommended next steps

1. Confirm the absence on PTAB E2E before you rely on it. No PTAB activity is a negative finding from two sources (ODP structured list + web search), not a certified null. Run the patent number in the PTAB E2E / Patent Trial and Appeal Board End-to-End system and in Patent Center's "Proceedings" tab for 9,264,354. If a petition has been filed in the last few months, the institution-decision deadline is three months from the earlier of the POPR filing or the POPR due date (37 C.F.R. § 42.107(b); 35 U.S.C. § 314(b)) — so any newly filed petition would show an institution decision within ~6 months of filing.
2. If you were served within the last year, your § 315(b) clock is running. File on the '354 patent's independent claims 1, 9, and 17 plus the asserted dependents (2–3, 5–6, 10, 12–13, 16–18, 20) to match the asserted set. If you are serving as a defendant alongside Nokia, note that Nokia's window is closed — do not assume Nokia can join your petition as a § 315(c) joinder; joinder requires an already-instituted proceeding and a petitioner that is not time-barred.
3. Exploit the untested claim set. Because nothing has been construed by the Board, you are litigating claim construction from scratch — the claim terms "location specific identifier," "service mapping data," and the requirement in all three independent claims of a combination of I-SID and C-VID values are the pressure points. The specification's admission that "a given implementation may never need to match an I-SID or a C-VID or both to select a service. The PBT-Service lookup table may be employed without one or both of these fields" is a § 112 written-description/enablement and claim-scope argument worth developing, and it is more usable in an IPR-adjacent posture than the § 101 ground because only §§ 102/103 (patents and printed publications) are available in an IPR.
4. Plan for post-institution settlement pressure. Given the Silicon Motion termination (IPR2024-01240, terminated 2025-03-14 after institution), a strong petition on '354 is a settlement lever, not necessarily a route to an FWD. Decide ex ante whether your objective is a cancellation judgment or a license at a discount.
5. Monitor the E.D. Tex. case for a stay and for parallel challenges. If any defendant in K.Mizra v. Nokia, 2:24-cv-00974-JRG files a petition, a § 316(a) / Fintiv-style stay fight follows — and K.Mizra has shown it will litigate discretionary denial hard (see its Fintiv brief in IPR2025-01437). Track the docket at CourtListener and PTAB rulings at the USPTO PTAB Decisions page.

I'll research the assignment record, focusing on reel/frame entries and correspondents of record.

Assignment Record — US Patent 9,264,354 B2

"Mapping PBT and PBB-TE traffic to VPLS and other services"

Sourcing note up front (please read): I hit my search-step limit before I could query the USPTO Patent Assignment Search interface directly. The reel/frame numbers below are taken from the authoritative patent text you supplied (Google Patents "Legal Events" for US 9,264,354, which reproduce USPTO reel/frame data) plus a PTAB exhibit reproducing the GIA→K.Mizra assignment instrument, plus one Google Patents legal-events hit on a sibling patent in the same portfolio. Correspondents of record are generally not displayed in the Google Patents legal-events view, so I could retrieve a correspondent for only one link in the chain, and I flag that explicitly rather than guessing. Verify every entry at:

• https://assignmentcenter.uspto.gov/ (search by patent number 9264354)
• https://assignment.uspto.gov/patent/index.html (same underlying records)

Inventors

Unusual patterns:

• Inventor→company assignment was not recorded promptly. On the sibling patent US2008/0247406 (same 2007-01-25 priority family, same inventors Figueira/Gitlin), the inventors' assignment to Hammerhead is recorded at Reel 021112/0104, signing dates 2008-06-06 to 2008-06-07 — i.e. ~5 months after the Jan 22, 2008 filing. The '354 patent's own Google Patents legal-events table does not list an inventor→Hammerhead assignment at all, so I cannot state its reel/frame. Treat that as a gap, not as evidence that no assignment exists.
• The assignee, not the inventors, is the anomaly. Hammerhead ceased operations and its portfolio was liquidated within roughly two years of filing. I found no evidence of individual inventor departures (no departure dates were retrievable), so I cannot make the "all inventors left within 12 months" call — but the company itself did not survive long enough for that pattern to be meaningful.

Original assignee

Two entities must be distinguished:

1. Applicant at filing / named on the 2008 publication (US2008/0212595A1): Hammerhead Systems, Inc. (California). A Silicon Valley carrier-Ethernet/MPLS aggregation startup that developed the "HSX" service aggregation switch line sold to telecom carriers. It was a real operating company, not a paper entity. Status: defunct — its patent portfolio (25 issued or pending applications) was sold in a bankruptcy proceeding (per Brixham's own characterization in the Juniper litigation; the chapter number is not confirmed in the sources I retrieved). Whether any shipped HSX product implemented the claimed I-SID/C-VID-based service mapping is not something I can confirm from the retrieved sources.

2. Entity named as original assignee on the issued patent: Brixham Solutions Ltd. (British Virgin Islands). Brixham was, by its own admission, created to buy the Hammerhead portfolio — "Brixham was created 'to purchase the rights to a patent portfolio of 25 issued or pending patent applications from Hammerhead Systems, Inc. . . . during a bankruptcy proceeding for a total of $230,000.'" (Quote reproduced from Brixham's motion, N.D. Cal. 3:13-cv-00616, at cases.justia.com). It shipped no products; its business was patent assertion — it sued Juniper Networks in the Northern District of California in February 2013 on four of the acquired patents (US 7,940,652 and US 7,535,895 were later invalidated by the PTAB and the Federal Circuit in 2015–2016). Status: acquired — its portfolio passed to Global Innovation Aggregators LLC in 2017.

Assignment timeline

Chronological, post-inventor-assignment. All three post-issuance/portfolio links are confirmed from the authoritative text.

• 2008-06-06 / 2008-06-07 (executed) / recorded ~2008 — Reel 021112/0104

  • Conveyance: Assignment (inventors → employer)
  • Assignor: Figueira, Norival R.; Gitlin, Richard D. (Fong Liaw not shown on this record)
  • Assignee: Hammerhead Systems, Inc., California
  • Correspondent: not retrievable from my sources
  • Context: routine inventor-to-employer assignment; this reel is documented on the sibling patent US2008/0247406, not verified as covering the '354 patent — include only as corroborating context.

• 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 retrievable. (A sibling record shows the Brixham acquisition was also recorded at Reel 023810/0916, effective 2010-01-08 — per the Google Patents legal events of US2008/0247406. Brixham's 2010 portfolio purchase therefore spans multiple reels, and this 2014-dated recording at 031933/0846 appears to be a later or confirmatory instrument. Verify which reel actually covers the '354 patent.)
  • Context: bankruptcy fire-sale — acquisition of a 25-asset portfolio out of Hammerhead's bankruptcy for $230,000; the Brixham entity was formed for the purchase. Note the ~4-year gap between execution (2010) and recording (2014-01-09) — recorded roughly 11 months after Brixham filed suit against Juniper (Feb 2013), i.e. a standing/chain-of-title clean-up during litigation rather than a pre-litigation transfer.

• 2017-06-27 (executed) / recorded 2017-08-16 — Reel 043312/0218

  • Conveyance: Assignment
  • Assignor: Brixham Solutions Ltd.
  • Assignee: Global Innovation Aggregators LLC (California)
  • Correspondent: not retrievable for this reel. Cross-portfolio GIA correspondence of record (from GIA's Power of Attorney filings on other patents, e.g. US 8,548,324) is Amin, Turocy & Watson LLP (Customer No. 23623, 127 Public Square, 57th Floor, Key Tower, Cleveland, OH 44114) and BrainSpark Associates LLC (Customer No. 98618, 528 South Meadows Drive, Chandler, AZ 85224). Not confirmed for Reel 043312/0218.
  • Context: transfer-to-aggregator — Brixham (already a pure assertion vehicle, post-Juniper losses) exits; GIA is a patent-holding/monetization entity with no operating business.

• 2019-12-24 (executed) / recorded 2020-01-13 — Reel 051579/0773

  • Conveyance: Assignment — "Assignment of Patents and Patent Rights," covering an Exhibit 1 list of patents (portfolio-level, not '354-specific)
  • Assignor: Global Innovation Aggregators, LLC, a Delaware limited liability company
  • Assignee: K.Mizra LLC, a Delaware limited liability company, principal place of business at 2160 Century Park East #707, Los Angeles, CA 90067
  • Correspondent: Daniel J. Friedman appears as the named submitter on a PTAB filing that reproduces this assignment instrument (exhibit "Patent Assignment – Global Innovation to K.Mizra (00407808)"). I cannot confirm he is the USPTO recording correspondent of record for Reel 051579/0773 — treat as a lead to verify, not a finding.
  • Context: transfer-to-asserter. The instrument expressly conveys "all causes of action and enforcement rights . . . including . . . past and future infringement," i.e. drafted for assertion. K.Mizra was founded in 2019 by Charles Jourdan Hausman (CEO), whose stated business is "acquiring high-value, high-quality patents," following a career in "IP enforcement and monetization."

Corporate-domicile corroboration for K.Mizra (not a USPTO record): Florida Sunbiz lists K.MIZRA, LLC as an active foreign LLC, principal address 777 Brickell Ave #500-96031, Miami, FL 33131, registered agent United States Corporation Agents, Inc. (476 Riverside Ave, Jacksonville, FL 32202) — a commercial registered-agent service — with Hausman as authorized person. Address changed as recently as 2026-02-08. (search.sunbiz.org, entity no. M21000004469.)

Timeline diagram

timeline
    title Ownership of US 9264354
    2007 : Priority date Jan 25
    2008 : Application filed by Hammerhead
    2009 : Hammerhead shuts down
    2010 : Portfolio sold in bankruptcy
         : Brixham acquires 25 assets
    2014 : Brixham assignment recorded
    2016 : Patent issues Feb 16
    2017 : Brixham assigns to GIA
    2019 : GIA agrees to sell to K Mizra
    2020 : K Mizra assignment recorded
    2024 : K Mizra sues Nokia
    2026 : Texas case still active

NPE / troll-pattern signals

Verdict

NPE — high confidence.

The chain is a clean, documented distress-to-assertion pipeline: a bankrupt operating company's portfolio sold for $230,000 / 25 assets into Brixham Solutions Ltd. (a BVI vehicle created for the purchase, Reel 031933/0846, effective 2010-01-08), then resold to Global Innovation Aggregators LLC (Reel 043312/0218, executed 2017-06-27) and finally to K.Mizra LLC (Reel 051579/0773, executed 2019-12-24, conveying enforcement rights "for past and future infringement") — which is now asserting the patent against Nokia in E.D. Tex. 2:24-cv-00974. That gives two independent strong signals (bankruptcy fire-sale; shell/asserter chain terminating at a repeat plaintiff), with cascading transfers and non-practicing assignee addresses as corroboration.

Confidence limiters to verify before relying on this: (a) correspondents of record for Reels 031933/0846 and 043312/0218 were not retrievable, so signal 3 is unresolved; (b) I could not confirm whether Reel 023810/0916 (the sibling patent's Brixham recording) also covers the '354 patent, which would change the executed-vs-recorded characterization of the 2010/2014 assignment; (c) no PTAB, ITC, or pre-2013 litigation involving the '354 patent was identified in the earlier sections of this analysis — absence of evidence, not evidence of absence.

Verify at: https://assignmentcenter.uspto.gov/ and https://assignment.uspto.gov/patent/index.html (search "9264354").

I'll research the prior-art citations for US 9,264,354, confirming citations and dates via search while treating the supplied patent text as authoritative for the citation list itself.

Prior-Art Analysis — US 9,264,354 B2 ("the '354 Patent")

Scope note. This section builds on the earlier-generated Patent summary and Litigation summary and does not repeat them. I treated 9264354 literally and ignored look-alikes (9,436,354; 9,345,354; 9,435,354; 8,614,354). I could not open a USPTO PatentCenter "References Cited" pane directly, but the citation list below is taken verbatim from the authoritative patent text you supplied (Google Patents' rendering of the USPTO record, fetched 2026-09-28), and I cross-checked the examiner-cited entries against the US8619784 PDF and the Justia/FreePatentsOnline "Referenced Cited" listings, which agree.

1. Which citations are actually prior art (pre-AIA § 102 framework)

The '354 patent is a continuation with a § 119(e) priority claim to provisional 60/897,778 (filed 2007-01-25) and a parent utility (12/009,833) filed 2008-01-22. Because both were filed before 16 March 2013, pre-AIA 35 U.S.C. § 102 applies, and the critical date for § 102(b) art is one year before the earliest effective U.S. filing → 2006-01-25.

This matters because it splits the 20 third-party citations into different statutory buckets:

Bottom line on § 102: none of these references is a clean, single-reference anticipation of independent claims 1, 9, or 17. Every one of those claims requires (a) reading both an I‑SID and a customer VLAN identifier from the frame and (b) consulting service mapping data that associates services with combinations of those two values. The cited art maps on single identifiers or on {VLAN, destination‑MAC} pairs, not on the I‑SID + C‑VID combination. The references are therefore realistically § 103 obviousness references (and § 102(e)/(a) references as to narrower claims), which is consistent with why the examiner allowed the claims. I flag below where a § 102 argument is at least colorable versus where it is not.

2. Tier 1 — The most relevant references (the ones the examiner cited against this family)

2.1 US 2007/0076719 A1 — Allan et al. (Nortel Networks)

• Full citation: US 2007/0076719 A1, "Provider backbone bridging – provider backbone transport internetworking," Allan, Bragg, Friskney, Holness, Parry; pub. 2007-04-05; App. 11/479,694 filed 2006-06-30; prov. 60/723,478 filed 2005-10-05; granted as US 8,369,330 B2 (2013-02-05). Examiner-cited (*).
• Description: Hub-and-spoke architecture where PBT trunks are spokes and a PBB sub-network is the hub. "The association of traffic with a specific virtual switched sub-network is performed by I-SID tagging of the traffic at the PE." Also describes PBT trunks defined by destination address + VLAN ID, and provider-tandem/VSI multiplexing.
• § 102 exposure: Strong § 102(e) art (U.S. filing 2005-10-05, well before the '354 invention date). It discloses the PBT/PBB interworking setting and I‑SID-based association, and PBT trunk identification by {B-DA, B-VID}. However, it does not show lookup into provisioned mapping data keyed on I‑SID + C‑VID combinations, nor reformatting to a service frame as claimed. Best positioned as anticipatory/obviousness art against claims 5 and 7 (receiving a PBT frame; PBT trunk identifier = B‑DA/B‑SA/B‑VID) and as § 103 art against claim 1. E.g., "PBT trunks are defined by a connection mapping … identified by the destination address and a Virtual Local Area Network (VLAN) identifier."

2.2 US 2008/0172497 A1 — Mohan et al. (Nortel Networks)

• Full citation: US 2008/0172497 A1, "Method and Apparatus for Interworking Ethernet and MPLS Networks," Mohan, Smallegange, Unbehagen, Bragg; pub. 2008-07-17; App. 12/016,190 filed 2008-01-17; prov. 60/880,816 filed 2007-01-17; granted as US 8,504,727 B2 (2013-08-06). PCT counterpart WO 2008/089370 A1 (pub. 2008-07-24) is separately cited in the family's related-art record. Examiner-cited (*).
• Description: Interworks 802.1ah/802.1Qay Ethernet with MPLS PW/VPLS. A PE maps PBB/PBT frames to PWs/VPLS "based on the tag associated with the frame, or uses the VLAN and DA to identify the PBT trunk." Discloses per-I-SID mapping and I‑SID translation at the edge between split domains, and "service interworking … where the MPLS network identifies its service instance such as PW or VPLS from the I‑SID or other service identifier in use on the Ethernet network."
• § 102 exposure: The closest reference on the merits. § 102(e) available (prov. 2007-01-17, eight days before the '354 priority). It squarely shows a provider-edge device that reads Ethernet identifiers (VLAN/VID, I‑SID) and maps the frame to an MPLS PW/VPLS service. It is a colorable § 102(a)/(e) argument against claim 1 (and counterpart claims 9/17) only if one reads its "VLAN ID" as the customer VLAN identifier and its per-I‑SID mapping as the claimed combination lookup; on the face of the document the mapping is based on VLAN (or VLAN+DA) and separately on I‑SID, not on the I‑SID + C‑VID combination, so a clean anticipation is doubtful. Most likely to appear in an invalidity contention as the primary § 103 reference, alone or with 2.1.

2.3 US 2007/0086361 A1 / US 7,688,756 B2 — Allan et al. (Nortel)

• Full citation: US 2007/0086361 A1, "Provider Link State Bridging," pub. 2007-04-19; and US 7,688,756 B2, granted 2010-03-30 (App. 11/537,775, filed 2006-10-02). Both listed.
• Description: PLSB — link-state (IS‑IS) controlled Ethernet where bridges exchange state to build shortest-path forwarding and where community-of-interest I‑SID information is carried in the routing system/forwarding tables across areas.
• § 102 exposure: § 102(e) available (U.S. filing 2006-10-02). Discloses forwarding/mapping on I‑SID in a provider Ethernet backbone; it does not disclose the claimed {I‑SID + C‑VID} service-mapping table or service-frame formatting. Realistically § 103 context (showing I‑SID as a service-flow identifier in the carrier-Ethernet art) rather than § 102.

2.4 US 2006/0245436 A1 — Sajassi (Cisco Technology)

• Full citation: US 2006/0245436 A1, "Comprehensive model for VPLS," pub. 2006-11-02 (filed 2005-04-28). Third-party cited.
• Description: Framework for VPLS service modeling/forwarding across an MPLS network; the canonical VPLS background reference.
• § 102 exposure: § 102(a) candidate (published 2006-11-02, just after the grace date; only § 103 in practice). It shows the VPLS service that the '354 maps frames to (claim 6/13/20) but no PBT/PBB ingress, no I‑SID/C‑VID combination lookup, and no "format the PBT frame according to the service." Not anticipatory of any independent claim; § 103 support for the "VPLS" service-recitation claims.

2.5 US 2008/0279196 A1 — Friskney et al.

• Full citation: US 2008/0279196 A1, "Differential Forwarding in Address-Based Carrier Networks," pub. 2008-11-13 (priority 2004-04-06). Third-party cited.
• Description: Address/MAC-based carrier Ethernet forwarding, with forwarding decisions conditioned on combinations of header fields (e.g., DA/VID) to differentiate service instances.
• § 102 exposure: Interesting because it shows conditioning forwarding on a combination of identifiers, but it is directed to Ethernet forwarding, not to mapping a PBT/PBB frame to an MPLS/VPLS service and reformatting it. § 103 reference only; no anticipation of claims 1/9/17.

3. Tier 2 — Contextual references (VPLS/pseudowire/service-interworking background)

4. Tier 3 — Peripheral / merely-technology-background citations

5. Self/co-pending family citations (NOT prior art)

• US 2008/0212595 A1 — Figueira et al. (Hammerhead Systems), pub. 2008-09-04 — this is the '354 family's own pre-grant publication (parent 12/009,833). Not prior art; cited on the continuation's face for family completeness.
• US 8,619,784 B2 — Figueira et al. (Brixham Solutions), granted 2013-12-31 — the parent patent of the same family.
• US 2014/0071989 A1 — Figueira et al. (Brixham Solutions), pub. 2014-03-13 — the '354's own application publication.

All three are the applicant's own work and cannot be § 102 art against the '354 claims.

6. Non-patent literature cited

7. Consolidated ranking and practical takeaways

1. Most likely primary references in any invalidity theory: US 2008/0172497 A1 (Mohan/Nortel) and its PCT WO 2008/089370 A1, followed by US 2007/0076719 A1 (Allan/Nortel). These are the only citations that both (a) sit at the PBB/PBT↔MPLS/VPLS boundary exactly like the '354 and (b) have pre-'354-priority U.S. filing dates giving real § 102(e) exposure. They line up with the asserted claims identified in the earlier Litigation summary (1–3, 5–6, 9–10, 12–13, 16–18, 20).
2. No clean § 102 anticipation of claims 1, 9, or 17. The distinguishing limitation — service mapping data keyed on combinations of I‑SID and C‑VID — is not disclosed by any cited reference, which is why each is better characterized as a § 103 reference (alone or in combination).
3. Date caveats: the pre-2006-01-25 group (US20040037279, US20040042454, US20040081171, US20040170173, US20050013297, US20050044262, US20050169270) is the only block eligible under § 102(b); the Nortel post-2006 group qualifies only under § 102(a)/(e); the rest are § 103-only.
4. Confidence: High that the citation list and publication/filing dates above match the USPTO record as rendered on the '354 Google Patents page (and corroborated by the US8619784 PDF and Justia/FPO listings). Medium on the precise § 102(a)-vs-(e) pigeonhole for the 2006–2008 publications, because those turn on the applicant's actual invention date, which the public record does not state. I found no additional USPTO-recorded prior-art citation beyond the 23 listed; if you need the as-filed PatentCenter "References Cited" pane (which can differ slightly from Google's aggregation), that should be pulled directly from PatentCenter before this is relied on in a brief.

Method note: the reference set and dates are drawn from the authoritative patent text supplied (USPTO-record-derived). Web searches were used only to corroborate citation identities and dates (e.g., the US8619784 PDF reference list, Justia/FreePatentsOnline "Referenced Cited" listings, and the Nortel US20070076719A1 / US20080172497A1 publication records); none of those contradicted the supplied text.

I'll ground my analysis in the prior-art references listed on the patent page, verifying the key ones before building the obviousness theory.

Let me verify a few date-critical references and check whether earlier versions exist, since two NPL items may postdate the priority date.

Obviousness Analysis Under 35 U.S.C. § 103 — US 9,264,354 B2

Built on the previously generated claim overview and litigation findings; those are not repeated here.

0. Analytical framing and a date-critical correction

Governing law. The '354 patent claims priority to provisional 60/897,778 (filed 2007‑01‑25) and was filed as a non‑provisional on 2008‑01‑22. It is therefore a pre‑AIA patent: §§ 102/103 as they read before the America Invents Act apply, and the "prior art date 2007‑01‑25" shown on the Google Patents page is the presumptive critical date.

Correction / flag to the earlier analysis. The patent page lists ten Non‑Patent Citations, including Sajassi et al., "VPLS Interoperability with Provider Backbone Bridges," Internet Draft, Mar. 2007. My verification shows the earliest version of that draft (draft‑sajassi‑l2vpn‑vpls‑pbb‑interop‑00) was posted 2007‑02‑27 — after the 2007‑01‑25 priority date (IETF datatracker history). The same is true of Belcher (World Wide Packets, 2007‑03‑08) and Allan et al., "Provider Link State Bridging" (Sep. 2008). None of those three NPL items may be used as prior art against the '354 claims on the stated dates. This matters because a surface reading of the examiner's citation list would suggest the Sajassi interop draft was "of record"; it is not § 102 art as dated. Its patent counterpart, however — Sajassi's US 2006/0245436 A1 (published 2006‑11‑02) — is squarely prior art and carries the same substance (see Ground A).

Usable prior art (verified dates) — the working set:

Not usable: WO 2008/118467 A1 (Hammerhead, priority 2007‑03‑26); US 7,903,676 (Cisco, filed 2008‑02‑05); US 2008/0219268 A1 (Dennison, priority 2007‑03‑01); US 2008/0144632 A1 (Rabie, PCT 2005 but US pub. 2008); US 2014/0071989 A1 and US 8,619,784 (applicant's own family). These all post‑date the critical date on the face of the page.

1. Level of ordinary skill in the art (POSITA)

A POSITA as of Jan. 2007 would have a B.S. in EE/CS (or equivalent) plus ~3–5 years designing carrier/metro Ethernet or MPLS transport equipment, with working knowledge of IEEE 802.1Q/802.1ad/802.1ah, the then‑emerging PBT/PBB‑TE work, MPLS LSPs and pseudowires, and VPLS as described in the IETF L2VPN drafts and in Cisco's Sajassi disclosure. This is the level at which each reference is presumed to be read.

2. The dispositive limitation and how the art maps to it

The claim overview already established the common thread of independent claims 1, 9, 17: the lookup key is the pair {I‑SID, C‑VID}, and the mapping data must define associations between services and corresponding combinations of values of those two fields. Everything else in claim 1 — a PE sitting between a PBB network and an MPLS network, reading header identifiers, and reformatting the frame into a "service frame" — is admittedly known.

Mapping the elements:

Nothing in the art discloses the literal two‑field {I‑SID, C‑VID} compound key. That is the single point of novelty, and it is precisely the kind of "combination of familiar elements according to known methods" that KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), holds obvious when the combination yields no more than predictable results. The remainder of this memo builds three grounds around that gap.

3. Grounds of rejection

Ground A (strongest): Sajassi '436 + Nortel '719 + Bottorff NPL, optionally + Zabihi '454 / Finn '171

Sajassi '436 discloses a network‑facing PE that (i) receives a frame whose VLAN tag carries a service instance identifier, (ii) maps that identifier into a second tag that identifies a VPLS instance, and (iii) forwards it across an MPLS/IP core over a pseudowire. It expressly recites the mapping of a service identifier to a service instance and the extension to 20‑bit service IDs, and it explicitly frames the invention as scalable VPLS interworking. This is the claim‑1 "determine a service … based on service mapping data" and "format … to obtain a service frame" steps, applied to VPLS.

Nortel '719 supplies the PBB/PBT half: a provider edge that receives PBT‑encapsulated traffic and, per its own specification, "the association of traffic with a specific virtual switched sub‑network is performed by I‑SID tagging of the traffic at the PE," with PBT trunks defined by destination address + VLAN ID and multiple VSS instances multiplexed over common trunk connectivity. That is a PE using a frame‑borne identifier to select among multiple services.

Bottorff (and, for stacking, Zabihi '454 or Finn '171) supplies the frame format: the PBB/PBT frame that arrives at the PE simultaneously carries the outer B‑VID/I‑SID and the encapsulated inner customer frame with its C‑VID/S‑VID. The inner C‑VID is therefore literally "specified in the frame" and available to the PE, exactly as claim 1 requires.

Why the combination: all three address the same problem — engineered, connection‑oriented Ethernet transport across a provider backbone and its interworking with VPLS/MPLS service networks. Sajassi already works at the PBB/MPLS boundary in substance; Nortel '719 already works at the PBB/PBT boundary; Bottorff defines the common frame they must parse. A POSITA implementing Sajassi's VPLS‑interworking PE on a PBB/PBT ingress port (as Nortel '719 and Bottorff describe) would necessarily parse the fields those references already identify.

Ground B (date‑tight but potent): Nortel '497 + Sajassi '436 + Bottorff

Nortel '497 (filed 2007‑01‑17, eight days before the critical date — § 102(e)) is arguably the closest reference. It discloses interworking between Ethernet (PBB and PBT domains) and MPLS networks at both the network and the service level; it states that the PBT ingress node "may select a trunk to carry the traffic to either MPLS domain Y or MPLS domain Z by looking at the VLAN ID associated with the frame"; and it describes de‑encapsulating PBB/PBT frames to reach PW/VPLS payloads, including the "dry martini"/PW‑in‑PBT arrangement in the '354's own FIG. 8. Paired with Sajassi '436 (mapping a service identifier to a VPLS instance over an MPLS/PW core) and Bottorff (the I‑SID + C‑VID frame layout), every claim‑1 element including the two‑field key is reached.

Because '497 is prior art by only eight days, patentee may attempt to swear behind it or to argue the provisional discloses the compound key. The provisional would need to be checked for whether it actually describes a {I‑SID, C‑VID} combination table; the '354 specification's own statement that "a given implementation may never need to match an I‑SID or a C‑VID or both" suggests the compound‑key emphasis was a later claim‑drafting overlay rather than the original disclosure's focus.

Ground C (structural/§ 103 rationale‑only): Sajassi '436 + Friskney '196 + Bottorff

Friskney ("Differential Forwarding in Address‑Based Carrier Networks," priority 2004‑04‑06) teaches the general technique of indexing forwarding treatment on a set of frame‑header bits (address + VID) rather than a single field. Combined with Sajassi's service‑identifier mapping and Bottorff's stacked PBB frame, it supplies the "why" for a multi‑field lookup key: the art already used compound bit‑sets as a lookup index when a single field was insufficient to disambiguate. Adding C‑VID alongside I‑SID in the same table is the application of a known technique to a known structure with a predictable result.

4. Motivation to combine (the KSR articulation)

The following reasons are drawn from the references themselves and from the problem the '354 specification identifies:

1. Same field, same problem, same solution shape. Sajassi, Nortel '719, and Nortel '497 all address scaling provider Ethernet and interworking it with VPLS/MPLS. KSR: combining references "designed to address the same problem" is obvious.
2. The fields already coexist in the frame. Once the PE parses an 802.1ah frame (Bottorff; Zabihi; Finn), the I‑SID and C‑VID are both present and both already used elsewhere for identification. Reading a second available field is not a new mechanism.
3. The stated business goal demands a second key. The '354 specification itself states the purpose is to "separate customer traffic according to the customer application or service, e.g., VoIP, video, Internet," and to unbundle one customer's traffic into multiple VPLS/EVPL services. I‑SID alone identifies the customer; C‑VID identifies the application/VLAN within that customer. A POSITA seeking the patent's own stated goal would predictably add the C‑VID column — a hallmark of "obvious to try."
4. Timing and commercial pressure. By late 2006, North American and European carriers (e.g., BT's 21CN selection, announced Jan. 2007) were demanding PBT/PBB‑TE interworking with MPLS/VPLS backbones; the motivation was dictated by the market, not by hindsight.
5. Predictable result, no new function. Each pre‑existing table row still maps a customer identifier to a service; adding a column refines granularity without changing how any element operates. KSR: "the combination of familiar elements according to known methods … when it does no more than yield predictable results."
6. Dynamic propagation was known. Sajassi's E‑GVRP/MVRP exchanges VLAN configuration among PEs automatically — antecedent to dependent claims 8 and 15 (updating the mapping data).

5. Dependent claims

These fall with a short, independent rationale:

6. Patentee's likely rebuttals, and responses

• "No reference discloses the combination of I‑SID and C‑VID." True literally; but the claim covers an indexing choice, and KSR forecloses treating an added lookup column as inventive where the fields, the table, and the goal were all known. Reinforce with Friskney (multi‑bit index) and with the specification's own concessions.
• "The references are non‑analogous / PBT vs. VPLS are different arts." Sajassi, Nortel '719, and Nortel '497 are the same art (provider Ethernet/MPLS transport) and were, indeed, combined commercially (Nortel PBT devices backhauling into MPLS backbones — see the BT 21CN coverage).
• "Secondary considerations." None of record with a nexus. The patent is asserted in K.Mizra LLC v. Nokia, 2:24‑cv‑00974 (E.D. Tex.) — where Nokia's preliminary invalidity contentions reportedly list the '354 with asserted claims 1–3, 5–6, 9–10, 12–13, 16–18 and 20 (per the previously generated litigation section). Any later‑asserted commercial‑success evidence would need a nexus to the compound‑key feature, not to PBT generally.
• Swearing behind Nortel '497 (Ground B). Only Ground B is exposed to this; Grounds A and C rely on art with 2005–2006 dates and are not.

7. Bottom line and confidence

Assessment: Claims 1, 9, and 17, and dependents 2–8, 10–16, 18–20, are more likely than not obvious under § 103, with the strongest single ground being Sajassi US 2006/0245436 A1 in view of Nortel US 2007/0076719 A1 and Bottorff et al. The case turns entirely on whether the {I‑SID, C‑VID} compound lookup key is treated as an inventive refinement or as a predictable added column — and the specification's own language (unbundling a customer's traffic by application; "may never need to match … both"; dynamically populated rows) cuts strongly against patentability.

Confidence: High on the reference dates and § 102 status (verified above, including the correction that the Sajassi/Belcher/Allan NPL items postdate the priority date and cannot be relied on). Medium‑high on the ultimate § 103 conclusion, since it rests on a KSR judgment call about the compound key rather than on literal anticipation, and I could not inspect the '354 provisional (60/897,778) to confirm what it supports, nor obtain the full text of Nokia's invalidity contentions within this session.

Unverified / needs checking before reliance: (i) the '354 provisional's disclosure; (ii) the exact claim of Sajassi '436 relied on for the MPLS‑core element (its claim 4 recites MPLS/IP, verified); (iii) whether any pre‑2007 version of the Sajassi interop draft exists beyond -00 (2007‑02‑27) — I found none.