“What goes on in your mind?” — The Velvet Underground

The USPTO’s Open Data Portal API covers a lot of ground — trademarks, patent examination data, maintenance fees, and more. This post covers one slice: the appeals, trials, and interferences endpoints, which return decisions from the Patent Trial and Appeal Board (formerly the Board of Patent Appeals and Interferences (BPAI)). Making sense of that data means knowing what it means, or at least what it relates to. Here’s the quick primer.

The Board runs several different kinds of proceedings, some of which no longer exist. An applicant’s ex parte appeal of the examiner’s rejection has a different procedural origin from a competitor’s attempt to kill an issued patent through inter partes review, even though both end up before the same Board. Confusingly, two of those proceeding types — inter partes review and inter partes reexamination — share half their name while being procedurally almost nothing alike. I memorized this taxonomy for the patent bar exam the way you memorize anything for a multiple-choice test — a list of names and deadlines with no weight behind them. It didn’t become real until I started practicing and looking at the data: who can bring each one, who decides it, and whether it’s still available.

The short version:

##The Applicant’s Appeal

Ex parte appeal happens when an applicant formally appeals the examiner’s rejection to the Board itself. Ex parte here means the only two parties are the applicant and the examiner, with no adverse third party — not that the rejection goes uncontested. The Board affirms, reverses, affirms in part, or remands. You can file petitions, for example to challenge an examiner’s premature final rejection. Some can toll a deadline, too: if the examiner’s answer contains an undesignated new ground of rejection, a petition to have it designated as new tolls the reply-brief period under § 41.40 of title 37 of the Code of Federal Regulations. You have to file that § 1.181 petition within two months of entry of the answer and before filing any reply brief. A losing party can optionally request rehearing, then appeal to the Federal Circuit or file a civil action under 35 U.S.C. § 145.

##When Two Applicants Claim the Same Invention

Interference is the old mechanism for resolving a dispute over who invented something first, when two parties separately claim substantially the same invention. It only makes sense under a first-to-invent system, which the United States abandoned for applications with an effective filing date on or after March 16, 2013. Older applications can still theoretically interfere with each other — an interference can run for years — but the population of eligible cases keeps shrinking toward zero and won’t come back.

Derivation proceeding is the replacement created by the America Invents Act (AIA), and it asks a completely different question. Under first-inventor-to-file (FITF), priority isn’t about who invented first anymore — it’s about whether the first person to file stole the invention from someone else. A derivation petitioner has to be an applicant or patent owner with a competing claim to the same invention, and has to allege the earlier filer derived it from them without authorization. Mere earlier invention isn’t a derivation theory; it isn’t a theory at all anymore. Derivation is also genuinely rare, with single digits filed most years and some years none at all.

Neither of these is a validity challenge in the sense a competitor cares about. Both are inventorship-priority fights between people who each think the patent (or application) should belong to them.

##The AIA Trials, and Who’s Actually Allowed to Bring One

The America Invents Act created a new adjudicative animal on September 16, 2012: trial proceedings decided directly by administrative patent judges, not examiners, with discovery, expert testimony, and oral argument. Three of the four types are genuine third-party validity challenges, and each one has a different, specific answer to “who can bring this.”

Inter partes review (IPR) — anyone except the patent owner can petition, on novelty or obviousness grounds only (§ 102 or § 103), based only on patents and printed publications. Timing has real teeth: you can’t file until nine months after grant (or after any post-grant review on the same patent wraps up), and you’re barred if you were served with a complaint alleging infringement of that patent more than a year before you file (35 U.S.C. § 315(b)). You’re also barred if you already filed a declaratory judgment (DJ) action challenging the patent’s validity before petitioning — a counterclaim doesn’t count against you, but a first-filed DJ action does. You have to disclose real-party-in-interest and privity, specifically so a company can’t dodge the time bar or estoppel by routing the petition through a shell.

Post-grant review (PGR) has a much narrower filing window — nine months from grant or reissue, full stop — but much broader grounds: any invalidity theory except best mode, including § 101 and § 112, not just patents and publications. The catch is eligibility, not timing: PGR is only available for patents examined under first-inventor-to-file, meaning patents with an effective filing date on or after March 16, 2013. That’s why PGR petition volume has always trailed IPR by orders of magnitude — for years after AIA trials opened, there simply weren’t many FITF patents to challenge yet.

Covered business method review (CBM) doesn’t exist anymore. It was a transitional program under AIA § 18 with an eight-year sunset built into the statute itself, and it expired on September 16, 2020. While it was alive, it had the strictest standing requirement of any AIA trial: the patent had to claim a “covered business method” (financial-product-or-service-related, excluding anything that qualified as a “technological invention,” a carve-out that generated its own body of litigation about where the line sat), and — unlike IPR or PGR — the petitioner had to have actually been sued or charged with infringement of that specific patent. You couldn’t pre-emptively challenge a CBM patent the way you can with IPR. You had to already be in a real fight over it.

Derivation also counts as one of the four AIA trial types, even though — as covered above — it isn’t a validity challenge at all.

##The Other Reexam: Why “Review” and “Re-exam” Aren’t the Same Word Twice

Inter partes review and inter partes reexamination share a name and almost nothing else, and I think the naming similarity is the single biggest source of confusion in this whole area.

Inter partes reexamination was created by the American Inventors Protection Act of 1999, available for requests filed between November 29, 1999, and September 15, 2012 — a hard cutoff, not a phase-out, though requests already pending on that date kept running under the old rules for years afterward. The grounds are the same as IPR would later adopt — patents and printed publications only — and a third-party requester stays involved throughout the proceeding, which is what makes it inter partes. But procedurally, it’s an examination: it runs in front of an examiner in the Central Reexamination Unit, not administrative patent judges, and it’s appealable to the Board the same way an ordinary prosecution rejection is. IPR is inter partes reexamination’s direct doctrinal successor — same requester eligibility concept, same evidentiary scope — redesigned as a trial decided by the Board itself from day one, instead of an examination that merely ends up at the Board on appeal.

Ex parte reexamination is older still — it’s existed since 1981 and, unlike inter partes reexam, it’s still available today. Anyone can request one, including the patent owner, and the requester can stay anonymous. But once the reexamination starts, a third-party requester is cut out of further participation. There’s no adversary left in the room after that point, which is the ex parte half of the name.

Both reexam types get their own control-number series distinct from ordinary application numbers: 90-series for ex parte reexam, 95-series for inter partes reexam, and a 96-series added later for reexaminations ordered out of supplemental examination proceedings under 35 U.S.C. § 257. If you ever see one of those control numbers in what looks like an ordinary appeal record, that’s why.

##BPAI to PTAB Is a Rename

The Board of Patent Appeals and Interferences (BPAI) existed from 1982, when the Federal Courts Improvement Act merged the old Board of Appeals and Board of Patent Interferences, until September 15, 2012. It heard ex parte appeals, interferences, and — starting in 1999 — inter partes reexamination appeals.

On September 16, 2012, the AIA renamed and reconstituted it as the Patent Trial and Appeal Board (PTAB). Same institution, continuous jurisdiction over ex parte appeals and interferences, plus the brand-new original trial jurisdiction over IPR, PGR, CBM, and derivation. “BPAI decision” and “PTAB decision” describe the same body across a name change, with September 16, 2012 as the real dividing line for what kind of new proceeding could be filed on any given day.

