US 7386046

I'll verify the patent against live sources, with particular attention to current litigation status and any 2026 CAFC activity.

Let me check the PTAB outcomes for the '046 patent and any 2026 appellate activity.

Let me pin down the IPR outcomes and check for any 2026 appellate activity.

US Patent 7,386,046 B2 — Analyst Summary

Verification note: I searched for the exact number 7386046 only. All results below are for U.S. Patent No. 7,386,046 B2 (application 10/076,013). I did not rely on similarly numbered patents (e.g., the continuation U.S. 8,073,047, the '610, '535, '477, '907, or '897 patents appear below only where they are legally relevant to the '046).

1. Bibliographic data

Documentary discrepancy, not corrected: the '046 specification recites provisional 60/268,394, while the continuation US 8,073,047 B2 as rendered in search results recites provisional 60/268,364. I report both literally as found; I have not independently confirmed which is the correct filing receipt (OCR error is plausible).

2. Abstract (verbatim)

"Data compression and decompression methods for compressing and decompressing data based on an actual or expected throughput (bandwidth) of a system. In one embodiment, a controller tracks and monitors the throughput (data storage and retrieval) of a data compression system and generates control signals to enable/disable different compression algorithms when, e.g., a bottleneck occurs so as to increase the throughput and eliminate the bottleneck."

Source: https://patents.google.com/patent/US7386046/en

3. Plain-language overview of the independent claims

The specification's "Summary" discloses four inventive aspects, and litigation records confirm at least claim 1 (method) and claim 40 (system) as independent claims. I do not have the complete printed claim set, so the claim count and any additional independent claims are stated with that caveat.

Claim 1 — Method claim (col. 20:14–32)

Plain language: A four-step method —

1. Compress data with a first compression routine that has a first compression rate (and a first algorithm).
2. Track the throughput of the data processing system to see whether that first rate satisfies a predetermined throughput threshold — where the tracking is specifically counting a number of pending requests for data transmission (i.e., backlog depth, not a bandwidth measurement per se).
3. If the threshold is not met, switch to a second compression routine/algorithm whose compression rate is greater than the first, in order to bring system throughput back up to at least the threshold.
4. (Implied by the "compressing … using a second … routine" step) continue compressing with the faster routine.

The narrowing hook is the "tracking throughput comprises tracking a number of pending requests for data transmission" clause. Court records reveal this limitation was treated by the Board as a point of novelty distinguishing the prior art (see §4).

Claim 40 — System claim (col. 27:25–28:10)

Plain language: A system comprising —

1. A data compression system that compresses and decompresses input data.
2. A plurality of compression routines selectively usable by that system, a first routine using a first compression algorithm and a second routine using a second compression algorithm.
3. A controller that tracks throughput and issues a control signal to select a compression routine based on throughput — where the tracked throughput is the number of pending access requests to a storage device (the storage-controller embodiment, rather than the transmission embodiment of claim 1).
4. When the controller determines throughput is below a predetermined threshold, it commands the compression engine to use a routine with a faster rate of compression so as to increase throughput.

Specified aspects likely reflected in dependent claims (from the Summary)

• The first routine is a default asymmetric routine and the second is a symmetric routine.
• Processing a user command to load a user-selected compression routine.
• Accepting a user command to compress data and automatically selecting a routine associated with the data type of that data (the "access profiles" 1/2/3 table: write-few/read-many → slow-compress/fast-decompress; write-many/read-few → fast-compress/slow-decompress; balanced → symmetrical).

Architectural gist

The patent's insight is a feedback loop: compression algorithm selection is made a function of measured system backlog (I/O queue depth), trading compression ratio for execution speed only when a bottleneck actually appears, and reverting to the slower, higher-ratio algorithm when the backlog clears. The companion disclosure covers the virtual-disk/GOB file-system layer (Superblock, Virtual Block Table, sector maps, data block headers, dynamic virtual disk sizing).

4. Post-grant proceedings and litigation status

