US 6732329

I'll search for the specific patent number and check for any 2026 litigation activity.

Let me check specifically for litigation or CAFC docket activity involving this patent number.

US 6,732,329 B2 — "Providing a header checksum for packet data communications"

Status of this report: The bibliographic and claim data below comes from the patent text itself (Google Patents, the USPTO Official Gazette entry for Issue 1282‑1, and the patent PDF). Sources are cited inline.

Bibliographic data

Uncertainty flagged: Unified Patents' page lists the priority date as 2001‑03‑26, while Google Patents and the USPTO Official Gazette both state 2001‑03‑27 (filing date of 09/819,523). I treat 2001‑03‑27 as authoritative, per the patent record, and note the one‑day discrepancy rather than auto-correcting it.

Abstract (verbatim)

"A method and apparatus for providing the header checksum of a data packet."

Technical gist

The patent addresses incremental header‑checksum recomputation. Given a first packet whose checksum S_A is already known for an even‑length octet string Φ_A = (φ_0 | φ_1 | φ_2) (head | middle | tail), and a second packet formed by replacing the middle segment φ_1 with a new segment φ̂_1 (padding with a zero octet if the result has odd length), the invention computes the new checksum S_B from S_A plus partial checksums, rather than rescanning the whole header. Core results in the disclosure: for an even length difference, S_B = S_A ⊕ f(φ̂_1) ⊖ f(φ_1) (Eq. 2); for an odd length difference, a "checksum string shifting" property is used, yielding S_B = f(φ_0) ⊕ f(φ̂_1) ⊕ (f(φ_2))′ , i.e. an octet‑swapped tail checksum (Eq. 3). To save work, only the shorter of φ_0/φ_2 is computed directly and the other derived by subtraction from S_A (Eqs. 4–5).

Independent claims in plain language

There are four independent claims — 1, 7, 13, and 16 (claims 2–6, 8–12, and 14–15 are dependent; claim 17 depends from 16).

• Claim 1 — Method (the base case). A method for propagating network signals for a first packet and a second packet. The first packet carries a checksum for a first octet string having a "middle segment"; the second carries a checksum for a second octet string having a "new middle segment." The method: (a) compute an even‑octet‑aligned checksum of the middle segment → middle checksum; (b) do the same for the new middle segment → new middle checksum; and (c) if the two middle segments differ in length by an even number of octets, combine the first checksum with the new middle checksum and the middle checksum to yield the second checksum — where the operation applied to the middle checksum is a checksum subtraction (not addition). In formula terms, this is the S_B = S_A ⊕ Ŝ_1 ⊖ S_1 computation.

• Claim 7 — Article of manufacture. The same substance as claim 1, but claimed as a computer‑readable storage medium containing instructions that program a processor to propagate the two packets and perform the even‑octet‑aligned checksum operations and the conditional combination with checksum subtraction. Identical scope to claim 1, different statutory category.

• Claim 13 — Communication network. Also the same substance as claim 1, claimed as a network with a node and a network medium, where the node is coupled to the network to propagate the two packets and to perform the checksum operations / conditional subtraction described in claim 1. Again a category‑shifted (apparatus/system) counterpart of claim 1.

• Claim 16 — Method, expressed with the explicit mathematics. A method for the two packets, with Φ_A = (φ_0 | φ_1 | φ_2) of even length and Φ_B defined as the concatenation (φ_0 | φ̂_1 | φ_2), appended with a zero octet when that concatenation has an odd byte count. Steps: form S_1 = f(φ_1) and Ŝ_1 = f(φ̂_1) (f(·) = even‑octet‑aligned checksum); and if φ_1 and φ̂_1 differ in length by an even number of octets, form S_B = S_A ⊕ Ŝ_1 ⊖ S_1, where ⊕ is 16‑bit checksum summation and ⊖ is 16‑bit checksum subtraction. This is the claim that literally recites the arithmetic and the 16‑bit one's‑complement operators.

The dependent claims (odd‑length case and narrowing limitations)

• Claims 2/3 (from 1), 8/9 (from 7), 14/15 (from 13), 17 (from 16) add the branch where φ_1 and φ̂_1 differ by an odd number of octets. Because appending one zero octet shifts octet alignment of the tail, the tail checksum must enter octet‑swapped: S_B = S_0 ⊕ Ŝ_1 ⊕ (tail checksum)′. To avoid recomputing both head and tail, the claim set splits on relative length: if the head is shorter than the tail, compute the head checksum directly and derive the tail checksum by checksum subtraction (S_A ⊖ S_1 ⊖ S_0); if the head is longer, compute the tail checksum directly and derive the head checksum (S_A ⊖ S_1 ⊖ S_2).
• Claims 4/10 (from 1/7) narrow to: both octet strings have an even number of octets; the second string is derived from the first by the segment replacement plus conditional zero‑octet append; and all checksum operations are 16‑bit operations.
• Claims 5/6, 11/12 (from 4/10) carry the odd‑length‑difference logic into the narrowed 16‑bit/even‑string context.

Literal‑text observation (no auto‑correction): Claim 16's final formula as printed renders as S_B = S_0 ⊕ Ŝ_1 ⊖ (S_1)′, i.e. the octet‑swap is applied to S_1. The corresponding step in the specification's FIG. 4 flow diagram (block 416) is stated as S_B = S_0 ⊕ Ŝ_1 ⊕ (S_2)′, i.e. the swap is applied to the tail checksum S_2, which is what the derivation in Eq. (3) supports. I flag this as a literal discrepancy in the printed record rather than resolving it. Similarly, the specification's prose in the FIG. 4 description contains a duplicated "l(φ_0)≧l(φ_2)" condition where one branch must logically read "less than."

Litigation / Federal Circuit check (as requested)

