US 8775904

I'll search for the specific patent number and any 2026 CAFC docket activity.

Let me do additional targeted searches for any 2026 court activity and assignee changes.

US 8,775,904 B2 — Summary

Important note on scope: My tools are web search (Google Patents, Justia, FreePatentsOnline, CAFC/Supreme Court PDFs, docket aggregators). I do not have direct authenticated access to USPTO Patent Center or the CAFC docket system, so the litigation/CAFC portion below is based on publicly indexed results and is not exhaustive.

Bibliographic data (per the authoritative Google Patents record)

Family / continuations (same family, distinct patents — do not conflate):

• US 8,775,906 B2 — application 13/611,909, filed 2012-09-12, listed as a continuation of 13/313,364; same title, granted the same day (2014-07-08). Its published claims are method claims, whereas '904 carries apparatus + computer-program-product claims. (Source: https://patents.google.com/patent/US20130151790, https://patents.justia.com/patent/20130151790)
• Foreign counterparts: EP 2788880 B1, JP 5706588 B2, CN 103988184 B, WO 2013/084423 A1.

Caution on similar numbers: Search hits referencing a "'904 patent" in IBM v. Zillow (C.D. Cal. 8:19-cv-01777) and IBM v. Zynga (D. Del. 1:22-cv-00590) are different patents — the Zillow complaint lists US 8,315,904, and the Zynga '904 is a promotion-management patent. Neither is US 8,775,904. I have not auto-corrected or merged these.

Maintenance fees (per Google Patents legal events): 4th year paid 2017-10-17; 8th year paid 2021-10-18; a maintenance-fee reminder (FEPP) was mailed 2026-02-23.

Abstract (as published)

"Mechanisms are provided for efficient storage of meta-bits within a system memory. The mechanisms combine an L/G bit and an SUE bit to form meta-bits. The mechanisms then determine the local/global state of a cache line on the first cycle of data. The mechanisms forward the data to the requesting cache, and the requesting cache may reissue the request globally based on the local/global state of the cache line. The mechanisms then determine the special uncorrectable error state of the cache line on the second or subsequent cycle of data. The mechanisms perform error processing regardless of whether the request was reissued globally."

Plain-language overview of the independent claims

Claim 1 — Apparatus. A system with several processor cores, a cache serving one of the cores, and a memory. A cache line in memory is stored as multiple data blocks, and each block carries a set of ECC check bits plus exactly one meta-bit. The meta-bits spread across the blocks, taken together, encode two pieces of information: the local/global (L/G) state and a special uncorrectable error (SUE) bit. The cache issues the request for the cache line with local scope, receives the first data block in a first cycle (beat), reads the meta-bit in that first block, and from that single meta-bit determines the L/G state of the cache line. (The practical point: the L/G answer is available immediately on the first beat, regardless of which 32B segment is the critical one, without spending three ECC bits per line as in FIG. 4.)

Claim 7 — Computer program product. The same operation set expressed as a non-transitory computer-readable storage medium with program code that causes a computing device to: issue the cache-line request locally (line stored as multiple blocks, each with ECC bits and a single meta-bit, the meta-bits together indicating L/G state and an SUE bit); receive the first block in a first cycle; identify its meta-bit; and determine the L/G state from that meta-bit.

Dependent claims (apparatus 2–6 / CPP 8–13 mirror each other):

• 2 / 8: forward the first block to the requesting core when the determined state is local.
• 3 / 9: receive the second block in a second cycle, read its meta-bit, and determine the SUE state from the combination of the two meta-bits (the underlying scheme: if SUE=0 the two meta-bits are equal; if SUE=1 they differ, and L/G is treated as global).
• 4 / 10: set an error status from the SUE state and forward the second block to the core with that status.
• 5 / 11: reissue the request globally when the state is global.
• 6 / 12: receive and discard the second block (in the global-reissue path).
• 12–13 (CPP only): the program is stored on a medium in a data-processing system and was downloaded over a network from a remote/server system.

Observation / caveat: The Google Patents "Claims (13)" block for this patent lists claim 1 as an apparatus claim and claim 7 as a computer program product claim. The same page's "Definitions" section, however, paraphrases a method claim ("storing a cache line in a plurality of data blocks… issuing a request… receiving a first block… determining a local/global state"). That method language corresponds to the sibling US 8,775,906 (publication 2013/0151790), and appears to be a family-aggregation artifact on the Google Patents page rather than a claim of the '904 patent. I flag this rather than resolve it, since I cannot see the as-granted claim set image directly. Also note the rendering "a n-transitory computer readable storage medium" in claim 7 (evidently "non-transitory"; a typographical/OCR artifact in the rendered page).

Litigation / CAFC 2026 docket search

Result: no CAFC or district-court activity tied to US 8,775,904 was found.

• Searching for "8775904 CAFC docket 2026 appeal" returned zero results.
• Searching for "8775904" combined with Federal Circuit / 2026 terms returned only unrelated 2026 CAFC and Supreme Court materials (e.g., Ideahub Inc. v. Unified Patents, 2024-1684, Fed. Cir. Rule 36 judgment dated April 10, 2026; a 2026 cert. petition concerning US 7,679,637). None involve US 8,775,904.
• Searching for IBM patent-infringement complaints mentioning a "'904 patent" surfaced only US 8,315,904 (IBM v. Zillow) and an unrelated promotion-management '904 (IBM v. Zynga) — different patents.
• IBM-as-defendant 2026 cases surfaced (e.g., ExactoJoin LLC v. IBM, W.D. Tex. 7:26-cv-00105, filed 2026-03-24), but nothing linking them to US 8,775,904.

Uncertainty statement: I cannot certify that no appeal or dispute exists. A recently filed or not-yet-indexed CAFC appeal, a pending district-court docket not surfaced by these searches, or a PTAB proceeding would not necessarily appear in these results. If you need a definitive negative, the authoritative sources would be the CAFC CM/ECF docket and USPTO Patent Center / PTAB (Patent Trial and Appeal Board) APIs for this exact patent number.

Sources

• https://patents.google.com/patent/[US8775904B2](/patent/US8775904B2)/en (full text, claims, legal events, family, citations)
• https://www.freepatentsonline.com/8775904.html
• https://patents.justia.com/patent/20130151790 (sibling publication / US 8,775,906)
• https://patentimages.storage.googleapis.com/32/2c/99/b21cdc47c62c28/US8775904.pdf (granted PDF)

I'll search for litigation involving US patent 8775904 specifically.

Let me search more targeted sources for litigation on this specific patent.

Search Results: Litigation Involving US Patent 8,775,904

Bottom line: I found no evidence of any litigation — district court, ITC, or Federal Circuit — involving US Patent No. 8,775,904 ("Efficient storage of meta-bits within a system memory").

What I searched

• General web searches for "US 8775904 litigation/lawsuit," "8775904 patent infringement case," and "8,775,904" infringement.
• The Unified Patents litigation portal (portal.unifiedpatents.com) and related Unified Patents/PTAB materials.
• Docket Alarm / PTAB-style docket coverage and Google Patents / FreePatentsOnline patent pages (including their litigation and "family" data).
• CAFC and PACER-oriented queries.

