US 6952831

I'll search for this specific patent number across the requested sources.

Now let me check for any CAFC 2026 docket activity involving this patent number.

US Patent 6,952,831 — Summary

Sources searched: Google Patents full text (authoritative, fetched 2026-09-24), FreePatentsOnline, Justia Patents, EPO Global Patent Index, and general CAFC 2026 docket searches. Caveat: I was unable to directly query USPTO PatentCenter or the CAFC docket system; the below is grounded in the patent text and secondary sources. See "Uncertainty" at the end.

---

Bibliographic Data

---

Abstract

"A method of creating a peripheral driver for a particular peripheral by learning the peripheral options and the commands for those options from the peripheral itself. The computer accesses a specified location in the memory of the peripheral which contains either a generic peripheral description file or a pointer to such a file. The file is a text-based file, which contains the peripheral options as name-value entries. The computer parses the file and learns of the available options and the appropriate commands to use those options. The computer is thus able to create a driver for the peripheral."

---

Plain-Language Overview of the Independent Claims

Claim 1 — System. A computer system for controlling a peripheral in which the "peripheral driver" is split into two physically separate pieces: (a) a universal peripheral driver component resident on the computing device, and (b) a text-based generic peripheral description file component. The peripheral has memory storage and talks to the computer over a network protocol. The description file holds a text-based characterization of the peripheral — including an implementation of the device-specific driver functions — and is found using at least one pre-defined object identifier (OID) value, read by the computer by referencing the peripheral's memory storage via the network protocol. The universal driver then incorporates that characterization and implements the device-specific functions to actually control the peripheral.

Claim 8 — Computer-readable medium. At least one CRM storing the universal peripheral driver component half of the driver (again, physically separate from the description-file half). The universal component implements device-specific functions to control a peripheral according to a text-based characterization it obtains from the description file; the description file is reached by querying the peripheral, over a network protocol, for at least one pre-defined OID value.

Claim 15 — Method. A method of controlling a peripheral by a computer where the driver is again split into the universal component and the physically separate text-based description file. Steps: (1) the universal component accesses the description file (the component sits on the computer; the file is accessed per a network protocol and by reference to a pre-defined location of memory storage of the peripheral); (2) it reads the device-specific driver functions from the text-based characterization; and (3) it implements those functions to control the peripheral per the characterization.

Common inventive thread across all three independents: the driver is split into a generic universal component plus a physically separate text-based device description, and the description is discovered from the device itself via a pre-defined object identifier resolved over a network protocol — rather than being pre-installed or manually selected by the user.

Dependent claims add: description file stored in peripheral memory (2) or on remote storage pointed to by a pointer in peripheral memory (3); SNMP as the network protocol (4/9/16); GET request for the OID (5/10/17); peripheral is a printer (6/13/20) or scanner (7/14/21); OID locates either the file's memory area (11/18) or a pointer to second storage (12/19).

---

Notes on Identifiers (not auto-corrected)

• The specification and claims repeatedly state the protocol as "Simple Network Mail Protocol (SNMP)." This is the literal text of the patent. The term-of-art reading would be "Simple Network Management Protocol," but per the strict rule I am not correcting it — the patent as issued says "Mail."
• The specification also contains internal inconsistencies, e.g., "printer bank 96" in one passage vs. "printer bank 114" elsewhere; and "Universal Font File (UFF)" vs. "(UTF)" in the text. These are reproduced as-is.
• Cited prior art (8 references) includes US 5,604,843 (Shaw et al., Microsoft) and US 6,426,798 (Yeung, Canon); non-patent citation: The Unicode Standard Version 2.0 (1997).

---

Uncertainty / Limits of This Search

1. No CAFC 2026 docket activity found for 6952831. Searches for the number in a Federal Circuit context returned no matching appeal, and a 2026 CAFC PTAB-appeal statistics digest (Finnegan, July 2026) contained no reference to it. Given the patent lapsed in 2013 for non-payment of maintenance fees, active 2026 appellate litigation is improbable — but I cannot positively confirm a null result without live PACER/CAFC docket access, which I do not have.
2. My search also surfaced a wholly unrelated hit for the bare token "6952831" (a Lithuanian registry notice number). It is not the patent and was disregarded.
3. Assignee data reflects Google Patents' recorded reassignment to Microsoft Technology Licensing, LLC; I did not independently verify current chain of title in USPTO assignment records.

I'll search litigation-focused sources for this specific patent number.

Let me run more targeted searches, including the patent's title and assignee in a litigation context.

Let me try litigation-specific databases and the continuation patent in the family.

Litigation Search — US Patent 6,952,831 ("Driverless printing")

Bottom line

No litigation is known involving US Patent 6,952,831. After multiple targeted searches, I found no district court case, ITC investigation, or CAFC appeal in which 6,952,831 (or its family member 7,421,712) is identified as an asserted or challenged patent.

---

What I searched

Note on the bare token "6952831": unrelated records appeared — e.g., an Indian trademark/registry application number (dated 11/04/2025) and a Lithuanian-registry-style notice. These are not the patent and were disregarded per the strict rule (do not treat similar/identical strings as the patent unless genuinely tied to it).

---

Why the null result is plausible (contextual corroboration)

1. Status: The patent expired 2013-10-04 for failure to pay maintenance fees (37 CFR 1.362; Google Patents legal events show LAPS 2013-10-04, STCH 2013-11-04, FP 2013-11-26). An expired patent cannot be asserted for ongoing infringement; only past damages within the 6-year lookback (35 U.S.C. § 286) would remain theoretically available. This materially reduces litigation likelihood after 2013.
2. Owner: Original assignee Microsoft Corp.; current recorded assignee Microsoft Technology Licensing, LLC (reassignment effective 2014-10-14, recorded 2015-01-15). Microsoft is typically a defendant in patent suits, not an asserting plaintiff for a lapsed 1999 printer-driver patent.
3. Family: The continuation US 7,421,712 B2 (filed 2005-05-27, published US 2005/0223390 A1) is the only sibling. I found no litigation on it either, and it likewise shows as "Expired – Fee Related."

(This is consistent with the previously generated summary section, which found no CAFC 2026 docket activity. No contradiction to flag — the earlier "cannot positively confirm a null result" caveat still applies.)

---

Limitations / uncertainty (stated explicitly)