• I searched for the specific number 6732329 (and 6,732,329) in connection with litigation, PTAB/IPR, reexamination, and Federal Circuit appeals. I found no district‑court case, PTAB proceeding, or CAFC docket entry naming US 6,732,329.
• The only CAFC‑related hits returned were unrelated matters (e.g., Ascendis Pharma v. BioMarin and the VLSI/Intel IPR2021‑01229 '373 patent dispute), none of which involve 6,732,329.
• Caveat: my searches surface indexed/public web content, not a direct PACER or CAFC CM/ECF query, so I cannot certify the absence of a 2026 docket entry with complete confidence. However, the absence is consistent with the recorded status: the patent is marked Expired – Lifetime with adjusted expiration 2022‑10‑12, which makes live infringement litigation unlikely.

Bottom line

US 6,732,329 is a 2001‑filed, 2004‑issued Intel patent (inventor Matthew M. Bace) covering an efficient, arithmetic‑only technique for updating a 16‑bit one's‑complement packet header checksum when a middle segment of the header/payload is replaced — using even‑octet‑aligned partial checksums, checksum subtraction, and an octet‑swap for the odd‑length case. Its four independent claims are method (1), article of manufacture (7), communication network (13), and a formula‑reciting method (16). It expired 2022‑10‑12 and shows no litigation or post‑grant challenge activity in the sources I could reach.

I'll search for litigation involving US patent 6732329.

Let me check litigation-specific sources.

Litigation Search Results: U.S. Patent No. 6,732,329

Bottom line: I found no record of any litigation (district court, ITC, PTAB, or Federal Circuit) involving U.S. Patent No. 6,732,329.

What I searched

I ran targeted queries against litigation-oriented sources, including Unified Patents' case data, Docket Alarm / PTAB records, CourtListener RECAP (which aggregates PACER filings), and general web indices quoting the patent number in both plain ("6732329") and comma-formatted ("6,732,329") styles, combined with litigation terms ("infringement," "complaint," "lawsuit," "docket," "IPR," "PTAB").

Every hit that surfaced was either:

• the patent document itself (Google Patents, Justia Patents),
• the '329 designation of entirely unrelated patents in other cases (e.g., the Techiya/Harman matter and the "’329 Patent" in a Delaware case — different patent), or
• general Unified Patents commentary that did not reference this patent.

Nothing matched this specific patent number as an asserted patent in a case caption.

Patent posture relevant to the absence of litigation

The patent is a long-held Intel asset that has expired. The record shows only prosecution and maintenance activity (assignment recorded 2001-07-05; maintenance fees paid at 4, 8, and 12 years; a certificate of correction in 2004). There are no recorded assignments to an NPE or other third-party monetization entity — a pattern that strongly correlates with never having been asserted in litigation.

Caveats and confidence level

• Confidence: moderate-to-high that no litigation exists. The patent is expired, never reassigned away from Intel, and no assertion appears in the aggregated sources I could reach.
• Not exhaustive. I could not directly load the Unified Patents Portal case list, PACER, or Docket Navigator (the coverage sources you named) — those are largely gated/interactive and did not return content via the queries available to me. A definitive negative would require a direct PACER or Docket Navigator party/patent search, and possibly an ITC EDIS search.
• No auto-correction applied. I treated the identifier "6732329" literally and excluded results for similarly numbered patents (e.g., the unrelated "’329" patents above, and U.S. 7,025,252, 9,253,239, etc.). If you intended a different patent, please confirm the exact number.

Recommended next steps for a definitive answer

1. Run a patent-number query in Docket Navigator or Lex Machina (both index patent-in-suit data directly).
2. Search PACER Case Locator and the ITC EDIS for the patent number.
3. Check USPTO Patent Center / Assignment for any assignment history beyond the 2001 Intel assignment (which would flag monetization).
4. Check PTAB (PTAB Center / Patent Trial & Appeal Case Tracking System) for any IPR/PGR/CBM filed against 6,732,329.

If anything turns up in those searches, I'd be glad to compile the plaintiff/defendant/jurisdiction/case-number/filing-date/status table you requested.

Proceedings overview

Total AIA trial proceedings on file for US 6,732,329: zero. Per the structured "PTAB proceedings on file" block sourced from the USPTO Open Data Portal — the canonical list for this analysis — there are no IPRs, no PGRs, and no CBM reviews (active, terminated, settled, or denied) involving this patent, and my independent web searches surfaced none either. The defensive posture is therefore not "hardened by surviving PTAB attacks" and not "claims already canceled" — it is untested at the Board. A defendant facing assertion today gets no free invalidity ruling from the PTAB record, but also no adverse claim-construction or estoppel baggage to fight; any IPR would be a first-instance proceeding under 35 U.S.C. §§ 311–319. The practical gating fact is different and more decisive: the patent expired on 2022-10-12 (adjusted expiration; legal status "Expired – Lifetime"), so there are no prospective damages to defend against for conduct after that date.

No per-proceeding entries follow, because the canonical list is empty. I will not manufacture proceeding numbers.

---

Why the empty record matters (verification trail)

What I checked

False positives to avoid (do not rely on these)

Several similarly-numbered items surface when you search the string "329" or "329 Patent." None involve US 6,732,329:

• IPR2025-01104, styled against "Patent No. 12,011,329" — a different patent entirely (intraoral device art; the "’329 Patent" there is a member of a family including 11,744,686, 11,xxx,969, 11,xxx,970, 11,xxx,232). The § 325(d)/Advanced Bionics analysis in that petition has nothing to do with the Bace checksum patent.
• Various IPR20xx-… exhibits (IPR2013-00540 through IPR2013-00550; IPR2015-01567; IPR2016-01573; IPR2017-00209; IPR2024-00293) mention unrelated patents (6,233,314; 6,603,835; 7,003,082; 5,515,369; 5,687,196; 8,075,338; 7,490,037; 8,626,255). Those are prior-art exhibits, not challenges to 6,732,329.
• The Unified Patents portal page that includes "US-6732329-B2" is a citation/reference page (it cross-links 6,732,329 to US 5,050,166 among others), not a Unified Patents-filed challenge.

The one signal the absence does send

Per the Federal Circuit's own amicus briefing (In re Kangxi), roughly 28% of patents asserted in district court are subsequently challenged at the PTAB. Combined with the litigation summary already generated in this analysis (no district court, ITC, or PTAB case found; no assignment away from Intel; only prosecution and maintenance activity through the 12-year fee), the pattern is consistent and mutually reinforcing: this was a defensive Intel portfolio asset that was never monetized or asserted, and it expired before anyone had a reason to file. That is a genuine negative finding, not a gap in the record.

Residual gaps I could not close (state these to the client)

1. Ex parte reexamination (35 U.S.C. § 302) is not an AIA trial and would not appear in the structured block. I did not find any reexam certificate for 6,732,329, but I also could not directly query the USPTO reexamination certificate database in this session. Low probability, but not formally excluded.
2. PGR is legally impossible for this patent: PGR applies only to patents subject to first-inventor-to-file (post-2013 applications). Application 09/819,523 was filed 2001-03-27 — pre-AIA. So a PGR would be a nullity even if someone tried.
3. CBM is legally impossible: CBM review applied only to covered business method patents of financial-services institutions, and the CBM program sunset on 2020-09-16. Even without the sunset, this patent (H03M 13/00 — coding/error detection; 16-bit ones-complement header checksums) is a technological invention, not a covered business method.
4. PTAB E2E / ODP lag: the structured block is authoritative for ODP ingest. There is no realistic scenario in which an IPR on a pre-AIA patent that expired in 2022 is pending but unindexed, but a direct E2E patent-number query would be the belt-and-suspenders confirmation.

---

Strategic summary

Claim status: all 17 claims UNTESTED. No claim of US 6,732,329 has ever been canceled, confirmed, or even instituted for trial at the PTAB. The claim set as granted (2004-05-04) stands unamended: claims 1–6 (methods), claims 7–12 (article of manufacture / CRM), claims 13–15 (communication network), and claims 16–17 (method claiming the specific formulae S_B = S_A ⊕ Ŝ_1 ⊕̂ S_1 and, in the odd-length case, S_B = S_0 ⊕ Ŝ_1 ⊕̂ (S_2)′, where ⊕ is 16-bit ones-complement summation and ⊕̂ is checksum subtraction). Note the correction in claim 17 as printed in the structured text: the final term is (S_1)′ (an octet-swap), while the corresponding specification equation (3)/(5) discussion and the FIG. 4 block 416 describe (S_2)′ — a specification-versus-claim discrepancy worth pinning down if you ever need to litigate claim 17. Also note the certificate of correction recorded 2004-07-06; its scope is not visible in the structured data and should be pulled from Patent Center before quoting any claim verbatim.

Estoppel landscape: empty. Because there is no prior petitioner, there is no § 315(e)(2) estoppel attaching to any party, and no § 315(e)(1) estoppel before the Board. A first-time petitioner would face no General Plastic follow-on-petition risk from prior filings on this patent (though the panel could still apply General Plastic if the same petitioner files serially against the same patent, and Fintiv-style § 314(a) discretion if there is a parallel district court case — a scenario that is hard to construct for an expired patent). The absence of a prior IPR also means no binding Board claim construction on "even-octet-aligned checksum," "checksum subtraction operation," or "octet-swapped version" — the § 112 and claim-construction record is entirely open.

Pattern signals: none. No petitioner repetition, no patent-owner appeal practice, no defensive aggregator in the chain. The only tertiary activity in the neighborhood is citing art: US 7,386,627 B1 (Network Appliance, "Methods and apparatus for precomputing checksums for streaming media," 2008-06-10) and US 9,698,825 B2 (Quest Software, "Fast update of data packet checksums," 2017-07-04) both cite this patent, which confirms the technical relevance of the incremental-checksum idea but has no defensive value against an assertion. The two most on-point prior-art references cited on the face of the patent remain the ones already in the record: US 5,935,268 (Bay Networks, "Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet") and EP 0 465 006 A1 (Digital Equipment Corp., "A method for generating a checksum") — both squarely directed at recomputing a checksum after modifying a packet, which is why the Examiner cited them.

---

Recommended next steps

If you are a defendant receiving a demand letter citing US 6,732,329:

1. Lead with expiration. The patent's adjusted expiration is 2022-10-12 and its status is "Expired – Lifetime" (no maintenance fee was paid past year 12, with the last recorded FPAY on 2015-10-21). A demand premised on ongoing or post-2022 infringement is defective on its face, and pre-expiration damages are barred by 35 U.S.C. § 286 (six-year lookback) for any claim filed after 2022 — you would be litigating over conduct from at most 2016–2022, if any. Ask the sender to identify the specific accused acts and dates. This is the single highest-leverage response.
2. Do not expect the PTAB to do your work for you. There is no FWD to cite, no canceled claim to point at, and therefore no "sanction-bait" argument available from the Board's record. If you need an invalidity position (e.g., for a declaratory judgment or a license negotiation), it must be built from scratch: US 5,935,268 and EP 0 465 006 A1 as the primary references, plus the RFC 1071 line of art (Braden et al., "RFC1071: Computing the Internet Checksum," 1988 — which the Board itself cites in other matters and which the Examiner evidently considered, since it appears in the similar-documents listing for this patent). Note that the specification expressly concedes the 16-bit ones-complement checksum is standard TCP/IP practice, which frames the § 103 case tightly around the segmented-recomputation limitation.
3. If you are contemplating an IPR anyway (e.g., to kill the patent for a declaratory judgment or to defeat a § 285 fee theory): be aware that the Board's current discretionary-denial practice heavily disfavors challenges to old patents with settled expectations. A 2001-priority patent that expired in 2022 is the paradigm case for a § 314(a) / § 325(d) discretionary denial, and the Deputy Director's "settled expectations" line of decisions (see, e.g., the Dabico / SoundClear-adjacent reasoning in the materials surfaced above) treats patent age as a factor weighing against institution. Budget for denial, not for trial.
4. Verify the two residual gaps before you rely on the negative finding in a filing: (a) a direct PTAB E2E patent-number query for any AIA trial, and (b) a USPTO Patent Center check for any ex parte reexamination certificate and for the scope of the 2004-07-06 certificate of correction. Both are quick, and both are the kind of thing opposing counsel will check.

If you are the patent owner or a licensor: the record cuts against you. Expired, never asserted, never reassigned, no PTAB history, no litigation history, and no continuation family carrying the claims forward in unexpired form. Any value theory has to rest on pre-2022 activity, and the § 286 six-year bar means the damages window is narrow and closing.

Links for citation:

• Patent document: https://patents.google.com/patent/US6732329/en
• Justia copy (claim text): https://patents.justia.com/patent/6732329
• PTAB E2E (proceeding search, for the E2E confirmation in step 4): https://ptacts.uspto.gov/ptabweb/ (search by patent number 6,732,329)
• CourtListener (for the CAFC confirmation in step 4): https://www.courtlistener.com/?q=%226%2C732%2C329%22

Note on confidence: I am highly confident there are no AIA trial proceedings on this patent — the structured ODP block is authoritative and my independent searches returned nothing on-patent. The only "unknowns" are the two low-probability items in step 4, which are verification chores rather than live risks.

I'll verify the assignment record against the primary sources before writing.

Inventors

Notes on pattern: This is a single-inventor patent — no co-inventor coordination to analyze. Bace is credited with 16 patents at Intel on the Patent Leaderboard index, i.e. he was a regular Intel filer, and the patent remained an Intel asset for its full life. There is no evidence of inventor departure within 12 months of filing, no re-assignment of inventor-side rights, and no indication of the pre-fire-sale inventor-exodus pattern you asked me to watch for. Absence of that signal is a negative finding, not a positive one.

Data discrepancy worth flagging: the Google Patents page for this document gives a "prior art date" of 2001-03-27 (the filing date), while the Unified Patents portal entry lists the priority date as 2001-03-26. This is a one-day indexing inconsistency between databases, not a substantive chain-of-title issue. I have not auto-corrected either value.

Original assignee

Intel Corporation (Santa Clara, California), per the issued patent front page ("Assigned to Intel Corporation, Santa Clara, Calif. (US)") and the recorded assignment.

• Primary line of business: Intel is a semiconductor and platform company — microprocessors, chipsets, networking silicon (including the IXP network-processor family and PRO/1000-class Ethernet controllers, the product lines most directly relevant to the header-checksum-offload subject matter claimed here), wireless, and data-center products.
• Did they ship a product embodying the claims? Not verifiable from the record I could reach. The patent claims a method and apparatus for computing a header checksum when a middle segment of an octet string is replaced (claims 1, 7, 13, 16), which maps onto checksum recomputation in packet paths — plausibly Intel network-processor / NIC firmware, but I have no citation tying these specific claims to a shipping Intel product. I will not assert product practice without evidence.
• Current status: Operating company. Intel remains the assignee of record. The patent itself is Expired – Lifetime, adjusted expiration 2022-10-12 (status as listed by Google Patents from the USPTO record). Intel was not acquired, dissolved, or in bankruptcy at any point in this patent's life.

Assignment timeline

The patent has one recorded assignment — the original inventor-to-Intel assignment. There are no post-issuance assignments of record.

• 2001-07-03 (executed) / recorded 2001-07-05 — Reel 011717 / Frame 0176
  • Conveyance: Assignment of Assignors' Interest ("ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNOR: BACE, MATTHEW M.")
  • Assignor: Matthew M. Bace (individual inventor), North Andover, MA
  • Assignee: Intel Corporation, Santa Clara, CA
  • Correspondent: Not determinable from the sources I could reach. The assignment abstract reproduced in the Google Patents legal-events record for this patent lists only assignor, reel/frame, and effective date. The corresponding attorney/agent of record for the prosecution of the application is Seth Z. Kalson (listed on the patent as "Attorney, Agent or Law Firm"). I want to be precise here: Kalson is prosecution counsel of record, not confirmed as the correspondent who filed the assignment cover sheet with the USPTO Assignment Division. Separately, assignment.uspto.gov records show the 2001-07-05 recordation was handled under INTEL CORPORATION's own name as the recording party line, with the reel/frame REEL/FRAME 011717/0176. I could not open the Assignment Center detail view (see caveat below), so I am not able to report the named correspondent with confidence, and I decline to guess.
  • Context: Original-prosecution assignment — routine inventor-to-employer conveyance of all right, title, and interest, executed ~14 months after filing and recorded 2 days later. Not a fire-sale, not a securitization, not an NPE transfer.

Other USPTO legal events in this chain (not assignments, but relevant to ownership posture) — from the Google Patents legal-events table:

Caveat on completeness of legal events: the fetched Google Patents legal-events capture terminates at the year-12 payment (2015-10-21). A year-16 maintenance payment would have fallen due around 2019 and does not appear in the extract I retrieved. Because the status reads Expired – Lifetime rather than Expired – Fee Related, the fee was evidently paid and the patent ran to its adjusted expiration on 2022-10-12; but I am flagging the gap rather than filling it.

If the Assignment Center has no records: it does have one — the 2001 inventor assignment — so the "stop after this section" instruction does not apply. But the substantive point stands: the chain contains only the original assignment. For the remaining ~18 years of the patent's life there is no recorded transfer of any kind, which under your own rule of thumb means the original assignee (Intel) still owned the patent at expiration.

Timeline diagram

timeline
    title Ownership of US 6732329
    2001 : Inventor Bace executes assignment
         : Recorded at Reel 011717 Frame 0176
         : Intel Corporation named assignee
    2002 : Pre-grant publication 2002 0184598 A1
    2004 : Patent issues to Intel
         : Certificate of correction recorded
    2007 : Maintenance fee paid year 4
    2011 : Maintenance fee paid year 8
    2015 : Maintenance fee paid year 12
    2022 : Patent expires in Intel name

NPE / troll-pattern signals

Verdict

Insufficient data — with the specific qualification that this is the "only the original assignment" prong of that category, not an absence-of-records situation, and that no NPE signal is present.

Justification: the entire recorded chain of title is a single document — Reel 011717/0176, executed 2001-07-03, recorded 2001-07-05, conveying Matthew M. Bace's rights to Intel Corporation, followed by a 2004-07-06 certificate of correction and maintenance-fee payments in 2007, 2011, and 2015, all with no further transfer. Because there is only one link and no litigation was found against this patent, the record supports neither an NPE verdict (zero of the eight signals present) nor the "operating-company assertion" verdict (Intel is an operating company, but there is no assertion to point to); the "defensive/non-asserting" verdict would require a defensive-aggregator terminus, which does not exist here. The honest characterization is: a 21-year-old Intel asset that was never reassigned, was maintained to term, and expired in Intel's name on 2022-10-12.

Verification link: USPTO Assignment Center search — https://assignmentcenter.uspto.gov/ (search patent number 6732329; equivalent legacy interface at https://assignment.uspto.gov/patent/index.html). Google Patents legal events for the same record: https://patents.google.com/patent/[US6732329](/patent/US6732329)/en.

Sourcing caveat — please read

I was not able to open the Assignment Center detail view directly; it is an interactive/gated interface and the detail page (which is where the correspondent of record field lives) did not render content to my queries. The reel/frame (011717/0176), execution date (2001-07-03), recording date (2001-07-05), assignor, and assignee above are drawn from the USPTO-derived assignment abstract reproduced in the Google Patents legal-events record for this patent and corroborated by the patent front page and the Justia Patent History entry. The correspondent of record is therefore the one field in your requested schema I could not populate, and I have declined to infer it from the prosecution attorney's name or from Intel's in-house practice. If you need that field confirmed to a defensible standard, pull the Reel 011717/0176 cover sheet image directly in Assignment Center; that single retrieval would close the only open item in this chain.

I'll search for each cited reference to build an accurate prior-art analysis. Let me run several targeted queries.

Now let me search the remaining cited references.

Prior-Art Analysis — US 6,732,329 B2

Technical analyst assessment. Claim references use the independent-claim map already established for this patent (independent claims 1 (method), 7 (article of manufacture), 13 (communication network), 16 (formula-reciting method), with dependents 2–6, 8–12, 14–15, 17). Dates below are the ones printed in the '329 record unless noted; I have not auto-corrected any identifier. Nothing here is a legal conclusion of invalidity — it is a mapping of each cited reference to the claim language.

0. Scope and a note on the search

The task asks for the prior art cited on the face of 6732329. The '329 record (Google Patents rendering of the USPTO record) lists exactly eight cited references in its "Citations / Patent Citations" tables. Those eight are listed and analyzed below. I treat the number 6732329 literally and exclude references to other patents that carry a "’329" shorthand (e.g., the unrelated Techiya/Harman or Delaware "’329" matters already noted in the litigation section).

Caveat on sourcing: I retrieved and read full text for US 5,050,166; EP 0 465 006 A1; US 5,701,316; US 5,935,268; and US 6,341,129. My search budget was exhausted before I could independently pull the full text of US 5,745,502, US 5,996,113, and US 2003/0061561 A1; for those three I rely on (a) the citation metadata printed in the '329 record and (b) general knowledge, and I flag the lower confidence explicitly. Where a substance statement is not verified against full text, it is marked [unverified].

1. The eight cited references at a glance

Note on date class: references A–F were all published/granted more than one year before the '329 filing date, so they are §102(b) art. References G and H were filed before 2001‑03‑27 but published/granted after it — they are §102(e) art (as of their filing dates), which is why they appear as "cited" rather than "background" art.

---

2. Reference-by-reference

A. US 5,050,166 A — Cantoni et al., "Transfer of messages in a multiplexed system" (granted 1991‑09‑17)

Description (verified). A segmentation-and-reassembly scheme: variable-length messages are carried over a network in fixed-length slots, each slot having a header containing a short source-identifier (SI) field that logically links all segments of one message; a reassembly machine at the destination uses the SI codes to reassemble. The disclosure also describes error checking: the segmentation machine computes a "CHECKSUM … [a] sum of all octects in a received message," and the reassembly machine recomputes it and compares ("CHECKSUM GOOD") to decide whether to pass the message up or discard it. The reference is a network-architecture reference; its checksum discussion is conventional from-scratch verification.

Potential §102 relevance. Preamble/environment only. Claim 13 recites "a communication network comprising: a node; and a network medium," with the node propagating packet signals — Cantoni discloses an access-unit (node) coupled to network buses (medium) propagating slots. But claim 13 requires the node to perform the even-octet-aligned checksum operations, the conditional subtraction, etc., none of which Cantoni discloses. Same for independent claims 1/7/16 (the "propagate … signals indicative of a first packet and a second packet" preamble). Assessment: not anticipatory of any of claims 1–17; best characterizable as §102(a)/(b) background art for the network/slot environment of claim 13.

---

B. EP 0 465 006 A1 — Digital Equipment Corp., "A method for generating a checksum" (published 1992‑01‑08)

Description (verified). Generates a checksum for a bit string by grouping contiguous octets and producing a checksum value from two running variables C0 and C1 computed with modulo‑255 arithmetic (a Fletcher-style arithmetic checksum, citing J.G. Fletcher, An Arithmetic Checksum for Serial Transmission, IEEE Trans. Comm. 1982). The EPO search report accompanying this family cites Nakassis, Fletcher's error detection algorithm (1988), and Cockburn, Efficient implementation of the OSI transport-protocol checksum algorithm using 8/16-bit arithmetic (1987).

Potential §102 relevance. Establishes that weighted/iterative checksum generation was known, and that an incremental checksum is expressible via running sums. But its arithmetic (mod 255, two-sum Fletcher) is a different arithmetic from the '329's 16-bit one's-complement ⊕ with a checksum-subtraction operator ⊖ and octet swap, and it does not disclose updating a checksum when a middle segment of a packet is replaced. Assessment: not anticipatory of any claim. Most relevant as §102(a)/(b) background for the general checksum concepts of claims 1/16.

---

C. US 5,701,316 A — Unisys Corp., "Method for generating an internet protocol suite checksum in a single macro instruction" (granted 1997‑12‑23)

Description (verified). Discloses a Block Add Octets (BAO) machine instruction that computes the 16-bit one's-complement Internet checksum over message octets in a block, using native one's-complement arithmetic (so overflow is handled by the "end around carry" that the instruction eliminates), handling partial double-words, full double-words, and odd numbers of double-words. It explicitly builds on RFC 1071 ("Computing the Internet Checksum," Braden/Borman/Partridge, 1988).

Potential §102 relevance. This is the reference that supplies the arithmetic substrate the '329 claims presuppose. It is directly on point for the limitation, found in claims 4, 10, and 16, that the checksum operations are 16-bit operations, and for the ⊕ (one's-complement 16-bit) summation the '329 uses. However, '5701316 computes the checksum from scratch; it does not disclose updating a pre-computed checksum S_A to a new S_B by removing the old middle-segment checksum (the '329's ⊖ step) or the head/tail segmentation and octet-swap handling. Assessment: not anticipatory of any of claims 1–17, but it is the strongest §102(a)/(b) reference for the checksum-arithmetic limitations of claims 4, 10, and 16, and a natural §103 secondary reference against the ⊕/⊖ operators recited in claim 16.

