US 6597812

I'll search for the specific patent number as requested.

Let me check specifically for any 2026 CAFC activity involving this patent.

US Patent 6,597,812 — Analyst Summary

Search scope note: I searched for the exact number 6597812 / 6,597,812 and did not return results for similar numbers. The following is grounded in the sources retrieved. I did not find any CAFC docket activity for this patent in 2026 (see litigation section for details and the uncertainty caveat).

---

Bibliographic Data

Sources: Google Patents (https://patents.google.com/patent/US6597812/en); Justia (https://patents.justia.com/patent/6597812); Unified Patents portal (https://portal.unifiedpatents.com/patents/patent/US-6597812-B1).

---

Abstract (verbatim)

"Systems and methods for providing lossless data compression and decompression are disclosed which exploit various characteristics of run-length encoding, parametric dictionary encoding, and bit packing to comprise an encoding/decoding process having an efficiency that is suitable for use in real-time lossless data compression and decompression applications. In one aspect, a method for compressing input data comprising a plurality of data blocks comprises the steps of: detecting if the input data comprises a run-length sequence of data blocks; outputting an encoded run-length sequence, if a run-length sequence of data blocks is detected; maintaining a dictionary comprising a plurality of code words, wherein each code word in the dictionary is associated with a unique data block string; building a data block string from at least one data block in the input data that is not part of a run-length sequence; searching for a code word in the dictionary having a unique data block string associated therewith that matches the built data block string; and outputting the code word representing the built data block string."

---

Plain-Language Overview of the Independent Claims

The '812 patent has 30 claims. The independent claims are claim 1 (method), claim 14 (program storage device / computer-readable medium), and claim 28 (system). Based on the specification and the PTAB petition record, they cover the following:

Claim 1 — Method for compressing input data (data blocks)
A hybrid compression method that does two things in one pass:

1. Detect whether the incoming data contains a run-length sequence (a long repeat of the same byte/block). If so, emit an encoded run-length sequence.
2. For non-run data, maintain a dictionary in which every code word maps to a unique data-block string; build a string from the next data block(s), look it up in the dictionary, and output the matching code word.
   In plain terms: "use run-length coding where there are long repeats, and dictionary (Lempel-Ziv–style index) coding everywhere else, sharing one code-word dictionary."

Claim 14 — Program storage device (machine-readable medium)
The same compression method as claim 1, but embodied as a program of instructions stored on a machine-readable medium (i.e., software form). Claims 15–22 add dependent features (run-length detection threshold "s", the three-part run-length output, dictionary maintenance/initialization, etc.) in program-storage-device form.

Claim 28 — System for compressing input data
A hardware/system counterpart with three elements:

• A dictionary of code words that include control code words plus code words each mapped to a unique data-block string;
• a run-length encoder that encodes a sequence of similar data blocks using at least one dictionary code word; and
• a dictionary encoder that encodes a data-block string using a dictionary code word,
  where the outputs of the two encoders are combined into a single encoded data stream.

Key supporting (dependent) limitations worth noting:

• Claim 4: dictionary is dynamically updated — new code word generated and added when the built string doesn't match.
• Claims 5–6: dictionary is re-initialized when the number of code words exceeds a threshold; a control code word is emitted on reset.
• Claim 7: control code words represent dictionary initialization, run-length sequence, and end-of-data.
• Claim 9: bit-packing the output code words (the specification describes a shift-register that emits 16 bits from 12-bit code words, a 16/12 ≈ 1.33 improvement).
• Claim 13: a hash table of arrays used to speed dictionary search (first-byte indexing; optionally nested/multi-level hashing, 256ⁿ sub-dictionaries).

The specification also notes the encoder dictionary is always at least one step ahead of the decoder dictionary, and describes the special-case handling when the decoder receives a code word not yet in its dictionary (first and last characters of the string are the same).

---

Litigation / PTAB History (as found)

• IPR2016-00783 — SAP America, Inc. et al. v. Realtime Data LLC (filed Apr. 1, 2016; instituted). PTAB Final Written Decision Sept. 28, 2017 found claims 1–4, 8, 14–17, 21, 28 unpatentable as obvious over O'Brien (U.S. 4,929,946) alone/with Nelson, and over O'Brien + Nelson + Welch (U.S. 4,558,302).
• Federal Circuit appeal — Realtime Data, LLC v. Iancu, No. 2018-1154 (Fed. Cir. Jan. 10, 2019), affirmed the PTAB (holding no motivation-to-combine finding was required where the secondary reference (Nelson) supplied no missing element). CAFC mandate recorded Apr. 22, 2019 (IPR2016-00783, Paper 65).
• IPR2017-00167 and IPR2017-00168 — Oracle America, Inc. v. Realtime Data LLC (filed Nov. 2, 2016). Both terminated by settlement (IPR2017-00167 terminated Apr. 11, 2017; IPR2017-00168 terminated/settled).
• District court litigation — numerous E.D. Tex., N.D. Cal., and D. Del. suits (e.g., 6:15-cv-00464/00467/00469/00470; 6:16-cv-00088; 6:17-cv-00046; 3:16-cv-01836).

Sources: Docket Alarm IPR2016-00783 docket; Oblon summary of Realtime Data v. Iancu (https://www.oblon.com/realtime-data-llc-v-iancu-...); Justia/Casetext opinion text; IPWatchdog Federal Circuit Review.

---

On "CAFC 2026 dockets"

I could not find any United States Court of Appeals for the Federal Circuit docket for patent 6,597,812 dated 2026. The authoritative Federal Circuit activity I located for this patent is the 2019 Realtime Data, LLC v. Iancu, No. 2018-1154 decision, and the underlying IPRs (2016–2017), with the 2019 mandate. This is consistent with the patent being expired since 2020-05-26, which would generally leave little or no basis for new 2026 appellate activity.

Caveat / uncertainty: My search of general web and aggregated docket sources did not surface a 2026 CAFC docket for this patent, but I cannot rule out a very recent docket that is not yet indexed. Because I do not have direct, authoritative access to the CAFC's PACER/CM-ECF docket system in this session, I cannot state with certainty that no 2026 filing exists — only that none appeared in my searches. If a specific 2026 case number is of interest, I would recommend verifying directly against the Federal Circuit docket (and the PTAB/PTActs record) before relying on this negative result.

(Note: one retrieved item ties the number 6597812 to a dual-venue PTAB/District Court table from usinventor.org listing it as "INVALID/VALID" — treat such third-party validity characterizations as informational only, not as a legal conclusion.)

I'll research litigation involving US patent 6597812. Let me run several searches in parallel.

Let me dig into the specific district court cases and PTAB proceedings.

Litigation involving U.S. Patent No. 6,597,812

Patent: US 6,597,812 B1 — "System and method for lossless data compression and decompression" (Fallon et al.; assignee Realtime Data LLC, d/b/a IXO; app. 09/579,221 filed 2000‑05‑26; priority 1999‑05‑28; granted 2003‑07‑22). Status per Google Patents: Expired – Lifetime (anticipated expiration 2020‑05‑26), so no live district‑court case can presently be pending on this patent.

A note on method and reliability: the patent's Google Patents page carries a "Family has litigation" block that mixes (a) cases where the '812 patent itself was at issue and (b) family/portfolio‑level suits brought by the same plaintiff on related patents. I flag below which entries I could corroborate as specifically directed to the '812 patent and which are only listed as family litigation.

---

1. Confirmed proceedings directly on the '812 patent

A. IPR2016‑00783 (PTAB) — the principal challenge to the '812 patent

Holdings: Realtime conceded that O'Brien's encoder is a dictionary encoder; the Board found O'Brien alone disclosed every limitation of claims 1–4, 8, 28, and that claims 14–17, 21 were obvious over O'Brien + Nelson + Welch. On appeal, the Federal Circuit rejected Realtime's argument that a motivation‑to‑combine finding was required, and rejected Realtime's proposed construction of "maintaining a dictionary" (attempted to import the reset‑when‑full requirement; the court noted dependent claim 5 adds initialization "further," so it is not a mandatory element of claim 1).
Sources: https://www.courtlistener.com/opinion/[4580424](/patent/4580424)/realtime-data-llc-v-iancu/ ; https://storage.courtlistener.com/pdf/2019/01/10/realtime_data_llc_v._iancu.pdf ; https://www.oblon.com/realtime-data-llc-v-iancu-no-requirement-to-make-any-finding-of-a-motivation-to-combine-two-references-when-a-claim-is-invalid-as-being-obvious-over-a-single-reference ; http://www.finnegan.com/print/content/67130/Realtime-Data-LLC-v-Andrei-Iancu.pdf ; https://portal.unifiedpatents.com/ptab/case/IPR2016-00783

B. Oracle's IPRs on the '812 patent

Caveat: IPR2017‑00167 is expressly identified in Realtime/Unified Patents document listings as directed to U.S. Pat. No. 6,597,812 and "Terminated Apr. 11, 2017." IPR2017‑00168 appears in the same Google Patents family‑litigation block with a "Settlement" disposition, but the secondary sources I retrieved truncate its patent number, so I cannot independently confirm which patent (or which Realtime patent) it targeted. Sources: https://portal.unifiedpatents.com/patents/patent/US-6597812-B1 ; https://patentimages.storage.googleapis.com/98/3c/d8/3bb378e7dc1215/[US10284225](/patent/US10284225).pdf ; https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1526225](/patent/1526225)/download-documents

---

2. District court cases listed as '812 family litigation

These are the district‑court dockets Google Patents/Unified Patents associate with this patent family. Where I indicate uncertainty, I could not confirm from the retrieved sources that the '812 patent itself was asserted in that specific docket (Realtime's 2015 E.D. Tex. wave asserted a large portfolio of related patents, and some of these dockets appear to be portfolio‑level suits).

Sources: https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6:15-cv-00470 ; https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6:17-cv-00046 ; https://unicourt.com/case/pc-db1-realtime-data-llc-dba-ixo-v-oracle-america-inc-[385217](/patent/385217) ; https://portal.unifiedpatents.com/patents/patent/US-6597812-B1 ; https://patents.justia.com/patent/[9769477](/patent/9769477) ; https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1507077](/patent/1507077)/download-documents ; https://portal.unifiedpatents.com/litigation/California%20Northern%20District%20Court/case/3:16-cv-01836

The HP/HP Enterprise/Teradata defendants in the district‑court suits above are the same parties who filed the IPR2016‑00783 petition, which is the strongest evidence that the '812 patent was in play in the 2015–2016 E.D. Tex./N.D. Cal. dockets involving HP, SAP, and Teradata.

---

3. Important negative findings

• No litigation is known against the many unrelated defendants frequently cited in Realtime Data reporting (e.g., EchoStar/DISH, Apple, Netgear, Rackspace, Riverbed, Commvault, Dell, Acronis, Barracuda, Array Networks). Those 2016–2018 suits and their associated IPRs (e.g., IPR2017‑01627, ‑01629, ‑01688, ‑01690, ‑01710, etc.) target Realtime's other patents (e.g., 7,415,530; 9,116,908; 7,161,506; 9,054,728; 8,717,204), not the '812 patent, on the record I retrieved.
• Realtime Adaptive Streaming LLC v. DISH/Sling/Arris (E.D. Tex. and D. Colo.) and related appeals concern the Realtime Adaptive Streaming portfolio, not the '812 patent.
• The '812 patent's Google Patents page also notes the patent is Expired – Lifetime, anticipated expiration May 26, 2020, which is consistent with all '812‑specific litigation having concluded.

---

4. Explicit uncertainties

I want to be precise rather than overstate:

1. I could not, from the retrieved sources, positively confirm that U.S. Pat. No. 6,597,812 was asserted in each of dockets 6:15‑cv‑00464, ‑00467, ‑00469 and ‑00470. Google Patents lists them under "Family has litigation," and Unified Patents additionally tags 6:15‑cv‑00470 and 6:17‑cv‑00046 on the '812 patent page, but the complaints themselves were largely portfolio complaints.
2. I could not retrieve a confirmed outcome for 6:17‑cv‑00046 (Realtime Data v. Oracle America, E.D. Tex., filed Jan. 23, 2017). Given the 2020 expiry and the parallel IPR terminations (IPR2017‑00167/‑00168, Apr. 11, 2017), it was very likely dismissed or settled, but I will not state that as fact without a source.
3. The exact patent number at issue in IPR2017‑00168 is not legible in my retrieved sources; only IPR2017‑00167 is confirmed against the '812.
4. This list is limited to U.S. proceedings. I did not retrieve any ITC § 337 action, foreign litigation, or E.D. Tex. post‑2017 docket asserting the '812.

If you need a certified‑grade docket list, the authoritative next steps would be the PACER dockets for the numbers above, the USPTO Patent Trial and Appeal Board API (PTAB‑API/PTACTS) for IPR2016‑00783, IPR2017‑00167 and IPR2017‑00168, and the Federal Circuit docket for No. 18‑1154.

I'll reconcile the structured ODP block against the IPR history already surfaced, then verify claim-level outcomes via search before writing.

Let me confirm the panel, institution date, and petitioner identity for the lead IPR, plus the 2017 Oracle filing details.

Proceedings reconciliation flag (read first)

The structured "PTAB proceedings on file" block in my instructions states that the USPTO ODP API returns no AIA trial proceedings for US 6,597,812. That is contradicted by the public record and by the earlier sections of this analysis. Web search confirms at least three IPR proceedings on this patent (IPR2016‑00783, IPR2017‑00167, IPR2017‑00168), one of which produced a Final Written Decision affirmed precedentially by the Federal Circuit.

Possible explanations: (a) the ODP ingest did not capture pre‑2018 proceedings on this patent number; (b) the "no AIA activity" result reflects a query keyed to a different identifier form. Either way, I am treating the ODP block as incomplete/an erroneous negative and grounding the following in the public PTAB/CAFC record, which I have cited. If your workflow depends on the ODP negative, it should be re-run and the discrepancy reported.

Per operating rules, I am not auto-correcting any identifier — IPR2016-00783, IPR2017-00167, IPR2017-00168 and 2018-1154 are reproduced exactly as found.

---

Proceedings overview

Three AIA trial proceedings (all IPR) have been filed against US 6,597,812: one was instituted and invalidated every challenged claim, affirmed by the Federal Circuit; two were filed by Oracle America, Inc. and both were terminated by settlement on the same day at the pre‑institution stage, with no merits reached — so the ledger is 1 claims‑invalidated, 2 settled (no institution), 0 active, 0 claims sustained, 0 institution denials. Bottom-line defensive posture for a defendant today: *the patent's three independent claims — 1 (method), 14 (program storage device), and 28 (system) — plus every claim the Board reached are dead and the invalidity holding is affirmed precedential law; any demand letter that asserts claim 1, 14, or 28 is unsupportable, and a defendant's practical defense is to point at Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019), rather than to file a new IPR.*