PTAB (all on the '046 patent, per Google Patents "Family has litigation" and independent dockets):

Judicial treatment of the '046: The Federal Circuit's August 23, 2024 opinion in Realtime Adaptive Streaming L.L.C. v. Sling TV, L.L.C. (No. 23-1035, 113 F.4th 1354) recounts that Realtime pointed to "a Board decision finding that the related '046 patent's 'tracking throughput' limitation was a point of novelty used to distinguish the prior art." The panel held that even so, such a Board decision "establish[es] that the throughput limitation was known in the prior art" but "does not mean it was well-understood, routine, and conventional" at Alice step two. The '046 patent itself was not the patent held § 101-ineligible in that case — the invalidated patent was the '610.

District court dockets naming the '046 (from Unified Patents / Google Patents litigation metadata) include D. Del. 1:17-cv-01519, -01520, -01692 (Netflix), -01693; D. Colo. 1:17-cv-02692, -02869, 1:18-cv-00927, -01046, -01048, -01173, -01175, -01177, -01345, -01446; C.D. Cal. 2:17-cv-07611, 2:18-cv-03629, 2:18-cv-09344, 2:19-cv-06361, 8:18-cv-00942; E.D. Tex. 6:18-cv-00215; D. Mass. 1:18-cv-10355; W.D. Tex. 6:19-cv-00441. Claim 1 of the '046 was used as the representative claim in the D. Del. Netflix matter, and claim 40 in the D. Del. Haivision matter.

5. Explicit "no result" finding on 2026 CAFC dockets

I found no 2026 Federal Circuit docket naming U.S. Patent 7,386,046. The nearest-in-time Federal Circuit activity surfaced was:

• No. 25-1529, Realtime Adaptive Streaming LLC v. Sling TV, L.L.C., Sling Media, L.L.C., DISH Network L.L.C. et al. (a 2025 docket, apparently the continuation of the fees dispute remanded by No. 23-1035).
• No. 26-1271 / 26-1287 — these are VidStream-related briefs, unrelated to the '046.

This null result is consistent with the patent having reached its adjusted expiration on 2023-04-04 and being recorded as Expired – Fee Related, which removes it as a live infringement cause of action. My search tools may not surface very recent 2026 filings reliably, so I flag this as a limits-of-search statement rather than a certified absence.

6. Confidence and uncertainty statement

• High confidence: title, inventors, application number, filing date, issue date, priority date, abstract, assignees, and the claim 1/claim 40 text (quoted in two separate Delaware opinions).
• Moderate confidence: status of IPR2019-01033 (petitioner's appeal apparently resolved in Realtime's favor — the "no challenged claims unpatentable" FWD plus a 2023-01-09 Federal Circuit mandate on the docket strongly suggest affirmance, but I did not retrieve the Rule 36 judgment itself); and the petitioner identity for IPR2019-00209.
• Not verified: the complete list of claims and total claim count; whether the ¶101 challenge to the '046 claims in the C.D. Cal./D. Del. cases succeeded or failed; and whether the provisional number is 60/268,394 or 60/268,364.
• One procedural footnote: the source snapshot supplied for the full patent text is timestamped 2026-09-28, which post-dates the April 26, 2026 date given for this task; I used it as the authoritative document but note the inconsistency.

I'll research this. Let me start with the litigation data already associated with this patent and then verify/expand with targeted searches.

Good grounding. Let me dig deeper into the specific cases, PTAB proceedings, and appeals.

Let me get the litigation list from the patent-specific portal and confirm the PTAB outcomes.

Litigation Involving U.S. Patent No. 7,386,046 ("the '046 patent")

Bottom line: Yes — the '046 patent was heavily litigated. It was one of the patents asserted by Realtime Adaptive Streaming LLC (and its affiliate Realtime Data LLC d/b/a IXO) in a large 2017–2018 infringement campaign against the consumer-electronics, streaming, and networking industries. It was also the subject of at least three inter partes reviews (IPRs) at the PTAB and appears in the appeal history at the Federal Circuit.

One important framing note: the '046 patent sits in the same family as several siblings (U.S. Pat. Nos. 8,867,610; 8,929,442; 8,934,535; 9,762,907; 9,769,477; 8,634,462; 9,578,298). Most of the Realtime suits asserted several of these together, so many dockets list the '046 patent alongside siblings. Below I distinguish cases where the '046 patent was affirmatively asserted from broader family litigation.

1. District court actions where the '046 patent was asserted

The clearest contemporaneous record is the Patent Owner's Mandatory Notice filed in IPR2019-00209 (Realtime's own list of pending cases involving the '046 patent):

Additional cases reported (via aggregated docket data, search patent:(7386046)) as involving the '046 patent:

Also confirmed via the complaint itself: Realtime Adaptive Streaming LLC v. Apple Inc., D. Colo. 1:17-cv-02869 (Apple complaint expressly pleads infringement of the '046 patent; the action was dismissed by order of Judge R. Brooke Jackson on 10/12/2018). The RPX litigation news item (12/02/2017) documents the Apple filing and the parallel Netflix/Sony filings.

I also note the JPML MDL No. 2845 decision, In re Realtime Adaptive Streaming LLC Patent Litig., 326 F. Supp. 3d 1374 (J.P.M.L. Aug. 1, 2018), which denied Realtime's motion to centralize. The '046 patent is expressly named as one of the eight patents at issue, and Schedule A lists the then-pending actions (Hulu 2:17-cv-07611; Sling TV 1:17-cv-02097; Polycom 1:17-cv-02692; Apple 1:17-cv-02869; Brightcove 1:17-cv-01519; Haivision 1:17-cv-01520; Netflix 1:17-cv-01692; Sony 1:17-cv-01693; Adobe 1:18-cv-10355; Amazon 6:17-cv-00549; Cisco 6:17-cv-00591; Samsung 6:18-cv-00113). Caveat: the MDL decision identified these as the family-wide set; it does not itemize which of them asserted the '046 patent specifically, so I am not representing that every Schedule A case asserted the '046 patent.

2. PTAB — Inter Partes Review of the '046 patent

There is also a reference in PTAB petition papers to IPR2019-01393 in connection with the '046 patent (denial of institution and denial of rehearing), but I could not confirm that association with confidence — flagging as unverified.

3. Federal Circuit appeals (from the patent-page litigation record)

The Google Patents record for this patent lists the following CAFC matters under "family has litigation": 21-1545, 21-2268, 21-1519, 21-1485, 21-1484, 20-2281.

Important caveat: That family-litigation list is family-wide; I could not confirm in the time available which of these appeals actually concern the '046 patent's own claims. For example, 21-2268 is Realtime Adaptive Streaming LLC v. Sling TV, L.L.C., which the Federal Circuit decided on the '610 patent (invalidity under §101, affirmed May 11, 2023) and the '535 patent IPR — not the '046 patent. So do not assume every listed CAFC docket is an '046 appeal.

4. Disposition / current status

• The '046 patent expired on 2023-04-04 (adjusted expiration; "Expired – Fee Related" for failure to pay maintenance fees), per the patent record.
• Realtime's district-court campaign against the '046 patent largely wound down through voluntary/joint dismissals (e.g., the Brightcove and Sony actions were dismissed by joint motion in late 2018; the Apple case was dismissed on 10/12/2018). Several D. Colo. cases are flagged in docket data as "TERMED" or "STAYED."
• In the one '046 IPR that reached a Final Written Decision identified here (IPR2019-01033, Google), no challenged claims were held unpatentable — a win for Realtime — although the broader corporate campaign suffered adverse §101 rulings on sibling patents ('535, '610) in parallel cases.

Sourcing and reliability notes

• Patent identity: US 7,386,046 B2, "Bandwidth Sensitive Data Compression and Decompression," app. 10/076,013, filed 2002-02-13, priority 2001-02-13, granted 2008-06-10; original assignee Realtime Data LLC; current assignee Realtime Adaptive Streaming LLC. (https://patents.google.com/patent/US7386046/en)
• IPR2019-00209 Mandatory Notice listing the five '046 suits (D. Del. Haivision and Netflix; C.D. Cal. Adobe and Google/YouTube; D. Colo. Comcast).
• In re Realtime Adaptive Streaming LLC Patent Litig., 326 F. Supp. 3d 1374 (J.P.M.L. 2018) — MDL denied (https://www.courtlistener.com/opinion/[7331679](/patent/7331679)/in-re-realtime-adaptive-streaming-llc-patent-litig/).
• Realtime Adaptive Streaming LLC v. Netflix, Inc., No. 17-1692-CFC-SRF (D. Del. Dec. 12, 2018) — R&R naming the '046 patent among the Fallon patents.
• IPR2019-01033 outcome — "Judgment Final Written Decision Determining No Challenged Claims Unpatentable," 11/10/2020 (https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2019-01033).
• IPR2019-01280 — Comcast v. Realtime Adaptive Streaming (https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2019-01280).
• Apple case dismissal — D. Colo. 1:17-cv-02869 docket (https://portal.unifiedpatents.com/litigation/Colorado%20District%20Court/case/1:17-cv-02869).

Caveats on things I could not fully verify: exact filing dates and terminal outcomes for several D. Colo./E.D. Tex. cases; which CAFC dockets specifically concern the '046 patent; and the outcome of IPR2019-00209. The D. Colo. and E.D. Tex. case lists come from aggregated docket aggregators rather than primary PACER records, so treat case-specific dates and dispositions as needing confirmation against PACER/Unified Patents dockets. I did not locate the litigation list at the specific Unified Patents caselist URL you cited, so I used the patent page's litigation data, the JPML opinion, PTAB filings, and docket aggregators instead.

I'll research the PTAB proceedings referenced in this patent's litigation history.

Let me dig into the specific proceedings and their outcomes.

⚠️ Data-integrity flag before the analysis

The structured "PTAB proceedings on file" block says the USPTO ODP API returns no AIA trial proceedings for US 7,386,046. That conflicts with the patent's own record: the Google Patents page for this patent carries a "Family has litigation" entry listing three PTAB cases — IPR2019-01033, IPR2019-00209, and IPR2019-01280 — and web-search sources (GreyB/IPVerse, RPX Insight, Docket Alarm, PTAB E2E) confirm all three exist and name the '046 patent. Treat the ODP block as an ingestion gap, not as evidence of no PTAB activity. I found no PGR or CBM on this patent.

Proceedings overview

Three AIA trials were filed against US 7,386,046 — all IPRs, all by large technology defendants — and the verified claim-level outcomes break down as: claims sustained 1 / claims invalidated 0 / settled-or-terminated with no cancellation 2; no claim of this patent was canceled in any proceeding I can verify, and the one fully documented FWD (Google) expressly held claims 1 and 23 not unpatentable. Bottom line for a defendant today: the patent is PTAB-hardened on the claims that were tested, not PTAB-killed — but that is largely academic, because the '046 patent expired 2023-04-04 (expired-fee-related per the patent record), so the real defensive posture is "no prospective infringement; past-damages-only exposure, and the IPR record shows a well-funded petitioner already failed on the merits of claims 1 and 23."

IPR2019-01033 — Google LLC and YouTube LLC v. Realtime Adaptive Streaming LLC

• Type: Inter Partes Review (35 U.S.C. §§ 311–319)
• Filed: 2019-05-06 (Petitioner real parties in interest: Google LLC and YouTube LLC)
• Status: Final Written Decision — judgment: "Final Written Decision Determining No Challenged Claims Unpatentable" (35 U.S.C. § 318(a)), entered 2020-11-10. Plain English: Petitioner lost; the challenged claims survived.
• Judge panel: Georgianna W. Braden, Gregg I. Anderson, and a third APJ whose surname is truncated in the public copies I retrieved (the caption reads "Before GEORGIANNA W. BRADEN, GREGG I. ANDERSON, and KEVIN W. …"). I will not guess the third name.
• Petition grounds (per the FWD's own challenge table):
  • Claims 1 and 23 — § 103(a) over Kiel
  • Claims 1 and 23 — § 103(a) over Kobata in view of Kiel
• Institution decision: Instituted (granting institution of inter partes review under § 314(a) of all challenged claims on all proposed grounds) on 2019-11-13. The Board was initially persuaded a skilled artisan would have been motivated to modify Kiel's process to select between compression algorithms based on queued tasks (Inst. Dec. at 30).
• Final Written Decision: Claim-by-claim verdict — claim 1: NOT shown unpatentable. Claim 23: NOT shown unpatentable. The FWD states verbatim: "we determine Petitioner has not shown by a preponderance of the evidence that claims 1 and 23 of U.S. Patent No. 7,386,046 B2 are unpatentable." The dispositive dispute was claim construction of "tracking throughput … comprises tracking a number of pending requests for data transmission": Patent Owner (and its expert Dr. Zeger) argued, and the Board ultimately accepted, that Kiel's "processor tasks" (task queue T_Q) are a processor-workload metric, not a count of pending requests for data transmission; Petitioner's own reply only argued the tasks were "linked with" such requests, which the Board found insufficient. No independent or dependent claim was canceled.
• Settlement / termination: No settlement; the case ran to a merits FWD.
• Appeal: Yes — Google LLC v. Realtime Adaptive Streaming LLC, No. 2021-1545 (Fed. Cir.). The appeal was from PTAB No. IPR2019-01033; argued by Naveen Modi (Paul Hastings) for Google and Paul A. Kroeger (Russ August & Kabat) for Realtime. Disposition: AFFIRMED, per curiam (Lourie, Prost, Taranto, JJ.), entered 2022-06-15, issued under Fed. Cir. R. 36 (nonprecedential; no opinion). See the Rule 36 judgment reproduced on the PTAB docket: https://www.docketalarm.com/cases/PTAB/IPR2019-01033/Google_LLC_v._Realtime_Adaptive_Streaming_LLC/docs/01-09-2023-Board/ ; CourtListener mirror: https://www.courtlistener.com/opinion/[6477827](/patent/6477827)/google-llc-v-realtime-adaptive-streaming/ . The estoppel/FWD record: FWD at Docket Alarm — https://www.docketalarm.com/cases/PTAB/IPR2019-01033/Inter_Partes_Review_of_U.S._Pat._7386046/docs/11-10-2020-Board/Termination_Decision_Document-33-Judgment_Final_Written_Decision_Determining_No_Challenged_Claims_Unpatentable.pdf
• Defensive value: This is the best-documented defense win for the patent owner and the most important fact for you. Claims 1 and 23 were tested on the strongest § 103 art Google could assemble (Kiel, Kobata+Kiel) and survived both the Board and a Federal Circuit appeal. An invalidity theory aimed at claim 1 or 23 built on Kiel or Kobata is now affirmatively foreclosed as to Google/YouTube and their privies by § 315(e)(2) estoppel, and is a poor bet for anyone else. Note that independent claim 1 and claim 23 are the "tracking throughput = pending transmission requests" claims; claim 40 is the parallel system claim that was not part of this IPR.

IPR2019-00209 — Netflix, Inc. (with Hulu, LLC and Netflix Streaming Services, Inc.) v. Realtime Adaptive Streaming LLC

• Type: Inter Partes Review
• Filed: 2018-11-11 (Petition Paper 2; supporting Declaration of James A. Storer, Ph.D.)
• Petitioner real parties in interest: Netflix, Inc.; Netflix Streaming Services, Inc.; and Hulu, LLC (per the Board's decision text).
• Status: Google Patents' litigation docket lists this case as reaching Final Written Decision status. The public document set also contains a Board "Decision Denying Request for Rehearing — Petitioner." ⚠️ I could not independently verify the claim-level disposition of this FWD from the sources I retrieved, and I will not represent what it held. What I can state: no source I found shows any claim of the '046 patent being canceled in this proceeding.
• Judge panel: Not confirmed from the sources retrieved.
• Petition grounds: The Board's June 2019 document addresses claims 27, 29–32, 34, and 35 of the '046 patent. ⚠️ I could not confirm from the retrieved text whether that list is the complete challenged set or a subset addressed in the decision, and I could not confirm the specific prior art or the § 102/§ 103 split. Do not represent these as the full challenged set.
• Institution decision: Not confirmed. (The mere existence of a "Decision Denying Request for Rehearing — Petitioner" is consistent with either a denial-of-institution that went to rehearing, or a post-decision rehearing request; the record I have does not resolve which.)
• Final Written Decision: Listed as entered per the Google Patents PTAB docket, but claim-level verdict not verified — I will not state that any claim was canceled or sustained.
• Settlement / termination: The joined proceeding (below) terminated 2020-05-27, which is the same effective end-point a parent FWD or termination would produce for the joinder. Whether the parent ended by FWD, settlement, or termination is not confirmed in the materials I retrieved.
• Appeal: Not confirmed for this proceeding.
• Defensive value: Read this as "Netflix/Hulu did not kill the '046 patent." Treat the proceeding as non-invalidating until you pull the FWD from PTAB E2E yourself (search case IPR2019-00209 → "Final Written Decision"). Because a FWD appears to have been entered, § 315(e)(2) estoppel applies to Netflix, Netflix Streaming Services, Hulu, and their privies, but the ground set is unverified.

IPR2019-01280 — Comcast Cable Communications, LLC v. Realtime Adaptive Streaming LLC

• Type: Inter Partes Review filed as a joinder to the earlier Netflix IPR on the '046 patent (Google's Patent Owner Preliminary Response expressly states: "Another defendant, Comcast, elected to join that IPR (see IPR2019-01280) — even though Comcast was sued a month later than Google.")
• Filed: 2019-06-27
• Status: Google Patents docket lists Final Written Decision status; third-party dockets (GreyB/IPVerse) list institution 2019-12-10 and termination 2020-05-27. ⚠️ A termination roughly 5.5 months after institution and ~6 months before the 12-month statutory deadline is not a merits FWD on its face — it is consistent with the parent proceeding ending (FWD, settlement, or termination) and the joinder being closed with it. I could not confirm which, and I will not state a claim-level outcome.
• Judge panel: RPX Insight lists the panel as including Christa P. Zado plus four others ("+4"); the additional names are not confirmed.
• Petition grounds: Presumed to mirror the Netflix parent proceeding's grounds (joinder practice requires substantially the same grounds); not independently verified.
• Institution decision: Joinder granted 2019-12-10 (per RPX Insight / GreyB).
• Final Written Decision: Listed on the Google Patents docket; verdict not verified.
• Settlement / termination: Terminated 2020-05-27 (per RPX Insight / GreyB). Character of termination (settlement vs. closure on parent's decision) not confirmed.
• Appeal: None found attributable to this docket.
• Defensive value: Comcast's joinder did not cancel any claim on any record I could verify. Its practical significance is pattern evidence: a third large defendant (Comcast) joined rather than filing fresh art, and the challenge still ended without a documented cancellation.

Strategic summary

Claim status of the '046 patent. Verified: claims 1 and 23 are SUSTAINED — the Board held Google/YouTube failed to prove them unpatentable, and the Federal Circuit affirmed (Fed. Cir. R. 36, 2022-06-15). Verified-adjacent: the Board at some point found the '046 patent's "tracking throughput" limitation was a point of novelty used to distinguish the prior art (relied on by Realtime in the parallel Sling TV / DISH appeal as proof of non-conventionality). Target of unverified challenges: claims 27, 29–32, 34, and 35 (IPR2019-00209) and claims 1 and 23 (IPR2019-01033); claim 40 (the system claim) and the balance of the claim set appear UNTESTED at the PTAB. No claim of '046 was canceled in any proceeding I can verify.
The single most important claim-status fact, though, is not a PTAB fact: per the patent record, the '046 patent is "Expired – Fee Related, expires 2023-04-04." No prospective infringement is possible for acts after that date; any live theory is a past-damages theory subject to the § 286 six-year lookback and the fact that cancellation of claims, had it occurred, would have wiped out even that.

Estoppel landscape. § 315(e)(2) estoppel attaches only to petitioners that reached a Final Written Decision: Google LLC and YouTube LLC (IPR2019-01033 — barred from re-asserting Kiel and Kobata+Kiel, and any ground they raised or reasonably could have raised); Netflix, Inc., Netflix Streaming Services, Inc., and Hulu, LLC (IPR2019-00209, if the FWD is confirmed — barred on the art they used, unverified); and Comcast Cable Communications, LLC (IPR2019-01280 — likely barred as a joined petitioner/FWD party, unverified). For you, if you are not a privy of those three, you are not estopped, but you are also not helped: Kiel and Kobata were already run and failed against claims 1 and 23. Practical takeaway — a § 103 attack on claim 1 or 23 needs art outside the Google/Netflix/Comcast sets, and § 325(d)/§ 315(e) discretion plus the FWD's claim-construction reasoning ("number of pending requests for data transmission" ≠ generic processor workload) will make that road steep. Depending on the forum, a § 101 attack may be the more realistic lever (Realtime's related '535/'610 patents drew § 101 scrutiny in district court), but note the Federal Circuit's repeated correction of over-broad § 101 rulings against this family.

Pattern signals. (1) Multiple large defendants, multiple IPRs, zero cancellations on this patent: Netflix/Hulu (IPR2019-00209), Comcast by joinder (IPR2019-01280), and Google/YouTube (IPR2019-01033). (2) The patent owner litigated to FWD and to the Federal Circuit and won — Realtime is not a patent owner that folds at the PTAB; it took the Google FWD up on appeal and the affirmance came down in its favor. (3) No defensive aggregator on this patent. Unified Patents does appear in the broader Realtime IPR chain (e.g., IPR2017-02129, IPR2018-00883) but on other Realtime patents, not the '046. (4) The broader campaign context is heavy — dozens of district-court suits across Realtime Data LLC → Realtime Adaptive Streaming LLC — which is exactly the profile of a patent that attracts repeat PTAB filings; the fact that three landed on the '046 and none won is the signal.

Recommended next steps

1. Pull the two FWDs I could not verify. Go to PTAB E2E / PTAB Decisions and open IPR2019-00209 and IPR2019-01280; the FWDs are public. Read the Judgment caption ("Determining All Challenged Claims Unpatentable" vs. "…No Challenged Claims Unpatentable") and the claim-by-claim conclusion. Do not rely on the Google Patents "Final Written Decision" label alone — it denotes case status, not outcome. The one FWD I did verify is Google's: https://www.docketalarm.com/cases/PTAB/IPR2019-01033/Inter_Partes_Review_of_U.S._Pat._7386046/docs/11-10-2020-Board/Termination_Decision_Document-33-Judgment_Final_Written_Decision_Determining_No_Challenged_Claims_Unpatentable.pdf — quote its disposition directly: "we determine Petitioner has not shown by a preponderance of the evidence that claims 1 and 23 of U.S. Patent No. 7,386,046 B2 are unpatentable."
2. Verify the expiration. Confirm on USPTO Patent Center that the '046 patent lapsed for non-payment of maintenance fees effective 2023-04-04. If so, that is your lead argument: no prospective infringement; the assertion is a legacy past-damages claim only. Pair it with the Google FWD to show that even the pre-expiration claims 1 and 23 were held valid over the best art a FAANG-scale petitioner could muster.
3. Handle the § 101 angle deliberately. Because the § 103 road on the tested claims is closed/poor, explore § 101 — but briefing on Realtime's related patents shows the Federal Circuit has been skeptical of district-court § 101 invalidity findings against this family (it vacated a Delaware § 101 judgment and reminded the court to address Realtime's Enfish, Visual Memory, DDR Holdings citations). A § 101 motion must engage Alice Step Two on the "tracking throughput" limitation, not just assert abstractness.
4. Map estoppel before you file anything. If you are a customer, supplier, or partner of Google/YouTube, Netflix/Hulu, or Comcast, assume you may be a privy for § 315(e)(2) purposes and that the Kiel/Kobata grounds are unavailable to you. If you are independent of them, you still start behind because those grounds already lost — budget for new art, and consider whether IPR2019-01033's claim-construction reasoning is worth attacking on appeal-proof grounds.
5. No active trials to watch. All three proceedings are closed (latest documented activity: the '046 docket entry of 2023-01-09 recording the Federal Circuit Rule 36 judgment in No. 2021-1545). There are no trial-stage milestones pending — no institution deadline, no oral hearing, no § 316(a)(11) FWD due date on this patent.

Caveats on sourcing: proceeding numbers, petitioner identities, filing dates, institution dates, panels, and claim lists are drawn from the patent's PTAB docket entries plus GreyB/IPVerse, RPX Insight, and Board documents linked above. The IPR2019-01033 FWD and the Federal Circuit disposition are fully verified. The claim-level verdicts of IPR2019-00209 and IPR2019-01280 are NOT verified in this report and are expressly flagged as such — do not treat "no cancellation found" as "the FWD found the claims patentable" until you read the two decisions yourself.

I'll research the assignment record for US 7386046 through multiple sources.

Let me dig deeper into the specific assignment records, correspondent attorneys, and litigation history.

Let me find the assignment cover-sheet correspondents and the exact reels for the '046 patent itself.

I've gathered enough from the patent record itself, Google Patents legal events, Espacenet INPADOC, PTAB filing excerpts, and EchoStar's SEC 10-K disclosures. Note upfront: I could not retrieve the attorney/agent correspondent of record for either recording, and I could not pull the exact reel/frame for the inventor→Realtime Data recording on the '046 patent itself — those are flagged as data gaps below rather than filled in.

Inventors

The patent (Appl. No. 10/076,013, filed 2002‑02‑13) claims priority to provisional 60/268,394, filed 2001‑02‑13.

Unusual-pattern check — none matching the "inventors flee" tell. Both inventors remained named on the long chain of Realtime Data continuations through at least 2019 (e.g., US 9,769,477 and US 10,212,417, both listing Fallon/McErlain). There is no evidence of inventors departing the original assignee within 12 months of filing; if anything the opposite — Fallon is the recurring inventor-principal across the entire portfolio. One minor oddity: the inventors' assignment was executed in August 2002 but apparently not recorded until 2006 (Google Patents legal event dated 2006‑09‑08), i.e., a ~4‑year recordation lag.

Original assignee

Realtime Data LLC (New York). It is listed on the face of the issued patent (issued 2008‑06‑10) and in Google Patents as the original assignee.

• Line of business: Data compression / "accelerated data storage and retrieval" ("storewidth") technology; the specification (FIG. 3) describes a DSP-based storage controller. The company also did business as "Realtime Data, LLC d/b/a IXO" and became one of the most prolific patent plaintiffs in the U.S.
• Did it ship a product embodying the claims? Not established. Realtime Data marketed compression/acceleration concepts, but I found no evidence of a commercially shipped product practicing the '046 claims; the entity's dominant visible activity is licensing/litigation.
• Current status: Operating as an entity (it survived long enough to be the assignor in the 2017 transfer and to keep filing its own suits in 2018–19). No bankruptcy found. It is the transferor, not the current owner.

Assignment timeline

Two recorded assignments are reflected for this patent. Reels for the second link are confirmed; the reel for the first link is only confirmable family-wide (flagged).

• Executed 2002‑08‑02 to 2002‑08‑07 / recorded 2006‑09‑08 — Reel not independently confirmed for the '046 (the identical Fallon/McErlain→Realtime Data recording appears in the family at 030877/0211 and 031267/0357 for sibling cases)

  • Conveyance: Assignment
  • Assignor: Fallon, James J.; McErlain, Stephen J.
  • Assignee: Realtime Data, LLC (New York)
  • Correspondent: Not retrievable from available sources — data gap, not a finding.
  • Context: founder/founding-inventor assignment of rights to the original operating assignee (the "original owner" link, not a transfer).

• Executed/effective 2017‑03‑07 / recorded 2017‑03‑14 — Reel 041573/0683

  • Conveyance: Assignment
  • Assignor: Realtime Data LLC
  • Assignee: Realtime Adaptive Streaming LLC (Tyler, TX)
  • Correspondent: Not retrievable from available sources — data gap, not a finding. (The PTAB ownership statement for Realtime Adaptive Streaming filed Dec 2017 bears an attorney signature "Michael V."; I could not confirm this as the recording correspondent and do not rely on it.)
  • Context: transfer-to-asserter — the portfolio is moved out of the original entity into a licensing-only plaintiff LLC on the eve of an assertion campaign.

Google Patents' legal-events tab for US 7,386,046 independently reflects both events (2006‑09‑08 → Realtime Data LLC; 2017‑03‑14 → Realtime Adaptive Streaming LLC). No security agreement, license, merger, or correction records were found for this patent.

Search link for verification: https://assignment.uspto.gov/patent/index.html (search 7386046) and https://assignmentcenter.uspto.gov/.

Timeline diagram

timeline
    title Ownership of US 7386046
    2002 : Inventors assign rights to Realtime Data
    2006 : Inventor assignment recorded
    2008 : Patent issued
    2017 : Assigned to Realtime Adaptive Streaming
         : Infringement suits filed against Netflix
    2019 : Unified Patents IPRs filed
    2023 : Patent expired fee related

NPE / troll-pattern signals

1. Shell-entity transfer — PRESENT. Reel 041573/0683 (eff. 2017‑03‑07, rec. 2017‑03‑14) moved the patent from Realtime Data LLC to Realtime Adaptive Streaming LLC, Tyler, TX — the Texas venue favored in EDTX patent cases. The licensing-only character is not inferred from the name: EchoStar's SEC 10-K states verbatim that "Realtime Adaptive Streaming is an entity that seeks to license an acquired patent portfolio without itself practicing any of the claims recited therein." That is a hard, non-naming-based corroboration.

2. Known asserter in the chain — PRESENT. The current assignee, Realtime Adaptive Streaming LLC, and its predecessor Realtime Data LLC (d/b/a IXO) are high-volume plaintiffs that appear on Unified Patents' tracked lists; Unified Patents maintains a dedicated page for this patent (portal.unifiedpatents.com/patents/patent/US‑7386046‑B2) and filed IPRs against the family (IPR2018‑00883, IPR2019‑00209, IPR2019‑01033, IPR2019‑01280). This is corroboration by third-party defensive filings, not by naming.

3. Repeat correspondent across the chain — UNCLEAR (data gap). I could not retrieve the correspondent of record for either recording; the sources I could access do not expose it. I am declining to name a firm rather than infer one. To close this, pull the two cover sheets directly from the Assignment Center.

4. Cascading transfers — NOT PRESENT. The chain is a two-link structure (inventors → Realtime Data LLC → Realtime Adaptive Streaming LLC) spanning ~15 years, not multiple chained LLCs within 24 months.

5. Pre-litigation transfer — PRESENT (borderline). Transfer effective 2017‑03‑07; Realtime Adaptive Streaming's first '046 assertions were filed in the D. Del. cluster on 2017‑11‑21 (Netflix, C.A. 17‑1692), 17‑1519 (Brightcove), 17‑1520 (Haivision), 17‑1693 (Sony). That is ~8.5 months — slightly outside the strict 6‑month window, so I flag the timing, but the transfer plainly exists to install a clean non-practicing plaintiff ahead of the campaign.

6. Bankruptcy fire-sale — NOT PRESENT. No Chapter 7/11 by Realtime Data LLC; the 2017 event is a portfolio assignment, not a court-supervised sale.

7. Privateering — UNCLEAR. The classic pattern (operating company → NPE to assert against competitors) does not cleanly apply, because the transferor, Realtime Data LLC, was itself a licensing/assertion entity rather than a practicing manufacturer. However, the two entities share the Fallon lineage and asserted in parallel (Realtime Data d/b/a IXO kept filing its own suits in 2018–19 while Realtime Adaptive Streaming ran the "Fallon patents"), which is consistent with a coordinated split of one assertion portfolio.

8. Defensive aggregator — NOT PRESENT. The chain terminates at Realtime Adaptive Streaming LLC, an active plaintiff; it does not land at RPX, AST, LOT, Unified, or OIN. The patent was attacked by Unified Patents, not acquired by it.

Verdict

NPE — high confidence.

The chain terminates at a licensing-only Texas LLC (Reel 041573/0683, effective 2017‑03‑07), and the non-practicing character is established by EchoStar's own 10-K admission rather than by the LLC's name. Within months the assignee launched a multi-defendant '046 campaign (Netflix 17‑1692, Brightcove 17‑1519, Haivision 17‑1520, Sony 17‑1693, all Nov 2017), and third parties (Unified Patents, IPR2018‑00883 / IPR2019‑00209 / ‑01033 / ‑01280) treated the family as assertion-grade prior art. Two or more strong signals are present (shell-entity transfer + known asserter, reinforced by the pre-assertion transfer), which meets the high-confidence bar. Residual caveats: the correspondent of record and the '046-specific reel for the 2006 inventor assignment remain unverified.

I'll research US Patent 7,386,046 and its prior art citations. Let me search for it.

Let me get the specific citation list from the patent's front page and Google Patents.

Let me retrieve the citation list from Justia and the patent PDF front page.

Important caveat up front

I was able to confirm the patent's identity and part of the prosecution record, but I was not able to retrieve the complete "References Cited" (front-page citation) list for US 7,386,046 through the searches available to me. The Google Patents and Unified Patents snippets returned the patent's body text, family members, and a large aggregated "Patent Art (322)" listing, but not the discrete § 102/§ 103 references printed on the patent's face.

Per the operating rules, I will not fabricate reference numbers, titles, or dates to fill that gap. Below I separate what I confirmed, what I partially confirmed, and what I could not verify.

1. Patent under analysis (confirmed)

Sources: https://patents.google.com/patent/US7386046/en ; https://portal.unifiedpatents.com/patents/patent/US-7386046-B2

2. Prior art I could confirm (from the prosecution record)

A PTAB petition document in the 7,386,046 family reproduces an Examiner's action rejecting the family's claims 1–17. Critically, every rejection was under 35 U.S.C. § 103(a) (obviousness) — not § 102 (anticipation):

Source: https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1525841](/patent/1525841)/download-documents?artifactId=O1Nw7z0L7XMqYquRYEO1IuLVHoR0nSnpTidwdWepBZHvY-ZmrCre2Ls#33#30

Why this matters for your § 102 question: Because these were cited in § 103 combinations, none of them individually anticipates the claims. Under § 102 a single reference must disclose every limitation. The Examiner's use of two- and three-reference combinations is an implicit finding that no single reference discloses all elements (e.g., Hasegawa alone lacked the throughput-threshold/faster-second-routine teaching, supplied by Craft). So an accurate answer to "which claims does reference X anticipate under § 102?" is: on the record retrieved, none of these references was applied as a § 102 anticipation; all were § 103 obviousness grounds.

I was unable to verify the exact title, assignee, or publication date of US 5,191,431, US 5,557,551, and US 6,104,389 from the retrieved results, so I am not stating those fields as fact.

3. References I partially confirmed (family / art listings) — treat with caution

The Unified Patents page for US‑7,386,046‑B2 lists a "Patent Art (322)" set. This count (322) is far larger than a typical front-page citation list and appears to be an aggregation of art across the Realtime Data family and its litigation — not necessarily the references printed on the 7,386,046 face. I therefore cannot represent these as "the citations of 7,386,046." Samples that appeared, with the dates/assignees as returned:

• US 4,682,150 A — 1985-12-08 — Teledata Sound — "Data Compression Method and Apparatus"
• US 5,621,820 A — 1994-03-02 — Autodesk — "Video Data Compression Method and System Which Measures Compressed Data Storage Time to Optimize Compression Rate"
• US 5,394,534 A — 1992-09-10 — "Data compression/decompression and storage of compressed and uncompressed data on a same removable data storage medium"
• US 5,832,126 A — 1995-07-06 — Oki Electric — "Method and Apparatus for Compressing Mixed Text and Image Data"
• US 6,091,777 A — 1997-09-17 — Cubic Video Technologies — "Continuously Adaptive Digital Video Compression System and Method for a Web Streamer"
• US 6,601,104 B1 — 1999-03-10 — Realtime Data LLC — "System and Methods for Accelerated Data Storage and Retrieval"
• US 6,856,651 B2 — 2000-07-24 — Riverbed Technology — "System and Method for Incremental and Continuous Data Compression"

Source: https://portal.unifiedpatents.com/patents/patent/US-7386046-B2

Thematically closest to the "bandwidth-sensitive" concept among these is US 5,621,820 (Autodesk), because it measures compressed-data storage time to optimize the compression rate — i.e., a feedback loop between measured system performance and compression-parameter selection, which is the core of claim 1/claim 11. It would be a natural candidate for a § 102 or § 103 challenge, but I have not verified its full disclosure and therefore cannot assert that it discloses every element of any claim.

4. Claim set to be mapped (confirmed from prosecution text)

• Claim 1 — method: compress with a first routine at a first rate; track system throughput to determine whether it meets a predetermined threshold; if not, compress with a second routine at a higher rate to raise throughput to the threshold.
• Claim 11 — system: data compression system; a plurality of compression routines; controller that tracks throughput and generates a control signal to select a routine based on throughput.
• Claim 13 — depend on 11, adds plurality of access profiles keyed to data type.
• Claim 14 — depend on 11: throughput = pending access requests to a storage device.
• Claim 15 — depend on 11: throughput = pending transmission requests over a communication channel.
• Claim 16 — program storage device embodying the method steps.
• Claim 17 — program storage device for accelerated data storage.
• Claim 18 (new/added later) — method: first algorithm on a communications channel; track channel throughput; switch to faster second algorithm.
• Related family claims add the "input transmission rate greater than storage rate / compression rate ≥ ratio" limitation.

The independent claims (1, 11, 16, 17) are the meaningful § 102 battleground; the dependent claims (13, 14, 15, 18) narrow toward access profiles, storage-controller pending requests, and transmission-controller pending requests.

5. What I could not verify (stated explicitly)

1. The complete printed "References Cited" list on the 7,386,046 front page. Not retrieved.
2. Titles / assignees / exact dates of US 5,191,431, US 5,557,551, US 6,104,389, and the "Kadnier" reference. Not verified.
3. The specific prior-art grounds in IPR2019-00209, IPR2019-01033, and IPR2019-01280 (petitioner, institution decision, final written decision, and the art relied on). I identified that the IPRs exist but could not retrieve their grounds. These IPR records would be the single most probative source for "most relevant prior art" and should be pulled directly.
4. Whether the "322" Unified Patents items include any of the actual face-of-patent citations.

6. Recommended next steps to complete the request

To produce the discrete, per-reference § 102 analysis you asked for, the following should be retrieved directly (I could not access them here):

1. Google Patents → US7386046B2 → "Patent Citations" and "Cited By" tables (the tables exist on the page but did not surface in my result snippets).
2. USPTO Patent Center / Patent Application 10/076,013 "Documents" tab — the "References Cited" / PTO-892 forms give the authoritative citation list.
3. PTAB PTAB-2019-00209, IPR2019-01033, IPR2019-01280 petitions and FWDs for the operative prior-art grounds.
4. The examiner's citations in the two continuation applications (Ser. Nos. 12/123,081 → US 8,073,047 and 12/132,399 → US 8,054,879), which share the 7,386,046 specification and typically reuse the same art.

If you can supply the PTO-892 / Google Patents citation table, I can map each reference element-by-element against claims 1, 11, 16, and 17 and state precisely which claims, if any, are Anticipated (single-reference, § 102) versus Obvious (§ 103 combinations).

Bottom line: Based only on what I could verify, the references actually applied to this family — Hasegawa (US 5,191,431), Craft (US 5,557,551), and Ando (US 6,104,389) — were applied under § 103(a), not § 102, so no confirmed single-reference anticipation exists on the retrieved record. I did not fabricate the remaining front-page citations, and I flag that they still need to be retrieved from the sources in § 6.

I'll research the prior art associated with this patent, including the cited references and the PTAB proceedings before analyzing obviousness.

Let me research the specific PTAB proceedings on this patent (IPR2019-01033, IPR2019-00209, IPR2019-01280) and the prior art cited in the patent.

Let me find the specific prior art relied upon in the IPRs challenging this exact patent.

Obviousness Analysis — U.S. Patent No. 7,386,046 B2

Methodological note up front (important): The patent text you supplied is the Google Patents rendering, and the paste truncates inside the "Description" section — it does not include the actual claim set. Likewise, my searches returned the docket records for the three PTAB proceedings on this patent (IPR2019‑00209, IPR2019‑01033, IPR2019‑01280) but not the specific ground-by-ground prior-art mappings those petitions used. I therefore reconstruct the claim scope from the patent's own SUMMARY language (which mirrors the independent claims) and draw prior art from (a) the "Patent Art"/citations listing on the patent page, and (b) references the patent itself cites and incorporates. Where I am inferring rather than quoting, I flag it. I did not fabricate claim text or grounds.

A. The invention and the claim scope to be tested

From the SUMMARY (which tracks the issued independent claims):

• System claim (claim 1):
  • (a) a data compression system for compressing/decompressing data input to the system;
  • (b) a plurality of compression routines selectively utilized by the compression system;
  • (c) a controller for tracking the throughput of the system and generating a control signal to select a compression routine based on the system throughput.
• Preferred/dependent subject matter: default asymmetric routine (slow compress/fast decompress) switched to a symmetric or fast-compress routine when throughput drops below a threshold; number of pending access requests as the tracked throughput metric; a data-transmission controller variant where pending transmission requests are tracked; access profiles / data-type-based automatic algorithm selection (file extension mapping); and a user-command mode to force a user-selected routine.

The critical inventive concept is therefore narrow: dynamically selecting among known compression algorithms according to measured system throughput (bandwidth), optionally using data type / access profile to pick the algorithm. Nothing in the claims (as summarized) requires a new algorithm, a new data structure, or a specific hardware architecture.

Key admissions in the patent's own background (applicable as AAPA): the patent states that the speed-vs-ratio tradeoff is well known; that "asymmetrical" schemes (e.g., Lempel-Ziv dictionary coding) vs. "symmetrical" schemes (e.g., Huffman) are known; and that TDM/RAID/disk bandwidth limits were longstanding problems. These admissions lower the bar for motivation to combine.

B. The prior art available on the face of the page

From the patent page's cited/Patent-Art entries and the Unified Patents prior-art listing (https://portal.unifiedpatents.com/patents/patent/US-7386046-B2), the most probative references are:

The docket record confirms this patent was challenged on §103 grounds three times (IPR2019‑00209; IPR2019‑01033; IPR2019‑01280, Comcast, inst. 2019‑12‑10, term. 2020‑05‑27; see https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2019-01280 and https://insight.rpxcorp.com/ptab/10520-...).

C. Ground 1 — Throughput-responsive algorithm selection (independent claim 1)

Combination: US 6,091,777 (Cubic) in view of US 6,195,024 / US 6,309,424 (Fallon), optionally with Nelson.

• Cubic teaches element (c) almost verbatim in spirit: a compression system that continuously adapts its compression to measured bandwidth for a streaming server.
• Fallon '024/'424 teach element (b): a compression engine that maintains a plurality of encoders and selects among them based on desired output characteristics.
• Nelson supplies the why: for a given data set, one chooses the faster/lower-ratio algorithm or slower/higher-ratio algorithm depending on whether speed or size is the binding constraint.

Motivation (KSR, predictable results): Both references sit in the same field (real-time data compression for transmission/storage). Substituting Fallon's multi-encoder selection into Cubic's bandwidth-measuring control loop is "a simple substitution of one known element for another … yielding predictable results": when bandwidth falls, pick the faster algorithm; when it is ample, pick the higher-ratio algorithm. The '046's own background concedes that the tradeoff being exploited is "well known." This mirrors the reasoning the Federal Circuit accepted for the sibling patent Realtime Data, LLC v. Iancu (Fed. Cir. Jan. 10, 2019), where the Board's finding that a POSITA "would have been motivated to turn to" known algorithms was affirmed (https://www.aipla.org/detail/news/2019/01/16/federal-circuit-affirms-data-compression-patent-invalidity; Oblon summary).

D. Ground 2 — Accelerated storage controller + runtime algorithm switch

Combination: US 6,601,104 (accelerated data storage, Fallon family, incorporated by the '046) in view of US 5,651,138 (Elonex) and/or US 6,091,777.

• The '104 teaches element (a): a storage controller that compresses in real time to increase effective storage bandwidth — the exact "storewidth" architecture the '046 describes as its preferred environment.
• Elonex '138 shows compression logic integrated with a peripheral/storage controller (controller context, DMA, etc.).
• Cubic (or a disk-bottleneck reference) supplies the throughput-monitoring trigger.

Motivation: The '046's background itself frames the problem — disk read/write rates lag behind bus rates, and a controller-level compressor can "accelerate" storage. A POSITA confronting a bottleneck (pending disk accesses) would predictably respond by temporarily switching to a faster compression routine to relieve the backlog, then reverting to the efficient routine when the queue clears. That is precisely the disclose-then-claim pattern KSR condemns ("combination of familiar elements according to known methods … when a known problem exists"). Because the '104 and '046 share a common assignee/priority lineage, a §103(c)-type common-ownership issue is worth noting, but it does not defeat obviousness where the reference predates the '046's priority and the combination is otherwise motivated.

E. Ground 3 — Data-type / access-profile selection (dependent claims)

Combination: US 5,832,126 (Oki, mixed text/image) or US 2001/0031092 A1 (Xerox) in view of any of the above.

• Oki teaches routing/selecting a compression method based on the type of content (text vs. image).
• Xerox '092 teaches content/quality-driven compression control.
• The '046's dependent subject matter — "automatically selecting a compression routine associated with a data type" (e.g., by file extension) — is squarely met by these references, and the "access profile" concept (read-heavy → slow-compress/fast-decompress; write-heavy → fast-compress/slow-decompress) is a routine design choice once the algorithm families of Nelson are available.

Motivation: automatic content classification before compression was a known optimization; a POSITA would apply it to the bandwidth-sensitive controller to minimize repeated read-time decompression (read-heavy OS/applications) or write-time compression cost (bulk database updates).

F. Why the combinations are proper under §103

1. Same field / common problem. All references address reducing effective data-movement cost through compression — the identical problem the '046's background identifies.
2. Known, finite set of options. Selecting between a slow/high-ratio (dictionary) and fast/low-ratio (Huffman/table) algorithm is a two-option design choice the specification itself describes as conventional.
3. Predictable results. Adaptive switching to relieve a throughput bottleneck yields nothing more than the expected trade-off (throughput up, ratio down) — a result-effective variable, not an inventive leap.
4. Express incorporation. The '046 incorporates the '024/'424 patents and the '394/'243 applications by reference, making their teachings part of the relevant knowledge base and directly combinable.
5. Litigation signal. The family has been held obvious in parallel proceedings (Fed. Cir. affirming the Board in Realtime Data v. Iancu, 2019), and this exact patent was subjected to three separate IPRs, showing the art was considered closely analogous/pertinent.

G. Caveats and confidence

• High confidence: the claimed subject matter (throughput-responsive selection among known algorithms; data-type-based selection) is of the kind routinely held obvious, and each functional element has a clear prior-art home in the references cited on the patent page.
• Lower confidence / unverified: I could not retrieve the verbatim claim set of US 7,386,046 nor the specific ground-by-ground art mapping from IPR2019‑00209 / 01033 / 01280. My element-to-reference mapping above is reconstructed from the SUMMARY language and the cited art, not from the issued claims. Before relying on this for any filing, one should pull the actual claims and the three IPR Final Written Decisions (and any adverse-judgment/termination reason for IPR2019‑01280, which terminated ~6 months after institution) from the PTAB docket. That termination timing may indicate a claim disclaimer or adverse judgment rather than a merits FWD, which would materially affect the §103 picture.
• Per your rules, I have not auto-corrected any identifier; all patent numbers and IPR numbers are reproduced as found.

If you can paste the actual claim set or the three IPR grounds, I can produce a limitation-by-limitation chart with pinpoint citations.