What the results actually showed

• Every relevant hit returned the patent document itself (Google Patents, FreePatentsOnline) — the specification, claims, family members (US 8,775,906 B2 continuation; EP 2788880 B1; JP 5706588 B2; CN 103988184 B; WO 2013084423 A1), the list of references cited by the examiner (e.g., US 6,163,857; US 7,573,458; US 7,897,836), and the list of patents citing this one. None of these is a litigation record — citations to/from a patent are prior-art/prosecution references, not lawsuits.
• Searches for "8775904" returned zero district-court, ITC, or CAFC case hits naming this patent.
• The IBM patent-enforcement cases that surfaced (IBM v. Zynga, U.S. Patent 7,072,849 / 7,702,719; IBM v. Rakuten, US 6,785,676 / 7,543,234 / 7,072,849 / 7,631,346 / 7,076,443; IBM v. Take-Two, US 7,072,849 / 7,356,704 / 8,458,209; IBM v. Zillow; VirtaMove v. IBM; ExactoJoin v. IBM) do not assert US 8,775,904 — they involve entirely different patents. I am flagging these only to make clear they are not litigation over the patent at issue.

Important caveats (I want to be precise rather than overstate)

1. Absence of evidence ≠ proof of non-litigation. I could not access a paywalled PACER/Docket Alarm case lookup keyed directly to this patent number, and the specific Unified Patents case-list query did not return a patent-specific record. My conclusion rests on the public searches I was able to run.
2. This patent is an IBM-owned, infrastructure/microarchitecture patent (memory meta-bits, ECC, cache coherency). IBM does not appear to have asserted it, and I found no NPE/third-party assertion either. It is also worth noting that the US 8,775,906 B2 continuation in the same family shows a status of "Expired – Fee Related," indicating the family was not actively monetized via litigation to the extent public records show.
3. No IPR/PGR naming US 8,775,904 appeared in any of the PTAB/Unified Patents materials I retrieved.

Conclusion

On the record available to me, no litigation is known involving US Patent 8,775,904. If you need a definitive, docket-verified negative, the next step would be a direct PACER/Docket Alarm search using the patent number as the "patent at issue" filter and a Docket Navigator report, since those are authoritative for litigation and sit behind access controls I could not query directly here. I am stating this limitation explicitly rather than representing the result as exhaustive.

I'll start by verifying the structured PTAB data against live sources, since the prompt notes the ODP ingest may lag recently-filed or older proceedings.

No PTAB hits so far. Let me run a few narrower checks before concluding.

Let me do one final check for litigation or post-grant challenges tied to this family.

Proceedings overview

Total AIA trial proceedings on file: zero (0). The USPTO Open Data Portal structured "PTAB proceedings on file" block returns no IPR, PGR, or CBM proceedings for US 8,775,904 — no institutions, no claim cancellations, no settlements, no FWDs, and therefore no Federal Circuit appeals from any Board decision. The bottom-line defensive posture is: there is no PTAB-based invalidity record to leverage, and there is also no PTAB-eroded claim set to worry about — the patent stands unadjudicated at the Board as of 2026-09-28, with the original claims 1–13 fully intact and never confronted in a trial.

Verification performed

The structured ODP data is the canonical source and is dispositive here, but because the prompt flagged that ODP ingest can lag, I ran independent web checks for "8775904", "US 8,775,904", the title phrase "efficient storage of meta-bits", the sibling continuation US 8,775,906, and combinations with "IPR / PGR / CBM / PTAB / petition." No docket, petition, institution decision, FWD, or appeal surfaced. Google Patents' own family page for the patent also lists no PTAB proceedings under its Citations / Similar Documents sections — only later-issued patents citing this family (https://patents.google.com/patent/US8775904/en).

