US 5467087

I'll search for patent 5467087 across USPTO sources and any CAFC docket activity.

Let me run additional targeted searches to check for any CAFC/Federal Circuit activity and to confirm current status.

US Patent 5,467,087 — Summary

Scope note / caveats up front

• I ran web searches against publicly indexed USPTO/PTAB material, Google Patents, Justia, RPX Insight and docket aggregators. I could not directly query USPTO PatentCenter or the CAFC docket system as live databases, so the "no CAFC activity" finding below is a search-based negative, not an authoritative docket-certified one.
• Your prompt gives "April 26, 2026," while my session date is 2026-09-28. Either way, I found no 2026 (or any) Federal Circuit appeal involving this patent number.
• Strict-number discipline: many search hits reference different "’087 patents" — e.g. Samsung's U.S. 7,756,087 (claim terms "non-scheduled transmission"/"N"), S3 Graphics' U.S. 7,043,087, and a Netlist "’087" patent in a 2026 Samsung PGR. Those are not 5,467,087 and I have excluded them. Do not merge them.

---

Bibliographic data (US 5,467,087)

Sources: https://patents.google.com/patent/US5467087/en ; https://insight.rpxcorp.com/patent/[US5467087A](/patent/US5467087A) ; PTAB IPR2017-00108 Exhibit 1010-5 (front page reproduction of the letters patent).

Abstract (verbatim)

"A data compression process and system that identifies the data type of an input data stream and then selects in response to the identified data type at least one data compression method from a set of data compression methods that provides an optimal compression ratio for that particular data type, thus maximizing the compression ratio for that input data stream. Moreover, the data compression process also provides means to alter the rate of compression during data compression for added flexibility and data compression efficiency. Furthermore, a system memory allocation process is also provided to allow system or user control over the amount of system memory to be allocated for the memory intensive data compression process. System memory allocation process estimates the memory requirement to compress the input data stream, and allocates only that amount of system memory as needed by the data compression for memory allocation efficiency."

The invention in one paragraph

The patent teaches a two-stage pipeline: a pre-compression stage sniffs the input stream's data type (the specification's preferred classifier distinguishes ASCII, binary and unicode — e.g. any byte > 127 ⇒ binary; matching high bytes across pairs of bytes ⇒ unicode) and emits a data-type identification signal; a compression stage uses that signal to pick a compression method (preferably LZ-1 or LZ-2, followed by Huffman or arithmetic coding) plus tuning parameters p_max/l_max, and encodes the data type in a header so the decompressor can auto-select the matching decoding path. Two optional refinements are claimed: a compression-rate control input (speed up by shrinking p_max/l_max or switching LZ-1→LZ-2) and dynamic memory allocation (allocate ~max(initial floor, estimated need)).

---

Plain-language overview of the independent claims

There are eleven independent claims: 1, 3, 9, 15, 17, 18, 28, 29, 30, 31 and 34.

Claim 1 — Method: type-adaptive compression with rate control. Determine which of several data types the input data is; pick at least one compression method because of that identified type; compress with the picked method; and receive a "data compression rate control indicator" for varying the compression rate.

Claim 3 — Method: type-adaptive compression with memory allocation. Same identify → select → compress core, plus allocating memory for compression in an amount that is substantially the greater of an initial (floor) allocation and the memory actually necessary to compress that input data.

Claim 9 — Method: type-adaptive compression plus matched decompression. Same identify → select → compress core, plus a decompression process: receive compressed data, retrieve the data-type information from it, and select at least one decompression method in response to that retrieved type information.

Claim 15 — Method: explicit data-type indicator and rate control. Receive input data of a specific type; identify the type; generate a data type indicator; select a compression method from a set of methods in response to that indicator; compress; and receive a compression-rate control indicator.

Claim 17 — Method: memory-estimation variant. Same receive/identify/generate-indicator/select/compress front end, plus determining the system memory allocation by (a) estimating a range of memory required to compress the input data and (b) allocating the estimated range.

Claim 18 — Method: LZ-1 implementation. Same front end, where the set of available compression methods includes an LZ-1 (sliding-window Ziv–Lempel) method.

Claim 28 — Method: indicator-driven compression with decompression. Same front end (receive, identify, generate indicator, select, compress), plus receiving compressed data, retrieving its data-type information, and selecting a decompression method to decompress it in response to the retrieved information.

Claim 29 — System: pre-compression + compression with rate adjustment. A data pre-compression system identifies the data type of uncompressed input and generates a type-identification signal; a compression system receives the data and the signal and compresses using method(s) selected in response to the signal; and the compression system includes data-compression-rate adjustment means.

Claim 30 — System: pre-compression + compression with memory allocation means. Same two-subsystem architecture, but the compression system includes memory allocation means that allocates an amount substantially equal to the greater of an initial amount and the amount necessary to compress the uncompressed data.

Claim 31 — System: compression side + retrieval-driven decompression side. Pre-compression system and compression system as above, plus a data pre-decompression system that receives compressed data, retrieves its associated data-type information and generates a compressed-data type signal; and a decompression system that receives both and selects a decompression method in response to that signal.

Claim 34 — Method: LZ-2 implementation. Same front end, where the set of compression methods includes an LZ-2 (dictionary/index) method.

Dependent claims worth noting (they carry the practical detail)

• ASCII / unicode / binary determination (claims 4–6, 10–12).
• Type-detection tests: whether a byte exceeds a predetermined value, or whether selected bytes are identical (claims 7–8, 13–14).
• p_max and/or l_max selection (claims 22, 26, 27), and adjusting p_max/l_max or switching LZ-1↔LZ-2 in response to the rate control indicator (claims 23–24).
• Huffman-type and Arithmetic-code options layered on the LZ stage (claims 19–21).
• Rate-adjustment and memory-allocation means appended to the system claims (claims 32–33).

The specification's Table 1 gives the tuning ranges: ASCII — p_max 2K–8K bytes, l_max 16–2048 bytes; Binary — p_max 16K–32K bytes, l_max 16–256 bytes.

---

Post-issuance activity (what I could actually find)

• Never appears to have been asserted as a patent-in-suit in anything my searches surfaced. Its documented role is almost entirely as prior art — which is consistent with it expiring in 2012.
• IPR2017-00108 (PTAB, filed Oct. 24, 2016) — an inter partes review of U.S. 9,054,728 (Realtime Data). Exhibit 1010-5 in that proceeding is a copy of U.S. 5,467,087 (Chu). The exhibit footer reads "ORACLE 1010."
• Realtime Data patents — U.S. 7,714,747 and U.S. 8,933,825 describe the Chu patent by name as the closest prior approach ("An alternative technique … is disclosed, for example, in U.S. Pat. No. 5,467,087 to Chu entitled 'High Speed Lossless Data Compression System'") and then criticize it — notably that unambiguously identifying data types is impractical, and that predicting which encoder yields the best ratio is hard.
• Apple invalidity contentions — "5,467,087 to Chu" appears in Defendant Apple Inc.'s invalidity contentions (Ex. 1039-57 in IPR2016-01738, referencing N.D. Cal. Case No. 4:16-cv-02595-JD), i.e. used as prior art against a later reissue/continuation-family patent.
• European Search Report, EP3304746A4 — Chu '087 is cited as an X (highly relevant) document against claims 1–37 of that application, pointing to columns 1–2 and 4–6 and FIGS. 4–6 and 8.