---

IPR2016-00783 — SAP America, Inc. et al. / Hewlett-Packard Enterprise Co. v. Realtime Data LLC

(Caption note: the petition is styled "SAP America, Inc. et al. v. Realtime Data LLC"; later papers and the FWD use "Hewlett-Packard Enterprise Co. v. Realtime Data LLC." The petitioner/real‑party‑interest group included SAP America, Hewlett-Packard Enterprise entities, and Teradata Operations, Inc. This is a caption variance, not two cases.)

• Type: Inter Partes Review (pre‑AIA patent; pre‑AIA 35 U.S.C. § 103 applied)
• Filed: 2016-04-01
• Status: Final Written Decision issued — claims held unpatentable; appealed and affirmed. (Consistent with the expired‑lifetime legal status, no live trial.)
• Judge panel: Georgianna W. Braden, J. John Lee, Jason J. Chung — FWD authored by Jason J. Chung.
• Petition grounds: 35 U.S.C. § 103(a) only. Challenged claims 1, 2, 3, 4, 8, 14, 15, 16, 17, 21, 28. Two grounds were instituted:
  • O'Brien (U.S. 4,929,946) + Nelson (The Data Compression Book (1992)) → § 103(a) as to claims 1–4, 8, 28;
  • O'Brien + Nelson + Welch (U.S. 4,558,302) → § 103(a) as to claims 14–17, 21.
  • Petitioner also relied on the Declarations of Dr. Charles D. Creusere.