---

D. US 5,745,502 A — Ericsson, Inc., "Error detection scheme for ARQ systems" (granted 1998‑04‑28) — [unverified full text]

Description. Cited in the '329 record as an ARQ (automatic repeat request) error-detection reference. ARQ art generally concerns detecting a corrupted transmitted block and triggering retransmission, typically with a per-block check code. [unverified] — I could not pull the full text in this session.

Potential §102 relevance. On its face, ARQ error detection is a different problem from incremental header-checksum recomputation on segment replacement. No element of the '329 claims' distinguishing features (even-octet alignment, middle-segment replacement, checksum subtraction) is expected to appear. Assessment: not anticipatory of any claim; background art only. Should be re-checked against full text before being relied on either way.

---

E. US 5,935,268 A — Bay Networks, Inc. (Jeffrey C. Weaver), "Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet" (filed 1997‑06‑03, granted 1999‑08‑10)

Description (verified). This is the closest prior art in the cited set. It addresses exactly the '329's problem statement: an original data block (e.g., an Ethernet frame) has a first error-detection code (a CRC); the block is then modified — e.g., a VLAN header is inserted, or data is inserted/removed so that a portion of the original block is shifted — which invalidates the original CRC. Rather than recompute from scratch (which would discard the protection accumulated so far), it: (i) computes a second EDC for the inserted/first data shifted to the position it occupies in the modified block; and (ii) combines the first and second EDCs — by XOR — to yield a third EDC for the modified block. Where a portion of the original block is shifted, it computes a fourth EDC for that portion at its original position and a fifth EDC at its modified position and XORs the first, second, fourth and fifth EDCs. The claims recite an apparatus and a computer-readable medium as well as the method.

