US 11706276

I'll search for authoritative information on this specific patent number and check both USPTO records and any CAFC litigation.

Let me check for litigation history and any USPTO proceedings involving this specific patent.

Let me do one more targeted check on whether this specific patent number appears in any litigation docket or assertion.

US Patent 11,706,276 (US11706276B2) — Analyst Summary

Important caveat on scope of my search: Your instruction was to search USPTO and CAFC 2026 dockets for 11706276 specifically. I searched and found no CAFC 2026 docket or opinion tied to patent number 11,706,276, and no evidence that 11,706,276 itself has been asserted in any located litigation. What the dockets show is family-member activity (discussed below). I flag this explicitly rather than inferring.

Bibliographic data (from the authoritative patent record)

Continuation chain: 11/970,493 (US 7,886,069) → 12/982,413 (US 8,977,768) → 14/632,670 (US 9,794,318) → 15/682,379 (US 10,574,716) → 16/136,149 (US 10,412,141) → 16/565,375 (US 11,050,808) → 17/326,056 (this patent). Child: 18/352,966 (US 12,267,380). Note: the earlier continuations carried the title "Video Distribution System Including Progressive Playback"; the present patent and its immediate parents use the "seeking within multimedia content" title.

Abstract (verbatim)

"A receiver driven approach for playback of remote content is described. One embodiment includes obtaining information concerning the content of the media file from the remote server, identifying a starting location within the media sequence, identifying byte ranges of the media file corresponding to media required to play the media sequence from the starting location, requesting the byte ranges required to play the media sequence from the starting location, buffering received bytes of information pending commencement of playback, playing back the buffered bytes of information, receiving a user instruction, identifying byte ranges of the media file corresponding to media required to play the media sequence in accordance with the user instruction, flushing previous byte range requests, and requesting the byte ranges required to play the media in accordance with the user instruction."

Plain-language overview of the independent claims

Claim 1 — Method (client-side seeking with request flushing)
A playback device (processor, memory, network connection) runs a client split into three parts: a file parser, a download manager, and a playback engine. The method:

1. File parser gets an index to a selected media sequence inside a media file.
2. Playback engine figures out what media is needed to play from a starting location.
3. File parser converts that need into byte range(s) and hands them to the download manager.
4. Download manager requests those byte ranges over the network, receives the bytes, and buffers them; it maintains a mask of what has been buffered.
5. Playback engine plays the buffered media.
6. User issues a seek instruction via a UI.
7. Using the mask, the device determines which required portions are not yet buffered.
8. A flush request goes to the download manager, which flushes the prior byte-range request by closing the connection with the remote server.
9. Download manager requests the unbuffered portions from the remote server.

Core inventive hook: mask-based byte-range seeking combined with flushing/cancelling the stale request by tearing down the server connection.

Claim 9 — Playback device (processor + memory + network connection) — the apparatus counterpart of claim 1, reciting the same steps carried out by a stored "playback client."

Claim 17 — Playback device (queue-and-object architecture)
Similar to claim 1, but adds: instantiating a remote file object (handles server communications and keeps a queue of requested portions) and a partial file object (handles storage and establishes a temporary data path for a data file). It maintains the queue and flushes any previously requested portion once it is no longer required, where flushing includes closing the connection associated with the flushed request; then, based on the mask, identifies unbuffered portions needed per the seek instruction and requests them.

Representative dependents (mirrored across all three families: 2–8, 10–16, 18–23):

• Flushing = flushing a queue of requested portions (cl. 2/10).
• Storing a file map containing the mask plus a data file of downloaded portions (cl. 3/11/19).
• Outputting the assembled data file when the file is fully downloaded (cl. 4/12/20).
• Instantiation of remote-file and partial-file objects (cl. 5/13).
• Remote server is a standard HTTP server (cl. 6/14/21).
• Media stored as a single file in a chunked container format (cl. 7/15/22).
• Each portion = a chunk, with a maintained list of index entries for requested chunks (cl. 8/16/23).

Prosecution / family context

• The disclosure describes a receiver-driven (client-driven) progressive-playback architecture explicitly contrasted with server-driven approaches (referencing U.S. Ser. Nos. 11/323,044; 11/323,062; 11/327,543; 11/322,604) and with Samba-based remote-file pre-caching, which the specification says is inadequate for trick-play (fast-forward, rewind, scene skipping) because frames to be delivered can be spaced far apart and require non-sequential access.
• Container formats contemplated: AVI 1.0, OpenDML/AVI 2.0, formats per U.S. Ser. Nos. 11/016,184 and 11/198,142, MP4 (MPEG-4 Part 15), and Matroska.
• Transport: HTTP 1.1 byte-range requests (and BitTorrent as an alternative).
• Implementation details: block size of 128 bytes in the status-file mask; sparse data file to avoid allocation latency; up to ~5 connections; earliest-deadline-first chunk selection; trick-play by requesting key frames at ~0.1× spacing (≈10 key frames/sec).
• Family: 9 family applications (id 39595207). Foreign counterparts include WO2008086313A1, EP4213033B1, JP5559544B2, CN101636726B, ES2875428T3. The Google Patents record carries a Darts-ip "First worldwide family litigation filed" flag for the family (not per-patent), which is why litigation appears in the family even for this continuation.

Litigation status (what I could and could not confirm)

Not confirmed: No CAFC 2026 appeal, no PTAB IPR, and no district-court complaint asserting 11,706,276 specifically surfaced in my searches. I therefore cannot state that this exact patent is or has been in suit.

What I did find — assertions of a sibling patent with the identical title and inventor (US 10,412,141, the " '141 patent"):

