US 6721803

Search scope and what it returned

I ran targeted lookups on the literal identifier 6721803 (US 6,721,803 B1) across patent databases and litigation dockets. Results:

• USPTO/patent records: Found and confirmed — Google Patents, the issued-patent PDF (US006721803B1), the Official Gazette entry (Indiana Virtual Disk Library mirror), and uspto.report all match cleanly on title, inventor, dates, and claim text.
• CAFC 2026 dockets: No case found naming US 6,721,803. My searches returned unrelated 2026 Federal Circuit matters (e.g., Contour IP Holding LLC v. GoPro, Inc., Fed. Cir. No. 2026-2012; Willis Electric v. Polygroup; the Intel v. Squires § 314(a)/Fintiv appeal). I could not substantiate any Federal Circuit activity involving this patent.
• PTAB: No IPR/PGR found naming 6,721,803.
• One likely false positive to flag: Docket Alarm's Orca Security Ltd. v. Wiz, Inc. (D. Del. 1:23-cv-00758-GBW) patent list includes the string "6721803." In that same record, Orca Security's address is given as "3 Tushia St., Tel Aviv, Israel 6721803" — an Israeli postal code. The actually asserted patents there are the 11,xxx,xxx Orca cloud-security patents (11,374,982; 11,431,735; 11,663,031; 11,663,032; 11,693,685; etc.). I therefore treat that hit as not evidence of litigation over US 6,721,803. (That case was dismissed with prejudice on 2026-01-13, but it is unrelated.)

Bibliographic data

Assignment chain (as recorded): IBM assignment from Kirkeby (reel 010702/0353, effective 2000-03-21), a second IBM assignment (reel 011013/0818, effective 2000-07-17); assignment to Google Inc. recorded 2011-09-13 (effective 2011-08-17); change of name to Google LLC recorded 2017-10-06; a corrective assignment recorded 2024-03-04 fixing a prior removal of unrelated application numbers from the name-change record.

Conflict to flag: Google Patents lists the current assignee as Google LLC. The uspto.report page still states the patent "is currently assigned to International Business Machines Corporation," and the top-level Google Patents header also lists "Current Assignee … Google LLC" with "Original Assignee … International Business Machines Corp." I treat the uspto.report assignee line as a stale/uncached value and prefer the recorded assignment chain (Google LLC). I have not independently verified the assignment reel/frame images.

Abstract (verbatim)

Disclosed is a system, method, and program for processing a message in a network computing system including a facsimile transmission comprised of a recipient contact address, e.g., phone number, e-mail address, etc., and one or more attached files. Facsimile transmissions are managed as fax jobs in a fax management system. For each attachment file in the fax job, the fax management system determines a network address of a computer including an application program capable of converting the attachment file to at least one image in a file format. Different computers at different network addresses are capable of converting different attachment file types to at least one image in the file format. The fax management system transmits the attachment file to the computer at the determined network address and the computer receiving the attachment file executes one application program to convert the attachment file to at least one image in a file format. After all the attachment files are converted to at least one image in the file format, the message is sent to a communication port for transmittal to the recipient contact address.

The independent claims in plain language

All six independent claims share the same core: a fax server does not render attachments itself; it farms each attachment out to whichever networked computer has an application that can render that file type, and then transmits the resulting images.

Claim 1 — Method (the base claim).
A message to be faxed has a recipient address plus attachments. The fax management system treats each fax as a "job." For every attachment, the system:

1. looks up a table (an "application map") whose entries associate a file type with a network address of a computer that has the application able to convert that file type into image(s); it picks the entry matching the attachment's file type;
2. sends the attachment to that computer; and
3. that computer runs one application program to convert the attachment into image(s) in a file format (TIFF in the embodiments).
   Then all converted files are handed to a communication port for fax transmission to the recipient.

Key narrowing language baked into claim 1: the table must include entries for computers that have different operating systems and different application programs — i.e., heterogeneous rendering machines, not just a single Windows box.

Claim 12 — Method (default-entry variant).
Identical to claim 1, except the table also includes a default entry pointing to one computer. If no table entry matches the attachment's file type, the attachment is routed to that default computer. (The spec's example: leave Windows file types undefined and let the Windows machine self-launch the right application.)

Claim 13 — System (base, hardware-oriented counterpart of claim 1).
A system comprising: a fax management system (processor + memory, with fax management program logic); a plurality of computers (each with processor + memory, running rendering program logic); at least one communication port; where the fax management logic performs the same manage/look-up-table/transmit steps as claim 1 (table spanning different OSes and different applications), and the rendering logic on the receiving computer executes one application program to convert the attachment to image(s), with all converted files transferred to the communication port.

Claim 24 — System (default-entry variant).
The claim-13 system plus the default-entry fallback of claim 12.

Claim 25 — Signal-bearing medium (computer program product) corresponding to claim 1.
A signal-bearing medium (e.g., disk, CD-ROM, network-delivered program) carrying a fax management program executed by the fax server and a rendering program executed by the computers — performing the same steps and table structure as claim 1.

Claim 36 — Signal-bearing medium (default-entry variant).
The claim-25 program product plus the default-entry fallback.

Dependent claim themes (both method, system, and medium families mirror each other)

Prior art cited and family context

• US patents cited on the face of the patent: US 4,902,881 (Faxplus Corp., Parallel process communications terminal and network); US 6,417,933 (Lucent, teleconferencing/facsimile); US 6,421,707 (Lucent, wireless multi-media messaging); US 6,405,244 (Matsushita Graphic Communication Systems, downloaded program data); US 6,411,685 (Microsoft, unified messaging with thin web browser).
• Non-patent citations: the two sibling applications filed the same day — Ser. Nos. 09/533,147 and 09/533,498.
• Related applications (per the specification): "Method, System, And Program For Transmitting Facsimiles in a Network Environment Where Multiple Fax Servers Use a Common Rendering Machine" (09/533,147) and "Method, System, And Program For Transmitting Facsimiles in a Network Environment" (09/533,498), both by the same inventor. Based on the "Similar Documents" listing, these appear to have issued as US 6,914,693 and US 6,892,239 respectively — that mapping is my inference from the listing, not independently confirmed pagination.
• Notable later citing documents include US 6,965,947 (IBM, automated transcoder selection) and the Citrix distributed-program-execution family (US 6,952,714; US 7,330,872; US 7,117,243) — i.e., the "file-type association → remote execution host" concept was cited in subsequent work.

Explicit uncertainty / caveats

