Opus 5 vs Qwen 3.8 on a 5090: re-fighting Apple's dead pinch-to-zoom patent
While writing this I listened to another work on repeat: Beethoven's Violin Sonata No. 9, the "Kreutzer" - Martha Argerich again, this time not with Kremer but with Vadim Repin. The third movement fits this post: it is itself a fight between violin and piano, on equal terms. The second is the calmer companion while you read (Apple Music · Spotify). And if you have fifteen spare minutes - who has those - close your eyes and start with the first; I find this recording one of the best. The work does not open up easily. I had to listen to it many times before I learned to love it.
This post reports one experiment with several comparisons in it. Apple's "pinch to zoom" patent against a touch-table patent from 2005. A deskside RTX 5090 running Qwen3.8 against Claude Opus 5. A self-hosted stack against a hosted one. And both machines against the examiner and judges who actually decided the case. The case's outcome is public record, down to the signed reexamination certificate, so every analysis below can be graded against what actually happened. (In a hurry? The honest answer is at the end)
The case
US 7,844,915 is popularly called the Apple pinch-to-zoom patent. The name is imprecise: independent claim 1 is a method claim on the heuristic that interprets one input point on a touch display as a scroll and two or more as a gesture. The prior art in this test is US 7,724,242 (Hillis), a touch-table patent filed in November 2005: one finger pans the displayed imagery, two separating fingertips zoom it, with simulated inertia and friction after lift-off.
The models were not told that this dispute is already over. A third-party ex parte reexamination requested in May 2012 (control no. 90/012,332) ran until 2020 - examiner rejections, two Board decisions, one Federal Circuit appeal, a remand - and ended in a certificate whose operative text is one line: "Claims 1-21 are cancelled." No claim survived, none was amended into allowability. That record is the answer key for this test: given only the patent, the prior art and the retrieval tools, does a model identify the grounds on which the claims actually fell?
The setup, briefly
Both models reached the live patent offices through the same tool server, my Patent Connector, which I build and sell, so both worked from the same sources through the same tools. You can run this three ways: everything hosted; your own tooling server with a frontier model on top (accounts, office credentials and the research trail stay on your infrastructure - the setup I see growing fastest); or everything on your own hardware, which is the configuration this post tests. Fully local is the configuration I get asked about most, and the short version is: the quality is closer than I expected, and a single 5090 is sized for one practitioner rather than a firm - one request occupies the whole card, so concurrent users queue; more or bigger cards change that, which is a question of budget.
The machine: Qwen3.8 27B at 6-bit quantization, 60-70 tokens per second, 64k token context, entirely in GPU memory. One reproducibility note: local model quality depends on serving configuration in non-obvious ways. Example: the temperature control in the chat front end never reaches the model on Ollama's OpenAI-compatible API, so sampling parameters must be set in the model file itself. In my experience, a local model that seems weaker than its benchmarks has a configuration problem more often than a capability one.
The test
The test has two phases. Phase one is blind analysis: assess the validity of the '915 independent claims over Hillis using only the connected tools. Web search off, and an explicit instruction not to consult reexamination, PTAB or litigation records. The instruction can be verified: every tool call is logged, and all six runs - three per model, each in a fresh chat - stayed within it. Claude ran at medium reasoning effort to bring per-run thinking time into the same range: three to four minutes for Claude, about two for Qwen. Phase two is disclosure: retrieve the actual reexamination file through the connector and compare the phase-one analysis with the examiner's.
A disclaimer: the prompt is not how a patent professional would brief a validity question. It is a test fixture - just enough instruction to require element-by-element claim charts, a claim-construction discussion and the relevant tool calls. It also hands the models the decisive reference: Hillis is the reference the reexamination's lead ground used, so prior-art searching was not part of the test. A real engagement would start from a better question and a longer, written method - more on that below.
What both models found
All six runs, both models, independently identified the same structure - and it is the structure the reexamination's lead ground in fact rests on. The '915 independent claims differ from Hillis's disclosure only in software-architecture terms: "creating an event object", "issuing a scroll or gesture call", "a window having a view", plus one further limitation in claim 1 ("the scroll stopped at a predetermined position in relation to the user input"). Under the broadest reasonable interpretation applied in examination, each of those terms reads on what Hillis discloses - an "event object" on Hillis's stored per-contact record of position, size, shape and timing; a "call" on Hillis initiating the identified action; the "window having a view" on the displayed imagery, using the '915 specification's own definition of a window as possibly the entire display. On that construction, Hillis discloses every limitation and the claims are anticipated. Under the narrower construction applied in litigation (Phillips), the same terms require an object-oriented event-dispatch architecture that Hillis nowhere describes; anticipation fails, and a challenge has to proceed as obviousness, supplying the event-dispatch layer from a secondary reference. Every run produced this fork, with claim charts quoting both documents.
The models differed in what they concluded from it. Claude concluded, in all three runs: all three independent claims likely invalid; claim 8 the weakest, because it lacks claim 1's stop-position limitation and its preamble matches Hillis's own storage-media claim; and, in one run, the strategic summary that the patentee has no good construction available - the broad construction loses to anticipation, the narrow one to obviousness. One Claude run additionally checked the citation record and found that Hillis had never been before the original examiner; searched out and quoted two candidate secondary references for the event-dispatch layer; and rejected Apple's own Hotelling application as a secondary reference because commonly owned 102(e) art was disqualified from obviousness combinations under pre-AIA 103(c).
The local Qwen produced the same fork and materially weaker conclusions. In two of three runs it concluded claim 1 "likely not invalid" on the narrow construction - in one run stating "likely NOT invalid" directly above its own estimate of roughly 55% probability of invalidity - and its obviousness combinations named no specific secondary reference, only "conventional event-driven GUI architecture".
What the record says
Phase two: retrieve the file and compare. The certificate cancels claims 1-21. The final rejection of July 2013 adopted six grounds. Ground 1, covering every independent claim: anticipation under 102(e) by Hillis alone - the theory most runs had ranked second. Grounds 2 and 3 added Lira and Makus against dependent claims. Grounds 4-6 were a complete, independent set over Nomura (a Japanese publication from 2000) in view of Rubine (a 1991 CMU technical report on gesture recognition whose event objects are literally objects of a class) - two references neither model surfaced, covering the same claims without relying on Hillis at all.
And the dispute over the independent claims that ran through two Board decisions and the Federal Circuit concerned none of the limitations the models treated as weak points. It was claim construction on the "distinguishing" step: Apple argued, with expert declarations, that "distinguishing between a single input point... and two or more input points" requires discriminating one from more-than-one, so that a reference handling exactly two fingers does not meet it. The examiner read "two or more" as a disjunctive list - two suffices - the Board agreed under the broadest reasonable interpretation, and the Federal Circuit affirmed that construction in In re Apple (2017). On that construction Hillis's one-finger pan and two-finger zoom meet the limitation, and the independent claims stand anticipated.
Every run, both models, had concluded this limitation was met - a few noted that Hillis never expressly recites counting contact points and called it inherent - and located the risk elsewhere. The models analyzed the claims the way an engineer reads a specification, looking for the technically thinnest disclosure. The case was decided on the construction of the claim language.
Which also addresses the objection a careful reader should raise: this is a famous case - is it simply in the training data? The blind protocol controls what the models could retrieve, not what they might remember, and the appellate decisions are published, so memorization cannot be excluded. But a model reproducing the record would have led with anticipation over Hillis alone, named the Nomura-Rubine grounds, and known the "two or more" construction dispute - the central holding of the documents it would be remembering. Across six runs: one filed anticipation first and still called obviousness the stronger theory, none named Nomura or Rubine, none identified the construction dispute, and the local model twice concluded not invalid. The errors themselves are the strongest evidence available here that the reasoning was worked out rather than remembered.
Claude's own post-disclosure audit of its phase-one work: "I priced three claims as materially different risks when they were one risk." And on the procedural posture it had underweighted - a granted reexamination, requested by a well-resourced litigant, on a reference the original examiner never saw, aimed at the exact limitation that had supported allowance: "that fact pattern does not resolve at 55%."
The examiner also made an argument neither model constructed. Beyond construing the disputed terms, he read the '915 specification for what it does not contain: no algorithm for the "distinguishing" step, and not the word "distinguishing" anywhere in the description. A claim limitation cannot be read to require a specific mechanism the specification never describes. Both models quoted that specification at length; neither noticed the absence.
Could the models have done better with better instructions? Probably. The connector serves the examination manuals - the MPEP among them - as tools; nothing in the prompt directed the models to consult them, and none did. That fix is one added line. So is "check disjunctive claim language". So is "weight the base rate of granted reexaminations". Each lesson from this test adds a line, and the sum of those lines is a description of a patent professional's training. The models execute a written method well. Someone still has to know the method, write it down, and review the run where it fails.
Where the small local stack breaks
Phase two separated the stacks, and not on analysis quality. Claude read the scanned record of the eight-year proceeding end to end, three times, and reconstructed the same six grounds each time. The local box could not begin the task, and a controlled two-page probe isolated why - two independent failures, neither in the model. First: the front ends. Onyx (4.6.1) removes image content from tool results before the model sees it; Qwen accordingly reported that it could not see the pages - correctly, rather than confabulating. AnythingLLM (1.16) passes the images through, but encoded as base64 text in the prompt: two scanned pages became 187,000 text tokens, and the model's vision encoder never received an image. No hardware upgrade fixes this; larger context would let the base64 fit without making it readable. It is a software defect in the front ends. Second: capacity. Even without images, a long prosecution record exceeds a 64k window. That is a sizing decision - the same model handles several times that context given the VRAM, meaning a larger or a second card. On the single-5090 configuration tested here, "read the whole record and summarize the grounds" is a frontier-model capability. Once a front end passes images through correctly, what remains is capacity - and capacity is a matter of buying hardware.
The honest answer
Can a deskside machine do serious patent analysis? On this evidence, yes, with stated limits. Working blind from the retrieved text, it produced verbatim element-by-element claim charts, identified that the case turns on claim construction, stated correctly what each construction does to anticipation and obviousness, and did not fabricate anything it could not see. The scanned record is where it broke, for the reasons above. Three things still separate it from the hosted stack: consistency of judgment at the decision point (the local model contradicted its own probability estimate twice; Claude's conclusions were stable across all runs); unprompted verification work (citation-record checks, named secondary references, the 103(c) exclusion); and context capacity for record-heavy work. The first two may narrow with better prompting; the third takes bigger hardware, or working through the record a few pages at a time.
And one limit is shared: neither model identified the construction dispute that decided the real case. The examiner did. Whatever else changes as these models improve, the conclusion of this test is that the reviewing professional is not a stopgap: the only participant who identified the argument the case actually turned on was a human.
Method, briefly
Blind two-phase protocol, 2026-08-23, Patent Connector 1.10.0 on both stacks. Local: Qwen3.8 27B (qwen3.8:27b-q6_K) at 64k context on one RTX 5090, Onyx front end; sampling fixed in the model file (temperature 0.6, top_p 0.95, top_k 20). Frontier: Claude Opus 5 on claude.ai at medium reasoning effort, web search off. Three fresh-chat runs per model in phase one; three phase-two runs for Claude, one attempted for the local stack. Compliance with the retrieval restriction verified from the tool-call logs. Grading: a fixed rubric applied against the record itself - the certificate and the adopted rejection grounds, retrieved and read through the same tools under test. Phase two on the local stack terminated on context overflow (~123k tokens required against ~58k available after prompt overhead); the two planned repeats were skipped because the record cannot fit the configured window regardless of sampling. Reported as a finding, not excluded. Raw transcripts, scorecard and probe logs are available on request.