• DivX, LLC v. Samsung Electronics Co., Ltd. et al., No. 2:20-cv-00301 (E.D. Tex., Marshall Div.) — the '141 patent asserted, identified as having the same title and inventor (Roland Osborne), expiring Jan 7, 2028, issued from Ser. No. 16/136,149. (Source: complaint PDF via Docket Alarm.)
• DivX, LLC v. Hulu, LLC, No. 2:21-cv-01615 (C.D. Cal.) ("Hulu II") — the '141 patent asserted against Hulu's trick play and adaptive-bitrate functionality; accused standards MPEG-DASH and H.264.
• ITC Investigation into "Certain Video Processing Devices, Components Thereof, and Digital Smart Televisions Containing the Same" (DivX claim-construction brief, Jan 19, 2021).
• Related EP opposition/appeal: EPO Board of Appeal T 1021/23 (decision Feb 14, 2025) concerning EP 3 467 666, a divisional of the WO 2008/086313 family (parent of the 08705745.1 application), opponents Netflix International B.V. and Amazon EU S.à.r.l.

2026 CAFC activity involving DivX — but a different patent: Netflix, Inc. v. DivX, LLC, No. 2024-1541, opinion Feb 13, 2026 — claim construction of "within the requested portions of the selected stream of protected video" in US 10,225,588 (IPR2020-00558); the court reversed the Board's construction, vacated, and remanded. This is not 11,706,276 and I list it only to prevent conflation.

DivX v. Netflix district court final judgment, May 7, 2026 (C.D. Cal. 2:19-cv-01602) addressed US 7,295,673; 8,139,651; 8,472,792; and 10,212,486 — again not this patent.

Ownership note

The Google Patents record lists DivX, LLC as original and current assignee, with a 2021-08-18 chain-of-title flurry involving DivX, Inc., DivX, LLC, DivX CF Holdings LLC, and Sonic IP, Inc. Litigation filings describe the current DivX, LLC as a 2017 Fortress Investment Group-created vehicle that acquired the patent assets from NeuLion's subsidiary Sonic IP, Inc. (Feb 2018 assignment), and DivX, LLC is characterized as a licensing/litigation entity. Treat "current assignee" accordingly as the recorded owner, not the original innovator entity.

Confidence / uncertainty statement

• High confidence on title, inventor, application number, filing date, issue date, priority date, abstract, claim structure, and the three independent claims — these come from the authoritative full patent text (Google Patents, fetched 2026-09-26).
• Moderate confidence on the precise current chain of title, because Google's own notice states the assignee listing may be inaccurate and is not a legal conclusion.
• Low/uncertain on any CAFC 2026 involvement of 11,706,276 itself — I found none. If a CAFC docket exists for this number, it did not surface in my searches, and I will not assert one. Verifying would require a direct CAFC docket-number or party-name query rather than a patent-number query.

I'll search for litigation involving US patent 11706276 across patent litigation tracking sources.

The searches surfaced DivX litigation but not clearly tied to the '276 patent. Let me dig deeper with targeted queries.

Bottom line

Based on the sources I was able to search (Google Patents/legal-status data, CourtListener/RECAP, Unified Patents' litigation and insights pages, Federal Circuit opinions, PTAB filings, and third-party litigation trackers), I found no litigation in which U.S. Patent No. 11,706,276 ("the '276 patent") itself is named as a patent-in-suit. I cannot identify a plaintiff/defendant pair, jurisdiction, case number, filing date, or outcome for any case asserting the '276 patent, because no such case appears in the sources retrieved.

I want to be explicit about the limits of this conclusion rather than overstate it: I could not run a query directly against a comprehensive, subscription litigation database (e.g., Docket Navigator, Lex Machina) or a full PACER docket search on the '276 number, and Google Patents' "family has litigation" flag is a family-level flag, not proof that the '276 patent specifically was asserted. So the correct statement is: no litigation asserting the '276 patent is known to me from the available results.

Important context: the '276 patent is a continuation in a heavily-litigated family

The '276 patent (appl. No. 17/326,056, filed 2021‑05‑20, granted 2023‑07‑18, assignee DivX LLC, priority date 2007‑01‑05) sits in a chain of continuations. Per the patent's own cross-reference section, that chain is:

US 7,886,069 → US 8,977,768 → US 9,794,318 → US 10,574,716 → US 10,412,141 → US 11,050,808 → US 11,706,276 → US 12,267,380 → US 2025/0159033 A1.

Several of the sibling/parent patents in this family — notably the '141 patent (US 10,412,141) and the '808 patent (US 11,050,808) — have been asserted. The '276 patent's claims closely mirror the family's subject matter (client-driven progressive playback with byte-range requests and flushing on seek). Litigation involving the family includes:

Key corroborating source: Unified Patents' own write-up states that the '716 patent (US 10,574,716, another direct family member) "has not been asserted in litigation, however, it is related to U.S. Patent 10,412,141 which was asserted against Realtek, TCL, Samsung, Hulu, and Amazon." That is the same pattern I observe for '276 — the family has litigation, but the specific continuation is not shown as asserted.

Post-grant proceedings (not litigation, but relevant)

For completeness, the family has drawn PTAB/reexamination activity, none of it directed at the '276 patent:

• IPR2020‑00558 — Netflix, Inc. v. DivX, LLC (US 10,225,588); Fed. Cir. Nos. 2022‑1083 and 2024‑1541 (remand and further appeal).
• IPR2021‑01476 — Unified Patents, LLC v. DivX, LLC (US 10,326,987); Fed. Cir. No. 2023‑1699, affirmed June 24, 2025.
• Ex parte reexamination of US 10,574,716 requested by Unified Patents (filed July 20, 2026; granted Sept. 18, 2026).

I found no IPR, PGR, or reexamination record naming the '276 patent.

Caveats / recommended verification

• The '276 patent's Google Patents page shows a "Family has litigation" indicator (Darts‑IP family ID 39595207). That is a family-level flag and does not establish that the '276 patent was itself asserted.
• To definitively confirm "no litigation," I would recommend running the exact string "11,706,276" and "11706276" against Docket Navigator, Lex Machina, and a full PACER/RECAP search, and checking USPTO Patent Center's "Litigation" tab for the patent. My searches surfaced family-member cases and PTAB matters but no complaint naming '276.

In short: No litigation specifically involving US 11,706,276 is known from the available sources. The apparent litigation connection is to other patents in the same continuation family — principally US 10,412,141 and US 11,050,808 — not to the '276 patent itself.

I'll verify the ODP default with targeted web searches before writing up.

Let me confirm with more targeted queries, including the family's earlier members and the patent's Google Patents PTAB tab.

Let me check the immediate parent (10,412,141) and any reexam on this patent, which Unified's portal may track.

Proceedings overview

Total AIA trial proceedings on US 11,706,276: zero. As of the most recent ODP ingest, the USPTO Open Data Portal returns no IPR, PGR, or CBM proceeding naming this patent — no petitions instituted, none denied, none settled, none terminated, and therefore no claims canceled and no claims sustained at the Board. Bottom line for a defendant: this is a clean, un-attacked patent, so there is no § 315(e) estoppel on the books against anyone, all 23 claims (independents 1, 9, and 17 plus 20 dependents) are live and untested, and an AIA-based invalidity strategy is fully available to you — subject to the § 315(b) one-year clock and the fact that the patent expires 2028-01-07, which sharply compresses the value of any challenge.

⚠️ Confidence note: I searched for proceedings on the '276 patent by number, by title, and via DivX-wide PTAB queries. Every hit was a DivX IPR on a different patent (the '987, '588, '792, '651, '749, '486, '297, '141, '716 family). I found nothing on '276. A very recently filed petition not yet indexed in ODP would not appear — treat the absence as strong but not apodictic.

