US 10212486

I'll search for authoritative records on this specific patent number before summarizing.

Let me check the litigation/appeal dockets more specifically, including the ITC action and the Realtek appeal.

Let me confirm the current status of the related Federal Circuit appeal and check for any 2026 activity.

US Patent 10,212,486 B2 — Summary

Primary source: Google Patents US10212486B2 (full text supplied; official PDF also appears as JX‑0003 in ITC Inv. No. 337‑TA‑1222 at ptacts.uspto.gov).

Bibliographic data (verified against the patent front page)

Assignment chain (USPTO assignment records, per Google Patents): DivX, LLC → Sonic IP, Inc. (Aug. 16, 2017) → DivX CF Holdings LLC (Feb. 13, 2018) → DivX, LLC (change of name, Mar. 5, 2018). The printed patent names DIVX, LLC as applicant/assignee.

Continuation family: The application is a continuation of 14/839,783 (now US 9,706,259), itself a continuation of 14/306,146 (now US 9,124,773), itself a continuation of 12/946,631 (now US 8,781,122), which claims priority to provisional 61/266,982. Later continuations/continuations‑in‑part include US 10,484,749, US 11,102,553, US 12,184,943, and pending US 2026/0122321 A1 (all with the same 2009‑12‑04 priority).

Abstract (as issued)

Systems and methods for providing multimedia content from one process or component to another over an unsecured connection. One embodiment includes obtaining the cryptographic information, extracting the at least partially encrypted video data from the container file to create an elementary bitstream, enciphering the cryptographic information, inserting it in the elementary bitstream, providing the bitstream to a video decoder, extracting the cryptographic information at the decoder, deciphering it, decrypting the elementary bitstream with it, and decoding for rendering on a display device.

Independent claims — plain language

Claim 1 (playback device). A playback device with one or more processors and non‑volatile storage holding a playback application that:

1. receives, at a parser, a container file holding video data;
2. extracts portions of the container file, where the container contains (a) video data with a plurality of partially encrypted frames, each frame having both encrypted and unencrypted portions, and (b) cryptographic information per frame that includes cryptographic material for the encrypted portion and a block reference identifying that encrypted portion;
3. passes each partially encrypted frame, its cryptographic material, and its block reference from the parser to a video decoder;
4. locates the encrypted portion of each frame using the block reference;
5. deciphers a frame key for each frame using the cryptographic material;
6. decrypts the encrypted portion of each frame based on that frame key using the video decoder; and
7. decodes each decrypted frame for rendering on a display using the video decoder.

In short: the demultiplexer/parser doesn't ship decrypted content downstream — it ships cryptographic material plus a pointer to the encrypted region alongside the still‑encrypted bitstream, and the decoder does the decryption and decoding.

Claim 15 (method). The same seven steps recited as a method for playing back encrypted video, with the same parser → decoder handoff of frame + cryptographic material + block reference, per‑frame key deciphering, decryption, and decoding.

Key dependent claims (device claims 2–14; parallel method claims 16–25): unsecured channel between parser and decoder (2, 16); block reference is "offset and length information" (3, 17); communication with a DRM component to decipher the frame key (4, 18); frame key encrypted to restrict playback to a particular user (5/6, 19/20); streaming the container file (7); building a cryptographic payload from the material + block reference (8, 21); payload delimited by an identifier (9, 22) that the decoder uses to extract it (10, 23); inserting the payload at the front of each demultiplexed frame (11, 12); and frame header encryption/plaintext variations (13, 14, 24, 25).

Observation on the printed text (not a correction): claims 5 and 6 are word‑for‑word identical, as are claims 19 and 20 — an apparent duplication in the granted claim set. Similarly, claim 11 refers to "the cryptographic payload" although the payload is first introduced in claim 8, from which claim 11 does not depend.

Litigation / docket posture (relevant to your CAFC query)

• ITC Inv. No. 337‑TA‑1222 ("Certain Video Processing Devices…"), instituted Oct. 19, 2020 on DivX's complaint asserting the '486, '297, '141 and '749 patents against Samsung, LG, MediaTek, Realtek and TCL. DivX partially terminated numerous '486 claims (claims 3, 7, 9, 13–14) in April 2021 (Order No. 49), and later withdrew '486 claims 15–19 and 21–25 (Order No. 25). The investigation terminated by settlement with TCL on May 24, 2022. See 87 FR 32184 / 2022‑11460.
• D. Del. 1:20‑cv‑01202 (DivX v. LG and Realtek) asserted the '486 and '749 patents against Realtek. The case was dismissed without prejudice on June 4, 2024, over Realtek's objection; Realtek appealed (Fed. Cir. 24‑2061). That appeal was dismissed under Fed. R. App. P. 42(b) by agreement on July 1, 2025 — order.
• Fed. Cir. 23‑1095 (Realtek v. ITC) arose from the same ITC investigation but was a sanctions/APA appeal, not a merits appeal on the '486; the court dismissed it as unreviewable on March 18, 2025 (opinion).
• Netflix litigation (C.D. Cal. 2:19‑cv‑01602): the '486 patent was among the asserted patents, with claims 1, 4, 8, 15 and 21 asserted. Notably, DivX stated that the '486 patent "was not subject of a PTAB proceeding and is not subject of an appeal" (Joint Status Report, Apr. 17, 2023, Dkt. 140).

On your specific request re CAFC 2026 dockets: A search of Federal Circuit activity did not surface any 2026 appeal involving US 10,212,486. The high‑profile 2026 Federal Circuit decision in this patent family — Netflix, Inc. v. DivX, LLC, Nos. 2024‑1541 (Fed. Cir. Feb. 13, 2026) (opinion) — concerns U.S. Patent No. 10,225,588, not the '486 patent, and should not be attributed to it. Similarly, the two Realtek appeals touching this family (23‑1095 and 24‑2061) were resolved in 2025. I did not independently query PACER/CM‑ECF for the '486 docket in 2026, so I cannot rule out a newly filed matter; treat that as an open item rather than a negative finding.

Confidence and uncertainty

• Bibliographic data, abstract, and claim text are taken directly from the authoritative full patent text and the printed front page reproduced in the ITC appeal appendix — high confidence.
• The "anticipated expiration 2030‑11‑15" figure is Google Patents' own calculation (20 years from the Nov. 15, 2010 filing of the earliest non‑provisional parent), not an official PTO statement; actual term could be affected by any terminal disclaimer or PTA.
• The apparent duplicate claims (5/6 and 19/20) are reported as they appear in the issued text; I am not asserting an error in the official record.
• No 2026 CAFC docket item specific to 10,212,486 was located; if you need a definitive negative, a PACER/CM‑ECF docket or the CAFC daily docket for the docket number would be required.

I'll search for litigation involving US Patent 10,212,486.

Let me search for more specifics on each case.

Litigation involving U.S. Patent No. 10,212,486 ("the '486 patent")

Patent: US 10,212,486 B2 — "Elementary bitstream cryptographic material transport systems and methods"
Assignee/owner: DivX, LLC (San Diego, CA)
Priority date: December 4, 2009 · Filing date: June 6, 2017 (Appl. No. 15/615,626) · Issued: February 19, 2019
Anticipated expiration: November 15, 2030