CAFC 2026 dockets — explicit finding

No Federal Circuit appeal, 2026 or otherwise, naming U.S. Patent 5,467,087 was located. Given the patent expired 2012-12-18, an appeal of a merits decision on this patent in 2026 would be unusual; what a 2026 docket search does surface are appeals and PTAB/IITC fights over other "’087" patents, which I deliberately excluded.

Where I am not certain

• I could not verify from an authoritative source whether application Ser. No. 07/993,181 issued, and under what number — the '087 specification only identifies it as a copending, commonly owned application.
• I could not confirm via PatentCenter whether any reissue, reexamination or disclaimer touched 5,467,087; the Google Patents record shows none, and it shows the simple expired-for-term status.
• The "current assignee = Apple Inc." line on Google Patents reflects the 2007 Apple Computer, Inc. → Apple Inc. name-change assignment; I did not independently retrieve the recorded assignment document.

I'll search for litigation involving US patent 5467087.

Initial searches didn't surface direct litigation. Let me search more targeted sources.

Litigation Search Report — U.S. Patent No. 5,467,087

Bottom line

I found no evidence of any litigation involving U.S. Patent No. 5,467,087. Based on searches of the sources available to me (Google Patents/Patents full record, aggregated litigation-oriented results, PTAB filings, and general web search), the patent does not appear in any district court, ITC, or Federal Circuit proceeding that I could identify.

I am flagging this as a negative result, not a certified "never litigated" finding — see the caveats at the end.

Patent identification (as stated in the record)

Search results

No case captions, docket numbers, or complaints naming US 5,467,087 were located. The only references to the number "5467087" that surfaced were false positives unrelated to this patent:

1. Prior-art citations during other patents' prosecution — e.g., the number appears in an information-disclosure listing in the file history of US 7,181,608 (IPR2016-01365, Exhibit 1002), and in a European search report (EP 3 304 746 A4) citing "US 5467087 A (CHU KE-CHIANG)". These are citations to the patent as prior art — not litigation.
2. A Westlaw citation number, not a patent — "2013 WL 5467087" in 976 F. Supp. 2d 577 (courtlistener.com). Coincidental numeric match.
3. An unrelated registry number — "Pranešimo Nr. 5467087" in the Lithuanian business registry. Not a patent.
4. "The '087 Patent" in Netlist, Inc. cases — This is the most important one to not conflate. Reports of Netlist, Inc. v. Samsung Electronics, Netlist v. Micron, and the related ITC Investigation No. 337-TA-1472 concern Netlist's U.S. Patent No. 12,308,087 (a memory/DRAM patent), not Chu's 5,467,087. Different patent, different owner, different technology. I excluded these.

Notes for a clearance/licensing analysis

• The patent expired on December 18, 2012, so it cannot be asserted today and no present litigation would be expected.
• It was issued to and remained with Apple Computer, Inc./Apple Inc. (assignment recorded 1995 and 2007). If you need to confirm whether historical enforcement ever occurred, the authoritative places to check are PACER dockets, the Unified Patents litigation portal (portal.unifiedpatents.com/litigation), RPX Insight, Lex Machina, and Docket Navigator — all of which are paywalled or access-restricted and could not be queried directly here.

Caveats (stated explicitly)

• My search did not return a direct, authoritative docket query for this exact patent number. My conclusion rests on the absence of any matching litigation record in the results retrieved, not on a confirmed null result from a litigation database.
• Accordingly, I cannot state with high confidence that the patent was never litigated. Older district court cases from the 1990s may not be comprehensively indexed in freely searchable sources.
• I did not auto-correct any identifier. Where the number 5467087 appeared, I treated it literally and distinguished it from look-alikes such as 12,308,087 and the Westlaw citation 2013 WL 5467087.

If you can grant access to a docket database or the Unified Patents/RPX portals, I can run the exact-case-list query and confirm whether the negative result holds.

Proceedings overview

Zero AIA trial proceedings are on file for US 5,467,087 — the USPTO ODP structured block returns no IPR, PGR, or CBM for this patent, and targeted web searches surfaced none, meaning there is no claims-invalidated proceeding to hand you, no FWD to quote, and no petitioner estoppel to exploit; the patent instead reached its anticipated expiration on 2012-12-18 (status: Expired - Lifetime), so the defensive value is not "IPR victory" but "expired art / past-damages-only exposure" — see the strategic summary for how to convert that into a defense.

---

Proceedings on file

None — no petitioner has ever challenged US 5,467,087 at the PTAB

No proceeding numbers exist to enumerate. I will not generate placeholders, because the constraint against fabricating proceeding numbers is absolute. For completeness, here is what the negative result means at each field you asked about:

• Type: N/A — no IPR / PGR / CBM docketed.
• Filed: N/A.
• Status: N/A (canonical source: USPTO Open Data Portal ingest for US 5,467,087 reports no AIA trial proceedings).
• Judge panel: N/A.
• Petition grounds: N/A.
• Institution decision: N/A.
• Final Written Decision: N/A — no claims of the '087 patent have been canceled, narrowed, or confirmed in an AIA trial. All 34 claims remain as issued (claims 1–34, as printed in the patent).
• Settlement / termination: N/A.
• Appeal: N/A — no FWD, therefore no CAFC appeal of one.
• Defensive value: The absence of IPR activity is itself the signal — see below. Practically, a defendant's leverage comes from (a) the 2012-12-18 expiration, and (b) the fact that the '087 disclosure is already being used as prior art against third parties, which tells you how a § 102/§ 103 attack on it would likely be built.

Adjacent activity worth flagging (not a proceeding on this patent): the '087 patent appears as a prior-art exhibit in the Realtime Data IPR family — PTAB petitions in IPR2017-00108 (Oracle v. Realtime Data, on U.S. Pat. No. 9,054,728) cite Chu's data compression rate adjustment process 130 as "Chu" in an obviousness combination, referencing Ex. 1105 / the '087 specification at 6:3–7, 6:13–15, 6:54–59 and FIGs. 5–6 (PTAB petition record). The patent is likewise an "X" category citation against later compression filings (e.g., EP 3 304 746 A4, citing US 5,467,087 for claims 1–37 as anticipating/rendering obvious) and is discussed substantively in EP 1 330 038 B1. Search results ingested 2026-09-26; no older or recently-filed PTAB proceeding was found that the ODP might not yet have indexed.

---

Strategic summary