• I could not directly query the primary litigation databases — the Unified Patents portal (portal.unifiedpatents.com/litigation/caselist), PACER, the CAFC docket, RPX Insight, or Docket Navigator. These require authenticated/interactive access or return only via search indexing, and my tool returned general web-search results rather than portal records. My null result is therefore based on web-index search coverage, not an exhaustive docket-level query.
• A defensive challenge is theoretically possible even for a lapsed patent (e.g., a declaratory-judgment action or an IPR filed during the patent's enforceability window, 1999–2013). I found none, but I cannot rule out a filing from the 1999–2013 period that is not well-indexed on the open web.
• Because the patent is expired, there is no active 2026 litigation probability of significance.

---

Requested table (all fields)

If you need a definitive, docket-level confirmation, the next step would be a manual Docket Navigator / Lex Machina / PACER party-and-patent search on the literal number 6,952,831 and on both family members (09/258,623; 11/139,332) — a tool I do not have direct access to here. I will not report a case that I cannot ground in an identifiable source.

PTAB / AIA Trial Proceedings — US Patent 6,952,831 ("Driverless printing")

Proceedings overview

Total AIA trial proceedings on US 6,952,831: none (0). The canonical structured block supplied with this task — sourced from the USPTO Open Data Portal — states the ODP API returns no AIA trial proceedings for this patent as of the most recent ingest, and targeted web searches (PTAB Center / PTABIS document hits, Docket Alarm PTAB case pages, Google Patents' prosecution-and-litigation tabs, and PTAB-focused blogs) surfaced no IPR, PGR, or CBM petition, institution decision, Final Written Decision, or appeal naming this patent. Bottom-line defensive posture: there is no IPR/FWD to point a defendant to, but none is needed — the patent lapsed for non-payment of maintenance fees effective 2013-10-04 and its 20-year term would in any event have run to 2019-02-26. A demand letter citing this patent in 2026 is asserting an expired patent, not a PTAB-hardened one.

No claim-level outcome table can be provided because no decision exists to quote. I will not manufacture proceeding numbers, panels, or dispositions.

---

Proceeding-by-proceeding detail

No proceedings to enumerate. There are no claims-invalidated proceedings to place at the top of the list, because there are no proceedings at all. For completeness, the categories the task asks me to break out resolve as follows:

---

Strategic summary

Which claims are canceled vs. sustained vs. untested. All 21 claims — independent claims 1 (system), 8 (computer-readable medium), and 15 (method), plus dependents 2–7, 9–14, and 16–21 — are untested before the PTAB. There is no IPR certificate cancelling a single claim, and no FWD holding any claim unpatentable. The only claim-status "change" on the record is not a PTAB artifact at all: the patent lapsed on 2013-10-04 for failure to pay maintenance fees under 37 CFR 1.362 (recorded 2013-11-04 / 2013-11-26), producing the Google Patents status "Expired – Fee Related." Separately, the anticipated expiration date of the 20-year term from the 1999-02-26 filing date is 2019-02-26. Either date disposes of an infringement theory more cleanly than any IPR.

Estoppel landscape. Section 315(e)(2) estoppel is not in play — estoppel attaches only to a petitioner whose IPR reached a final written decision, and no petition was ever filed. Practically, this cuts in the defendant's favor in the opposite direction from the usual analysis: there is no petitioner-side estoppel and no petitioner, meaning the entire prior-art space remains available to a defendant in litigation. A defendant would not need to reach prior art: the § 315(e) question is academic when the asserted patent has expired. If a plaintiff nonetheless pleaded infringement of the expired claims, the dispositive argument is the maintenance-fee lapse and the term expiry, not invalidity. (Nothing here should be read as an IPR estoppel shield from a non-existent proceeding.)

Pattern signals. No repeat petitioner, no serial/General-Plastic petition pattern, no defensive aggregator. Searches for "Unified Patents" in connection with either this patent or its continuation returned nothing. This is consistent with the patent's profile: it was never a high-value assertion vehicle. The strongest signal in the record is the opposite of troll activity — US 6,952,831 and its family member US 7,421,712 B2 (continuation filed 2005-05-27, published as US 2005/0223390 A1) function mainly as prior art against others' later applications, not as assertions against defendants. For example, the EPO search report for EP 2 083 351 A1 (Ricoh, "On-demand print driver") cites US 6 952 831 B1 (Moore), 2005-10-04 as an X-category reference against claims 1–6 and 8–13, and Google Patents records roughly 55 third-party forward citations (94 counting the full cited-by family), including US 2003/0184782 A1 (Perkins, "Printer driver configured to dynamically receive printer self-description"). The patent owner (Microsoft, then Microsoft Technology Licensing, LLC per the 2015-01-15 reassignment effective 2014-10-14) never pursued PTAB appeals on it, which would have been impossible — there was nothing to appeal.

One structural observation worth flagging for timing: the AIA trial regime opened 2012-09-16, so the only window in which a CBM or IPR could realistically have been aimed at a live, assertable version of this patent is roughly 2012-09-16 through the 2013-10-04 lapse (about 13 months). The absence of any petition in that window is unsurprising given the patent's age and the pendency of its own continuation.

---

Recommended next steps

• The patent has no PTAB disposition to link. There is no FWD to quote, so do not build a defense narrative around one. The controlling facts are the lapse and the term expiry: Google Patents records "Expired – Fee Related," lapse effective 2013-10-04 (37 CFR 1.362), and an anticipated expiration of 2019-02-26 (US 6,952,831 on Google Patents).
• Verify the null result independently if the stakes justify it. My conclusion rests on the ODP-derived structured block plus web search; I could not directly query PTAB Center / PTABIS or the PTAB E2E docket system. To close that gap, run the patent number through the PTAB Center public search and USPTO Patent Center, and check CourtListener for "6952831" for any Federal Circuit or district-court activity. Note that the ODP ingest lag means a very recent filing might not appear in the structured block — but given the 2013 lapse, a newly filed petition against this patent is implausible.
• Check the continuation, not just the parent. Family member US 7,421,712 B2 (continuation of the same '623 application, same 1999-02-26 priority date) shares the same expiry horizon and is likewise the subject of no PTAB activity I could locate. If a demand letter on "driverless printing" technology arrives, confirm which of the two (or which later, unrelated patents such as Ricoh's US 9,189,192) is actually being asserted — the October 2005 publication date and Moore inventorship are the identifying markers of the Microsoft family.
• If a plaintiff pleads infringement anyway, the threshold challenge is not § 102/§ 103 but whether the asserted claims can support a live cause of action at all given the 2013-10-04 lapse and the 2019-02-26 term end. Revived rights after a fee lapse are governed by 37 CFR 1.378 (unintentional delay) and are narrow; assume the burden is on the patent holder to establish any enforceable right. That is a stronger and cheaper disposition than an IPR would have been.
• If you are a defendant sizing up prior-art defenses for other purposes (e.g., a later patent in the same technology space), note that this patent itself is a citable prior-art reference with a 1999-02-26 priority date, and it was already deployed as X-category art in EP 2 083 351 A1. Its disclosure — the universal driver plus text-based GPD discovered via a pre-defined OID over the network — is available as prior art notwithstanding its own lapsed status.

---

Uncertainty / limits. (1) I could not positively confirm a null result without direct PTAB E2E / Patent Center / PACER access; the "no proceedings" conclusion rests on the authoritative structured block plus web search that repeatedly returned this patent only in prior-art-citation contexts, never in a trial-caption context. (2) I found no evidence of an ex parte or inter partes reexamination either, but I did not run a dedicated reexam search — if one surfaced, it would be a post-grant proceeding outside the AIA-trial categories but potentially relevant to claim status. (3) Per the prior section's caveat, all bibliographic and status data are grounded in the Google Patents full text fetched 2026-09-24 and secondary sources; chain of title to Microsoft Technology Licensing, LLC was not independently verified in USPTO assignment records. (4) Nothing above is a legal conclusion or freedom-to-operate opinion.

I'll verify the assignment record through searches before constructing the analysis.

US Patent 6,952,831 — Ownership Chain & NPE-Pattern Analysis

Method note (important limitation): I could not directly query USPTO Patent Assignment Search (assignmentcenter.uspto.gov) or PEDS/ODP in this environment. The reel/frame data below is reconstructed from the Google Patents Legal Events table for US 6,952,831 (authoritative full text supplied, fetched 2026-09-24) and corroborated against Espacenet INPADOC "AS" (assignment) events, which reproduce the same REEL/FRAME strings. The correspondent-of-record field — the single most valuable tell for NPE chains — was not retrievable for either recording from the sources I could reach, and I will not guess it. Where a data point is unavailable I say so explicitly.

---

Inventors

• Pattern check — no anomaly. The single inventor assigned to Microsoft contemporaneously with filing (execution and filing both 1999-02-26), and stayed associated with the patent through issuance. There is no evidence of inventors departing the original assignee within 12 months of filing (that would be a fire-sale precursor). Prior-generation summary noted Moore's residence as Mercer Island, WA — consistent with a Redmond-area Microsoft employee; I could not independently corroborate an employment-date record, so treat "Microsoft employee" as inferred from the assignment rather than confirmed from HR/SEC data.

---

Original assignee

The original assignee is unambiguously an operating company, not a holding vehicle. That matters for the verdict below.

---

Assignment timeline

Two (2) recorded assignments exist. Both are corroborated by Espacenet INPADOC "AS" events carrying identical REEL/FRAME strings.

• 1999-02-26 (executed) / recorded 1999-02-26 — Reel 009811/0567

  • Conveyance: Assignment
  • Assignor: Paul Moore (sole inventor)
  • Assignee: Microsoft Corporation (Washington)
  • Correspondent: Not retrievable from sources available to me. (Recorded text is limited to "ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOORE, PAUL." No correspondent name/firm captured.)
  • Context: Standard inventor-to-employer assignment — the original, ordinary ownership transfer; not an acquisition or aggregation.

• 2014-10-14 (executed) / recorded 2015-01-15 — Reel 034766/0001

  • Conveyance: Assignment
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC (Washington)
  • Correspondent: Not retrievable from sources available to me. Because this reel (034766/0001) is a bulk, company-wide Microsoft→MTL transfer covering large numbers of Microsoft patents (confirmed here against unrelated Microsoft applications such as US 2005/0123886 and US 2006/035628, which carry the identical reel/frame in Espacenet), the correspondent on this reel is a single entity-level filer, not a per-patent attorney of record. Anyone analyzing this patent's chain must treat reel 034766/0001 as one event in a portfolio migration, not a bespoke transfer of this patent.
  • Context: Internal corporate reorganization / captive-portfolio migration — Microsoft spun its patent-holding and licensing function into the wholly owned subsidiary Microsoft Technology Licensing, LLC in 2014. No change in ultimate control.

Non-assignment legal events (for completeness, since they bear on assertion capacity):

• 2009-03-04 — FPAY, 4-year maintenance fee paid.
• 2009-07-28 — Certificate of Correction (CC) issued.
• 2013-05-17 — REMI (maintenance-fee reminder mailed, 12-year window).
• 2013-10-04 — LAPS / patent expired for failure to pay maintenance fees (37 CFR 1.362; docketed STCH 2013-11-04 and FP 2013-11-26).
• 2019-02-26 — Anticipated expiration date (moot; patent had already lapsed).

Chronology flag worth stating plainly: the Microsoft→MTL assignment was executed 2014-10-14, i.e. more than a year after the patent had already lapsed (2013-10-04) for non-payment. Microsoft transferred an already-expired patent to its captive licensing LLC. That is administrative housekeeping of a dead asset, not the seeding of an assertion campaign.

---

Timeline diagram

timeline
    title Ownership of US 6952831
    1999 : Inventor Moore assigns to Microsoft Corp
    2005 : Patent issues on Oct 4
    2009 : Certificate of Correction issued
    2013 : Patent lapses for unpaid maintenance fee
    2014 : Microsoft assigns to Microsoft Tech Licensing
         : Recorded at USPTO in Jan 2015

---

NPE / troll-pattern signals

Cross-reference note: I searched RPX/Unified-style asserter coverage and general litigation sources for patent 6,952,831 and found none. Two spurious "6952831" hits surfaced (a Lithuanian registry notice "Pranešimo Nr. 6952831" and an Indian trademark application number 6952831); neither is this patent and both were disregarded, consistent with the prior-generation summary.

---

Verdict

Defensive / non-asserting — closest fit.

Justification: The ownership chain is the original inventor-to-employer assignment (Paul Moore → Microsoft Corporation, reel 009811/0567, 1999-02-26) followed by a single intra-corporate migration (Microsoft Corporation → Microsoft Technology Licensing, LLC, reel 034766/0001, effective 2014-10-14 / recorded 2015-01-15). Both assignees are operating-company entities, no NPE-list name appears, and there is no recorded assertion or litigation involving this patent — which had already lapsed for non-payment of maintenance fees on 2013-10-04, before the very assignment that would otherwise matter. Strictly, the terminating assignee is a captive operating-company licensing subsidiary rather than a classic RPX/AST/LOT aggregator, so the label is applied on the "non-asserting / no NPE" substance; the true neutralizer here is expiration, not a defensive purchase. Zero of the eight NPE signals are affirmatively present (one is unverifiable), so no NPE verdict is supportable.

Verification link: https://assignmentcenter.uspto.gov/ (search by patent number 6952831; legacy index at https://assignment.uspto.gov/patent/index.html — reel 009811/0567 and reel 034766/0001).

---

Uncertainty / limits

1. Correspondent of record is unknown — the single data field most probative for NPE detection could not be retrieved for either reel. If you have live Assignment Center access, pull the correspondent for reels 009811/0567 and 034766/0001; my signal #3 will resolve to "not present" unless a repeat asserter-side filer shows up.
2. Reel 034766/0001 is a bulk Microsoft→MTL reel — verified by its presence on unrelated Microsoft applications, meaning it cannot carry an inferential finding about this patent specifically. Any analysis treating it as a personalized transfer is error.
3. No CAFC / district-court activity for 6,952,831 was located (consistent with the prior-generation summary). Given the 2013 lapse, active 2026 litigation is improbable, but absence of live PACER/CAFC access prevents a hard null confirmation.
4. Any claim that Microsoft "shipped a product embodying the claims" is grounded in the patent's own specification (Windows unidriver/GPD architecture) and the incorporated Microsoft patents, not in a fetched product-teardown; treat it as well-supported inference.

I'll research the prior art references cited against US 6,952,831, starting with the USPTO record and each cited reference.

Let me research the remaining cited references.

Let me research the remaining four cited references.

Prior Art Analysis — US 6,952,831 B1 ("Driverless printing")

Identification note (strict, literal): I analyzed the USPTO/Google Patents record for US 6,952,831 B1, application 09/258,623, filed 1999-02-26, issued 2005-10-04, inventor Paul Moore, original assignee [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) No similar-numbered patent was substituted. Search results that contradicted the record were not found; where the fetched full text and search results agreed, I used them.

Methodology & limits (stated up front):

• The authoritative list of references cited against this patent comes from the fetched USPTO/Google Patents record (see "Citations (8)" and "Non-Patent Citations (1)" in the full text). That list is reproduced literally below.
• I retrieved substantive text (abstract/summary/spec) for US 5,604,843; US 6,421,069; US 6,426,798; US 6,148,346 and partial text for US 6,091,507.
• For US 5,467,434; US 5,579,529; US 6,219,153 I relied on the patent's own citation records plus training knowledge — I did not retrieve the full specification text before hitting the tool-step limit, so those descriptions are marked as lower-confidence.
• Pre-AIA § 102 applies (filing 1999-02-26), so I assess each reference under §§ 102(a)/(b)/(e) as they existed then.

---

1. The 8 patent references cited in US 6,952,831

1.1 — US 5,604,843

• Full citation: US 5,604,843 A — "Method and system for interfacing with a computer output device." Inventors: Lin F. Shaw, Eric J. Bidstrup, Zhanbing Wu. Assignee: Microsoft Corporation. Filed/priority 1992-12-23; issued 1997-02-18.
• Description: The unidriver/minidriver architecture. Each minidriver implements device-driver functions and holds device-characterization data; it forwards calls to a universal driver, which controls the device using that characterization data. (Retrieved: Google Patents; FreePatentsOnline; EveryPatent.)
• § 102 basis: Qualifies under § 102(b) (issued >1 year before 1999-02-26). Note: this reference is not asterisked as examiner-cited in the record — it is the patent the '831 specification expressly incorporates by reference, so it is "cited by the applicant/description" (category D).
• Anticipation relevance: Discloses the universal-driver-component + device-characterization-data half of independent claims 1, 8, 15. It does not disclose a text-based description file resident at the device, an object identifier, or a network-protocol GET. It does not anticipate any claim, but it is the closest art on the "universal driver" element.

1.2 — US 6,421,069 B1

• Full citation: US 6,421,069 B1 — "Method and apparatus for including self-describing information within devices." Inventor: Harold Aaron Ludtke et al. Assignees: Sony Corporation / Sony Electronics Inc. US provisional 60/054,327 filed 1997-07-31; US filing 1998-06-04; issued 2002-07-16.
• Description: Self-describing information is embedded in a device's ROM describing the device's capabilities and controls; other devices read it to build a GUI and remotely control the device. It "can also include an address from which additional information about the device and upgrades are automatically obtained… either an internet address or points to a location within a network of devices," and can include driving software. (Retrieved: Google Patents; US6421069 PDF.)
• § 102 basis: Qualifies under § 102(e) (US filing 1998-06-04 / provisional 1997-07-31, both before the '831 filing).
• Anticipation relevance: This is the most conceptually relevant reference — it teaches device-resident self-description read from the device, plus a pointer/address to a remote location for updated information (analogous to '831 claims 3, 12, 19). It does not disclose SNMP, a pre-defined OID, or a GET, and its descriptions are graphical/self-describing rather than a text-based name-value description file feeding a universal driver. Arguably relevant to claims 1, 3, 8, 12, 15, 19; does not fully anticipate any claim.

1.3 — US 6,426,798 B1 ⚠️ date anomaly — flagged

• Full citation: US 6,426,798 B1 — "Data structure for printer description file." Inventor: Yeung. Assignee: Canon Kabushiki Kaisha. Filed/priority 1999-03-04; issued 2002-07-30.
• Description: A universal printer description data structure (XML/DTD) defining printer capability data elements; a printer-specific implementation is populated and stored in a universal printer description file used to configure a universal printer driver to interface with a specific printer; extensible to add new data elements. (Retrieved: Google Patents.)
• § 102 basis — ANOMALY: Its US filing date (1999-03-04) is six days after the '831 filing date (1999-02-26). It therefore does not qualify as prior art under § 102(a), (b), or (e) unless the applicant's actual invention date is proven later than 1999-03-04. I am flagging this as a genuine inconsistency between the citation list and the statutory dates rather than auto-correcting it: the record shows it in the "Citations (8)" list, but on its face it postdates the priority date and is best treated as contemporaneous/curiosity art, not § 102 art. Verifying this in PatentCenter would require a manual check I could not perform.
• Anticipation relevance: Even if it were prior art, it discloses the text-based printer-description-file + universal-driver pairing (relevant to claims 1, 8, 15) but not the OID/network-protocol retrieval from the device.

1.4 — US 6,148,346

• Full citation: US 6,148,346 A — "Dynamic device driver." Inventor: Hanson et al. Assignee: Peerless Systems Imaging Products, Inc. Filed 1996-06-20; issued 2000-11-14.
• Description: A device driver split into an operating-system-specific portion and an operating-system-independent device driver portion, linked by a two-way communication mechanism; HTML-formatted information may be stored in (or retrieved relative to) the printer. (Retrieved: Unified Patents portal; Espacenet INPADOC; USPTO.report.)
• § 102 basis: Qualifies under § 102(e) (US filing 1996-06-20).
• Anticipation relevance: Relevant to the "driver split into a portable/generic component + separately-stored device-specific data" idea (claims 1, 8, 15). No OID/SNMP disclosure. Does not anticipate.

1.5 — US 6,091,507

• Full citation: US 6,091,507 A — "Method and apparatus for printing a document over a network." Inventors: Vatland et al. Assignee: Colorspan Corporation. Filed/priority 1994-07-01; issued 2000-07-18.
• Description: Network printing of documents (per the title and citation record; full text not retrieved).
• § 102 basis: Its issue date (2000) postdates the '831 filing, so it is § 102(e) art (US filing 1994-07-01), not § 102(b).
• Anticipation relevance: General network-printing background (claims 1, 4, 15, 16 touch network communication). Does not anticipate — no universal-driver/description-file/OID combination disclosed.

1.6 — US 6,219,153 B1 (lower-confidence — full text not retrieved)

• Full citation: US 6,219,153 B1 — "Printer having a memory for storing a printer profile parameter." Inventors: Kawanabe et al. Assignee: Canon Kabushiki Kaisha. Priority 1997-11-17; issued 2001-04-17.
• Description: A printer that stores a printer profile parameter in its own memory (per title/citation record) — i.e., device-resident configuration data, but a profile parameter, not a text-based description file driving a universal driver.
• § 102 basis: § 102(e) (US filing on/before 1997-11-17).
• Anticipation relevance: Relevant to "description/capability data stored in peripheral memory" (claims 2, 11). Does not anticipate any independent claim.

1.7 — US 5,579,529 (lower-confidence — full text not retrieved)

• Full citation: US 5,579,529 A — "Method for configuring computer peripherals." Inventors: Terrell et al. Assignee: NCR Corporation. Filed/priority 1993-12-30; issued 1996-11-26.
• Description: Automated configuration of computer peripherals (per title/citation record).
• § 102 basis: § 102(b) (issued 1996-11-26, >1 yr before 1999-02-26).
• Anticipation relevance: Background on peripheral self-configuration; possibly relevant to claims 1, 15's "configuring the driver from the peripheral." Does not anticipate.

1.8 — US 5,467,434 (lower-confidence — full text not retrieved)

• Full citation: US 5,467,434 A — "Apparatus and method for determining printer option availability and representing conflict resolution in a combination of print job selections." Inventors: Hower et al. Assignee: Xerox Corporation. Filed/priority 1992-08-28; issued 1995-11-14.
• Description: Determining which printer options are available and resolving conflicts among print-job selections — a user-interface/option-model reference.
• § 102 basis: § 102(b) (issued 1995-11-14).
• Anticipation relevance: Relevant to the options/UI presentation aspects discussed in the '831 spec and FIG. 4 (claims 1, 8, 15's "device-specific driver functions" and the UI). Does not anticipate.

---

2. Non-patent citation

• Citation: The Unicode Standard, Version 2.0, The Unicode Consortium, Addison-Wesley Press, 1997.
• § 102 basis: § 102(b) printed publication (>1 yr before 1999-02-26).
• Relevance: Background for the "text based" limitation common to claims 1, 8, 15 (character encoding of the description file). Not anticipatory of the claimed architecture.

---

3. Bottom line — § 102 anticipation assessment

Key conclusion: No single cited reference anticipates any claim of US 6,952,831 under § 102. Every independent claim (1, 8, 15) requires the conjunctive combination of (i) a driver split into a universal peripheral driver component and a physically separate text-based generic peripheral description file component, and (ii) that description file being located via at least one pre-defined object identifier (OID) value and accessed through a network protocol (GET/SNMP per claims 4/5/9/10/16/17). None of the eight references teaches the OID-over-network-protocol discovery of the description file from the peripheral. The closest single reference is US 6,421,069 (Sony/Ludtke) — device-resident self-description plus an address for updated information — but it lacks the OID/SNMP mechanism and the universal-driver-incorporates-text-file architecture, so it is § 103 (obviousness) or background art, not § 102 anticipation. This is consistent with the fact that the examiner cited these references yet the claims issued.

Most relevant prior art ranking: 1) US 6,421,069 (device self-description + pointer to remote info); 2) US 5,604,843 (universal driver/minidriver, incorporated by reference); 3) US 6,426,798 (text-based printer description file → universal driver); 4) US 6,148,346 (OS-independent driver portion).