While reviewing old automation, I checked how the USPTO Open Data Portal handles API-key rotation. Account holders rotate keys during scheduled maintenance, after rebuilding an application, when operators change, or after a possible leak. A routine rotation has three steps: create a replacement key, update the application, and deactivate the old key.

The USPTO, however, requires an email to be sent. Its FAQ says:

Can I have multiple API keys with one ID.me account?

No. The ID.me account integration with your USPTO.gov account is a one-to-one connection. You can only integrate your ID.me account into one USPTO.gov account. If you need to replace your API Key, email data@uspto.gov a request for a new API Key https://help.id.me/hc/en-us/articles/4412245504407-USPTO-and-ID-me on your personal Manage API Key page.

The portal includes a self-service control for deactivating the current key.

##Problem

ID.me links one human identity to one USPTO.gov account. The FAQ treats that identity link as a reason to limit the user to one API key. Several applications may depend on the same account, and each application may require independent key rotation or deactivation. The one-key policy and email-only replacement process are crazy.

The one-key policy forces a choice between failed requests and continued use of a possibly leaked key. Deactivating the current key immediately causes authenticated requests to fail until the USPTO issues a replacement key and the user installs the new key. Keeping the current key active avoids failed requests while leaving the possibly leaked credential usable. The FAQ gives no turnaround time for a replacement request.

The email-only replacement process discourages routine rotation. Leaving the current key alone avoids administrative delay and failed requests. The path of least resistance is to keep using the same credential until a suspected compromise forces a change.

##Solution

The portal should let users create multiple named keys and show each key’s creation date, last use, and expiration date. Overlapping keys let users update each application before deactivating the old key.

##Closing

On July 23, the USPTO announced a new homepage design. The director praised the “extensive time and effort” spent improving navigation. I’m glad the USPTO got its fancy new splash page. I would trade a little of that effort for a Create replacement key button.

Recent advances in free and open-source (FOSS) software distribution have made it possible to build interesting things that would have been significantly harder even a year ago, using a set of FOSS subcomponents that are greater together than the sum of their respective parts:

• model-agnostic open agent harnesses (e.g., OpenCode, pi);
• agent memory extensions (e.g., beads);
• portable skill files and prompt assets (e.g., agentskills);
• versioning and filesystem-backed workspace organization (e.g., Git)
• intermediate text representations with rendering and export (e.g., TeX, docx, html, pdf, png, etc.);
• terminal-native workflows (e.g., tmux, vim, emacs, etc.).

Taken individually, these are just software methodologies/packages. However, wired together, they transform into a powerful software substrate for knowledge work that is unlike anything previously available.¹

As a shorthand, I’m calling the pattern used to build this system the MAVENS (Memory, Agent, Versioned, Exportable, ruNtime, Skills) stack.² The MAVENS stack is a new paradigm in software development, and it represents a clear path to unlocking value in knowledge work not only in patent practice, but across many other domains.

maven (noun): expert or person of skill; from Yiddish meyvn, from Hebrew mevin (מבין), “one who understands.”

One of the biggest wins of the MAVENS stack, and one that cannot be emphasized enough, is that the FOSS constituent parts are community-maintained, which allows the knowledge worker (e.g., patent practitioner) to focus on improving the things that matter to the knowledge worker (the runtime, skills and their outputs). The FOSS parts are essential, but they are like the machinist’s caliper or the electrician’s multimeter–generic tools that Just Work.

The next biggest win is that the open agent harness+memory can be used separately to improve the MAVENS stack itself, leading to a self-improvement feedback loop. For example, a client recently gave me a bucket of TeX as a disclosure, including pages of formulas that would have taken weeks to transcribe by hand, and which would have been error-prone in any event. I was able to extend my MAVENS stack to include a TeX-archive import feature, and map it onto the runtime. This code is completely reusable.

In another case, a colleague sent me a set of figures that did not have reference numerals. I quickly extended my MAVENS stack to add them in programmatically based on the existing figure numbering and, optionally, the content of an associated specification. This was done in minutes, and is a tool that can be used in perpetuity. There are many much more exotic examples of this type of work, all represented using the MAVENS software architecture.

The step change here is not the ability to work with TeX from inventors to preserve math fidelity, or do image generation/ processing, or any of the other myriad things the software can do. Those are just examples. The leap in capabilities comes from the combination of the components, that enable the MAVENS stack itself to be modified and improved, while it is being used.

##Confidentiality and Privacy and Governance, Oh my!

A brief digression to discuss model access, where the devil is in the details. For example, in the MS Azure model menagerie, there is an essential distinction between models sold directly by Azure (“Azure Direct models”) and models that are surfaced through Azure but are still from Partners and Community. The former are the cleaner case: Microsoft hosts them in Microsoft’s Azure environment, under Microsoft’s product and data-protection commitments, and Microsoft says prompts and completions are not shared with other customers or with the underlying model provider and are not used to train foundation models absent permission or instruction. Partner and Community models have their own ToS.

For example, whereas OpenAI models are Azure Direct, Anthropic’s models (Claude) are not, which means that the governing privacy posture is different, and Anthropic’s privacy policy and commercial terms are part of the analysis. As such, before using the MAVENS stack, it is essential to understand these terms in all of their excruciating detail.

Deployment characteristics also drive data location, and here the official terms matter too. Azure speaks in terms of region, geography, and DataZone. For Azure Direct models, data stored at rest remains in the customer-designated Azure geography, but the location of processing for prompts and responses depends on deployment type. A Standard or regional deployment processes in the deployment region. A Global deployment may process prompts and responses in any geography where the relevant model is deployed. A DataZone deployment may process prompts and responses anywhere within the Microsoft-defined data zone, today the United States or the European Union. So if you stand up a US DataZone deployment, processing may occur anywhere in the United States; if you stand one up in an EU member state, processing may occur in that or another EU member state. Thus, when using the MAVENS stack, it is essential to become intimately familiar with model categories, deployment types, geography of data at rest, and where inferencing may occur.

##Deconstructing the MAVENS stack

I will now describe the technical underpinnings of the MAVENS stack (in no particular order, and with AI slop images for maximum engagement).

##1. the Agent harness

An open agent harness allows the practitioner to interact with models in an agentic way. It’s the practitioner’s interface into the model provider(s) (which can be any, including the latest and greatest from OpenAI, Anthropic, Grok or others) and their respective model(s). The agent harness I’m primarily using currently, OpenCode, can be accessed in a Terminal User Interface (TUI, yay), CLI, via the web, desktop (beta, pretty rough), and via an IDE like Visual Studio.

Thus, the MAVENS stack may require a change in how you work. I will argue this is for the better–programmers have known for a long time that text, pipes and composability beat monolithic GUIs for software work, hands down. And all knowledge work is now software work.

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

– The Bell System Technical Journal. Bell Laboratories. M. D. McIlroy, E. N. Pinson, and B. A. Tague. “Unix Time-Sharing System Forward”. 1978. 57 (6, part 2). p. 1902