I identified eight dockets/actions listed for this patent on the Google Patents litigation page (https://patents.google.com/patent/US10212486/en), and confirmed the substance of the principal ones. One caveat up front: Google Patents' litigation list for a patent is family-based, so a listed case does not always mean the '486 patent itself was asserted. I flag that distinction for each case below.

Confirmed litigations asserting the '486 patent

1. ITC Investigation No. 337-TA-1222 — "Certain Video Processing Devices, Components Thereof, and Digital Smart Televisions Containing the Same"

• Complainant: DivX, LLC
• Respondents: Samsung Electronics Co., Ltd.; [Samsung Electronics America, Inc.](/litigations/by-plaintiff/Samsung%20Electronics%20America%2C%20Inc.); Samsung Electronics HCMC CE Complex Co., Ltd.; [LG Electronics Inc.](/litigations/by-plaintiff/LG%20Electronics%20Inc.); LG Electronics U.S.A., Inc.; MediaTek, Inc.; MediaTek USA Inc.; MStar Semiconductor, Inc.; Realtek Semiconductor Corp.; and the TCL entities (TCL Corporation, TCL Technology Corp., TCL Electronics Holdings Ltd., TTE Technology, Inc., Shenzhen TCL New Technologies Co., TCL King Electrical Appliances (Huizhou) Co., TCL MOKA International Ltd., TCL Smart Device (Vietnam) Co.)
• Jurisdiction: U.S. International Trade Commission
• Case number: 337-TA-1222
• Filing date: Complaint filed September 10, 2020 (supplemented Sept. 15 and 22, 2020); instituted October 19, 2020, 85 FR 66355
• Asserted patents: U.S. Pat. Nos. 10,212,486 ('486); 8,832,297; 10,412,141; 10,484,749
• Status/outcome: Realtek was terminated from the investigation on DivX's unopposed motion (Order No. 67, July 16, 2021; Commission declined review Aug. 4, 2022). The investigation was terminated as to the last remaining respondent, TCL, on a joint motion based on a settlement agreement (joint motion April 19, 2022; termination May 2022). Companion sanctions proceedings (Realtek's motion against DivX; DivX's motion) were denied and terminated — Commission notice published at 87 FR (Aug. 30, 2022).
• Source: https://www.govinfo.gov/app/details/FR-2020-10-19/2020-23056; https://www.federalregister.gov/documents/full_text/xml/2022/08/30/2022-18606.xml

2. DivX, LLC v. Realtek Semiconductor Corp. (with LG Electronics Inc. and LG Electronics U.S.A., Inc.)

• Plaintiff: DivX, LLC
• Defendants: Realtek Semiconductor Corp.; LG Electronics Inc.; LG Electronics U.S.A., Inc.
• Jurisdiction: U.S. District Court for the District of Delaware (Judge Jennifer L. Hall)
• Case number: 1:20-cv-01202 (also docketed as 1:20-cv-01202-JLH / -CFC)
• Filing date: September 9, 2020
• Asserted patents: '297, '486, '141, '749 (per the Rule 120 Report to the Commissioner: "US 8,832,297 B2; US 10,212,486 B2; US 10,412,141 B2; US 10,484,749 B2")
• Outcome/status: Terminated June 4, 2024 — Memorandum Order granting Defendant's Motion to Dismiss Without Prejudice; complaint dismissed without prejudice and case closed.
• Source: https://www.courtlistener.com/docket/18422116/divx-llc-v-realtek-semiconductor-corp/

3. DivX, LLC v. TCL Corporation et al.

• Plaintiff: DivX, LLC
• Defendants: TCL Corporation; TCL Technology Group Corp.; TCL Electronics Holdings Ltd.; TCL King Electrical Appliances (Huizhou) Co. Ltd.; TCL MOKA International Ltd.; TCL Smart Device (Vietnam) Co. Ltd.; TTE Technology, Inc.; Shenzhen TCL New Technologies Co. Ltd.; MediaTek Inc.; MediaTek USA Inc.; MStar Semiconductor, Inc.
• Jurisdiction: U.S. District Court for the District of Delaware
• Case number: 1:20-cv-01203 (docketed 1:20-cv-01203-CFC)
• Filing date: September 9, 2020
• Asserted patents: Same four-patent group as the ITC action, including the '486 patent (Complaint, D.I. 1)
• Status: I could confirm only that MediaTek was terminated (February 2021) and docket activity through April 26, 2022 (D.I. 15/16). I could not verify a final disposition from the sources retrieved — treat the current status as not independently confirmed.
• Source: https://www.courtlistener.com/docket/18422115/parties/divx-llc-v-tcl-corporation/

4. DivX, LLC v. Samsung Electronics Co., Ltd. et al.

• Plaintiff: DivX, LLC
• Defendants: Samsung Electronics Co., Ltd.; Samsung Electronics America, Inc.; Samsung Electronics HCMC CE Complex, Co., Ltd.
• Jurisdiction: U.S. District Court for the Eastern District of Texas, Marshall Division (Judge Rodney Gilstrap)
• Case number: 2:20-cv-00301
• Filing date: September 9, 2020
• Asserted patents: '297, '486, '141, '749 (Complaint for Patent Infringement)
• Status: As of the last docket data I retrieved, the case was pending; Defendants filed an Unopposed Motion to Stay (Nov. 2020), presumably tied to the parallel ITC investigation. I could not confirm a later judgment or dismissal.
• Source: https://www.docketalarm.com/cases/Texas_Eastern_District_Court/2--20-cv-00301/DivX_LLC_v._Samsung_Electronics_Co._Ltd._et_al/docs/1.pdf

5. DivX, LLC v. Netflix, Inc. — the only case I found that went to judgment on the '486 patent

• Plaintiff / Counterclaim-Defendant: DivX, LLC
• Defendant / Counterclaimant: Netflix, Inc.
• Jurisdiction: U.S. District Court for the Central District of California (Judge George H. Wu)
• Case number: 2:19-cv-01602-GW-AGRx (later styled 2:19-cv-01602-PSG-DFM)
• Filing date: March 2019 (DivX's complaint was served on Netflix March 12, 2019, which started the one-year IPR window)
• Asserted patents at trial: U.S. Pat. Nos. 7,295,673; 8,139,651; 8,472,792; and 10,212,486 — with claims 1, 4 and 15 of the '486 patent specifically asserted
• Outcome/status: Jury trial began March 13, 2026. On March 25, 2026, the jury returned a unanimous verdict that Netflix did not infringe the asserted claims, including claims 1, 4 and 15 of the '486 patent. Final judgment entered May 7, 2026 (Dkt. 1197): "Netflix has not infringed and does not infringe claims 1, 4, or 15 of U.S. Patent No. 10,212,486"; Netflix declared the prevailing party and awarded costs; case terminated.
• Source: https://law.justia.com/cases/federal/district-courts/california/cacdce/2:2019cv01602/[738825/1197](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=738825-1197)/

Cases listed on the patent's litigation page that I could not confirm asserted the '486 patent

6. DivX, LLC v. Hulu, LLC

• Case number: 2:19-cv-01606 (C.D. Cal.)
• Status: Dismissed August 25, 2022 (as recited in the PTAB petition in Netflix, Inc. v. DivX LLC, IPR2020-00646, referring to the '792 patent as asserted in both DivX v. Netflix, 2:19-cv-01602, and DivX v. Hulu, 2:19-cv-01606). I could not independently confirm that the '486 patent was asserted against Hulu.
• Source: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1533651](/patent/1533651)/download-documents

7. DivX, LLC v. TCL Technology Group Corporation et al.

• Case number: 2:21-cv-00264 (E.D. Tex., Judge Rodney Gilstrap)
• Filing date: July 15, 2021 · Amended complaint filed August 2021
• Asserted patents: The complaint exhibits I retrieved reference the '955 and '641 patents, not the '486 patent. This action is listed on the '486 Google Patents litigation page (family-based), but I could not confirm that the '486 patent was asserted in it. Flagging this as a possible over-inclusion of the family listing.
• Source: https://unicourt.com/case/pc-db5-divx-llc-v-tcl-technology-group-corporation-et-al-[958128](/patent/958128)

8. Federal Circuit appeals 23-1095 and 24-2061

• Both are listed on the '486 patent's litigation page as Court of Appeals for the Federal Circuit matters. I could not verify from the sources retrieved what patents or issues these appeals concern, or whether the '486 patent itself is on appeal. They appear to be DivX-related patent appeals but the linkage to the '486 patent is unconfirmed.

Additional point relevant to the '486 patent's enforcement history

No PTAB proceeding was ever filed against the '486 patent. In DivX's memorandum in support of a motion to lift the stay in the Netflix case, DivX stated that "Eight of the previously asserted claims and the entire 486 Patent were not even challenged in IPR." (Case No. 2:19-cv-1602, Dkt. 146-1.) The many IPRs in this campaign (e.g., IPR2020-00646, -00647, -00648, -00614, IPR2019-01379) targeted sibling patents such as the '792, '515 and '673 patents, not the '486 patent.

Bottom line

The '486 patent has been asserted in a multi-front campaign by DivX, LLC that began in March 2019 and ran through 2026: (a) the ITC § 337 investigation 337-TA-1222 against Samsung, LG, MediaTek/MStar, Realtek and TCL (ended in termination/settlement, 2022); (b) parallel Delaware actions 1:20-cv-01202 (Realtek/LG; dismissed without prejudice June 4, 2024) and 1:20-cv-01203 (TCL et al.; status unconfirmed); (c) the Texas action 2:20-cv-00301 (Samsung; status unconfirmed); and (d) the C.D. Cal. action 2:19-cv-01602 against Netflix, which is the only case I found that reached a merits judgment on the '486 patent — a March 25, 2026 jury verdict and May 7, 2026 final judgment of non-infringement of claims 1, 4 and 15 in Netflix's favor.

Two limitations on this answer: I did not have access to PACER directly, and the two Federal Circuit appeal numbers (23-1095, 24-2061) listed for this patent could not be tied to the '486 patent with confidence. If exact dispositions for the Delaware TCL case (1:20-cv-01203) or the Texas Samsung case (2:20-cv-00301) matter, those dockets should be pulled from PACER/CourtListener before relying on them.

I'll verify the structured "no proceedings" default against public sources before finalizing.

Important nuance found — I need to reconcile conflicting reports about the '486 patent. Let me dig further.

The record strongly indicates no IPR was ever filed on the '486 patent, but one secondary source contradicts that. Let me resolve it.

Proceedings overview

Total AIA trial proceedings on file for US 10,212,486: zero (0) — no IPR, no PGR, no CBM. The USPTO ODP structured block returns no AIA trials, and I could not corroborate any proceeding through public search; the primary litigation record affirmatively states that no IPR petition was ever filed against the '486 patent. The bottom line for a defendant is therefore the opposite of "hardened by PTAB win": the '486 patent has never been screened by the Board, so there is no estoppel, no FWD to point to, and no PTAB ruling that narrows or cancels anything — but also no PTAB ruling you can borrow. All of its 25 claims (all originally issued) remain untested at the PTAB, and validity was adjudicated instead in the ITC and in district court, where DivX has been losing ground on other issues. Note also that the two natural petitioners (Netflix and Hulu) blew their § 315(b) one-year windows in March 2020, so the '486 will never see an IPR from the parties who had the best art — which is why the § 315(b) calendar, not the merits, is the central fact of this patent's PTAB story.

Verification trail (why I conclude "none"):

• The structured ODP "PTAB proceedings on file" block is empty.
• Netflix's own stay motion (2020-03-13) charts seven petitions covering seven of the eight patents-in-suit, and the eighth — the '486 — is conspicuously absent: "Netflix and Hulu … have filed IPR petitions on all but one of the patents-in-suit." (Dkt. 94, C.D. Cal. 2:19-cv-01602, https://storage.courtlistener.com/recap/gov.uscourts.cacd.[738825](/patent/738825)/gov.uscourts.cacd.738825.94.0.pdf)
• Status table filed in the same case: "'486 Patent, Claims 1, 4, 8, 15, and 21 — No challenge — All asserted claims are pending." (https://storage.courtlistener.com/recap/gov.uscourts.cacd.738825/gov.uscourts.cacd.738825.158.0.pdf)
• The 2023-12-29 joint status filing states it flatly: "Eight of the previously asserted claims and the entire 486 Patent were not even challenged in IPR," with a "No IPR petition filed" entry keyed to the '486. (https://storage.courtlistener.com/recap/gov.uscourts.cacd.738825/gov.uscourts.cacd.738825.146.1.pdf)

⚠️ One flagged discrepancy (unresolved — verify before relying)

A secondary trade-press table (IPFray, reporting the March 2026 Netflix/DivX jury verdict) lists U.S. 10,212,486 as "Invalidated by PTAB." That is inconsistent with every primary document I found, including party filings in the same litigation as late as 2023-12-29, and with the absence of any ODP record. My working conclusion is that the IPFray table is an error (the entry appears alongside the '651 patent, which did go through IPR) or a conflation with the ITC/§ 101 outcomes. It is not a substituting source for a PTAB proceeding number, and I could not find a proceeding number to attach to it. If it is real, it post-dates the 2023 status briefs — check PTAB E2E (https://ptacts.uspto.gov/ptabweb/) and the '486 patent's file wrapper directly. Do not build a defensive position on either reading until you pull the file wrapper.

Related PTAB activity that bears on a '486 defense (adjacent, not on this patent)

These are not proceedings on 10,212,486 and are listed only for strategic context. Do not cite any of them as a '486 FWD.

Netflix, Inc. v. DivX, LLC — IPR2020-00614 ('673), IPR2020-00052 ('651), IPR2020-00646 ('792), IPR2020-00511 ('920), IPR2020-00647 ('720), IPR2020-00648 ('515), IPR2020-00558 ('588)

• Type: Inter Partes Review (§ 102 / § 103)
• Filed: various, October 2019 – February/March 2020
• Status: All instituted; FWDs issued 2021–2023; DivX largely prevailed, with the Board upholding challenged claims in several proceedings; mixed results on appeal.
• Appeals (representative): 22-1203/22-1204 (Fed. Cir. 2023-10-25, precedential, https://cafc.uscourts.gov/opinions-orders/22-1203.OPINION.10-25-2023_2211191.pdf — affirmed DivX; panel held the Board need not "decode a petition to locate additional arguments beyond the ones clearly made," Dyk, J., dissenting); 22-1083 (2023-03-01, https://cafc.uscourts.gov/opinions-orders/22-1083.OPINION.3-1-2023_2088157.pdf — '588 claim construction); 24-1541 (2026-02-13, https://www.cafc.uscourts.gov/opinions-orders/24-1541.OPINION.2-13-2026_2647816.pdf — '588, applying the last-antecedent rule to construe "within the requested portions of the selected stream of protected video").
• Why this matters to a '486 defendant: DivX asserted narrow claim constructions in these IPRs (e.g., '588 IPR2020-00558 POR at 25: the modifier attaches to "locating," requiring encryption information to be inside the requested stream portions). The Federal Circuit rejected that style of narrowing argument on 2026-02-13 in the '588 appeal. The '486 claim 1 shares the same architectural vocabulary ("encrypted portions and unencrypted portions of data," "block reference that identifies the encrypted portion," top-level index file), so those prosecution-side/IPR-side narrowing positions are the first place to look for a § 101 or § 103 attack — but those are judicial and ITC constructions, not PTAB estoppel.

Unified Patents, Inc. v. DivX, LLC — IPR2019-01379

• Type: Inter Partes Review
• Status: Patent owner won; FWD 2021-02-08 (Paper 52) upheld the challenged claims; Unified did not appeal.
• Context for '486: Unified ran a Patroll prior-art bounty on the '486 patent itself — "$7,000 … seeking prior art for claim 1 of US 10,212,486, asserted in district court cases by DivX LLC (an NPE)," open 2020-01-24 to 2020-03-01 (http://patroll.unifiedpatents.com/contests/y389QTG6iwxnecqtK). The contest closed with a winner but no IPR was ever filed on the '486. That is the single most useful negative signal in this file: a well-funded defensive aggregator crowdsourced art against claim 1 and still did not file.

Strategic summary

Claim status. No claim of 10,212,486 has been canceled, amended, or even institution-tested. Claims 1–25 as issued stand, with 25 claims currently on the face of the patent. On this record there are no "surviving claims" to list because none were ever cancelled — but the corollary is that there is no PTAB holding to cite for any claim, in either direction. The '486's validity history is judicial, not administrative: (a) a § 101 eligibility attack via Realtek's motion for judgment on the pleadings in D. Del. (C.A. 1:20-cv-01202, Dkt. 52, 2021-04-27, arguing the claims are directed to the abstract idea of decryption); (b) an ITC invalidity challenge in No. 337-TA-1222 (obviousness, plus a "video decoder" claim-construction fight decided at hearing); and (c) the C.D. Cal. Netflix action, which went to a jury verdict on 2026-03-25 finding Netflix does not infringe claims 1, 4, and 15 of the '486, with final judgment entered 2026-05-07 (https://law.justia.com/cases/federal/district-courts/california/cacdce/2:2019cv01602/[738825/1197](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=738825-1197)/). Infringement, not validity, is what killed DivX's '486 theories in district court.

Estoppel landscape. There is no § 315(e)(2) estoppel on the '486 at all — for anyone. No petition, no institution, no FWD, no estoppel. That cuts both ways for a current defendant: (1) you can run prior-art grounds the Board never saw, without worrying that a privy raised them; and (2) no petitioner has narrowed DivX's claim scope in an IPR, so you cannot point to a prior Board construction and say "DivX already conceded this." What does exist is a calendar bar for the obvious petitioners: Netflix was served 2019-03-12 (its motion identifies the service date), Hulu's case was filed 2019-03-04, and the § 315(b) year ran in March 2020. Netflix and Hulu can never file an IPR on the '486 now. A newly served defendant is the only remaining path into the PTAB on this patent, and it has one year from its own service date — a live window given the patent's listed anticipated expiration of 2030-11-15.

Pattern signals. DivX, LLC (a Fortress/SoftBank-backed entity formed 2018, per Hulu's 2022 briefing) is an aggressive, portfolio-wide monetizer: district court actions in C.D. Cal., D. Del., and E.D. Tex. (2:19-cv-01602, 2:19-cv-01606, 1:20-cv-01202, 1:20-cv-01203, 2:20-cv-00301, 2:21-cv-00264), ITC Investigation No. 337-TA-1222, and Federal Circuit appeals at 23-1095 and 24-2061. It does fight IPRs hard and it does appeal adverse rulings — it litigated seven Netflix/Hulu IPRs to FWD and through the Federal Circuit, and it filed a public comment opposing proxy petitioners like Unified Patents (https://downloads.regulations.gov/PTO-P-2020-0022-0783/attachment_1.pdf). Unified Patents is in the chain as a defensive aggregator (the '651 IPR it lost, plus the '486 bounty), but it never filed on the '486. DivX has also asserted the '486 family broadly — the '486, its continuation 10,484,749, and the sibling 10,412,141 / 8,832,297 were co-asserted at the ITC; the family also includes 8,781,122, 9,124,773, 9,706,259, 11,102,553, 12,184,943 and pending US20260122321A1. The '486's own ITC exposure narrowed by withdrawal — on 2021-02-01 the Commission declined review of an ID terminating the investigation as to claims 15–19 and 21–25 of the '486 (https://www.usitc.gov/secretary/fed_reg_notices/337/337_1222_notice_02012021sgl.pdf) — which is a useful tell about how much of the claim set DivX was willing to spend on.

Recommended next steps

1. Do not cite a '486 IPR/FWD — there isn't one. If a demand letter or complaint asserts claims 1, 4, 8, 15, or 21, there is no PTAB disposition to raise against it. Pull the file wrapper and PTAB E2E (https://ptacts.uspto.gov/ptabweb/) yourself to close out the flagged IPFray discrepancy before you file anything.
2. If you have been served within the last 11 months, a § 315(b) clock is running and it is the only way to get this patent in front of the Board. After your year, no IPR on the '486 is possible for you either, and the patent runs to 2030-11-15.
3. Mine the sibling IPRs. Netflix's IPR2020-00052 ('651), -00614 ('673), -00646 ('792), -00511 ('920), -00647/00648 ('720/'515), and -00558 ('588) each contain DivX's own narrowing constructions of shared claim language (encryption/decryption of frame portions, index files, "asset" lists), plus an expert record you can reuse. Read DivX's Patent Owner Responses for admissions about the scope of "block reference," "cryptographic material," and "video decoder" — the last of which was litigated as a claim-construction issue in the ITC.
4. Lead with the non-PTAB outcomes. The strongest '486 defenses on this record are non-infringement (Netflix cleared claims 1, 4, 15 on 2026-03-25; judgment 2026-05-07) and § 101, per Realtek's D. Del. motion. Note that ITC validity findings generally lack collateral estoppel effect in district court, so an ITC win for you does not automatically travel.
5. Rule 50/52 and appeal preservation. Because the Federal Circuit has twice now punished DivX's narrow-construction posture on sibling claims (22-1083; 24-1541, 2026-02-13), preserve claim-construction positions that track the "last-antecedent"/plain-grammar reading of '486 claim 1 rather than DivX's narrow reading.

Caveat on confidence. I am highly confident that no IPR/PGR/CBM proceeding on 10,212,486 appears in the ODP structured block or in the litigation record through 2023-12-29. I have not verified the file wrapper for anything filed after that date, and the single secondary source claiming PTAB invalidation of the '486 (IPFray, 2026) conflicts with the primary record and I could not confirm a proceeding number for it. Treat that one line as unverified, not as an established fact.

I'll research the assignment chain and litigation record for US 10212486 before writing the report.

Strong initial signal — the litigation record describes a Fortress-owned entity. Let me dig into the specific reel/frame entries, correspondent, and the litigation docket.

Ownership & Assignment Analysis — US 10,212,486 B2

Patent: Elementary bitstream cryptographic material transport systems and methods
Application: 15/615,626 (continuation) · filed 2017-06-06 · issued 2019-02-19
Earliest priority: 2009-12-04 (provisional 61/266,982) · parent 12/946,631 filed 2010-11-15
Assignee of record (per Google Patents legal events): DivX, LLC

Scope caveat up front. The reel/frame figures I can attribute with confidence are the two portfolio-level recordings that appear directly on this patent's legal-events record (045310/0020 and 045498/0560) plus the two inventor/subsidiary links recited in DivX's own chain-of-title statement filed in the prosecution history of sibling application 15/453,714 (042819/0871 and 042819/0890). I could not retrieve the correspondent of record for any recording from the sources available to me, and I will not invent one. Where I have not verified something, I say so.

Inventors

Basis for employer: the recorded inventor→company assignment on this family runs from Chan, Soroushian and Wood to DivX, LLC (Google Patents legal event 2017-08-16; the equivalent portfolio link is recited at Reel 042819/0871 in the 15/453,714 chain-of-title). Chan also appears as a named inventor on the related DivX DRM family ('673, '710, '183, '920 patents) — a stable, single-employer inventor group, not a scattered group of individual assignors.

Timing note (filing context): the parent application was filed 2010-11-15, roughly one month after Sonic Solutions acquired DivX (announced/closed 2010), so at the moment of filing the inventors' employer was a DivX entity inside the Sonic Solutions corporate family.

Unusual patterns: I found no evidence that any of the three inventors departed the applicant within 12 months of filing, and no evidence of an inventor-retention/consulting arrangement. The only mildly unusual artifact is that the inventors executed a fresh assignment recorded 2017-08-16 — eight years after the original 2010 filing — because a new continuation (15/615,626) had just been filed on 2017-06-06. That is chain-of-title hygiene for the new case, not an inventor-exodus signal. Do not read a fire-sale pattern into the inventor record here.

Original assignee

Entity named on the issued patent: DivX, LLC (Google Patents "Original Assignee: Divx Llc"; current assignee field also DivX LLC).

Critical distinction — there are two different legal persons called "DivX, LLC":

1. The original operational DivX, LLC — the San Diego video-codec company (formerly DivX, Inc., which IPO'd in Sept. 2006). It shipped real products embodying the technology: the DivX codec/player software and the DivX Certified device program (DivX's own ITC briefing claims "over 1 billion downloads of its software"). Primary line of business: consumer video codec/DRM software and device certification/licensing.
   • Corporate history per Netflix's filings: acquired by Sonic Solutions (2010) → Rovi (2011) → sold to Parallax Capital Partners and StepStone Group (2014) → NeuLion, Inc. (2015).
   • On 2018-02-13 this entity changed its name to NLD, LLC (per DivX v. Netflix standing record, C.D. Cal. 2:19-cv-01602, Dkt. 496/797-1).
2. The entity now owning this patent, also named "DivX, LLC" — formerly DivX CF Holdings LLC, created 2017-12-15 by Fortress Investment Group expressly to acquire the NeuLion patent portfolio. It was renamed DivX, LLC on 2018-02-12/13. Per Netflix's motion (C.D. Cal. 2:19-cv-01602, Dkt. 797-1): "Plaintiff DivX has no engineering department, employs only one engineer, is led by an attorney, and engages in litigation and patent licensing as its primary business"; it is a pass-through entity 97%-owned by DivX CF Investors LLC, whose only members are Fortress entities; Fortress personnel hold a management-committee majority and owe it no fiduciary duty.

Current status of the original operating business: dissolved into the corporate chain above — no longer an independent operating company; its software business line passed through Rovi → Parallax/StepStone → NeuLion (NeuLion itself was later acquired by Endeavor, 2019). The patents, however, did not travel with the operating business — they were carved out and sold to the Fortress entity in Feb 2018.

Assignment timeline

All dates and counterparties below are from the Google Patents legal-events record for US 10,212,486 unless otherwise noted; reel/frame attributions are flagged where the specific patent's own record does not state them.

• 2017-08-16 recorded (execution date not separately shown on the record I retrieved) — Reel/Frame not stated on the '486 legal-events entry; the portfolio chain-of-title recites Reel 042819/0871 for this link on sibling application 15/453,714. Verify on Assignment Center.

  • Conveyance: Assignment
  • Assignor: Chan, Francis Yee-Dug; Soroushian, Kourosh; Wood, Andrew Jeffrey
  • Assignee: DivX, LLC (pre-Fortress; the entity now known as NLD, LLC)
  • Correspondent: not retrievable from the sources I reviewed. (For the record: the patent's prosecution correspondence address is KPPB LLP, 2190 S. Towne Centre Place, Ste 300, Anaheim, CA 92806 — this is prosecution counsel, not confirmed as the assignment-recording correspondent.)
  • Context: routine inventor assignment executed to perfect title for the newly filed continuation.

• 2017-08-16 recorded — Reel/Frame not stated on the '486 legal-events entry; portfolio chain-of-title recites Reel 042819/0890 on 15/453,714. Verify.

  • Conveyance: Assignment
  • Assignor: DivX, LLC
  • Assignee: Sonic IP, Inc. (4790 Eastgate Mall, Suite 200, San Diego, CA 92121)
  • Correspondent: not retrievable
  • Context: internal reorganization — patents concentrated into the NeuLion subsidiary that held them.

• 2017-12-15 (execution, not a recorded assignment) — DivX CF Holdings LLC is formed by Fortress Investment Group; signatory Constantine Dakolias, then Co-CIO of Fortress Credit Funds. (Source: Netflix standing-MSJ statement, C.D. Cal. 2:19-cv-01602 Dkt. 797-1.) Not a USPTO-recorded event; included because it precedes and explains the 045310/0020 recording.

• 2017-12-18 / executed ~2018-02-16 documented — purchase agreement between DivX CF Holdings LLC and NeuLion for "certain intellectual property assets," including the asserted patents. (Netflix Dkt. 797-1.)

• 2018-02-12 executed / 2018-02-13 recorded — Reel 045310 / Frame 0020 (this reel/frame appears directly on the '486 legal-events record as REEL/FRAME:045310/0020)

  • Conveyance: Assignment
  • Assignors: Sonic IP, Inc.; DivX, LLC
  • Assignee: DivX CF Holdings LLC (New York)
  • Correspondent: not retrievable
  • Context: acquisition / transfer-to-monetizer — bulk sale of hundreds of patents and applications from NeuLion's subsidiary to a Fortress-created LLC. This is the single most consequential link in the chain.

• 2018-02-12 effective / 2018-03-05 recorded — Reel 045498 / Frame 0560

  • Conveyance: Change of Name (DivX CF Holdings LLC → DivX, LLC)
  • Assignor: DivX CF Holdings LLC
  • Assignee: DivX, LLC
  • Correspondent: not retrievable
  • Context: change of name only — but note this is the step that lets the Fortress shell adopt the operating company's name.

• 2019-02-28 recorded — no reel/frame stated for this entry

  • Conveyance: Change of Principal Place of Business (administrative, not a transfer)
  • Assignor/Assignee: DivX, LLC (record address 4350 La Jolla Village Drive, Suite 950, San Diego, CA 92122)
  • Correspondent: not retrievable
  • Context: administrative address update only.

No later conveyance is recorded. In particular, there is no assignment to RPX, AST, LOT Network, Unified Patents, or the Open Invention Network — the chain terminates at the Fortress-controlled entity.

Post-issuance litigation tied to this patent (for sequencing, not assignments):

• C.D. Cal. 2:19-cv-01602 (District) DivX, LLC v. Netflix, Inc. — complaint served 2019-03-12; '486 asserted there.
• C.D. Cal. 2:19-cv-01606 DivX, LLC v. Hulu, LLC — '486 asserted (Hulu I).
• ITC Inv. No. 337-TA-1222, Certain Video Processing Devices… — complaint filed 2020-09-10, instituted 2020-10-19; asserted patents 8,832,297; 10,212,486; 10,412,141; 10,484,749. Respondents: Samsung, LG, TCL, MediaTek, MStar, Realtek. Terminated by settlement (TCL) with the investigation terminated May–June 2022; MediaTek (2021), Realtek (2021), LG and Samsung (2021) terminated earlier.
• D. Del. 1:20-cv-01202 / 1:20-cv-01203; E.D. Tex. 2:20-cv-00301 / 2:21-cv-00264; Fed. Cir. 23-1095 and 24-2061 (appellate activity). Case captions for the Delaware and Texas matters were not verified in this review.
• Note: US 10,484,749 — asserted in the same ITC action — is a direct continuation of this patent (child of 15/615,626), so the same Fortress chain runs through it.

Timeline diagram

timeline
    title Ownership of US 10212486
    2009 : Provisional filed Dec 4
    2010 : Parent application filed by DivX LLC
         : Sonic Solutions acquires DivX
    2011 : Rovi acquires Sonic Solutions
    2014 : DivX sold to Parallax and StepStone
    2015 : NeuLion acquires DivX business
    2017 : Continuation filed Jun 6
         : Inventors assign to DivX LLC
         : DivX LLC assigns to Sonic IP Inc
         : Fortress creates DivX CF Holdings LLC
    2018 : Sonic IP assigns to DivX CF Holdings
         : DivX CF Holdings renamed DivX LLC
    2019 : Patent issued Feb 19
         : DivX sues Netflix and Hulu
    2020 : ITC complaint filed Sep 10
    2022 : ITC case terminated by settlement
    2026 : Netflix Fed Cir appeal decided

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT.
The patent moved from Sonic IP, Inc. (NeuLion's operating-family subsidiary) to DivX CF Holdings LLC, an LLC that did not exist until 2017-12-15 and was created by Fortress specifically to receive the assets — recorded at Reel 045310/0020, executed 2018-02-12. The tell here is not the name suffix but the documented facts: Fortress created it, its signatory was a Fortress Credit Funds CIO, it took in "hundreds of other patents," and it immediately renamed itself to "DivX, LLC" (Reel 045498/0560) so that it shares a name with the operating company whose inventors built the patent. Per the standing record it now has no engineering department, one engineer, an attorney as its principal, and litigation/licensing as its primary business (C.D. Cal. 2:19-cv-01602, Dkt. 797-1).

2. Known asserter in the chain — PRESENT (with attribution).
Current assignee DivX, LLC is a Fortress Investment Group vehicle. Unified Patents states this explicitly: "The '486 patent is owned by DivX, LLC, a subsidiary of well-known NPE, Fortress Investment Group" (unifiedpatents.com, 2020-06-24), and its Patroll contest page describes the '486 as "asserted in district court cases by DivX LLC (an NPE)." DivX, LLC itself does not appear on the classic Acacia / Marathon / IV / IPNav / Wi-LAN lists — the chain has no traditional NPE brand — but the Fortress-backed assertion vehicle is the relevant comparator, and both Unified Patents and RPX have docketed this campaign. Characterization is the vendors'; the underlying facts (ownership by DivX CF Investors LLC, a Fortress entity) are from the opponent's stipulated-to standing record.

3. Repeat correspondent across the chain — UNVERIFIED / INSUFFICIENT DATA.
I could not retrieve the correspondent of record for any of the four recordings (042819/0871, 042819/0890, 045310/0020, 045498/0560) and therefore cannot test the recurrence signal. What I can document is separate and should not be conflated with assignment correspondents: prosecution correspondence address of record is KPPB LLP (Anaheim, CA); DivX's IPR counsel is Lowenstein & Weatherwax LLP (Kenneth J. Weatherwax, Reg. No. 54,528; 1880 Century Park East, Suite 815, Los Angeles); DivX's ITC counsel is Mintz Levin Cohn Ferris Glovsky and Popeo. Whether any of these filed the assignment recordations is not established. This is the one signal where a properly formed NPE hunt should go back to Assignment Center and pull the "correspondent" field on all four reel/frame entries.

4. Cascading transfers — PRESENT.
Four recorded changes of title within roughly seven months (2017-08-16 → 2017-08-16 → 2018-02-13 → 2018-03-05), three of them touching this specific patent, plus the unrecorded Dec 2017 formation of the recipient. The 2018-02-12/13 assignment at 045310/0020 was a bulk transfer of hundreds of patents, and the follow-on 045498/0560 name change was recorded within three weeks. That compression — combined with the immediate rebranding of the acquirer as "DivX, LLC" — is the classic cascade signature.

5. Pre-litigation transfer — NOT PRESENT on the stated 6-month test (but relevant context).
The transfer to DivX CF Holdings LLC (045310/0020, 2018-02-12/13) predates the first infringement suit against Netflix (complaint served 2019-03-12) by ~13 months, outside the 6-month window. The ITC complaint came ~31 months later. So on the literal test: not present. Substantively, however, the purchase agreement of late 2017/early 2018 was acquisition-for-assertion — the buyer was created for the purchase and the entity has no product revenue. Flagging the distinction rather than forcing the box.

6. Bankruptcy fire-sale — NOT PRESENT.
No Chapter 7/11 anywhere in the chain. The transfers were ordinary M&A (Sonic Solutions → Rovi) followed by private-equity carve-outs (Parallax/StepStone, NeuLion) and finally an IP-asset purchase agreement between NeuLion and DivX CF Holdings dated ~2017-12/2018-02. This is a negotiated portfolio divestiture, not a bankruptcy sale.

7. Privateering — UNCLEAR / NOT ESTABLISHED.
The transferor (NeuLion/Sonic IP) was an operating company that sold the patents outright to a hedge-fund entity, which then asserted them broadly against third parties. There is no evidence in the sources I reviewed that NeuLion retained a royalty or beneficial interest such that the assertions were run "on the operating company's behalf." Absent that, this is a monetization sale rather than classic privateering. Marking unclear rather than guessing.

8. Defensive aggregator — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN. The opposite is documented: Unified Patents attacked this patent (Patroll contest on the '486; IPR2019-01379, which Unified lost, not appealed). The patent remains owned by the Fortress vehicle and is still being asserted (Netflix litigation active into 2026; the Fed Cir decided the '588 appeal, 24-1541, on 2026-02-13). This patent has not been neutralized.

Verdict

NPE — high confidence.

The dispositive facts are corporate, not nominal: this patent's title was conveyed on 2018-02-12/13 at Reel 045310/0020 from Sonic IP, Inc. to DivX CF Holdings LLC, an entity created on 2017-12-15 by Fortress Investment Group solely to hold the purchased portfolio, then renamed DivX, LLC three weeks later at Reel 045498/0560 — adopting the operating company's name. The resulting owner does not make anything (no engineering department, one engineer, attorney-led, litigation and licensing as its primary business; 97% owned by a pass-through Fortress entity, per the undisputed standing record in C.D. Cal. 2:19-cv-01602, Dkt. 797-1), and it has asserted the patent against Netflix, Hulu, Samsung, LG, TCL, MediaTek and Realtek — ITC Inv. 337-TA-1222 and multiple district-court actions. That satisfies two strong signals (shell-entity/monetization transfer + Fortress-backed asserter confirmed by Unified Patents) plus cascading transfers. The one gap worth closing before treating this as final is the correspondent of record on the four recordings, which I could not retrieve — pull those fields at the links below.

Verification:

• USPTO Assignment Center — search patent 10,212,486: https://assignmentcenter.uspto.gov/
• Alternate index: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events (reel/frame 045310/0020 and 045498/0560 appear in this record): https://patents.google.com/patent/US10212486/en
• Unified Patents PATROLL contest on the '486: http://patroll.unifiedpatents.com/contests/y389QTG6iwxnecqtK

If you want me to keep going: the highest-value next step is a same-day pull of the correspondent field on Reel 042819/0871, 042819/0890, 045310/0020 and 045498/0560, cross-checked against the correspondents on the sister patents US 10,484,749 and US 11,102,553 (both share this priority date) — if a single firm or attorney filed all of them, that is the repeat-correspondent finding, and it would move signal #3 from unverified to present across the whole Fortress–DivX family.

I'll research US patent 10212486 and its prior art citations. Let me start with several searches.

Let me research additional key cited references.

Prior-Art Analysis — US 10,212,486 B2

1. Patent identification (literal)

Because the patent is a continuation of a chain rooted in a 2009‑12‑04 provisional, prior art must predate that date to qualify under §102(a)/(b) (or have an earlier effective filing under §102(e)/AIA‑style §102(a)(2)).

2. The claims to be tested

Only two independent claims exist: claim 1 (playback device) and claim 15 (method), which are substantively parallel. Both require:

1. a container file with video data having a plurality of partially encrypted frames, each containing encrypted portions and unencrypted portions;
2. a set of cryptographic information per frame = cryptographic material + a "block reference" that identifies the encrypted portion;
3. providing each frame, its cryptographic material, and its block reference from a parser to a video decoder;
4. identifying the encrypted portion using the block reference;
5. deciphering a frame key from the cryptographic material;
6. decrypting the encrypted portion based on the frame key at the video decoder; and
7. decoding for rendering.

Notable dependents: claim 2/16 (unsecured channel), 3/17 (block reference = offset and length), 4/18 (DRM component), 5–6/19–20 (frame key restricts playback to a particular user), 7 (streaming), 8–10/21–23 (build cryptographic payload delimited by an identifier the decoder uses to extract), 11–12 (insert payload at the front of each frame), 13/24 (encrypted portion = frame header), 14/25 (unencrypted portion = frame header).

3. Important methodological caveats (please read before relying on this)

• The Google Patents record for US 10,212,486 lists 669 cited references. The authoritative text supplied to me reproduces only the first ~70 of those (through US 5,828,370). I therefore cannot enumerate "each" citation; I focus, as instructed, on the most relevant references — the ones whose disclosures actually bear on the claim language above. Any reference outside the visible subset is not covered here.
• Anticipation is a legal conclusion requiring element‑by‑element comparison against a single reference. Everything below is a technical relevance assessment ("potentially anticipates / is pertinent to"), not a legal opinion of invalidity.
• Where I could not verify a citation's bibliographic data from live sources, I say so explicitly rather than guess.

4. Most relevant cited prior art

A. US 5,805,700 A — the single most on‑point cited reference

• Full citation: Policy based selective encryption of compressed video data, US 5,805,700 A; inventors David W. Aucsmith, Joseph M. Nardone, Keith L. Shippy; assignee Intel Corporation.
• Dates: filed 1996‑10‑15; granted 1998‑09‑08.
• Disclosure (verified): A formatter selectively encrypts "basic transfer units" (BTUs) of compressed video in accordance with an encryption policy, so that the stream is partially encrypted — some data encrypted, the rest left in the clear — while achieving degradation approximating full encryption. In an MPEG embodiment, "all BTUs containing either the start code for a group of pictures or the start code for a particular frame are encrypted"; alternatively, "a fraction of the BTUs of an I‑frame, and a fraction of the BTUs of a P‑frame are encrypted." Selected BTUs are encrypted "employing a stream cipher technique." Source: https://patents.google.com/patent/US5805700 and US5805700 PDF.
• Claim relevance:
  • Potentially anticipates / strongly pertinent to claim 1 & 15 on the "plurality of partially encrypted frames, wherein each partially encrypted frame contains encrypted portions and unencrypted portions of data" element (the encrypted BTUs vs. unencrypted BTUs within frames).
  • Pertinent to claims 13/24 and 14/25 (encrypted portion and unencrypted portion each comprising a frame header / start code).
  • Weaker on the "block reference" and "frame key deciphered at the decoder from cryptographic material" elements. The '700 patent's policy is applied at the formatter/encryptor; it does not clearly describe transporting, per frame, a block reference (offset/length) together with wrapped cryptographic material across a parser→decoder boundary. So it is unlikely to anticipate claim 1 standing alone in full, but it is the closest cited art on the "partial frame encryption" core.

B. US 2004/0081333 A1 / US 7,295,673 B2 (Grab) — most on‑point on the "block reference" element; expressly incorporated by reference

• Full citation: Method and system for securing compressed digital video, US 7,295,673 B2; inventors Eric W. Grab and Adam H. Li; assignee DivX, Inc. Published as US 2004/0081333 A1.
• Dates: provisional 60/420,500 filed 2002‑10‑23; non‑provisional filed 2003‑07‑08; granted 2007‑11‑13; pre‑grant publication 2004‑04‑29.
• Disclosure (verified): Encrypts "selected parts of selected frames" in accordance with a frame encryption function, producing a protected stream containing both encrypted frames and unencrypted frames, synchronized with "frame decryption information." The decryption flow (Fig. 8 of the publication) expressly: parses each received frame → looks up corresponding frame decryption information → "determine intra‑frame offset and size of encrypted portion and identify corresponding encrypted portion of frame" → "identify appropriate decryption key from frame decryption information" → "decrypt encrypted portion of frame using identified decryption key." The specification states the frame decryption information includes "data distinguishing the encrypted frames from the unencrypted frames." Sources: https://patents.google.com/patent/US7295673 and US20040081333A1 PDF.
• Claim relevance:
  • Potentially anticipates claims 1 & 15, element by element, for the offset‑and‑size "block reference" + frame decryption key + decrypt‑only‑the‑encrypted‑portion + decode elements.
  • Directly pertinent to claims 3/17 (block reference comprises offset and length information) — this is a near‑verbatim match ("intra‑frame offset and size").
  • This reference is expressly incorporated by reference into US 10,212,486's own specification ("in the manner described in U.S. Pat. No. 7,295,673 to Grab et al."), so it is part of the intrinsic record framing the claimed "frame keys."
  • Practical significance: Grab‑333 is the same reference used against this patent family in PTAB proceedings — in IPR2020‑00511 (Netflix v. DivX, US 9,184,920) the Board/Federal Circuit focused on whether "Grab‑333 teaches obtaining encrypted content at the frame level" and partial‑frame encryption/decryption performed at the frame level (Ex. 1007). See the Petitioner's Response on remand: https://www.docketalarm.com/cases/PTAB/IPR2020-00511/... That confirms Grab‑333's frame‑level partial encryption is the art of record for this family.

C. US 5,621,794 A (Fujitsu) — pertinent to length/offset metadata and partial frame encryption

• Full citation: Moving-picture encipherment method and system, and enciphered moving-picture decipherment method and system; inventors M. Matsuda, N. Torii, T. Hasebe, N. Iwayama, M. Takenaka; assignee Fujitsu Limited.
• Dates: JP priority 1994‑12‑06; US filed 1995‑08‑21; granted 1997‑04‑15.
• Disclosure (verified): Encodes intra‑ and inter‑frame data, divides encoded frames into data blocks of predetermined length, determines whether a block contains a predetermined part of an intra‑coded frame, and enciphers only those blocks — outputting a stream containing "the data block of moving‑picture data which was enciphered and the data block of moving‑picture data which has not been enciphered" (i.e., partially encrypted frames). It adds length information indicating the data length of the enciphered moving‑picture data and "determination information" at the beginning of the data block. Source: https://patents.google.com/patent/US5621794.
• Claim relevance:
  • Pertinent to claims 1 & 15 ("partially encrypted frames … encrypted portions and unencrypted portions").
  • Pertinent to claims 3/17 — explicit length information for the enciphered data (a de facto offset/length block reference).
  • Pertinent to claims 9/22 — "determination information … at a beginning of the data block" (identifier/prefix positioning before the encrypted data).
  • Does not, on its face, describe wrapping a frame key and transporting it interleaved into an elementary bitstream demultiplexed from a container — so it is stronger on the partial‑encryption/offset signal and weaker on the "parser→decoder cryptographic‑material transport" signal.

D. Sony/Candelore partial‑encryption family — pertinent to intra‑frame partial encryption (claims 13/14)

• Full citation (representative): US 7,848,520 (Partial encryption storage medium) and the Sony "content distribution for multiple digital rights management" family published as WO 2004/023717 (Korean grant KR 10‑1250615 B1, examiner‑cited art including US 5,805,700 A). These reflect the Candelore‑style partial encryption where selected macroblocks/slices ("star pattern") of an encoded frame are encrypted while the remainder is left unencrypted.
• Dates: Sony partial‑encryption priority runs from 2002‑09‑09 (US 60/409,675) and similar, all well before 2009‑12‑04.
• Disclosure: encrypting only selected portions (macroblocks/slices) of the encoded frame while other portions remain in the clear — i.e., frames that are partially encrypted, with the encrypted/unencrypted split located by slice/macroblock position.
• Claim relevance: pertinent to claims 1 & 15 and 13/24, 14/25 (encrypted vs. unencrypted portions within a frame; encrypted/unencrypted "frame header" variations). This is the classic §102/§103 art for "partial encryption of an encoded frame."
• Confidence note: I confirmed the content of this family from the cited Korean grant and the IPR record (Ex. 1105 "Candelore‑I," star‑pattern slice encryption), but I was not able to verify every US serial number in that family (e.g., the exact identity of US 7,848,520) from live sources in this session. Treat the specific US number as unverified; the technical teaching (partial/selective macroblock encryption) is well established.

E. Other cited references that may be pertinent but on which I have lower confidence

These appear in the citation list (directly or via the parent patent US 8,781,122) but I did not independently verify their full bibliographic data or disclosure scope, so I flag them as leads to investigate, not conclusions:

• US 2007/0255940 A1 (Ueno, Transmitting apparatus and receiving apparatus) — patentability lead for interleaving key/crypto metadata into a transmitted stream.
• US 2009/0097644 A1 (Haruki, Playback apparatus and playback control method) — lead for playback‑side decryption of partially protected content.
• US 2004/0105549 A1 (Suzuki, Key management system and multicast delivery system) and US 2003/0035545/46 A1 (Jiang, ciphering‑configuration / key‑lifetime) — leads for key‑delivery/DRM wrapping (claims 4/18, 5–6/19–20).
• US 7,036,779 / US 7,151,831-style Candelore grants — frequently cited in this DivX family; identity not confirmed here.

5. Summary by claim

6. Bottom line

The strongest cited prior art against US 10,212,486 is US 7,295,673 B2 / US 2004/0081333 A1 (Grab, DivX) for the "block reference = intra‑frame offset and size" + frame‑decryption‑key elements (claims 1, 3, 15, 17), and US 5,805,700 (Intel) plus US 5,621,794 (Fujitsu) for the "partially encrypted frames with encrypted and unencrypted portions" element (claims 1, 13, 14, 15, 24, 25). The claimed "transport of enciphered cryptographic material interleaved into an elementary bitstream that is provided from a parser to a video decoder over an unsecured channel" (claims 2, 8–12, 16, 21–23) is the aspect least clearly met by the visible cited art — consistent with DivX's own framing that this family's novelty lies in protecting the data on an unsecured connection rather than the connection itself.

Caveats restated: (i) this is a technical relevance screen, not a §102 legal opinion; (ii) only ~70 of the 669 cited references were available to me, so this is not exhaustive; (iii) the exact identity of the Sony/Candelore US grant (US 7,848,520) and several 2007–2009 US application publications could not be independently verified and should be confirmed against USPTO/Google Patents before use.

I'll analyze the prior art cited on this patent's page and supplement with searches for the key references and their contents.

Let me gather more of the cited prior art and check for any PTAB/litigation record on this patent family.

Obviousness Analysis — U.S. Patent 10,212,486 B2

"Elementary Bitstream Cryptographic Material Transport Systems and Methods"

Analyst note on scope. This analysis is built on the "Prior Art" section of the Google Patents record for US 10,212,486 B2 (https://patents.google.com/patent/[US10212486B2](/patent/US10212486B2)/en), i.e., the "Citations (669)" list, the "Cited By (9)" list, and the "Families Citing this family (56)" list, plus the references the patent itself incorporates by reference. Important caveat: the citations list rendered on the page was truncated after the earliest entries (through roughly U.S. 5,822,524, filed 1995). I can therefore fully verify only the pre‑1998 portion of the 669 references. Every reference I rely on below is either (a) explicitly visible in that list, (b) incorporated by reference in the '486 specification, or (c) visible in the "Families Citing" table — and each is flagged accordingly. Where I could not confirm presence in the 669 list, I say so.

I. Governing framework

Under Graham v. John Deere and KSR Int'l v. Teleflex, the question is whether the differences between the claimed subject matter and the prior art would have been obvious to a person of ordinary skill in the art ("POSITA") at the December 4, 2009 priority date, in view of the scope/content of the prior art, the differences, the level of ordinary skill, and any objective indicia. As of 2009, the POSITA here is a person with a bachelor's degree in EE/CS (or equivalent) and several years of experience in digital video compression, container formats (AVI, MKV, MP4), and content protection/DRM.

The field is very crowded. The same family has been litigated extensively (E.D. Tex. 2:20‑cv‑00301 and 2:21‑cv‑00264; D. Del. 1:20‑cv‑01202/01203; C.D. Cal. 2:19‑cv‑01602/01606; ITC 337‑TA‑1222; CAFC 23‑1095, 24‑2061), and related DivX patents have been the subject of IPRs (e.g., IPR2020‑00511 on U.S. 9,184,920; IPR2020‑00614 on U.S. 7,295,673), where partial‑frame encryption and frame‑level decryption teachings were combined successfully (see the Petitioner briefs at docketalarm.com and the exhibit at courtlistener.com). That record itself evidences that the constituent techniques were known.

II. The claims to be analyzed

Claim 1 (independent, device): a playback device with (1) processors and (2) non‑volatile storage containing a playback application configured to:

• (a) receive a container file with video data at a parser;
• (b) extract portions with the parser, the container file comprising video data with a plurality of partially encrypted frames, each frame having encrypted and unencrypted portions, plus a set of cryptographic information for each frame comprising (i) cryptographic material for the encrypted portion and (ii) a block reference that identifies the encrypted portion;
• (c) provide the frame + the cryptographic material + the block reference from the parser to a video decoder;
• (d) identify the encrypted portion using the block reference;
• (e) decipher a frame key for each frame using the cryptographic material;
• (f) decrypt the encrypted portion using the frame key with the video decoder; and
• (g) decode the decrypted frame for rendering.

Claim 15 is the method counterpart of claim 1 (same elements). Dependents add: unsecured channel (2, 16); offset and length in the block reference (3, 17); DRM component to decipher the frame key (4, 18); frame key encrypted to restrict playback to a particular user (5/6, 19/20); streaming (7); building a cryptographic payload of crypto material + block reference (8, 21); payload delimited by an identifier and decoder extraction using the identifier (9/10, 22/23); inserting the payload at the front of each demultiplexed partially encrypted frame (11, 12); encrypted portion = frame header (13, 24); unencrypted portion = frame header (14, 25).

III. Prior art inventory (from the page's prior-art section and the specification)

IV. Grounds of rejection

Ground 1 — Claim 1 (and 15) obvious over Grab '673 in view of Nardone '700

Grab '673 is not merely art — it is expressly incorporated by reference into the '486 specification for the frame‑key aspects, which makes it an admission of like subject matter and squarely available. Its Fig. 8 flow ("determine intra‑frame offset and size of encrypted portion … identify appropriate decryption key … decrypt") reads almost verbatim on the "block reference + decipher frame key + decrypt" steps; its offset+size teaching maps directly onto claim 3's "offset and length information."

Motivation to combine (KSR rationales):

1. Common field and problem — both address protecting compressed/encoded video delivered to a playback device while minimizing processing/bandwidth cost (Nardone: "a fraction of the processor cycle cost"; Grab: bounded‑bandwidth decryption, ~3% of data).
2. Predictable result / known technique improving similar device — selecting which portions of frames to encrypt per a policy (Nardone) is a known way to reduce cost; applying it to Grab's frame‑level encryption/decryption engine yields nothing more than the expected combination of frame‑level partial encryption with per‑frame offset/size decryption information.
3. Reasonable expectation of success — both operate on MPEG‑compressed video and both already contemplate decryption preceding decode at the receiving device; the integration is a matter of routine design.
4. Explicit commercial pressure — the '486 Background admits the "high‑value … unencrypted … bitstream" problem over the demux‑to‑decoder path, providing a concrete reason to keep crypto control in the bitstream.

Ground 2 — Claims 4, 18 (DRM component) and 5/6, 19/20 (frame key restricted to a user) over Ground 1 further in view of Ginter '900

Ginter '900 teaches distributing protected content together with cryptographic material and managing keys/wrap keys so that only an authorized device/user may render it — i.e., a digital rights management component performing deciphering/key management, and keys that are themselves encrypted so as to restrict playback to a particular user or device (claim 5/6). The '486 spec itself describes the DRM portion as containing a frame key that is "encrypted in a way that only enables playback by a particular device and/or user," confirming this is the known mode of operation. Motivation: key wrapping/encryption of content keys for user‑restricted delivery was a ubiquitous, well‑documented DRM practice; combining it with Ground 1 yields predictable results. Witten '648 (video media security/tracking) provides corroborating evidence of content‑carried rights/usage control.

Ground 3 — Claims 2, 16 (unsecured channel) over Ground 1 further in view of Boebert '766 (and the '486 admission)

Claim 2/16 merely recites that the parser delivers the partially encrypted frames (and crypto material/references) to the decoder over an unsecured channel. Boebert '766 teaches trusted‑path/data‑enclave handling of cryptographic material across untrusted components — the principle of not relying on channel security. Combined with the '486 Background's own admission that the demux→decoder channel was the exposure point, a POSITA would have secured the payload rather than the link. This is a design choice with predictable effect and thus obvious.

Ground 4 — Claims 8–12 and 21–23 (payload construction, identifier delimiting, decoder extraction, insertion at the front of each frame) and claims 3, 17 (offset + length)

The Sony/Candelore partial‑encryption family (e.g., U.S. 7,773,750; 7,139,398; and "Elementary Stream Partial Encryption," U.S. 7,124,303 / pub. US 2003/0081776 A1) expressly discloses (i) video encryption pointers that identify the encrypted portions of partially encrypted video and that "include … a starting offset and a number of bytes"; and (ii) keeping start‑of‑frame/slice headers unencrypted so a standard decoder can still locate frame boundaries and compute byte offsets (directly on point for claims 13/14, 24/25, and for locating the encrypted block). Inserting a signaling/pointer payload ahead of the associated frame in the elementary stream, and having the decoder parse it, is the standard MPEG "user data"/reserved‑start‑code technique — which the '486 specification itself describes as leveraging a format‑defined element the decoder simply ignores ("a MPEG‑4 compliant decoder discards frames that contain a reserved start code identifier").

Caveat: I could not confirm from the truncated 669‑item list that these Sony/Candelore references are among the references cited on the '486 face. If they are, Ground 4 is very strong; if not, they remain available as analogous art and should be added to the record by citation. The block‑reference/offset‑length limitation (claim 3/17) is independently supplied by Grab '673 even without them, and frame‑header handling (claims 13/14, 24/25) is supplied by Nardone '700 (which encrypts BTUs containing frame/GOP start codes) and by Candelore's clear‑header teachings.

Ground 5 — Claim 7 (streaming the container file)

Streaming/progressive delivery of container‑file content to a player was conventional and is reflected elsewhere in the DivX record (e.g., U.S. 7,519,274 and U.S. 8,472,792 in the "Families Citing" table, and the DivX portfolio's progressive‑playback work). No independent significance attaches to streaming in claim 7; it is a known delivery mode for the same container file, and obvious in view of the stated purpose of distributing content over networks.

V. Claim‑by‑claim disposition

VI. Objective indicia and counter‑arguments to expect

• No teaching away. Nardone and Grab both advocate encrypting less, not more; the claimed frame‑level partial encryption is the same design principle, so there is no teaching away from the combination.
• Secondary considerations. Patent Owner will likely point to commercial success of DivX players, licensing, and copying by accused infringers (Hulu, and parties in the E.D. Tex./D. Del./ITC actions). However, the nexus is weak because the asserted features (partial frame encryption, offset/size references, frame keys, container transport) were individually known; such indicia should be discounted absent a nexus to the specific combination, and in any event are litigated in the parallel proceedings rather than being established here.
• "Block reference" — Patent Owner's likely fallback is that the reference must identify the encrypted portion within the encoded frame (not merely identify an encrypted packet). Grab '673's "intra‑frame offset and size of encrypted portion" neutralizes this argument; the PTAB's construction discussions in the parallel IPRs (e.g., construing "frame encryption function" broadly to cover sub‑frame units such as slices/macroblocks — see the DivX v. Hulu exhibit) support the broad reading.
• "Deciphering a frame key using cryptographic material" (key wrapping) — no single cited reference in the visible portion uses that exact vocabulary, but the combination of Grab's frame−decryption−key teaching with conventional, standards‑based key wrapping (AES key wrap of small key blocks was well established by 2009) supplies it; Ginter provides the DRM key‑delivery framework. This element is the most amenable to a § 103 argument rather than a single‑reference showing.

VII. Confidence and open items

• High confidence: Grab '673 is incorporated by reference into the '486 specification and discloses frame‑level partial encryption with an offset/size block reference, a decryption key, and decoder‑side decrypt‑then‑decode. Nardone '700 is cited on the face of the '486 and teaches policy‑based selective encryption of MPEG compressed video in a container. Ground 1 is a strong § 103 combination for claims 1 and 15.
• Medium confidence: mapping of Ginter '900, Boebert '766, Witten '648, and Fujitsu '794 to the dependent claims. Their subject matter is as I have described, but their precise involvement in the '486's own 669‑item citation list (versus the parent's list) should be re‑verified.
• Unverified: whether the Sony/Candelore partial‑encryption family (U.S. 7,773,750; 7,139,398; 7,124,303; 7,151,831; 7,336,787) and the MPEG user‑data/SEI insertion practice appear in the '486 record. I could not confirm this from the truncated citations view and have flagged it rather than assume it.
• Recommended next step: re‑run this analysis against the complete 669‑reference list from the '486 front page (the rendered page cut off at ~U.S. 5,822,524), and cross‑check the reference lists of the co‑family members U.S. 8,781,122, 9,124,773, 9,706,259, 10,484,749, 11,102,553 and 12,184,943, which share the same priority and will collectively identify the secondary references (container formats, DEMUX/decoder transport, key wrapping) that bear on the dependent claims.