Potential §102 relevance. This maps, structurally and conceptually, onto the '329's independent claims:

• Claim 1 / claim 7 / claim 13 (the base case): '268's "original block with first EDC" ≈ the '329's first packet with first checksum S_A for Φ_A; '268's "second EDC for the first data" ≈ the '329's new middle checksum Ŝ_1 = f(φ̂_1); '268's "XOR the first and second EDCs" ≈ the '329's combination of S_A with the new-middle and old-middle checksums. Key literal gap: the '329 requires the operation applied to the old middle checksum to be a checksum subtraction operation (⊕ with the one's-complement inverse), whereas '268 combines with XOR over a CRC. In the CRC/GF(2) domain, "removing" the shifted portion is achieved by XOR (XOR is self-inverse), so the two are functionally analogous — but they are not literally the same operator. Under a strict, literal reading of "checksum subtraction operation," '268 does not anticipate claim 1/7/13; under a broader reading of "checksum" it is the leading §102 candidate.
• Claim 16 (the explicit formula S_B = S_A ⊕ Ŝ_1 ⊖ S_1): '268 describes the same arithmetic shape (original code combined with a new-segment code and a treatment of the displaced old segment). But claim 16 recites a 16-bit one's-complement ⊕ and ⊖, which '268 does not; and '268's displaced-portion handling (fourth/fifth EDCs) is CRC-based. Not literal anticipation, but the closest art on the incremental-update concept.
• Claims 2/3, 5/6, 8/9, 11/12, 14/15, 17 (odd-length-difference branch, octet-swap): '268's "portion of the original block shifted" case (needing fourth and fifth EDCs, i.e., accounting for the shift) is the analogue of the '329's odd-number-of-octets branch that forces the octet-swapped tail checksum. But '268 never discloses the specific octet-swap (α0|α1 → α1|α0) operation that the '329 uses to handle the alignment shift, nor the "compute only the shorter of head/tail and derive the other by subtraction" optimization of the '329 (Eqs. 4–5). Not anticipatory of these dependent claims.