Thus, it stands to reason that knowledge workers should embrace UNIX principles for knowledge work, for maximum effectiveness.

###Harness engineering and harness training

I already mentioned that coding agents can be used to improve the agent harness and other aspects of the MAVENS stack, to extend functionality on an as-needed basis, and that those customizations/extensions compound over time. Some recent research in this area hints at what will be coming down the pike soon:

Changing the harness around a fixed large language model (LLM) can produce a 6× performance gap on the same benchmark [46]. The harness–the code that determines what to store, retrieve, and show to the model–often matters as much as the model itself.

This paper showed automated harness engineering produces better classifications, faster, in legal and legal adjacent domains – including USPTO molecule-reactant datasets and criminal charging from case descriptions – than hand-curated techniques. Meta-Harness significantly outperformed LawBench, using far fewer tokens.

This was accomplished via harness training:

At a high level, [Meta-Harness] repeatedly proposes, evaluates, and logs new harnesses. […] [B]y leaving diagnosis and edit decisions to the proposer rather than hard-coding search heuristics, Meta-Harness can improve automatically as coding agents become more capable.

For now, I’m left to wonder, what would it take for a patent practitioner, or another knowledge worker, to learn to trust a self-improving orchestration layer? More on this in a future post, perhaps.³

###Clawed Open

While I was doing final edits on this post, as if on cue, the interwebs began to vibrate with the news that the source code for the Claude Code harness had escaped into the wild.

The code was quickly ported via purported clean room engineering. The claw-code developer wrote the following:

At 4 AM on March 31, 2026, I woke up to my phone blowing up with notifications. The Claude Code source had been exposed, and the entire dev community was in a frenzy. My girlfriend in Korea was genuinely worried I might face legal action from Anthropic just for having the code on my machine — so I did what any engineer would do under pressure: I sat down, ported the core features to Python from scratch, and pushed it before the sun came up.

The whole thing was orchestrated end-to-end using oh-my-codex (OmX) by @bellman_ych — a workflow layer built on top of OpenAI’s Codex (@OpenAIDevs). I used $team mode for parallel code review and $ralph mode for persistent execution loops with architect-level verification. The entire porting session — from reading the original harness structure to producing a working Python tree with tests — was driven through OmX orchestration.

The result is a clean-room Python rewrite that captures the architectural patterns of Claude Code’s agent harness without copying any proprietary source. I’m now actively collaborating with @bellman_ych — the creator of OmX himself — to push this further. The basic Python foundation is already in place and functional, but we’re just getting started. Stay tuned — a much more capable version is on the way.

Without taking a position as to the legitimacy of this activity, a few things seem clear.

First, Anthropic needs better InfoSec. They seem to have physical security buttoned up:

Even this blankness is doled out grudgingly: all but two of the ten floors that the company occupies are off limits to outsiders. Access to the dark heart of the models is limited even further. Any unwitting move across the wrong transom, I quickly discovered, is instantly neutralized by sentinels in black. When I first visited, this past May, I was whisked to the tenth floor, where an airy, Scandinavian-style café is technically outside the cordon sanitaire. Even there, I was chaperoned to the bathroom. – https://www.newyorker.com/magazine/2026/02/16/what-is-claude-anthropic-doesnt-know-either

Second, the claw-code repository is of a piece with the types of LLM-based copying risks people have warned about for a while now in the IP community, which I wrote about in reference to (somewhat ironically) the Anthropic C compiler project, and which have, in the interim, cropped up in other contexts.

Third, setting aside the morality of the Claude clones, for practical purposes, the horse is out of the barn, and the digital commons will be the immediate beneficiary. Everyone can now read the Claude Harness, its code and its prompts to develop their own coding agents. They can do so in conjunction with any models. This leak seems likely to include trade secret information that, until yesterday, appeared to have given Claude Code a non-insignificant edge over competitors like OpenAI Codex.⁴

Having said that, some of the technical details about the inner workings of Claude Code sound kind of obvious in hindsight. A more tinfoil-hat interpretation is that Anthropic may not be terribly unhappy to have the wider FOSS world iterate on parts of the harness. But that is speculation.

###Porcelain, not plumbing

One of the practical upsides of using an agent harness is that it abstracts away all of the LLM drudgery (counting tokens, counting costs, authenticating with providers, keeping a current list of models and their respective capabilities/parameters, etc.). Anyone who has spent any time coding against an LLM knows this bean counting starts to feel like medieval torture after a while, especially due to constant drift and churn among providers and their model offerings. The harness can simply ingest data from a FOSS API (e.g., models.dev) that the community keeps up to date. On its own, this is a huge win. All of the API programming, which can change in sudden and highly disruptive ways, is a thing of the past. A lot of boilerplate programming is no longer necessitated, given the better abstractions of the MAVENS stack.

Open agent harnesses also have a flexible model layer. A useful knowledge work system should be able to work with whichever models make sense in the moment: local models where they are good enough or operationally attractive, frontier hosted systems where stronger performance is worth it. Ad hoc or case-by-case selection should be available when it’s called for or as input modalities dictate. It’s nice to be able to ask OpenAI and Anthropic the same question, back-to-back, and compare responses.⁵

One potential wrinkle in the MAVENS stack is lackluster web and desktop support. While usable, they are not as polished. But if you’ve read this far, there’s a good chance a terminal interface not only might not scare you, but could be just the thing you’re looking for.

##2. agent Memory

###Screaming at goldfish

An excerpt from Steve Yegge that might resonate with you if you’ve tried using an agentic model to do anything remotely complex without agent memory (vibe coding, coding with a straight face, or otherwise):

Your agent enthusiastically begins working on phase 1 (out of 6). You go through the whole canonical multi-step vibe coding workflow loop together: design the solution, review the design, write code, review code, make fixes, write more tests, review, cleanup, rebase, update plans, git operations. (All stuff in our book!)

So far, the agent is happy, and you are happy. Everyone is so, so happy.

The agent eventually finishes phases 1 and 2 (out of 6), with you repeating this dev loop many times.

It’s working, but during this time, several compactions/restarts happen, which resets the agent’s memory.

By the start of phase 3 (out of 6), the AI has mostly forgotten where it came from. It wakes up, plops in your video cassette, and reads about phase 3. It then declares, “Oh wow, this is a big project, I’m going to break it into five phases and create a markdown plan.” Which should sound eerily familiar.

Then it begins working on phase 1 (out of 5) of phase 3 (out of 6). Except it just calls it “phase 1”, with no mention of the six outer phases it was just working on.

You start to sweat.

The agent finishes the first two phases 1 and 2 (out of 5), which takes many more compactions, and it has been displaying signs of increasing dementia along the way.

When the agent arrives at phase 3 (out of 5) of phase 3 (out of 6), it has gone full-blown bugshit amnesiac, and it announces triumphantly:

“Congratulations, the system is DONE! 🎉 Let’s start manual testing! 🚀”

And you’re like, “Woah… w-what? What… about… all the other phases? The inner ones and outer ones? I distinctly remember a lot more phases!”

And they deadass look you in the eye and say, “What phases?”

