How to describe your invention for a prior-art search (2026)

The quality of a prior-art search depends more on how you describe your invention than on the search engine running it. “An AI that does legal stuff” returns a thousand irrelevant hits; “a transformer-based classifier that extracts §102 rejection arguments from USPTO office actions and maps them to claim numbers” returns the five patents you actually need to read. This post is a concrete playbook for writing the second kind of description.

Why the description matters

A modern prior-art search engine (ours included) runs two passes. The first is keyword-based: it tokenises your description and matches against patent text databases. The second is semantic: it embeds your description as a vector and compares against embeddings of candidate references. Both passes reward specificity and punish vagueness. “Novel method” matches every patent ever written; “key-schedule shortcut for post-quantum resumable TLS” matches the handful your invention actually competes with.

A good description is also what forces you to think clearly about your own invention. Half the value of running a prior-art search is the 30 minutes you spent writing the search query — the discipline of reducing your idea to 3-5 sentences often exposes gaps you didn't know you had.

The five-ingredient recipe

A description that actually searches well has five ingredients:

1. The technical field. One or two words that place the invention in a category. “Cryptography”, “medical imaging”, “supply chain management”. This is what gets you into the right classification bucket during keyword search.
2. The problem it solves. One sentence describing the technical shortcoming in the status quo. “Post-quantum TLS handshakes are 3-5× slower than classical ones because they re-derive the full key schedule on every resumption.”
3. The inventive mechanism. The novel bit — what your invention actually does that prior art doesn't. This is the most important part. “The client caches an intermediate key-schedule state, authenticated with a PQ signature, so resumption only re-runs the final three rounds.”
4. The concrete parameters or components. Specific names, numbers, protocols, algorithms. “TLS 1.3”, “ML-KEM”, “SHA-256”, “HKDF”. These are the highest-value search tokens because they're also in the patent databases.
5. The differentiating outcome. What this lets a user do that previously wasn't possible. “Sub-5-ms post-quantum session resumption on mobile devices.”

A worked example

Say you're filing on a novel compiler optimisation. A bad description:

A compiler feature that makes programs run faster. The invention is a new technique I developed for optimising loops.

This matches literally thousands of compiler patents — it has no technical field beyond “compiler”, no problem statement, no mechanism, no components, no outcome. Now the same invention rewritten with the five ingredients:

A compile-time loop transformation for JIT compilers targeting ARMv9 that detects loop-carried dependencies on SIMD-writable memory and automatically inserts store-to-load forwarding via SVE2 gather-scatter instructions. Unlike existing LLVM auto-vectorisation passes which require dependency-free inner loops, this invention handles pointer-aliased store/load pairs by speculatively executing with a rollback table. Benchmark: 2.3× speedup on SPEC CPU 2017 vector kernels on Apple M3.

Now the keyword pass matches documents containing “loop-carried dependencies” + “SVE2” + “store-to-load forwarding” — a dramatically tighter candidate set. The semantic pass can compare the invention's overall mechanism to published LLVM-optimisation literature. Both return useful results.

Common mistakes we see

• Marketing language. “Revolutionary”, “best-in-class”, “industry-leading”. Strip these. They have zero token value and they make the semantic embedding less specific.
• Company/product names. “Our AuthFlow product” matches your own marketing pages, not prior art. Describe the invention, not the shipped SKU.
• Too general. “A machine learning system for medical diagnostics” covers 50,000 patents. Narrow to the specific technique: “A convolutional neural network trained on dermatoscopy images for classifying melanocytic nevi using the Menzies 7-point checklist as an auxiliary loss.”
• Too narrow. Over-specifying the implementation can exclude relevant art. “Using exactly 12 convolutional layers” hides art that used 10 or 15 layers but has the same core idea. Describe the mechanism at the level of generalisation a §103 obviousness argument would use.
• No problem statement. If you don't say what broke before, the engine can't match papers about the broken state of the art. Always include the “because X doesn't work” sentence.

Length and structure

Aim for 3–8 sentences, 80–250 words. Shorter than that and you don't have enough tokens for the semantic embedding to discriminate; longer and you start introducing irrelevant noise that dilutes the signal.

Structure the paragraphs: field + problem (sentence 1), mechanism + components (sentence 2-4), outcome (last sentence). You don't need headers or bullet lists — flowing prose works better for both the tokeniser and the embedding model.

The iteration loop

Run the description through 50search. Read the top 10 results. If three or more of them feel off-topic, your description is too general — add a specific component or parameter. If the top 3 look spot-on but numbers 4-10 are noise, your description is fine; the field is just competitive. If the top 10 look unrelated, your description may be too narrow or using jargon the databases don't index — substitute standard terminology (e.g. “gradient boosting” over “decision-tree ensemble additive”).

You can run a search as many times as you want — searching is free.

A template you can copy

Paste this into the 50search prompt box and fill the five placeholders. It's not rigid grammar; adapt as needed:

A [FIELD] invention that [MECHANISM + COMPONENTS]. Unlike [EXISTING APPROACH], which [SHORTCOMING], this invention [DIFFERENTIATING BEHAVIOUR]. The outcome is [CONCRETE RESULT].

The bottom line

Prior-art search is signal-in-signal-out. A specific, 5-ingredient description returns a specific set of references you can actually read and compare against. A vague description returns noise that wastes a day of your time. The 30 minutes you spend writing the description properly saves you 3 hours of sifting through useless hits.

When you're ready, run a free prior-art search — no account required. If you're on your first search, read the prior-art playbook for the database-selection + result-reading workflow that follows query-writing.