• Institution decision: Instituted 2016-10-05 on both grounds above. The Board's institution analysis turned on "maintaining a dictionary": it found no express construction necessary because O'Brien taught every step of that limitation as recited in dependent claim 4.
• Final Written Decision: issued 2017-09-28. Verdict, quoting the FWD's disposition: "Petitioner has shown by a preponderance of the evidence that claims 1–4, 8, 14–17, 21, and 28 of the '812 patent are unpatentable." Reasoning in brief: the panel agreed with the patent owner's own framing that O'Brien alone disclosed every limitation of claims 1–4, 8, and 28; Nelson was relied on only to show that O'Brien's string compression is dictionary encoding (a point Realtime conceded: "Petitioner, Patent Owner, and their respective declarants all agree that O'Brien's encoder is a type of dictionary encoder"). The panel nonetheless addressed motivation to combine and found O'Brien and Nelson "share striking similarities," and that O'Brien "suggests that a wide variety of adaptive compression algorithms could be used and encourages a person having ordinary skill in the art to turn to 'well known' algorithms such as Nelson's" — a "simple substitution yielding predictable results." Claims 14–17 and 21 fell on O'Brien + Nelson + Welch.
• Settlement / termination: None. Trial ran to FWD (oral hearing transcript entered 2017-08-03; Paper 61).
• Appeal: Yes. Notice of appeal filed 2017-11-03; docketed as Realtime Data, LLC v. Iancu, No. 2018-1154 (Fed. Cir.). Issues on appeal: (1) whether the Board erred in finding a motivation to combine O'Brien and Nelson; (2) whether the Board erred by failing to construe "maintaining a dictionary" and in finding O'Brien disclosed it. Disposition: AFFIRMED, 2019-01-10 — Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019) (Dyk, Taranto, Stoll; opinion authored by Stoll; precedential). Holding, in essence: where a reference discloses every element, the Board need not articulate a motivation to combine a secondary reference used only to clarify terminology ("anticipation is the epitome of obviousness"), and the Board's construction of "maintaining a dictionary" was supported by claim 4 and the specification. CAFC mandate recorded 2019-04-22 (IPR2016-00783, Paper 65).
• Defensive value: This is the single most valuable asset a defendant has. Claims 1–4, 8, 14–17, 21, and 28 are unpatentable as affirmed, and the three independent claims (1, 14, 28) are among them. Any infringement theory built on those claims is not merely weak — it is contrary to a precedential Federal Circuit affirmance.