Assessment: US 5,935,268 is the primary reference for any §103 challenge to the family of independent claims, and it is the only cited reference that recites the incremental update of a check code when a segment of an existing packet is replaced — the very premise of the '329. It does not stand alone as a §102 anticipation under the literal claim language, because the '329 claims are confined to the one's-complement/16-bit "checksum" with a subtraction operator and to the even-octet-alignment/octet-swap mechanics. Layering US 5,701,316 (C) onto '268 supplies the 16-bit one's-complement checksum arithmetic and would close much of the §103 gap; the residual novelty is the octet-alignment/octet-swap and the head/tail optimization.

---

F. US 5,996,113 A — Intel Corp., "Method and apparatus for generating digital checksum signatures for alteration detection and version confirmation" (filed 1996‑11‑26, granted 1999‑11‑30) — [unverified full text]

Description. Same assignee as the '329 (Intel). The title states its purpose: generating digital checksum signatures used for alteration detection and version confirmation — i.e., using a checksum as a fingerprint to detect whether data has been altered and whether a version has changed. [unverified] for claim-level detail.

Potential §102 relevance. This is a same-owner reference on the purpose of checksums (integrity/alteration detection), which is consistent with the '329's framing ("a checksum is used to detect errors"). It does not appear to disclose the '329's incremental-update algorithm (middle-segment replacement, even-octet alignment, subtraction, octet swap), so it is not anticipatory of any claim; background art only, and it may bear on the ordinary-skill level and on the state of Intel's own art.