---

4. Caveats / uncertainty (explicit)

1. US 6,426,798's date anomaly is real and unresolved. Its US filing (1999-03-04) postdates the '831 filing (1999-02-26); I did not access PatentCenter to confirm whether it was relied on under a different statutory basis or merely listed as of-interest. Do not treat it as § 102 art without that confirmation.
2. Three references (US 5,467,434; US 5,579,529; US 6,219,153) are described from title/citation records and training knowledge, not verified full text (tool limit reached). Their descriptions should be confirmed before being relied on.
3. I did not run a formal claim chart against every reference; the "closest claim" mapping is analytical, not an examiner-style element-by-element chart.
4. Per the strict rule, I reproduce the patent's literal protocol name "Simple Network Mail Protocol (SNMP)" and its other internal inconsistencies (e.g., "printer bank 96" vs. 114; "UFF" vs. "UTF") without correction — consistent with the earlier generated sections.
5. No direct USPTO PatentCenter / PTAB query was possible; the reference list is grounded in the fetched Google Patents full text of US 6,952,831, corroborated by FreePatentsOnline.

Would you like me to build a formal element-by-element § 103 obviousness chart (e.g., US 6,421,069 + US 6,148,346 in view of SNMP/OID knowledge) for the independent claims?

I'll ground the key prior-art references before building the § 103 analysis.