Sources: PTAB FWD (https://www.finnegan.com/images/content/2/1/v2/[218739/2017](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=218739-2017).09.pdf); CourtListener opinion (https://www.courtlistener.com/opinion/[4580424](/patent/4580424)/realtime-data-llc-v-iancu/); CAFC PDF (https://storage.courtlistener.com/pdf/2019/01/10/realtime_data_llc_v._iancu.pdf).

---

IPR2017-00167 — Oracle America, Inc. v. Realtime Data LLC

• Type: Inter Partes Review
• Filed: 2016-11-02
• Status: Terminated / dismissed (settlement) — verbatim PTAB judgment: "Dismissing the Petition" under 37 C.F.R. §§ 42.5(a), 42.71(a).
• Judge panel: Georgianna W. Braden, J. John Lee, Jason J. Chung.
• Petition grounds: Not adjudicated. Oracle's petition challenged the '812 patent, but the Board expressly stated it "has not yet determined, under 35 U.S.C. § 314, whether or not to institute a review." Because no trial was instituted, no ground, claim, or reference was reached on the merits. I will not characterize the grounds further.
• Institution decision: None reached — the case terminated in the preliminary proceeding stage.
• Final Written Decision: None.
• Settlement / termination: Joint Motion to Terminate under 35 U.S.C. § 317(a) and 37 C.F.R. § 42.74 filed 2017-03-31; termination granted 2017-04-11 (Paper 20). The written settlement agreement (Exs. 2016/2017) was filed under seal and granted business‑confidential treatment — terms are confidential; the Board made it available only to Federal Government agencies on written request or to any person on a showing of good cause.
• Appeal: None (no appealable FWD).
• Defensive value: Minimal offensive value, but useful context. Oracle's parallel district court case (6:16‑cv‑00088, E.D. Tex.) was dismissed with prejudice by stipulation (2017-05-15), and a related Oracle case (6:17‑cv‑00046) was dismissed (2017-05-08) — i.e., a global settlement. Because the IPR never instituted, no § 315(e) estoppel arises for Oracle.

---

IPR2017-00168 — Oracle America, Inc. v. Realtime Data LLC

• Type: Inter Partes Review (second Oracle petition against the '812 patent)
• Filed: 2016-11-02
• Status: Terminated (settlement) — public prosecution‑file and later‑brief tables list it as: "Oracle America Inc. v. Realtime Data LLC, IPR2017-00168, U.S. Pat. No. 6,597,812, Terminated Apr. 11, 2017."
• Judge panel: Same panel as IPR2017-00167 (Braden, Lee, Chung).
• Petition grounds: Not adjudicated — terminated pre‑institution alongside its companion.
• Institution decision: None reached.
• Final Written Decision: None.
• Settlement / termination: Terminated 2017-04-11 as part of the same Oracle–Realtime settlement. Terms confidential.
• Appeal: None.
• Defensive value: Confirms Oracle filed two petitions against this patent and settled both rather than litigate. No estoppel; no merits record.

Caveat on this proceeding's detail: I could confirm the filing date, patent number, petitioner, and termination date for IPR2017‑00168 from third‑party tables reproducing USPTO records, but I did not locate a standalone termination decision PDF for it in this session (unlike IPR2017‑00167, whose termination decision I linked). Verify against PTAB E2E (https://ptacts.uspto.gov/) before citing its internal procedural history.

---

Strategic summary

Claim status. The Board reached claims 1–4, 8, 14–17, 21, and 28 and held all of them unpatentable, affirmed by the Federal Circuit. That set includes all three independent claims — claim 1 (method), claim 14 (program storage device), and claim 28 (system) — and thus strips the patent of every independent claim. What remains untested (neither challenged in the instituted grounds nor adjudicated): dependent claims 5, 6, 7, 9, 10, 11, 12, 13 (depending from claim 1), 18, 19, 20 (from claim 14), 22–27, and 29–30 (from claim 28). Critically, each of these depends from an independent claim that is now adjudicated unpatentable and affirmed; a dependent claim cannot be infringed without practicing its parent, so these survivors have essentially no independent assertion value. With the patent expired as of 2020-05-26, there is also no reissue or continuation pathway to resurrect the scope. Practical label: no live independent claim.

Estoppel landscape (§ 315(e)(2)). The SAP/HP/Teradata petitioners that obtained the FWD are barred, in any later district‑court or ITC proceeding, from raising any ground they raised or reasonably could have raised — effectively all § 102/§ 103 art a skilled searcher would have found against claims 1–4, 8, 14–17, 21, 28, including O'Brien, Nelson, and Welch and any obvious variants. Oracle, by contrast, settled pre‑institution, so it faces no statutory estoppel — that is the one procedural soft spot in the record. For a new defendant, estoppel does not run to you at all; but you also do not need it, because the claims are already cancelled. Any fresh art you might develop is relevant only to the untested dependents, which cannot be asserted independent of a dead parent.

Pattern signals. (1) Multiple IPRs on one patent by different petitioners — SAP/HP/Teradata (instituted, FWD) and Oracle (two petitions, both settled) — is the classic "well‑asserted patent" signature; a patent with a wide assertion campaign (E.D. Tex. 6:15‑cv‑00464/00467/00469/00470, 6:16‑cv‑00088, 6:17‑cv‑00046; N.D. Cal. 3:16‑cv‑01836) is precisely the profile of Realtime Data's portfolio. (2) The patent owner fought it to the Federal Circuit and lost on a precedential opinion — Realtime did not simply abandon the '812, it litigated the motivation‑to‑combine and claim‑construction issues through appeal. (3) No defensive aggregator is in the '812 chain. I found no Unified Patents petition against US 6,597,812; Unified appears on the Google Patents page only as the data‑source attribution for the litigation listings, not as a petitioner. (Note: Unified Patents did file against other Realtime patents, e.g., IPR2017‑02129 on 8,717,204 — do not conflate those with the '812.) Treat the usinventor.org "INVALID/VALID" characterization of 6,597,812 as informational only, not a legal conclusion.

---

Recommended next steps

If you are a defendant being asserted on the '812 patent:

1. Demand the asserted claims in writing. If the demand letter cites claim 1, 14, or 28 (or 2–4, 8, 15–17, 21), the correct response is to point directly at the FWD disposition — "Petitioner has shown by a preponderance of the evidence that claims 1–4, 8, 14–17, 21, and 28 of the '812 patent are unpatentable" — and at the affirmance in Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019). Because the CAFC mandate issued 2019-04-22, those claims are cancelled; an assertion built on them is sanction‑exposed.
2. If the assertion is on an untested dependent claim (5–7, 9–13, 18–20, 22–27, 29–30), note that each incorporates an invalidated independent claim. Ask for the infringement theory that reaches your product through the added limitation without the parent's scope, and consider a § 315(e)(2)‑adjacent argument plus § 101 exposure — Realtime's sibling patents on near‑identical specifications drew § 101 ineligibility rulings (e.g., the Google/Netflix decisions on claim 15 of the '535 patent and the fee‑award litigation discussed in Realtime's 2024 CAFC appellant brief at http://patentlyo.com/media/2024/08/Realtime-Appellant-Brief.pdf).
3. Do not reflexively file a new IPR. The one‑year § 315(b) clock, the estoppel cost, and the fact that the independent claims are already dead make a new IPR low‑value unless a specific surviving dependent claim is actually asserted. Exhaust the cancellation argument first.

If you are monitoring rather than defending:
4. Confirm the certificate of cancellation for claims 1–4, 8, 14–17, 21, 28 issued after the 2019 mandate, and docket‑check that no new proceeding (2020–2026) has been filed. The patent expired 2020-05-26, which makes new AIA filings commercially pointless and consistent with the absence of any post‑2019 PTAB or CAFC activity I could find.
5. Close the ODP gap. The structured ODP block's "no AIA trial proceedings" result is wrong on this patent. Have whoever owns the ingest re‑query by patent number and by petitioner; the correct canonical set is IPR2016‑00783, IPR2017‑00167, IPR2017‑00168.

Sources to cite in any filing or memo: PTAB FWD, IPR2016‑00783 (2017-09-28) — https://www.finnegan.com/images/content/2/1/v2/[218739/2017](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=218739-2017).09.pdf; Federal Circuit opinion (2019-01-10) — https://www.courtlistener.com/opinion/4580424/realtime-data-llc-v-iancu/ and https://storage.courtlistener.com/pdf/2019/01/10/realtime_data_llc_v._iancu.pdf; IPR2017‑00167 Termination Decision (2017-04-11) — Docket Alarm PTAB docket https://www.docketalarm.com/cases/PTAB/IPR2017-00167/; PTAB E2E for docket‑level verification — https://ptacts.uspto.gov/.

One honesty caveat, per the no‑fabrication constraint: I could not locate a primary source for the judge panel or the specific petition grounds of IPR2017‑00168 in this session; the panel listed above is inferred from its companion IPR2017‑00167 (same filing date, same parties, same patent), and I have labeled the IPR2017‑00168 grounds as "not adjudicated" rather than inventing art. Verify those two data points on PTAB E2E before relying on them.

I'll research the assignment record and NPE history for this patent.

Ownership Chain — US 6,597,812 B1

Data-access caveat up front: The USPTO Assignment Center (assignmentcenter.uspto.gov / assignment.uspto.gov) exposes its record set only through its own search UI; I could not pull the raw reel/frame and correspondent fields for this patent through the retrieval tools available in this session. I have therefore marked every field I could not independently verify rather than inferring it. The one assignment event below is taken from the Google Patents legal-events record for US6597812B1 (https://patents.google.com/patent/US6597812/en), which mirrors the Assignment Center's indexed data. Do not treat the reel/frame as verified — verify at the source links at the end.

---

Inventors

Notes and patterns:

• Both named inventors are the assignors of record to the original assignee. This is a conventional employer/founder assignment, not a third-party acquisition.
• The priority provisional (U.S. 60/136,561) was filed 1999-05-28; the non-provisional (09/579,221) was filed 2000-05-26 — exactly the last day of the 12-month priority window. That is a common last-minute-filing pattern and is not itself meaningful for ownership purposes; I note it only because it makes any claim of "filed after the inventors had already left" impossible.
• No departure pattern. The tell you asked about — all inventors exiting within 12 months of filing — is not present. The opposite is true: Fallon continued to be named as the lead inventor on Realtime Data applications well into the 2010s (e.g., U.S. App. 14/733,565 filed 2015; 14/876,276 filed 2015; and a certificate of correction naming him on 7,415,530), which is consistent with a founder/principal-inventor role rather than a rank-and-file engineer who left.
• Two inventors, one assignee, one portfolio — a small, tightly held invention team. No inventor-side retention of rights, no separate inventor-owned entity, appears anywhere in the record.

---

Original assignee

Realtime Data, LLC (original and, per Google Patents, current assignee) — a New York limited liability company (state of incorporation: New York, per uspto.report/company/Realtime-Data-L-L-C).

• Addresses of record over time: 206 East 63rd Street, New York, NY 10021; Bronxville, NY; and 11 Wampus Close, Armonk, NY (used on a 2017 filing in a related Realtime case). All are ordinary street addresses, not registered-agent service addresses.
• Primary line of business: Realtime Data presented itself around the 1999–2001 filing era as a data-compression / acceleration developer. The Applicant's own specification describes real-time lossless compression for storage and transmission, and the company filed trademarks for "IXO" (serial 75909186, filed 2000-02-03, reg. 2605385) and "X3 SPEEDFEED" (serial 76208065, filed 2001-02-09, reg. 2988428) — the latter is a product-style mark, indicating genuine product marketing in this period.
• Did they ship a product embodying the claims? Unclear / not established. The IXO and X3 SPEEDFEED marks evidence branding activity, but I found no evidence of a currently shipping product. By the 2009–2018 period the entity appears in the record exclusively as a plaintiff — Realtime Data, LLC d/b/a IXO — across a very large district-court and PTAB campaign.
• Current status: Operating as a patent-licensing/enforcement entity. No merger, dissolution, or bankruptcy found. The patent itself expired 2020-05-26 (20 years from filing) and its asserted claims were cancelled on appeal in 2019, so the chain is effectively frozen at Realtime Data, LLC.

Caveat on the name: "d/b/a IXO" is a trade-name designation, not a separate legal entity. I found no recorded change-of-name assignment in the Google Patents legal-events list, so the record appears to run inventor → Realtime Data, LLC only.

---

Assignment timeline

The Google Patents legal-events record for this patent shows exactly one post-filing ownership event:

• 2000-08-08 (date shown; execution date not exposed in the retrieved event data — it is on or before this date) / recorded 2000-08-08 — Reel _/ (not retrieved in this session; verify at Assignment Center)
  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST — SEE DOCUMENT FOR DETAILS")
  • Assignor: BO, STEVEN L.; FALLON, JAMES J.
  • Assignee: REALTIME DATA, LLC
  • Correspondent: Not retrievable in this session. The Assignment Center's correspondent-of-record field for this recording must be pulled directly; I will not guess a firm name. (For context only: related Realtime/ Fallon-family filings in the same era carry outside-counsel docket series such as 2855.00xxxx and 3421.00xxxx, which indicates a repeat prosecution firm handled the portfolio — but I could not tie a named attorney or firm to this patent's recording, so this is not a finding.)
  • Context: Initial founder/employer assignment — rights vested in the operating company at ~2.5 months post-filing, before issuance. Not a fire-sale, reorg, securitization, or transfer-to-asserter.

Reel/frame cross-reference warning: My searches surfaced real reel/frame numbers for other Realtime Data applications — e.g. Reel 011797, Frame 0735 (assignment from inventors to Realtime Data LLC, used in the 7,181,608 file) and Reel 012703, Frame 0889 (used in the 7,358,867 file). Those are different applications and must not be attributed to US 6,597,812. The '812 recording is presumably in the same reel-number neighborhood (recorded August 2000), but I have no verified number and will not assert one.

No other conveyances are recorded anywhere I could find — no security agreement, no merger, no change of name, no license, no release, no corrective assignment. That means there is no post-issuance assignment to reconstruct: the original assignee never let go of the patent. There is also no evidence that the '812 was ever moved to the related Realtime-family assertion vehicles (Realtime Adaptive Streaming LLC, Realtime Array LLC), which I found asserting other Fallon-family patents; flagging that as a searched-and-not-found, not as a negative proof.

---

Timeline diagram

timeline
    title Ownership of US 6597812
    1999 : Provisional filed by Fallon and Bo
    2000 : Non-provisional filed
         : Assigned to Realtime Data LLC
    2003 : Patent issued
    2015 : First infringement suits filed
    2016 : IPR petitioned by SAP and HP
    2017 : PTAB holds claims unpatentable
    2019 : Federal Circuit affirms
    2020 : Patent expires

---

NPE / troll-pattern signals

1. Shell-entity transfer — not present.
There is no recorded transfer from an operating assignee to a licensing-only LLC. The only event is inventor → Realtime Data, LLC. Realtime Data, LLC is a New York LLC with ordinary street addresses of record (206 East 63rd St, New York; Bronxville, NY; 11 Wampus Close, Armonk, NY) — not a registered-agent drop box. Caveat: the LLC's own character is licensing-focused, but that is captured under signal 2, not this one; a shell-transfer finding requires a transfer, and there isn't one.

2. Known asserter in the chain — present (strong).
Realtime Data, LLC (a/k/a Realtime Data, LLC d/b/a IXO) is the sole assignee for the entire life of the patent and is a high-frequency, well-documented patent plaintiff. The record I retrieved shows this single entity as plaintiff/patent owner in, among others, Realtime Data LLC d/b/a IXO v. Actian, Dropbox, EchoStar, Riverbed, BMC Software, Oracle, Netgear, Circadence, Acronis, Synacor, IBM, Cloudera, Teradata, Microsoft and more, and as patent owner against petitioners SAP, Hewlett-Packard, Dell, Apple, Oracle, Riverbed, Rackspace, Commvault, Teradata and Unified Patents. The Google Patents litigation links for this patent alone list seven district-court cases (E.D. Tex. 6:15‑cv‑00464, ‑00467, ‑00469, ‑00470; 6:16‑cv‑00088; 6:17‑cv‑00046; N.D. Cal. 3:16‑cv‑01836) plus IPR2016‑00783 and IPR2017‑00167/00168. There is no evidence in any of this of a product embodying the claims being sold by the plaintiff.

3. Repeat correspondent across the chain — unclear / insufficient data.
There is only one link in the chain, so recurrence cannot exist by definition. I was not able to retrieve the correspondent of record for the 2000‑08‑08 recording. This is a data gap, not an exoneration — pull the correspondent field from the Assignment Center before relying on this row.

4. Cascading transfers — not present.
One assignment in 21 years. No chained LLCs, no shared correspondent addresses, no transfers at all after 2000‑08‑08.

5. Pre-litigation transfer — not present.
The assignment is dated 2000‑08‑08. The first infringement suits naming this patent were filed May 2015 (E.D. Tex. 6:15‑cv‑00464 et seq.). That is a ~15-year gap. This chain was not arranged to enable assertion; the patent simply stayed put and was asserted a decade and a half later.

6. Bankruptcy fire-sale — not present.
No Chapter 7/11, no stalking-horse sale, no assignment out of an estate. The assignee is a live New York LLC and the patent expired in its hands.

7. Privateering — not present / not established.
There is no operating-company parent that fed this patent to an NPE for proxy assertion. Realtime Data appears to be the original owner-developer that pivoted from development/marketing (IXO, X3 SPEEDFEED marks, 2000–2001) to licensing and enforcement. That is a "born/hybrid NPE" posture, not privateering. I found no SEC filing or coverage tying a manufacturing parent to this transfer.

8. Defensive aggregator — not present.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Unified Patents appears in the record only as an adversary (IPR2017‑02129 and others against Realtime Data), which is the inverse of a defensive-acquisition endpoint.

---

Verdict

NPE — high confidence.

The chain is a single founder-to-company assignment (recorded 2000‑08‑08, assignors Bo and Fallon, assignee Realtime Data, LLC), and the assignee never transferred the patent — so the usual "shell-transfer" and "cascading-transfer" tells are absent. But signal 2 is present at high strength and is not a naming inference: Realtime Data, LLC d/b/a IXO is the sole owner for the patent's entire life and the plaintiff in a dozen-plus district-court campaigns and the target of a dozen-plus IPRs, with the '812 itself asserted in seven district-court cases (2015–2017) and invalidated in SAP America v. Realtime Data, IPR2016‑00783 (FWD 2017‑09‑28), affirmed in Realtime Data, LLC v. Iancu, No. 2018‑1154 (Fed. Cir. Jan. 10, 2019). That combination — a dedicated licensing/enforcement owner with no product embodying the claims, asserting on a portfolio-wide scale — is the definition of the NPE pattern, and it is documented rather than inferred.

Because the patent expired 2020‑05‑26 and the challenged claims (1–4, 8, 14–17, 21, 28) were cancelled, the chain is now terminal and non-assertable. I did not find any 2026 ownership or appellate activity, consistent with the earlier summary section's finding.

Verify at:

• USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search patent number 6597812; check the Correspondent field on the 2000‑08‑08 record)
• Legacy Assignment Search — https://assignment.uspto.gov/patent/index.html
• Google Patents legal events — https://patents.google.com/patent/US6597812/en

