US 9258558

I'll search for this specific patent number.

Let me search for litigation/docket information and the specific claims.

Let me search for CAFC 2026 activity and the actual claim language.

Summary — US Patent 9,258,558 B2

Bibliographic data (per the authoritative full text and Google Patents record)

Note on the family: US 14/271,930 is not a first-filing; it is a continuation‑type filing of a family claiming the 2011‑01‑12 priority. The record lists a chain of further continuations claiming priority to it: US 14/951,893 (US 9,681,137 B2), US 15/498,774 (US 10,015,494 B2), US 15/995,654 (US 10,638,134 B2), US 16/822,816 (US 11,350,096 B2), US 17/733,257 (US 11,770,536 B2), US 18/232,045 (US 12,149,695 B2), and US 18/911,811 (US 2025/0039386 A1). An international counterpart publication in the same technical family is WO 2013/101067 A1.

Abstract / disclosure overview

I was not able to retrieve the literal abstract text verbatim from the sources returned; the following is a faithful paraphrase drawn from the specification's statement of invention and definitions section, not a quotation.

The patent is directed to entropy coding (specifically binary arithmetic coding/decoding, CABAC‑style) for image/video compression, where a picture is processed in processing units (blocks) of mutually different sizes (e.g., 4×4, 8×8, 16×16, 32×32, 64×64). The invention addresses the problem that in H.264/AVC‑style entropy coding a separate context (probability model) is defined per block size and per coefficient‑position/surrounding condition; as block sizes multiply, the number of contexts explodes, each context is updated less often, and the estimated symbol occurrence probability becomes less accurate.

The proposed solution: for signals with the same statistical properties, use a shared context across processing units of different sizes rather than a size‑specific context. The specification explains that high‑frequency coefficients in large blocks (16×16 and above) share the same statistics regardless of block size, whereas low‑frequency coefficients carry image‑specific structure and are best kept in dedicated, block‑size‑specific contexts. The result is fewer contexts, a smaller context memory, more frequent probability updates, better probability prediction, and higher coding efficiency. The specification also contemplates: sharing only for blocks larger than a predetermined size; segmenting a large block into small sub‑blocks and reusing the small‑block context; a "shared" table covering multiple large block sizes irrespective of low/high frequency; and signalling in the stream header (slice or picture unit) whether a shared context is used and how contexts are combined.

Plain-language overview of the independent claims

Important caveat: The retrieved full text did not include the issued claim set (the fetched portion ends within the specification). The claim descriptions below are therefore reconstructed from the specification's statement‑of‑invention (steps S401–S405 for coding and S501–S505 for decoding) and the "Definitions" section, which paraphrase the claim 1 subject matter. I do not have authoritative claim language for claims 1, and the precise number and wording of independent claims cannot be confirmed from the material available to me. Treat the following as a subject‑matter summary, not as claim text.

1. Image coding method (specification steps S401–S405) — A method of compression‑coding an image made up of processing units of different sizes, comprising: (a) obtaining the current signals to be coded for each processing unit; (b) binarizing each current signal to produce a binary signal; (c) selecting, for each current signal, a context from among multiple contexts; (d) arithmetic‑coding the binary signal using coded probability information associated with the selected context; and (e) updating that probability information based on the generated binary signal. The point of novelty is in step (c): the context is selected as a shared context that is also used by a signal in a processing unit having a different size from the one containing the current signal.

2. Image decoding method (specification steps S501–S505) — The mirror‑image claim: obtain current signals to be decoded for each processing unit; select a context for each from among multiple contexts (again a shared context used across processing units of different sizes); arithmetic‑decode to generate a binary signal using decoded probability information associated with the selected context; multi‑value‑convert the binary signal to reconstruct the image; and update the decoded probability information based on the binary signal.

3. Apparatus counterparts — The specification states the invention can be embodied as an image coding apparatus (processing units performing the coding steps), an image decoding apparatus (processing units performing the decoding steps), and an image coding and decoding apparatus comprising both. The illustrated coding unit (FIG. 3, unit 100) comprises a binarization unit 101, symbol occurrence probability storage 102, context control unit 103, binary arithmetic encoder 104, and a context block classification control unit 105; the decoding unit (FIG. 13, unit 300) mirrors this with a binary arithmetic decoder 301, storage 302, context control 303, multi‑value conversion 304, and context block classification control 305. Whether these apparatus aspects are claimed as separate independent claims, I cannot confirm.

Dependent‑claim subject matter described in the specification includes: using the shared context when the processing unit size exceeds a predetermined size; using a dedicated (non‑shared) context for low‑frequency components; using a shared context for high‑frequency components above a predetermined frequency; and segmenting a large block into sub‑blocks of a common small size and using the small‑block context for each sub‑block.

Litigation / docket check — CAFC 2026

I searched for the specific number 9,258,558 in connection with Court of Appeals for the Federal Circuit 2026 dockets (and with Sun Patent Trust and USPTO/PTAB records). I found no CAFC 2026 docket, appeal, or PTAB proceeding that identifies US 9,258,558. I want to be explicit that this is a "not found" result rather than confirmation of absence — my searches did not return the CAFC docket database directly, so I cannot rule out a proceeding that simply was not indexed.