No proceedings to report

Because there are no AIA trials on this patent, the per-proceeding template yields nothing. Rather than fabricate entries, here is the related-proceedings intelligence that matters to a defendant — with the express caveat that none of these are proceedings on US 11,706,276.

Why the '716 reexam is the single most actionable item for you. US 10,574,716 ("Video distribution system including progressive playback") sits in the same continuation chain as '276 — 11/970,493 → 12/982,413 → 14/632,670 → 15/682,379 ('716) → 16/136,149 ('141) → 16/565,375 ('808) → 17/326,056 ('276) — and shares the progressive-playback written description. Unified's art there was good enough to clear the CRU's SNQ threshold against the shared specification. That art is a ready-made starting point for a '276 challenge, though the '276 claims (file parser / download manager / playback engine split, mask maintenance, flush-by-closing-connection) will need independent mapping. Note this also means Unified is already engaged on this family, but as a reexam petitioner, not an IPR petitioner — so Unified incurs no § 315(e)(2) IPR estoppel on '276.

Assertion context (for the § 315(b) clock). The '276 patent itself does not appear in the ITC/Delaware campaigns I reviewed. Its direct parent, '141, was asserted in ITC Inv. No. 337-TA-1222 against Samsung, LG, MediaTek, Realtek, and TCL, plus companion Delaware suits (FR notice); that campaign resolved by settlement (Samsung/LG July 2021; TCL April 2022) and Realtek withdrawal. DivX is characterized in the Unified reporting as an NPE / Fortress Investment Group entity. I could not confirm whether '276 has been asserted anywhere — treat any assertion date as your trigger to docket the one-year bar.

Strategic summary

Claim status: 100% untested. No claim of US 11,706,276 has ever been canceled, confirmed, or even reviewed by the PTAB. Independents 1, 9, and 17 and all 20 dependents stand as issued. Contrast this with the family's other members: the '987 patent lost its only two independent claims to Unified at IPR2021-01476, and the '716 parent is now under a granted ex parte reexam. The '276 patent is the least-hardened-by-litigation and least-attacked member of a family that has otherwise been picked apart. There is no certificate-of-cancellation risk to cite and no FWD to quote.

Estoppel landscape: nothing binds anybody. Because no IPR was ever instituted against '276, § 315(e)(2) bars no petitioner or privy from raising any ground. You can assert § 102 and § 103 combinations — including art used during original prosecution, art from the '716 reexam, and art harvested from the sibling IPRs (Biderman, Gigliotti, Sood, Myers, Casalena, Nilsson, Ma; Zetts; Vehviläinen/Kadono) — provided you map it to these claims. Two gates remain: (1) § 315(b)'s one-year-from-service bar, and (2) § 315(e)(1) estoppel that will attach to you only if you institute and reach FWD. PGR is unavailable (the 9-month post-grant window closed 2024-04-18), CBM is unavailable (AIA § 18 sunset), leaving IPR and ex parte reexam as your only AIA-era routes. Note also that the § 325(d) risk is elevated: this is a heavily-prosecuted family and examiners have seen a lot of this art, so a petition must show why the Office erred, not merely re-present references.

Pattern signals. DivX is a serial PTAB defendant: it has litigated IPRs on numerous family patents against Unified Patents (a defensive aggregator), Netflix, and Hulu, and it appeals aggressively — it took the '588 and '792 losses to the Federal Circuit and won both claim-construction/remand rulings. Unified's current '716 reexam shows the aggregator has now pivoted from IPR to reexam against this family, likely to avoid the § 315(e) estoppel problem DivX itself flagged in its 2020 PTO comments (DivX submission) and to escape Fintiv-style discretion. The strategic read: the family is under sustained attack, but '276 specifically is untouched, and the closest live threat (the '716 reexam) runs against a sibling with the same specification.

Recommended next steps