Let me ground the remaining cited references.

Obviousness Analysis — US 6,952,831 under 35 U.S.C. § 103

Patent: US 6,952,831 B1, "Driverless printing," Paul Moore (Microsoft), filed 1999-02-26, issued 2005-10-04.
Analysis date (per task): April 26, 2026. Note a contradiction to flag: this task specifies April 26, 2026, while the earlier summary section of this analysis used a system date of 2026-10-01. I flag it and proceed on the April 26, 2026 date; nothing in this analysis turns on the difference.
Prior art basis: The 8 references cited on the face of the patent (per the Google Patents "Patent Citations (8)" table) plus the single non-patent citation. URLs are given where I confirmed the reference.

---

0. Threshold status note (does not change the § 103 analysis)

Per the previously generated sections (authoritative here), the patent lapsed for non-payment of maintenance fees effective 2013-10-04 (37 CFR 1.362) and its 20-year term would have run to 2019-02-26. Obviousness is therefore analyzed for its prior-art and defensive value (the '831 disclosure is itself citable art, e.g., as the X-category reference against EP 2 083 351 A1), not because live claims are being challenged. No contradiction with the earlier sections.

---

1. Governing law and the POSITA

Under Graham v. John Deere, 383 U.S. 1 (1966), and KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), I apply: (i) scope/content of the prior art; (ii) differences between the prior art and the claims; (iii) level of ordinary skill; (iv) secondary considerations. KSR supplies the enumerated rationales for combining (predictable use of prior-art elements according to known methods; simple substitution; use of a known technique to improve a similar device in the same way; "obvious to try" where the field presents a finite number of identified, predictable solutions).