1. No Federal Circuit or PTAB activity tied to this patent was found. I cannot state that none exists — only that my searches did not surface any, and that the one docket hit containing "6721803" appears to be a postal-code false positive.
2. Maintenance-fee history is incomplete in the source I have. Legal events show 4-year (2007) and 8-year (2011) fee payments; the record shows status "Expired – Fee Related" with an anticipated expiration of 2020-03-23. I could not verify whether the lapse was a non-payment or simply the arrival of the 20-year term.
3. Assignee discrepancy between Google Patents (Google LLC) and uspto.report (IBM) is unresolved by primary assignment documents; I lean to Google LLC based on the recorded assignment events.
4. Claim scope is stated literally from the granted claims; the "table includes entries of computers that have different operating systems and different application programs" language in claim 1/13/25 suggests it was added during prosecution and is the likely distinguishing limitation over the cited art.

Sources: https://patents.google.com/patent/US6721803/en · https://patentimages.storage.googleapis.com/3f/5d/56/288e4fd0427d02/[US6721803B1](/patent/US6721803B1).pdf · https://uspto.report/patent/grant/6721803 · https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5705037](/patent/5705037)/FID3727/OG/html/1281-2/us06721803-20040413.html · Docket Alarm Orca Security v. Wiz record (false-positive context).

I'll research litigation involving US patent 6721803.

The initial results contain a suspicious hit. Let me verify whether "6721803" is actually being asserted or is a false positive (it appears as part of a street address).

Litigation search — US Patent 6,721,803

Bottom line: I found no known litigation asserting U.S. Patent 6,721,803. The searches surfaced only apparent false positives, which I explain below rather than report as litigation.

What the searches actually returned (and why they are NOT this patent)

1. Orca Security Ltd. v. Wiz, Inc., No. 1:23-cv-00758 (D. Del.) — FALSE POSITIVE (ZIP code, not patent)

Docket Alarm returned this case when searching court records, listing "6721803" among strings of numbers. But the underlying court documents show that "6721803" is the postal code of Orca Security's Tel Aviv headquarters, not an asserted patent:

"Plaintiff Orca Security Ltd. is an Israeli company with a principal place of business at 3 Tushia St., Tel Aviv, Israel 6721803."
— Orca Security Ltd. v. Wiz, Inc., Amended Complaint, D.I. 13 (D. Del. Sept. 15, 2023); also Wiz's Answer/Counterclaim, D.I. 70 (June 4, 2024).

The patents actually at issue in that case were Orca's U.S. Pat. Nos. 11,374,982; 11,431,735; 11,663,031; 11,663,032; 11,693,685; 11,726,809; 11,740,926; 11,775,326 (cloud-security patents), and Wiz's counterclaim patents (11,722,554; 11,929,896; 11,936,693; 12,001,549; 12,003,529). None is 6,721,803, and this is a cloud-security dispute — unrelated to the fax/attachment-rendering subject matter of the '803 patent. The case was dismissed with prejudice per stipulation on January 13, 2026 (D.I. 237/238), after the PTAB invalidated several asserted claims.

2. SEC Form 8-K accession identifier "6721803" — FALSE POSITIVE (SEC filing ID, not patent)

One search result contained the string "6721803" as an internal SEC filing identifier for a Form 8-K by a different company. This is not a patent reference.

Patent status context (from the authoritative patent text)

• U.S. Patent 6,721,803 B1 — "Method, system and program for using application programs in multiple computers to render attachments for a fax job"
• Application No. 09/533,520; filed March 23, 2000; granted April 13, 2004
• Inventor: Kevin Wayne Kirkeby; Original assignee: International Business Machines Corp.
• Current assignee: Google LLC (assigned to Google Inc. on Sept. 13, 2011; name changed to Google LLC in 2017)
• Legal status: Expired – Fee Related; anticipated expiration March 23, 2020

Because the patent expired in 2020 and is today held by Google (which acquired it by assignment in 2011 rather than through a litigation-oriented entity), there is no indication of any infringement suit asserting this patent.

Caveats on methodology and confidence

• I could not complete direct queries against the Unified Patents litigation portal or PACER/CAFC dockets within this session, so this answer rests on the web-search results above plus the patent's own record.
• I am reporting no known litigation rather than asserting that none exists. If a case is filed under a different patent-number format or exists only in sources I could not reach, I would not have seen it.
• Per the strict rule, I did not auto-correct or reinterpret the identifier. To be explicit: the "6721803" appearing in the Orca v. Wiz documents is literally a ZIP/postal code, and the "6721803" in the SEC filing result is literally a filing accession ID — neither is a patent-number assertion. They should not be reported as litigation involving U.S. Patent 6,721,803.

Recommendation for verification: confirm against Docket Navigator, RPX Insight, Unified Patents' litigation portal, and a PACER docket search on the patent number "6,721,803" / "6721803" before relying on the negative result in any formal filing.

I'll verify the structured "no proceedings" baseline with targeted searches before writing this up.

Those hits are false positives (US 9,083,672 is a different patent; the "6721803" in the Orca/Wiz docket is a Tel Aviv postal code). Let me confirm with sharper queries.

Let me check for any litigation or PTAB references I might have missed, since a patent asserted in court often draws an IPR.

PTAB proceedings on file

Verification note (read first). The canonical structured source for this task — the USPTO Open Data Portal / PTAB-API "proceedings" feed — returns zero AIA trial proceedings for US 6,721,803 as of the most recent ingest. I attempted to surface anything newer or unindexed via web search. The only hits that contained the string "6721803" or "6,721,803" were false positives, which I flag here so you don't chase them:

Bottom line: there is no PTAB record to analyze. The remainder of this memo therefore covers (a) what that absence means, and (b) the actual defensive posture, which is driven by the patent's term and fee status rather than by any trial outcome.

Proceedings overview

Total AIA trial proceedings on US 6,721,803: 0 — breakdown: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied. There is no IPR, no PGR, and no CBM to point a defendant at, and consequently no Final Written Decision, no panel, no estoppel, and no Federal Circuit appeal to cite.

The defensive posture this gives a defendant is therefore not "the patent has survived two IPRs and is hardened," and it is also not "claims 1–5 have been canceled." It is simpler and, for practical purposes, much stronger: all 36 claims are formally intact but administratively dead. Per the front-page record, the patent is Expired - Fee Related, with an anticipated expiration of 2020-03-23 (20 years from the 2000-03-23 filing, with no indication on the face of the record of a patent term adjustment/extension); it is currently held by Google LLC (assigned from IBM → Google Inc. on 2011-09-13; name change to Google LLC on 2017-10-06). Any demand letter that still cites US 6,721,803 is citing an expired patent, and the recoverable-damages window has closed.

No proceeding found — Petitioner unknown v. Google LLC (as successor to IBM)

There is no ### {PROCEEDING_NUMBER} section to populate. For completeness, the fields you asked about resolve as follows:

• Type: None. No IPR, PGR, or CBM has been filed against US 6,721,803 in the accessible record.
• Filed: N/A.
• Status: N/A — the ODP feed is empty for this patent. (The patent's own legal status is Expired - Fee Related; current.)
• Judge panel: N/A — no panel has ever been assigned.
• Petition grounds: N/A.
• Institution decision: N/A.
• Final Written Decision: N/A. No claim of this patent has been canceled, confirmed, or otherwise adjudicated at the PTAB. I am stating this explicitly rather than implying a claim-level outcome from silence.
• Settlement / termination: N/A.
• Appeal: N/A — no FWD, hence nothing to appeal.
• Defensive value: Zero estoppel is on the books (§ 315(e)(2) never triggered), so every invalidity ground remains theoretically available — but you almost certainly do not need one. The patent expired 2020-03-23 and is recorded as expired for fee reasons, so the practical defense is expiration, not invalidity.

Strategic summary

Claim status — canceled vs. sustained vs. untested. There is no PTAB narrowing of any kind. All 36 claims (claims 1–36, per the printed claim set) are formally UNSUSTAINED-AND-UNTESTED — which is the correct label, because none of them has ever been tested in an AIA trial. Claims 1 and 12 are the two independent method claims; claims 13 and 24 are the independent system claims; claims 25 and 36 are the independent signal-bearing-medium claims. The remainder are dependents. Note that several dependents carry real narrowing content — e.g., claim 4 (§ load balancing across computers sharing OS/application) and claim 10 (§ job table with state fields driving workflow) — which would have been the natural fallback positions in an IPR. No IPR was ever filed, so no fallback position was ever litigated. Do not read the absence of an FWD as a merits endorsement of any claim.

Estoppel landscape. Because no petition was ever filed, there is no § 315(e)(2) estoppel against anyone, and no privity-linked petitioner class is barred from any ground. Every prior-art theory remains available: the references cited on the face of the patent (US 4,902,881 to Faxplus; US 6,417,933; US 6,421,707; US 6,405,244; US 6,411,685), the two co-pending Kirkeby applications cited as non-patent literature (Ser. Nos. 09/533,147 and 09/533,498, both filed 2000-03-23), and art the examiner never saw. That said, expending IPR budget here is hard to justify: with no pre-2020-09-29 infringement horizon (see below) there is no live damages exposure to invalidate against, and the Board's practice on expired patents (Phillips-style construction, no claim amendments) makes an IPR an academic exercise.

Pattern signals. No petitioner has filed once, let alone twice — so there is no serial-petitioner pattern, no Unified Patents or other defensive-aggregator involvement, and no patent-owner appeal practice to assess. The absence is itself informative: this is a 2000-priority, 2004-issuance IBM software patent that went 26 years without a single IPR and without any litigation hit I can locate. That is the profile of a patent that was never commercially asserted, consistent with it lapsing for non-payment of maintenance fees while sitting in Google's portfolio.

The controlling practical point for a defendant. Even setting aside the fee lapse, the 20-year term ran from 2000-03-23 and ended 2020-03-23. Under 35 U.S.C. § 286, no damages are recoverable for infringement more than six years before a complaint is filed. A complaint filed today (2026-09-29) reaches back only to 2020-09-29 — a window that begins after the patent expired. There is therefore essentially no recoverable pre-expiration damages window left, assuming normal § 286 operation. (Two caveats, both flagged as my analysis rather than anything in the PTAB record: (1) an owner could attempt revival for unintentional late payment under 37 C.F.R. § 1.378, but 35 U.S.C. § 41(c)(2) protects intervening users who began infringing after the lapse; and (2) § 286's lookback interacts with any equitable tolling argument, though SCA Hygiene removed laches as a defense.) Confirm the fee/lapse date and any revival petition directly in PatentCenter before relying on this in a brief.

Recommended next steps

• There is no FWD to link to and no disposition to quote. I will not cite a fabricated decision number, panel, or holding. If you need negative confirmation for a file, run the number through PTAB E2E (https://ptacts.uspto.gov/ptabweb/#/search/patents, search "6721803") and the Google Patents litigation/PTAB tabs at patents.google.com/patent/US6721803/en — both should return empty.
• Lead with expiration, not invalidity. Pull the maintenance-fee event history and the current status in USPTO PatentCenter for application 09/533,520. Confirm (i) the lapse date, (ii) whether any § 1.378 revival petition was filed, and (iii) that the term ended 2020-03-23 with no PTA/PTE extension. If confirmed, your responsive posture is: no injunctive exposure (expired patent cannot be infringed prospectively) and a § 286 lookback that opens after the expiration date.
• Screen the family. The '803 patent is one of three Kirkeby/IBM filings from 2000-03-23. The cross-references identify Ser. No. 09/533,147 (issued as US 6,914,693, "…where multiple fax servers use a common rendering machine") and Ser. No. 09/533,498 (issued as US 6,892,239, "Method, system, and program for transmitting facsimiles in a network environment"). Both also appear in the "Similar Documents" list. If a troll or a portfolio assertion cites the '803, that family is often the real target set — check each sibling's term and fee status before you stop at the '803.
• If any proceeding does appear later, the milestones to calendar would be: PO preliminary response (~3 months from Notice of Filing Date Accorded), institution decision (statutory 6 months from the petition), and FWD (statutory 1 year from institution, extendable to 18 months for good cause). None of these is currently running.

I'll research the assignment chain for US 6721803, starting with the assignment records and corroborating sources.

Inventors

Kevin Wayne Kirkeby — sole named inventor on all 36 claims. Located by patent records at Rochester, Minnesota, which is IBM's Rochester, MN campus (the AS/400 / OS/400 development site referenced throughout the specification).

• Employer at filing (2000-03-23): International Business Machines Corporation. This is confirmed by the assignment itself — the assignor of record is "KIRKEBY, KEVIN WAYNE," with IBM as assignee, on both the initial and follow-up recordings (reels 010702/0353 and 011013/0818). The inventor was therefore an IBM employee assigning to his employer, the classic § 261 employer-assignment pattern.
• Departure pattern: None. Patent Leaderboard and SciSpace both list Kirkeby with 14 granted US patents all assigned to IBM, spanning 2004 through 2024-09-10 (e.g., US 12,086,228 "Login token management," 2024). That is a ~24-year continuous IBM tenure covering the entire life of this patent. There is no "all inventors departed within 12 months of filing" signal — the opposite is true. One caveat: the most recent output (patient-care sensor systems; login-token management) suggests he may have moved into IBM's healthcare business unit (the entity now branded Merative, spun out of IBM Watson Health in 2022). I could not independently confirm his post-2022 employer of record, but the patents remain IBM-assigned on the face of the records.

Original assignee

International Business Machines Corporation (Armonk, NY) — named on the issued patent and the grant-time owner.

• Primary line of business: enterprise IT — mainframes/servers, middleware and software, and services. Directly relevant here: IBM built and sold the platforms the specification itself names — Lotus Notes / Lotus Domino, Fax for Domino, the IBM AS/400 server and OS/400 OS, and the IBM Integrated Netfinity Server expansion card. IBM therefore had genuine commercial products in the network-fax / document-rendering space at filing.
• Did IBM ship a product embodying the claims? Partially determinable. IBM shipped Domino-based fax products and the AS/400 + Netfinity rendering-card hardware described as embodiments. I could not confirm that any shipped IBM product practiced the specific claimed architecture (fax server farms each attachment out to a per-file-type machine via an application table). Treat "product embodying the claims" as unconfirmed.
• Current status: Operating. IBM is a live public company (NYSE: IBM); it has never filed bankruptcy. No dissolution, no acquisition of IBM itself. (IBM did divest assets/units over time, but the whole company remains operating.)

Assignment timeline

Important limitation, stated up front: the Assignment Center exposes a correspondent-of-record field (the attorney/firm who filed the recording), and you asked me to capture it. I was not able to retrieve that field for this patent — my research tools hit a step limit before I could query the Assignment Center record view, and the public aggregators (Google Patents legal events, uspto.report, Justia) do not republish correspondent names. The reels, frames, conveyance types, parties, and dates below are taken from the patent's own legal-events record and corroborating press/SEC-sourced reporting. I am not substituting invented correspondent names. Recommend a direct lookup at https://assignmentcenter.uspto.gov/ (search patent number 6721803) to read the correspondent fields on reels 010702/0353, 011013/0818, 026894/0001, and 044144/0001.

• 2000-03-21 (executed) / recorded 2000-03-23 — Reel 010702/0353

  • Conveyance: Assignment
  • Assignor: Kevin Wayne Kirkeby (individual)
  • Assignee: International Business Machines Corporation (Armonk, NY)
  • Correspondent: not captured (see limitation above).
  • Context: Standard employer/inventor assignment — the original conveyance that vested title in IBM on the filing date.

• 2000-07-17 (executed) / recorded 2000-07-27 — Reel 011013/0818

  • Conveyance: Assignment
  • Assignor: Kevin Wayne Kirkeby
  • Assignee: International Business Machines Corporation
  • Correspondent: not captured.
  • Context: Confirmatory/second-recordation assignment to the same assignee four months later. Two assignments from the same inventor to the same company with no intervening owner almost always means the first recordation was defective (missing/incorrect signature, wrong execution date, or a recordation error) and was re-filed to cure it. No change in beneficial ownership — this is housekeeping, not a transfer.

• 2011-08-17 (executed) / recorded 2011-09-13 — Reel 026894/0001

  • Conveyance: Assignment
  • Assignor: International Business Machines Corporation
  • Assignee: Google Inc. (Mountain View, CA)
  • Correspondent: not captured.
  • Context: Bulk portfolio sale / defensive aggregation. This reel is part of the documented August 2011 IBM→Google transfer of approximately 1,023 patents, executed 2011-08-17 and recorded in the following weeks (first reported by SEO by the Sea; confirmed by Bloomberg, CNET, Wired, AP). Google acquired the batch — across fax, networking, chip fabrication, Java, etc. — explicitly as a defensive arsenal to deter and counter-assert against Android litigation. This is an operating-company-to-operating-company sale, not a transfer to an NPE.

• 2017-10-06 (recorded) — Reel 044144/0001 (reel number inferred from the 2024 corrective assignment's cross-reference; see note)

  • Conveyance: Change of Name
  • Assignor: Google Inc.
  • Assignee: Google LLC
  • Correspondent: not captured.
  • Context: Internal corporate reorganization only — Google Inc. converted to Google LLC (its wholly owned subsidiary take-over in the Alphabet restructuring). No change in beneficial ownership.

• 2024-03-04 (recorded) — Reel 044144/0001 (corrective recordation)

  • Conveyance: Corrective Assignment
  • Assignor: Google Inc.
  • Assignee: Google LLC
  • Correspondent: not captured.
  • Context: Administrative correction, not a transfer. The record expressly corrects "the removal of the incorrectly recorded application numbers 14/149802 and 15/419313 previously recorded" on the name-change record. Purely clerical; ownership unaffected.

• Fee events (non-conveyance, noted for completeness): maintenance-fee payments recorded 2003-12-05 (fee procedure), 2007-09-19 (4-year), 2011-09-23 (8-year). Legal status is recorded as "Expired – Fee Related," with an anticipated expiration of 2020-03-23 (the full 20-year term from filing). I could not determine from available records whether the 11.5-year fee (due ~Nov 2015) was unpaid or whether the term simply ran out in 2020; the "Fee Related" label usually indicates a lapse for non-payment, which would mean the patent died before its nominal term. Flagging as unresolved.

Assignee discrepancy carried over from the prior section: uspto.report still shows "assigned to International Business Machines Corporation." That line reflects the grant-time assignee and is stale. The recorded chain (reel 026894/0001 → change of name) establishes Google LLC as current owner. I prefer the recorded chain.

Timeline diagram

timeline
    title Ownership of US 6721803
    2000 : Inventor assigns to IBM
         : Second IBM assignment recorded
    2011 : IBM sells to Google Inc
    2017 : Name change to Google LLC
    2024 : Corrective assignment recorded

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No licensing-only LLC ever appears. The only post-issuance transfer is IBM → Google Inc. (reel 026894/0001, executed 2011-08-17), an operating company with billions in revenue. No "IP/Holdings/Ventures" suffix, no registered-agent-service address, no single-member LLC.

2. Known asserter in the chain — Not present. Neither assignee (IBM, Google/Alphabet) appears on any public NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Google is a frequent patent defendant, not an asserter of this kind.

3. Repeat correspondent across the chain — Unclear. This is the one signal I could not test, because the correspondent-of-record fields were not retrievable with the tools available. There are only two principals across the whole chain, so even a repeated correspondent would be unremarkable. Do not treat the absence of a finding here as a finding of absence — verify directly on reels 010702/0353, 011013/0818, 026894/0001, 044144/0001.

4. Cascading transfers — Not present. Two transfers over a 16-year interval (2000 and 2011), then a name change and a clerical correction. No chained LLC hops, no <24-month cascade, no shared-correspondent-address cluster.

5. Pre-litigation transfer — Not present. No infringement suit naming US 6,721,803 was found (consistent with the prior section's search, including the Orca Security v. Wiz postal-code false positive). Nothing to be "pre-" to.

6. Bankruptcy fire-sale — Not present. IBM never filed Chapter 7/11. The 2011 sale was a voluntary portfolio monetization by a solvent seller, not a distressed liquidation (contrast Kodak, Nortel, Polaroid).

7. Privateering — Not present, with a nuance. The IBM→Google 2011 batch was a defensive purchase publicly framed as anti-litigation armor for Android. There is a related data point worth distinguishing: Google later transferred some acquired patents to HTC, which asserted them against Apple. However, US 6,721,803 is not among the patents I can tie to any such downstream assertion, and no evidence links this patent to privateering. Nuance does not rise to a finding.

8. Defensive aggregator — Not present in the literal sense; functionally similar. The chain terminates at Google LLC, which is an operating company, not RPX / AST / LOT / Unified / OIN. But the 2011 acquisition was defensive in purpose, and the patent has never been asserted — so the practical outcome (neutralized, non-asserting) resembles a defensive-hold, even though the entity type does not match this category's definition.

Verdict

Defensive / non-asserting.

The recorded chain is short and clean: inventor → IBM (reel 010702/0353, 2000-03-23; confirmatory reel 011013/0818, 2000-07-27), then IBM → Google Inc. (reel 026894/0001, executed 2011-08-17, part of the documented ~1,023-patent August 2011 defensive stockpile), then a Google Inc. → Google LLC change of name and a 2024 clerical correction. There is no shell entity, no known asserter, no cascading LLC chain, no bankruptcy, and no litigation naming this patent — the patent sits in a defensive operating-company portfolio and has never been asserted. I note one honest caveat: this option's literal definition contemplates termination at a defensive aggregator (RPX/AST/LOT/Unified/OIN), and the terminal owner here is Google LLC, an operating company; I select this verdict because the functional outcome — defensively acquired and never asserted — matches, and no other option fits given that Google neither practices these specific claims in a shipped product nor sues competitors over them. The correspondent-of-record check on reels 010702/0353, 011013/0818, 026894/0001, and 044144/0001 remains the one open item and should be run directly at the Assignment Center.

Verification link: https://assignmentcenter.uspto.gov/ (search patent 6721803; legacy interface at https://assignment.uspto.gov/patent/index.html returns the same records).

I'll research the prior art references for US 6,721,803, starting with the patent citation list and then examining each reference.

Now let me research the other four cited references.

Prior-Art Analysis — US 6,721,803 B1

Building on the bibliographic and claim sections already produced, this section addresses the specific request: the references cited on the face of US 6,721,803 and their anticipation potential under 35 U.S.C. § 102.

1. The citation set (what is actually "cited for" this patent)

The granted patent lists five U.S. patent references as cited prior art (there are no foreign patent citations). Under the "Patent Citations" heading on the Google Patents record, all five are marked as "cited by examiner":

There are also two non-patent citations — the inventor's own same-day sibling applications, Ser. No. 09/533,147 and Ser. No. 09/533,520. Because 09/533,520 is this application, and 09/533,147 was co-filed the same day (2000-03-23) by the same inventor, neither is prior art; they are listed only as related/cross-referenced material. I flag this because a reader might otherwise mistake the "Non-Patent Citations" block for § 102 art.

2. Reference-by-reference analysis

Reference 1 — US 4,902,881 A

• Full citation: Parallel process communications terminal and network, US 4,902,881, Faxplus Corporation, filed June 10, 1988, issued Feb. 20, 1990.
• Description: A public, credit-card-authenticated communications terminal built on an IBM AT-class host with a second, dedicated facsimile co-processor on a shared bus, plus a voice module and dual telephone lines. Document services include facsimile, copying, electronic mail, and document storage; a network of such terminals connects to hubs. The invention is essentially a parallel-processing standalone terminal — two processors, one for general control and one dedicated to real-time fax compression/decompression.
• § 102 posture: This is a patent that issued more than one year before the 2000-03-23 filing date, so it is § 102(b) art as of its 1990-02-20 issue date (and § 102(a) as of 1988). Pre-AIA § 102 applies throughout, since the application was filed in 2000.
• Anticipation potential for 6721803's claims: None. It is directed to a single multi-processor terminal, not to a fax-management server that parcels attachments across heterogeneous networked computers via a file-type-to-network-address table. It does not disclose (i) an application map associating file type → network address → application, (ii) transmitting an attachment to a remote computer selected by that lookup, or (iii) converting an attachment (as opposed to scanning a document) into a fax image. It fails every independent claim (1, 12, 13, 24, 25, 36) and therefore cannot anticipate the dependent claims that incorporate them. Its realistic role is § 103 background — evidence that networked fax systems with dedicated fax processing hardware were known.

Reference 2 — US 6,417,933 B1 ⚠️ most substantively relevant of the five

• Full citation: Teleconferencing and facsimile communications system and method, US 6,417,933 B1, Edward Stanley Szurkowski, assignor to Lucent Technologies Inc., Appl. No. 08/773,996, filed Dec. 26, 1996, issued July 9, 2002 (58 claims; U.S. Cl. 358/442).
• Description: A teleconferencing server (administrative processor, voice bridge, email processor, on-line/paging processors, and a facsimile bridge) that coordinates facsimile distribution to conference attendees. Critically, the email processor "separat[es] attached files from incoming email messages, feed[s] these files to such a software application as to convert their contents into facsimile images," and the facsimile bridge distributes the resulting fax data.
• § 102 posture: Issued after the 2000-03-23 filing date, so it is not § 102(a)/(b) as a printed patent. It is available as § 102(e) prior art as of its 1996-12-26 filing date (a U.S. patent granted on an application filed before 6721803's filing, by another).
• Anticipation potential: This reference teaches two elements of the independent claims — detaching email attachments and converting them to facsimile images using an application. That maps onto the "convert the attachment file to at least one image in a file format" step (element (iii) of claim 1 / 12) and onto claim 9 (message content/cover page converted to images and sent with attachments). However, it does not disclose the distinguishing limitation — a table associating a file type with a network address of a computer that hosts the rendering application, with entries spanning different operating systems and different application programs, and the consequent routing of each attachment to a remote rendering machine. Lucent '933 renders attachments inside the teleconferencing server, i.e., the opposite architecture. It cannot anticipate any independent claim; it is best characterized as a § 103 reference against the attachment-conversion elements.

Reference 3 — US 6,421,707 B1

• Full citation: Wireless multi-media messaging communications method and apparatus, US 6,421,707 B1, Miller et al., assignor to Lucent Technologies Inc., filed Feb. 13, 1998, issued July 16, 2002.
• Description: A wireless data server complex that receives messages through a universal input subsystem (email, voicemail, fax, SMS, intranet) and delivers them in a subscriber-preferred format. A converter bank subsystem converts an input into the appropriate delivery format — the specification expressly covers text-to-speech and text-to-fax conversion and includes a "service scenario of e-mail attachment conversion" (FIG. 9).
• § 102 posture: Issued after the filing date; available as § 102(e) art as of its 1998-02-13 filing date.
• Anticipation potential: It discloses format conversion of message attachments for delivery and even selecting a converter appropriate to a target format/recipient profile (a profile-based dispatcher). That is conceptually adjacent to the "determine which converter can render this file type" idea. But the converter selection is driven by a subscriber delivery-format profile, not by a file-type → network-address-of-a-computer table spanning heterogeneous machines, and conversion happens within the service complex. No independent claim is anticipated. Most relevant to element (iii) of claims 1/12/25/36 and to claim 9.

Reference 4 — US 6,405,244 B1

• Full citation: Communication apparatus for receiving downloaded program data and data download method, US 6,405,244 B1, assignor to Matsushita Graphic Communication Systems, Inc., filed Mar. 9, 1999 (patent lists priority to 1998-07-09; the Google Patents family shows it as a division of Ser. No. 09/264,821), issued June 11, 2002.
• Description: A communication apparatus that receives downloaded program data and rewrites/updates its own program (firmware) via download, plus an associated data-download method.
• § 102 posture: Issued after the filing date; § 102(e) art as of its 1999-03-09 filing date (with a 1998-07-09 priority).
• Anticipation potential: None, and little § 103 relevance. This reference concerns remote program downloading to a communication device — it does not address fax-job management, attachment rendering, an application map, or transmission to a recipient contact address. Its likely citation purpose was generic (a networked communication apparatus receiving program data), possibly to show that network devices obtaining/executing application programs was known. It does not touch the novelty of any claim.

Reference 5 — US 6,411,685 B1

• Full citation: System and method for providing unified messaging to a user with a thin web browser, US 6,411,685 B1, assignor to Microsoft Corporation, filed Jan. 29, 1999, issued June 25, 2002.
• Description: A unified-messaging system that aggregates multiple message types (including fax and email) and presents them to a user through a thin web browser client, performing server-side formatting/conversion so the thin client need not render natively.
• § 102 posture: Issued after the filing date; § 102(e) art as of its 1999-01-29 filing date.
• Anticipation potential: It supports the general concept of server-side conversion of messages/attachments for delivery to a device that cannot render them natively — a thematic cousin of offloading rendering from the client. But it does not disclose distributing rendering across multiple different computers selected by file type, nor a communication port for facsimile transmission under a fax-management job model. No independent claim is anticipated. At most a § 103 reference for the "conversion performed by a machine other than the originator" idea.

3. Bottom-line § 102 assessment

No cited reference anticipates any claim of US 6,721,803. The reason is structural and worth stating precisely, because it reinforces the earlier caveat that the "different operating systems and different application programs" language looks like a prosecution-driven narrowing:

• Every independent claim (1, 12, 13, 24, 25, 36) requires a table whose entries associate a file type with a network address of a computer that hosts the rendering application, and expressly requires that this table "includes entries of computers that have different operating systems and different application programs" (claims 1/13/25) or a default entry fallback (claims 12/24/36).
• None of the five references discloses a distributed, multi-machine, file-type-directed rendering architecture. Lucent '933 and Lucent '707 convert attachments within a single server/converter subsystem; Faxplus '881 is a single multi-processor terminal; Matsushita '244 and Microsoft '685 are unrelated to attachment-routing.
• Because dependent claims incorporate their independent claims, no dependent claim is anticipated either — even where a reference (Lucent '933 for claim 9; Lucent '707 for the converter-selection aspect) overlaps an individual element.

Most useful as § 103 obviousness art: Lucent '933 (US 6,417,933) and Lucent '707 (US 6,421,707) are the two references an examiner would most likely combine with a network-messaging/print-server-style routing reference to attack the independent claims; Faxplus '881 supplies the networked-fax-system backdrop.

4. Two scoping notes

1. "Cited By" is not prior art. The ~26 later documents on the record (e.g., US 6,965,947 IBM "automated transcoder selection"; the Citrix distributed-program-execution family US 6,952,714 / US 7,330,872 / US 7,117,243) all post-date 6721803's 2000-03-23 filing. They are forward citations — useful for understanding the technology's later trajectory, but they cannot be § 102 art against this patent and should not be presented as such.

2. Two non-patent citations are self-citations, not art (same inventor, same filing day).

5. Caveats / limits on this analysis

• I derived the reference list from the granted patent's front page as reproduced via Google Patents and the Official Gazette entry. I did not re-verify each cited reference's claim text against the 6721803 claims element-by-element from the original PDFs for every reference; the "no anticipation" conclusion rests on the bibliographic/abstract-level descriptions above plus the definitive structural requirement of the application-map limitation. A formal § 102 chart would require full-text comparison of each reference's specification.
• For US 6,405,244 and US 6,411,685 I could not retrieve inventor names in this session; I have not fabricated them. Their assignees, filing dates, and issue dates as listed are from the record.
• Dates for issuance of the two Lucent references (2002) mean they function as § 102(e) art as of their filing dates only (1996-12-26 and 1998-02-13) — a common trap when reading a pre-AIA case, and worth stressing.

Sources: https://patents.google.com/patent/US6721803/en (citation block) · https://patents.google.com/patent/US4902881 · https://patents.google.com/patent/US6417933 · https://www.freepatentsonline.com/[6417933](/patent/6417933).html · https://patents.google.com/patent/[US6421707B1](/patent/US6421707B1) · https://patents.google.com/patent/US6405244 (and family US20020099782) · US 6,411,685 identified via the 6721803 citation list.

I'll research the five prior-art references cited on the face of US 6,721,803 to ground the obviousness analysis in their actual disclosures.

Obviousness Analysis — U.S. Patent 6,721,803 (35 U.S.C. § 103)

Building on the prior "Prior art cited and family context" section. This section does not restate the bibliographic, claim-summary, or litigation material already generated; it uses the five face-cited references as the starting art base and adds what I could retrieve of their actual disclosures.

1. Legal framework and the notional POSITA

Which § 103 applies. The application (09/533,520) was filed March 23, 2000 — before the March 16, 2013 AIA date. The '803 patent is therefore governed by pre-AIA 35 U.S.C. § 103(a), and the analysis follows Graham v. John Deere Co., 383 U.S. 1 (1966) (scope/content of prior art; differences; level of ordinary skill; secondary considerations), with the motivation-to-combine question informed by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (predictable combinations, "design incentives," "known techniques"), 35 U.S.C. § 103(a) and MPEP §§ 2141–2144.

Prior-art status of the cited references. Four of the five cite-ons issued in 2002 — after the '803 date — but each was filed before 2000-03-23, so each qualifies as prior art under pre-AIA § 102(e) as of its filing date:

Level of ordinary skill. A POSITA at the March-2000 date would be a software/network engineer with ~2–4 years of experience in client–server messaging, network fax (store-and-forward), document-format conversion (word-processor/spreadsheet/graphics → raster image), and OS-level "file-type → application" association (e.g., the Windows shell self-launch behavior). Distributed processing, load distribution, and server offload were ordinary design vocabulary by 2000.

Also in the record as prior-art admissions: the "Description of the Related Art" section of the '803 specification itself admits (i) a dedicated server-class fax server ("IBM AS/400") that receives/renders/transmits fax jobs, and (ii) a "Windows NT server as a dedicated fax server" performing both rendering and transmission, and states as a known problem that "such fax servers would be limited to rendering fax documents created in server based applications." These admissions supply both the starting architecture and the motivation for the improvement.

2. What the cited references actually teach (scope & content)

I retrieved the definitional passages/claims for four of the five. One I could not retrieve in full — flagged.

US 6,417,933 (Szurkowski, Lucent) — "Teleconferencing and facsimile communications system and method."
The most on-point reference for the core conversion step. A teleconferencing/fax server has an e-mail processor that:

"is further capable of separating attached files from incoming email messages, feeding these files to such a software application as to convert their contents into facsimile images…"
and that parses messages and generates status messages back to the originator.
This teaches email → application → fax-image conversion of attachments and central job/status handling.
Source: https://patents.google.com/patent/US6417933

US 6,421,707 (Miller et al., Lucent) — "Wireless multi-media messaging communications method and apparatus."
Teaches an architecture with a "converter bank subsystem 180 [that] converts an input into an appropriate delivery format prior to its delivery," with enumerated converters including text-to-speech and text-to-fax, selected based on a stored subscriber profile/input-format, and an explicit figure for "e-mail attachment conversion" (FIG. 9).
This teaches format-to-converter selection and multiple co-existing converters — the conceptual ancestor of a file-type→converter/application map.
Source: https://patents.google.com/patent/US6421707

US 6,411,685 (O'Neal, Microsoft) — "System and method for providing unified messaging to a user with a thin web browser."
Claim 1 recites a server node with "a conversion engine to convert a first message received on a first medium to a second message forwardable on a second medium," the conversion engine comprising text-to-speech, text-to-TIFF, and TIFF-to-GIF applications; the telephony system "is responsible for incoming and outgoing calls for both voicemail and fax mail."
This teaches a server-side conversion engine that produces TIFF (the '803 file format) and unifies fax/e-mail/voicemail media.
Source: https://patents.google.com/patent/US6411685 (OG text: https://webapp1.dlib.indiana.edu/virtual_disk_library/index.cgi/[5628977](/patent/5628977)/FID2/og/html/1259-4/us06411685-20020625.html)

US 4,902,881 (Janku, Faxplus) — "Parallel process communications terminal and network."
Teaches a multi-processor terminal where one processor is the controller and "the other processor is dedicated to high speed implementation of standard facsimile functions," expressly because the host processor "would not be able to accomplish the same results in the same time." It also describes a network of terminals and interconnected hubs.
This teaches off-loading fax rendering/compression work away from the general-purpose controller — the functional motivation for distributing rendering, and a network-of-nodes architecture.
Source: https://patents.google.com/patent/US4902881

US 6,405,244 (Matsushita) — "Communication apparatus for receiving downloaded program data and data download method."
I could not retrieve a clean abstract or claim text for this reference in this session; only a family/division listing (US 09/264,821 → US 6,405,244) and sitemap entries. Based on title and assignment I characterize it tentatively as teaching a communication apparatus that receives/downloads program data and uses that program — i.e., program/configurability of a network device. Flag: characterization unverified; do not rely on it as a primary reference without pulling the full text.
Source (family listing only): https://patents.google.com/patent/US20020099782

What is NOT in the cited-art base: none of the retrieved references expressly discloses selecting among a plurality of physically distinct networked computers, indexed by a table of file-type→network-address, where the computers run different operating systems and different applications, and dispatching each attachment to the matching machine. That is the feature that appears added during prosecution (see § 6).

3. Mapping claim limitations to the art

4. Proposed § 103 combinations and the motivation to combine

Ground A — Base claims 1 / 13 / 25: '933 + '707 (optionally + '881)

Combination: '933 (email-attachment → application → facsimile image conversion, with central fax transmission and status handling) in view of '707 (a converter bank that selects an appropriate converter — text-to-fax among them — for a given input/attachment based on stored mapping).

Motivation / why obvious (KSR):

• Both references are in the same field (network fax / unified messaging) and address the same problem — getting heterogeneous incoming message content (including attachments) into a transmittable fax/image format.
• '933 already teaches the exact conversion mechanism claimed (feed an attached file to a software application to produce a facsimile image). '707 already teaches selection among multiple converters keyed to the content/format, including an explicit "e-mail attachment conversion" scenario. A POSITA seeking to generalize '933's single "software application" to handle the many attachment types users actually send would naturally adopt '707's format-indexed converter selection. The result — "pick the converter/application that matches the file type, then convert" — is a predictable, mundane improvement of the kind KSR holds obvious.

Gap: neither reference locates the converters on separate networked machines with different OSes. To reach claim 1's heterogeneity limitation, add '881 or, more simply, ordinary knowledge.

Ground B — Base claims 1 / 13 / 25: '933 + '707 + '881

Combination: Ground A plus '881.

Motivation: '881 supplies the architecture and incentive for performing fax-rendering/compression work away from the controlling processor ("the other processor is dedicated to high speed implementation of standard facsimile functions"), expressly because the general-purpose host "would not be able to accomplish the same results in the same time." The '803 specification's own background confirms the real-world pressure — a single server performing both rendering and transmission "requires significant processor resources," and "many of these Windows NT machines must be provided." Thus a POSITA had:

1. a reason to move rendering off the managing server (busy-server/throughput, per '881 and the '803 background admission), and
2. a known technique for doing so — distribute the work to other machines,
   and the only remaining design choice is which machine: the one that has the application for that file type. Indexing that choice by file type in a table is the network analogue of the well-known local file-type/application association (and of '707's converter selection / typical routing tables). Distribution across heterogeneous machines is the inherent, expected consequence of "use whatever networked machine has the right application" in a mixed-OS enterprise network — not an unexpected result.

This is the strongest available ground, and the motivation evidence is unusually clean because the '803's own specification concedes the server-load problem and the single-OS limitation that the claim's heterogeneity language is designed to overcome.

Ground C — Base claims 1 / 13 / 25: '685 + '933 and/or '707

Combination: '685 (server conversion engine producing TIFF, unifying fax/e-mail/voicemail media) with '933/'707 (attachment-to-fax-image conversion and format-indexed converter selection).

Motivation: '685 teaches converting one medium's message into another medium's format and expressly includes text-to-TIFF — i.e., the '803's chosen common fax format ("an image in a file format"). Combining '685's TIFF-producing conversion engine with '933's attachment feeding yields the conversion of attachments to TIFF images that the '803 claims. The incentives are the same (unified messaging, deliver to the fax network) and the references are combinable with predictable results. '685 is especially useful against independent claim 12 and dependent claim 9/21/33 (message content and cover page rendered to images), since it teaches converting message content — not just attachments — into TIFF.

Ground D — Claims 12 / 24 / 36 (the default-entry variants)

Claims 12, 24, and 36 are broader/differently limited than claims 1/13/25: they omit the "different operating systems and different application programs" requirement and instead require a table with a default entry used when the file type is unmatched.

Combination/motivation: A default/fallback mapping is a classic, well-known design choice — default routes in network routing, a "wildcard" or catch-all entry, and '707's profile-driven default handling all supply it. The '803 specification itself explains the design rationale ("This avoids the need to define all possible file extension types"), which a POSITA would have found obvious independent of any reference. This limitation is the weakest link in the claim set and the most vulnerable to a § 103 challenge even over '707 or '685 alone in combination with routine engineering judgment. (The retained network-address aspect is satisfied by the same "machine that has the application" reasoning as Grounds A–C.)

Dependents (mirrored across method/system/medium families)

Under KSR, these are "predictable variations" and "known techniques" for the disclosed purpose; none appears to produce an unexpected result.

5. Why a POSITA would combine — the through-line

Three factual pillars make the combinations non-hindsight:

1. Same problem, same field. All five references sit in network fax / unified messaging / document conversion. '933 and '707 both convert message attachments for fax delivery; '685 unifies fax/e-mail/voicemail and produces TIFF; '881 offloads fax processing; '244 concerns program-bearing communication apparatus.
2. Admitted motivation in the '803 itself. The patent's background concedes (a) fax rendering is "very processor intensive," (b) a single dedicated server is a bottleneck requiring many machines, and (c) server-based rendering is limited to server-based applications. These are precisely the problems the claimed distributed, heterogeneous-machine selection solves — so the incentive is documented in the patent, not manufactured by the analyst.
3. Known solution techniques. Off-loading work to another machine ('881), selecting a converter by input/format ('707), converting messages to TIFF ('685), and mapping a file type to the application that opens it (ubiquitous OS behavior) were each ordinary. Combining them yields the claimed subject matter with predictable results.

6. Weaknesses / where a rejection is likely to be contested

• The heterogeneity limitation is the fulcrum. Claims 1, 13, and 25 require the table to contain "entries of computers that have different operating systems and different application programs." No retrieved reference expressly discloses this. A rejection on Grounds A–C would rest on reasoning ("the natural way to render many attachment types is to use whatever networked machine has the matching application, which in a mixed-OS enterprise will necessarily differ in OS and application") plus the '803's own admissions. That reasoning is defensible but is the point of attack.
• '881 is a specialized 1988 credit-card terminal, argued in a different (analog/Group III) context; an applicant could contend it is non-analogous as to networked server-based rendering, though it remains analogous art for offloading fax processing.
• Possible teaching away. '881's premise is to dedicate a processor within the terminal to fax functions — arguably toward co-location, not distribution. This cuts against Ground B and should be met with the general offload/routing reasoning.
• '933 may be read as server-local conversion ("feeding these files to such a software application"), so it supports the conversion step but not the distribution step; the distribution must come from '881 or knowledge.
• Antedating. Because the § 102(e) references predate the '803 filing by 1–4 years, swearing behind (Rule 131) is impractical; this is a favorable posture for a challenger.
• Full-text verification gap. I could not retrieve the complete disclosure of US 6,405,244 and retrieved only claim 1/12 of US 4,902,881; the '707 and '685 characterizations rest on definitions/claims rather than full specs. Any formal invalidity contention should confirm pin cites in the full texts.

7. Secondary considerations (objective indicia)

No objective indicia of non-obviousness are evidenced in the material available to me: no litigation asserting the '803 patent was found (the only "6721803" docket hit is a postal-code false positive, per the earlier section); the patent expired 2020-03-23; and it is held by Google LLC by assignment (an operating company, not an assertion vehicle). There is no record of commercial success, long-felt need, failure of others, or copied design that would rebut the § 103 case. Under Graham, this leaves the analysis on the prior-art/level-of-skill side, where the combination reasoning above is strong.

8. Double-patenting note (not § 103, but adjacent)

Per the earlier section, the two same-day sibling applications by the same inventor (Ser. Nos. 09/533,147 and 09/533,498 — apparently issued as US 6,914,693 and US 6,892,239) are not prior art to the '803 under pre-AIA § 102 ("by another"), but their overlapping disclosure raises a potential obviousness-type double patenting (ODP) concern if their claims are not patentably distinct. That is a separate rejection basis and should be checked against the sibling claims; it is flagged here only because it is a common companion to a § 103 attack on this family.

9. Bottom line

• The strongest § 103 grounds are '933 + '707 and, for the distribution/heterogeneity limitation, '933 + '707 + '881; '685 supplements the TIFF-conversion and message/cover-page limitations; '244 is a possible secondary reference pending full-text verification.
• Independent claims 1, 13, and 25 are the most defensible for the patentee because of the "different operating systems and different application programs" limitation, which is not expressly taught and must be supplied by reasoning plus the patent's own admissions.
• Independent claims 12, 24, and 36 (the default-entry variants, which omit the heterogeneity requirement) and most dependent claims read squarely onto the art combination plus routine engineering and are the most vulnerable.
• No secondary considerations are available to rebut; the motivation evidence is unusually strong because the '803 specification itself recites the very problems (server load; server-only application support) the cited-art combination solves.

Confidence: Moderate-to-high on the reference characterizations I retrieved ('933, '707, '685, '881); low/unverified on '244. The overall conclusion is a prima facie § 103 case that is strong on the conversion/selection/transmission limitations and rests on reasoned combination for the heterogeneous-network-address limitation.

Sources: https://patents.google.com/patent/US6417933 · https://patents.google.com/patent/US6421707 · https://patents.google.com/patent/US6411685 · https://patents.google.com/patent/US4902881 · https://patents.google.com/patent/US20020099782 (US 6,405,244 family) · https://patents.google.com/patent/US6721803/en (authoritative text)