1. Confirm the zero for yourself before relying on it. Pull the patent's papers in PTAB E2E (Patent Trial and Appeal Board End-to-End) and the Google Patents PTAB tab. I found nothing, but a petition filed in the last few weeks may not be indexed. There is no FWD, no institution decision, and no termination to link to for this patent.
2. If DivX has served you with a complaint asserting '276, count the days. § 315(b) gives you exactly one year from service to petition for IPR. Nothing else in this file will preserve that right.
3. Mine the '716 reexam file first. Unified's SNQ-granted request (SN 90/016,490, granted 2026-09-18) is public at Unified's portal. The art that survived the CRU's SNQ screen against the shared '276/'716 specification is the highest-yield starting point for a § 103 petition, and — unlike an IPR — it does not build any estoppel for you.
4. Do not rely on the sibling IPR outcomes. IPR2021-01476's cancellation of '987 claims 1 and 10 is not estoppel-bearing against '276 and does not cancel anything here; any petition must independently map art to claim 1's file-parser → byte-range → mask → flush-by-closing-connection sequence, and to claims 17's remote-file-object/partial-file-object architecture.
5. Budget against the clock, not the merits. The patent's anticipated expiration is 2028-01-07 (Google Patents stated term). With roughly 15 months of runway from today, model whether an IPR FWD (statutory 1-year deadline from institution, plus possible Federal Circuit appeal) can land before expiry, and weigh that against a reexam or a district-court invalidity case where the patentee bears the burden.

I'll start by pulling the authoritative assignment data and cross-referencing sources.

Let me dig into the specific corporate entities and assignment records.

Ownership & Assignment Analysis — US 11,706,276 B2

Patent: US 11,706,276 B2 ("Systems and methods for seeking within multimedia content during streaming playback")
Application: 17/326,056 · filed 2021‑05‑20 · granted 2023‑07‑18 · priority 2007‑01‑05 (Prov. 60/883,659)
Current assignee of record: DivX, LLC (per Google Patents legal events)
Assignment Center: assignmentcenter.uspto.gov · assignment.uspto.gov/patent/index.html

Retrieval caveat (read first): I was unable to pull the Assignment Center detail view for this patent in this session, so reel/frame numbers and the correspondent-of-record for US 11,706,276 itself are not verified here. What follows is grounded in (a) the Google Patents "Legal Events / Reassignment" table rendered on the patent page, and (b) chain-of-title and corporate records for sibling DivX applications and the DivX litigation campaign. Where a reel/frame is cited, it comes from a sibling application, and I say so.

Inventors

Unusual-pattern check: Not present. This is a single-inventor continuation (the substantive filing is US 11/970,493, 2008‑01‑07). Because there is only one inventor, the "all inventors depart within 12 months" fire-sale tell cannot form. Osborne's inventor portfolio is concentrated at DivX across many years, which is the opposite of a departure signature. No evidence of any inventor-side irregularity.

Original assignee

DivX, Inc. (f/k/a DivXNetworks, Inc.), San Diego, CA — an operating company.

• Product embodying the claims: Yes, historically. DivX shipped the DivX codec, DivX Player/DivX Web Player software, and ran the DivX Certified device program; progressive playback and trick-play are exactly the features the DivX client/player implemented (see the it-history DivX profile — ~240M codec downloads, 100M+ player downloads/yr, tech on 350M+ CE devices).
• Primary line of business: consumer video software + technology licensing to CE manufacturers and content services.
• Current status: No longer independent — acquired by Sonic Solutions (2010, ~$323M); Sonic then acquired by Rovi (2011, ~$720M); Rovi sold the DivX/MainConcept business to Parallax Capital Partners + StepStone Group (2014, up to $75M) (OCBJ); DivX acquired by NeuLion (2015, $62.5M) (VentureBeat). The "DivX" name now attaches to DivX, LLC, a patent-licensing entity that litigation filings describe as "Fortress-backed" and as an entity that "regularly creates corporate entities like DivX for the purpose of acquiring patents" (CourtListener, DivX v. Hulu).

Assignment timeline

Google Patents' legal-events table shows five recorded reassignments, all with recording date 2021‑08‑18 (i.e., a single bulk recordation). Execution dates are not displayed. Reel/frame and correspondent are not shown by Google Patents and were not retrievable in this session for this patent.

• 2021‑08‑18 (recorded) — Reel not retrieved

  • Conveyance: Assignment of assignor's interest
  • Assignor: Osborne, Roland
  • Assignee: DivX, Inc. (f/k/a DivXNetworks, Inc.)
  • Correspondent: not retrieved
  • Context: Original inventor-to-employer assignment.

• 2021‑08‑18 (recorded) — Reel not retrieved

  • Conveyance: Merger and Change of Name
  • Assignor: DivX, Inc. and Siracusa Merger LLC
  • Assignee: DivX, LLC
  • Correspondent: not retrieved
  • Context: Internal corporate reorganization (DivX, Inc. merged into a DivX LLC following the Sonic/Rovi acquisitions).

• 2021‑08‑18 (recorded) — Reel not retrieved

  • Conveyance: Assignment
  • Assignor: DivX, LLC
  • Assignee: Sonic IP, Inc.
  • Correspondent: not retrieved — flag: no recurrence determinable without the correspondent field.
  • Context: Transfer to a Rovi/TiVo-family IP-holding subsidiary (Sonic IP, Inc. is a TiVo Corporation subsidiary per OnScope).

• 2021‑08‑18 (recorded) — Reel not retrieved

  • Conveyance: Assignment
  • Assignor: Sonic IP, Inc.
  • Assignee: DivX CF Holdings LLC
  • Correspondent: not retrieved
  • Context: Transfer to a newly formed single-purpose vehicle — a defendant brief states "In late 2017, a new and unrelated entity was formed called 'DivX CF Holdings LLC' for purposes of acquiring certain Old DivX" assets (RPX litigation document).