POSITA definition (adopted for this analysis): a software engineer with a bachelor's degree in computer science or electrical engineering and approximately 2–4 years of experience designing device drivers and host/peripheral communication software for a mass-market operating system, including familiarity with GDI-style graphics device interfaces, network management protocols (SNMP), and printer page-description/description-file formats as of February 1999.

---

2. The decisive point: the specification concedes most of the claim

The '831 specification is, unusually for an obviousness analysis, an admission-rich document. It expressly characterizes as already known:

• The GDI/driver architecture and the driver's role translating GDI functions into device commands.
• The universal driver ("unidriver") + minidriver split (US 5,604,843, cited and incorporated by reference in the '831 spec itself).
• The GPD — a "text-based printer description format" describing "all of the features on a printer and how to display those features to the user," as "a series of name-value pairs called entries."
• An updated unidriver that parses the GPD file and presents the options to the user.
• SNMP as the transport: "The communications between the printer 90 and computer 20 use a known protocol, such as the Simple Network Mail Protocol (SNMP)" — an express admission that the protocol is a known prior-art protocol.
• A "drop-in" code mechanism and pointers to additional files (ICM profile, font metrics).
• The printer-bank aggregation with printer profiles.

The only things the patent frames as new are (a) putting that admitted GPD on the peripheral rather than on a disk/website, and (b) finding it there via a pre-defined OID. Both are squarely within the prior art below. The merits question is therefore narrow: was it obvious, as of 1999-02-26, to move an admitted text description file onto the device and fetch it with an admitted known protocol at a fixed identifier?

---

3. The cited prior art and what each teaches

---

4. Element-by-element mapping to independent claim 1

Every element of claim 1 is disclosed or rendered obvious by the combination of US 5,604,843 + US 6,421,069 (optionally + US 6,217,153).

---

5. Grounds of rejection

Ground 1 — Claims 1, 2, 6, 8, 13, 15, 20: US 5,604,843 (Shaw) in view of US 6,421,069 (Rudtke)

The core combination.

Shaw supplies the two-piece architecture the claims recite — a universal driver physically separate from a per-device characterization component — and the function of that characterization (device-specific control commands that the universal driver "incorporat[es].") Rudtke supplies the only remaining element: relocating that characterization onto the device itself and reading it out over a network.

Motivation (KSR rationales (A), (B), (C), (D)):

• Known problem, known fix. Rudtke states the exact problem the '831 spec recites verbatim in its Background — that driver/GPD distribution is done "on a floppy disk or CD-Rom," requiring the user to load the right one, and that "a user must load the printer driver software on the computer system before the computer system is able to recognize and communicate with the printer." Both documents attack the same administrative burden.
• Simple substitution / component relocation. Rudtke teaches that the information needed to control and represent the device can be stored in the device and read out by the host; the only difference from Shaw is where the minidriver's characterization blob lives and how it is transferred. Moving a data object from host storage to device storage and transferring it at connect time was an ordinary engineering choice with predictable results.
• Reasonable expectation of success. Shaw already reads device characterization at initialization and stores it "in a format expected by the universal driver." Rudtke already reads self-describing device data over a link and presents device controls/UI. Combining them yields nothing more than Shaw's unidriver initialized from Rudtke's device-resident description.
• Even the format is admitted. The '831 spec concedes the text-based GPD, its name-value structure, and the parsing unidriver were prior work; Rudtke's device-resident data performs the same role (device type, features, capabilities, and "user interface information for representing the device and its features to the user").

Ground 2 — Claims 1, 2, 3, 8, 12, 15, 19: US 5,604,843 in view of US 6,148,346 (Hanson)

The strongest combination on the "physically separate" and "remote storage / pointer" limitations.

Hanson discloses a driver already split into two physically separate portions — an OS-specific portion and an OS-independent device-specific portion — and expressly places the latter off the host: "resides either in the host computer system, in the peripheral device that it is specific to, or in an independent server connected… through a local area network… or… the Internet." It further discloses the step of "retrieving, at the host computer system, at least one peripheral device driver associated with the selected peripheral device…" (claim 1) and that the retrieved portion "includes information regarding peripheral device operation, peripheral specific data objects… and may include graphical user interface (GUI) objects" (e.g., paper trays, formatting requirements).

Motivation: Hanson was concerned with the same network-peripheral driver-management problem the '831 patent addresses — "connect[ing] any peripheral devices to any host computer system" over a LAN/Internet, "easily accommodat[ing] peripheral devices and host computer systems produced by various manufacturers." A POSITA seeking to eliminate pre-installed GPD selection (the '831 Background) would look to Hanson's network-retrievable, device-specific driver portion and to its device/server-resident data objects, and would predictably arrive at claims 1, 3, 12, and 19.

