US 5550962

I'll search for the specific patent number and any related litigation or CAFC docket activity.

US 5,550,962 — Verification Summary

Search scope & confidence note. I searched for the exact number 5550962 / 5,550,962 against patent databases and CAFC/Federal Circuit docket material. No CAFC 2026 docket activity, IPR/PGR, or district-court litigation naming this patent was returned. Databases indexed via search (Google Patents, Justia, FreePatentsOnline, uspto.report, CAFC scheduled-cases/opinions listings) are consistent with each other and with the authoritative full text supplied in this session. I did not directly query the USPTO Patent Center/Patent Public Search UI or PACER in this session, so the bibliographic data below rests on the supplied full text plus corroborating indexes rather than a live USPTO record pull. Where sources conflict, I flag it.

---

Bibliographic data

Cited prior art: US 5,321,808 A (Hewlett-Packard, "Dual process display server," 1994-06-14); non-patent literature "The X Window System" (ACM Transactions on Graphics, Vol. 5, No. 2, pp. 78–109) and "The Multi-Threaded X Server" (Proceedings, 6th Annual X Technical Conference, pp. 73–89).

---

Abstract (as granted)

A distributed drawing processing system including a drawing server that integratedly executes a string of drawing commands transmitted from a client program for graphics display. The client program divides the drawing command string into a block of drawing commands processable on a parallel basis and a block of drawing commands not processable on a parallel basis, and transmits the divided blocks to the drawing server. The drawing server executes the drawing command string while judging, for each divided block, whether to process it on a parallel or sequential basis.

---

Plain-language overview of the independent claims

Claim 1 — Client-tagged parallelism flag (broadest claim).
A drawing system with three parts: a client that sends a multi-command drawing string over a defined protocol; a drawing server that receives it and drives a display; and a communication path between them. The client side attaches a single predetermined command to the drawing command string that tells the server whether the subsequent command string should be handled in parallel or sequentially, and sends it. The server side has an "execution control determination means" that, on receipt, reads that attached command and decides parallel vs. sequential treatment accordingly. The novelty is essentially moving the parallelizability decision to the client and encoding it in-band as a control command.

Claim 7 — Explicit parallel-block bracketing (start/end pair).
Same three-part system architecture, but the client attaches a pair of commands around at least one drawing command string: a "parallel processing block start command" marking the beginning of a parallelizable string and a "parallel processing block end command" marking its end. The server, on receipt, processes the subsequent string in parallel in response to the start command and reverts to sequential processing in response to the end command. This is the concrete bracket-delimiter implementation of claim 1's general concept.

Dependency structure (for context, not independent):

• Claims 2–6 depend from claim 1 — adding a plurality of drawing threads plus a dispatcher that allocates commands to threads (2), multiple processors (3), dispatcher/threads distributed across bus-connected processors (4), client and server in the same processor (5), and client/server in different processors linked by a network (6).
• Claims 8–15 depend from claim 7 — allocating commands to threads until the parallel-block end command arrives (8), the parallel/sequential command dispatcher pair (9), multiple processors (10), bus-connected processor distribution (11), nesting an explicit sequential block between the parallel start/end pair with the whole span still run as one parallel block (12), the dispatcher pair applied to sequential sub-blocks (13), same-processor co-location (14), and network-separated processors (15).

Literal-transcription note: claim 7 as published opens "A drawing processing system compromising:" — a typo for "comprising" that appears in the granted text and in multiple reproductions of it. I have not corrected it, per instruction to interpret identifiers and text literally. Likewise, claim 8's "until said dispatch accepts said parallel processing block end command" reads as a typo for "dispatcher." These are recorded verbatim, not normalized.

---

Technical context

The patent addresses a known limitation of X Window System–style display servers: a server built on a multiprocessor could parallelize drawing requests coming from different clients (via per-client threads, per the Multi-Threaded X Server reference) but could not parallelize requests from a single client, because reordering drawing commands can corrupt the display. The specification's FIG. 13 example is the canonical illustration — drawing a blue square over a large red circle, where overtaking execution causes the red circle to be painted last and the blue square to disappear in the overlap zones. The invention's answer is to have the client, which is in the best position to know the drawing-order semantics of its own command stream, bracket the command stream into parallelizable and non-parallelizable regions, and let the server's dispatcher use those in-band markers to decide between the parallel command dispatcher (FIG. 10) and the sequential command dispatcher (FIG. 9) routines, with any commands outside explicit blocks defaulting to sequential treatment.

---

What I could not confirm

• No USPTO litigation record: I found no assignment of this patent beyond the original Hitachi assignment, no reissue/rexam, and no IPR/PGR or district-court case asserting it. Hitachi, Ltd. does appear as a defendant in unrelated 2021–2025 patent suits (e.g., FrameTech LLC, Elite Gaming Tech LLC, TurboCode LLC matters), but none of those search results tie to US 5,550,962.
• No CAFC 2026 docket entry: searches of the Federal Circuit's scheduled-cases listings and 2026 opinion summaries returned no case involving this patent number.
• Values shown on third-party aggregator sites (e.g., "Approx Value $105,000" on patentleaderboard.com) are commercial estimates, not authoritative USPTO or court data, and should not be treated as ground truth.
• The 2015 vs. 2008 expiration discrepancy noted above is a genuine conflict within the source record; I have identified which entry the maintenance-fee events support but cannot resolve it further without a direct USPTO fee-history pull.

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

These results are off-target (different patents). Let me search litigation-specific databases directly.

Let me check dedicated litigation databases and docket aggregators more specifically.

Litigation Search — US Patent 5,550,962

Bottom line: I found no known litigation (district court, ITC, or PTAB) involving US 5,550,962.

Sources searched and what they returned

False positives — explicitly distinguished (do NOT attribute these to US 5,550,962)

1. Apotex Corp. v. Merck & Co., No. 96-C-7375 (E.D. Pa.), aff'd, Apotex USA, Inc. v. Merck & Co. (Fed. Cir. 2000) — concerns the Apotex '780 and '962 patents covering a VASOTEC (enalapril) manufacturing process. Those are pharmaceutical process patents, not US 5,550,962. The "962" here is a coincidence of trailing digits.
2. Saxon Innovations suits (HP, Dell, Acer, Apple) asserting 5,592,555; 5,502,689; 5,530,597; 5,235,635 — different numbers entirely, different owner.
3. Lucent v. Gateway (Fleming '759 patent) and Gussin v. Nintendo ('335 patent) material surfaced by keyword hits on "drawing commands"/"sequential" — unrelated patents and parties.
4. A Florida corporate annual report ("FEI Number: 46-5550962") — an IRS EIN, not a patent.
5. Various 2026 Federal Circuit briefing (e.g., Constellation/LG damages petition, VL Collective IP v. Unified Patents) — no relation to '962.

