US 6820233

I'll run targeted searches for this specific patent number across patent and litigation sources.

The initial searches returned mostly unrelated documents. Let me refine with more specific queries.

Let me check specifically for any litigation or Federal Circuit activity involving this patent.

Patent 6820233 — Technical Summary

Sourcing note

The authoritative record below comes from the Google Patents full-text record for US6820233B2 (https://patents.google.com/patent/[US6820233](/patent/US6820233)/en), which is the patent-number match the user requested. I interpreted the identifier literally as US 6,820,233 B2 and did not substitute any similar number.

⚠️ Disambiguation flag: one search hit (a Hungarian IP-journal PDF) discusses a different patent numbered 6,627,233 (Wrigley chewing-gum / WS-23 case, Wm. Wrigley Jr. Co. v. Cadbury plc). That is a distinct 7‑digit number and is not the patent at issue. Do not conflate the two.

Bibliographic data

Abstract (as granted)

In packet communications that employ header compression/decompression, the computational complexity of checksum generation can be reduced by re-using static checksum information associated with header bits that do not change from header to header. The static checksum information can be used together with information about header bits that do change from header to header, in order to generate a desired checksum. The checksum can then be used to verify a reconstructed header produced from a compressed header by a header decompressor.

Plain-language overview of the independent claims

Claim 1 — Method (independent)

A method of generating checksums used by a receiving station to verify reconstructed headers (the reconstructed headers being the receiver's best reconstruction of the "target headers" that the transmitter compressed). Three steps:

1. Get static checksum information. The static portion = header fields that stay the same across every header in the packet flow (e.g., IP source/destination addresses). The static checksum information is produced by coding the static information from a preceding header in the flow (i.e., an earlier/context-update header — not the current target header itself).
2. Get "further information" representing the transient portion — the header bits that can differ from header to header (e.g., IP‑ID, RTP sequence number).
3. Combine the static checksum information with the further information to generate a checksum used to verify the reconstructed header corresponding to the target header.

Plain English: Instead of recomputing a CRC over the whole header every time (expensive, especially when the decompressor must test many successive header "guesses"), reuse the already-computed checksum contribution of the never-changing fields and only fold in the part that actually changed.

Claim 23 — Apparatus (independent)

The apparatus counterpart of claim 1, comprising:

• a first input receiving static checksum information associated with the static portion of a target header, the static checksum information being produced by coding static information from a header that precedes the target header in the packet flow;
• a second input receiving further information representative of the transient portion of the target header; and
• a combiner coupled to both inputs that combines the static checksum information and the further information to generate a checksum for verifying the reconstructed header.

Plain English: A hardware/software checksum-generator block with two input paths — the reusable "static" checksum state/component and the "changed bits" data — merged by a combiner (e.g., modulo‑2/XOR logic or a checksum register).

Notable dependent-claim features (context for the independent claims)

• Claims 3–8 (register-state approach): code the preceding context-update header's static bits into a checksum register without the transient bits, and store the register's coding state; on later headers, reload that stored state and shift in only the changing bits. Claims 5/6 add sorting the header to separate static from transient bits.
• Claims 9–11 (probability-sorted, multi-state): further sort the transient bits by probability of change (LSBs first, MSBs last) and store a coding state at each bit position, so that for a new header only the bits after the first changed bit need be shifted in; states are refreshed per guess/header.
• Claims 12–19 (checksum-component approach): a first checksum component for the static bits, plus a plurality of further checksum components each representing one transient bit position; combining is done by modulo‑2 addition of the selected components. Claim 18–19 add a second checksum component representing plural bit positions at once (the MSB-group optimization), combined with the others.
• Claim 20: the checksum is a CRC checksum.
• Claims 21–22 / 32–33: explicitly contemplate performance at either the receiving station (decompressor) or the transmitting station (compressor).

Technical gist of the disclosure

The specification relies on the linearity of cyclic redundancy codes — f(c₁+c₂) = f(c₁)+f(c₂) — so a full-header CRC can be assembled as C₀ (initial checksum with transient bits zeroed) XOR a precomputed per-bit checksum C_ei for each transient bit that is set (Equation 2), optionally with MSB-group checksums C_S0 / C_S+1 to cut the number of XOR operations further (Equations 3–4). Practically relevant to ROHC-style (Robust Header Compression) IP/RTP flows over wireless links.

Litigation / CAFC 2026 docket search — no matching results found

I searched for this patent number in connection with USPTO records, district-court/CAFC activity, and Ericsson enforcement generally. I found no CAFC 2026 docket (or any district-court case or PTAB proceeding) in which US 6,820,233 is the patent at issue. Specifically:

• The Google Patents record for US6820233B2 contains no litigation section, and its "Cited By / Families Citing" entries are all later patent documents, not case records.
• Searches surfaced numerous other Ericsson disputes (e.g., Ericsson Inc. v. [D-Link Corp.](/litigations/by-defendant/D-Link%20Corp.), E.D. Tex. 6:10‑cv‑00473; Ericsson v. Intellectual Ventures I, CAFC 16‑1671; Koninklijke KPN N.V. v. Ericsson, CAFC 23‑2217, dismissed by stipulation Jan. 24, 2024), but none of these lists US 6,820,233 among the asserted patents.
• The only CAFC-2026-adjacent hit was a Law360 item about a patent owner dropping an appeal against T‑Mobile and Ericsson; nothing ties it to 6,820,233.

Uncertainty / caveat: my toolset does not query PACER or the CAFC docket system directly, so this is an absence-of-evidence finding, not an authoritative "no litigation exists" confirmation. The patent expired 2022‑11‑09, which makes active assertion unlikely, but I cannot certify that no historical suit ever named it. If a definitive negative is required, run a formal search in USPTO Patent Center / Assignment, PACER (all districts), CAFC docket, and a commercial docket service (Lex Machina, Docket Navigator, CourtListener RECAP) using the literal string "6,820,233" / "6820233".

Key source

• Google Patents, US6820233B2: https://patents.google.com/patent/US6820233/en (full description, claims, family, citations, legal events)
• WO counterpart: https://patents.google.com/patent/WO2002007323A2/en (same family, priority 2000‑07‑14)

I'll search for litigation records involving US patent 6820233.

Let me search additional litigation-specific sources.

Let me run a few more targeted searches to confirm.

Summary of Findings

I found no litigation specifically involving U.S. Patent No. 6,820,233.

Based on my searches of patent litigation resources (Unified Patents litigation portal results, PACER-derived dockets via Justia/PacerMonitor, CourtListener, and general web search for the patent number), there are no known federal district court cases, ITC investigations, CAFC appeals, or PTAB proceedings (IPR/PGR) in which U.S. Patent No. 6,820,233 was asserted or challenged.

Searches Performed

Important Disambiguation (results that could be mistaken for this patent)

Several Ericsson cases surfaced, but none of them asserts 6,820,233:

• Ericsson Inc. v. D-Link Sys., Inc. (E.D. Tex. 6:10-cv-00473) — asserted U.S. Patent Nos. 6,772,215; 6,330,435; 6,466,568; 6,424,625; 6,519,223. The '223 number is 6,519,223, not the '233 patent, and it went to an 8‑day jury trial in June 2013.
• Telefonaktiebolaget LM Ericsson v. Lenovo (E.D.N.C. 5:23-cv-00714, 5:23-cv-00570) — asserted the '841, '659, '618, '613 and '178/'273 family patents.
• Ericsson Inc. v. Acer (D. Del. 1:26-cv-00176, consolidated with 1:25-cv-01106) — different patents; pending.
• Wireless Alliance, LLC v. AT&T Mobility (E.D. Tex. 2:23-cv-00095) — Ericsson intervened, but asserted patents are different.

These are all distinct patent numbers and should not be attributed to the '233 patent.

Patent Status (relevant context, not litigation)

Per the Google Patents record for US6820233B2:

• Assignee: Telefonaktiebolaget LM Ericsson AB
• Priority: 2000‑07‑14 (provisional 60/218,472); filed: 2001‑01‑02
• Granted: 2004‑11‑16
• Legal status: Expired – Lifetime, adjusted expiration 2022‑11‑09
• Family: EP1302049B1, JP5048200B2, CN1187944C, WO2002007323A2, DE60128359T2, ES2286126T3, ATE362265T1, AU2001267975A1

The patent expired in November 2022, which is consistent with (though not proof of) the absence of active assertion activity in recent years.

Caveats & Confidence

• Confidence: Moderate-to-high that no reported litigation names this patent. My searches did not exhaustively query PACER (a paid subscription database) or Docket Navigator/Lex Machina; a comprehensive PACER "patent number" search would be the authoritative confirmation.
• I could not directly retrieve a Unified Patents portal page keyed to this specific patent number (the tool does not resolve that portal's dynamic queries), so that resource is unconfirmed rather than affirmatively negative.
• No outcome/status table can be provided because no case was identified.

Bottom line: No known litigation or PTAB challenge involving U.S. Patent No. 6,820,233 was found. If you need a definitive negative, I recommend a direct PACER docket search on the patent number and a Docket Navigator/Lex Machina "patents asserted" query.

Proceedings overview

Total AIA trial proceedings on US 6,820,233: 0. Per the USPTO Open Data Portal structured block provided with this task, the ODP returns no AIA trial proceedings (no IPR, PGR, or CBM) for this patent as of the most recent ingest, and my independent web searches surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal involving this patent number. There is therefore no "claims invalidated / sustained / settled / institution denied" breakdown to report — all 33 claims stand exactly as they issued on 2004-11-16, and the defensive posture is the inverse of the usual "hardened by IPR" story: this is an untested, never-challenged patent at the PTAB, and one that has now expired (statutory term ended; Google Patents lists "Adjusted expiration 2022-11-09" and legal status "Expired – Lifetime"). For a defendant facing a demand today, the absence of PTAB activity means there is no free kill-shot in the record, but the expiration date is a far more powerful defense than any IPR outcome would have been.

No proceedings to rank

There are no IPR####-#####, PGR####-#####, or CBM####-##### numbers to list. I will not manufacture any. The Google Patents "Cited By / Families Citing" and "Cited By (17)" tables for this patent list only other patents and published applications — not PTAB trial numbers — which is consistent with a patent that was never the subject of an AIA trial.

One important false-positive to flag: search engines readily return IPR2021-00843, caption Alcon Inc., et al. v. AMO Development, LLC, which involves U.S. Patent No. 9,233,023 (the "'023" patent) — an ophthalmic laser-surgery patent. That is a different patent (nine-million series vs. six-million series) and has nothing to do with Ericsson's header-compression patent. Any docket list you build must not conflate 6,820,233 with 9,233,023.

Strategic summary

Claim status. All claims 1–33 are intact and untested. Nothing has been canceled, disclaimed, or held unpatentable. Claims 1 (method) and 23 (apparatus) are the independent claims; 2–22 and 24–33 are dependents. No claim has been narrowed by any adversarial proceeding. The only "narrowing" events are ordinary prosecution (the 2001-04-02 assignment and 2004-10-28 grant) — the file history shows no reissue, no reexam, and no certificate of correction beyond routine.

The decisive fact is expiration, not estoppel. § 315(e)(2) estoppel is a non-issue because there is no petitioner, and there is no party carrying estoppel into your case. More importantly, the patent's term has run: Google Patents records legal status "Expired – Lifetime" with adjusted expiration 2022-11-09, and the last maintenance-fee payment on file is the 12-year fee (2016-05-16). Practically, the only infringement exposure is for past conduct before the expiration date, and any damages theory would be limited to that historical window (plus the six-year § 286 look-back under the pre-expiration period). An IPR in 2026 on an expired patent would be procedurally viable only for claims covering past damages, and the Board has repeatedly declined to institute where the patent has expired and no live controversy over claim scope remains — so a defendant's better move is a § 101/§ 112 or invalidity defense in district court, or simply the expiration/limitations defenses, not a PTAB petition.

Pattern signals. There is no pattern to read. No serial petitioner, no defensive aggregator (Unified Patents, RPX, etc.) appears anywhere in the family or citation record. The patent's citation neighborhood is backward-looking only (it cites US 5,987,022 to Motorola; US 5,935,268 to Bay Networks; and WO 00/79763, Ericsson's own ROHC filing). None of those were raised in an AIA trial against this patent. The NPE/assertion history that typically precedes an IPR is also absent from the record I retrieved.

Recommended next steps

1. Do not build a defense around a PTAB record — there isn't one. Link your team to the absence itself: the ODP structured data lists zero proceedings, and no FWD or CAFC opinion exists for US 6,820,233 on Google Patents, PTAB E2E, or CourtListener. State it plainly in any invalidity/§ 285 memo.
2. Lead with expiration. Confirm the term date on USPTO PatentCenter for Application No. 09/753,365 (Google Patents shows adjusted expiration 2022-11-09, "Expired – Lifetime"). If a demand letter asserts ongoing infringement, the expiration date is a complete answer; if it asserts past damages, the § 286 six-year bar and laches/§ 282 limitations become the battleground.
3. If past-damages exposure is real, the strongest invalidity art is in the patent's own citation list: US 5,987,022 (Motorola) and US 5,935,268 (Bay Networks) for pre-computation/re-use of checksum state, plus WO 00/79763 (Ericsson ROHC) and the non-patent literature the examiner considered — Degermark et al., "RObust Checksum-based Header Compression (ROCCO)," IETF draft (2000-06-15), and Degermark et al., "Low-Loss TCP/IP Header Compression for Wireless Networks," Wireless Networks 3(5), 375–387 (1997). These are not estopped, since no IPR ever ran.
4. Mind the § 315(b) clock if you were served. Because there is no prior petition, the one-year IPR bar in § 315(b) is your only PTAB-timing constraint — but given expiration, weigh whether a petition is worth filing at all versus a district-court invalidity/expiration posture. Note the PTAB's statutory 1-year trial deadline and 6-month institution deadline would apply only if you file; with no proceeding pending, there are no institution-decision or FWD due dates to track.
5. Vet the number carefully before citing anything. Every "023" trial hit I found (e.g., IPR2021-00843) is for U.S. 9,233,023, not U.S. 6,820,233. Cross-check the application number 09/753,365 and priority date 2000-07-14 before relying on any docket entry.

Confidence note: I have high confidence there are no AIA trial proceedings on US 6,820,233, based on the ODP block (canonical) plus multiple targeted searches that returned only family members, citing documents, and the unrelated 9,233,023 Alcon IPR. I could not locate any district-court assertion or CAFC appeal either; if one exists, it is not in the sources I retrieved, and I am not asserting one does not exist.

I'll research the assignment record for this patent across USPTO sources and cross-reference.

Let me check more sources including assignment databases and NPE directories.

Let me try to retrieve the assignment records directly from USPTO and Google Patents.

Ownership Chain Analysis — US 6,820,233 B2

Sourcing note. The authoritative assignment data below comes from the Google Patents legal-events record for US6820233B2 (https://patents.google.com/patent/US6820233/en) and the family WO publication. I was unable to reach the USPTO Assignment Center UI directly (https://assignmentcenter.uspto.gov/ or https://assignment.uspto.gov/patent/index.html) within this session — the record below reflects what is indexed, and the one item I could not verify from the primary source is the correspondent attorney on the assignment recording (see the flagged uncertainty in the timeline). This does not alter the core finding: there is exactly one recorded assignment and no post-issuance transfer of any kind.

Inventors

Per the issued patent (US 6,820,233 B2) and the family WO publication WO 2002/007323 A2 (PCT/SE01/01493), all six named inventors assigned to Ericsson:

Pattern notes.

• Five of six inventors list Luleå, Sweden addresses — the location of Ericsson's Luleå R&D operation and Luleå University of Technology, consistent with an Ericsson-employed team. This is a normal corporate-inventor roster, not an "inventor-holds-then-sells" arrangement.
• Degermark is the outlier: Tucson, AZ, and independently documented as a co-author of the ROCCO header-compression IETF draft and the Low-Loss TCP/IP Header Compression for Wireless Networks paper (both cited as prior art/non-patent literature on the face of this patent). He is the well-known header-compression researcher of the group; his academic affiliation, not a corporate address, is the reason for the single US address.
• No evidence of inventors departing the assignee within 12 months of filing. I have no data on departures, and none is suggested by the record — flag this as unclear/not determinable, not as a negative finding.

Original assignee

Telefonaktiebolaget LM Ericsson (publ) — named as assignee on the issued patent and as applicant on the WO counterpart.

• Line of business: global telecommunications network-equipment vendor (radio access networks, core network, transport, and the ROHC/header-compression software used in its radio products). Ericsson is a publicly traded company (Nasdaq: ERIC; SEC Form 20-F filer) and a major standard-essential-patent (SEP) licensor in cellular standards.
• Did they ship a product embodying the claims? Yes — Ericsson implemented and productized Robust Header Compression (ROHC) in its radio network products, and this patent family was affirmatively declared to the IETF as IPR relevant to RFC 3095 ("RObust Header Compression (ROHC): Framework and four profiles"). The IPR statement was filed with the IETF on 2002-09-27 by Malin Gullstrand (EAB), Ericsson (https://ftp.ripe.net/ietf/IPR/ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt). That declaration is strong evidence the assignee practiced the technology in commerce.
• Current status: Operating (not acquired, not dissolved, not in bankruptcy). No assignment or change-of-name that would alter the original ownership appears in the record.

Assignment timeline

One recorded assignment; no post-issuance transfers.

• Executed 2001-01-15 → 2001-02-14 / Recorded 2001-04-02 — Reel 011657 / Frame 0465
  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS' INTEREST")
  • Assignor: Ingemar Johansson; Krister Svanbro; Lars-Erik Jonsson; Hans Hannu; Stefan Håkansson; Mikael Degermark (all six inventors)
  • Assignee: Telefonaktiebolaget LM Ericsson (publ), Stockholm, Sweden
  • Correspondent: ⚠️ Not confirmed from the primary source. The Google Patents legal-events entry for reel 011657/0465 lists only the conveyance and signing dates — it does not expose the recording correspondent attorney. What is on record elsewhere in the family is the prosecution agent: Malin Gullstrand, Ericsson Radio Systems AB, Patent Unit Research, S-164 80 Stockholm (named as agent on WO 2002/007323 A2). The same Malin Gullstrand (EAB) filed Ericsson's RFC 3095 IPR statement. I flag this as an in-house-Ericsson signature rather than a recurrence across an NPE chain — this is a single appearance on one link, so it does not meet the repeat-correspondent signal threshold. To confirm the assignment-record correspondent specifically, query reel 011657 / frame 0465 in the USPTO Assignment Center.
  • Context: Ordinary inventor-to-employer assignment executed within ~7 weeks of the US non-provisional filing (2001-01-02). No acquisition, no fire-sale, no reorg, no securitization.

No further recorded assignments. There is no evidence anywhere in the family or legal-events record of:

• a transfer to any "IP/Holdings/Ventures/Licensing" entity,
• a security interest or lien,
• a merger/change-of-name affecting title,
• a transfer to Ericsson's known divestiture vehicles (Unwired Planet, Optis, VideoLabs, Celerity, etc.).

The chain therefore terminates at the original operating-company assignee, and the patent expired – lifetime on 2022-11-09 still in Ericsson's name.

Timeline diagram

timeline
    title Ownership of US 6820233
    2000 : Provisional application filed by Ericsson inventors
    2001 : Non-provisional US application filed
         : Inventors assign rights to Ericsson
    2002 : PCT application WO 2002 007323 published
    2004 : US patent granted Nov 16
    2022 : Patent expires Nov 9

NPE / troll-pattern signals

Additional (pro-patent-holder / standard-relevant) note, not a troll signal: the family was affirmatively declared by Ericsson to the IETF as potentially essential to RFC 3095 (ROHC) on 2002-09-27. That places the asset in the SEP conversation — relevant if a future ownership query is run, but it is the opposite of an anonymous-shell pattern.

Verdict

Insufficient data — but with a clean, non-NPE factual core.

The USPTO/Google record for US 6,820,233 shows only the original assignment (inventors → Telefonaktiebolaget LM Ericsson, Reel 011657 / Frame 0465, executed 2001-01-15→2001-02-14, recorded 2001-04-02) and no post-issuance transfers of any kind. Per the rubric, "only the original assignment" maps to Insufficient data; however, the substantive conclusion for a troll-pattern screen is that every one of the eight NPE signals is negative or unproven — the chain is a single inventor-to-operating-employer link that terminates at Ericsson, which both practiced the technology (RFC 3095 ROHC) and still held title when the patent expired 2022-11-09. This is the expected profile of a large operating company's internally developed patent, not an NPE chain.

Caveats: (1) I could not query the Assignment Center directly, so the assignment-record correspondent attorney is unverified; (2) the 8-signal screen is based on a single authoritative source (Google Patents legal events) rather than a PACER/Docket-Navigator cross-check. To close both gaps, run a patent-number search on Reel 011657 / Frame 0465 at https://assignmentcenter.uspto.gov/ and a "patents asserted" query in Docket Navigator/Lex Machina using the literal string 6,820,233.

Verification link: https://assignmentcenter.uspto.gov/ (search patent number 6,820,233; or search reel 011657, frame 0465)

Cross-reference sources: Google Patents US6820233B2; WO 2002/007323 A2 (PCT/SE01/01493); IETF IPR statement ERICSSON-RFC3095 (2002-09-27).

I'll verify the prior-art citations for US 6,820,233 against USPTO and other patent databases. Let me run targeted searches for each cited reference.

Let me verify the non-patent literature and the Japanese family citations.

Prior-Art Analysis — US 6,820,233 B2

Scope and sourcing note

This analysis is built from the "References Cited" front-page data of US 6,820,233 B2 (the USPTO-cited art, as reproduced in the Google Patents full-text record at https://patents.google.com/patent/US6820233/en). I interpreted the identifier literally as 6,820,233 and did not substitute any similar number.

Two important framing points:

1. Only documents cited against the patent are prior art. The record's "Cited By," "Families Citing this family," and "Similar Documents" lists are all later documents that cite the '233 patent — they are not prior art and are excluded here. The genuine prior-art set is the 3 patent documents + 5 non-patent citations on the face of the patent (plus 3 foreign patents that appear in the family-citation list of the WO counterpart).
2. Anticipation vs. relevance (§ 102 vs. § 103). For § 102 the reference must disclose every limitation of the claim as written. Because a dependent claim incorporates all limitations of its independent claim, a reference that discloses only an added feature of a dependent claim (e.g., the XOR-combining step) does not anticipate that dependent claim unless it also discloses the independent claim's full scope. My claim mappings below therefore flag explicitly where a reference is a true § 102 candidate versus merely § 103-relevant to a claim element.

I could not complete every follow-up database pull before running out of search steps, so the non-patent-literature descriptions below are grounded in the patent's own citation data plus the corroborating hits I did retrieve (noted inline).

A. Patent-document citations (3) — as listed under "Patent Citations"

1. US 5,987,022 A — Geiger et al. (Motorola)

• Full citation: U.S. Patent 5,987,022, "Method for transmitting multiple-protocol packetized data," filed Dec. 27, 1996, granted Nov. 16, 1999. Assignee: Motorola, Inc. (Source: https://patents.google.com/patent/[US5987022A](/patent/US5987022A)/en and https://uspto.report/patent/grant/5,987,022.)
• Description: Discloses a data-communication system that packetizes IP traffic over a bandwidth-limited RF link and selects among several header-compression techniques based on a "message type identifier." It expressly distinguishes the IP header as containing "redundant, static data" and segregates a remaining portion (the fields that must be transmitted — receive window, acknowledgment number, IP packet ID, TCP checksum) from the removed/static portion, which is represented by an assigned connection number. Uses differential (delta) header compression (Van Jacobson–style) and tolerates loss of compressed acknowledgments.
• Potential § 102 reach: Relevant to the "static portion vs. transient portion" concept of independent claims 1 and 23 and to the header-separation steps of claims 5–8 (sorting a header to separate static from transient information) and claims 7–8 (further information taken from the target header vs. the reconstructed header).
  • Candid assessment: This is a genuine § 102 candidate only for a claim drawn solely to separating static from non-static header fields in a compression flow. It does not disclose generating a checksum from the static portion, reusing a stored coding state, or combining checksum components. It therefore cannot anticipate independent claims 1/23 as written; it is best characterized as a § 103 combination reference supplying the "static/transient field" context.

2. US 5,935,268 A — Weaver (Bay Networks)

• Full citation: U.S. Patent 5,935,268, "Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet," filed Jun. 3, 1997, granted Aug. 10, 1999. Inventor: Jeffrey C. Weaver. Assignee: Bay Networks, Inc. (Source: https://patents.google.com/patent/US5935268 ; PDF: https://patentimages.storage.googleapis.com/72/19/52/cd26d477d67871/US5935268.pdf.)
• Description: Discloses computing a CRC/error-detection code (EDC) for a modified binary data block (e.g., an Ethernet frame encapsulated as a VLAN frame) without re-running the CRC over the whole block. A second EDC is computed only over the changed/added data (the VLAN header, shifted to its position in the modified block), and the first (original) EDC is XORed with the second EDC to produce the EDC for the modified block. It explicitly relies on the fact that EDCs are binary values and that "adding comprises XORing" — i.e., the linearity property on which the '233 patent's Equations 1–4 rest. Also covers the case where a portion of the original block is shifted, requiring fourth/fifth EDCs, and XORing first+second+fourth+fifth.
• Potential § 102 reach: This is by far the closest prior art to the computational mechanism of the '233 patent:
  • Independent claims 12/13 (a first checksum component for unchanged data + further checksum components combined with it) and claims 14–15 (selecting further components and adding them modulo-2 to the first component) — the Bay Networks "XOR the original EDC with the newly-computed EDC over the changed data" step reads directly on the modulo-2 combination recited.
  • Claim 29 (apparatus computation logic "for adding, modulo-2, each of the further checksum components to the first checksum component") and claim 20/31 (CRC checksum).
  • Candid assessment: Because claims 12–15 and 29 are dependent (they incorporate claims 1/23), US 5,935,268 cannot formally anticipate them unless it also discloses the independent-claim limitations — namely a header-compression context, a "target header" whose static portion "remains unchanged in corresponding static portions of all headers in a packet flow," a static checksum produced by "coding the static information from a preceding header," and use of the result to verify a reconstructed header. Bay Networks operates on data blocks (frame encapsulation), not on reconstructed packet-flow headers, so those limitations are absent. Conclusion: strong § 102/§ 103 art against the checksum-combination mechanism (notably claims 12–15, 20, 29–31), but not a full-claim anticipator of claims 1/23.

3. WO 2000/079763 A1 — Jonsson et al. (Ericsson) — the closest environment reference

• Full citation: WO 2000/079763 A1, "Robust header compression in packet communications," international filing date Jun. 16, 2000 (PCT/SE2000/001269), priority US 09/335,558 filed Jun. 18, 1999, published Dec. 28, 2000. Assignee: Telefonaktiebolaget LM Ericsson (Publ). US national counterpart: US 6,754,231 B1. (Sources: https://patents.google.com/patent/WO2000079763A1/en ; https://www.frandavenue.com/en/patent/WO0079763A1 ; EP 1222789 A1.)
• Description: This is the ROCCO/ROHC base disclosure by the same assignee and overlapping inventors. It teaches generating a checksum (CRC) over the full uncompressed header, placing that checksum in the compressed header, and at the decompressor reconstructing/guessing the header and verifying it by recomputing a checksum and comparing to the received checksum; if the checksums don't match, the reconstruction is retried ("the above-described header decompression procedures can be repeated as many times as desired"). This is precisely the FIG. 1–3 prior-art environment that the '233 patent's background section describes and improves upon (the "computationally complex" full-header checksum recomputation per guess).
• Potential § 102 reach:
  • Claim 20 / 31 (CRC checksum) and the verification framework recited in the preambles of claims 1, 21–23, 32–33 (a receiving station verifying reconstructed headers from compressed headers).
  • Candid assessment: WO'763 computes the CRC over the whole header (static + transient) and recomputes it for each guess — it does not disclose the claimed re-use of a static checksum component / stored coding state ("static checksum information … produced by coding the static information from a header that precedes the target header") combined with only the transient information. That re-use is the very point of novelty of the '233 patent. So WO'763 is not an anticipator of independent claims 1/23; it is the principal § 103 reference (the base scheme the '233 improvement modifies).
  • Date note (important): WO'763 published Dec. 28, 2000, i.e. after the '233 priority date of Jul. 14, 2000, so it is not § 102(a)/(b) art by its publication date. It can only qualify as pre-AIA § 102(e) art (as of its Jun. 16, 2000 international filing date, if it designated the US and was published in English — which the US counterpart US 6,754,231 confirms). This date subtlety matters and should be verified if § 102(e) status is asserted.

B. Non-patent citations (5) — as listed under "Non-Patent Citations"

4. ROCCO Internet-Draft (Degermark, Hannu, Jonsson, Svanbro, Jun. 15, 2000)

• Description (corroborated): The draft (draft-ietf-rohc-rtp-rocco-01, 67 pp.; BibTeX: https://datatracker.ietf.org/doc/draft-ietf-rohc-rtp-rocco/01/bibtex/, authors Degermark, Hannu, Jonsson, Svanbro) introduces a header-compression framework: the compressor computes a CRC over the full header before compression, places the CRC in the compressed header, and the decompressor uses the CRC to verify that it has rebuilt the headers correctly, retrying reconstruction if verification fails. It is the direct textual counterpart of WO'763 above.
• Potential § 102 reach: Same as WO'763 — claim 20/31 (CRC) and the verification-of-reconstructed-header preambles of claims 1/21–23/32–33; not the static-reuse novelty.
• Date note: Dated Jun. 15, 2000, i.e. before the '233 priority date (Jul. 14, 2000), so it is § 102(a) art by date (and it is not >1 yr before the Jan. 2, 2001 filing, so not § 102(b)). Inventorship nuance: four of the six '233 inventors (Degermark, Hannu, Jonsson, Svanbro) are ROCCO authors, and both are Ericsson works — which raises a "by others" / common-ownership question (pre-AIA § 102(a) requires the disclosure be "by others," and § 103(c) common ownership can disqualify art for obviousness). The examiner nonetheless cited it as prior art. This is a nuance worth flagging, not a conclusion.

5 / 5b. Degermark et al., "Low-Loss TCP/IP Header Compression for Wireless Networks" (Oct. 1997)

• Description: Proposes IP-header compression robust to lossy wireless links by making the compressed header self-describing (encoding the change/delta rather than relying solely on prior context), and notes that IP header compression "requires the use of a secure link layer protocol with a strong checksum" (corroborated by the later US 7,069,495 text, which quotes this article). It also discusses the static vs. changing field structure of IP headers.
• Potential § 102 reach: Background/§ 103 art supporting the static/transient field distinction (claims 1/23, 5–8) and the use of checksums generally; not an anticipator of the checksum-reuse claims.

6. Larzon, Degermark, Pink, "Efficient use of wireless bandwidth for multimedia applications" (MoMuC '99, Nov. 1999)

• Description: Workshop paper on exploiting header redundancy for multimedia over wireless. Background art on the static-field / differential-field compression premise. § 103 background only; no checksum-component reuse disclosed.

7. RFC 1144 — Jacobson (Feb. 1990)

• Description: The foundational TCP/IP header-compression specification (delta encoding of changing fields; static fields sent on context establishment). Universally treated as the origin of the "static fields sent once, changing fields sent as deltas" model central to the '233 preamble. § 103 background only; no checksum reuse.

C. Foreign family citations (3) — appearing in the family-citation list of the WO counterpart

These are listed in the WO 2002/007323 family record ("Family Cites Families") and are CRC/checksum-computation art:

• Potential § 102 reach: These are directed to CRC/checksum computation techniques (error-detection circuits, CRC-code generation, checksum calculators) — likely cited for the underlying CRC/linear-code computation concepts underpinning claims 20/31 and the modulo-2 combination of claims 15/29. As generic CRC-computation art they do not disclose the header-compression context or the static-checksum re-use, so they are § 103/background references only, not anticipators. (Note: the JP 3257298 publication date of 2002-02-18 post-dates the '233 priority date, so if relied upon it must be as its 1994 filing date — I could not confirm the exact JP filing/publication event chain before the step limit and flag this as unverified.)

D. Consolidated mapping — reference → claims

Legend: ✓ = genuine § 102 disclosure candidate for that subject matter; ~ = relevant/§ 103 or partial-element disclosure; ✗ = does not disclose the limitation.

E. Bottom-line assessment (with confidence)

• No single cited reference appears to disclose every limitation of independent claim 1 or claim 23, in particular the core novelty: static checksum information produced by coding the static information taken from a preceding header in the flow and re-used (combined with only the transient/changed information) to verify a reconstructed header. The cited art either (a) computes a full-header CRC each time (WO'763 / ROCCO — the very scheme the patent improves), or (b) applies the reuse-and-XOR idea to general data-block/frame modification, not packet-flow header reconstruction (US 5,935,268). This is consistent with the patent having issued over these references.
• Highest-value prior art, in order:
  1. US 5,935,268 (Bay Networks) — closest to the computational mechanism (compute an EDC over only the changed data and XOR it with the reused existing EDC, expressly invoking CRC linearity). Strong § 102/§ 103 art against the modulo-2-combination subject matter (claims 12–15, 20, 29–31).
  2. WO 2000/079763 A1 / US 6,754,231 (Ericsson) and its IETF counterpart the ROCCO draft — the closest environment art (CRC-over-header + verify reconstructed header by retry). Principal § 103 art against the independent claims; discloses the claim 20/31 CRC subject matter.
  3. US 5,987,022 (Motorola) — closest to the static/transient field separation premise (claims 5–8).
• Date/status caveats to verify before relying on these for a formal invalidity position:
  • WO'763's publication (Dec. 28, 2000) is after the '233 priority date; its § 102 candidacy depends on pre-AIA § 102(e) status via the Jun. 16, 2000 international filing date.
  • The ROCCO draft precedes the priority date (Jun. 15, 2000 < Jul. 14, 2000) but raises a possible "by others"/common-ownership question given overlapping inventors/assignee.
  • The JP 3257298 publication date (2002) post-dates the priority date; early reliance would be on its 1994 filing date (unverified here).

Confidence: High on the identity and content of the face-of-patent citations (they are reproduced verbatim from the USPTO front page via Google Patents and were independently corroborated for US 5,935,268, US 5,987,022, WO 2000/079763, and the ROCCO draft). Moderate on the precise § 102-vs-§ 103 characterization, since that turns on claim construction and on the date/inventorship nuances flagged above, and I was unable to complete direct USPTO Patent Center full-text and JP-record pulls before the search step limit. If a binding anticipation opinion is required, confirm (i) the exact 35 U.S.C. § 102(e) date of WO 2000/079763 / US 6,754,231, (ii) the ROCCO draft's authorship/date chain, and (iii) each JP reference's actual filing date, in USPTO Patent Center / Global Dossier / JPO.

I'll ground this obviousness analysis in the actual prior art cited on the patent page. Let me pull details on the key references.

Let me confirm two more references — the Degermark 1997 "Low-Loss TCP/IP Header Compression" paper and the JP family citations.

Obviousness Analysis — U.S. Patent No. 6,820,233 under 35 U.S.C. § 103

Reference base: the "Prior Art" materials on the patent's Google Patents record — Patent Citations (3), Non-Patent Citations (5), and Family Cites Families (3). This builds on, and does not repeat, the bibliographic, claim-overview, and litigation sections generated earlier. Analyst opinion only; not a legal opinion. Dates below are taken literally from the record.

0. Standard and the person of ordinary skill

Under Graham v. John Deere the analysis proceeds: scope/content of the prior art → differences from the claims → level of ordinary skill → secondary considerations. Under KSR Int'l v. Teleflex, a combination is obvious where the elements are "known," the combination is "of familiar elements according to known methods," and it "does no more than yield predictable results," or where there is a "design incentive" or "market pressure" to solve the known problem.

POSITA (circa mid-2000): a B.S. in EE/CS plus ~2–3 years in packet networking / header compression, or equivalent; conversant with RFC 1144, RFC 2507/2508, the ROCCO drafts, ROHC, CRC arithmetic (including the linearity of cyclic codes), and IP/UDP/RTP header structure.

1. What claim 1 / claim 23 actually require

Per the earlier claim overview, independent claim 1 requires only three functional steps:

• (a) "static checksum information" for the static (unchanging-across-the-flow) header portion, produced by coding the static information from a preceding header in the flow;
• (b) "further information" representative of the transient (changing) portion; and
• (c) combining (a) and (b) to generate a checksum used to verify the reconstructed header.

Claim 23 is the apparatus mirror (first input / second input / combiner). The dependent claims then subdivide into two families: (i) stored checksum-register coding states (claims 3–11) and (ii) precomputed checksum components added modulo-2 (claims 12–19, incl. the MSB-group optimization).

2. Prior-art qualification — an important date caveat

⚠️ Flag: WO 2000/079763 and the ROCCO ‑01 draft share inventors and assignee with the '233 patent and sit on the same 1999–2000 timeline. The strongest combinations therefore should be anchored on the non-common-ownership, §102(b)-solid references (Bay Networks '268, Motorola '022, Degermark 1997, RFC 1144) and treat WO'763/ROCCO as corroborating rather than load-bearing art.

3. Core disclosures of the load-bearing references

• US 5,935,268 (Bay Networks) — the closest art on the reuse concept. It generates a CRC/EDC for a modified data block by: (1) keeping the first EDC of the original block; (2) computing a second EDC only for the changed/inserted data (shifted to the correct position); and (3) XORing the first and second EDCs to yield the third EDC. For multiple changes it computes several EDCs and XORs them together (including "composite EDC" for a multi-bit data unit). It expressly frames this as avoiding "a fresh CRC… discarded upon modification" — i.e., avoiding full recomputation — and rests on the CRC property that EDCs combine by XOR. Apparatus: "a first circuit… a second circuit XORs…". URL: https://patents.google.com/patent/US5935268
• US 5,987,022 (Motorola) — multi-protocol header compression; states the IP header "generally consists of redundant, static data," removes "redundant or static" fields identified by a connection number, maintains a context, and transmits only the changing fields (IP‑ID, TCP checksum). URL: https://patents.google.com/patent/[US5987022A](/patent/US5987022A)/en
• Degermark et al. 1997 — header compression that stores static fields once in a compression context/state and sends only deltas; uses generation/checksum mechanisms to detect a stale context; expressly wireless. DOI 10.1023/A:1019138108114.
• RFC 1144 — canonical static-fields-sent-once + delta-encoded-changing-fields compression.
• ROCCO Internet-Draft (Degermark, Hannu, Jonsson, Svanbro) — computes a CRC over the full header before compression, sends it in the compressed header, and has the decompressor verify reconstruction and retry guesses; separates static from dynamic fields and LSB-encodes changing fields. https://datatracker.ietf.org/doc/draft-ietf-rohc-rtp-rocco/01/
• WO 2000/079763 (ROHC) — the framework the '233 background describes: compressor generates a CRC from the uncompressed header and sends it as the compressed header; the decompressor reconstructs/guesses, computes a CRC, compares, and re-guesses repeatedly. It expressly contemplates many successive checksum generations per header. https://patents.google.com/patent/WO2000079763A1/en

4. Proposed combinations

Combination A — US 5,935,268 (Bay Networks) + Degermark 1997 (optionally + RFC 1144) → claims 1, 23 and most dependents

Mapping (claim 1):

• Static checksum information produced by coding static information from a preceding header ⟸ Bay Networks' first EDC of the original block, i.e., coding the unchanged information from the block that precedes the modified block; Degermark 1997 supplies the header-compression context in which the "static portion" = source/destination addresses etc. that "do not have to be sent more than once."
• Further information representative of the transient portion ⟸ Bay Networks' second EDC computed for the changed data; Degermark 1997's delta-encoded changing fields (IP‑ID, sequence numbers).
• Combining to verify a reconstructed header ⟸ Bay Networks' XOR of first + second (+…+nth) EDCs; Degermark 1997's checksum-based validation of the reconstructed header at the receiver.

Motivation (KSR): both references address generating error-detection codes over packet data where only part of the packet changed; Bay Networks expressly identifies the problem that the '233 patent solves (recomputing a fresh CRC is wasteful and discards valid prior work). A POSITA applying header compression over a lossy wireless link — where budget for per-packet/per-guess computation matters — would look to the known incremental-CRC/XOR-update technique and apply it to the constant static header contribution. Result is predictable and requires no change in the function of any element.

Combination B — US 5,987,022 (Motorola) + US 5,935,268 (Bay Networks) + Degermark 1997

Motorola supplies the explicit teaching that IP headers are "redundant, static data" that can be stored/omitted and reconstructed from context, while dynamic fields are transmitted; Bay Networks supplies the "reuse the old EDC + XOR the changed-data EDC" mechanism; Degermark 1997 supplies the compressed-header/receiver-reconstruction setting. Motivation: same field, and Motorola itself motivates reducing per-packet overhead in bandwidth-limited RF/wireless.

Combination C (corroborative) — WO 2000/079763 + US 5,935,268 (only if WO'763 qualifies)

If WO'763 is counted (via §102(e) and absent §103(c) disqualification), the mapping is the cleanest: WO'763 discloses the complete verify-by-reconstruction-checksum loop including repeated guesses — precisely the environment where reducing checksum cost matters — and Bay Networks supplies the XOR-reuse mechanism. See the §2 caveat: because of the shared Ericsson ownership/inventors, this combination is strongest when WO'763 is used only as background/evidence of the state of the art, with Bay Networks as the enabling reference.

5. Dependent-claim analysis

Claim 23 (apparatus): met by Bay Networks' "first circuit… second circuit XORs…" (combiner with two inputs), set in the header-compression context of Degermark 1997/Motorola.

6. Why a POSITA would combine — consolidated motivation

1. Same field / same problem. All load-bearing references concern error-detection codes over packetized data, and three of them concern header compression specifically.
2. Express recognition of the problem. ROCCO/WO'763 make the decompressor generate a checksum for each reconstruction attempt; Bay Networks expressly criticizes recomputing a fresh CRC on modification. The motivation to reduce checksum work is thus in the art, not supplied by the applicant.
3. Known mathematical tool. The '233 specification's entire rationale is the linearity of cyclic codes — f(c₁+c₂)=f(c₁)+f(c₂) — and Bay Networks already exploits exactly this by XORing EDCs. Combining known components by modulo‑2 addition is a predictable use of a known property.
4. Predictable result / no change in function. Reusing the static contribution and folding in only the changed contribution yields the same checksum with less computation — a predictable improvement, satisfying KSR.
5. Design incentive / market pressure. Cellular links: bandwidth is the costly resource (ROCCO/Degermark 1997, and Ericsson's own materials), so reducing per-packet/per-guess computation to enable robust decompression is an obvious engineering goal.

The three JP family citations (Sanyo code-error-detection circuit; Matsushita "CRC code generation method"; Toyo "checksum calculator") are cumulative: they show that optimizing CRC/checksum generation was a mature, crowded art, reinforcing that the claimed optimization is a predictable engineering choice rather than an inventive leap. (Their full texts were not retrievable in this session, so they are characterized cautiously; JP 2000‑339184 A in particular post-dates the priority date and should not be relied upon.)

7. Counterarguments, secondary considerations, and confidence

• Analogy/field objection to Bay Networks: it concerns VLAN/Ethernet encapsulation, not header compression. Rebuttal: it is reasonably pertinent — the same problem (EDC for modified data) and same mechanism (XOR of EDCs). Its "original block" maps to "the header preceding the target header," and its "changed data" maps to "transient portion."
• Date/ownership (most serious vulnerability of the petitioner's case): WO'763 and ROCCO overlap in inventors/assignee with the '233 patent; if treated as §102(e) art they may be disqualified under pre-AIA §103(c). A robust §103 theory should therefore lead with Bay Networks '268 (independent party, §102(b)-solid) as the enabling reference, using WO'763/ROCCO only for background or as §102(a)/(b) art where their dates permit.
• Secondary considerations: the record shows no unexpected results, long-felt need, failure of others, or nexus-bearing commercial success that would rebut. (The patent expired 2022‑11‑09, and no litigation was found in the earlier sections — so no presumption of validity has been judicially tested.)
• Confidence:
  • Claims 1/23 and 12–20 — high likely obvious over Bay Networks '268 + Degermark 1997 / Motorola '022.
  • Claims 3–11 (stored-state and probability-sorted families) — moderate; supported mainly by ROCCO/Degermark as design choices, and sensitive to the date/ownership caveat.
  • Overall — moderate-to-high, contingent on (i) treating Bay Networks as reasonably pertinent art and (ii) resolving the WO'763/ROCCO prior-art-status questions flagged in §2.

Sources: Google Patents US6820233B2 (https://patents.google.com/patent/[US6820233](/patent/US6820233)/en); US5935268 (https://patents.google.com/patent/US5935268); US5987022 (https://patents.google.com/patent/US5987022A/en); WO2000079763A1 (https://patents.google.com/patent/WO2000079763A1/en); ROCCO draft (https://datatracker.ietf.org/doc/draft-ietf-rohc-rtp-rocco/01/); Degermark et al. 1997, Wireless Networks 3(5):375–387 (DOI 10.1023/A:1019138108114).