• 2021‑08‑18 (recorded) — Reel not retrieved

  • Conveyance: Change of Name
  • Assignor: DivX CF Holdings LLC
  • Assignee: DivX, LLC (current assignee)
  • Correspondent: not retrieved
  • Context: Change of name only — the 2017 acquisition vehicle was renamed DivX, LLC, which is the present owner.

Corroborating sibling-application reel/frames (NOT verified for US 11,706,276). The chain-of-title filed in a different DivX application (15/453,714) records the same corporate links at Reel 042819/0890 (DivX, LLC → Sonic IP, Inc.) and Reel 045310/0020 (Sonic IP, Inc. → DivX CF Holdings LLC) (Docket Alarm / IPR2021‑01476 Exhibit 1002). This confirms the corporate chain but should not be cited as this patent's own reel/frame.

Timeline diagram

timeline
    title Ownership of US 11706276
    2007 : Priority date 2007-01-05
    2008 : Filed by DivX Inc
    2010 : Sonic Solutions acquires DivX
    2011 : Rovi acquires Sonic Solutions
    2014 : Rovi sells DivX to Parallax and StepStone
    2015 : NeuLion acquires DivX
    2017 : DivX CF Holdings LLC formed
    2021 : Chain recorded at USPTO
    2023 : Continuation issues as US 11706276

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT.
The patent moved out of an operating licensee into a chain of holding vehicles: DivX, LLC → Sonic IP, Inc. (IP-holding subsidiary) → DivX CF Holdings LLC, an entity a defendant brief characterizes as "a new and unrelated entity… formed… for purposes of acquiring certain Old DivX" assets (RPX doc), which was then renamed DivX, LLC (Google Patents event, recorded 2021‑08‑18). Sibling-app reel 045310/0020 records the Sonic IP → DivX CF Holdings step. Caveat: I could not retrieve the Assignment Center address/registered-agent block, so I am not asserting a registered-agent-service address or a single-member Delaware/Texas LLC structure — only the SPV-then-rename structure, which is documented.

2. Known asserter in the chain — PRESENT.
DivX, LLC is not on the enumerated classic list (Acacia, Marathon, IV, Wi-LAN, Vringo, etc.), but it independently meets the "high-frequency plaintiff surfaced by RPX/Unified" prong:

• Described in a filed brief as "Fortress-backed DivX" which "regularly creates corporate entities like DivX for the purpose of acquiring patents" (CourtListener).
• Repeat plaintiff: DivX, LLC v. Netflix (C.D. Cal. 2:19‑cv‑01602), DivX, LLC v. Hulu (2:19‑cv‑01606), DivX, LLC v. Amazon.com (1‑24‑cv‑02061 / 3‑24‑cv‑00818), and ITC Inv. 337‑3578 v. TCL.
• Defense-side aggregation target: Unified Patents LLC v. DivX, IPR2021‑01476 — Unified Patents typically challenges NPE-held patents.

3. Repeat correspondent across the chain — UNCLEAR.
The Assignment Center correspondent field could not be retrieved, so recurrence cannot be tested. For context only (litigation, not assignment-of-record correspondents): DivX's enforcement/IPR counsel is Lowenstein & Weatherwax LLP — Kenneth J. Weatherwax, USPTO Reg. No. 54,528, 1016 Pico Blvd, Santa Monica, CA 90405 — a firm with a large NPE client roster (DivX IPR2025‑01062 Mandatory Notices), plus Fenwick & West (DivX‑IPR@fenwick.com). Because these are litigation entries, not recording-practice entries, a single appearance is not a finding. Flagged as a gap to close.

4. Cascading transfers — PRESENT.
Four consecutive transfers terminate on the same recordation date, 2021‑08‑18, i.e., the entire chain was papered in one bulk filing rather than contemporaneously with the underlying corporate events. Successive assignees include two DivX-name variants and one Sonic-name variant, consistent with a chain arranged for a clean record. Whether the assignees share a correspondent address cannot be confirmed (see signal 3).

5. Pre-litigation transfer — NOT PRESENT on the available record.
The bulk recordation (2021‑08‑18) post-dates DivX's earliest asserted suits (Hulu and Netflix, 2019). I found no filing tying US 11,706,276 to a specific suit, so a within-6-months-before-first-suit link cannot be established either way for this patent. (This is a finding of no evidence, not a negative.)

6. Bankruptcy fire-sale — NOT PRESENT.
No Chapter 7/11 proceeding. The DivX divestitures were ordinary corporate sales: Rovi → Parallax/StepStone (2014, up to $75M) and DivX → NeuLion (2015, $62.5M). These are distressed divestitures, not bankruptcy sales.