And you bite back a scream, and go look in their markdown plan, only to discover in horror that they have been creating a dozen 6-phase plans a day for the past three weeks since your last Great Markdown Purge, and you have literally hundreds of new markdown files, all with low-context titles like cleanup-tech-debt-plan-phase-4.md — all partly implemented, all partly obsolete, all 100% useless.

C’mon, raise your hand if this has happened to you. ✋ If you’re not sure, you might want to go look in your plans/ directory. Surprise! 🎉

After six months of this situation happening like twenty times a day, if you’re at all like me, you start thinking, I need a Plan Manager.

If you’ve tried using markdown-based plan files to guide an agent, you’ve probably choked back that same sweaty sob/scream, and you might know that agent memory is the way out.

A tool like beads helps to alleviate the “demented agent” issue by giving the model “a persistent, structured memory” that it can use “to handle long-horizon tasks without losing context”.⁶

However, for patent practitioners, the approximate parallel is a model context resetting/compacting, while in the midst of drafting a 68-page patent application, with a context window at 39% (304.2K tokens). Regardless of the knowledge domain, the ability to level set the context window predictably and somewhat losslessly becomes Very Important.

Previously, you’d need to attempt to store all of the things that the agent needs to know in flat text files and find a way to reinject that context. With memory, you can just throw all of your implementation tasks and context into hierarchical issues à la beads, and kill the model session and start a fresh one if the context gets too wild and woolly. When you come back, at 0% context window consumed, the model still has (mostly) everything it needs to pick up where it left off. This is simultaneously a faster, cheaper and less error-prone way to use agents.⁷

###Editing modalities - Agents and Subagents

Some agent harnesses have the ability to use editing modalities, or agent modes. Interestingly, Pi does not expose separate modes in quite the same way. OpenCode ships with two: Plan and Build, which, respectively, (essentially) provide read-only and write access to the filesystem including use of tools. A typical patent drafting workflow looks like this:

• Plan complex features/functionality, optionally based on existing language in plan mode. This is all done in memory with iterative model turns.
• Once the plan looks good, save it as persistent hierarchical tasks using beads.
• Switch to build mode and begin iteratively carrying out the plan. This involves generating new files or editing existing ones.

OpenCode ships with two sub-agents: General and Explore, which respectively, can research complex questions and execute multi-step tasks (including with tools); and quickly search files (think Grep, with extras).

The agent/subagent layer is where the MAVENS stack starts to feel like a real knowledge work environment. In OrdinarySkill.ai, I modify the default agent set with additional agents and subagents that are purpose-built to do patent-specific tasks. It works amazingly well–if you have used a coding agent, it’s like that–but for patent work.

The OpenCode API documentation is a good read if you are interested in more details about OpenCode’s agent implementation.

##3. Versioning

Git is old hat for most software developers, and software patent practitioners. Suffice it to say that keeping the artifacts of patent drafting in a distributed VCS is very comforting, for all of the reasons it is in software development.

##4. Export

Everything up to this point has been a reversion to the text-first, composable Unix mode: a terminal, a good editor, plain text files, and version control are a very natural environment for agentic work. It’s a shame that reality must intrude, in the form of document production.

For patent work, Word is the lingua franca. The USPTO effectively penalizes applicants for filing PDFs, which is only a slightly nuttier decision than the one to standardize the entire filing system around the dumpster fire of a file format that is docx.

Regardless, Word is the craggy remote airstrip where 99% of patent deliverables must land.

That means the drafting environment must be able to move cleanly from structured source into picture-perfect MS Word output. TeX, Pandoc, and related tooling are not glamorous, but they are powerful building blocks for getting there.

However, as much as I enjoy dumping on Word, Microsoft has in recent years done some things that make working on Windows not only bearable but so interoperable with Unix that there’s almost zero friction. I have nothing but love for Windows Subsystem for Linux, which allows any MAVENS stack to directly interoperate with Word and the Microsoft filesystem. The fact that WSL has Arch Linux out of the box is the cherry on top.

##5. The ruNtime

The runtime includes matter state that the system can reason about.
Patent drafting is not just “write a lot of text.” It is a constrained document-building problem with dependencies everywhere: claims and specification must stay aligned, figures need to map cleanly into the detailed description, optional sections come and go, and terminology has to remain coherent over tens of pages. The ruNtime provides a stable substrate for this work that is grounded in document structure and practitioner know-how.

The runtime is where I think a lot of the durable value sits in the MAVENS stack, for patent practitioners but really for all knowledge workers who apply it. Agent harnesses will improve, models will churn, and export tooling will remain mildly cursed. A well-designed runtime gives all of those moving parts a common contract. It lets different agents, skills, and renderers operate against the same data without each inventing its own private version of reality. For me, this is the real promise: less hidden state, fewer surprises, and a workflow that gets better because the software actually knows what the work is.

##6. The Skills

If the runtime is the source of truth, the skills are the reusable recipes/moves.
A skill is not just a giant prompt pasted into a text file. It is a named, portable procedure for doing a recurring piece of patent work: routing a workflow, drafting a first pass of particular text, reviewing for consistency, harmonizing terminology, generating a figure prompt, flagging possible support issues, and otherwise teeing up issues for practitioner review. The important thing is that skills can be recursively improved independently of the agent harness or model provider, with the practitioner as a guide. Skills are packages of reusable technique.

Once a useful drafting pass or review sequence exists, it can be reused across matters, sharpened over time, and composed with other skills, without collapsing into prompt soup. Instead of evaporating with individual chats, this knowledge starts compounding in an organized repository. And these tools are editable, in the tool. So after you finish a session where you correct a bunch of things, you can say something like “update my claims review skill file to include avoiding passive voice and nominalizations.” It will do it and report back. This is an incredibly powerful, and fast, way to work, where the practitioner can crystallize and preserve judgment for repeated use.

This is also one of the more interesting places for professional differentiation. While the MAVENS stack is open, the best skills can still reflect a practitioner’s own drafting habits, review heuristics, and sense of what makes an application good. Good taste is difficult to express in code, but the skill layer moves us closer.

##Closing

AI software tooling has become critical to patent practice. It is not docketing software, accounting software, or some other ancillary system, removed from the legal work. An AI patent drafting stack reaches directly into the substantive legal function itself. It does not displace ultimate practitioner responsibility for what is claimed, argued, supported and filed. But it sits close enough to the heart of the work that it must be treated with the same seriousness.

At the same time, there is a merger underway between software functions and legal functions, which implies a merger of tooling. As legal work itself becomes more software-shaped, the tools built for sophisticated software work become increasingly applicable to sophisticated legal work.

What has become possible only very recently is the ability to assemble drafting environments from mature FOSS tooling, and to use them to access the best models available, while fully customizing the system for a given knowledge work domain, allowing the knowledge worker to build or shape a workflow around the actual work. For patent practice in particular, drafting has enough structure, repeatability, and document-centric gravity that this kind of environment can be very effective.

As I use agentic systems more, and particularly the MAVENS stack, I find myself running dozens of lightweight agents interactively to solve different problems concurrently. tmux allows me to run these agent sessions persistently, and no file, directory or data source is safe from the grip of my MAVENS stack. One agent tees up a first pass critique of a claim set, while another steps through an office action analysis workflow, another generates terrible images for a draft blog post. This is the promise of agentic AI–on-demand, parallel application of knowledge models to digital artifacts, wherever they may be.