Open items I could not close: (i) the reel/frame for the 2000‑08‑08 assignment; (ii) the correspondent of record for that recording (needed to complete signal 3); (iii) whether any unrecorded or state-law transfer to a Realtime-family assertion vehicle ever occurred — the recorded record says no, but absence in the sources I could reach is not proof.

I'll research the prior art citations for US 6,597,812. Let me run several searches.

Let me get the front-page references and International search report documents considered for this patent.

Prior Art Analysis — US 6,597,812 B1

Scope and methodology note (important)

I searched for the specific number 6597812. I did not return results for similar numbers. One limitation must be stated up front: I was not able to retrieve the examiner's face-of-patent "References Cited" list (the U.S. Patent Documents / NPL list printed on the front page and in the "Notice of References Cited") for the '812 patent from the sources available in this session. Google Patents' "Patent Citations" widget returned by search belonged to a different patent (US 2012/0182163), not to the '812 patent, so I have not attributed those four citations to the '812 patent.

What I can ground with high confidence is the set of references actually adjudicated against the '812 patent in the PTAB/Federal Circuit record, which — because they were found to disclose or suggest the challenged claims — is the most probative prior art for this patent. I flag clearly below which items are patent documents and which are non-patent literature, and I mark any identifier I could not verify rather than guess.

---

Ground truth anchor: the adjudicated invalidity record

The controlling validity record for the '812 patent is IPR2016-00783 (Hewlett-Packard Enterprise Co. et al. v. Realtime Data LLC), Final Written Decision Sept. 28, 2017, and its affirmance in Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. Jan. 10, 2019), which held claims 1–4, 8, 14–17, 21, and 28 unpatentable. That record is the single best guide to the most relevant prior art.

Related proceedings: IPR2017-00167 and IPR2017-00168 (Oracle America, Inc. v. Realtime Data LLC, filed Nov. 2, 2016) both terminated by settlement, but their petitions (and exhibit lists) name additional prior art, notably a bit-packing reference referred to as "Heath."

---

Most relevant prior art — detailed table

Reference 1 — O'Brien (U.S. 4,929,946)