7. Privateering — UNCLEAR.
The pattern is consistent with privateering (an operating company's patents ending up in a PE-funded assertion vehicle), and the chain shows DivX patents being pushed out through Sonic IP, Inc. into a Fortress-linked DivX, LLC that now sues streaming platforms. But I did not retrieve an SEC filing or Patent Progress/EFF coverage naming this patent as a privateering artifact. Treated as unresolved.

8. Defensive aggregator — NOT PRESENT.
The chain terminates at DivX, LLC, not at RPX, AST, LOT Network, Unified Patents, or OIN. The inverse is true: Unified Patents has attacked the DivX family at the PTAB.

Verdict

NPE — high confidence.

Two strong signals are present and documented: (i) a shell/SPV transfer chain — DivX, LLC (co. 1) → Sonic IP, Inc. → DivX CF Holdings LLC, an entity formed in late 2017 expressly "for purposes of acquiring certain Old DivX" assets, then renamed DivX, LLC (sibling-app reel 045310/0020; Google Patents events all recorded 2021‑08‑18); and (ii) a known/high-frequency asserter at the end of the chain — DivX, LLC is described in filed briefs as "Fortress-backed," "regularly creates corporate entities like DivX for the purpose of acquiring patents" (CourtListener, DivX v. Hulu), sues Netflix, Hulu, Amazon and TCL, and is the target of Unified Patents' IPR2021‑01476. The current owner does not appear to ship a product embodying the claims (its monetization is licensing and litigation), which rules out the "operating-company assertion" verdict, and nothing in the chain terminates at a defensive aggregator.

Residual uncertainty: the Assignment Center correspondent-of-record and reel/frame for US 11,706,276 itself were not retrieved, so the highest-value tell (repeat correspondent running multiple shells) is unverified. If the correspondent field shows the same attorney/firm across the Sonic IP and DivX CF Holdings links, this would firm to a documentary high-confidence call; if it shows distinct operating-company counsel, the SPV signal would weaken.

Verify at: USPTO Assignment Center — search patent number 11706276; mirror at assignment.uspto.gov.

I'll search for the citation record of this specific patent number and cross-check against the authoritative text already provided.

Let me retrieve the full front-page citation record and the examiner-cited references for this specific patent.

Prior-Art Analysis — US 11,706,276 B2

Critical sourcing note (read first)

Per my operating rules, I will not invent content. Two hard limitations apply here:

1. The authoritative full text you provided truncates the citation list. The Google Patents record states "Citations (381)," but the text supplied to me cuts off mid-entry at US5400401A … 1995-. I therefore do not have the complete, ordered 381-item citation list for 11,706,276, and I will not fabricate the missing ~350 entries.
2. What I can verify comes from (a) the partial Google list in your text, and (b) the front-page "References Cited" of the sibling family members — US 11,050,808 B2 and US 10,412,141 B2 — which carry the identical title, identical specification, and identical examiner (Glenford J. Madamba, TC/AU 2451). Continuation front pages in this family reuse substantially the same reference list, so these are the best available proxies, but I flag them as proxies, not the literal 11,706,276 front page.

Source URLs used:

• https://patents.google.com/patent/[US11706276B2](/patent/US11706276B2)/en (partial citations)
• https://patentimages.storage.googleapis.com/90/07/14/e377291e969368/US11050808.pdf (front-page references)
• https://patentimages.storage.googleapis.com/79/52/54/b691b978c0c015/US10412141.pdf (front-page references)
• https://portal.unifiedpatents.com/patents/patent/US-[10412141](/patent/10412141)-B2
• https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558133](/patent/1558133)/... (Netflix IPR exhibit list vs. the '141 sibling)

A. Threshold §102 point you must not skip

No single one of these cited references anticipates independent claim 1, 9, or 17 as a whole. Anticipation under 35 U.S.C. §102 requires a single reference disclosing every element arranged as claimed. The independent claims here require a specific combination: (i) a three-module client (file parser + download manager + playback engine); (ii) index→byte-range conversion; (iii) a mask of buffered media; and (iv) on seek, flushing a prior byte-range request by closing the connection to the remote server. That four-part combination is what distinguishes the claim, and it is exactly why the art below was cited as §103 combination art during prosecution rather than as §102 art.

I map below which references come closest to §102 (i.e., potentially anticipate a given claim on their own) versus which are §103-only combination references. I explicitly label descriptions I could not verify.

B. Examiner-cited U.S. patents (front-page "References Cited") — partial, verified

From the sibling front pages (US 11,050,808 / 10,412,141), the post-2000 examiner-cited U.S. patents:

Foreign patent docs cited: CA 2306524 A1 (9/2001); CN 1575595 A (2/2005). Neither is a plausible standalone §102 reference to claims 1/9/17.

C. Examiner-cited U.S. patent-application publications — partial, verified

D. Non-patent literature cited (verified in the family front pages/prosecution)

E. Most probative prior-art set — the Netflix IPR against the sibling US 10,412,141

The single most useful prior-art package for 11,706,276 is not the 381 front-page citations — it is Netflix's IPR petition against US 10,412,141 (the sibling with the same title, spec, and claims; PTAB petition documents at ptacts.uspto.gov, petition 1558133). Its grounds/exhibits map directly onto the 11,706,276 claims, because the claim sets are propagated across the family:

The IPR petition text I retrieved also confirms the type of obviousness argument run against this family — e.g., combining Zetts (MPEG/encoder) with Kaku (frame-number-based image data reading) to render "two indexes in a single multimedia file" and GOP offset tables obvious. That combination logic is the template a challenger would apply to 11,706,276's index-dependent claims.

F. Claim-by-claim §102 conclusions (conservative)

Bottom line: the most legally dangerous references against this patent are US 2005/0102371 A1 (Aksu) and US 2006/0059223 A1 (Klemets) for the independent claims, with US 5,874,986 (Gibbon) and US 8,731,369 (Li) supplying the trick-play/index elements. Each is realistically a §103 reference; I found no cited reference that anticipates claims 1, 9, or 17 on its own.

G. What I could not verify (explicit)

• I could not retrieve the complete 381-item citation list for 11,706,276; the authoritative text supplied truncates at US 5,400,401. My patent and publication tables above are partial and drawn from sibling front pages, which may differ in ordering or content from the literal 11,706,276 front page.
• Descriptions marked "Background," "Media," or "—" are ones where I do not have a verified technical disclosure abstract. I did not invent descriptions for them.
• The "Schmidt" vs. "Schmitz" discrepancy for US 5,544,318 is left as printed in each document per my no-auto-correction rule.
• I did not find (and do not assert) any §102 anticipatory reference beyond those flagged; if one exists in the untruncated list, it did not surface in my searches.

I'll ground the bibliographic details of the key candidate references before analyzing.

Let me check a few more of the cited references and whether the '276 patent has drawn any validity challenge.

Obviousness Analysis — U.S. Patent No. 11,706,276 under 35 U.S.C. § 103

A. Framework, and a gating issue the prior art list forces us to confront

Effective filing date gate. The '276 patent issued July 18, 2023 from App. Ser. No. 17/326,056 (filed May 20, 2021), but it is a direct continuation in a chain that terminates at provisional 60/883,659 (Jan. 5, 2007) and non-provisional 11/970,493 (Jan. 7, 2008). Assuming the claims have written-description support in that 2008 disclosure — and, as I noted in the summary, they appear to (the specification expressly describes the flush, the mask, the connection closing, the sparse data file, and the trick-play key-frame selection) — the presumptive § 102 prior-art date is January 5–7, 2007 and pre-AIA §§ 102/103 govern.

This matters enormously, because most of the truly on-point references on the patent's own face post-date the priority date by 2–10 years. The "Citations (381)" table on the Google Patents page is truncated in the source I was given — only six rows are visible (U.S. 3,609,227; 4,694,491; 5,132,992; 5,341,474; WO 94/24625; U.S. 5,400,401) before the fetch cuts off. The bulk of what appears on that page is the "Families Citing this family (83)" table, and many of those entries cannot be § 102 prior art against a 2007-priority claim. I flag this rather than build a rejection on references that are time-barred.

B. The prior-art pool actually usable against the '276 claims

Doctrinal wrinkle worth flagging: the four DivX server-driven applications incorporated by reference into the '276 specification are, because of the incorporation, arguably part of the patent's own disclosure and thus not available as prior art per se. But (a) their published applications are independently § 102(e) art (filed Dec. 2005–Jan. 2006, published ~2006), subject to (b) pre-AIA § 103(c) / AIA § 102(b)(2)(C), which disqualify commonly-owned § 102(e)/(f)/(g) art from § 103 combinations — DivX owns both sides here. Net effect: the documents may be excluded, but the Background's admissions (AAPA) are usable regardless, and they carry most of the motivational freight.

C. The references that would decide the case if priority were broken (worth knowing, not usable now)

All are on the family's face and all post-date Jan. 2007:

• US 2011/0078750 A1 (2Wire, "Trickplay in media file," pri. 2009-09-29) — client-side trick play "regardless of how far along the download has progressed"; key frames "retrieved using index information contained within the media file"; and it expressly disparages server-side trick-play intelligence, noting that a client "can only perform trickplay on a media file from a server having the trickplay processing capability" and that against "a standard media server, such as a HyperText Transfer Protocol (HTTP) server, the limitations on trickplay functionality … persist." This reads almost verbatim on the '276 premise.
• US 8,856,218 B1 (Google, "Modified media download with index adjustment," 2011-12-13) — download an index of a media file; use that index to request/download only a proper subset of the units, excluding the rest; HTTP Range header requests (claim 17); "seek-function request" (claim 4); omission of alternate bit-rate versions, language versions, and subtitle/trick-play tracks (claims 11–15).
• US 9,807,468 B2 (Microsoft, "Byte range caching," 2009-06-16) — receive byte-range request; identify overlapping chunks; maintain an index of which chunks are stored; "make a request to the origin server only for those chunks that a client has not previously requested."
• US 10,666,707 B2 (Microsoft, "Nonconsecutive file downloading," 2017-01-11) and US 9,510,029 B2 (EchoStar, trick play during streaming, 2010/2011).

The single most important strategic observation: a § 103 challenge that does not first knock out the 2007 priority date has to fight with 1990s VOD art, while a challenge that does knock it out can use art that maps element-for-element. That asymmetry is the crux of any real-world attack on this patent.

D. Claim 1 — element mapping for the strongest available pre-2007 combination

Proposed Ground: Bellcore '474 in view of Accom WO 94/24625 (U.S. 5,544,318) and HTTP/1.1, further in view of the BitTorrent protocol and the AAPA.

Claim 6/14/21 ("remote server is a standard HTTP server") is met directly by the specification's own Background (standard web servers do not parse; hence the receiver-driven design) together with RFC 2616.

E. Motivation to combine (KSR/Peterson rationales)

The motivation here is unusually well documented, and it comes mostly from the patent itself:

1. The problem is expressly identified in the Background. The patent states that server-driven systems require custom servers that "scale poorly when called upon to deliver content simultaneously to a large number of players," and that Samba-style pre-caching is "insufficient when trying to perform 'trick play' functions." A POSITA seeking feature-length VOD over commodity HTTP infrastructure has an articulated reason to move the determination of which bytes are needed from the server to the client — which is precisely the '276 claim 1 architecture.
2. Design incentive / market pressure. Delivering VOD over standard HTTP without custom servers was a recognized objective; "obvious to try" applies where "there are a finite number of identified, predictable solutions."
3. Simple substitution of a known element. Bellcore '474 already performs index/map-driven, segment-granular, trick-play-aware retrieval and buffering — it simply performs the computation at the central office. Moving that computation to the endpoint (Accom's client module) is substitution of a known element to obtain a predictable result.
4. Known technique improving a similar device in the same way. BitTorrent's bitfield/mask and piece-level request scheduling was known, and applying a "what do I already have / what do I still need" mask to a media download is the same technique applied to the same class of problem (large-file retrieval over unreliable networks).
5. Ordinary engineering of the cancellation step. Once Accom supplies the function (cancel obsolete requests; deserialize/reprioritize the queue), implementing it against HTTP requires closing the connection, because HTTP provides no in-band cancel primitive. Where a known technique has a single obvious implementation in the chosen protocol, that implementation is obvious — and the specification itself concedes the benefit is purely latency-related ("Closing the connection can remove latency associated with waiting for the media server to respond to pending download requests"), i.e., a predictable performance advantage.