Ground 3 — US 6,421,069 in view of US 6,217,153 (Canon), further in view of US 5,604,843

The "query the device over the network and receive its characterization" combination.

Rudtke supplies device-resident self-description plus an address (Internet address or network pointer) to obtain "additional information about the device and upgrades" automatically — which is precisely claim 3 ("remote memory storage… pointed to by a pointer contained in the peripheral memory storage"), claim 12, and claim 19. Canon '153 supplies the request/response retrieval of device-resident characterizing parameters into the host, on which the host's driver then operates — precisely the "accessed by referencing the peripheral memory storage in accordance with the network protocol" and "learns the peripheral's capabilities" steps.

Motivation: Both references motivate automatic acquisition of device data to avoid user-supplied device identification and to keep host-side configuration current — the twin concerns in the '831 Background ("the user will have to identify the printer"; "printer options may change between the time that the drivers are incorporated into the operating system and the time the user buys the printer"). The pointer-to-remote-storage feature is a known technique (Rudtke) applied to supply the latest device data (the '831 Fig. 6 embodiment), with the predictable benefit that the manufacturer "could… immediately place[]" a new option in the description.

Ground 4 — Claims 4, 5, 9, 10, 16, 17, 18: adding SNMP/OID retrieval

Claims 4/9/16 recite SNMP; claims 5/10/17 recite a GET request for a pre-defined OID; claims 11 and 18 recite using the OID to locate memory.