---

G. US 6,341,129 B1 — Alteon Networks, Inc., "TCP resegmentation" (filed 1998‑04‑03, granted 2002‑01‑22)

Description (verified). A resegmentation entity (e.g., a router) splits a large TCP segment into subsegments sized to the receiving host's MTU, producing "resegmented TCP header + resegmented TCP data" IP datagrams; its disclosed algorithm loops over subsegments and, for each new subsegment, copies the original IP and TCP headers, adjusts TCP SYN/FIN/PUSH/URG and sequence/urgent pointers, sets the new datagram length, and then "recalculate the TCP checksum" and "recalculate the IP checksum" before sending.

Potential §102 relevance. On point for the '329's environmental premise — creating a second packet derived from a first packet and needing a new checksum (claim 1's preamble; claim 4's "the second octet string is related to the first … by replacing the middle segment … and appending … a zero octet if necessary"). But '341,129 recomputes the TCP/IP checksums (from scratch over the new segment); it does not disclose deriving S_B from a pre-computed S_A via even-octet-aligned partial checksums and a checksum subtraction. Assessment: not anticipatory of any claim. Useful as §102(e) art for the environment/preamble limitations of claims 1, 7, 13, and 16 (packet derived by alteration, new checksum required), and as a §103 secondary reference showing that recomputing versus incrementally updating was a recognized design choice.

---

H. US 2003/0061561 A1 — Analog Devices, Inc., "Method, apparatus, and product for use in generating CRC and other remainder based codes" (filed 2000‑02‑17, published 2003‑03‑27) — [unverified full text]

Description. A published application (thus §102(e) art as of its 2000‑02‑17 filing date, despite its 2003 publication date) directed to generating CRC and other remainder-based codes — i.e., polynomial long-division check codes, as opposed to the one's-complement sum checksums of the '329.