Claim status: all claims untested and technically alive, but the patent is expired. No claim of US 5,467,087 has been canceled, narrowed by amendment, or confirmed in an AIA trial. Claims 1–34 stand exactly as issued on 1995-11-14. The claims that "matter" are the four independent claims — claim 1 (identify data type → select compression method → compress; plus rate control), claim 9 (adds decompression/type-retrieval), claim 15 (data type indicator + selection; plus rate control), claim 17 (memory allocation estimation), claim 18 (LZ-1-based set), claim 28 (compression + decompression selection), claims 29–31 (system claims, with rate-adjustment means, memory-allocation means, and pre-decompression/decompression subsystems respectively), plus claim 34 (LZ-2-based) — along with the dependents that recite p_max/l_max selection and LZ-1/LZ-2/Huffman/Arithmetic combinations. The critical fact is the legal-status entry: anticipated expiration 2012-12-18, with the patent now Expired - Lifetime. That caps prospective relief at zero and confines any case to past damages under 35 U.S.C. § 286 (six years back from the complaint, further trimmed by § 287 marking/notice and laches-type equitable defenses).

Estoppel landscape: there is none — and that cuts in a defendant's favor on cost, not on substance. Because no petitioner ever reached a Final Written Decision, § 315(e)(2) estoppel never attached to anyone. No party is barred from raising § 102 or § 103 grounds, and equally, no defendant inherits a ready-made invalidity record from a prior petitioner. There is no IPR FWD to cite as collateral estoppel or as a claim-construction anchor, and no IPR record to mine for expert testimony. Any invalidity theory must be built from scratch — in district court under pre-AIA §§ 102/103 (the application was filed 1992-12-18, well before the AIA), or via ex parte reexamination, which remains available even on an expired patent and is the cheapest route to a cancellation certificate. Note that an IPR remains legally available on an expired patent, but with no injunction possible and only backward-looking damages exposure, the economics rarely justify one.

Pattern signals: this is a low-assertion, prior-art-for-others patent, not a troll vehicle. The patent's current assignee is Apple Inc. (originally Apple Computer, Inc.; inventor Ke-Chiang Chu), i.e., the same family that produced the concurrently filed application Ser. No. 07/993,181, which matured into related Chu compression patents (e.g., US 5,530,645 and US 5,640,551). There is no serial petitioner, no Unified Patents-style defensive-aggregator challenge, and no PTAB appeal history associated with this number. The more notable signal is the inverse: the '087 patent has become a tool in other people's disputes, cited as § 102/103 art against Realtime Data's compression patents and as an X-reference in later EPO prosecution. In other words, the industry treats this specification as prior art, not as a threat. If a demand letter now cites US 5,467,087, that is an unusual posture and should itself prompt diligence on chain of title and on whether the asserted claims are being read consistently with the specification's actual LZ-1/LZ-2/Huffman framework.

---

Recommended next steps

1. No PTAB activity to exploit or defend against. State it plainly in any opinion letter: there is no IPR/PGR/CBM on US 5,467,087, so there is no FWD to link, no canceled claim set, and no § 315(e)(2) estoppel to assert or fear. If you were expecting a "claims 1–5 are canceled" silver bullet, it does not exist — verify against PTAB E2E and the patent's Google Patents page before responding to a demand.
2. Lead with expiration and § 286, not invalidity. The patent expired 2012-12-18. Confirm the maintenance-fee/expiration record in USPTO Patent Center, then map any accused conduct to the six-year lookback window (complaint date minus six years). For most modern products, the exposure is either zero or concentrated in legacy conduct — often the single most efficient defense available, and far cheaper than an invalidity case on a 34-claim, 1992-priority patent.
3. If past damages are genuinely on the table, build the § 102/103 record in district court or by ex parte reexam. The productive references are the ones the patent itself frames as prior art — the Ziv/Lempel papers (IEEE Trans. Info. Theory, 1977 and 1978), Welch's LZW article (IEEE Computer, June 1984), Fiala & Greene "Data Compression with Finite Windows" (CACM, April 1989), and the ARC utility — plus the '087 patent's own admissions that ASCII/binary/unicode detection and LZ-1/LZ-2/Huffman selection were known. The examiner's cited art (US 4,558,302 to Welch; US 5,040,585 to IBM; US 5,240,867 to IBM; US 5,247,638 to StorageTek; JP 2-262766) is a starting point, not the ceiling.
4. Watch for the '087 patent in the Realtime Data / Oracle IPR record. Because Chu is being used as an obviousness reference there, the petition exhibits and any institution/FWD reasoning in IPR2017-00108 and sibling Realtime Data IPRs give you a free, curated reading of the '087 specification by qualified experts — useful as § 282 notice material and as a source of admission-style characterizations of the disclosure. Docket them via PTAB E2E and, for any appeal, CourtListener.
5. Diligence the demand letter itself. If an assertion arrives on a patent that expired in 2012 and never attracted a single IPR, scrutinize standing and title (the 2007 Apple Computer → Apple Inc. assignment), the identity of the real party in interest, and whether pre-suit notice/marking supports any § 286 recovery at all. The absence of PTAB activity on a patent this old is a meaningful tell: it is not a well-asserted patent that defendants chose to fight, it is one that nobody thought worth attacking because it was allowed to lapse.

I'll research this patent's ownership record using live sources before reconstructing the chain.

Let me pin down the Apple change-of-name recording details and check for any assertion activity.

Ownership & Assignment Reconstruction — US 5,467,087

Patent: High speed lossless data compression system
Inventor of record: Ke-Chiang Chu · Original assignee: Apple Computer, Inc. (California)
App. 07/992,972 filed 1992‑12‑18 · Issued 1995‑11‑14 · Status: Expired – Lifetime (anticipated expiration 2012‑12‑18)

Data caveat up front. The Assignment Center's per‑patent "Assignment Abstract of Title" page could not be machine‑retrieved in this session (the portal is a JS search application, not a crawlable record). The assignment events below are taken from the Google Patents legal‑events record, which is auto‑generated from the same USPTO assignment data. The exact reel/frame numbers and the recorded correspondent for each event were not obtainable, so I have not invented them. Where reel/frame appears below it is explicitly attributed to a source rather than asserted for this patent.

---

Inventors

• No unusual departure pattern. Chu is a prolific Apple inventor — indexed at ~38 lifetime patents, ~34 assigned to Apple — with a continuous stream of Apple‑assigned compression/imaging filings across 1990–1999 (e.g. US 5,305,295; US 5,374,916; US 5,444,445; US 5,431,... compression codebook/encryption patents). He did not exit the assignee around filing; the inventor‑to‑assignee relationship is the ordinary employer/employee assignment.
• Sibling case: the specification cross‑references concurrently filed App. Ser. No. 07/993,181 (Dec. 18, 1992), commonly owned — this is US 5,374,916, Automatic Electronic Data Type Identification Process (also Chu / Apple). It is a separate patent and is not part of this chain, but it confirms both filings are first‑party Apple work.

Original assignee

• Entity on the face of the patent: Apple Computer, Inc., a California corporation (1 Infinite Loop, Cupertino, CA 95014).
• Line of business: consumer/enterprise computer hardware and system software — an operating company, not a holding vehicle.
• Product embodiment: Apple is a shipping manufacturer, and this patent family sits squarely in Apple's own data‑compression/system‑software R&D (the sibling Chu filings cover codebook encryption, compressed‑data storage/access, and Unicode compression). I could not independently confirm a specific Apple shipping product that reads on the granted claims, so I state that as unverified rather than asserted.
• Current status: Operating. Renamed Apple Computer, Inc. → Apple Inc. effective 2007‑01‑09 (California Corporations Code §1110(d) merger of a wholly‑owned subsidiary), per Apple's Form 8‑K filed 2007‑01‑10. Apple Inc. is today's assignee of record.