In any event, I hope that you, too, always have an agent running.

##Notes

##How it Started

commit 59014c091efa219987779af1c0844c4aa0304ee0
Author: Noah K. Tilton <code@tilton.co>
Date:   Sun Jan 7 17:00:08 2024 -0600

    blah

I made this initial commit on a Sunday afternoon with a listless message I use when I’m too lazy or tired to type a descriptive one. This is not usually a problem, because most of the software I write is not intended to be read or used by others. I have not worked as a professional software developer for over a decade, and as a patent prosecution partner with a robust practice, I still do not.

However, in late 2023, something changed that, looking back, was a momentous time in my journey as a patent practitioner. Over the holidays, a colleague repeatedly pestered me (in a good way) about ChatGPT, and specifically, whether it could be used in the practice of patent law.

In the nine months or so leading up to that time, during the initial GPT-3 era, I was like a lot of other people in the IP space – ambiently familiar with large language model (LLM) technology, but focused on other things. I had also developed a bit of trepidation toward LLMs, due to an uneasiness I had felt during early experimentation with GPT, that I was riding up a lift hill, and once I reached the crest and started the first precipitous drop, there would be no getting off. This is still the best metaphor I can conjure for the viral, exponential arrival of LLMs – as a rollercoaster ride that never ends.

I had some downtime over the holidays, and I usually code during that period since it’s cold, dark and I can’t sit still. Within a few weeks of being nagged by that persistent colleague, I had a working web app, later renamed OrdinarySkill.ai (OS), that performed a variety of automated LLM-based drafting and prosecution tasks. While I made OS available for use to others, I had no aspirations to be a software CEO. Any usefulness to others was purely incidental. Notwithstanding, over 1B tokens have been consumed by users of OS to date, for a variety of things.

In sum, OS was an early indicator of the disruptive potential that LLMs would have on the practice of patent law, and it was soon surpassed by more capable (read: more user-friendly) tooling. I continued working on it actively until Fall of 2025, and it dramatically accelerated aspects of my practice, which did not go unnoticed.

##“Buy or Build?”

This is one of the questions that people began asking during this time. The romancing by any number of more or less credible SaaS providers has been intense. All offer some form of LLM-based patent workflow automation.

I developed an aversion to these spammy offers–which continue essentially unabated to this day–and to the COTS products behind them, some of which are provided by companies with very deep pockets, both well-established legal software players, and new entrants. The reasons for my gut-level response are numerous, and if you don’t care, skip this section. In no particular order:

• I have never needed COTS to access an LLM, because I am comfortable writing code to access private language model APIs directly. Nothing stands between me and the model. I know, down to the token, exactly what is being fed into the model, and can reason explicitly about outputs with zero opacity (and no upcharge). Need to generate something specific and bespoke? Wrap custom prompts in a loop or a function. Need to change something? Add new functionality? I have access to the same agentic coding tools the COTS vendors do, and can knock features out in an afternoon. Or an hour. Or less. (More on this in short order.) I’ve been accused of “vibe coding”, and I am guilty as charged. I’m in good company.

• Because the COTS patent tools are not programming environments (by definition and design), they are not flexible enough to accommodate all use cases. This level of control isn’t for everyone, but it’s unaddressed, and probably unaddressable by COTS software. Tooling created for all patent attorneys at all law firms attempts to be all things to everyone, and does a mediocre job at everything.

• LLM systems are already non-deterministic by default, which makes reasoning about their outputs a hard problem. The last thing I want is well-intentioned minders of a walled garden adding more layers of uncertainty to the process. I have heard repeatedly from other frustrated practitioners riding the LLM rollercoaster that they simply cannot get COTS software to do what they want it to do, regardless of how exacting or precise their prompts have become.

• Apart from reduced flexibility, there are legitimate questions around the value add of patent COTS over foundation models themselves, which remains dubious unless ease of use is of paramount importance (which it is in some cases). While most foundation models are effectively identical, harnesses are critical for getting useful results. And because harnesses are critical, they’re the last thing that should be outsourced.

• No one knows what current patent law AI tool providers, who have at least theoretical access to some of the juiciest data on the planet, will do with it in the future. A federal judge recently ruled that a criminal defendant’s conversations with Claude were not covered by attorney-client privilege. Information shared with publicly-available LLMs appears to be a law enforcement treasure trove, on the order of networked automatic license plate readers or genetic ancestry databases in terms of its utility in building criminal cases. In that climate, introducing third party risk seems unwise, even if the parallel is a civil-equtiable context.

• FOMO is not a reason. The Citrini/Shah paper linked below reads like alarmist bullshit, and some of it is, but the AI-Driven Economic Feedback Loop is 100% real. COTS adoption feels a lot more like following than leading.

• Last but not least, there’s the issue of VC’s overt disintermediation of a proud legal tradition with roots reaching back to the founding of the country. Not all AI tools are VC backed, but I think it’s shortsighted to assist in this process by being a passive consumer of COTS patent AI software. I’m not really interested in helping to train my replacement.

It felt very good to get all of that off my chest, and I hope you do not feel personally attacked, dear reader. I think it’s important, since I’m discussing my vocation, to remind you that this blog represents my opinion only, and I do not speak for anyone else (see the disclaimer, below). However, I think this is important context for where we’re headed.

Assuming patent COTS tools are an antipattern for the Patent Programmer-Practitioner, what does that leave one to do?

##The Real MacKay

This is really a blog post about how LLM technology is truly indistinguishable from magic, and how embracing it over the past few years has given me a Christmas morning-like excitement that I haven’t felt about a technology since I started teaching myself RedHat Linux in 2003. Before that I’d probably have to revisit the first few months I spent logging on to AOL in the early ’90s to find similar enthusiasm for a technology. As far as digital technologies go, LLMs are the Real McCoy.

And a lot has been written recently about the disruption posed by “AI.” I use the term advisedly, as one should–as Rusty Foster correctly points out, AI isn’t people, and anthropomorphizing generative AI in the form of LLMs can be a costly category error, because it blurs the line between a piece of software and a human being. Yet some of the more hyped up prose implies that this is a distinction without a difference, because LLM output “quality has reached a point where many professionals can’t distinguish [it] from human work.” But “many professionals” isn’t the same as “all.” It’s certainly not “all patent examiners.”

If you are looking for semantically ablated text, you’ll find mounds of it. The syntax hallmarks of AI slop are unmistakable. You might not care if you are booking a plane ticket. But if you are drafting a patent claim, you should.

So while they are the Real McCoy, at this point, it’s probably also correct, especially if you are using them in the practice of law, to think of LLMs as stochastic parrots and blurry JPEGs of reality, and act accordingly. There are much more colorful descriptors, if you wish.

Despite their rough edges, LLMs are the best learning platform humanity has ever assembled, apart from other humans, and are lowering the innovation bar across the board, in every domain you can think of, including mathematics.

In my case, it’s motorcycles. At least this quarter. I decided to start work on an antique rehabilitation project, and have recently used LLMs to teach myself about bonded titles (joke’s on me), 4-cylinder carburetor rebuilding, and 3D printing. These are topics about which I knew next to nothing, until 45 days ago.