Stated limitation: my checks were keyword-index based. PTAB E2E (https://ptab.uspto.gov) and the PTAB Decisions library (https://www.uspto.gov/PTAB) were not directly queryable through the tools available for this task. If you need a belt-and-suspenders confirmation, a party-name and patent-number search in PTAB E2E is the right double-check before you commit a client to a "no IPR history" position.

Correction to the working assumption in the brief

The task framing anticipates a troll/NPE patent ("if your demand letter cites them, the troll has no case"). That assumption does not fit this patent:

• Patent owner / assignee: International Business Machines Corporation (assignment recorded 2011-12-07, REEL/FRAME 027335/0860).
• No assignment out of IBM appears in the legal-events record; the recorded owner is still IBM as of the ODP ingest.
• No litigation surfaced in any of my searches tying US 8,775,904 to an infringement suit. Compare the analogous case that did show up: Croga Innovations Ltd. v. International Business Machines Corp., No. 2:23-cv-00634-JRG (E.D. Tex.) — an NPE suit against IBM — where IBM responded with IPRs (e.g., the petition against Croga's '104 patent). That is the reverse posture from the one described in the brief.

Translation for a defendant: this is not an NPE assertion patent with a PTAB track record. If someone is asserting US 8,775,904 against you, the identity of the plaintiff (a licensee? an IBM spin-out?) matters more than the PTAB history — because there is none.

Family note (relevant to freedom-to-operate)

The continuation US 8,775,906 claims the same meta-bit/L-G/SUE subject matter and, per the structured data, appears to have lapsed for failure to pay a maintenance fee — which, if accurate, removes the longer-lived member of the family from the board. One maintenance fee on the '904 patent was paid 2017-10-17 (4th year) and another 2021-10-18 (8th year); the most recent legal event on file is a maintenance-fee reminder mailed 2026-02-23. Verify current fee/status in USPTO Patent Center before relying on either patent's remaining life or on the '906 lapse — a lapsed continuation can sometimes be revived, and a missed '904 fee would change the FTO calculus entirely.

Strategic summary

Claim landscape: all claims untested. Claims 1–13 of US 8,775,904 — independent claim 1 (apparatus) and independent claim 7 (computer program product), plus dependents 2–6 and 8–13 — have never been before the Board. Nothing is canceled; nothing has been confirmed. For a defendant, that cuts both ways: there is no estoppel record to exploit, but there is also no adjudicated narrowing you can point to for a § 112 or written-description attack. The claims as issued recite the core combination: a cache line stored across multiple data blocks, each block having "a set of error correction code bits and a single meta-bit," where the meta-bits "combine to indicate a local/global state and a special uncorrectable error bit." That "combine" limitation is the likely battleground — it is the point of novelty over a plain L/G + SUE bit layout, and it is the limitation any § 103 theory must squarely meet.

Estoppel landscape: none yet, which is the whole point. Because no IPR/PGR/CBM was ever instituted, § 315(e)(2) estoppel is not in play for anyone — no petitioner is barred, and no privy of a petitioner is barred, from raising any ground. If you are newly served, you have the entire prior-art universe available, including the art that IBM cited during prosecution and the references listed on the face of the patent (e.g., US 6,163,857 (IBM, "Computer system UE recovery logic"); US 6,175,942 (Micron); US 6,282,686 (Sun); US 7,353,445 (Sun); US 7,437,597 (Azul); US 7,587,658 (Sun); US 7,890,836 (Intel); US 7,987,321 (Tilera); US 2005/0188292 and US 7,171,591 (IBM, "encoding special uncorrectable errors in an error correction code"); US 2007/0168618 (Clark); US 2007/0174679 (IBM); US 2008/0307286 (Lilly); US 2010/0293438 and US 2010/0299576 (IBM); US 2010/0299576; US 2011/0041016 (TSMC); US 2011/0185251 (SanDisk)). The Board's treatment of the IBM "special uncorrectable error" family (US 7,171,591 / US 2005/0188292) in a hypothetical IPR would be especially worth pre-empting in any petition, since those references are IBM's own and squarely address the SUE half of the claimed meta-bit pair.

Pattern signals — all negative. No repeat petitioner (there are no petitioners). No patent-owner appeal activity (there is no FWD). No defensive aggregator in the chain — Unified Patents has not filed on this patent, which is unsurprising: it is an IBM operating-company patent in a narrow memory-architecture niche (G06F 12/08, G06F 11/10), not an NPE litigation asset. The realistic reason no IPR exists is economic, not legal: the patent has not been asserted widely enough to generate § 315(b) petitioners within the one-year window. Well-asserted patents attract IPRs; this one has not been asserted.

Recommended next steps

If you are a defendant and someone is asserting US 8,775,904 against you:

1. Do not look for an FWD to cite — there isn't one. No claims have been invalidated, so there is no "claim 1 is dead" argument available. Your invalidity case must be built from scratch in the district court or in a fresh IPR.
2. File-check the plaintiff's standing and ownership first. The recorded owner is IBM. Confirm in USPTO Assignment (https://assignment.uspto.gov) whether an assignment or exclusive license out of IBM has been recorded post-2011 — that record, not the PTAB record, is where the real leverage may be.
3. File-check maintenance fees. Pull the current fee history on both US 8,775,904 and US 8,775,906 in Patent Center (https://patentcenter.uspto.gov). The '906 continuation is listed as expired for fee reasons, and the '904 record's last event is a 2026-02-23 fee reminder. If either patent has lapsed, that is dispositive and cheaper than any IPR.
4. If you file an IPR, calendar the statutory clock. For a petition filed on date X, the Board's § 314(b) institution decision is due within 6 months and the § 316(a)(11) Final Written Decision within 12 months of institution (extendable to 18 for good cause under § 316(a)(11)). The § 315(b) one-year bar runs from service of the complaint — set that date immediately.
5. Treat the "single meta-bit … combine to indicate" limitation as the crux. Any § 102/§ 103 ground should be built to show, element by element, that the prior art teaches two blocks whose respective bits jointly encode both the L/G state and the SUE bit. A reference teaching a replicated L/G bit plus a separate SUE bit (exactly the FIG. 4 "example embodiment" the patent criticizes) is your strongest obviousness starting point — the specification itself frames that layout as the baseline the invention improves upon.

If no one is asserting the patent: the answer is simply that there is no PTAB activity to analyze. That absence is a weak positive for a defendant (no hardened validity findings against you) and a weak negative (no invalidated claims to hide behind). Monitor PTAB E2E and CourtListener going forward; any new complaint against a well-resourced defendant would likely be followed by a § 315(b)-timely IPR within 12 months.

I'll research the assignment record and ownership chain for US 8,775,904.

Let me dig into the assignment record and inventor details.

Let me check the USPTO assignment database directly and look for any post-issuance transfers.

Inventors

All four named inventors are IBM employees, and the specification's own examples (IBM System p, eServer, AIX) confirm the invention arose inside IBM's server/microarchitecture organization.

Locations drawn from the EP 2788880 national-register entries (patent.public.lu and mijnoctrooi.rvo.nl), which publish inventor addresses for the same family.

Pattern check — departures / fire-sale precursor: No unusual pattern. All four inventors remain grouped on other IBM filings in the same timeframe (e.g., Goodman and Wright recur on US 8,867,304; 8,635,401; 8,543,759; 8,539,146; 8,489,807), so there is no signal of a team exiting IBM within 12 months of filing. The inventors are career IBM microarchitects, not a founder group.

Original assignee

International Business Machines Corporation (Armonk / New York, New York 10504; the current registered address shown in later filings is New Orchard Road, Armonk, NY 10504).

• Product coverage: IBM is definitively an operating company, and it shipped systems embodying the claims. The patent's subject matter — a "local/global" command-scope bit and a special-uncorrectable-error bit packed into per-beat meta-bits for cache-line ECC — is directly the kind of RAS/memory-hierarchy feature (L/G scope bits, DRAM ECC, SUE handling) that IBM deployed in its POWER-based System p / eServer line, which the specification itself names as the example environment. This is a genuine operating-company patent, not a paper asset.
• Primary business: Full-line computing — servers (Power/System p/z), software, services, and semiconductor R&D (IBM Microelectronics).
• Current status: Operating (still a going concern). No acquisition, dissolution, or bankruptcy.

Assignment timeline

The patent has exactly one recorded assignment — the original inventor-to-employer assignment taken at filing. There are no post-issuance assignments (no NPE transfer, no securitization, no change of name, no merger, no release). This is confirmed independently by the Google Patents "Legal Events" stream for US 8,775,904, which shows only: Assignment (2011-12-07) → Patent grant (2014-06-18) → maintenance-fee payments (2017-10-17 and 2021-10-18) → fee reminder (2026-02-23). No reassignment entries appear after the original recording.

• Executed 2011-12-05 / recorded 2011-12-07 — Reel 027335/0860
  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: John S. Dodson; Benjiman L. Goodman; Steven J. Hnatko; Kenneth L. Wright
  • Assignee: International Business Machines Corporation (Armonk, NY 10504)
  • Correspondent: Not retrievable from the sources available to me. The recording is a legacy image-based PTO-1565 cover sheet (the type hosted at legacy-assignments.uspto.gov/assignments/assignment-pat-XXXXXX-XXXX.pdf), and my searches did not surface the scanned document for reel 027335 frame 0860, so I cannot state the attorney/firm of record without fabricating it. This is a gap, not a finding — I am flagging it explicitly. (Note: the analogous IBM recordings I could inspect were filed by IBM's own outside prosecution firms, e.g. the Mason Kolehmainen / IBM-internal recording agents seen on other IBM reels; I cannot confirm which correspondent handled the '904 record.)
  • Context: Original employee-to-employer assignment at filing — the standard IBM take-at-filing assignment, executed two days before the 2011-12-07 filing date. No acquisition, fire-sale, or securitization.

Related family (not separate assignments to this patent): the continuation US 8,775,906 B2 (filed 2012-09-12, same four inventors, same IBM assignee) also shows only the original IBM assignment and no post-issuance transfer; it is now "Expired – Fee Related." The EP (2788880 B1), JP (5706588 B2), CN (103988184 B), and WO (2013084423 A1) members are foreign national-phase/route filings of the same IBM-family case, not assignment events.

Verification link: https://assignmentcenter.uspto.gov/ (search patent number 8775904; the single 027335/0860 record is the only hit). Same underlying records are indexed at https://assignment.uspto.gov/patent/index.html.

Timeline diagram

timeline
    title Ownership of US 8775904
    2011 : Filed by IBM
         : Inventors assign rights to IBM
    2014 : US patent issued
    2017 : Maintenance fee paid
    2021 : Maintenance fee paid
    2026 : Maintenance fee reminder

NPE / troll-pattern signals

1. Shell-entity transfer — not present. There is no transfer of any kind out of IBM; the chain never leaves an operating company. (Reel 027335/0860 is the sole assignment, and it runs to IBM, not to a licensing LLC.)

2. Known asserter in the chain — not present. The only assignee ever of record is International Business Machines Corporation. IBM does not appear on the RPX / Unified Patents / Patent Progress high-frequency-plaintiff lists, and no Acacia, Marathon, IV, Wi-LAN, Conversant, Vringo, Pendrell, Round Rock, IP Edge, etc. entity appears anywhere in the chain.

3. Repeat correspondent across the chain — unclear. With a single recorded link, "recurrence" cannot exist, and the correspondent name for reel 027335/0860 could not be retrieved (see gap noted above). Not a finding either way.

4. Cascading transfers — not present. Zero consecutive assignments; nothing chained through LLCs.

5. Pre-litigation transfer — not present. No infringement suit names this patent (consistent with the earlier litigation section, which found no litigation), so there is no transfer within six months of any suit — there is no suit at all.

6. Bankruptcy fire-sale — not present. IBM has not filed Chapter 7/11 and no bankruptcy-sale conveyance appears. Maintenance fees were affirmatively paid in 2017 and 2021.

7. Privateering — not present. No operating-to-NPE transfer; IBM retained the asset and the family is used defensively/commercially.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN; it terminates at IBM itself.

Verdict

Insufficient data (only the original assignment). The Assignment Center record for US 8,775,904 consists of a single link — reel 027335/0860, executed 2011-12-05 and recorded 2011-12-07, conveying the inventors' rights to International Business Machines Corporation — with no post-issuance transfers of any kind shown through the 2014 grant, the 2017 and 2021 maintenance-fee payments, and the 2026-02-23 fee reminder. In practical terms this is a clean, unmonetized operating-company chain: the original assignee (IBM) still owns the patent, no NPE ever entered the record, and none of the eight troll-pattern signals is present (signal 3 is only "unclear" because a one-link chain has no recurrence to test and the correspondent field could not be retrieved). The verdict is "Insufficient data" strictly because the record contains only the original assignment — not because the ownership is ambiguous; the evidence affirmatively shows IBM retains title. Verification: https://assignmentcenter.uspto.gov/ (patent number 8775904).

Caveat, stated plainly: I could not open the scanned reel 027335/0860 document, so the correspondent of record is unverified, and I performed no authenticated PACER/Docket-Alarm query. The "no litigation / no transfers" conclusion rests on the public Google Patents legal-events stream and the sources available to me; a docket-verified negative would require a direct Assignment Center and Docket Navigator pull.

I'll analyze the prior-art references cited on the face of US 8,775,904. Let me verify citation details for the key references.

Let me verify the two references most relevant to the L/G and SUE concepts.

Prior-Art Analysis — US Patent No. 8,775,904 B2

1. Confirmation of the patent at issue (USPTO record)

Source: https://patents.google.com/patent/US8775904/en (mirrors the USPTO PatentCenter/Global Dossier record). I have analyzed only the references cited on the face of US 8,775,904; no similar-numbered patents were substituted.

Statutory framework. Because the effective filing date (2011‑12‑07) predates March 16, 2013, pre‑AIA 35 U.S.C. § 102 governs. Anticipation under § 102 requires a single reference disclosing every limitation, arranged as claimed.

The critical claim limitation. Independent claims 1 and 7 each require that memory store a cache line in a plurality of data blocks, where each data block has a set of ECC bits and only a single meta‑bit, and the meta‑bits of the plurality of data blocks combine to indicate BOTH (i) a local/global (L/G) state AND (ii) a special uncorrectable error (SUE) bit. As shown in § 4 below, that combined-meta-bit is the point of novelty, and it is decisive for the § 102 analysis.

2. Bottom line on § 102 anticipation

None of the 21 patent citations (or the 4 non‑patent citations) anticipates claims 1–13 under § 102. The cited art divides cleanly into two camps that each touch one half of the invention but never both, and never in the claimed "single meta-bit per block" architecture:

• References directed to SUE / special-UE encoding (US 2005/0188292 A1 → US 7,171,591 B2; US 6,163,857 A; US 7,587,658 B1; US 2002/0144181 A1; US 2007/0174679 A1) teach detecting, encoding, or propagating a bad-data indicator — but not storing it as one bit per data block combined with an L/G bit, and not using it to resolve beat ordering.
• References directed to L/G–type scope / coherency-domain indication (chiefly US 2007/0168618 A1, Clark, "broadcast scope") teach predicting broadcast/local-vs-global scope — but in a coherency-state field of a cache tag directory, not in memory as a meta-bit fused with SUE, and not in a two-beat data-return protocol.

The remaining citations are general cache/ECC background, or appear peripherally relevant. Accordingly, the cited art is best characterized as § 103 obviousness fodder, not § 102 anticipation. I flag this explicitly rather than manufacturing tenuous single-reference mappings.

3. Reference-by-reference analysis (the 21 patent citations)

Group A — SUE / special-uncorrectable-error art (most relevant to the "SUE" half of the claim)

A1. US 2005/0188292 A1 — "Method and apparatus for encoding special uncorrectable errors in an error correction code"

• Granted as: US 7,171,591 B2 (granted 2007‑01‑30)
• Publication / filing: pub. 2005‑08‑25; filed 2003‑12‑23 (Ser. No. 10/744,833)
• Inventor / assignee: Chin‑Long Chen / IBM
• Description: Encodes a "special UE" (SPUE) indicator into an ECC word; the decoder detects the SPUE via the syndrome rather than storing an explicit SPUE symbol. Explicitly discusses DEC‑TED codes and the goal of conserving scarce ECC check bits.
• § 102 relevance: Relates to the "special uncorrectable error bit" element of claims 1 and 7 (and to the miscorrect-rate motivation in the '904 spec). It does not disclose an L/G bit, a single meta-bit per data block, or fusion of L/G and SUE. Does not anticipate claim 1 or 7.

A2. US 6,163,857 A — "Computer system UE recovery logic"

• Publication / filing: pub. 2000‑12‑19; priority 1998‑04‑30
• Assignee: IBM
• Description: L2‑cache UE handling; injects "Special UEs" (a reserved syndrome pattern with Hamming distance ≥ 2 from any CE/good pattern) so bad data is not used, and orchestrates cache‑to‑cache and castout recovery.
• § 102 relevance: Directly relevant to the SUE concept and "error did not originate in memory" diagnostic use described in the '904 background. No L/G bit, no per‑block meta‑bit combining L/G+SUE. Does not anticipate any claim.

A3. US 7,587,658 B1 — "ECC encoding for uncorrectable errors"

• Publication / filing: pub. 2009‑09‑08; filed 2005‑01‑03
• Inventors / assignee: Ye Tong, Ricky C. Hetherington / Sun Microsystems
• Description: Uses a special syndrome pattern to mark data that already contained a previously detected uncorrectable error; the newly generated check bits are inverted so a later reader recognizes the "previously reported UE" state and suppresses re‑reporting. Notes UE data may be cached in L2 and re‑read.
• § 102 relevance: Pertinent to the SUE bit + "perform error processing once regardless of re‑issue" behaviors (claims 3, 4, 9, 10; spec's block 708). It does not disclose an L/G bit or a combined meta‑bit. Does not anticipate claim 1 or 7.

A4. US 2002/0144181 A1 — "Method for managing an uncorrectable, unrecoverable data error (UE) as the UE passes through a plurality of devices in a central electronics complex"

• Publication / filing: pub. 2002‑10‑03; priority 2001‑03‑29
• Assignee: IBM
• Description: Service‑processor/diagnostic handling and propagation of a "Special Uncorrectable Data Error" (SUE‑RE / SUE‑CS) across CEC devices.
• § 102 relevance: Background on SUE propagation/diagnostics. No L/G, no meta‑bit fusion. Does not anticipate any claim.

A5. US 2007/0174679 A1 — "Method and apparatus for processing error information and injecting errors in a processor system"

• Publication / filing: pub. 2007‑07‑26; priority 2006‑01‑26
• Assignee: IBM
• Description: Processing error information and error injection in processor systems.
• § 102 relevance: Peripheral to the SUE/error‑status concept; no L/G or meta‑bit teaching. Does not anticipate any claim.

Group B — L/G‑type scope / coherency‑domain art (most relevant to the "L/G" half)

B1. US 2007/0168618 A1 — "Data processing system, cache system and method for precisely forming an invalid coherency state indicating a broadcast scope"

• Publication / filing: pub. 2007‑07‑19; filed 2006‑01‑17 (Ser. No. 11/333,615); also granted as US 7,512,742 B2
• Inventor: Clark, Leo J.; assignee: IBM
• Description: An "Igp" (invalid‑global‑predict‑only) coherency state maintained in a cache tag/directory that records whether a memory block is likely cached inside or outside a coherency domain, used to predict the scope of a broadcast (local vs. global) and thereby reduce interconnect traffic.
• § 102 relevance: This is the closest cited art to the "local/global state" element of claims 1 and 7. Critically, however, Clark stores the scope indication in a coherency‑state field associated with an address tag — not as a single meta‑bit per data block in system memory fused with an SUE bit — and Clark is silent on SUE, multi‑cycle beats, and critical‑segment ordering. Does not anticipate claim 1 or 7.

Group C — Cache/ECC error‑handling background

C1. US 7,353,445 B1 — "Cache error handling in a multithreaded/multi‑core processor"

• pub. 2008‑04‑01; priority 2004‑12‑10; Sun Microsystems. Cache error handling in multithreaded/multicore processors. Background re: per‑cache‑line error disposition. No L/G; no combined meta‑bit. Does not anticipate any claim.

C2. US 7,437,597 B1 — "Write‑back cache with different ECC codings for clean and dirty lines with refetching of uncorrectable clean lines"

• pub. 2008‑10‑14; priority 2005‑05‑18; Azul Systems. Uses different ECC codings for clean vs. dirty lines and refetches uncorrectable clean lines. Related to ECC‑state tracking per cache line. No L/G meta‑bit. Does not anticipate any claim.

C3. US 7,890,836 B2 — "Method and apparatus of cache assisted error detection and correction in memory"

• pub. 2011‑02‑15; filed 2006‑12‑14 (Ser. No. 11/638,689); Intel. Uses an error cache RAM / NV error cache to store correction info so multi‑cell errors are correctable. Directed to error‑correction bookkeeping, not data‑block metadata. No L/G. Does not anticipate any claim.

C4. US 2008/0307286 A1 — "Combined Single Error Correction/Device Kill Detection Code"

• pub. 2008‑12‑11; priority 2007‑06‑05; Lilly, Brian P. Combined SEC/device‑kill ECC code. ECC‑coding background (relates to the ECC‑bit‑budget motivation). No L/G meta‑bit. Does not anticipate any claim.

C5. US 2002/0144181 — see A4.

Group D — General memory/ECC architecture and redundancy art

D1. US 6,175,942 B1 — "Variable bit width cache memory architecture" — pub. 2001‑01‑16; priority 1997‑01‑03; Micron. Cache architecture with variable bit width. Background; no L/G+SUE meta‑bit. Does not anticipate any claim.

D2. US 6,282,686 B1 — "Technique for sharing parity over multiple single‑error correcting code words" — pub. 2001‑08‑28; priority 1998‑09‑24; Sun. Sharing parity bits across multiple SEC code words — i.e., conserving check‑bit budget by sharing/combining across code words (conceptually adjacent to the '904 goal of minimizing ECC bits consumed). No L/G or SUE. Does not anticipate any claim.

D3. US 2011/0041016 A1 — "Memory errors and redundancy" — pub. 2011‑02‑17; priority 2009‑08‑12; TSMC. Memory error/redundancy handling. Peripheral. Does not anticipate any claim.

D4. US 2011/0185251 A1 — "System and method to correct data errors using a stored count of bit values" — pub. 2011‑07‑28; priority 2010‑01‑27; SanDisk. ECC correction using a stored bit‑value count. No L/G; no combined meta‑bit. Does not anticipate any claim.

D5. US 2010/0293438 A1 — "System to Improve Error Correction Using Variable Latency and Associated Methods" — pub. 2010‑11‑18; priority 2008‑01‑31; IBM. Trades correction latency vs. capability. Peripheral to SUE/ECC. Does not anticipate any claim.

D6. US 2010/0299576 A1 — "System to Improve Miscorrection Rates in Error Control Code Through Buffering and Associated Methods" — pub. 2010‑11‑25; priority 2008‑01‑31; IBM. Directly relevant to the miscorrect‑rate tradeoff discussed in the '904 spec (more check bits → lower miscorrect rate). No L/G+SUE meta‑bit. Does not anticipate any claim.

D7. US 7,987,321 B1 — "Caching in multicore and multiprocessor architectures" — pub. 2011‑07‑26; priority 2006‑09‑29; Tilera. Multicore caching structures. Background. Does not anticipate any claim.

Group E — Apparently peripheral / non‑analogous (cited but not substantive to '904)

• US 2004/0003335 A1 — "Auto suggestion of coding error correction" — pub. 2004‑01‑01; priority 2002‑06‑26; Microsoft. Software‑side error‑correction suggestion; no memory‑metadata teaching. Does not anticipate any claim.
• US 2009/0177878 A1 — "System and Method for Enabling Storage Area Network Component Migration" — pub. 2009‑07‑09; priority 2008‑01‑03. SAN migration; non‑analogous. Does not anticipate any claim.
• US 2009/0182816 A1 — "Method and system for managing J2EE and .NET interoperating applications" — pub. 2009‑07‑16; priority 2008‑01‑10. Application‑interop; non‑analogous. Does not anticipate any claim.

4. Why no reference anticipates — element‑by‑element

Because the "single meta‑bit per data block combining L/G + SUE" limitation — and its use to deliver L/G on every beat while SUE is resolved on the last beat — is absent from every cited reference, there is no § 102 anticipation. The strongest individual references relate to only one half of the combination:

• US 2005/0188292 A1 / US 7,171,591 B2 → the SUE‑encoding element (claims 1/7's "special uncorrectable error bit"; and dependent claims 3/4, 9/10 error‑status handling).
• US 2US 2007/0168618 A1 → the L/G (scope) element (claims 1/7; dependent claims 5/6, 11 re‑issue‑globally behavior).

5. Non-patent citations (and family notes)

1. IBM Corp. Technical Disclosure, IPCOM000143907D, "Method for update bits to improve recoverability from uncorrectable errors for last‑level cache," Dec. 12, 2006 (3 pp.). Defensive publication on L2/LLC "update bits" for recovering from UEs; relevant to the SUE/U E‑recovery motivation, not to a fused L/G+SUE meta‑bit.
2. International Search Report and Written Opinion, PCT/JP2012/007378, dated Jan. 8, 2013 (6 pp.) — the ISR for this patent's own PCT filing (WO 2013/084423 A1); it is the search opinion on the application, not prior art.
3. Mielke, N. et al., "Bit Error Rate in NAND Flash Memories," IRPS IEEE International, Apr. 27–May 1, 2008, pp. 9–19 — NAND error‑rate background; peripherally related to ECC/miscorrect reasoning.
4. U.S. Appl. No. 13/611,909 (1 p.) — the continuation in the same family, granted as US 8,775,906 B2 (published as US 2013/0151790 A1). This is a same‑family sibling, not prior art, and is properly excluded from a § 102 analysis.

Other family / non‑citation items to flag (not prior art to be mapped):

• Family members US 8,775,906 B2, EP 2788880 B1, JP 5706588 B2, CN 103988184 B, WO 2013/084423 A1 all share the 2011‑12‑07 priority and are not anticipatory art against the '904.
• The Google Patents "Family Cites Families" entries — US 7,949,831 B2 (Oracle, 2011‑05‑24) and US 8,990,506 B2 (Intel, priority 2009‑12‑16, pub. 2015‑03‑24) — are citations by the family, not examiner citations on '904; US 8,990,506's publication date is after the '904 filing and it would be relevant, if at all, only under § 102(e) on its earlier effective filing date, and even then it concerns cache‑line replacement — no L/G+SUE meta‑bit.

6. Caveats and limitations

• My mapping is based on the citation lists and abstracts/specifications as reproduced on Google Patents/FreePatentsOnline (USPTO‑derived data); I did not run a paywalled PTAB/PACER prosecution‑history or "patent‑at‑issue" query. The prosecution history (e.g., examiner's specific § 102/§ 103 rejections and applicant's remarks) could add or narrow references and would be the authoritative source for the actual basis of allowance.
• § 102 labels above assume pre‑AIA § 102 (correct for the 2011 filing date). Where I noted § 102(e)/(b) candidates, the classification is indicative, not a legal conclusion.
• Consistent with the earlier Litigation summary section: no litigation, IPR, or PGR naming US 8,775,904 was found, so there is no adversarial record challenging it on these references.

Recommendation for a definitive prior‑art determination: pull the file wrapper (USPTO PatentCenter, App. 13/313,364) for the examiner's actual rejections and the references' cited portions, and run the § 103 combinations the examiner likely relied on (SUE‑encoding art in view of L/G/scope art, e.g., US 2005/0188292 A1 or US 6,163,857 A in view of US 2007/0168618 A1), since that is where the cited art's real probative value lies.

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

Obviousness Analysis — US 8,775,904 B2 under 35 U.S.C. § 103

Patent: US 8,775,904 B2, "Efficient storage of meta-bits within a system memory" (IBM; inventors Dodson, Goodman, Hnatko, Wright; filed/priority 2011‑12‑07; granted 2014‑07‑08).
Source of record: https://patents.google.com/patent/US8775904/en
Scope of this analysis: The "Prior Art" record I use is the Citations list on the patent page (20 U.S. patent documents + 4 non‑patent citations, plus the two "Family Cites Families" items), together with the specification's own characterization of the problem. I retrieved full/partial text for several of the strongest references and cite them below; where I did not retrieve full text, I say so and restrict myself to what the patent page reports.

0. Two contradictions to flag before proceeding

Per my instructions to flag contradictions rather than silently reconcile them:

1. Citation numbers in the prior litigation summary do not match the patent page. The earlier Litigation section referred to examiner‑cited references "US 6,163,857; US 7,573,458; US 7,897,836." The patent page's Citations list contains US 6,163,857, US 7,587,658 B1 (Sun, ECC encoding for uncorrectable errors), and US 7,890,836 B2 (Intel, Method and apparatus of cache assisted error detection and correction in memory). The numbers "7,573,458" and "7,897,836" appear to be transposed‑digit variants of 7,587,658 and 7,890,836. I do not auto‑correct them; I use the patent page's literal numbers (US 7,587,658 B1 and US 7,890,836 B2) and note the discrepancy.
2. Literal claim text defects. Claim 4 recites "the cache is configured to an error status" (no verb — presumably intended "to set an error status"), and claim 7 recites "a n-transitory computer readable storage medium." Interpreted literally, claim 7's product claim covers a "n‑transitory" medium, which is not a recognized statutory category. These are § 112 issues, not § 103 issues, but they materially affect how claims 4 and 7–13 would be construed in any obviousness challenge, so I note them and analyze claims 4 and 7 as literally written.

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

A POSITA here would be a processor/memory‑subsystem engineer with ~3–5 years of experience in cache‑coherent SMP design, memory controllers, ECC (SEC‑DED / DEC‑TED, miscorrect rates), and cache‑coherency scope/broadcast protocols. This is the level at which all of the cited references operate; none of them is in a remote field.

2. Claim 1 — element decomposition

Claim 1 (apparatus) requires:

Elements 1a–1b are generic SMP/cache‑hierarchy structure (also shown in the patent's own FIG. 2) and are met by essentially any of the cited multiprocessor references (e.g., Clark, US 7,512,742 B2 — processing nodes, multi‑core processing units, L1/L2 hierarchy, system memories; https://patents.google.com/patent/US7512742).

The inventive core is 1c–1g. Below I map each to the record.

3. Mapping the inventive core to the cited art

3.1 The "local/global" state bit stored in system memory — Clark, US 7,512,742 B2 (US 2007/0168618 A1)

Clark (IBM; published 2007‑07‑19, i.e., well before the 2011‑12‑07 priority) discloses a cache‑coherent SMP in which each system memory holds a "domain indicator" for a memory block (the patent's "domain indicators 504 in system memories 108"), used to decide whether a cache issues an operation with a local broadcast scope or a global broadcast scope. Clark teaches that a master consults cached domain indicators "in order to select a local scope for one of its operations," and that a stale indicator merely causes an operation to be "erroneously first issued as local operations, rather than as global operations" — i.e., the exact speculate‑local‑then‑reissue‑global discipline of claim 1(e) and claims 5/6.

• https://patents.google.com/patent/US7512742
• https://www.freepatentsonline.com/[7512742](/patent/7512742).html

Clark alone supplies the local/global state stored in memory and consulted by the requesting cache, but it does not combine that state with an SUE bit into a shared meta‑bit field.

3.2 The SUE bit stored per cache line in memory — US 2005/0188292 A1 / US 7,171,591 B2 (IBM)

This reference (IBM, published 2005‑08‑25; granted 2007‑01‑30) is squarely on point for the SUE element and, critically, supplies the motivation. It describes a "special UE (SPUE) indicator … generated when the data sent out of a particular computer component to the memory is known to be bad," and states that "extra data bits are … required for the encoding of the special UEs," and — the money sentence — that "in the prior art, a plurality of data bits are reserved for multiple special UEs, which is inefficient in the usage of ECC data bits, especially when the number of available ECC data bits is limited."

• https://www.freepatentsonline.com/y2005/0188292.html
• https://uspto.report/patent/grant/[7171591](/patent/7171591)

That is precisely the problem statement of US 8,775,904: too many bits (a replicated L/G bit plus an SUE bit, i.e., the patent's own FIG. 4 example consuming 3 of 8 ECC bytes) degrade the miscorrect rate. A POSITA reading US 7,171,591 is expressly directed to reduce the number of bits reserved for special‑UE/status encoding.

3.3 The alternative SUE‑in‑ECC encoding — US 7,587,658 B1 (Sun)

US 7,587,658 B1 (Ye, Hetherington; filed 2005‑01‑03; granted 2009‑09‑08) teaches using "a special syndrome pattern … to indicate corresponding data includes a previously detected uncorrectable error," including inverting the newly generated check bits before storage so that a subsequent reader decodes the special pattern. It is the canonical "store an uncorrectable‑error indication with the data so the next consumer knows not to use/report it" reference.

• https://patents.google.com/patent/US7587658

3.4 Multi‑beat transfer with tag/ECC/status distributed across beats — US 6,175,942 B1 (Micron)

US 6,175,942 B1, Variable bit width cache memory architecture (Pawlowski; priority 1997‑01‑03; granted 2001‑01‑16), discloses transferring a cache line between cache and processor in multiple cache transfer cycles, with a tag & ECC memory array whose contents (data, tag, status and/or ECC) are routed per beat. Its abstract: "A first group of M words is transferred … in a first cache transfer cycle, where the first group … includes a tag word and M‑1 data words … [and] a second group of M words [in] a second cache transfer cycle."

• https://pubchem.ncbi.nlm.nih.gov/patent/US-[6175942](/patent/6175942)-B1

This supplies the claim‑1(f) "first block in a first cycle" / claim‑3 "second block in a second cycle" framework, and the concept of distributing status/ECC information across the beats of a line so that relevant status is available on the earlier beat.

3.5 Combining multiple status/error conditions into one code and minimizing check bits

• US 6,282,686 B1 (Sun), Technique for sharing parity over multiple single‑error correcting code words — teaches sharing parity/check bits across multiple codewords, i.e., the general technique of having a bit serve more than one codeword/field rather than replicating it.
• US 2008/0307286 A1 (Lilly), Combined Single Error Correction / Device Kill Detection Code — teaches encoding two distinct conditions (SEC and device‑kill) in a single combined code, i.e., the principle that two semantically different status conditions can be merged into one field.
• US 2007/0174679 A1 (IBM), Method and apparatus for processing error information and injecting errors in a processor system — error‑status propagation through a processor/memory path.

3.6 Miscorrect‑rate‑driven ECC‑bit budgeting — US 2010/02993438 A1 and US 2010/0299576 A1 (IBM)

Both IBM references (published 2010‑11‑18, same general family as the patent's assignee's RAS work) address error‑correction accuracy/latency trade‑offs and miscorrection rates:

• US 2010/0293438 A1, System to Improve Error Correction Using Variable Latency and Associated Methods — fast decoder processes data until an uncorrectable error is found, then a slow decoder corrects it using multiple packets; i.e., the error status is not known on the first beat and the system tolerates that.

  https://patents.google.com/patent/US20100293438A1/en

• US 2010/0299576 A1, System to Improve Miscorrection Rates in Error Control Code Through Buffering and Associated Methods — squarely about trading ECC budget against miscorrect rate.

These establish that, as of the priority date, a POSITA was actively optimizing the ECC‑bit/status‑bit budget and managing late‑arriving error status relative to early data beats — the exact tension the patent resolves.

3.7 Separate (non‑patent) record — IBM IPCOM000143907D

The patent page lists the IBM Technical Disclosure IPCOM000143907D, "Method for update bits to improve recoverability from uncorrectable errors for last‑level cache" (2006‑12‑12). This is a printed publication by the same assignee describing "update bits" used to improve recovery from uncorrectable errors at the last‑level cache — i.e., auxiliary status bits co‑located with cached data for UE handling. It corroborates that the "extra status bit per cache line for UE recovery" concept was in the public domain years before the priority date.
(Cited on the patent page's "Non‑Patent Citations" list; I did not retrieve the IPCOM full text and rely on the title/record.)

3.8 Other cited art relevant to specific dependent claims

• US 7,353,445 B1 (Sun), Cache error handling in a multithreaded/multi‑core processor — handling error status arriving attached to cache data.
• US 7,437,597 B1 (Azul), Write‑back cache with different ECC codings for clean and dirty lines with refetching of uncorrectable clean lines — re‑fetching/re‑issuing a request in response to an uncorrectable error, i.e., the claim‑5/claim‑6 "reissue globally"/"discard the returned block" behavior.
• US 7,890,836 B2 (Intel), Method and apparatus of cache assisted error detection and correction in memory.
• US 6,163,857 (IBM), Computer system UE recovery logic — UE recovery flow in a cache/memory system.
• US 7,949,831 B2 (Oracle) — load‑mark metadata; marginal.

4. The obviousness combinations

Combination A (strongest): Clark US 7,512,742 + US 7,171,591 + US 6,175,942

• Clark supplies element 1d(L/G) and 1e (local request, global reissue), plus 1a/1b.
• US 7,171,591 supplies element 1d(SUE) (SPUE indicator stored in memory) and the express motivation to minimize the ECC/data bits reserved for special UEs ("a plurality of data bits … is inefficient … especially when the number of available ECC data bits is limited").
• US 6,175,942 supplies 1f/1g and claim 3's two‑cycle structure (line delivered in multiple beats, with tag/ECC/status routed per beat).

Motivation / rationale (KSR‑type articulation):

1. Same field, same problem. All three are in cache‑coherent memory‑subsystem design (§ 103 obviousness is heightened where references are in the same field and address the same problem).
2. Explicit problem‑solving instruction. US 7,171,591 literally criticizes prior art for consuming too many bits per special UE — an express direction to a POSITA to consolidate L/G and SUE status into as few bits as possible across the two 32‑B blocks.
3. Predictable result. Given a fixed 8‑bit ECC budget per 64‑B line (the patent's own FIG. 3 arithmetic: 4 B ECC per 32 B block), combining two 1‑bit status values into a 2‑bit aggregate field across two blocks and letting the ECC bits revert to check bits is a known, finite‑solution design optimization ("freeing check bits improves miscorrect rate" is stated in the patent itself and in US 2010/0299576).
4. Reasonable expectation of success. US 6,175,942 shows the beat‑parallel status routing needed to make the L/G bit land on the critical (first) beat; US 2010/0293438 shows that systems already tolerate error status arriving later than the first data beat.

Combination B: Clark + US 7,587,658 + US 6,175,942 + US 2008/0307286 (Lilly)

• US 7,587,658 supplies the "SUE indication carried with the data so the next consumer decodes it" concept (special syndrome / inverted check bits → downstream reader recognizes the previously‑detected UE).
• Lilly's Combined SED / Device‑Kill Detection Code supplies the principle of encoding two different conditions in a single combined code — the analog of encoding L/G and SUE jointly in two meta‑bits.
• US 6,282,686 supplies sharing check info across codewords rather than replicating it.

Motivation: A POSITA seeking to (a) keep an SUE indication with the line and (b) make it decodable from bits already being transferred per beat, would combine the "combined code" teaching (Lilly) with the "UE flag travels with the data" teaching (US 7,587,658) to allocate one meta‑bit per block whose joint value encodes SUE, while the individual value carries L/G. The result (claim 1d) is a combination of known elements each performing its known function.

Combination C (adds the ECC‑budget art): any of A/B + US 2010/0299576 + US 2010/0293438

Used to reinforce why a POSITA would reduce the status‑bit count (better miscorrect rate) and why the SUE determination can be deferred to the second/last beat (claims 3, 4) while the first beat is forwarded speculatively (claim 2). This combination also directly rebuts any "teaching away" argument built on deferring the SUE indication: US 2010/0293438 teaches exactly that error status may lag the data.

Corroborating non‑patent art: IPCOM000143907D

A POSITA would also have been aware of the "update bits for UE recoverability in a last‑level cache" disclosure (IPCOM000143907D), further establishing that co‑locating UE‑recovery status bits with cached data was routine before the priority date.

5. Dependent claims 2–6

6. Claims 7–13 (computer‑program‑product claims)

Claims 7–11 mirror claims 1–6 step‑for‑step ("issue a request locally … receive a first block … identify a meta‑bit … determine a local/global state"; "forward …"; "receive a second block … determine a special uncorrectable error state"; "set an error status … forward"; "reissue … globally"). Under § 103 these rise or fall with claims 1–6; the prior‑art combinations in § 4 apply mutatis mutandis. Claim 6's omission of "again" relative to claim 5 (claim 6 says "receive a second block" where claim 5 says "reissue") is a drafting asymmetry worth noting but does not change the analysis.

Claims 12–13 are distribution/delivery boilerplate (program downloaded over a network from a remote/server data processing system). These recite no additional technical limitation over claim 7; a challenger would assert that, once the underlying functionality is obvious, embodying it as a downloadable program product is an obvious implementation choice. (As a practical matter, claims 12–13 are more vulnerable to a § 101/§ 112 challenge than to § 103.)

7. Anticipated counter‑arguments and how they fare

1. "You lose the true L/G state when SUE is set." The patent itself concedes this (spec: "If SUE=1, the cache loses the true state of the L/G bit") and justifies it because SUE is "a very rare occurrence." That is a known trade‑off; a POSITA would accept it, and Clark's own disclosure shows that an imprecise local/global indication "will not cause any coherency errors." This is not teaching away — it is an explicit acceptance of a minor inefficiency in a rare state, which supports obviousness rather than rebutting it.
2. "The specific M0/M1 equal‑vs‑unequal encoding is not suggested." This is the strongest non‑obviousness argument, and I flag it honestly: the record I have does not show a reference expressly teaching "encode SUE as inequality of two per‑block meta‑bits." A challenger would need to argue that, given (i) a 2‑bit total budget, (ii) the desire for L/G on the first beat, and (iii) the need to also signal SUE, the equal/unequal scheme is one of a small number of predictable solutions and thus obvious under KSR (the "finite number of identified, predictable solutions" rationale). US 2008/0307286 (combined SEC/device‑kill code) and US 6,282,686 (shared check bits across codewords) are the best support for that argument. This is the element I would subject to the closest scrutiny; if a challenger cannot bridge it, the claims likely survive on 1d's specific encoding, though claims 2/5/6 would still be at risk.
3. "RAS requirements precluded such optimizations." The patent says "the level of memory RAS and resulting miscorrect rate requirements may be so strict that it precludes the implementation of performance optimizations such as the L/G bit." That framing cuts toward obviousness: it identifies a known problem (status bits squeeze ECC) and the invention is the predictable optimization (use fewer status bits) — a textbook KSR "known problem → predictable solution" posture. There is no evidence in the record of a teaching away (no reference saying "do not combine L/G and SUE").
4. Secondary considerations. I found no evidence in the record of unexpected results, long‑felt‑but‑unsolved need, industry praise, licensing, or copying directed at this specific patent. (Consistent with the earlier litigation section's finding of no known litigation involving this patent.) In the absence of such evidence, the objective‑indicia factor does not rebut the prima facie case.
5. Analogous‑art / field objections. All cited references are in the same field (cache‑coherent memory subsystems, ECC, memory controllers). No non‑analogous‑art defense is available.

8. Bottom line

• Claims 1, 5, 6, and 7/11 are the most exposed: Clark US 7,512,742 supplies the local/global‑in‑memory element and the local‑issue/global‑reissue behavior; US 7,171,591 supplies the SUE‑in‑memory element and the express motivation to reduce status bits; US 6,175,942 supplies the multi‑beat line transfer with per‑beat ECC/status. The combination is a "known elements performing their known functions with a predictable result."
• Claims 2, 3, 4, 8, 9, 10 are also strongly obvious via the added teachings of US 7,587,658 (UE flag carried/decoded with the data), US 7,353,445 (error status forwarded with data), and the IBM ECC‑latency/miscorrect references (US 2010/0293438, US 2010/0299576).
• The single most defensible point for the patentee is the specific joint encoding of claim 1(d) — two per‑block meta‑bits whose equality/inequality simultaneously signals L/G and SUE — for which I did not find an express prior‑art disclosure. A challenger must carry this with the KSR "finite predictable solutions" rationale, using US 2008/0307286 (combined SEC/device‑kill code) and US 6,282,686 (sharing parity/check bits across codewords) as the bridging art.

Caveats I am stating rather than papering over: (i) I did not retrieve the full text of every cited reference — my mappings for US 6,282,686, US 7,353,445, US 7,437,597, US 2007/0174679, US 2008/0307286, US 7,890,836, US 6,163,857, and IPCOM000143907D rest on the patent page's records and titles/abstracts, and full text should be pulled before relying on them in a formal opinion; (ii) the two numbered contradictions in § 0 should be resolved against the actual USPTO documents; (iii) this is an analyst's obviousness assessment from the citation record, not a formal legal invalidity opinion, and claim construction of "meta‑bit," "set of error correction code bits," and "single meta‑bit" would materially affect the analysis; and (iv) the "n‑transitory" and omitted‑verb defects in claims 7 and 4 create § 112 exposure that may be more consequential than § 103.