F. Dependent claims

• Cl. 2 / 10 (flush = flush the request queue): Accom's queue removal, expressly claimed in U.S. 5,544,318 claim 11.
• Cl. 3 / 11 / 19 (file map with mask + data file): BitTorrent bitfield + payload file; sparse-file block indexing is a standard OS technique (and the patent's Background admits "a common file allocation approach").
• Cl. 4 / 12 / 20 (output data file when fully downloaded): Routine completion handling; BitTorrent "seed"/complete-file write.
• Cl. 5 / 13 (remote file object + partial file object, temp data path, queue): Routine object-oriented decomposition; '474's script-processor/I-O-processor split and Accom's client-module/server-module split supply the architectural teaching.
• Cl. 7 / 15 / 22 (single file, chunked container format): AVI/RIFF, OpenDML, MP4, Matroska — all admitted in the specification as known.
• Cl. 8 / 16 / 23 (list of index entries for requested chunks): AVI idx1 index entries + '474's "map … field sizes" disclosure.
• Cl. 17 (added limitations): instantiate remote file object and partial file object; maintain the queue; "upon determining that the at least one previously requested portion of media is no longer required," flush; close the connection. This is the narrowest independent claim and is the one Accom most directly reaches, because Accom is framed precisely around determining that an outstanding request has become obsolete.

G. Where the patent most plausibly survives — and the counter-argument to my own analysis

1. No single reference, and no permitted combination, discloses the ordered combination in one place. The strongest available art maps the elements individually, and the flush-by-closing-connection limitation has to be reached through an inferential bridge ("Accom's cancel ⇒ close the socket in HTTP"). That is a KSR "obvious to try" argument rather than a clean "arranged as claimed" argument, and it is more vulnerable to a POSITA-declaration attack from the patentee.

2. Objective indicia cut against the challenger — and they are significant. The 2Wire reference (priority 2009-09-29) states that client-side trick play against a standard HTTP server remained an unsolved limitation, and Google's '218 (filed 2011-12-13) was still being prosecuted on "download the index, then download only a subset" years after Jan. 2007. If sophisticated implementers were still addressing this problem in 2009–2011, that is evidence of (a) long-felt need and (b) failure of others — the classic secondary considerations rebuttal, and it is grounded in the very documents on this patent's face. The patentee would not need to find new evidence; it can point at the family's own citation list.

3. Pre-AIA § 103(c) may neutralize the most convenient art. If a challenger tries to use the DivX server-driven published applications as § 102(e) art, common ownership at the time of invention defeats the § 103 combination. (This is exactly the kind of argument that was pressed — and largely succeeded — in the family's PTAB and district-court skirmishes.)

4. Which means the decisive question is priority, not art. The cleanest, most economically efficient attack is a § 112 written-description / enablement attack on the 2007 priority claim, aimed at the "flush request" + "closing the connection" + "mask" limitations, to see if any claim lacks support in the Jan. 2008 disclosure and therefore gets a post-March-2013 effective filing date (triggering AIA § 102 and unlocking 2Wire, Google, Microsoft, EchoStar). I assess that as unlikely to succeed on the present record — the specification's FIGS. 4–7 and accompanying text describe the mask/status file, the flush, and the connection closing — but it is the pivot on which any serious challenge turns.

H. Bottom line — graded assessment

If priority is broken (AIA applies): claims 1, 9, and 17 become highly vulnerable — 2Wire '01078750 alone discloses client-side, index-driven key-frame trick play against a standard HTTP server, and Microsoft '7468 supplies the "request only the chunks not already cached, using a chunk index/mask" element almost verbatim.

I. Consistency checks against the earlier sections, and caveats

• Apparent internal inconsistency in the earlier litigation sections: the Litigation Summary table lists DivX, LLC v. Netflix, Inc., C.D. Cal. No. 2:19-cv-01602 as asserting U.S. 11,050,808 and 10,412,141, while the Patent Summary describes the May 7, 2026 final judgment in that same case as addressing US 7,295,673; 8,139,651; 8,472,792; and 10,212,486. These are reconcilable (different patents may have been narrowed out of the case by the time of judgment), but as written they conflict and the reader should not rely on either list as complete for that docket. This does not affect the § 103 analysis, because neither section identifies any proceeding against 11,706,276 itself.
• Truncated source: the "Citations (381)" table in the material I was given cuts off after six rows (U.S. 5,400,401). My pool is therefore necessarily incomplete, and the possibility that an earlier-dated reference hidden in the un-fetched portion of that table is more on point than Bellcore/Accom cannot be excluded. A full § 103 opinion requires the complete 381-row citation list plus the family's IDS submissions.
• No independent verification of my claim-mapping: I have not inspected the '276 file history (the examiner's reasons for allowance, or any art applied rather than merely cited). The references discussed here appear on the face of the patent/family; whether the examiner substantively relied on any of them is not established. Verifying would require the USPTO PatentCenter file wrapper for App. 17/326,056.
• What I did not find: no IPR, PGR, or reexamination naming 11,706,276 — consistent with the earlier Litigation Summary. The family has post-grant activity (notably the ex parte reexamination of U.S. 10,574,716 requested July 20, 2026 and granted Sept. 18, 2026), which may generate art reusable against '276; that reexamination's grounds would be worth pulling directly from the PTAB/PatentCenter record.
• Confidence: High on the reference disclosures and dates I quoted (they come from the reference texts and EPO/Google records retrieved above). Moderate on the § 112/priority-support assessment. Low on whether any single combination would survive a contested IPR, given the KSR-bridge weakness in the "closing the connection" limitation.