• Full citation: U.S. Patent No. 4,929,946, Adaptive Data Compression Apparatus Including Run Length Encoding for a Tape Drive System, issued May 29, 1990.
• Publication/filing date: Issued May 29, 1990 — well before the '812 priority date of May 28, 1999, so it qualifies as prior art at minimum under pre-AIA 35 U.S.C. § 102(b).
• Brief description: A hardware adaptive data-compression system for a tape drive that combines run-length encoding with dictionary/string (LZW-style) encoding. It segments the input stream and encodes runs using a code indicating a run is approaching, a character reference value, and a repeat count. The PTAB and Federal Circuit found it discloses the preamble and every step of claim 1 and the elements of claim 28, including the "maintaining a dictionary" limitation (as interpreted through dependent claim 4's "dynamically generating a new code word … and adding the new code word").
• Claims potentially anticipated under § 102: 1, 2, 3, 4, 8, and 28. The Board found O'Brien alone discloses all limitations of claims 1–4, 8, and 28; the Federal Circuit affirmed, and expressly noted that "a disclosure that anticipates under § 102 also renders the claim invalid under § 103, for 'anticipation is the epitome of obviousness'" (Connell v. Sears, Roebuck & Co., 722 F.2d 1542, 1548 (Fed. Cir. 1983)). This is the strongest § 102 candidate for those claims.
  • Realtime's counter-argument (rejected): O'Brien allegedly does not "maintain" a dictionary because it discards the dictionary between segments. The Board and CAFC rejected this, reading "maintaining a dictionary" to be satisfied by claim 4's steps, with reset/initialization being optional (claim 5).

Reference 2 — Welch (U.S. 4,558,302)

• Full citation: U.S. Patent No. 4,558,302, High Speed Data Compression and Decompression Apparatus and Method, issued December 10, 1985 (the classic LZW patent).
• Publication/filing date: Issued Dec. 10, 1985 — prior art under pre-AIA § 102(b).
• Brief description: Discloses the LZW dictionary-based compression/decompression algorithm, including implementation as software for loading into a stored-program digital computer as well as hardware. It was cited in IPR to supply the software/program-storage-device character of claims 14–17 and 21 (the computer-readable-medium claims).
• Claims potentially anticipated under § 102: Likely none standalone — Welch was used as a secondary reference for § 103, not as a single-reference anticipatory disclosure. It is relevant to claims 14–17 and 21 in combination with O'Brien (and Nelson). I would not characterize Welch alone as anticipating any claim of the '812 patent.

Reference 3 — Nelson, The Data Compression Book (1992)

• Full citation: Mark Nelson, The Data Compression Book, M&T Books (1992).
• Publication date: 1992 — prior art; used as an evidentiary/teaching reference.
• Brief description: A widely used textbook explaining LZ77, LZ78, LZW (including code variants referred to as LZW12.C and LZW15V.C), and dictionary-maintenance techniques. In the IPR it was used to show that a skilled artisan would recognize O'Brien's string compression as dictionary encoding, and (in the alternative) that substituting Nelson's dictionary operations into O'Brien was a simple substitution with predictable results.
• Claims potentially anticipated under § 102: None alone. Used for § 103 motivation/teaching regarding claims 1–4, 8, 14–17, and 28.

Reference 4 — Welch IEEE article (1984)

• Full citation: T. Welch, "A Technique for High-Performance Data Compression," IEEE Computer, Vol. 17, No. 6, June 1984, pp. 8–19.
• Publication date: June 1984 — prior art.
• Brief description: The seminal LZW journal article describing high-performance dictionary-based data compression. Listed in the Oracle IPR exhibit list (Ex. 1014).
• Claims potentially anticipated under § 102: None alone; § 103 background corroboration.

Reference 5 — "Heath" (bit-packing) — UNVERIFIED

• In the Oracle IPR2017-00167/168 petition, Grounds 3 and 4 challenged claims 9 and 22 (the bit-packing claims) using O'Brien + Nelson + "Heath." Realtime argued that using bit-packing in O'Brien would render O'Brien inoperable for its intended purpose.
• I could not verify in this session the full citation (patent number, title, issue date) for "Heath." I am explicitly declining to fabricate a patent number. If this reference matters to your analysis, its citation should be pulled directly from the IPR2017-00167 or IPR2017-00168 exhibit list (Exhibit numbering in the Oracle petition).
• Claims at issue: 9 and 22 (bit-packing), asserted only in § 103 combinations.

---

Reference documents cited in the '812 specification itself (not prior art, but cross-references)

The '812 specification references the following related Realtime Data applications, which are commonly assigned and therefore not prior art against the '812 patent — but they are the citation-like references embedded in the text:

• U.S. patent application Ser. No. 09/210,491, filed Dec. 11, 1998, "Content Independent Data Compression Method and System" (incorporated by reference).
• U.S. patent application Ser. No. 09/266,394, filed Mar. 11, 1999, "System and Methods For Accelerated Data Storage and Retrieval" (incorporated by reference).
• U.S. Provisional Application Ser. No. 60/136,561, filed May 28, 1999 (priority basis).

---

Anticipation (§ 102) vs. obviousness (§ 103) — how to read this

A key nuance for your task: the '812 patent was invalidated under § 103, not § 102, in the adjudicated record. However, the Board's finding that O'Brien alone discloses every limitation of claims 1–4, 8, and 28 is functionally a single-reference (anticipation-style) disclosure. The Federal Circuit made the relationship explicit, quoting Connell: "anticipation is the epitome of obviousness." So for a § 102 framing:

• O'Brien (U.S. 4,929,946) is your best and essentially only single-reference § 102 candidate, covering claims 1, 2, 3, 4, 8, 28.
• Welch (U.S. 4,558,302), Nelson (1992 book), and the Welch 1984 article are § 103 references — none is a standalone anticipatory reference.
• "Heath" is asserted only for claims 9 and 22 and only in § 103 combinations.

No reference in the record was shown to anticipate claims 5, 6, 7, 10–13, 18–20, 23–27, 29–30 on its own; those were not part of the instituted/unpatentability findings above.

---

Contradiction flag (per your instruction)

The previously generated summary in this analysis states the IPR2016-00783 FWD "found claims 1–4, 8, 14–17, 21, 28 unpatentable as obvious over O'Brien alone/with Nelson, and over O'Brien + Nelson + Welch." That is consistent with what I found here, with one refinement worth noting: the Board's primary holding was that O'Brien alone discloses all limitations of claims 1–4, 8, and 28 (Nelson being used to label O'Brien's technique as dictionary encoding, or alternatively as an obvious substitution), and Welch was the additional reference for the CRM/software claims 14–17 and 21. There is no contradiction between the two statements, but the "O'Brien alone" framing is the legally operative one for § 102 purposes and is the more precise reading.

---

Uncertainty caveats (explicit)

1. The examiner's face-of-patent reference list for the '812 patent was not retrievable in this session. My table is therefore the adjudicated prior art set, which is the most probative but is not necessarily identical to the examiner's cited references. If you need the exact "References Cited" printed on the front page and in the Notice of References Cited, that should be pulled from the USPTO Patent Public Search / PatentCenter file wrapper for US 6,597,812 directly.
2. "Heath" citation is unverified — I have not supplied a number/title/date because I could not confirm it, and I will not fabricate one.
3. Consistent with the earlier section, I found no 2026 CAFC docket activity for this patent; the authoritative appellate record remains Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019).

Primary sources used:

• Google Patents — https://patents.google.com/patent/US6597812/en
• IPR2016-00783 Final Written Decision (Finnegan PDF) — https://www.finnegan.com/images/content/2/1/v2/[218739/2017](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=218739-2017).09.pdf
• Oracle IPR2017-00167 petition (USPTO PTActs) — https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1473614](/patent/1473614)/download-documents
• Oblon summary of Realtime Data v. Iancu — https://www.oblon.com/realtime-data-llc-v-iancu-no-requirement...
• Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019) — https://app.midpage.ai/case/realtime-data-llc-v-iancu-[4357677](/patent/4357677)
• Docket Alarm IPR2017-00168 docket — https://www.docketalarm.com/cases/PTAB/IPR2017-00168/

I'll research the prior art references identified in the earlier sections and any additional art relevant to this patent before building the § 103 analysis.

Let me get the full Final Written Decision text and research prior art covering claims that were not challenged in the IPR (e.g., bit-packing, hash table, dictionary reset).

Let me verify the bit-packing reference (Heath) and the second petition's grounds for the remaining claims.

Obviousness Analysis of U.S. Patent 6,597,812 under 35 U.S.C. § 103

Building on the previously generated bibliographic, claim, and litigation sections. This section does not repeat them; it adds the substantive § 103 analysis. Note one correction to the prior summary: the earlier text said "Claim 28 — System … the outputs of the two encoders are combined." That is consistent with the Federal Circuit's reading. No contradiction found.

---

I. Governing legal standard

Because the '812 patent issued July 22, 2003, and never contained a claim with an effective filing date on or after March 16, 2013, the pre-AIA version of § 103(a) applies. Realtime Data, LLC v. Iancu, 912 F.3d 1368, 1375 n.1 (Fed. Cir. 2019) (quoting the AIA § 3(n) savings clause). The four Graham factors govern:

1. scope and content of the prior art;
2. differences between the prior art and the claims;
3. level of ordinary skill; and
4. objective indicia of non-obviousness.

Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966); KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). Because the "claimed discoveries almost of necessity will be combinations of what, in some sense, is already known," a challenger relying on multiple references must establish a motivation to combine — "explicitly or implicitly in market forces; design incentives; the interrelated teachings of multiple patents; any need or problem known in the field … and the background knowledge, creativity, and common sense of the person of ordinary skill." Realtime Data, 912 F.3d at 1373–74. Where, however, a single reference discloses every element, the reference may be used under § 103 without an express motivation-to-combine finding, because "anticipation is the epitome of obviousness." Id. at 1372–73 (quoting Connell v. Sears, Roebuck & Co., 722 F.2d 1542, 1548 (Fed. Cir. 1983)).