What the searches did return are UPC (Europe) proceedings involving Sun Patent Trust, but on different patent numbers — notably EP 3 852 468 and EP 3 407 524 (Sun Patent Trust v. Vivo), EP 2 618 514 (Sun Patent Trust v. Lynk & Co / Zeekr / Lotus / Smart), and EP 2 903 267 / EP 3 200 463 (Sun Patent Trust / Dolby v. Roku). None of these identifies US 9,258,558, and a European counterpart number for US 9,258,558 was not established by my searches. I therefore cannot state that any of those actions involve this US patent.

Uncertainty statement

• Literal abstract text: not captured in the retrieved record; the summary above is a paraphrase of the specification, not the filed abstract.
• Literal claim language: not retrieved; the independent‑claim overview is reconstructed from the specification's step descriptions and may not match the issued claims word‑for‑word, and the count/type of independent claims is unverified.
• CAFC 2026 activity: no record found tying this patent number to a 2026 Federal Circuit docket. No assertion should be drawn that such a proceeding does or does not exist.
• Filing vs. priority date: the 2014‑05‑07 filing date is the filing date of application 14/271,930 itself; the 2011‑01‑12 priority date reflects the earlier family member, consistent with the continuations listed above.
• All identifiers are reported exactly as they appear in the source material; none have been auto‑corrected.

I'll research litigation involving US Patent 9258558 using the sources you specified.

The initial searches matched unrelated patents ending in "558"/"855". Let me refine with the patent's owner (Sun Patent Trust) and exact number formats.

Summary of Findings

No litigation involving U.S. Patent No. 9,258,558 was found in the sources searched.

Despite directed searches against litigation-tracking sources (Unified Patents Portal — including the litigation caselist URL you provided, PACER/court-listener/Justia dockets surfaced through search), the patent number 9,258,558 did not appear in any complaint, docket entry, or case record.

Search methodology

I ran targeted queries combining the exact number in multiple formats — 9258558, 9,258,558, US9258558 — together with litigation-context keywords (litigation, lawsuit, defendant, complaint, infringement) and the patent's owner (Sun Patent Trust / Panasonic Intellectual Property Corporation of America) and its subject matter (image coding / arithmetic coding / CABAC).

What the searches actually returned (and why it is NOT this patent)

Every apparent "hit" was a different patent with a superficially similar number, not US 9,258,558:

I want to be explicit per the operating rule: I did not auto-correct any number. I did not treat the "'855", "'063", or "EP…" references as US 9,258,558, and I am not reporting them as such.

Important caveats