Assignment timeline

Two recorded events only. Both are first‑party (inventor → Apple, then Apple's own name change). There is no third‑party or NPE transfer anywhere in this chain.

• 1992‑12‑18 (executed/recorded same date) — Reel/frame not retrievable in this session

  • Conveyance: Assignment of Assignors Interest (original employment assignment, recorded at filing)
  • Assignor: Ke-Chiang Chu
  • Assignee: Apple Computer, Inc. (California corporation)
  • Correspondent: not retrievable — no correspondent is exposed in the Google Patents legal‑events feed
  • Context: original inventor assignment to employer at time of filing.

• 2007‑01‑09 (executed) / recorded 2007‑05‑15 per Google Patents legal events — Reel/frame not retrievable in this session

  • Conveyance: Change of Name (carried in the record as an assignment; assignor listed as "Apple Computer, Inc., a California corporation")
  • Assignor: Apple Computer, Inc.
  • Assignee: Apple Inc.
  • Correspondent: not retrievable — Apple's own name‑change recordings during this period were handled in bulk under internal/trademark counsel of record; a single repeat NPE‑style correspondent does not appear.
  • Context: pure corporate renaming — same economic owner, no change in beneficial ownership, no consideration to a third party. This is not a transfer.

Reference only (from other Apple records, not asserted for this patent): Apple's 2007 name‑change recordings appear under multiple reel/frames across the Office because they were recorded in batches — e.g. 3469/0280 (recorded Jan 26 2007), 3478/0408 (recorded Feb 8 2007), 019265/0961, 020638/0127. To confirm US 5,467,087's specific reel/frame and correspondent, run the patent‑number lookup in the Assignment Center (link in the Verdict section). I deliberately do not map any of the above numbers onto this patent.

Timeline diagram

timeline
    title Ownership of US 5467087
    1992 : Filed by Apple Computer Inc
         : Chu assigns rights to Apple
    1995 : Patent issued
    2007 : Apple Computer renamed Apple Inc
    2012 : Patent expired

---

NPE / troll‑pattern signals

Note on the patent's appearance in litigation documents. US 5,467,087 shows up in PTAB/IPR papers and district‑court filings only as prior art / a cited reference — e.g. it is cited in the Realtime Data IPR record and in Realtime Data defendants' invalidity contentions (alongside US 5,374,916). It also appears in BTG International's WO 2004/012338 search report as a "Y" reference. In every instance the patent is being cited against someone else, by Realtime Data's adversaries or by an examiner — not asserted by Apple and not asserted by any NPE. That is a meaningful negative signal on assertion activity.

---

Verdict

Insufficient data — narrowly, and for a specific reason: the chain contains no third‑party assignment to analyze.

This is not a case of an empty record; it is a case of a record that never left the original assignee. The only two events are (a) Chu's original 1992‑12‑18 assignment to Apple Computer, Inc. and (b) Apple's 2007‑01‑09 change of name to Apple Inc. — the same corporation, not a transfer. No reel/frame in the chain records a sale, security interest, merger‑into‑NPE, or defensive‑aggregator acquisition, and no assignee is a known asserter. Per the rubric, "only the original assignment" maps to Insufficient data; the correct substantive reading is original‑assignee‑retained, non‑NPE. The patent expired 2012‑12‑18 and is now in the public domain.

Verify at: USPTO Assignment Center — https://assignment.uspto.gov/patent/index.html (search patent number 5467087 to pull the recorded reel/frame and correspondent for the two events above; that is the one field I could not retrieve here).

Caveats (honesty markers): (1) Exact reel/frame numbers for this patent's two events were not obtained — none are fabricated above. (2) No evidence was found that Apple ever shipped a product specifically reading on the granted claims, nor that Apple ever asserted this patent; treat "operating‑company embodiment" as plausible but unverified.

I'll verify the target patent and each cited reference against live sources before mapping them to § 102.

Let me verify the remaining cited references.

Prior-Art Analysis — U.S. Patent No. 5,467,087 (Chu)

Target patent confirmed: US 5,467,087 A, "High speed lossless data compression system," Ke-Chiang Chu, Appl. No. 07/992,972, filed 1992-12-18, granted 1995-11-14, Apple Computer, Inc., 34 claims / 8 sheets, status Expired – Lifetime (anticipated expiration 2012-12-18). Source: https://patents.google.com/patent/US5467087/en. The examiner-cited art was also reproduced verbatim from the letters patent front page in IPR2017-00108, Ex. 1010-5 (footer "ORACLE 1010"), which I used to cross-check the [56] list and the named inventors.

Because the application was filed 1992-12-18, pre-AIA 35 U.S.C. § 102 governs throughout. I have kept every identifier exactly as printed (see the flagged discrepancies at the end).

---

1. How I applied § 102 (method note, so the claim mapping is auditable)

Anticipation under § 102 requires a single reference that discloses every element of the claim, arranged as the claim arranges them. A reference that discloses most elements is not anticipatory — it is § 103 material (which the earlier Obviousness section already covers; I do not repeat it here). The § 102 categories available against this application:

• § 102(b) — patented or described in a printed publication more than one year before 1992-12-18, i.e. before 1991-12-18.
• § 102(a) — known/used/patented/published before the applicant's invention date (no earlier-publication bar needed).
• § 102(e) — described in a U.S. patent granted on an application filed by another before the applicant's invention, effective as of the reference's U.S. filing date. Several of the examiner's citations were granted after Chu's filing and are § 102(e) art for that reason.

---

2. The complete [56] reference set — citation, dates, § 102 status

The record lists 8 patent documents (9 counting the B1 reexamination certificate), 1 foreign patent document, and 7 unique non-patent items (the Google Patents feed shows "13" NPL entries because 6 are duplicated/OCR-twinned). Every one appears on the patent's front page and in the Oracle exhibit.

Non-patent literature (§ 102(b) printed publications, all predating 1991-12-18): Ziv & Lempel, IEEE Trans. IT 23(3):337–343 (May 1977); Ziv & Lempel, IEEE Trans. IT 24(5):530–536 (Sep. 1978); Welch, IEEE Computer, pp. 8–19 (June 1984); Elias, IEEE Trans. IT (Mar. 1975), pp. 194–203; "Riala" & Greene, CACM 32(4):490–504 (Apr. 1989); Bell, Cleary & Witten, Text Compression (Prentice-Hall 1990), pp. 206–243; ARC File Archive Utility v5.1 (System Enhancement Associates, © 1985, 1986), p. 2.

---

3. Reference-by-reference § 102 analysis

P1 — US 3,394,352 (Wernikoff / Electronic Image Systems), 1968-07-23 — § 102(b)

Description: Early code-communication / variable-length coding-and-decoding apparatus. Its significance here is second-hand and important: US 5,045,852 (P7) expressly characterizes US 3,394,352 as prior-art model selection of the deterministic kind — "using measures cleverly derived from the data structure … making it effectively a single, more complex, model." I did not independently retrieve the '352 text, so treat its specific disclosure as inferred from P7's characterization.
Claims potentially anticipated: None. It predates the LZ art entirely and discloses no "data type" identification step and no LZ/Huffman selection responsive to a data type. Best role: § 102(a)/(b) background showing data-characteristic-driven coding was old.

P2 — US 4,558,302 (Welch / Sperry), 1985-12-10 — § 102(b)

Description (verified): The LZW patent — a compressor that parses an input stream into strings, searches a string table for the longest match, transmits the code signal for the match and stores an extended string (prefix + extension character); a companion decompressor receives the codes and rebuilds a matching string table. The specification states the data "may comprise … English language textual material, stored computer records" and that input characters "may be received in the form of eight-bit bytes … in a convenient code such as the ASCII format." Sources: https://patents.google.com/patent/[US4558302A](/patent/US4558302A)/en ; https://worldwide.espacenet.com/publicationDetails/biblio?CC=US&NR=[4558302](/patent/4558302) ; http://patentimages.storage.googleapis.com/2c/fc/25/2b29895a953f8f/US4558302.pdf.
Claims potentially anticipated: None as a whole. Welch discloses the "LZ-2" dictionary/index method and the matched decompression path — i.e., elements that '087 claim 34 ("the set of data compression methods comprises an LZ-2 data compression method"), claim 18's LZ family, and the decompression element of claims 9/28/31 presuppose. But Welch has no data-type identification and no type-responsive method selection, so it cannot, standing alone, meet any independent claim. It is the definitive § 102(b) anchor for the LZ-2 element of claims 18/21/34.

P3 — US 4,558,302 B1 (reexamination certificate, Unisys), 1994-01-04 — § 102(b) via the parent

Description: A reexamination certificate (B1) for the Welch patent; it adds no new disclosure and takes the effective date of the original patent (1985-12-10) for prior-art purposes. It is listed separately on the front page but is the same specification as P2.
Claims potentially anticipated: Same as P2 — none, and no independent claim. Purely cumulative art; the Unisys/GIF-era significance (per the W3C archive note that Unisys held 4,558,302) is commercial, not legal, against '087.

P4 — JP 2-262766 A (Fuji Photo Film), published 1990-10-25 — § 102(b)

Description: "Image data compressing method" (Int. Cl. H04N 1/41 per the front page). I could not retrieve the Japanese text in this session, so I state its disclosure as unverified/inferred from title and classification: content-responsive compression selection in the image domain, analogous to P6.
Claims potentially anticipated: None on the verified record. As with P6, it is the "analogous-art / type-responsive compression" § 102(a)–(b) backdrop for the identify→select core, and cannot meet the text/byte-stream data-type element of claims 4–8/10–14.

P5 — US 5,010,345 (Nagy / IBM), filed 1989-12-28, issued 1991-04-23 — § 102(b)

Description (verified): LZ compression using two data structures — a fixed-length history buffer (offset + length history references) and a lexicon (index lexicon references) — with literal references when no match exists. Expressly recites a "maximum history reference length value" (claimed at claim 6: "said longest string is equal to or less than a preselected maximum history reference length value"), teaches the 512/1,024/4,096 lexicon variants, and discusses that the large-table string-extension technique "requires substantial memory and a fast central processing unit," with "memory … generally a greater problem than execution speed." Sources: https://patents.google.com/patent/US5010345 ; https://www.freepatentsonline.com/[5010345](/patent/5010345).html.
Claims potentially anticipated: None (no data-type identification anywhere; it is a fixed single-method compressor). It is, however, the strongest single-reference § 102(b) disclosure of the parameter that '087 turns on: the maximum match length l — directly material to claims 22, 26, 27 (p_max/l_max selection) and to the memory-sizing rationale of claims 3/17/30/33, which are § 103 points, not § 102.

P6 — US 5,220,417 (Sugiura / Canon), US filed 1991-11-27, issued 1993-06-15 — § 102(e)

Description (verified): "discrimination means for discriminating a color/black-and-white status of an input original" + "compression means for compressing image data … with different compression methods in accordance with a result of discrimination by the discrimination means." Claim 26 recites first/second compression means and setting means for a first mode (selection "in accordance with a color/black-and-white status of the input image data") and a second mode (selection "in accordance with a manual key input"); claim 27 adds discrimination means that automatically discriminates the status. The stated object: "compression efficiency can be greatly increased." Sources: https://patents.google.com/patent/US5220417 ; https://uspto.report/patent/grant/[5220417](/patent/5220417).
Claims potentially anticipated: This is the single closest anticipatory candidate in the whole record, and it maps onto the pre-compression→selection→compression core of claims 1, 15, 18, 28, 34 and to the manual/second-mode input.

• If "data type" is construed to cover a discriminated characteristic of the input image (color vs. B/W), P6 could arguably anticipate the three-element core common to those claims.
• On the strict reading I would defend, it does not anticipate any of them: (i) '417's discrimination is an image color/tonal status, not "the specific data type of the set of input data" in the ASCII/binary/unicode sense the specification (and claims 4–8/10–14) require; (ii) '417's manual key selects which compressor, and therefore cannot meet the "rate control indicator" element of claims 1/15/23/24; and (iii) it discloses no memory-allocation, no p_max/l_max, and no LZ/Huffman/Arithmetic set.
  Net: P6 is a strong § 102(e) reference for the selection element and the best § 103 primary reference, but I would not assert clean anticipation of any claim of '087 on it alone.

P7 — US 5,045,852 (Mitchell, Pennebaker & Rissanen / IBM), filed 1990-03-30, issued 1991-09-03 — § 102(b)

Description (verified): "Dynamic model selection during data compression." At least two compression models are run and compared; the model with the best performance for a block is selected and only its block is used in the output. Claim 4 recites "coding a model identifier at the start of each block of compressed data indicative of the model producing the respective block," and claim 5 states "said model identifier is used to decode the compressed data block." Disclosure states the technique "is totally general, and can be applied to virtually any data compression problem where two or more models exist, and can use any form of compression coding"; names Huffman coding as an example and uses an adaptive arithmetic coder. Sources: https://patents.google.com/patent/[US5045852A](/patent/US5045852A) ; https://pubchem.ncbi.nlm.nih.gov/patent/EP-0448802-A2 (EP 0448802 A2, priority 1990-03-30, publ. 1991-10-02).
Claims potentially anticipated: None — its selection criterion is measured coding performance, not an identified data type of the input, so it cannot meet the identifying step of any independent claim.
Why it still matters under § 102: P7 is the cleanest single-reference § 102(b) showing of the decompression-side loop of claims 9/25/28/31 — i.e., the compressed stream carries a selection identifier, and the identifier is used to select the decoder. On the retrieve-type-information → select-decompressor sub-elements, P7 is the most direct anticipation-style disclosure in the record; only the "data type" qualifier keeps it out of strict § 102 territory.

P8 — US 5,184,126 (Nagy / IBM), filed 1989-12-28, issued 1993-02-02 — § 102(e)

Description (verified): "Method of decompressing compressed data" — the companion decompressor to P5's format. It reads a sequence of literal / history / lexicon references, emits a lexicon string if the reference is lexicon, a history string if history, a literal string otherwise, and inserts the emitted string into a history buffer, adding it to the lexicon when the reference is a history reference. Sources: https://worldwide.espacenet.com/publicationDetails/biblio?CC=EP&NR=0435802A3 ; http://data.epo.org/publication-server/rest/v1.2/patents/EP0435802NWA2/document.html (EP 0 435 802 A3, IBM, inventor Nagy; US filing 1989-12-28). Because it issued after Chu's filing, only its filing date (1989-12-28) is available — § 102(e).
Claims potentially anticipated: None. P8 discloses a decompressor that follows one fixed format; it contains no retrieval of a data-type descriptor and no selection among decompressors. It is § 102(e) art for the decompression mechanism that the decompression claims presuppose (claims 9, 25, 28, 31, 32, 33) — § 103 material.

P9 — US 5,247,638 (O'Brien / Storage Technology), filed 1990-06-18, issued 1993-09-21 — § 102(e)

Description (verified): Compression within a dynamically mapped virtual data storage subsystem. It teaches that compression "has an efficiency that varies with the content of the data record," that the compressed size is "unknown until the completion of the data compression operation," and therefore space is allocated after compression; it also covers discarding the compressed form when it does not shrink the data. Sources: https://patents.google.com/patent/[US5247638A](/patent/US5247638A) ; https://patentimages.storage.googleapis.com/86/2e/f0/22b0b30048fd12/US5247638.pdf.
Claims potentially anticipated: None. P9 discloses no data-type identification and no compression-method selection, so it misses the identifying and selecting elements of every independent claim on which claims 3/17/30/33 depend.
Why it still matters under § 102(e): It is the closest single-reference disclosure of the "allocate ~ what the compression needs" idea — i.e., the memory-allocation element of claims 3, 17, 30, 33 — which is § 103 material, not § 102.

---

4. Consolidated § 102 claim map

Bottom line: No cited reference anticipates any of the 34 claims — and, after the specification's own admissions, the strongest § 102 candidate (US 5,220,417, § 102(e)) still misses the rate-control element of claims 1/15 and applies to an image, not a data-type, discrimination. The examiner's art does its work through § 103 combinations, which the Obviousness section already maps; I have deliberately not re-run that analysis here. (If your question is really "which single reference would I lead with in an invalidity chart," the answer is US 5,220,417 as primary + US 5,045,852 as secondary + Fiala & Greene/Mitchell 1990 for the rate element — i.e., § 103, not § 102.)

---

5. Non-patent literature — § 102(b) treatment (brief)

None of the seven NPL items identifies an input stream's data type and selects a compressor in response — so none anticipates. Their § 102(b) value is as element-level anchors: Ziv & Lempel 1977 = "LZ-1" (claims 18, 21, 34); Ziv & Lempel 1978 / Welch 1984 = "LZ-2" (claims 21, 34); Elias 1975 = integer/offset-length coding (claims 18/22); "Riala" & Greene 1989 = bounded-window (p_max) trade-off (claims 22, 23, 26, 27); Bell, Cleary & Witten 1990 and ARC v5.1 = speed-vs-ratio method choice as of the filing date. Because each is a printed publication predating 1991-12-18, each is squarely § 102(b) art — which matters if any claim is later argued to be limited to a specific one of these named techniques.

---

6. What the record is "missing" (useful for a § 102-vs-§ 103 decision)

• No single prior-art document identifies a byte stream's ASCII/binary/unicode character and then selects an LZ/Huffman/Arithmetic method in response. That is precisely the gap the specification admits ("prior art data manipulation processes do not include automatic detection of the data type of an input data stream"). The nearest references (P4, P6) do the analog in the image domain.
• No reference discloses a received rate-control signal that changes the compression rate/parameters. The patent's own characterization ties this to CPU idle-time scheduling, a systems-level goal rather than a compression-art teaching.
• Consequence: this is a § 103 record, not a § 102 record. Anticipation is essentially unavailable against this patent; obviousness is where the leverage lies.

---

7. Verification & citations

• Target patent: https://patents.google.com/patent/US5467087/en
• Front-page [56] list (independent reproduction): IPR2017-00108, Ex. 1010-5, "US Patent No. 5,467,087 Chu" — https://gaeflexstaging-dot-docketupdate.appspot.com/cases/[PTAB](/ptab)/IPR2017-00108/Inter_Partes_Review_of_U.S._Pat._9054728/10-24-2016-Petitioner/Exhibit-1010-5-US_Patent_No_5,467,087_Chu/
• US 4,558,302 — https://patents.google.com/patent/US4558302A/en ; https://worldwide.espacenet.com/publicationDetails/biblio?CC=US&NR=4558302 ; http://patentimages.storage.googleapis.com/2c/fc/25/2b29895a953f8f/US4558302.pdf ; Unisys-owned status: https://lists.w3.org/Archives/Public/www-html/1995Jan/0014.html
• US 5,010,345 — https://patents.google.com/patent/US5010345 ; https://www.freepatentsonline.com/5010345.html ; https://uspto.report/patent/grant/5010345
• US 5,045,852 — https://patents.google.com/patent/US5045852A ; https://pubchem.ncbi.nlm.nih.gov/patent/EP-0448802-A2 ; https://uspto.report/patent/grant/5045852
• US 5,184,126 (EP 0 435 802 A3) — https://worldwide.espacenet.com/publicationDetails/biblio?CC=EP&NR=0435802A3 ; http://data.epo.org/publication-server/rest/v1.2/patents/EP0435802NWA2/document.html
• US 5,220,417 — https://patents.google.com/patent/US5220417 ; https://uspto.report/patent/grant/5220417
• US 5,247,638 — https://patents.google.com/patent/US5247638A ; https://patentimages.storage.googleapis.com/86/2e/f0/22b0b30048fd12/US5247638.pdf

Not independently verified in this session (disclosure characterized from the title, classification, and the patent's own discussion): US 3,394,352; JP 2-262766; and the specific textual content of the seven NPL items. Treat those characterizations as inferred, not verified.

---

8. Contradictions / identifier caveats I am flagging rather than silently fixing

1. "US 5,040,585" and "US 5,240,867" appear in the prior "Recommended next steps" section as examiner-cited IBM art. Neither number is on the '087 front page. The actual examiner citations are US 5,045,852 (IBM) and US 5,247,638 (Storage Technology — not IBM). I treat 5,040,585 and 5,240,867 as transcription slips and have not used them. Per the standing rule I did not auto-correct them.
2. "Edward R. Riala" (as printed in both Google Patents and the letters patent) vs. the known author of the CACM article — Edward R. Fiala. I reproduce "Riala" as the record prints it and note the likely spelling variance rather than correcting it.
3. Date discrepancy in the task headers: operating header says 2026-09-29; the "Current task" block says April 26, 2026; the summary/obviousness sections noted 2026-09-28 vs April 26, 2026. Nothing in a § 102 analysis of a patent that expired 2012-12-18 turns on this, but I flag it rather than pick one.
4. Citation-count variance: the Google Patents page presents both a "Citations (8)" panel and a "Patent Citations (9)" panel — the difference is the US 4,558,302 B1 reexamination certificate. The "Non-Patent Citations (13)" figure double-counts six items; there are seven unique NPL entries.

I'll verify the disclosures of the key cited references before mapping them to the claims.

Obviousness Analysis — U.S. Patent No. 5,467,087

"High speed lossless data compression system" — Ke-Chiang Chu, Apple Computer, Inc.
App. No. 07/992,972; filed 1992-12-18; granted 1995-11-14; expired 2012-12-18.

Note before starting: There is a date inconsistency in my instructions — the operating header says today is 2026-09-28, while the "Current task" block says April 26, 2026. Nothing in the analysis turns on it (the patent expired in 2012 regardless), but I am flagging it rather than silently picking one. Also, per the standing rule, I have not auto-corrected any patent number or identifier; all numbers below are reproduced exactly as they appear in the record.

---

1. Legal framework applied

Under Graham v. John Deere Co., 383 U.S. 1 (1966), and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), I assess: (a) scope and content of the prior art; (b) differences between the prior art and the claims; (c) level of ordinary skill; and (d) secondary considerations. Under KSR, a combination is obvious where the improvement is a "predictable use of prior art elements according to their established functions," where there is a "design incentive" or "market pressure," or where the claimed subject matter is an "obvious to try" selection from a finite number of identified, predictable solutions. The motivation need not be found in the references themselves — it may come from "the background knowledge, creativity, and common sense of the person of ordinary skill" (KSR, In re Kahn).

Critically, the specification's own Background section contains judicial admissions about the state of the art, which I treat as strong evidence of the pre-filing knowledge of a PHOSITA (see §3).

---

2. Level of ordinary skill

A PHOSITA here would be a person with a bachelor's degree in electrical engineering or computer science and 2–4 years of experience implementing lossless data compression for storage/transmission, familiar with the Ziv-Lempel ("LZ") family (LZ77/LZ78), Welch/LZW, Huffman, and arithmetic coding, and with the well-documented speed-versus-ratio trade-offs of sliding-window compressors. That is the level evidenced by the Text Compression textbook (Bell, Cleary & Witten, 1990) and the Communications of the ACM article (Riala & Greene, 1989) cited in the record.

---

3. The decisive admission in the specification

The patent's own Background states:

• "The compression ratio for each data compression technique, however, also varies depending on the data type of the input data stream."
• "Thus, for each data type, one or more data compression techniques can be identified which will provide an optimal data compression ratio according to that data type, while other data compression techniques producing a lower compression ratio for that particular data type should be avoided."
• "However, despite the variety of data types that are commonly used in the industry, prior art data manipulation processes do not include automatic detection of the data type of an input data stream."

So the problem (match the compressor to the data type) and the solution architecture (identify type → select compressor) were acknowledged as known desiderata. The patent's asserted contribution is the automation of type detection and the bundling of that with rate and memory control. That posture makes the case materially weaker under §103 than the abstract suggests, because the goal was known and the components were each known.

---

4. The prior art and what each reference actually teaches

I verified the content of the most load-bearing references by search (sources in §9).

All of the above qualify as prior art: the 1968–1991 items under pre-AIA §102(a)/(b); US 5,184,126 and US 5,247,638 under §102(e) (both filed before 1992-12-18, though granted after); US 5,220,417 under §102(e) (US filing 1991-11-27) and §102(a)/(b) via JP priority/EP publication.

---

5. Difference between the claims and the prior art

Stripped of boilerplate, the independent claims reduce to a small number of elements:

1. Identify the data type of the input stream.
2. Select a compression method from a set in response to the identified type.
3. Compress with the selected method.
4. (Claims 1/15 family) also receive a rate-control indicator and vary compression rate (p_max/l_max, or LZ-1 vs. LZ-2).
5. (Claims 3/17 family) allocate memory ≈ max(initial amount, amount needed).
6. (Claims 9/28/31 family) on decompression, retrieve the type info from the compressed stream and select a matching decompressor.

Element 2 is squarely disclosed by US 5,220,417 (in the image domain) and US 5,045,852 (in the general compression domain). Element 1's existence is admitted as desirable in the specification's own Background. The only genuine gap in the cited art is element 1's automatic determination of ASCII/binary/Unicode from byte statistics in a text/stream context (claims 7–8 and 13–14), plus the specific "receive a rate control indicator" signal of claims 1/15/23/24.

---

6. Grounds of obviousness

Ground 1 — Claims 1, 2, 15, 16, 22, 23, 24, 26, 27

Primary: US 5,220,417 (Canon) in view of US 5,045,852 (IBM) and Riala & Greene (1989) / Bell-Cleary-Witten (1990).

• Canon '417 discloses, in haec verba, the core sequence: discriminate the input's type → select between plural compression methods in accordance with the discrimination result → compress. Its "second mode" (selection driven by a manual key input) additionally discloses a received control input that changes the compression path — the functional analogue of the claimed rate-control indicator.
• IBM '852 supplies the motivation and the reinforcement for the general case: model selection "is totally general, and can be applied to virtually any data compression problem where two or more models exist, and can use any form of compression coding." A PHOSITA reading '852 would understand that type- or content-driven selection is not special to images.
• Riala & Greene and Bell-Cleary-Witten supply the rate-control rationale: they quantify that shrinking the window/max-match length speeds compression at a cost in ratio. The patent's own ¶ on Table 1 states the identical principle ("Selecting a lower p_max typically increases the rate … while typically decreasing the compression ratio"), and the specification's stated purpose for the rate control — "to maximize the CPU's idle time to do data compression and … increase the data compression speed when the CPU is in preparation to begin another process" — is classic background/idle-time scheduling, a well-known design goal in multitasking operating systems.
• Motivation to combine: same field (lossless data compression); same problem (choose the compressor suited to the data); predictable result (better ratio at a chosen speed); and Canon '417 itself announces the benefit ("compression efficiency can be greatly increased"). Under KSR, a predictable solution to a recognized need drawn from a finite set (LZ-1, LZ-2, Huffman, arithmetic) is obvious to try.

Ground 2 — Claims 3, 17, 30, 33 (memory allocation)

Primary: US 5,247,638 (Storage Technology) in view of US 5,010,345 (IBM).

• '638 addresses precisely the recited problem: "compression … has an efficiency that varies with the content of the data record," the compressed size "is unknown until the completion of the data compression operation," and therefore storage space is allocated after compression. It further teaches comparing the compressed length against the original and substituting the original if compression did not help — i.e., allocating only what is needed. This maps onto "an amount of memory … substantially equal to the greater of an initial amount … and an amount … necessary to compress."
• IBM '345 supplies the memory-sizing rationale for LZ specifically: the method "requires substantial memory and a fast central processing unit," and lexicon/history-buffer size is a selectable design parameter — giving a PHOSITA a reason to estimate memory from the chosen algorithm and its parameters (exactly what claim 17 and dependent claims 22/26/27 recite).
• Motivation to combine: both references are about compression in memory-constrained systems; '638's teaching that compressed size is unknown until measured provides the reason to estimate and then increment, and '345 supplies the estimator variables.

Ground 3 — Claims 9–14, 25, 28, 31, 32, 33 (decompression side)

Primary: US 5,184,126 (IBM) in view of US 5,220,417 (Canon) and US 4,558,302 (Welch).

• IBM '126 is a method of decompressing the same LZ-class format generated by '345 — establishing that a matching decompression path selected for a given compressed format was conventional.
• Canon '417 teaches the transmission-side counterpart: selecting between first and second output means "in accordance with a kind of an apparatus at a party for transmission" and transmitting the compressed data so the receiver reconstructs it — i.e., the compressed stream carries the selection information needed by the decompressor. That anticipates "retrieving a data type information from the set of compressed data."
• Welch '302 teaches dictionary-based decompression with a decoder that reconstructs from the compressed stream.
• Judicial admission: the specification states that encoding the data type in "a header located at the beginning of an output data buffer" is "the typical standard used for denoting a data type of a data stream." That is an admission that header-based type signaling is conventional — dispositive against any argument that claim 9/28/31 add inventive weight here.
• IBM '852 additionally teaches transmitting the model-selection decision within the compressed stream so the decoder can reproduce the input — the exact "retrieve type info → select decompressor" loop.

Ground 4 — Claims 18, 19, 20, 21, 34 (LZ-1, LZ-2, Huffman, Arithmetic)

Primary: Ziv & Lempel 1977 and 1978 / Welch 1984 in view of US 5,045,852 and US 5,010,345.

• ZL77 = the patent's "LZ-1" (history buffer, (p,l) pointers); ZL78/Welch = "LZ-2" (dictionary indices). Both were individually old and their relative trade-off was documented — the patent itself says LZ-1 "provides a greater data compression ratio" while LZ-2 is faster. Placing both in a common "set" from which one is selected is the essence of obviousness: a finite, known menu.
• Huffman and arithmetic coding as second-stage entropy coders: IBM '852 expressly names Huffman and uses an adaptive arithmetic coder; Elias supplies integer-code construction. Cascading an entropy coder after an LZ stage was standard practice (see also ARC 5.1).
• Motivation to combine: predictable performance improvement from a bounded, enumerated set; KSR "obvious to try."

Ground 5 — Claim 24 (select LZ-1 vs. LZ-2 in response to rate control)

Primary: Ziv & Lempel 1977/1978 in view of US 5,045,852 and Riala & Greene.

IBM '852 teaches selecting among models on measured performance; Riala & Greene quantify the speed/ratio trade-off. Choosing the faster LZ-2 when faster throughput is demanded, and the higher-ratio LZ-1 otherwise, is a predictable use of known elements for their known functions — the paradigm case under KSR.

---

7. Claim-by-claim summary

Two structural observations worth noting: (i) the patent carries eleven independent claims (1, 3, 9, 15, 17, 18, 28, 29, 30, 31, 34) that recite nearly the same three-step core with rotating add-ons, and (ii) claim 34 is essentially the claim-1/15 core with "the set … comprises an LZ-2 data compression method" — an element taught by Ziv & Lempel 1978 and Welch 1984 standing alone. That claim density is itself a signal of a broad, thinly-differentiated claim set.

---

8. Candid assessment: where the claims are strongest

I will not overstate the case. The genuine vulnerabilities of the obviousness theory are:

1. No cited reference expressly discloses automatic ASCII/binary/Unicode detection of a byte stream. The specification admits this gap ("prior art data manipulation processes do not include automatic detection of the data type of an input data stream"), and the two references closest to that step — US 5,220,417 and JP 02-262766 — operate in the image domain (color vs. black-and-white). A patentee would argue non-analogous art and a missing express teaching. The counter is KSR's "field of endeavor" and "reasonable expectation of success" tests: both arts are data compression, both references are classified in compression classes, Canon '417 was cited by the examiner, and the disputed step is a measurement step whose output feeds an admitted selection step.
2. Claims 7, 8, 13, 14 (specific byte-value and byte-pair-identity detection algorithms) are the least well covered by the record. If those dependent claims matter commercially, additional art (e.g., contemporaneous file-type/encoding-detection literature and the UNIX file(1)-style heuristics) would be needed. I did not verify such art here, because the task scope is the record's Prior Art section.
3. The "rate control indicator" as a received signal (claims 1, 15, 23, 24) is arguably not shown as such; the closest is Canon '417's manual-key second mode plus R&G's trade-off teaching. This is a moderately strong point for the patentee, though the specification's own framing (idle-time CPU scheduling; lower p_max/l_max) makes the element small.
4. Secondary considerations. I found no evidence in the record of unexpected results, long-felt need, commercial success with nexus, or industry praise tied to these claims. The patent's Background actually frames the problem as long-known and the benefit as expected ("maximizing the compression ratio"). Absent objective evidence, the Graham factor (d) does not rebut prima facie obviousness.

Net: the independent claims (1, 3, 9, 15, 17, 18, 28, 29, 30, 31, 34) are vulnerable to a §103 challenge built on US 5,220,417 + US 5,045,852 + Riala & Greene, with US 5,247,638 + US 5,010,345 for the memory-allocation family and US 5,184,126 + US 4,558,302 for the decompression family. The strongest defense for the patentee rests on the specific detection algorithms of claims 7–8/13–14 and on the image-vs-text non-analogous-arts argument against US 5,220,417.

---

9. Verification notes / citations

I confirmed the substance of the four most load-bearing references rather than relying on titles:

• US 5,045,852 (dynamic model selection; "totally general"; arithmetic/Huffman; selection decision signaled in-stream) — https://patents.google.com/patent/[US5045852A](/patent/US5045852A) and https://patentimages.storage.googleapis.com/05/4c/4f/ec9062b193627c/EP0448802A3.pdf
• US 5,247,638 (compression efficiency varies with content; size unknown until compression completes; post-compression space allocation) — https://patents.google.com/patent/[US5247638A](/patent/US5247638A) and https://patentimages.storage.googleapis.com/86/2e/f0/22b0b30048fd12/US5247638.pdf
• US 5,220,417 (discrimination means + compression means selecting different compression methods in accordance with the discrimination result; auto/manual modes) — https://patents.google.com/patent/US5220417
• US 5,010,345 (history buffer + lexicon; "maximum history reference length"; substantial-memory discussion) — https://patents.google.com/patent/US5010345 and https://www.freepatentsonline.com/[5010345](/patent/5010345).html

I did not retrieve the full text of US 3,394,352, US 4,558,302, US 5,184,126, JP 02-262766, or the ARC/Riala-Greene/Elias/Bell-Cleary-Witten materials; the characterizations of those items above are drawn from their titles, the patent's own discussion of them, and established knowledge of the compression literature. Where I state a specific disclosure for those items, treat it as inferred, not verified — I have flagged the two steps that are genuinely weak (claims 7–8, 13–14 and the "rate control indicator") rather than papering over them.

Finally, a cross-reference to the prior section: because the patent expired 2012-12-18, any present challenge would be an ex parte reexamination or an invalidity opinion rather than an IPR/PGR in district-court-style litigation; the obviousness grounds above are unaffected by that status, but the practical vehicle is.