Prompt Engineering Patterns for Patent Work

1. Role · Task · Format · Context

The foundational framework on which all other patterns build. Four sections in this order. Role sets the expertise perspective. Task states the concrete assignment. Format specifies how the answer should be structured. Context contains the input data, usually last, so the model first understands the assignment and then slots the data into that understanding.

# Role
You are a European patent attorney with 20 years of EPO practice.

# Task
Summarise the following patent description.

# Format
Write in flowing English, continuous text, no bullet points.

# Context
[The description text]

The ordering trick: role and task come first so the model knows how to read the context that follows. If you reverse the order, the model processes the patent description first and only learns the actual question at the end.

2. Prompt Chaining

Decompose a complex task into several small prompts whose outputs build on each other. A daily necessity in patent work: "Find the distinguishing feature over D1" is a different prompt from "What technical effect does that feature provide", and only together do they produce a complete argument.

Example for problem-solution development:

• Prompt 1: What is the distinguishing feature over D1?
• Prompt 2: What technical effect does this feature provide?
• Prompt 3: Formulate the objective technical problem.

Prompt chaining evolves into context engineering when the steps move into separate chats. See the dedicated context-engineering article.

3. Chain of Thought

Force the model to reason step by step before giving the answer. For complex questions like claim construction, doctrine of equivalents or disclosure analysis, this noticeably improves quality.

To answer this, proceed step by step:
1. What feature distinguishes the claim from D1?
2. What technical effect does this feature provide?
3. Formulate the objective technical problem.
Only then give the final problem-solution analysis.

Modern reasoning models (GPT-5 Thinking, Claude Opus with extended thinking, DeepSeek r1) do this implicitly to some degree. With standard models the explicit "step by step" is what separates a gut-feel answer from a traceable argument.

4. Few-Shot Prompting

Prepend two or three worked examples before the actual question. Works especially well for patterns that are hard to describe in words, such as the style of a feature decomposition, the structure of a claim-chart row, or the phrasing of a problem-solution statement.

Example 1:
Feature F1: "a housing"
Disclosure in D1: col. 3, line 5: "a housing"
Assessment: literally disclosed ✓

Example 2:
Feature F2: "thermally conductive"
Disclosure in D1: no mention
Assessment: not disclosed ✗

Now for feature F3:
[...]

Three examples are usually enough. More only burns tokens and barely improves the output. The examples should cover the real variation of the actual task, not repeat the same thing three times.

5. Self-Reflection

After the model has answered, you ask whether it is sure. Same chat. Sounds trivial, but it catches a surprising number of errors because the model approaches the second pass from a different angle.

Are you sure the feature is not disclosed in document D1, either
explicitly or implicitly? Review your own answer critically.

Self-reflection has a limit: the model checks its own answer, not the world. For hard fact checks you need a fresh chat with the source document, see pattern 7.

6. Devil's Advocate

Ask the model to attack its own answer or the draft under review with maximum vigour. The phrasing has to be sharp enough that the model does not retreat into politeness.

Give the five most important reasons why this claim set is rubbish.
No sugar-coating, no polite hedging.

Use cases: claim drafting (find your own weaknesses), opposition preparation (anticipate adversary arguments), FTO (design-around risks), office-action response (spot the weak points in your own argument). Especially strong when the attack chat runs separately from the drafting chat.

7. Fact-Checking with Verbatim Quotes

The single most important anti-hallucination pattern in patent work. Every statement that refers to a document must be backed by a verbatim quote with a reference. Forcing the model to supply those quotes is what separates "sounds plausible" from "actually there".

Is feature F3 disclosed in document D1? Support your answer with
verbatim quotes from the document. If you cannot find a quote,
say "not disclosed". No paraphrases.

Follow-up prompt:
Critically review your previous answer. Do the quotes you gave
match the document verbatim? Repeat each quote with its paragraph
number.

See also the dedicated articles on duty of evidence and paragraph-by-paragraph review, which apply the pattern at scale.

8. Structured Output

Prescribe the format the answer has to use. XML tags, Markdown tables, JSON schema. That makes the output machine-processable but also easier to scan for humans.

Use the following output format:
<UM>State the distinguishing feature in the original wording,
starting with: "Claim 1 differs from D1 in that..."</UM>
<Reason>Justification for your decision</Reason>
<Cite>Reference in D1</Cite>

The tighter the format, the less the model can wriggle out. For feature decomposition, claim charts, disclosure matrices and risk tables this enforces a completeness that would quietly slip in flowing prose.

Combining patterns in practice

The patterns stack. A typical office-action analysis combines Role-Task-Format-Context with prompt chaining (each reference separately), chain of thought (develop the argument step by step), few-shot (examples of the desired argumentation style), devil's advocate (anticipate weaknesses of the response), fact-checking with verbatim quotes (support every claim), and structured output (as a table with claim, objection, response, source).

The ordering is not arbitrary. Role-Task-Format-Context always comes first. Chain of thought and structured output work particularly well together. Self-reflection and devil's advocate are verification steps and come at the end. Fact-checking runs in parallel to everything, preferably in a separate chat.

Connection to the other articles

• Context engineering: how the patterns are orchestrated across multiple chats.
• Context management: why a fresh context outperforms a clever pattern in a poisoned one.
• Multi-model workflows: self-reflection and devil's advocate in their extreme form, with separate models.
• Duty of evidence: the discipline behind pattern 7.