1. Owner context: US 9,258,558 is assigned to Sun Patent Trust (originally Panasonic IP Corp. of America), an entity that is highly active in video-codec (HEVC/H.265) patent litigation and FRAND disputes in the UPC and U.S. It would be plausible for this patent to have been asserted or cross-licensed, but plausibility is not evidence — I found no record of it being asserted.
2. Search limits: My access is via web search, which does not guarantee complete coverage of PACER or every UPC/PTAB record. Absence of results in these searches is not the same as a definitive negative. A confirmatory check directly on Unified Patents Portal (https://portal.unifiedpatents.com/litigation/caselist), PACER, CourtListener/RECAP, Justia Dockets, and the UPC case database using the exact number would be appropriate before relying on this conclusion.
3. Possible non-litigated enforcement: The patent may have been licensed (e.g., via an HEVC patent pool such as Access Advance) or included in portfolios without any filed suit, which would not generate a litigation record.

Bottom line

To the best of my search, there is no known litigation specifically asserting U.S. Patent No. 9,258,558. If you need a definitive answer, I recommend a direct number-level query against PACER and the Unified Patents litigation database, since those are the authoritative sources and my search results for this specific patent number returned nothing on point.

If you can share a candidate case (e.g., a specific Sun Patent Trust matter), I can verify whether a patent with this exact number appears in its asserted-patent list.

I'll verify the canonical "no proceedings" signal against live sources before writing anything up.

No on-point hits so far. Let me run additional targeted queries, including the priority family and patent owner.

Let me check the Unified Patents portal entry and family-level PTAB challenges directly.

I hit my search-call limit while verifying, but I had already confirmed the key point: I could not surface any AIA trial proceeding identifying this patent. Here is the write-up.

---

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal (ODP) structured block for this patent states, verbatim: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." That yields a breakdown of 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials — which means the defensively relevant bottom line is a null, not a verdict: US 9,258,558 has never been through an AIA trial, so there is no Final Written Decision to free-ride on, but equally no § 315(e)(2) estoppel against you and no § 315(b) clock started by anyone else's service.

I did not identify any proceeding number to omit — there is nothing to list.

---

Proceedings — none to report (verification log)

Because the task instructs me not to invent proceeding numbers, I am reporting the negative finding rather than fabricating per-proceeding sections. Here is exactly what I checked and what came back.

Verification performed (2026-09-30)

Important caveat, stated plainly: an ODP "no proceedings" signal plus a null web-search result is evidence of absence, not proof of absence. The two most common ways a real challenge can be invisible in this check are (a) a petition that was filed and denied institution (a denial is a Board decision but is sometimes poorly indexed), and (b) an ex parte reexamination, which is not an AIA trial and would not appear in an "AIA trial proceedings" list at all. Neither the ODP block nor my searches surfaced either. Confirm direct before relying on this.

On the related family — do not conflate

The structured data shows US 9,258,558 is the head of an active continuation chain, all still in force or pending, all bearing the identical title:

• US 9,681,137 (via US 14/951,893)
• US 10,015,494 (via US 15/498,774)
• US 10,638,134 (via US 15/995,654)
• US 11,350,096 (via US 16/822,816)
• US 11,770,536 (via US 17/733,257)
• US 12,149,695 (via US 18/232,045)
• US 2025/0039386 A1 (via US 18/911,811)

None of these shows a PTAB proceeding in the ODP block either. Separately, my search surfaced US 9,961,352 and US 10,237,562 (Lim et al., Sun Patent Trust) — same title, same assignee — but those trace to a different application (US 13/400,793, filed 2012-02-21, PCT/JP2012/001168), not to the 2011-01-12 priority chain of the '558 patent. Do not assume shared claim scope; the identical title is a trap for automated docket matching.

Why no PGR or CBM could exist here anyway

Independent of the search result, the vehicle analysis is dispositive on two of the three AIA trial types:

• PGR: unavailable as of 2026-09-30. The patent granted 2016-02-09; the § 321(c) nine-month PGR window closed on or about 2016-11-09.
• CBM: unavailable. CBM review was limited to patents claiming a financial services data-processing apparatus/method (AIA § 18(d)); this patent is H04N image/arithmetic coding (CPC H04N 19/13, H03M 7/4006/4012/4018 — CABAC), not a covered business method. CBM was also sunset by statute for petitions filed on or after 2020-09-16.
• IPR: the only live AIA trial vehicle, available on §§ 102/103 grounds for patents/printed publications, for the remaining life of the patent (adjusted expiration listed as 2032-02-21).

So if a PTAB proceeding exists that I did not find, it must be an IPR (or a non-AIA ex parte reexam, which is out of scope for this list).

---

Strategic summary

Claim status: 100% UNTESTED. No claim of US 9,258,558 has ever been canceled, confirmed, or construed by the PTAB. I deliberately do not list "surviving claims," because I did not retrieve and verify the issued claim set, and inventing claim-level status from the specification would be exactly the kind of fabrication the task forbids. Treat every claim as unadjudicated for validity purposes. (The specification's framing — a shared-context selection for signals across processing units of different sizes, with dedicated contexts for low-frequency components — corresponds to whatever issued as claim 1, but I have not verified the issued language.)

Estoppel landscape: wide open. With no prior petitioner, there is no § 315(e)(2) estoppel, no privity/RPI spiderweb to untangle (contrast the Greenthread/RPX fact patterns that surfaced in my search), and no risk that a prior challenger "reasonably could have raised" your art. Your full prior-art universe is available: any § 102/§ 103 combination of patents and printed publications, including HEVC/JCT-VC contributions and H.264/AVC-adjacent references. The only statutory gate is § 315(b): if you have been served with a complaint alleging infringement of this patent, the one-year clock is running and that is your hard deadline. A demand letter or license solicitation does not start it.

Pattern signals: none. No repeat petitioner, no defensive aggregator (Unified Patents or RPX) in the chain, no patent-owner appeal of any FWD, no IPR to appeal. This is consistent with the companion litigation finding in this analysis — no litigation asserting US 9,258,558 was located either. The patent is owned by Sun Patent Trust, a highly active HEVC/FRAND enforcer, so the absence of both litigation and PTAB activity is itself a modest signal that this particular patent has been monetized through portfolio licensing (e.g., an HEVC pool or bilateral license) rather than assertion. That could change; Sun Patent Trust's history shows it will litigate when licenses are not taken.

Macro caveat that materially changes the calculus as of today (2026-09-30): the PTAB institution environment has tightened sharply. Per the sources surfaced in this search, institution rates fell to roughly a 38% fiscal-year average with a ~14% rate in Q4 2025 among the first petitions decided under the Director's bifurcated procedure (BSA policy filing, 2026-09-02: https://www.bsa.org/files/policy-filings/09022026bsausptofee.pdf), and 2025 produced a record 607 procedural denials (Unified Patents, 2025 in Review: https://thenaplesroundtable.org/wp-content/uploads/formidable/29/2025-in-Review-Unified-Patents.pdf). The October 2025 NPRM would, if finalized, make denial mandatory where a claim was previously upheld by the USPTO, ITC, or a court, and require petitioners to abandon parallel § 102/103 defenses. For an untested, unlitigated, 2011-priority patent, the "previously upheld" trigger is not yet armed — which is the one thing working in a challenger's favor.

---

Recommended next steps

1. Get a definitive negative from the authoritative source before you build a defense on it. Direct, number-exact queries at:

   • PTAB Center / PTAB E2E (PTAITS) — https://ptacts.uspto.gov/ptacts/ — search 9258558 in the proceedings/applications field.
   • Unified Patents Portal patent page — https://portal.unifiedpatents.com/patents/patent/US-9258558-B2 (I was unable to retrieve and verify the content of this page; treat the URL as a target to check, not as a confirmed record).
   • CourtListener/RECAP — https://www.courtlistener.com/ — for any FWD or CAFC opinion referencing the patent.
   • Also check ex parte reexamination status via USPTO Patent Center, since a reexam would not appear in an AIA-trial list. Note that reexam filings hit an all-time high of 726 in 2025 as challengers routed around IPR denials — it is a genuinely viable alternative route here, carries no § 315(b) time bar and creates no § 315(e) estoppel, but also produces no claim-level estoppel benefit and can be lengthy.

2. If you are a defendant already served with a complaint: calendar the § 315(b) one-year bar immediately and treat it as the only hard PTAB deadline in this matter. There is no PGR or CBM alternative. Given current institution rates, plan for the realistic possibility of denial and preserve your district-court invalidity case in a form that survives (i.e., do not rely on an IPR stay as your primary strategy).

3. If you have only received a demand letter: the clock has not started. Use the time to (a) obtain the full prosecution history of app. 14/271,930 and its parent chain, (b) map the "shared context across different processing-unit sizes" limitation against JCT-VC/HEVC context-modeling contributions and H.264/AVC CABAC context selection, and (c) evaluate whether the commercial product actually practices the shared-context limitation at all — the specification draws a careful line between low-frequency (dedicated per block size) and high-frequency (shared) contexts, which creates a non-infringement argument space distinct from invalidity.

4. Do not cite claim numbers as canceled or sustained. There are none. If opposing counsel or a demand letter asserts that a prior IPR invalidated or upheld specific claims of US 9,258,558, that assertion is contradicted by the ODP record and should be challenged with the verbatim ODP statement quoted above.

Bottom line: zero AIA trials on file. This patent is neither hardened by surviving an IPR nor softened by an invalidation — it is simply unchallenged, and the only PTAB door open to a challenger today is an IPR filed inside the § 315(b) window.

I'll research the assignment record for US 9,258,558, building on the litigation findings already established.

Inventors

All four named inventors list Panasonic Corporation (Osaka, Japan) as their employer at the time of the underlying work — the family's registers show each inventor with the address form "c/o Panasonic Corporation." This matches the parent filing (priority 2011-01-12; Panasonic was still the working assignee then).

Unusual-pattern check: No evidence of inventors departing the original assignee within 12 months of filing, and no inventor-side assignment to a third party. The four are a stable Panasonic coding research group (they recur together across Panasonic's HEVC-era arithmetic-coding filings). The one mobility event in the chain is corporate, not individual: the entity that held the application changed (Panasonic → PIPC America) rather than the inventors leaving. No fire-sale-precursor pattern.

One nuance worth flagging: the priority application was a PCT/JP family filing, and the issued US patent is a continuation (US 14/271,930, filed 2014-05-07, ~3 years after the 2011-01-12 priority). The inventors were therefore named on the parent, and the US continuation issued directly into the already-reassigned chain.

---

Original assignee

Panasonic Intellectual Property Corporation of America is the assignee named in the issued-patent front page (Google Patents lists it as the original assignee of record for US 9,258,558; the "current assignee" field is Sun Patent Trust).

• Primary line of business: IP holding/management subsidiary of Panasonic Corporation — not a product company in its own right. Address of record: 20000 Mariner Avenue, Suite 200, Torrance, CA 90503.
• Did the corporate family ship products embodying the claims? Yes — Panasonic Corporation was a principal H.264/AVC and HEVC contributor and shipped TVs, camcorders, and codec silicon practicing context-adaptive arithmetic coding (CABAC). The patent's own specification (US 9,258,558, Background) expressly builds on the H.264/AVC Standard (ISO/IEC 14496-10), so the claims read on products the Panasonic family actually made.
• Current status: PIPC America is an active Panasonic IP-holding entity; its parent, Panasonic Corporation → Panasonic Holdings Corporation, remains an operating company (no bankruptcy, no dissolution). It did not "shed" this patent via insolvency — it moved it by corporate assignment (below).

---

Assignment timeline

Important honesty note up front: The USPTO Assignment Center reel/frame numbers and the recorded correspondent (attorney/agent) for US 9,258,558 were not retrievable through my searches. I am therefore not inventing reel/frame values. What follows is grounded in (a) the Google Patents legal-events strings on the authoritative patent text you supplied, and (b) a cross-referenced parallel Panasonic record (Irish Patent Register entry for Panasonic app. 10010390.2) that shows the same two corporate entities transferring under dated Deeds of Assignment — strong circumstantial evidence that the same deeds cover this US family, but I flag it as cross-referenced, not directly read off this patent's reel.

Assignment 1 — Panasonic Corporation → Panasonic Intellectual Property Corporation of America

• Executed 2014-05-26 (deed date, cross-referenced) / recorded 2014-06-12 — Reel not retrieved (verify at Assignment Center)
  • Conveyance: Assignment
  • Assignor: Panasonic Corporation (1006, Oaza Kadoma, Kadoma-shi, Osaka 571-8501, JP)
  • Assignee: Panasonic Intellectual Property Corporation of America (20000 Mariner Avenue, Suite 200, Torrance, CA 90503)
  • Correspondent: not retrieved — the Assignment Center page will list the recording attorney; I could not confirm a name, so I do not assert one. No recurrence can be flagged.
  • Context: Internal corporate reorganization — Panasonic swept its patent family into a US IP-holding subsidiary (a routine intra-group consolidation, not a sale to a third party).

Assignment 2 — Panasonic Intellectual Property Corporation of America → Sun Patent Trust

• Executed 2015-12-16 (deed date, cross-referenced) / recorded 2016-03-30 — Reel not retrieved (verify at Assignment Center)
  • Conveyance: Assignment
  • Assignor: Panasonic Intellectual Property Corporation of America
  • Assignee: Sun Patent Trust (450 Lexington Avenue, 38th Floor, New York, NY 10017)
  • Correspondent: not retrieved — no recurrence can be flagged.
  • Context: Transfer to a patent-monetization / licensing entity (portfolio transfer to an asserter). Sun Patent Trust is a non-practicing licensing trust established to hold and license the Panasonic-origin portfolio.

There are no further recorded assignments after 2016-03-30. Subsequent Google Patents "priority" entries (US 14/951,893; 15/498,774; 15/995,654; 16/822,816; 17/733,257; 18/232,045; 18/911,811) are continuation-family filings, not ownership changes — the owner after Assignment 2 remains Sun Patent Trust. Do not misread those as transfers.

---

Timeline diagram

timeline
    title Ownership of US 9258558
    2011 : Priority application filed by Panasonic
    2014 : US continuation filed
         : Deed to Panasonic IP Corp of America
    2015 : Deed from Panasonic IP to Sun Patent Trust
    2016 : Patent US 9258558 issued
         : Sun Patent Trust recording posted

---

NPE / troll-pattern signals

---

Verdict

NPE — high confidence.

The chain ends at Sun Patent Trust, a non-practicing licensing/assertion entity — the Assignment 2 link (deed 2015-12-16; recorded 2016-03-30) transferring the patent out of Panasonic IP Corp of America to a licensing trust at 450 Lexington Avenue, 38th Floor, New York satisfies Signal 1 (transfer to a licensing-only entity) — and Sun Patent Trust is an independently documented repeat codec plaintiff satisfying Signal 2. Two strong signals, no defensive-aggregator termination. Two important qualifiers: (i) this is a portfolio NPE (organized SEP/codec licensing), not an opportunistic shell-LLC troll, and (ii) the prior litigation pass found no assertion of this specific patent, so it is best characterized as a licensed/enforcement-ready portfolio asset rather than a proven litigated one. The reel/frame numbers and correspondents should be confirmed directly, since I could not retrieve them.

Verify at: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search "9258558"; the alternate index at https://assignment.uspto.gov/patent/index.html surfaces the same records).

I'll research the prior art citations for US Patent 9,258,558. Let me start with targeted searches.

Let me look for the specific patent citations listed on the face of US 9,258,558.

Let me search for the specific prior-art citations on the face of this patent.

Prior-Art Analysis for U.S. Patent No. 9,258,558

Important sourcing note (read first)

I must be explicit about a limitation, per the operating rule against fabrication:

I was not able to retrieve the front-page "References Cited / Patent Citations" list (the Form 892 examiner citations) for US 9,258,558 from the sources reached in my searches. The authoritative full text provided for this patent is truncated in the fetched copy before the "References Cited" table, and my targeted searches for the citation table returned the patent's description and family/similar-document tables rather than the examiner's citation list. I therefore cannot honestly enumerate the individual examiner-cited patent references with their § 102 mappings, and I will not invent them.

What I can do reliably is (a) list the references the patent itself cites in its own text (grounded in the authoritative full text), (b) list the family members and their dates (grounded in the Google Patents family table), and (c) give a candidate prior-art landscape with explicit confidence labels.

---

1. The patent at issue (identity confirmed, not auto-corrected)

Source: https://patents.google.com/patent/US9258558/en (authoritative text provided). Cited by this patent's own "Prior art keywords": context, coded, signal, image, unit.

Because the priority date is 2011-01-12, prior art must predate that date to qualify under § 102(a)/(b) (with the caveat that § 102(e)/§ 102(a)(2) references have their own effective-date rules).

---

2. References cited within the patent's own text (grounded, verifiable)

These are the technical references the applicants cite in the Background section (non-patent literature / standards), verbatim from the provided full text:

Note: These are applicant-authored background citations, not necessarily examiner § 102 rejections. The patent text expressly frames NPL-1/NPL-2 as "conventional art" that the invention improves on (the patent discusses a conventional arithmetic coding unit 10 in FIGS. 1–2 with binarization unit 11, symbol-occurrence-probability storage 12, context control 13, and binary arithmetic encoder 14).

---

3. Examiner "Patent Citations" (Form 892) — not retrieved

I could not obtain the front-page list of examiner-cited patents/publications for US 9,258,558. Recommendation: pull the citation list directly from one of these authoritative sources using the exact number:

• USPTO Patent Public Search / PatentCenter for US 9,258,558 → "References Cited."
• Google Patents → US9258558B2 → "Patent Citations" and "Non-Patent Citations" tables.
• USPTO / EPO file wrapper (Global Dossier) for application 14/271,930 to see the actual examiner rejections (Form 892 and Office Actions).

I am flagging this rather than guessing, because the instruction to map each reference to specific claims under § 102 requires the actual list.

---

4. Candidate prior art that could be relevant (clearly labeled as candidates, not confirmed citations)

The following are well-known references in this exact field (shared-context CABAC across transform block sizes). I identify them because the patent's claims are directed to that concept — but I have not confirmed which of these appear on US 9,258,558's face. Treat as leads for verification.

Independent claim 1 (image coding) requires, in substance: obtaining current signals to be coded of each of multiple processing units having mutually different sizes; binarizing; selecting a context as a shared context for a signal included in one of the processing units and having a size different from the size of the processing unit including the current signal; arithmetic coding using coded probability information for the selected context; and updating that probability information. The independent decoding claim (in the patent text, numbered S501–S505) mirrors this.

---

5. Family members (not prior art — for completeness / double-patenting context)

From the Google Patents family table, all sharing the 2011-01-12 priority:

• US 2012/0177300 A1
• US 8,755,620 B2 (granted 2014-06-17) — parent/sibling "…for performing arithmetic coding and/or arithmetic decoding"
• US 9,258,558 B2 (this patent)
• US 9,681,137 B2
• US 10,015,494 B2
• US 10,638,134 B2
• US 11,350,096 B2
• US 11,770,536 B2
• US 12,149,695 B2

These are continuations of the same disclosure and therefore are not prior art to one another; they are relevant only for obviousness-type double patenting and continuation practice, not § 102.

---

6. Bottom line

• Verified identity: US 9,258,558 B2, priority 2011-01-12, Sun Patent Trust (orig. Panasonic), directed to shared-context CABAC across processing units of different sizes. Exact-number match confirmed; no auto-correction applied.
• Applicant-cited NPL (grounded in the text): ISO/IEC 14496‑10 (H.264/AVC) and Wiegand et al., IEEE TCSVT, July 2003, pp. 560–576.
• Examiner "Patent Citations" list: NOT retrieved — I will not fabricate it. To complete a true per-reference § 102 mapping, the Form 892 list and the Office Actions for application 14/271,930 must be pulled from USPTO Patent Public Search / PatentCenter / Global Dossier or the Google Patents "Patent Citations" table for US9258558B2.
• Preliminary § 102 read: the strongest conventional reference (H.264/CABAC, NPL‑1) appears to teach distinct contexts per block size and thus likely does not anticipate claim 1's cross-size shared context; it is better characterized as a § 103 base. The GE Video Compression significance-map family (priority 2010‑04‑13) is the most plausible pre-priority field-relevant candidate worth checking against the face of '558.

If you can supply the Form 892 / "Patent Citations" table for US 9,258,558 (or grant access to the file wrapper), I will produce the full per-reference citation format, dates, descriptions, and claim-specific § 102 mappings you asked for.

I'll research the prior art associated with US 9,258,558 before building the § 103 analysis.

Let me try to retrieve the actual "References Cited" list from the patent record.

I have the patent's own text but need its cited prior art. Let me pursue the family/ISR records and known HEVC-era context-modeling art.

Obviousness Analysis — U.S. Patent No. 9,258,558 B2 (35 U.S.C. § 103)

Grounding caveat (important — read first)

You asked me to "use the results from the Prior Art section of this page." I was not able to retrieve a discrete "Prior Art" section for this patent. The fetched Google Patents record for US 9,258,558 ends inside the specification and does not include either (a) the face-of-patent "References Cited" list (the (56) field) or (b) the "Cited By / Similar Documents" panel. My targeted searches for the patent's citation list returned only unrelated patents that happened to share digits (e.g., a '855 brewing patent, US 10,237,562, US 10,237,553, US 10,616,579), which per the operating rules I do not treat as belonging to this record.

I therefore ground the analysis below in two evidenced categories only:

1. References the patent text itself cites (expressly identified in the fetched specification):

   • ISO/IEC 14496-10, "MPEG-4 Part 10 Advanced Video Coding" (i.e., the H.264/AVC standard), cited as the state of the art.
   • Thomas Wiegand et al., "Overview of the H.264/AVC Video Coding Standard," IEEE Transactions on Circuits and Systems for Video Technology, July 2003, pp. 560–576.
   • The H.264 CABAC context machinery is described in the patent's own FIGS. 1–2 and FIG. 4 as conventional (indices ctxIdx, pStateIdx, valMPS).

2. HEVC/H.264-era context-coding references that surfaced in the searches (I flag confidence per item below; each should be verified against the actual file history before being relied upon in a petition).

Any statement I make about a specific reference's content is at the level of general knowledge about that reference unless I say otherwise. My reconstructed claim 1 (from the specification's S401–S405 statement of invention) is not the issued claim text — I do not have the issued claims — so this is a subject‑matter‑level § 103 analysis, not a claim‑by‑claim chart.

---

1. The claim elements that must be met

Reconstructed independent claim (coding method), from the specification's statement of invention:

The entire § 103 case turns on element (g) and on the dependent-claim refinements of where sharing is applied (large blocks; high-frequency coefficients) versus where it is not (low-frequency coefficients).

This is a favourable posture for an obviousness attack: elements (b)–(f) are the patentee's own admitted prior art, and element (a) is conceded as conventional. Only a single, narrowly framed difference needs to be supplied or rendered obvious.

---

2. Primary references and what each teaches

R1 — ISO/IEC 14496-10 (H.264/AVC) + Wiegand et al. 2003 (both cited in the patent)

Published 2003 and March 2010 respectively; more than one year before the 2011‑01‑12 priority date. § 102(b)/§ 102(a) art.

Teaches, per the patent's own description of it (FIGS. 1, 2, 4, 5A):

• Binarization of coefficients (SignificantFlag), context selection keyed to block size AND coefficient position/surrounding condition, arithmetic coding with PE, and probability updating.
• Context tables keyed by block size — Table 1 for 4×4 ("block size A"), Table 2 for 8×8 ("block size B") — with the specification noting that "the values 0, 1, and 2 of the contexts ctxIdx for use in Table 1 are not used in Table 2."
• Crucially, H.264 is a hierarchical transform scheme in which an 8×8 transform block is built from 4×4 sub-blocks in High Profile — i.e., the art already contemplated the same coefficient statistics being handled at more than one block granularity.

R1 supplies elements (a)–(f) and, most importantly, supplies the problem statement: context count grows with block size and condition, so each context is updated less frequently and its probability estimate degrades. The patent admits this framing verbatim ("An increase in the number of block sizes significantly increases the number of contexts… the update frequency of the symbol occurrence probability PE may be further decreased").

R2 — CABAC context-modeling references of the same family

• Marpe et al., "Context-Based Adaptive Binary Arithmetic Coding in the H.264/AVC Video Compression Standard," IEEE TCSVT 13(7), July 2003. (High confidence this exists and its content.) The canonical CABAC paper; establishes that contexts are probability models that can be merged/split, that ctxIdx allocation is a design variable trading memory against model precision, and that context dilution (too many models × too few updates) degrades coding efficiency.
• Karczewicz-family context/coefficient-coding patents (e.g., US 2008/0260027 A1; US 8,488,672 B2; US 8,937,998 B2 — Qualcomm) (moderate confidence; these appeared in the citation list of a related Sun Patent Trust patent, US 10,616,579, not confirmed as cited in '558). Generally directed to context modeling and grouping for transform-coefficient coding.
• WO 2010/021699 A1 (Thomson Licensing), "Context-based Adaptive Binary Arithmetic Coding (CABAC) Video Stream Compliance" (moderate confidence; surfaced in the citation list of related Sun Patent Trust patent US 10,903,848).
• US 2011/0148674 A1 and US 2006/0109149 A1 (Xylene Holding SA), digital-signal arithmetic coding/decoding with contexts (moderate confidence, same caveat).

These collectively establish the recognised design space: the number of contexts is a tunable, and practitioners routinely consolidate contexts that share statistics to (i) cut context-memory and (ii) increase per-context update counts.

R3 — HEVC/JCT‑VC coefficient-coding work contemporaneous with the priority date

The patent's priority date (2011‑01‑12) sits at the outset of JCT‑VC. The HEVC design ultimately adopted a unified coefficient-coding context set applied across transform sizes up to 32×32, precisely the "share the context across block sizes" concept of element (g). (High confidence as to the general fact; specific JCT‑VC contribution numbers must be pinned down from the JCT‑VC document archive before being cited — I did not retrieve them here.) If the relevant JCT‑VC contributions predate 2011‑01‑12, they are § 102(a)/(b) printed publications and are the single strongest § 103 reference.

---

3. The combination and the motivation to combine (KSR)

Proposed ground: R1 (H.264/AVC + Wiegand) in view of R2 (CABAC context-modeling art) and/or R3 (HEVC/JCT‑VC coefficient coding).

Why a POSA would have combined them

1. The problem is stated in R1 itself. Context dilution with increasing block sizes is the express problem the patent attributes to the prior art. Where the prior art frames the problem, the solution is presumptively obvious. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 421 (2007).

2. Finite number of identified, predictable solutions. Given a set of contexts indexed by (block size × coefficient position/surrounding condition), a POSA has a small, closed menu of options for reducing context count: merge contexts across block sizes, merge across positions/conditions, or quantise the condition. Sharing a context across block sizes is the first and most natural of these — one of "a finite number of identified, predictable solutions." Id. at 421.

3. Predictable, predictable-result benefit. The two benefits the patent claims — (i) smaller context memory and (ii) more frequent probability updates improving prediction accuracy — are the arithme­tically necessary consequence of merging contexts and increasing per-context sample counts. No unpredictable mechanism is invoked.

4. The statistical premise is admitted. The specification concedes that "the high frequency components in the blocks having a 16×16 block size or larger have the same statistical properties of the image, and thus the same context is applicable thereto when the conditions (surrounding conditions) are the same even if the block sizes are different." That is an admission that sharing high-frequency contexts across large block sizes is a consequence of known statistics, not an inventive insight.

5. Design incentive / market pressure. Video coding is a standardisation-driven field organised around rate-distortion efficiency and decoder memory. R1 establishes that the coefficient context tables are the dominant entropy-coder memory consumer; the incentive to shrink them while keeping probability estimates fresh is explicit in the standard-development literature (R2/R3).

6. Reasonable expectation of success. Context merging was already practised to some degree in the H.264 context tables (the specification notes contexts ctxIds 2 and ctxIds 3 are already shared between conditions in Table 1), showing that the POSA already regarded contexts as mergeable when statistics coincide.

---

4. Claim-by-claim application

Independent claim 1 (coding) and its decoding mirror

R1 discloses (a)–(f). R2/R3 disclose or render obvious (g): selecting a context that is also used by a signal in a differently-sized processing unit. Motivation: R1's own stated context-dilution problem + KSR (finite solutions, predictable result). Conclusion: obvious.

Dependent: shared context when processing-unit size > predetermined size

R1 discloses the notion of a block-size threshold (the H.264 4×4 vs 8×8 tables); applying the sharing regime only where the statistical benefit is greatest (large blocks, which the patent admits are rarely used, i.e., exactly where context statistics are starved) is a routine optimisation with predictable effect. Obvious.

Dependent: dedicated (non-shared) context for low-frequency / DC-region coefficients

R1 already assigns distinct contexts by coefficient position, and the H.264 DC/low-frequency contexts carry content-specific structure. Preserving dedicated low-frequency contexts while sharing high-frequency ones is the ordinary engineering choice of sharing only where statistics coincide. Obvious.

Dependent: shared context for high frequencies above a predetermined frequency

Direct corollary of the above; follows from the admitted statistical equivalence. Obvious.

Dependent: segmenting a large block into sub-blocks of common small size and using the small-block context

This is conventional hierarchical transform practice in H.264/AVC High Profile (8×8 transform decomposed into 4×4 sub-blocks) and in HEVC's TU tree. Reusing the small-block context for the sub-blocks is the natural application of a known block-partitioning scheme. Obvious.

Dependent: recording in the stream header (slice/picture unit) whether a shared context is used / how contexts are combined

R1 discloses exactly this signalling paradigm for codec configuration (SPS/PPS/slice header). Adding a flag is a predictable use of a known mechanism; no new technical effect. KSR at 417 (familiar elements combined according to known methods). Obvious.

Apparatus / coding-and-decoding apparatus claims

R1 (Wiegand, FIG. 2) discloses coding/decoding apparatus structure; the patent's FIG. 3 / FIG. 13 units (binarization 101, storage 102, context control 103, arithmetic encoder 104, context block classification control 105) are conventional blocks plus the classification unit that implements element (g). Obvious for the same reasons.

Program / LSI / recording-medium claims

In re Beauregard / In re Kollar‑type considerations; routine implementation of an obvious method on a known computer/LSI. Obvious.

---

5. Counter‑arguments a patent owner would raise, and my assessment

No nexus between any commercial success and the claimed feature has been shown in the material available to me.

---

6. Conclusion and confidence

Subject-matter conclusion: On the evidence I can ground, the claimed subject matter of US 9,258,558 (a coding/decoding method in which contexts are shared across processing units of different sizes, optionally only above a size threshold and/or only for high-frequency coefficients, optionally via sub-block reuse, optionally signalled in a header) is likely obvious under § 103 as H.264/AVC CABAC (R1, the patent's own admitted prior art) in view of the CABAC context-modeling literature (R2) and/or contemporaneous HEVC/JCT‑VC coefficient-coding work (R3), with a motivation rooted in the context-dilution problem that R1 itself states and in the admitted statistical equivalence of high-frequency coefficients across large block sizes.

Confidence levels:

• High that elements (b)–(f) and the "mutually different sizes" framing are prior art (the patent admits them).
• Moderate-to-high that element (g) is obvious given R1's stated problem; the strength turns on the R3 / HEVC evidence of unified coefficient-context sets across transform sizes before 2011‑01‑12.
• Low that I have identified the actual references the examiner cited or that a petitioner would use — I could not retrieve this patent's (56) "References Cited" list, and the specific candidates in R2/R3 above were surfaced from related Sun Patent Trust patents' citation lists and general art knowledge, not from '558's own face.
• Unverified: the issued claim text. My element-by-element mapping uses the specification's S401–S405 statement of invention as a proxy; claims 1's actual language must be obtained and mapped before any § 103 conclusion is relied upon.

Recommended next steps before filing or relying on any invalidity contention:

1. Pull the actual issued claims and the file history (USPTO PatentCenter / Global Dossier for 14/271,930) to see what the examiner cited and what the applicant argued.
2. Retrieve the face-cited (56) references from the patent PDF (patentimages for US 9,258,558) — I could not obtain the reference list in this session.
3. Obtain the JCT‑VC contributions on coefficient-context unification with dates before 2011‑01‑12, and pin down exact document numbers (e.g., the CE11/coefficient-coding documents) before citing them. HEVC final text post-dates the priority date and is therefore not itself prior art; only the pre‑2011‑01‑12 contributions qualify.
4. Obtain the international search report for the WO 2013/101067 counterpart, which would list the art the ISA considered.

All patent numbers and identifiers above are reported exactly as surfaced in the sources; none have been auto‑corrected.