My cover story is that I can use the bike to teach my kids about engines. In connection with this we recently visited the UIUC Fab Lab (shoutout to Michael and co.) intending to use their 3D scanner for a part that would be $50 on eBay. It turns out that the 3D scanner device manufacturer had gone poof, along with the software for it.

Undeterred, we fired up Polycam–an amazing piece of software in its own right–and were able to quickly capture a 3D model of the complex part we wanted to print, in glTF 2.0, using our phones. We then loaded that file into Blender (this decision was made for us, because glTF is the only free export format of polycam, and Blender supports glTF well) and are now well on our way to learning enough Blender to get useful 3D prints, with almost no trial and error or RTFM.

It’s worth pausing to appreciate that this entire sequence of events is something I would never have had time for in a non-LLM world. And there are 1000 other examples of this type of self-directed learning, many of which I have taken for granted and already forgotten.

It’s also worth pausing to consider, what if polycam wasn’t a thing? What if there wasn’t a quick and easy alternative to the defunct 3D scanner? Could we have bypassed the NextEngine licensing server by reflashing the device? Written replacement firmware? What would the solution path look like? Could we point Claude Opus at it and go make a sandwich? Perhaps not entirely, but how much time would that have saved, compared to cracking it manually?

If there is a problem that needs solving, or an idea about which one has an inkling, or a project that seems a tad too ambitious, some initiative plus an LLM makes for a sufficiently more capable/ dangerous human. I am not the only one whose initial AI skepticism has been won over by recent advances in agentic AI discourse, especially where software is concerned.

Another recent example, beyond motorcycles, is how quickly things I already know how to do can be significantly sped up. For some of my clients, I need to keep up with new small arms technologies and trends in that industry. So I created GunClaims, a microsite that processes the entire USPTO patent gazette every Tuesday, classifies the new patent issuances according to whether they are in the small arms/ammunition field, and publishes them in an easy-to-read format.

It took me about 8 hours total to put GunClaims together, from programming to deployment, and testing. That’s pretty amazing velocity from idea to clockwork execution. Of course, GunClaims could be done with any sub-specialty or subject matter interest, and it is far from perfect. I only mention it, as one example of the amplification potential in using LLMs to automate tasks that might otherwise exist only as mere passing thoughts.

##Agentic Schmagentic (A very complicated and nuanced story)

In this moment, we are well on our way in the agentic era of the LLM rollout. In simple terms, an “agentic” model refers to one that has state (memory), access to tools, and which runs in a loop to act autonomously in furtherance of a goal. That goal–which can be expressed in multi-modal terms–could be something like “create firmware for this defunct 3D scanner.” Or “explain where this pilot jet goes in relation to the float arm.” Or “draft an office action response” or “draft a first draft of a patent application.” However, because $goal can be just about anything, there has been much rending of garments and outright doomerism over agentic technology (some of which may be correct). The economic consequences of the transformation to an agentic world are less clear.

Despite this, not everyone believes the sky is falling. Labor substitution is still difficult, and bottlenecks still exist (often by design). A more sober report from Citadel in response to the Citrini piece makes the case that AI is a productivity shock, not a demand shock, and notes that SWE jobs are rapidly rising while human demand for new technologies remains elastic. Others have observed that software developers are basically cockroaches.

I think Terry Tao gets it right, discussing the application of Generative AI to the Erdős Problems:

There’s a big crowd of people who really, really want AI success stories. And then there’s an equal and opposite crowd of people who want to dismiss all AI progress. And what we have is a very complicated and nuanced story in between.

Regardless of which prognostications are correct, the truth of the matter is that the agentic LLMs are already extremely impressive, in certain narrow bands. Thus, there does not seem to be any question that LLM tech will be disruptive of existing white collar labor practices. The question is one of degree. But the first and most notable disruption to date has been to code generation, a.k.a. computer programming, a.k.a. software engineering.

##Jetpacks, Baby!

Returning to my Git commit above, for the first year or so of developing OS, I was writing code as I had for 20 years – in a text editor, with code assistant niceties (syntax highlighting, static analysis, autocomplete and an LSP server). A year later, I had worked up the nerve to use ChatGPT to explore coding ideas piecemeal, evaluating the outputs and manually copy-pasting them into my editor, before cleaning them up and testing them. At this point, I was still facing down the same trepidation and unease I had felt when first touching these models, something that I was not alone in feeling. That rollercoaster looks massively tall…

Mid-October of last year marked the agentic inflection point in my use of LLMs. After hearing a friend rave about Cursor, I finally broke down and installed Visual Studio so I could dip my toes into Claude and Codex. Whoosh! This rollercoaster has a jetpack! I was hooked.

…And that was an older version of Codex (which I settled on using, due to inertia and familiarity). Newer versions of Claude/Codex are even more impressive, and are good at making (sometimes improved) copies of other highly complex things, like JavaScript frameworks and C Compilers. They can also do this very swiftly, compared to traditional software development practices.

Chris Lattner’s analysis of the Anthropic C compiler project is quite revealing of current agentic capabilities. The technical capability conclusions of that article are worth internalizing. I discuss them in more detail below. More directly relevant to the practice of patent law, Chris noted:

IP Law and Proprietary Software Moats

The Claude C Compiler also raises important yet uncomfortable questions about intellectual property. If AI systems trained on decades of publicly available code can reproduce familiar structures, patterns, and even specific implementations, where exactly is the boundary between learning and copying?

This is an excellent observation, and an illustration of an issue (LLM-based copying) that has been on IP professionals’ radars for a while now. Similar concerns touched off (another) SaaS-pocalypse in markets over the last few weeks. Suffice to say, IP law is rapidly evolving in this area, and markets are–rightfully–jittery, as agentic capabilities have arrived.

##Of Vibe Drafters and Agentic Patent Practitioners, or How I Am Using Agentic AI in Patent Practice

So how am I using agentic AI in patent practice?

The shortest answer is the following analogy:

coding agents : software engineering :: drafting agents : patent practice

The slightly longer answer involves a two-part experiment:

1. Find a software practitioner blog post about how they are using agentic AI for software development.

2. apply the following word replacements:

   from ->	to
   code	draft
   software	patent
   programmer, engineer, etc.	patent practitioner

The result of this word replacement experiment is likely as good an answer to the question as any other.

Take for example the introductory paragraphs of Simon Willison’s recent post on Agentic Engineering Patterns (strikethrough and underline showing above substitutions):

Writing about Agentic Engineering Patent Practice Patterns

I’ve started a new project to collect and document Agentic Engineering Patent Practice Patterns—coding drafting practices and patterns to help get the best results out of this new era of coding drafting agent development we find ourselves entering.

I’m using Agentic Engineering Patent Practice to refer to building software patents using coding drafting agents—tools like Claude Code and OpenAI Codex, where the defining feature is that they can both generate and execute code a draft—allowing them to test that code draft and iterate on it independently of turn-by-turn guidance from their human supervisor.

I think of vibe coding drafting using its original definition of coding drafting where you pay no attention to the code draft at all, which today is often associated with non-programmers non-practitioners using LLMs to write code a draft.