The list of references and the petition/decision record below derive from the IPR2016-00783 final written decision (https://www.finnegan.com/images/content/2/1/v2/[218739/2017](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=218739-2017).09.pdf), the Federal Circuit opinion (https://storage.courtlistener.com/pdf/2019/01/10/realtime_data_llc_v._iancu.pdf), and the Oracle-served petition papers hosted on PTAB's PTActs system (https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1473614](/patent/1473614)/...).

---

II. Level of ordinary skill in the art (POSA)

The petition record defines a POSA as a person with an undergraduate degree in computer science and two years of industry experience, or a graduate degree in data compression, and familiarity with lossless compression generally (run-length and LZW/dictionary coding). This level is uncontroversial here: both RLE and LZW were mature, textbook arts by 1999. The prior art is therefore the entire body of lossless compression literature as of May 28, 1999.

---

III. The prior art references

Caveat: I could not independently confirm Heath's § 102(b) status as the petition asserted it; Heath issued Oct. 26, 1999 — after the '812 provisional date (May 28, 1999) but based on a Dec. 2, 1997 application, so it is at minimum § 102(e) art. The distinction does not affect the analysis.

---

IV. Ground 1 — Claims 1–4, 8, and 28 obvious over O'Brien (and, in the alternative, O'Brien + Nelson)

A. Claim 1 (method): every element disclosed by O'Brien alone

Why no express motivation-to-combine is needed for claim 1: O'Brien alone discloses every limitation. As the Federal Circuit held, the Board "was free to come to the very conclusion it reached: that O'Brien alone disclosed every element of claims 1–4, 8, and 28." Realtime Data, 912 F.3d at 1373. Nelson was used only to explain that O'Brien's "reference value encoder" is what the art calls a dictionary encoder — a point Realtime conceded in the IPR ("Petitioner, Patent Owner, and their respective declarants all agree that O'Brien's encoder is a type of dictionary encoder," 2017 WL 4349409, at *5).

Alternative motivation (if Nelson is treated as supplying a missing limitation): O'Brien itself repeatedly calls its method "an adaptive data compression algorithm" and states the "exact details of the present algorithm are not relevant," expressly inviting the artisan to substitute known adaptive algorithms. Nelson — a well-known textbook — teaches that LZW is dictionary-based and that dictionary algorithms are adaptive. This is sufficient: "[A]n ordinary artisan would have naturally looked to Nelson, a well-known data compression textbook, to better understand or interpret O'Brien's compression algorithms." Realtime Data, 912 F.3d at 1374. Combining O'Brien's RLE + adaptive string coding with Nelson's dictionary-coding implementations is a substitution of one known element for another yielding predictable results (KSR, 550 U.S. at 416–17, 421).

B. Claim 2 (run-length trigger when "at least the next s successive data blocks … are similar")

O'Brien detects a run when the bytes monitored on its leads match and issues a run-length detect signal — the claimed threshold "s" is simply the number of matched bytes required, an obvious design parameter. O'Brien's Table A additionally maps repeat counts to specific reference values, so the artisan implementing a practical trigger would set s by routine choice.

C. Claim 3 (three consecutively output words: control code, character code word, count)

Claim 3 requires consecutive output of (i) a first control code word indicating a run-length sequence, (ii) a code word for the character, (iii) a count of successive similar blocks. O'Brien outputs (character of the run), (Table A run-length reference value that tells the decoder a run was encoded and the number of bits in the repeat count), and (repeat count). The Board construed "consecutively" as "following one another in uninterrupted order; successive" and expressly declined to import a chronological modifier — rejecting Realtime's argument that O'Brien's order is "character first." The Board found O'Brien teaches claim 3/16. (FWD at § II.F; https://www.finnegan.com/images/content/2/1/v2/[218739/2017](https://assignmentcenter.uspto.gov/search/patent/reelFrameDetail?reelFrame=218739-2017).09.pdf.) Notably, the same three-part run-length output also appears expressly ordered in Heath ("[the] compressor outputs a run length signaling code word equal to the next code word to be built … followed by the number of additional repetitions"), providing an independent motivation/teaching if the claim is construed to require a specific order.

D. Claims 4 and 8 (dynamic dictionary update; code word = dictionary index)

• Claim 4 ("dynamically generating a new code word … if the built data block string does not match … and adding the new code word"): O'Brien expressly does this — when the current string is not found in string table 306, it is added and assigned the next available reference value, and the previous reference value is updated. The Board found "O'Brien taught every step for 'maintaining a dictionary' identified in dependent claim 4." Realtime Data, 912 F.3d at 1371.
• Claim 8 (code word = "dictionary index"): O'Brien's "reference values" are the indices into its string table — i.e., dictionary indices. Nelson confirms the nomenclature.

E. Claim 28 (system: dictionary with control code words + RLE encoder + dictionary encoder, combined output)

O'Brien discloses a dictionary/string table containing (a) run-length control reference values (Table A — telling the decoder a run was encoded) and (b) character/string reference values each mapped to a unique string; a run-length detection/encoding circuit; a reference-value (dictionary) encoder 304; and a byte-assembly module that combines the two encoded outputs into a single stream onto the tape. The Board determined O'Brien teaches claim 28.

Result (ground truth): The Board held claims 1–4, 8, and 28 unpatentable, and the Federal Circuit affirmed (Realtime Data, LLC v. Iancu, No. 2018-1154, 912 F.3d 1368 (Fed. Cir. Jan. 10, 2019); mandate Apr. 22, 2019).

---

V. Ground 2 — Claims 14–17 and 21 obvious over O'Brien + Nelson + Welch

Claim 14 is the program-storage-device (software) counterpart of claim 1; claims 15–17 and 21 mirror claims 2–4 and 8 in software form.

• Disclosure: O'Brien + Nelson supply all substantive limitations, exactly as in Ground 1.
• Welch supplies the missing element — hardware/software equivalence: The Welch patent shows the very same LZW algorithm implemented in both hardware (Figs. 2–5) and software (Figs. 6–9). This establishes that a POSA would have known that an algorithm of this type can be embodied as a stored program of instructions without changing its operation.
• Motivation: The only difference between claim 1 and claim 14 is the preamble ("program storage device"). Because implementing a known compression algorithm in software on a machine-readable medium was itself well known and predictable (Welch proves it), claim 14 and its dependents are obvious over the O'Brien/Nelson/Welch combination. The Board so held, and the Federal Circuit affirmed.

Result: Claims 14–17 and 21 held unpatentable; affirmed.

---

VI. Grounds for the claims not adjudicated in IPR2016-00783

The FWD covered only claims 1–4, 8, 14–17, 21, and 28. The following claims were never finally adjudicated (claims 9 and 22 were challenged in the later Oracle petition, IPR2017-00167/-168, which settled before an FWD). They remain presumptively valid and are the focus of any further § 103 challenge. Each can be met by straightforward additional combinations.

A. Claims 9 and 22 (bit-packing encoded run-length sequences and code words) — over O'Brien/Nelson + Heath

• Claim 9 (dependent on claim 1): "bit-packing encoded run-length sequences and code words that are output."
• Claim 22 (dependent on claim 14): same limitation in program-storage-device form.

