Paragraph-by-Paragraph Review
Systematically through the entire document, not just the model's intuition. A pattern for long patent specifications, office actions and prior art.
Core message: LLMs tend to skim. They grab prominent places (opening paragraphs, claims, abstract) and build a summary that sounds plausible but misses important side passages. Paragraph-by-paragraph review forces the model into a systematic pass where each paragraph produces its own output. It is the most reliable way to prevent things from being overlooked.
Why skimming is dangerous in patent work
Patent specifications often carry their most important substance where the model does not expect it. An alternative embodiment that covers exactly the design-around sits in paragraph [0047] between two less relevant examples. A limitation that carries the Art. 123(2) basis is tucked into the figure description instead of the general description. A prior-art document discloses the critical feature not in the claim but in a technical background section.
A model asked to "summarise the document" typically grabs the prominent places and subordinates the rest. The critical side passages fall through the cracks. For an infringement analysis, an opposition or an FTO triage, that is a non-starter. Paragraph-by-paragraph review removes that asymmetry.
The pattern
Go through the document front to back. For each paragraph: number, one-sentence summary, explicit assessment against the review question. No jumps, no omissions.
The core idea: the model produces a structured output per paragraph. That makes skipping visible (a missing paragraph in the output means it wasn't read) and the review repeatable (a different question runs the same pass with a different assessment column).
How to enforce it in the prompt
- Paragraph anchor: "Go through the patent specification paragraph by paragraph, in the order [0001], [0002], [0003] …" For unnumbered documents: "Go through the document paragraph by paragraph. Number them yourself as §1, §2, §3 …"
- Table format: "Return the result as a table with columns Paragraph / One-sentence summary / [review question]." For example: "Paragraph / Feature M3 mentioned? / Quote if yes". A table is easier to audit than free text.
- Completeness check at the end: "At the end: confirm that every paragraph from [first] to [last] appears in the table. If a paragraph is missing, name the number and add it."
- Explicit no-finding rule: "If a paragraph is irrelevant to the review question, still enter the number with 'not applicable'. Do not skip paragraphs."
Applications in patent practice
- Scanning a patent specification for a feature. Review question: "Does this paragraph mention feature M3 or an alternative?" Output: a table with paragraph number, short answer, and the verbatim quote if yes. Typical for claim construction, feature breakdown, equivalence search.
- Working through the objections in an office action. Review question: "Which claim parts does this section address and which documents does it cite?" This produces a gap-free map of objections before the defence begins.
- Checking a prior-art document for disclosure of M1 through M7. Review question per paragraph and per feature: hit yes/no plus quote. Especially effective for long, technically dense documents where a feature is often only disclosed in passing.
- Walking through a patent file history. Review question: "What was changed in this submission relative to the previous version, and where is the basis?" Lays the groundwork for Art. 123(2) arguments.
- Mapping a long client specification to product features (FTO). Review question: "Which product feature does this paragraph describe, and are there wording variants?" Produces the feature list for the search.
Anti-patterns that undo the review
- "Summarise the patent specification." The classic unstructured instruction. The model grabs the abstract and the claims and ignores the rest.
- Free text instead of a table. Without a table, omissions go unnoticed. A model can skip two paragraphs and still deliver coherent prose.
- Too many review questions in parallel. If the prompt asks five questions at once, the table grows wide and unreadable. One pass, one question. Multiple passes if needed.
- Chunking by character count. When the specification exceeds the context window, it must be processed in parts. The split has to happen at paragraph boundaries, not at fixed character positions, otherwise you slice a sentence in half.
- No completeness check at the end. Without an explicit confirmation, you don't know if the model actually reached paragraph [0047].
Why agents do this automatically better
Manual paragraph-by-paragraph passes in a chat UI are tedious and error-prone. A Claude Code or OpenCode skill can split a document into paragraphs programmatically, fire an LLM call per paragraph and consolidate the table. That scales to 300-page files without the typical weaknesses of manual long-context prompting. See the patent plugin for concrete skill implementations.
Connection to the other pillars
Paragraph-by-paragraph review is one of the four pillars for prompt engineering in patent practice. The interplay:
- Context management: the pass only makes sense with a clean context. Otherwise the model mixes paragraphs from multiple documents.
- Duty of evidence: every row in the table contains a verbatim quote. The pass generates the evidence automatically.
- Self-reflection + devil's advocate: a reviewer model runs the same pass in parallel and flags discrepancies. Especially powerful on critical workflows.
Newsletter
Stay up to date on generative AI in patent practice.
Join the GenAI Newsletter