This limitation is met by an express admission. The '831 specification states the protocol is "a known protocol, such as the Simple Network Mail Protocol (SNMP)" and describes "a pre-defined OID…, such that the computer 20 can GET that OID every time." SNMP management of printers was conventional by 1999 (device management via MIB OIDs was standard; the printer-MIB work dates to the mid-1990s). Where a specification describes a feature as known or conventional, that is a persuasive admission that the feature cannot impart patentability (In re Nomiya; MPEP 2129). Canon '153 separately teaches the concrete mechanism of "send[ing] commands to the printer for accessing a non-volatile memory in the printer" and obtaining the stored information in response.

Literal-claim caveat: the claims and specification say "Simple Network Mail Protocol (SNMP)." Taken literally this is a nonce/nonsense expansion of the SNMP acronym. For § 103 purposes I read the term as the POSITA would — SNMP, the Simple Network Management Protocol — because the specification's described GET/OID mechanism is SNMP's. If instead the term is read literally, the limitation is arguably indefinite under § 112(b) (the previously generated summary correctly declined to auto-correct it; I preserve that discipline here while noting the § 103 reading depends on the correction).

Ground 5 — Claims 6/13/20 (printer) and 7/14/21 (scanner)

• Printer: US 5,604,843 (printer characterization data); US 6,217,153 (printer profile parameters); US 5,467,434 (printer profiles in a printer bank); US 6,091,507 (network printing).
• Scanner: the specification itself states "a universal scanner driver could read input from a Generic Scanner Description (GSD) file for a scanner. As in the case of a printer GPD 102, the scanner GSD could be a text-based file containing options in name-value entries." That is an express admission that the scanner species is the same invention applied to an analogous peripheral with no new mechanism. A POSITA would apply the same device-resident-description approach to scanners with a reasonable expectation of success (identical architecture, different engine).

Ground 6 — the printer-bank layering (Fig. 5 embodiment)

US 5,467,434 discloses a printer bank with per-printer profiles, a remote input section, and comparison of requested job selections against the profiles — i.e., the "two levels of commands" layering and capability aggregation the '831 spec describes ("the GPD 112 resident on the peripheral 110 would teach the computer 20 how to instruct the peripheral 110, and the GPD files 102 resident on the printers 90 would teach the peripheral 110 how to instruct each of the printers 90"). The '831 spec says this layering "would be obvious to one of skill in the art" — another admission.

---

6. Why a POSITA would have been motivated — synthesis

Speaking to each independently sufficient KSR rationale:

1. Predictable combination of known elements (KSR (A)). Every claimed element exists in the cited art: unidriver (Shaw), device characterization with device-specific commands (Shaw), device-resident self-description (Rudtke), network retrieval of the device-specific driver portion (Hanson), query/response read of device memory (Canon '153), text-based description files (admitted GPD). The combination yields merely the expected sum of its parts — a driver that configures itself from data it retrieves from the device.
2. Simple substitution (KSR (B)). Replacing a host-stored minidriver/GPD with a device-stored one, and a user-selected file with a queried one, is substitution of one known element for another to obtain a predictable result.
3. Known technique, same improvement (KSR (C)). SNMP GET-by-OID and request/response reads of peripheral non-volatile memory were established techniques for discovering peripheral capability; applying them to driver configuration is the same improvement (automatic, current, device-accurate configuration) previously achieved for status/management data.
4. Obvious to try (KSR (D)). The field presented a finite set of identified, predictable approaches to the "which GPD is right for this printer?" problem: (i) bundle more pre-installed drivers; (ii) let the user select from a website; (iii) ask the device. Option (iii) was already known (Rudtke, Hanson, Canon '153), and the art provided a clear design incentive to reduce user installation burden (both Rudtke and the '831 spec identify it as the goal).

Market/design pressures: (a) minimizing memory for pre-installed drivers (the '831 Background's own account of the unidriver/minidriver origin); (b) keeping configuration current as device options are added post-OS-release (the '831 Background's "printers options may change" point); (c) "plug-and-play" network device installation, already an industry direction. These supply the "design incentive" and "market pressure" recognized in KSR.

---

7. Dependent claims — no separate patentable weight

Claims 2/3 (file in peripheral memory / remote memory via pointer), 11/12 and 18/19 (OID locates the file or a pointer), and 4/5/9/10/16/17 (SNMP, GET) all recite where the description file sits and how it is addressed — the classic subject matter of In re Harza and KSR's point that "a patent composed of several elements is not proved obvious merely by demonstrating that each of its elements was, independently, known." Here the evidence is stronger: the elements are not merely individually known, they were known to be combinable (Hanson expressly places the driver portion on the peripheral or a remote server; Rudtke expressly teaches an address/pointer to obtain device information and upgrades). An obviousness rejection of the independent claims carries the dependents.

---

8. Secondary considerations (Graham factor 4) — none found

• No unexpected results appear in the '831 disclosure. The claimed advantages (no manual driver selection, current options, unknown-but-presentable features) are the predictable consequences of a device-supplied description.
• No licensing/industry-praise/skepticism evidence surfaced in the earlier sections of this analysis; the patent was never asserted (per the Litigation section) and shows no PTAB activity (per the PTAB section). Absence of assertion is not itself an obviousness factor, but it means there is no record of nexus-bearing secondary evidence to weigh against the prima facie case.
• Commercial success (Microsoft's driver architecture) would not attach absent proof of nexus to the specific claimed advance — i.e., device-resident GPD fetched by pre-defined OID — as opposed to the admitted unidriver/GPD system, which predates the claim.

---

9. Weaknesses, counterarguments, and stated uncertainties

I want to be explicit about the soft spots rather than overstate the case.

1. Date defect in US 6,426,798. Google Patents lists this Canon reference with a priority date of 1999-03-04 — seven days after the '831 filing date of 1999-02-26. If that date is correct, US 6,426,798 is not prior art under § 102(a)/(e)/§ 103 against the '831 claims, notwithstanding that it appears in the patent's facial citation list (examiners do cite later-dated art, and a § 102(e) date can differ from the listed priority if there is an earlier provisional). I could not verify its actual filing/§ 102(e) date. I have therefore excluded it from every ground above. This is a genuine uncertainty, not a correction of the number or date.
2. US 5,579,529 and US 6,091,507 full texts not retrieved. I ran out of tool steps before fetching them. My treatment of both is deliberately conservative — I use them only as facial corroboration that peripheral-configuration and network-printing art existed by the mid-1990s. No ground above depends on either reference, so this gap does not affect the conclusions.
3. "Simple Network Mail Protocol" literal reading. As noted in § 5, the claim term as literally written is arguably indefinite, and the § 103 analysis of claims 4/5/9/10/16/17 depends on reading it as SNMP. Per the strict rule, I have not silently corrected the patent's identifier.
4. "Text based" / "incorporates." A patentee could argue that Shaw's binary/data-structure minidriver resource file is not "text based," and that "incorporates" implies more than "reads at initialization." I find these distinctions unpersuasive given that (a) the '831 spec admits the text-based GPD was known, so the text-based character is not the point of novelty, and (b) Shaw's initialization function literally "reads the device characterization data [and] stores [it] in a format expected by the universal driver," which is incorporation. But a fact-finder could weigh the wording differently.
5. Hindsight risk. The grounds are built on references that post-date each other in places (Shaw 1997, Rudtke 2002 issue/1998 filing, Hanson 2000 issue/1996 filing). All filing/priority dates except US 6,426,798 predate 1999-02-26, so there is no § 102(a)(2)/§ 103 date problem — but an advocate could argue the motivation narrative sounds like it is told backward from the claim. The counter is that the motivations are drawn from the references' own stated problems (Rudtke's elimination of driver disks; Hanson's "any peripheral to any host" objective; Canon '153's on-request profile retrieval) and from the '831 specification's own admitted problem statement.
6. Consistency checks against earlier sections:
   • Earlier sections correctly state 21 claims, independents 1 (system), 8 (CRM), 15 (method), and the 1999-02-26 priority. No contradiction.
   • The PTAB section noted the patent "function[ed] mainly as prior art against others' later applications" and cited EP 2 083 351 A1's X-category use of "US 6 952 831 B1 (Moore)." That is consistent with my treatment here.
   • The Litigation section's Unified Patents snippet listed the family member as "US-7421712-B2 … 1999-02-25 Driverless Printing" (one day earlier than the 1999-02-26 priority shown by Google Patents). Minor inconsistency in a secondary source; flagged, not relied upon. It does not affect this analysis.

---

10. Bottom line

• Strongest ground: US 5,604,843 (Shaw) + US 6,421,069 (Rudtke), optionally further in view of US 6,217,153 (Canon) ⇒ claims 1, 2, 6, 8, 13, 15, 20 obvious. This combination covers every element of independent claim 1, and the motivation is supplied by both references' own stated objectives and by the '831 specification's admitted problem statement.
• Second ground, strongest on the "physically separate" and remote/pointer limitations: US 5,604,843 + US 6,148,346 (Hanson) ⇒ claims 1, 2, 3, 8, 12, 15, 19 obvious; Hanson literally discloses a driver split into separate portions with the device-specific portion residing in the peripheral or a remote server and retrieved over a LAN/Internet.
• SNMP/OID limitations (4, 5, 9, 10, 16, 17, 18): met by the specification's express admission that SNMP is a "known protocol" and that the computer "GET[s] that OID every time," plus US 6,217,153's request/response read of peripheral non-volatile memory.
• Scanner claims (7, 14, 21): obvious by direct analogy — the specification itself says the GSD is "as in the case of a printer GPD 102."
• Overall: the claims are a predictable relocation and lookup of an admitted prior-art text description file, using an admitted prior-art protocol, combined with an admitted prior-art universal driver. Under KSR, the combination is obvious, and the specification's own admissions do most of the work.

Not legal advice, and not a freedom-to-operate or validity opinion. The analysis rests on the Google Patents full text fetched 2026-09-24 and the reference texts retrieved above; US 5,579,529, US 6,091,507, and the actual § 102(e) date of US 6,426,798 were not verified. If a definitive conclusion is required, pull the full texts of those three references from USPTO Patent Center/Patent Public Search (the '831 file wrapper) and confirm US 6,426,798's earliest effective filing date before relying on it in any ground.