The specification itself frames bit-packing as a known technique for a known problem: dictionary code words are usually <2 bytes while strings are longer, and a 12-bit code word on a 16-bit bus wastes 4 bits per transfer — bit-packing recovers this with "negligible" overhead (the spec's own 16/12 ≈ 1.33 improvement).

Heath expressly discloses the limitation: "code words are shifted and packed into the compressed data stream … which is output by the compressor" (Heath at 9:8–12). Heath is in the same field (data compression), addresses the same problem class (improving dictionary/RLE compression for a channel), and — critically — also combines RLE with dictionary coding, so it is doubly analogous. Motivation: a POSA seeking to maximize channel throughput would apply Heath's known packing technique to O'Brien's byte-assembly module, which "is already configured to combine reference values into bytes." Predictable result; no change in principle of operation.

Counterargument to note (from the settled Oracle proceeding): Realtime argued that using bit-packing in O'Brien would render it inoperable, because O'Brien uses variable-length reference values ("The use of fixed length data compression codes…", O'Brien), so packing fixed-width code words would break O'Brien's decoding. In re Gordon, 733 F.2d 900 (Fed. Cir. 1984) (a combination that renders the primary reference inoperable cannot be obvious). This is a genuine, non-frivolous defense to the bit-packing claims and should be evaluated on the actual O'Brien disclosure; a challenger would do better to anchor bit-packing to a fixed-width dictionary system (e.g., Nelson's LZW12.C, or Welch's fixed-width code symbols) than to O'Brien's variable-length reference values. This is the single weakest link in the O'Brien-centered theory, and it is precisely why claims 9 and 22 survived to settlement.

B. Claims 5 and 6 (dictionary reset when code words exceed a threshold; control code word emitted on reset) — over O'Brien + Nelson (LZW15V.C)

Nelson's LZW15V.C teaches a "Flush" control code that "tells the decoder to 'Flush' the dictionary, causing the dictionary to be re-initialized," used when the dictionary grows so large that compression becomes less efficient; the Flush code is placed in the output stream so the decoder mirrors the reset. This is precisely claims 5 and 6: (1) initialize/reset the dictionary when the number of code words exceeds a predetermined threshold, and (2) output a control code word indicating the dictionary has been initialized. O'Brien also initializes at each segment boundary and outputs a segment/run-length reference value. Motivation: resetting on overflow preserves compression efficiency while keeping the encoder/decoder dictionaries synchronized — a well-understood design goal. Result predictable.

C. Claim 7 (control code words for initialization, run-length sequence, end-of-data, or a combination) — over O'Brien + Nelson

O'Brien's Table A reserve reference values are control codes (run-length indicators); O'Brien also has an end-of-segment/end-of-data mechanism, and initializes its dictionary. Nelson's LZW12.C expressly supplies End-of-Stream (256) and First-Code (257) control codes, and LZW15V.C adds Bump and Flush. The union of these control-code functions reads directly on claim 7's "run-length encoded sequence / dictionary initialization / end of the input data" alternatives.

D. Claim 10 (build-string loop with Pstring/C data structures and Mcode "previous code word") — over O'Brien

O'Brien's reference-value encoder implements exactly this: read next character; combine with current prefix to build a new string; search the table; if found, update the previous reference value and the prefix and continue; if not found, output the previous reference value. The claimed "first/second data structure" and "previous code word" are the prefix string and the last-used reference value. Nelson's LZW12.C/LZW15V.C pseudocode shows the same loop expressly.

E. Claims 11 and 12 (add current string to dictionary; store last input block and restart from it) — over O'Brien

O'Brien adds the not-found string to string table 306 and assigns the next reference value, then "the previous reference value is updated to be the reference value for the final character of the current string … The entire process is then repeated using the next input byte." That is claims 11 and 12 verbatim.

F. Claim 13 (hash table of arrays indexed by first data block; used for searching) — over Welch (+ O'Brien/Nelson

• Disclosure: Welch expressly discloses "the limited-search hash procedure" and states "During compression, the hash table mechanization is utilized to store the non-preassigned strings…." Welch teaches combining the character with the code for the string to form a table address — i.e., a first-byte-anchored hash lookup. Nelson likewise teaches hash tables for LZW dictionary search.
• Motivation: Both Welch and O'Brien/Nelson address the recognized need to reduce dictionary search time; using a hash table to accelerate lookup in a dictionary encoder is a known solution applied to a known problem with predictable results. A POSA seeking to keep the encoder real-time would plainly adopt it.

G. Claims 18–20, 23–27, 29–30 (software-form run-length/dictionary complements)

These are the program-storage-device (or system) parallels of the method claims addressed in §§ IV–VI, and are met by the same references plus Welch for the software embodiment (as in Ground 2). Claim 28's system elements are met by O'Brien alone (see § IV.E).

---

VII. Claim-by-claim summary

---

VIII. Why a POSA would have been motivated to combine

Independent of the single-reference strength of O'Brien, the record supplies several KSR-sufficient motivations:

1. Same field, same problem, same solution. O'Brien, Nelson, Welch, and Heath are all lossless compression references addressing the same recognized deficiencies (poor compression of repetitive strings; dictionary search cost; wasted bus bits).
2. Express invitation in O'Brien. O'Brien calls its method "an adaptive data compression algorithm," says "the exact details of the present algorithm are not relevant," and states that "adaptive data compression algorithms are well known" — an express teaching to look to the known art. This supports both the Nelson and Welch/Heath substitutions.
3. Predictable results / simple substitution. Replacing or augmenting a known dictionary encoder with another known dictionary encoder (LZW12.C/LZW15V.C), a known add-on (hash search), or a known output optimization (bit-packing) is "a simple substitution of one known element for another," with no change in the principal of operation. KSR, 550 U.S. at 416–17.
4. Design incentives / market forces. Real-time compression on constrained buses creates a concrete incentive to (a) exploit long runs (O'Brien's RLE), (b) shrink indices (dictionary coding), and (c) eliminate wasted bus bits (bit-packing) — the exact three ingredients recited across the '812 claims.
5. The '812 specification itself concedes the arts are known. It describes RLE, dictionary coding, hashing, and bit-packing as "widely utilized," "well known," and "any suitable … known to those skilled in the art," and admits the benefit of the combination flows from known characteristics, not from any new mechanism. A specification that frames the invention as a combination of known techniques to obtain a predictable aggregate benefit is the paradigm of obviousness. KSR, 550 U.S. at 417–18.

---

IX. Counterarguments and their resolution

1. "O'Brien segments data into small blocks; maintaining one growing dictionary contradicts O'Brien's principle of operation." (Realtime's principal argument; also the In re Gordon "inoperability" theme.) The Board and Federal Circuit rejected it: O'Brien's segmentation was a speed/ratio tradeoff, not a teaching away from maintaining a dictionary, and O'Brien's own encoder adds strings and assigns reference values within each segment — i.e., it maintains a dictionary. Realtime Data, 912 F.3d at 1371–72.
2. "No express motivation to combine O'Brien and Nelson." Rejected. Where O'Brien alone discloses all elements and Nelson merely clarifies terminology, no motivation finding is required; and even if one were required, "the interrelated teachings," the well-known status of Nelson, and O'Brien's invitation to use known adaptive algorithms supply substantial evidence of motivation. Id. at 1373–74.
3. "The run-length output order in claim 3 is not O'Brien's order." The Board construed "consecutively" as uninterrupted/successive (not chronological) and declined to read in an ordering requirement; O'Brien teaches the three outputs. If a court reads in a specific order, Heath provides an express ordered disclosure (signaling code word → repeat count).
4. "Bit-packing renders O'Brien inoperable (variable-length codes)." This argument has force against claims 9 and 22 if the primary reference is O'Brien, because O'Brien uses variable-length reference values. In re Gordon, 733 F.2d 900, 902 (Fed. Cir. 1984). A challenger should instead anchor the bit-packing claims to a fixed-width dictionary system (Nelson LZW12.C/Welch) plus Heath. This is the most defensible remaining stronghold of the '812 patent.
5. Objective indicia (secondary considerations). The Board noted that Patent Owner did not proffer a substantive argument on objective indicia (FWD n.7). No nexus-bearing evidence of unexpected results, long-felt need, or commercial success was established. This Graham factor therefore cuts in favor of obviousness.

---

X. Caveats

• The § 103 challenge has already succeeded for 10 of the 30 claims (1–4, 8, 14–17, 21, 28), as adjudicated in IPR2016-00783 and affirmed in Realtime Data, LLC v. Iancu, 912 F.3d 1368 (Fed. Cir. 2019). Those claims stand cancelled. This is the strongest possible ground truth for the analysis above.
• The remaining claims (5–7, 9–13, 18–20, 22–27, 29–30) were never cancelled and remain presumptively valid, but I identify above specific, largely conceded art (Nelson's LZW15V.C Flush/Bump codes for the reset/control-code claims; Welch's limited-search hash for claim 13) that would support § 103 challenges. These are analyses, not adjudications.
• The patent is expired (anticipated expiration 2020-05-26). Expiration affects remedies, not validity; an obviousness analysis remains meaningful for history and for related-family members.
• I could not verify the precise identifier of the "Seroussi" reference cited in the settled Oracle petition; I have described its asserted teaching without asserting a patent number. Similarly, Heath's § 102(b) status is as the petition characterized it; its qualification as § 102(e) art is independently clear from its Dec. 2, 1997 filing date.
• Where search results and training data conflict, I have followed the retrieved sources (PTAB/Federal Circuit documents).