Agentic Engineering Patent Practice represents the other end of the scale: professional software engineers patent practitioners using coding drafting agents to improve and accelerate their work by amplifying their existing expertise.

With sincere apologies to Simon, the rhetorical point here is pretty clear: that this fun little experiment works so well demonstrates the near-total convergence between the cognitive tasks of professional software engineers and patent practitioners, as far as LLM tooling is concerned. The only difference is the technological domain, and credentials.

One caveat/clarification: there are important distinctions between the instances of coding model providers that are available from given different tenancy configurations/ paid membership tiers, that are beyond the scope of this post (except to say, it’s essential that vetting and diligence be done to avoid privilege waiver or other issues). I am not endorsing any particular model provider.

I’ll be writing more about my free/open source agentic patent software stack in the coming days, so please stay tuned for that. For now it suffices to say, you know you’re on the bleeding edge when you are impatiently patching code to fix bug reports that are only a few hours old.

##Merging, but Not Emerging (?)

Returning to Chris Lattner’s piece from about the Claude C compiler, I suggest that reading it again, but this time, imagine that instead of a C compiler, he’s talking about a patent application drafting system (or whichever hairy knowledge artifact you please). Here are some of the things you might have read in that case, from his main takeaways (edited using my replacement table above, and graded by me for anecdotal accuracy):

• AI has moved beyond writing small snippets of drafts and is beginning to participate in drafting large patent applications (True)

• AI is crossing from local draft generation into global practitioner participation (True)

• Our legal apparatus frequently lags behind technology progress, and AI is pushing legal boundaries. Is private patent practice cooked? (Maybe)

• Good drafting depends on judgment, communication, and clear abstraction. AI has amplified this. (True)

• AI drafting is automation of implementation, so design and stewardship become more important. (True)

• Manual rewrites and translation work are becoming AI-native tasks, automating a large category of drafting effort. (True)

• AI, used right, should produce better drafts, provided humans actually spend more energy on architecture, design, and innovation. (True)

• Architecture documentation has become infrastructure as AI systems amplify well-structured knowledge while punishing undocumented systems. (True)

Perhaps the most interesting takeaway of Chris’s post (unedited) is that:

AI systems can internalize the textbook knowledge of a field and apply it coherently at scale. AI can now reliably operate within established engineering practice. This is a genuine milestone that removes much of the drudgery of repetition and allows engineers to start closer to the state of the art. But it also highlights an important limitation of this work:

Implementing known abstractions is not the same as inventing new ones. I see nothing novel in this implementation.

Change “engineering” to “lawyering” or “accountancy” and see how it feels. I think it’s about right, including that agentic systems are–currently–pattern-limited, and lacking truly creative emergent intelligence.

Chris then hits the nail directly on the head:

As implementation becomes cheaper, the role of engineers shifts upward. The scarce skills become choosing the right abstractions, defining meaningful problems, and designing systems that humans and AI can evolve together. This will increasingly blur the boundary between software engineering and product thinking.

The merger will not be televised.

##It’s All One Song

The merger between software development and patent practice (and other knowledge tasks) shows itself in funny ways.

Example: I was recently offered a guest column by a major financial publication, and I spent a couple of days thinking about the topic and writing about my perspective. The copy was like this, but shorter and a lot more sterile. It used the phrase “jagged edge” (with attribution).

The editor refused to publish it, saying my essay was “duplicative of recently published content.” At first I thought I was being accused of plagiarism, but then I decided to ask for the editor for clarification. What they really wanted, they said, was something more focused on “my specific experience in developing an AI solution, along with lessons learned/challenges observed that other AI innovators can appreciate.”

Well, this is that specific experience, in rando blog form, and the lesson learned/ challenge observed is that we’re all on the same AI forevercoaster, and that wasn’t my original idea, either. On the off chance you’re that editor, I hope you don’t find this content overly duplicative, but also, who needs an editor (!?) and, you’re welcome (not getting those non-billable hours back).

##Agentic Patent Practice: Inferences from Other Disciplines

Having established that agentic patent practice is a horse of a different color, but still a horse, there are endless lessons that we Agentic Patent Practitioners can take away from the “first wavers”–those whose disciplines have been so profoundly affected by the rise of agentic machines–and their useful adaptations. The aforementioned agentic engineering guide discusses several additional principles and patterns that are directly applicable to Agentic Patent Practice, and is a good place to start.

“Knowledge Priming” is another useful pattern, that involves systematically parameterizing the agent with information it needs to generate better outputs.

Several others have written more or less formally about how they are using agentic AI systems more systematically to improve results.

Terry Tao is instructive here, too. He observed that current models are successful at eliminating tedium and searching the long tail of problem spaces, and at enabling population-level analysis, while expressing healthy skepticism of turnkey agentic workflows:

[A] lot of AI companies have this obsession with push-of-a-button, completely autonomous workflows where you give your task to the AI, and then you just go have a coffee, and you come back and the problem is solved. That’s actually not ideal. With difficult problems, you really want a conversation between humans and AI. And the AI companies are not really facilitating that.

This rings true.

My overarching point is that patent practitioners should be reading the experiences and absorbing learning from those who have gone before, and porting their adaptations to our practice.

##Riding the AI Forevercoaster off into the Sunset (?)

Lately I’ve been thinking about how the ranking of app tokens in my MFA app determines the order of importance of each app to my life. There are a few token providers above my LLM providers on my phone, but the LLMs are close to the top–ahead of Amazon, Cloudflare, Firefox, Github, and social media, to name a few.

If your employer is not already forcing you to use AI, they probably will be soon. Indeed, if you are working a white collar job, and not retiring soon, facility with AI is not something you’ll be able to avoid.

It’s also true that AI makes everyone work more, and harder. As Siddhant Khare puts it,

AI reduces the cost of production but increases the cost of coordination, review, and decision-making. And those costs fall entirely on the human.

Recent research suggests essentially the same thing: that unfettered AI adoption can lead to “cognitive fatigue, burnout and weakened decision-making.” Khare makes some other good points about the inherent cognitive fatigue brought about by working with nondeterministic systems, the FOMO treadmill and prompt yak shaving. His solutions to these problems, and more, are worth reading. As are Steve Yegge’s recent thoughts on what he calls the AI Vampire. And those of Jennifer Moore on anchoring and vigilance.

These articles and others about cognitive debt make the point that the adoption of AI has forced many software developers who were formerly “doers” into “reviewers.” The same is true in the law. Gone are the days of keyboard jockeying, searching a thesaurus for the perfect next word while grinding out paragraphs of prose. Editing and revision are the main modalities now, even for newer practitioners. If you have used AI for even a short time, this is old hat.

For people just entering the practice, Terry Tao is a typical font of useful wisdom:

[Math] problems are like distant locations that you would hike to. And in the past, you would have to go on a journey. You can lay down trail markers that other people could follow, and you could make maps. AI tools are like taking a helicopter to drop you off at the site. You miss all the benefits of the journey itself. You just get right to the destination, which actually was only just a part of the value of solving these problems.

This is apt, and I would encourage newer practitioners to be wary of helicopter rides and other forms of convenience, lest they fall into the Sorcerer’s Apprentice Trap.