Potential §102 relevance. Different code family (CRC/remainder vs. Internet one's-complement checksum) and no disclosure of incremental update on segment replacement. Assessment: not anticipatory of any claim; §102(e)/background art for the general field of error-detection code generation.

---

3. Ranking and the "most relevant" prior art

4. Bottom line on §102

Under the literal claim language, none of the eight cited references anticipates any of claims 1–17 as a single reference. The two limitations that break clean anticipation are:

1. "even-octet-aligned checksum operation" and the "checksum subtraction operation" (claims 1, 7, 13, 16) — the incremental art that exists (US 5,935,268) uses a CRC/XOR framework, not a one's-complement 16-bit checksum with a defined subtraction operator (⊕ with the inverse).
2. The octet-swap handling of the odd-length-difference case and the head/tail "compute the shorter, derive the other by subtraction" optimization (claims 2/3, 5/6, 8/9, 11/12, 14/15, 17; spec Eqs. 3–5) — no cited reference discloses the octet-swap (α0|α1 → α1|α0) mechanism at all.

The strongest validity exposure is therefore §103, not §102: US 5,935,268 (incremental check-code update on packet modification) in view of US 5,701,316 (16-bit one's-complement Internet-checksum arithmetic), with US 6,341,129 and EP 0 465 006 as further secondary art. US 5,935,268 alone is the single most relevant reference and the correct starting point for any obviousness analysis of independent claims 1, 7, 13, and 16.

5. Discrepancies / confidence flags

• Three references not independently verified: US 5,745,502, US 5,996,113, and US 2003/0061561 A1 — descriptions rely on the '329's citation metadata plus general knowledge; marked [unverified]. Re-run full-text retrieval for these before relying on the §102 assessment for them.
• US 6,341,129's publication date (2002‑01‑22) is after the '329 filing date, so it is not §102(b) art; its prior-art effect is only via §102(e) as of its 1998‑04‑03 filing date. The same logic applies to US 2003/0061561 A1 (effective as art from its 2000‑02‑17 filing date). This is consistent with their appearance as cited art rather than "background."
• No auto-correction applied: all patent/publication numbers are used exactly as printed in the '329 record; where two sources would give different dates for the same reference, the dates printed in the '329 citation tables are used.
• The '329's own internal inconsistencies (the claim 16 " (S_1)′ " vs. spec block 416 " (S_2)′ " octet-swap discrepancy, and the duplicated "l(φ_0)≧l(φ_2)" condition) were flagged in the earlier claim-summary section; they do not change what the cited prior art discloses, but they would matter if claim 16's exact scope were being litigated.

If you want, I can next pull and verify the three [unverified] references and build a limitation-by-limitation §103 chart for US 5,935,268 + US 5,701,316 against each independent claim.

I'll ground this obviousness analysis by pulling the actual content of the key cited references before analyzing the combinations.

Let me pull the remaining cited references and the RFC that the field treats as foundational.

Obviousness Analysis — U.S. Patent No. 6,732,329 B2 under 35 U.S.C. § 103

Scope note. The '329 patent (filed 2001‑03‑27, granted 2004‑05‑04) is pre‑AIA, so pre‑AIA § 103(a) governs; the Graham v. John Deere factors and KSR v. Teleflex rationales apply unchanged. This analysis builds on the claim breakdown in the earlier "Patent summary" and does not repeat it. It uses the references listed in the "Prior Art" / citations sections of the patent page (https://patents.google.com/patent/US6732329/en).

Cross‑reference / contradiction flag (required by the operating rules). The earlier summary stated that "Claim 16's final formula as printed renders as S_B = S_0 ⊕ Ŝ₁ ⊖ (S₁)′." Per the claim text as reproduced on the page, claim 16 ends with S_B = S_A ⊕ Ŝ₁ ⊖ S₁ (the even‑difference case), and the formula containing S_0 ⊕ Ŝ₁ ⊖ (S₁)′ appears in claim 17 (the odd‑difference case). I therefore re‑attribute that formula to claim 17 and note the separate literal discrepancy the earlier summary identified: claim 17 swaps S₁, whereas specification Eq. (3) and FIG. 4 block 416 swap the tail checksum S₂. I do not auto‑correct the identifier or the formula; I only flag the attribution mismatch and the S₁/S₂ discrepancy.

---

1. Person having ordinary skill in the art (POSITA)

A POSITA as of March 2001 would hold a B.S. in electrical engineering or computer science (or equivalent) plus roughly 2–5 years of experience implementing network protocol stacks, and would be familiar with: (i) RFC 1071, "Computing the Internet Checksum" (Braden, Borman, Partridge, Sept. 1988) — expressly cited on this very page and in US 5,701,316; (ii) 16‑bit one's‑complement (end‑around‑carry) arithmetic; (iii) TCP/IP header formats and the checksum field; and (iv) checksum offload / partial‑checksum hardware practice. This is a modest skill level; the art is arithmetically well‑trodden.

2. The limitations that matter for § 103

Stripped to its gist, independent claim 1 requires three things beyond the packet‑propagation preamble:

1. Even‑octet‑aligned checksum operation on each of the middle segment and the new middle segment (claims 1, 7, 13; formalized as f(·) in claim 16).
2. Conditional trigger — the combination step applies only when the middle and new middle segments differ in length by an even number of octets.
3. A checksum subtraction applied to the old middle checksum when combining (claims 1, 7, 13; claim 16 states it as S_B = S_A ⊕ Ŝ₁ ⊖ S₁).

The dependent claims add the odd‑length branch (octet‑swapped tail term, S_B = S₀ ⊕ Ŝ₁ ⊕ (S₂)′) and the "compute the shorter of head/tail, derive the other by subtraction" optimization (Eqs. 4–5).

3. The references, and what each actually teaches

4. Grounds of rejection

Ground A (primary): Bay Networks '268 + RFC 1071 + Unisys '316

This is the strongest ground and it reaches claims 1, 4, 7, 10, 13, and 16.

• '268 supplies the method framework and the motivation. Claims 1/7/13 recite propagating "a first packet … comprising a first checksum for a first octet string comprising a middle segment" and "a second packet comprising a second checksum for a second octet string comprising a new middle segment." That is exactly the '268 scenario: an original block with a first EDC and a modified block (original with a segment replaced/inserted) needing a new EDC. '268's computation of an EDC for changed data "shifted to a position corresponding to its position within the modified data block" — and its separate EDCs for a moved portion at its original versus modified positions — is the same insight the '329 patent exploits: measure the changed segment, aligned to where it sits, and combine with the pre‑existing code.
• RFC 1071 supplies the subtraction. The "checksum subtraction" limitation (claims 1, 7, 13, 16) is RFC 1071's incremental‑update formula in one's‑complement arithmetic: new checksum = old checksum − old word + new word. Claim 16's S_B = S_A ⊕ Ŝ₁ ⊖ S₁ is precisely this operation applied to a segment rather than a single word.
• '316 supplies the 16‑bit/alignment limitation. Claims 4/10 require "16‑bit operations" on even‑length octet strings. '316 teaches the 16‑bit one's‑complement Internet checksum and, expressly, that octet even/odd assignment must be preserved — which is the functional content of the "even‑octet‑aligned checksum" limitation (f(·) is simply a 16‑bit sum performed with the segment's boundaries padded to even addresses so octet pairing is correct, exactly what '316 says must be respected).

Motivation to combine (KSR): (1) all three are in the same field — packet error detection for TCP/IP; (2) each independently identifies the same problem (checksum‑generation overhead / cost of recomputation) and '268 expressly criticizes recomputing from scratch; (3) the combination is a mere substitution of one known arithmetic update rule (RFC 1071's subtract‑old/add‑new) into a known incremental‑update architecture ('268), a predictable result with no change in function; (4) the field presented only a finite set of predictable options for reducing recomputation, making the approach "obvious to try."

Ground B: Ground A + EP 0 465 006 (DEC)

Adds the modular‑arithmetic and segment‑scope foundation. EP '006 teaches checksum computation over a defined scope using mod (2^q − 1) arithmetic with q = 16, i.e., the algebra of the ⊕/⊖ operators, and teaches computing the checksum over a selected sub‑string. This reinforces that "compute a checksum over a chosen segment of the packet, with one's‑complement style modular addition" was known, and supplies an alternative articulation for the "even‑octet‑aligned checksum operation" limitation for claims 1/7/13 and for the narrower 16‑bit limitation of claims 4/10.

Ground C: Ground A + Alteon '129 (TCP resegmentation)

Best used against the claim preambles and against the odd‑length dependent claims. '129 teaches modifying a packet's segmentation, generating "a new TCP checksum on each new segment," and expressly notes the operation is "processor intensive" — supplying a concrete, contemporaneous reason a POSITA would seek a cheaper way to produce the new checksum than a full rescan. It also confirms that the modified packet's header/checksum field is recomputed in situ as the packet is forwarded, matching the "propagate … signals indicative of a first packet and a second packet" recitation.

Ground D (odd‑length / octet‑swap claims): Ground A + '316 alignment teaching + RFC 1071 octet‑pairing/byte‑order discussion

Claims 2, 3, 5, 6, 8, 9, 11, 12, 14, 15, and 17 require that, for an odd length difference, the tail checksum enters octet‑swapped (S_B = S₀ ⊕ Ŝ₁ ⊕ (S₂)′). The argument is:

• '316 teaches that the 16‑bit checksum depends on which octets pair together (even‑address octets with even, odd with odd).
• Inserting a single octet into the middle of an octet string re‑pairs every subsequent octet; therefore the checksum of the shifted tail is not the checksum of the tail as it stood, but its octet‑swapped version. This is elementary one's‑complement algebra once the pairing rule is known.
• '268 teaches the same "position‑shift" accounting at the block level (computing the code for a moved portion at both its old and new positions and combining), which is the structural analogue of adding the swapped term.
• Tellingly, the '329 specification states the "Checksum String Shifting property … without proof," i.e., the inventors themselves treat it as an established algebraic result rather than a discovery. That framing materially undercuts any non‑obviousness argument built on the swapped‑tail term.

Motivation: minimizing the number of re‑computations (only the shorter of head/tail is computed; the longer is derived by subtraction per Eqs. 4–5) is a straightforward optimization of a known computation, squarely within KSR's "design choice" and "predictable variation" rubrics.

5. Secondary considerations

No record evidence of unexpected results, long‑felt but unsolved need, or industry praise tied to the claimed steps appears in the material reviewed; the earlier sections confirm the patent was never assigned away from Intel and shows no litigation or post‑grant challenge, so there is no presumption‑bearing record to weigh. Absent such evidence, secondary considerations do not rebut the grounds above. (The 2004 certificate of correction and the claim‑17 S₁/S₂ discrepancy affect clarity, not the § 103 comparison.)

6. Weaknesses a challenger (or a patentee) should account for

1. '268 is CRC/XOR‑based, not one's‑complement. Its "adding" step is XORing EDCs, which is valid because CRC is linear over GF(2), whereas the '329 claims demand one's‑complement subtraction. A patentee will argue that combining '268 with RFC 1071 is not a mere substitution but a re‑derivation of the algorithm. That argument is answerable by the RFC 1071 incremental‑update formula, which already provides the exact subtract‑old/add‑new operation, but it is the point to litigate.
2. The even‑octet‑aligned f(·) construction and the odd‑length octet‑swap are the sophisticated elements. Whether a POSITA would have arrived at the specific pairing of (a) even‑octet‑aligned partial checksums, (b) subtraction for the even case, and (c) octet‑swap for the odd case, is the genuine question. Claims 1/7/13/16 (even case) are the most vulnerable; claims 2/3/17 and their kin (odd case) are the most defensible, unless a reference is found that expressly teaches the octet‑swap‑for‑shift relation.
3. Retrieval gaps. I could not verify US 5,050,166 or US 5,745,502, and only partially verified US 2003/0061561 A1; a complete § 103 analysis should confirm whether any of them discloses shifting/alignment handling in a one's‑complement checksum, which could close the gap on the odd‑case claims.

7. Bottom line

In short: the base, even‑length aspect of the invention — incremental one's‑complement checksum updating of a packet whose middle segment was replaced — is on strong § 103 ground against Bay Networks '268 in view of RFC 1071 and Unisys '316 (with DEC EP '006 and Alteon '129 as corroborating secondary references). The odd‑length octet‑swap aspect is the only materially contestable territory, and its defensibility depends on whether the octet‑swap‑for‑one‑octet‑shift relationship is shown to have been known or readily derivable in the 2001 art.