Why the absence of litigation is consistent with the record

• The patent lapsed for failure to pay maintenance fees effective 2008-08-27, with discontinuation recorded 2008-09-22 under 37 CFR 1.362 (per the legal-events table in the full text). An expired, fee-lapsed patent has little or no enforcement value, which is consistent with the absence of any assertion activity — and would bar any prospective infringement suit. (This corroborates the expiration finding in the previously generated bibliographic section; note again the internal conflict with Google Patents' computed "anticipated expiration 2015-04-10," which is a term estimate, not the operative event.)
• The only recorded ownership transfer is the original 1995-04-10 assignment to Hitachi, Ltd. (effective 1995-04-03). No later assignment to an NPE/assertion entity appears in the record.

Confidence and caveats (stated explicitly, per your no-fabrication rule)

• Confidence that no litigation exists: moderate-to-high for the 1995–2008 window and for PTAB/IPR activity; lower for anything after ~2008, since litigation databases are rarely complete for a patent that no one has asserted.
• I was unable in this session to directly query: the Unified Patents litigation case list UI (portal.unifiedpatents.com/litigation/caselist), PACER/Docket Navigator, or the Federal Circuit's docket system. My search tool calls to those targets were cut off by a step limit. My conclusion rests on the Google Patents record, RPX Patent Insight, uspto.report, and keyword searches against litigation-oriented material — all of which are negative for this patent.
• I found no plaintiff, defendant, jurisdiction, case number, or filing date to report. Providing any such entry would require fabricating it, which I will not do.

Recommended verification if you need a definitive negative: a paid Docket Navigator or LexisNexis PatentAdvisor "patent litigation history" pull on US 5,550,962, plus a PACER "case number search" and a PTAB API query — these are the authoritative sources I could not reach live.

I'll verify the structured "no proceedings on file" result against live sources before reporting.

Let me run a couple more targeted checks against PTAB-specific dockets and the JP counterpart.

Proceedings overview

Total AIA trial proceedings on US 5,550,962: zero. The USPTO Open Data Portal (ODP) AIA-trial record — the canonical source for this analysis — returns no IPR, PGR, or CBM proceeding naming this patent, and my independent checks against PTAB docket aggregators and the Federal Circuit's public listings found nothing to contradict that. Breakdown: 0 active, 0 invalidated, 0 sustained, 0 settled, 0 institution-denied. The defensive bottom line: there is no PTAB record to lean on and no claim that has been canceled — but there is also no live patent. US 5,550,962 lapsed in 2008 for non-payment of maintenance fees, seven years before the AIA trial regime's first petitions and roughly four years before the IPR statute took effect. Any demand letter citing this patent is asserting a patent that has been dead for eighteen years.

---

Proceedings list

(none)

There is no proceeding to analyze at the claim level. Rather than invent institution decisions, panels, or FWDs, I record the verified null result with its provenance:

• ODP AIA trial data: no proceedings on file for application US 08/419,278 / patent US 5,550,962.
• Google Patents record (https://patents.google.com/patent/US5550962/en): the "Cited By" list contains 66 records and the "Patent Citations" list contains one (US 5,321,808 A, Hewlett-Packard, "Dual process display server"). Neither section contains any PTAB trial record; Google Patents inserts IPR/PGR links into this section when they exist, and none appear here. The Legal Events table for this patent ends at 2008-10-14 ("Lapsed due to failure to pay maintenance fee," effective 2008-08-27) with no inter partes review, post-grant review, or CBM entries.
• PTAB docket aggregators / CAFC listings: no match for 5550962 or 5,550,962 as a challenged patent. The patent does surface in PTAB exhibit materials — e.g., it appears as a cited reference of record in a Realtek petition exhibit (IPR2023-00922, Exhibit 1002). That is third-party prior-art citation activity about the reference, not a proceeding against the patent, and it should not be mistaken for one.

Why there is no PTAB record (structural, not coincidental)

Three independent reasons make the null result expected rather than surprising:

1. Statutory unavailability of PGR. PGR under 35 U.S.C. § 321 applies only to patents subject to first-inventor-to-file provisions — i.e., applications filed on or after 2013-03-16. US 5,550,962 has a 1994 priority date and a 1995 filing date; it was never PGR-eligible. That removes an entire proceeding type from the possible universe.
2. The IPR window postdates the patent's death. Inter partes review became available for pre-AIA patents on 2012-09-16. The patent had already lapsed on 2008-08-27. A would-be challenger in, say, 2013 had nothing to challenge and no enforceable right to clear. CBM review (available only to a party charged with infringement) is likewise impossible against an expired, unasserted patent.
3. Never asserted. The patent's own record shows the original 1995 assignment to Hitachi, Ltd. and nothing else — no reissue, no reexamination, no recorded subsequent assignment, no litigation. Patents that are never asserted in district court rarely attract IPRs, because the usual trigger (a served complaint and the § 315(b) one-year clock) never occurs. Well-asserted patents eventually attract IPRs; this one was never asserted, and it expired before that could matter.

---

Strategic summary

Claim status. The meaningful distinction for this patent is not "canceled vs. sustained" — it is "expired vs. live." All 15 claims (independent claims 1 and 7, plus dependents 2–6 and 8–15) stood as granted and were never amended, canceled, or narrowed by any PTAB or district-court proceeding, because no such proceeding exists to have done so. But all 15 claims became unenforceable through lapse on 2008-08-27, with formal patent discontinuation recorded 2008-09-22 under 37 CFR 1.362. As noted in the earlier verification section, the source record carries a conflicting "anticipated expiration 2015-04-10" entry; that is a computed statutory-term estimate that takes no account of the fee lapse, and the maintenance-fee events are the operative ones. For practical purposes, there are no surviving claims of US 5,550,962 to assert.

Estoppel landscape. There is no § 315(e)(2) estoppel to analyze, because no petitioner ever filed and no final written decision ever issued. The estoppel question is moot in both directions: no petitioner is barred from anything (a person sued on this patent could not exist today), and no patent owner is protected by an earlier favorable judgment. If a defendant receives a demand citing US 5,550,962, the correct response is not an IPR calculus at all but a Rule 11 letter and a § 285 fee-motion posture — the demand is premised on unenforceable subject matter, and the patent's status is a single USPTO-register lookup away.

Pattern signals. None to read. No repeat petitioner, no serial IPC filings, no defensive aggregator (Unified Patents or similar) in the chain, and no PTAB-appeal practice by the patent owner, because the patent owner (Hitachi, Ltd.) never faced a challenge and allowed the patent to lapse in 2008. The one downstream trace in the record is that Hitachi appears in unrelated recent patent litigation (e.g., FrameTech LLC, Elite Gaming Tech LLC, TurboCode LLC matters per the earlier search pass), but none of those matters involve this number. The patent's modern footprint is as a cited reference — it appears on the face of later graphics patents' file histories, which is the normal fate of an early parallel-graphics disclosure once it expires.

One cross-reference worth flagging. The prior-art reference US 5,321,808 A ("Dual process display server," Hewlett-Packard) cited on this patent's face is the single most likely starting point for any validity analysis if the patent were live. It is not live, so the point is academic — but it explains the patent's claim-1 framing (client-tagged parallelism control) as a deliberate distinction over a two-process display server, and anyone writing about this patent's scope should note that the differentiating feature was always the in-band control command, not parallelism per se.

---

Recommended next steps

• If you are a defendant receiving an assertion: the dispositive fact is that US 5,550,962 lapsed for non-payment of maintenance fees effective 2008-08-27. Confirm it yourself in one step at USPTO Patent Center (https://patentcenter.uspto.gov/) by pulling application 08/419,278 and reading the fee-history / Legal Events tab — the 2008-03-03 maintenance-fee reminder, 2008-08-27 lapse, 2008-09-22 discontinuation, and 2008-10-14 lapse entry should all be visible. Cite the discontinuation entry and the CFR provision rather than any aggregator's "expiration" field.
• Do not file an IPR. Beyond being unnecessary against a lapsed patent, a petition would fail at the threshold on the ground that the patent has no claims enforceable against anyone; there is nothing to cancel that is not already inert.
• If the demand comes from a party claiming to hold rights in the patent: the actual dispute is about whether the asserted claims were ever validly assigned or whether litigation is being conducted in bad faith over expired subject matter. Preserve the demand letter, the asserted claim numbers (likely claim 1 and/or claim 7), and the asserted reading, and consider a pre-motion letter rather than a merits response.
• Statutory-timeline note is inapposite here. For an active proceeding, the relevant milestones would be the institution decision (statutory 6-month target from petition filing), oral hearing, and the final written decision (statutory 1 year from institution under § 316(a)(11)). None of these apply — there is no proceeding, and none is possible.
• Bottom line, stated plainly: there is no PTAB activity on file for US 5,550,962, and the absence is not a gap in the record — it is the expected consequence of a patent that was never asserted and expired in 2008, four years before IPRs became available against pre-AIA patents. The patent has not been "hardened" by surviving challenges; it simply no longer exists as an enforceable right. If a demand letter cites US 5,550,962, it is citing a dead patent, and that is a defense that requires one register lookup rather than a PTAB petition.

Sources checked: USPTO Open Data Portal AIA trial data (as supplied); Google Patents, https://patents.google.com/patent/US5550962/en; uspto.report, https://uspto.report/patent/grant/[5,550,962](/patent/5550962); PTAB docket-aggregator records via web search; Federal Circuit public listings. No specific FWD or CAFC opinion is linked because none exists for this patent — I have deliberately not fabricated a docket number, panel, or disposition.

I'll attempt to corroborate the assignment record against the sources named in the task before writing up.

I hit the session's search-step limit before I could complete every cross-reference, so I'll flag exactly what I did and did not verify.

---

Inventors

Seven named inventors, all listed as assignors on the single recorded assignment to Hitachi, Ltd.:

Employer attribution rests on the recorded conveyance (ASSIGNMENT OF ASSIGNORS INTEREST, assignors = the seven inventors, assignee = HITACHI, LTD., JAPAN), not on an independent employment record — I did not pull personnel records.

Unusual-pattern check: none detected, but the check is weak by construction.

• No inventor appears as an assignor to anyone other than Hitachi on this patent's record, and no inventor retained a separate undivided interest (no partial-assignment reel/frame).
• The "all inventors gone within 12 months" fire-sale precursor is not assessable from assignment records alone. The only indirect datapoint is patent-count aggregation: third-party profiles index these same inventors with multi-patent Hitachi portfolios accumulating over multiple years (Nakamura ~11 patents, Sugita ~8, Koda ~7, Yamamoto ~3 — patentleaderboard.com inventor pages). Sustained hit rates at one assignee is weak circumstantial evidence of continued tenure rather than a mass exodus. Treat as inferential, low weight.

---

Original assignee

Hitachi, Ltd. (Japan). Sole assignee for the entire recorded life of the patent — Google Patents' "Current Assignee" field still reads Hitachi Ltd, with no reassignment entries.

• Primary line of business: diversified industrial/electronics conglomerate (hardware, IT systems, power/infrastructure, materials). In the 1994–1996 window this was a mainframe/workstation-era Hitachi, selling UNIX workstations and X11-capable display hardware — the exact setting the specification assumes.
• Did they ship a product embodying the claims? Unclear / not established. The specification is drafted against generic X Window System display-server architecture (X server, ThreadSet dispatcher, frame buffer 205, display 206), which is the kind of thing an X11 server vendor would ship. But nothing in the record reviewed — no product literature, no 10-K product reference, no claim chart — ties a specific Hitachi product to claims 1 or 7. I am not willing to assert product practice on inference.
• Current status: Operating. Hitachi, Ltd. is an active, publicly traded company; it is not dissolved, not in bankruptcy, and not a party to any insolvency proceeding bearing on this patent. There is no change-of-name, merger, or internal-reorganization assignment recorded against US 5,550,962, notwithstanding Hitachi's various corporate restructurings over the following decades. The patent simply stayed put.
• Patent status: expired for fee non-payment effective 2008-08-27 (37 CFR 1.362 discontinuation entered 2008-09-22). Any residual asset value is nil.

---

Assignment timeline

There is exactly one recorded assignment. Everything else in the legal-events history is fee administration, not conveyance.

• 1995-04-03 (executed) / recorded 1995-04-10 — Reel 007507 / Frame 0021
  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST)
  • Assignor: NAKAMURA, SHOUJI; KIMURA, SHINJI; SUGITA, YUMIKO; YAMAMOTO, REKI; KODA, ERIKO; KUWANA, TOSHIYUKI; MANDA, MASATO
  • Assignee: HITACHI, LTD. (Japan)
  • Correspondent: Not exposed in the record reviewed. Google Patents' legal-events rendering of this recording shows owner name, conveyance text, reel/frame and effective date, but not the correspondent-of-record field. I did not obtain the attorney/agent name from Assignment Center directly this session, so I will not name one. This is the one field the task specifically asks for and it is the one field I cannot fill from the authoritative text in hand.
  • Context: Original inventor-to-employer assignment executed a week before the US filing date (1995-04-10) and recorded the same day as filing — routine chain-of-title perfection at filing, tied to the 1994-04-13 JP priority (JP 6-074631 / JPH07282272A).

Non-assignment legal events (for completeness, not conveyances):

Contradiction carried forward from the prior section: Google Patents' "anticipated expiration 2015-04-10" is a computed 20-year-term estimate, not the operative end date. The maintenance-fee events establish 2008-08-27. This matters for the NPE analysis in one direction only: from 2008-08-27 forward the patent was unenforceable and unmaintainable, which removes any post-2008 assertion window.

Cross-reference results (what I actually got):

• Google Patents legal events: one AS entry (the 1995 recording), no ASN/reassignment rows. Consistent with a single-owner chain.
• RPX Insight (insight.rpxcorp.com/patent/US5550962A): hosts a patent page listing Hitachi as owner and status "Expired due to Fees." This is a public patent database listing, not an ownership interest — RPX holding a page for a patent is the opposite of evidence that RPX bought it. Flagging because it is the most likely misread in this fact pattern (signal 8).
• Unified Patents / RPX asserter directories: not completed — my queries were truncated by the session step limit. No Unified Patents challenge to US 5,550,962 surfaced in the partial results.
• Litigation search: no complaint, IPR/PGR, or district-court case naming US 5,550,962 surfaced. (Consistent with the prior section's finding.)
• SEC filings: no 10-K/8-K reference to this patent was located; a single mid-1990s drawing-server patent would not be a disclosable asset for a conglomerate of Hitachi's size.

---

Timeline diagram

timeline
    title Ownership of US 5550962
    1994 : JP priority application filed
    1995 : Assignment executed to Hitachi Ltd
         : US application filed
         : Assignment recorded reel 007507 frame 0021
    1996 : Patent issued to Hitachi Ltd
    2000 : Maintenance fee paid at 4 years
    2004 : Maintenance fee paid at 8 years
    2008 : Lapsed for failure to pay fees
         : No further assignment ever recorded

---

NPE / troll-pattern signals

Additional structural point that cuts against any NPE reading: by 2008-08-27 the patent had lapsed for fee non-payment, and its nominal 20-year term ran out 2015-04-10. An abandoned, term-expired patent covering a 1990s X11 drawing-server dispatcher has no licensing or assertion value — which is itself consistent with the observed absence of any downstream buyer.

---

Verdict

Insufficient data — and specifically, the "only the original assignment" case the task anticipates.

The entire recorded chain of title is a single instrument: Reel 007507/Frame 0021, executed 1995-04-03, recorded 1995-04-10, conveying all seven inventors' interest to Hitachi, Ltd. No subsequent assignment, security agreement, merger, change of name, license, or release has ever been recorded against US 5,550,962. There is therefore no shell-entity transfer, no cascading LLC chain, no repeat correspondent to trace (the correspondent field is not exposed in the source I could review), and no defensive aggregator at the end of the chain. The patent lapsed for fee non-payment effective 2008-08-27 and its term would have run out 2015-04-10 regardless, leaving nothing to assert. On these facts the NPE hypothesis has no support — but the correct label is still insufficient data, not operating-company assertion and not defensive aggregation, because a one-link chain cannot affirmatively establish any of the other categories either.

Two caveats on confidence. First, I could not query Assignment Center directly this session; the reel/frame and events above come from the authoritative record supplied plus corroborating indexes (Google Patents, uspto.report, Justia, RPX Insight, everypatent), and those indexes do not surface the correspondent of record — the single field the task most wanted. If you need it, a Patent Number = 5550962 lookup at https://assignmentcenter.uspto.gov/ will render it. Second, my Unified Patents and litigation cross-checks were cut off by the session step limit, so "no assertion found" there means not found in the queries I completed, not verified absent.

Verification link: https://assignmentcenter.uspto.gov/ (search Patent Number → 5550962; legacy mirror at https://assignment.uspto.gov/patent/index.html). Expect to see exactly one hit — application 08/419,278, reel 007507, frame 0021, Hitachi, Ltd.

I'll verify the citation record against live sources before writing the § 102 analysis.

Let me pull the cited reference's own citation record and the NPL bibliographic details.

Let me confirm the cited reference's own bibliographic details (inventors, application number).

Prior-Art Analysis — US 5,550,962 (35 U.S.C. § 102)

Sources note. I searched for the literal string 5550962 / 5,550,962 and did not substitute similar numbers (5,500,962; 5,550,692; 5,596,962 etc. are different patents and are excluded). The authoritative full text supplied in this session is the primary source; I corroborated the citation record against Google Patents renderings of the patent family and against the cited reference's own record. One clock discrepancy: your task header says 2026-04-26 while my session clock reads 2026-09-28 — immaterial to a 1994-priority patent, but flagged.

---

1. The complete § 56 citation record of US 5,550,962

This is the crux of the request, and the honest answer is short: there is exactly one (1) patent citation of record.

I want to be explicit about the trap here: the patent's record also contains a "Cited By" list of 66 documents and a "Similar Documents" list. None of these is prior art to '962. Every "Cited By" entry post-dates the '962 priority date (earliest is US 5,655,080, filed 1995-08-14, four months after the '962 filing of 1995-04-10). Direction matters: those patents cite '962 as their prior art; they cannot be cited against '962. The "Similar Documents" entries (e.g., US 5,201,049, 1993-04-06; US 4,748,846) are relevance-ranked algorithmic listings, not citations of record, and I flagged in the earlier section that I did not verify their disclosures.

---

2. Reference A — the sole patent citation (full treatment)

Full citation

US 5,321,808 A, "Dual process display server," assignee Hewlett-Packard Company (Palo Alto, CA), inventor Lawrence E. Rupp (Loveland, CO, per the EP counterpart's inventor listing — the US patent's own inventor field was not independently confirmed in this session; treat as high-confidence but flag). Application filed 1992-03-20 (US serial 07/855,188, inferred from the EP priority claim, not independently confirmed). Issued 1994-06-14.

PDF: https://patentimages.storage.googleapis.com/1a/69/5d/4a5258c6971eda/US5321808.pdf
Claim text: https://insight.rpxcorp.com/patent/US5321808A
Full text: http://www.everypatent.com/comp/pat5321808.html

Family member (not of record on '962, but the same disclosure): EP 0 561 042 A2/A3, application 92117846.3, filed 1992-10-19, priority US 855,188 of 1992-03-20, published 1993-09-22; granted as EP 0 561 042 B1 on 1999-03-10. https://patentimages.storage.googleapis.com/8b/2a/b9/a2af8d0b7f7012/EP0561042A3.pdf

Brief description

An X Window System client/server graphics system — X client program (10) on a workstation, LAN (12), display server (14) with PEX extensions, display hardware (16) (FIGS. 1A/1B). Its point of departure is that a single-process X/PEX server stalls when a long operation (PEX structure traversal, rendering) monopolizes it. The '808 answer is a dual-process server:

• First process (60) receives client requests and routes by prescribed category — dispatching requests in a first category and storing, in a first memory (66), requests in a second category, while storing associated messages in a second memory (64a).
• Second process (62) retrieves the messages, retrieves the stored requests, and dispatches them "in accordance with messages retrieved from said second memory."

It also recites the governing X execution semantics and names the very problem '962 exists to solve:

"1. Each request is considered atomic… 2. There is no implied scheduling between requests received via separate connections. 3. Requests received over a single connection are executed in the order they are received." … "Multi-threaded servers may avoid this behavior by allowing other requests to be processed while lengthy operations are occurring."

§ 102 statutory availability against '962

'962 is pre-AIA (1994 priority; 1995-04-10 U.S. filing). Section-by-section:

Operative conclusion: US 5,321,808 is § 102(e) prior art with an effective date of 1992-03-20. It is not § 102(a) or § 102(b) art on these dates. That distinction matters if anyone charts it — citing '808 as a "printed publication" or under 102(b) is a date error.

Element-by-element § 102 comparison — does '808 anticipate?

Claim 1 (independent):

The two limitations that carry the claim are missing. '808's categorization is (i) server-side, not client-originated, and (ii) functional, not temporal — the first/second "prescribed categor[ies]" distinguish core-X from PEX/queued operations (a routing split for load management), not "parallelizable" from "must-be-ordered." The "messages" the second process dispatches in accordance with are generated by the first process inside the server, not attached by the client. And '808 affirmatively states the opposite temporal rule — single-connection requests execute in the order received.

Claim 7 (independent): requires the client to attach a pair — a parallel-processing-block start command and a parallel-processing-block end command — bracketing the string. '808 discloses no client-originated bracketing command of any kind. Absent.

Dependent claims 2–6 and 8–15: each depends from claim 1 or claim 7 and therefore inherits the missing client-side control-command limitation; none can be anticipated even where the added element is disclosed. For completeness on the added elements:

§ 102 verdict on Reference A

US 5,321,808 anticipates none of claims 1–15. It is, however, the closest art of record and the natural primary reference for a § 103 combination (I set out that combination in the earlier obviousness section: Scheifler + Smith + Rupp → claims 1/7, with claim 12 the weakest point for the challenger). Its proper role in a § 102 chart is negative — it establishes what the art already had (server-side category dispatch, the single-connection ordering rule, the monopolization problem), which throws the surviving delta of '962 into sharp relief: the client-tagged, in-band parallel/sequential control command.

---

3. References B and C — the non-patent literature of record

The task says "each patent citation," and there is only one; but because these two NPL works are also prior art of record on the '962 face, I give them the identical treatment for completeness.

Reference B — Scheifler & Gettys, "The X Window System"

• Full citation: Robert W. Scheifler & Jim Gettys, "The X Window System," ACM Transactions on Graphics, Vol. 5, No. 2, pp. 78–109 (Apr. 1986). DOI 10.1145/22949.24053.
• Publication date: April 1986. § 102(b) prior art — more than one year before the 1995-04-10 U.S. filing (and before the 1994-04-13 priority).
• Description: the foundational distributed drawing system. Network-transparent client/server protocol; the server as sole intermediary for display output and input; reliable in-order duplex byte stream (TCP, DECnet) or, when client and server share a machine, shared memory. Expressly states the design philosophy — "Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands" — and the extensibility teaching: X is "extensible at both the protocol and library interfaces without requiring incompatible changes to existing applications."
• § 102 analysis: Anticipates no claim. It discloses the client, the drawing server, the communication path, and the protocol — i.e., the preamble of claims 1 and 7 — but the server is explicitly single-threaded and sequential, and there is no client-originated parallel/sequential control command. It is § 103 material (it supplies the motivation to put the parallelizability decision in the client), not § 102 material.
• Pagination caveat carried forward from the earlier section: the '962 face cites "pp. 78–109"; the article's actual pagination is 79–109. Immaterial to the analysis.

Reference C — Smith, "The Multi-Threaded X Server"

• Full citation: John Allen Smith, "The Multi-Threaded X Server," in The X Resource, Issue 1 (Jan. 1992) — the Annual Proceedings of the X Consortium's 6th Annual X Technical Conference, MIT — pp. 73–89. Ed. Adrian Nye; O'Reilly & Associates; ISBN 0-937175-96-X / 978-0-937175-96-5. Corroborating design document: MIT X Consortium MTX Component Design Specification (https://people.freedesktop.org/~ajax/mtx/cds_part1.pdf).
• Publication date: January 1992. § 102(b) prior art — more than one year before the 1995-04-10 U.S. filing.
• Description (as corroborated): replaces the X server's single thread of control with multiple flows (Main Server Thread, Client Input/Output Threads, Device Input Thread). Stated goal: "Improve interactivity by preventing long protocol requests from locking out other clients"; "allows for more efficient use of multiprocessor architectures." Explicitly targets "Support Symmetric Multi-Processing (SMP) platforms with 1 to 10 processors" and POSIX 1003.4a threads, using "mutexes and condition variables," Hoare and crowd monitors.
• § 102 analysis: Anticipates no claim. It supplies the multi-threaded/multiprocessor server and the thread-execution environment (claims 2–4, 8–11), but the threads are allocated per client and per device, not by an in-band parallel/sequential command attached to a single client's drawing string. It discloses nothing about a client declaring parallelizability. Again § 103 material, not § 102.

Note on duplicate listings: the record's "Non-Patent Citations (4)" is an artifact of the markup — it contains Scheifler and Smith each listed twice (a formatted entry and a plain-text repeat). It is two works, not four.

---

4. The reference that is not on the face of '962 but would have been § 102(b) art

EP 0 561 042 A2/A3 (Hewlett-Packard; Rupp), published 1993-09-22 — the European counterpart of US 5,321,808, claiming the same 1992-03-20 US priority and disclosing the same dual-process server. Because it published more than one year before the '962 U.S. filing date (1995-04-10), its 1993-09-22 publication date is § 102(b) art — a statutory basis unavailable to the US patent itself, whose 1994-06-14 issue date falls inside the one-year grace period. It is not a citation of record on '962, so I present it as an available-but-uncited reference, not a cited one. It shares '808's disclosure and therefore fails anticipation for the same reason.

---

5. Summary table — § 102 outcome for every reference of record

---

6. Bottom line

1. US 5,550,962 cites exactly one patent: US 5,321,808 A. Anyone asserting "the patent citations" for '962 beyond that one number is either reading the far larger "Cited By" list (which runs the wrong direction) or has pulled a different patent.
2. No reference of record anticipates any of claims 1–15 under § 102. The single novelty-bearing limitation common to both independent claims — a client-attached, in-band command (or start/end command pair) telling the server whether the following drawing-command string is parallelizable — appears in none of US 5,321,808, Scheifler & Gettys, or Smith. The prior art supplies the players (client, server, protocol, network, threads, multiprocessors) and the problem (one client's long request locking out others), but not the client-declared parallelizability signal. That element is where a § 102 case would have to be made, and it cannot be made on this record. The invalidity exposure, to the extent there was any, was always a § 103 question, as analysed in the previous section.
3. Date hygiene warning. US 5,321,808 is § 102(e) art (effective 1992-03-20), not § 102(a) or § 102(b) art — its 1994-06-14 issue date is inside the one-year grace period relative to the 1995-04-10 filing. If you need § 102(b) art with a patent-published flavour, it is the EP 0 561 042 publication of 1993-09-22, and that document is not cited on '962.
4. Materiality check. The examiner cited the closest art available (US 5,321,808 is the correct primary reference for this disclosure), and the claims issued notwithstanding it — consistent with the analysis above that the citation is § 103 fodder, not an anticipation.

7. Verification gaps (stated explicitly, per the no-fabrication rule)

• Inventor list and application serial of US 5,321,808 were not confirmed from the U.S. patent's own front page in this session. "Rupp, Lawrence E." and serial 07/855,188 are drawn from EP 0 561 042 A3 and its priority claim; treat as high-confidence-but-inferred.
• Full text of US 5,321,808 was read via its PDF, the RPX claim listing, and the EveryPatent transcription — not a Patent Center image pull. The quoted execution-semantics passage and the claim-1 dispatcher language appear consistently across those; confirm against the granted patent before filing anything.
• Smith's "Multi-Threaded X Server" was read through the confirmed X Resource Issue 1 table of contents, one scanned conference page, and the MTX Component Design Specification. The CDS is a derived MIT X Consortium document, not the paper; attribute quoted CDS language to the CDS, not to pp. 73–89, unless independently confirmed.
• I did not run a live USPTO Patent Public Search / Patent Center query in this session; the citation record above rests on the authoritative full text supplied plus corroborating Google Patents renderings. For a filing-grade record, pull the PTO-892 / "References Cited" page from the '962 file wrapper (application 08/419,278) or the IFW "Patent References Cited" tab at https://patentcenter.uspto.gov/.
• No live CAFC, PTAB or district-court document bearing on this patent was located in the prior sections, and none is needed here — but see those sections for the dispositive status point: US 5,550,962 lapsed for non-payment of maintenance fees effective 2008-08-27, so this § 102 analysis is historical/defensive only.

I'll corroborate the reference disclosures and dates before building the §103 combinations, since the stricter rule requires me to prefer live results over memory.

Obviousness Analysis — US 5,550,962 under 35 U.S.C. § 103

Building on: the Prior-Art, Litigation, PTAB, and Assignment sections already generated. I do not repeat their content. Where this section depends on their findings, it cross-references them.

Threshold note (not repeated, but dispositive of why this analysis matters): per the PTAB and Assignment sections, US 5,550,962 lapsed for non-payment of maintenance fees effective 2008-08-27 (discontinuation 2008-09-22, 37 CFR 1.362), and was never asserted. A § 103 analysis of an unenforceable patent is historical/academic — there is no live invalidity defense to win. It remains useful for understanding the patent's true scope and the strength of the 1996 grant.

A note on the two live-corpus corrections this task's strict rule requires. The live sources I re-pulled this session confirm and slightly sharpen the Prior-Art section:

• The '808 background text itself states: "Multi-threaded servers may avoid this behavior by allowing other requests to be processed while lengthy operations are occurring." That is an express acknowledgement of multi-threaded display servers inside the § 102(e) reference — a materially stronger motivation hook than the Prior-Art section captured, and I use it below. Source: http://www.everypatent.com/comp/pat5321808.html, https://patents.google.com/patent/[US5321808](/patent/US5321808).
• The EP 0 561 042 A2 family member's abstract confirms a "request dispatcher 28 and a set of dispatch tables 30 … one table for each client connection," with the dispatcher keyed to request category (X vs. PEX extension), and confirms the server is "a single thread of execution." Source: http://data.epo.org/publication-server/rest/v1.2/patents/EP0561042NWA2/document.pdf. This is the § 102(b) printed publication counterpart to '808.
• The Smith paper's existence in The X Resource, Issue 1 (January 1992), is confirmed via the volume's table of contents: "The Multi-Threaded X Server, by John Allen Smith." Source: https://www.brownsbfs.co.uk/Product/Nye-Adrian/X-Resource/9780937175965.

No live source contradicts the Prior-Art section. One new adjacent observation: the US 5,819,077 record (a Hitachi patent in '962's "Cited By" trail) carries non-patent citations to Nishimoto et al, "PEX: A Network Transparent 3D Graphics System," IEEE, pp. 14–26 and Kubitz et al, "A Critical Evaluation of PEX," IEEE 1990, pp. 65–75 (https://patents.google.com/patent/US5819077). Those works are not cited on the face of '962, so I exclude them from the combinations below — but they are the kind of X/PEX architectural art a real challenger would have added, and I flag them in § 8.

---

1. Legal framework and the operative date

• Pre-AIA § 103(a) governs. '962 has a 1994-04-13 JP priority and a 1995-04-10 US filing; the AIA's § 103 (effective 2013-03-16) does not apply. The test is Graham v. John Deere: scope/content of the prior art, differences between art and claims, PHOSITA level, and secondary considerations. KSR Int'l v. Teleflex governs the motivation analysis: a combination is obvious where (a) prior elements are combined by known methods to yield predictable results, (b) a known technique is substituted to improve similar devices, (c) a known technique is applied to improve a like device in the same way, or (d) the change is "obvious to try" over a finite number of identified, predictable solutions.
• The claim text controls literally. Per the earlier section's transcription note, claim 7 opens "A drawing processing system compromising:" and claim 8 says "until said dispatch accepts…" — I carry those verbatim and construe them as the ordinary artisan would (i.e., "comprising"/"dispatcher"), without normalizing the granted text.

---

2. Level of ordinary skill in the art (PHOSITA)

Not disputed by any reference; defined for the motivation analysis:

A PHOSITA in April 1994 would hold a B.S. in computer science or electrical engineering (or equivalent) plus roughly two years of experience in graphics/window-system programming, or a lower degree with commensurate experience. That artisan would be familiar with:

• the X Window System client/server protocol and its network-transparent request stream (Scheifler & Gettys);
• display-server internals, including request dispatchers and dispatch tables (US 5,321,808 / EP 0 561 042 A2);
• multi-threaded server design in the X environment (Smith, "The Multi-Threaded X Server");
• the fact that X execution semantics require requests over one connection to be executed in order ("requests received over a single connection are executed in the order they are received").

This level matters because the entire § 103 question is whether adding a client-emitted control token to an otherwise-known multi-threaded display server was within the ordinary skill level. It is a protocol-design change, not a new hardware or algorithmic invention.

---

3. Claim construction of the two limitations that decide the case

Claims 7's pair of start/end commands is the concrete (bracketed) species of claim 1's genus. Claims 2–6 and 8–15 add: plural drawing threads + allocating dispatcher (2, 8); parallel vs. sequential dispatcher routines (9, 13); plural processors (3, 10); bus-connected distribution (4, 11); same-processor (5, 14); network separation (6, 15); and — the most specific — a sequential block nested inside a parallel block, with the whole span still run as one parallel block (12).

Critical finding, consistent with the Prior-Art section: the client-attached parallel/sequential indicator — the single element that distinguishes both independent claims from all cited art — is not disclosed by any reference in '962's record. Everything else in claims 1 and 7 is disclosed. The § 103 case therefore rises or falls on motivation and predictability, not on element coverage.

---

4. Combination 1 — US 5,321,808 + Smith, "The Multi-Threaded X Server" (primary combination)

What each reference supplies (not repeating the Prior-Art section's full descriptions):

Motivation to combine — the strong grounds:

1. Express incorporation-by-acknowledgement. US 5,321,808's own specification recites that "Multi-threaded servers may avoid this behavior by allowing other requests to be processed while lengthy operations are occurring." The § 102(e) reference thus names Smith's solution and endorses it for exactly the problem '808 addresses (a lengthy PEX/render request monopolizing a single-threaded server). Combining them is not a hindsight reconstruction — it is what the earlier reference tells the artisan to do. This is a KSR rationale (b) ("known technique to improve similar devices") with the motivation stated in the art itself.

2. Same field, same problem, same architecture. Both references are X-Window display-server art; both concern dispatch of client drawing/request streams to a display; both use dispatchers and shared state. The field of endeavor and the problem to be solved are identical.

3. Predictable result. Putting Smith's per-client threads into '808's multi-process, dispatcher-based server yields a multi-threaded display server — the predictable aggregation of two known dispatching mechanisms. Claims 2, 8, 9, 10, 11 read directly on this aggregate.

4. '808 itself frames the ordering constraint as the hurdle. Because '808 teaches that "requests received over a single connection are executed in the order they are received," the artisan combining '808 with Smith immediately confronts the only remaining obstacle to intra-client parallelism: preserving order where it matters. The references thereby set up the problem '962 claims to solve.

Where Combination 1 falls short: it does not reach claims 1 or 7, because neither reference (nor their combination) puts the parallel/sequential decision in the client's hands as an in-band command. '808 keys dispatch on request category (X vs. PEX); Smith keys threading on client identity. Neither keys anything on a client-declared parallelizability flag for the subsequent string. Combination 1 is therefore a § 103 case against claims 2–6 and 8–11, and against claim 9's dispatcher-pair architecture, but not against the independent claims.

---

5. Combination 2 — US 5,321,808 + Smith + Scheifler & Gettys (the full § 103 case against claims 1 and 7)

To reach the independent claims, the third reference supplies the client-side protocol machinery.

What Scheifler & Gettys add: the foundational X client/server model — a client application formats X protocol request packets and transmits them to a server that executes drawing requests for a display, over a network-transparent connection. The artisan is thus taught that the client originates the request stream, including control requests, and that the protocol is extensible (X extensions exist as a matter of course).

The complete motivation chain:

• Step 1 (from '808 + Smith): build a multi-threaded X display server so that lengthy drawing work does not monopolize the server. Result: parallel execution across clients.
• Step 2 (problem recognized from '808): the reason a single client's stream cannot simply be parallelized is the ordering rule — "requests received over a single connection are executed in the order they are received" — and the concrete failure '962 later illustrates in FIG. 13 (blue square drawn, then red circle overtaking it, so the square vanishes in the overlap).
• Step 3 (the ordinary-skill insight): the client application, not the server, knows which of its own drawing commands are order-independent (two unrelated window fills vs. a square layered over a circle). It is therefore the natural place to make the parallel/sequential determination. This is the exact reasoning '962's own specification states as its justification — "the parallel processing block is added on the client side because parallel processability can be more easily judged by the client rather than by the drawing server." A statement of design rationale in the specification that amounts to "the client is the convenient place to do this" is, by itself, evidence that the placement was an ordinary design choice, not an inventive insight.
• Step 4 (the mechanism, from Scheifler & Gettys): the X protocol already carries client-originated control requests. Adding a control request/marker that says "the following N commands are order-independent" is the simple substitution of a known technique (in-band protocol token) to improve the server's throughput in the same way — KSR rationale (c). The server side is already a dispatcher ('808) with threads (Smith); routing on a new token requires only a new branch in existing dispatch logic, a predictable implementation with a reasonable expectation of success.

KSR rationales squarely engaged:

• (a) combining '808's dispatcher + Smith's threads by known methods → predictable multi-threaded server;
• (b)/(c) applying the known in-band protocol-token technique (Scheifler & Gettys) to that server to designate parallelizable regions → predictable improvement;
• (d) "obvious to try": the design space of where to put the parallelizability determination is small (client vs. server) and the references themselves point to the client, producing a finite, identified, predictable set of solutions.

Result: under this combination, claim 1 (a single control command indicating parallel/sequential) and claim 7 (a start/end pair bracketing the string) are reasonably argued obvious, with the strongest sub-argument for claim 7's pair being that the artisan's natural implementation of a client-declared region is a bracket — a "begin/end" token pair — which is the standard idiom for delimiting a region in a protocol stream.

---

6. Claim-by-claim mapping

Net: a well-constructed petition or § 103 defense would attack claims 1 and 7 (and thus all dependents) on the Combination-2 motivation; as a fallback, claims 2–6 and 8–11, 13–15 are individually weak on Combination 1 alone, and claim 12 is the claim most likely to survive a § 103 challenge on this record.

---

7. Counterarguments the patent owner would raise (and how they fare)

1. "No reference teaches a client-declared parallel-processing marker." Accurate on the record — this is the genuine gap (flagged in § 3 and in the Prior-Art section). But under KSR, the absence of an express teaching of the placement does not defeat obviousness where the placement is a predictable design choice the art itself points to (the client knows its own semantics). This argument is strong as a § 102 argument and moderate-weak as a § 103 argument.

2. "'808 teaches away: it blocks the client to preserve in-order execution." Partially persuasive. '808's blocking is a performance concession — it exists precisely because ('808 admits) the single-threaded server can't do better; and '808 in the same breath endorses multi-threaded servers. Blocking to preserve order is not a disparagement of intra-client parallelism so much as a workaround for its absence. A teaching-away argument would need more than '808's ordering rule; the rule states a constraint to satisfy, not a mandate against satisfying it via parallelism.

3. "Smith parallelizes across different clients only — '962's specification says intra-client parallelism is the gap." Accurate but self-defeating. The specification frames the gap as the problem, which is exactly what a § 103 analysis requires the art to have identified. The motivation to close an identified gap by an ordinary protocol mechanism is the KSR "obvious to try" scenario.

4. "Secondary considerations." There is no evidence of record of unexpected results, long-felt-but-unmet need, industry praise, copying, or commercial success with a nexus to claims 1/7. Specifically:

   • The long-felt need is argued in the specification itself (the X server monopolization problem), which cuts against the patentee — a need the art already recognized and was addressing (Smith; '808's multi-threaded-server remark).
   • No licensing or product evidence exists (per the Assignment/NPE sections: single 1995 assignment to Hitachi, no subsequent transfers, no product tie).
   • Silence on secondary considerations is the norm for a never-asserted patent and here weighs against non-obviousness rather than in favor.
     Caveat: I did not retrieve the original prosecution file wrapper, so I cannot report whether the applicant made any unexpected-results argument during prosecution. Absence of evidence is not proof of absence; treat this as "not located," not "verified none."

---

8. Thinness of the record — and what a real challenger would add

The § 103 case above is built entirely from the single patent citation plus two NPL references on '962's face. That record is unusually sparse. The Prior-Art section already established there is exactly one patent citation (US 5,321,808). For completeness:

• Additional art a live challenge would have located but which is not in this record: the X/PEX architectural literature surfacing in the adjacent Hitachi US 5,819,077 record — Nishimoto et al, "PEX: A Network Transparent 3D Graphics System" (IEEE, pp. 14–26) and Kubitz et al, "A Critical Evaluation of PEX" (IEEE 1990, pp. 65–75) (https://patents.google.com/patent/US5819077). These are not § 102 art against '962 on the citations of record, and I do not fold them into the combinations above; I flag them only to note that the motivation story for a multi-threaded, dispatcher-based X server was well populated in the 1990–1992 literature. A petitioner would very likely have supplemented the record with them.
• JP counterpart: JPH07282272A (published 1995-10-27) is '962's own family member, not prior art; it is nonetheless relevant if one wants the examiner's treatment of the same disclosure in the JP prosecution (not retrieved this session).

---

9. Bottom line

1. No anticipatory reference exists. Consistent with the Prior-Art section, no reference — alone or in the record — discloses the client-attached parallel/sequential control command of claim 1 or the start/end pair of claim 7. § 102 fails on both independent claims.

2. The strongest § 103 theory is US 5,321,808 + Smith + Scheifler & Gettys. '808 supplies the dispatcher architecture and — decisively — the reference's own endorsement of multi-threaded servers; Smith supplies per-client drawing threads; Scheifler & Gettys supply the client-originated, extensible X protocol into which a parallelizability marker is a natural insertion. The motivation for that insertion is that the client, not the server, knows which drawing commands are order-independent — a rationale '962's own specification states.

3. Claims 1 and 7 are arguable as obvious but not clearly so — the missing element (client-declared parallelizability) is genuine, and the case depends on KSR-style reasoning about the location of an otherwise-known decision. Assessed fairly: moderate, not strong. Claims 2–6 and 8–11, 13–15 fall readily on Combination 1; claim 12 is the strongest claim and would likely survive.

4. Secondary considerations are absent from the record and do not rescue the patent.

5. All of this is academic. Per the PTAB and Assignment sections, '962 expired for fee non-payment on 2008-08-27 and has no enforceable claims. The § 103 question is a historical assessment of the 1996 grant's strength, not a live defense. Anyone weighing the patent's significance should treat it as an early, moderately-supported disclosure of client-declared parallel regions in a drawing command stream — a concept whose novelty at the time lay in the placement of the decision, and whose patentability under § 103 is, on this record, defensible but not robust.

---

Sources relied on this session (live re-checks): US 5,321,808 https://patents.google.com/patent/US5321808 and http://www.everypatent.com/comp/pat5321808.html; EP 0 561 042 A2/A3 http://data.epo.org/publication-server/rest/v1.2/patents/EP0561042NWA2/document.pdf and https://patentimages.storage.googleapis.com/8b/2a/b9/a2af8d0b7f7012/EP0561042A3.pdf; Smith, "The Multi-Threaded X Server," The X Resource Issue 1 (Jan. 1992) TOC https://www.brownsbfs.co.uk/Product/Nye-Adrian/X-Resource/9780937175965; US 5,819,077 (adjacent-citation context) https://patents.google.com/patent/US5819077. Claim text and citation inventory per the authoritative '962 record: https://patents.google.com/patent/US5550962/en.

Caveats I am deliberately preserving rather than papering over: (a) the court/PHOSITA-standard framing would in practice be set in litigation, which does not exist here; (b) the prosecution file wrapper (Form PTO-892, office actions, any applicant arguments) was not retrieved this session, so the examiner's stated § 102-vs-§ 103 treatment of US 5,321,808 is reported from the citation record, not the file history; (c) the two X/PEX IEEE references are not on '962's face and are excluded from the combinations — they are identified only as likely supplementary art, not applied.