Better to stay firmly belted in to your coaster seat, keeping your arms and legs inside the ride at all times.

On February 9, 2026, the U.S. Court of Appeals for the Federal Circuit reversed a judgment and jury damages award against Netflix, holding that the asserted claims of three related GoTV Streaming patents (U.S. Patent Nos. 8,478,245, 8,989,715, and 8,103,865) are patent-ineligible under 35 U.S.C. § 101. The court concluded the claims are directed to an abstract idea (using a generic template of specifications and then tailoring those specifications to a user device’s constraints using conventional server/ network operations) and do not recite an inventive concept sufficient to transform that idea into patent-eligible subject matter.

Although the court also reversed the district court’s indefiniteness ruling as to one claim phrase, the § 101 holding was dispositive and the Federal Circuit directed entry of judgment for Netflix, erasing a significant jury verdict in the process.

##The § 101 Holding: Abstract Idea + Conventional Implementation

###The Claimed Concept (as Treated by the Court)

GoTV’s patents are generally directed to delivering application content to wireless devices by having a server:

• receive a device request (including device type);
• generate a wireless-device-generic template (a non-device-specific set of display specifications);
• send a custom configuration (look-and-feel data) to the device; and
• generate and send a page description based on the generic template and the device’s capabilities, containing at least one “discrete low level rendering command” in device-generic syntax but within the device’s rendering capability.

For eligibility purposes, GoTV treated claim 1 of the ’865 patent as representative, and the court focused its analysis accordingly, finding all asserted claims invalid for the same reasons.

##Alice Step One: “Directed to” an Abstract Idea

Reversing the District Court’s conclusion that the claims were eligible at Step One, the Federal Circuit held that the representative claim is directed to the abstract idea of:

• creating a template set of specifications that is generic in at least some respects, and
• tailoring at least one aspect of that template for final production to fit user-specific constraints (here, the requesting device’s capabilities).

The court emphasized that this type of templating-and-tailoring concept is a familiar, longstanding practice and remains abstract even when applied to a particular technological environment (wireless device displays). The claims were not saved by describing the idea in the vocabulary of networks and mobile rendering; narrowing the abstract idea to “display content on a wireless device” did not change the Step One outcome.

Conventionality and technological environment are legitimate Alice Step One inquiries, and the Federal Circuit in GoTV followed a line of other cases that have treated “result-based functional language” as a red flag at Step One. For example, in Two-Way Media, the court explained that the representative claim required the functional results of “converting,” “routing,” “controlling,” “monitoring,” and “accumulating records,” but “does not sufficiently describe how to achieve these results in a non-abstract way,” and that, at best, the claimed constructions relied on generic computer components providing only a generic environment for carrying out the abstract idea.

Likewise, Recentive confirmed that it is proper at Step One to treat claims as abstract where the claimed “advance” is the use of an already available technology with its already available basic functions “as a tool” and where the claims disclose only that the technology is used in a new environment—and it adds that simply performing a task humans previously did “with greater speed and efficiency” (without improved computer techniques) does not change the eligibility outcome (expressly noting this point applies “[w]hether the issue is raised at step one or step two”).

###No Concrete “Computer Improvement”

GoTV argued the claims were directed to a computer/network improvement, but the court rejected that framing because the claims:

• do not recite new or improved hardware (server, device, or network);
• do not improve the wireless device’s rendering process (the device’s rendering capability is assumed and merely accommodated);
• do not improve ordinary computer operations such as receiving, storing, processing, outputting, and transmitting data.

Instead, the claim uses conventional computing and networking as tools to perform the templating-and-tailoring idea.

###“Technical” Labels Didn’t Change the Analysis

The court treated terms GoTV relied on (e.g., “wireless device generic template,” “custom configuration,” “page description,” and “rendering command”) as describing packages of information rather than specific technological structures or mechanisms that improve how computers or networks operate. In the court’s view, these terms did not provide the missing “how” needed to show a concrete improvement to computer functionality, as opposed to functional results.

##Alice Step Two: No Inventive Concept

Having found the claims directed to an abstract idea, the court proceeded to Step Two and held there was no inventive concept that made the claims “significantly more” than the abstract idea.

Key points driving the Step Two conclusion:

• The claims rely on result-focused, functional language (e.g., generate a template, tailor based on device capability, send descriptions/configurations) without specifying how tailoring is performed in a nonconventional way.
• The claims invoke ordinary server/network functions (receiving requests, assembling information, transmitting data) without any claimed improvement in how those functions are carried out.
• Any asserted improvements in speed or efficiency were attributed to using conventional computers and networks, which the court reiterated is not enough to confer eligibility.
• The court discounted reliance on GoTV’s expert declaration because conclusory assertions about inventiveness or performance gains, untethered to concrete claim limitations, do not supply an inventive concept.

##What This Means in Practice

###1) “Adapt content to device capabilities” remains § 101-sensitive

This decision reinforces that claims centered on tailoring content/display specifications to device constraints are vulnerable when they read as merely gathering information, generating a template, tailoring the template, sending it and transmitting it, all implemented using conventional computing and networking.

###2) Eligibility turns on the “how,” not the “what”

If the “advance” is adaptation/customization (templates, tailoring, optimization, personalization, ML-based selection), claims need to include the how, in the form of a concrete mechanism (specific algorithmic steps, data structure constraints, protocol-level changes, or a defined improvement to computer/network operation). Otherwise, a court can characterize the claim as result-oriented and “tool use” at Step One.

Even when claims use jargony language (“templates”, “configurations”, “rendering commands”), the court will look for a specific mechanism or a concrete improvement in computer/network functionality, rather than a desired outcome recited at a high level. For the prosecutors in the crowd, the appropriate claim drafting mantra is “how, not what.”

###3) Step two requires more than efficiency rhetoric

Assertions that the approach is faster, cheaper, or more scalable without claim language that concretely implements a technical improvement are unlikely to establish an inventive concept, especially on a record limited to intrinsic evidence and generalized expert opinions.

###4) Avoid field-of-use crutches:

Limiting claims to a “technological environment” (streaming, wireless rendering, event scheduling, network maps) is often treated as a new environment for an otherwise generic technique and does not, by itself, prevent an abstract-idea finding at Step One.

IPO 2025 just wound down, and wow … what a time. San Diego is a cool place that I haven’t been to since I was a wee lad – so it’s as if I was visiting for the first time.

It’s a bit weird that the entire place is cashless (seriously, you cannot pass a bill almost anywhere unless you get off the beaten path). That reminds me, I should take some pre-paid credit cards with me next year.

It also takes some getting used to that every time you look up, you see a military helicopter (or three) flying in formation, a nuclear-powered carrier looming across the harbor, or a destroyer go trawling by. Usually surrounded by a pack of jet skis.

At the same time, the weather is great, and the whole place is dipped in a SoCal vibe that’s kind of hard to put your finger on, yet unmistakable. I could not live in California for reasons, but I’d sure like to visit again.

As for the conference, the IPO annual meeting is as focused and professional as it gets, bringing together many of the best IP minds under one roof (which is more fun than it sounds like, promise). I was lucky to have several good meetings come together, both planned and unplanned. And I played pickleball for the first time ever, which on its own made the trip worth it.