Technical Description Checklist
Twenty properties of a clear technical description of how something works, each with a prompt to write against. Run it on your own write-up before you hand it to a patent attorney or agent. Read it below, copy it, or download it.
What this checklist is
An engineering check on a piece of writing. Each item names a property of the text: something a reader can find in it or not find in it. A design document, a README section, a technical note or an idea disclosure can all be run through it.
It asks nothing about protection and gives no score. Where an item does not apply (an idea with no screen has nothing for item 10), skip it. The blanks are the useful output: each one is a question the next reader would otherwise have to ask you. It is not legal advice.
How to use it
- Start with the three effort questions. They decide whether to lead with steps or with parts, and where the background goes.
- Then go item by item against your text, not from memory. Quote the sentence that answers an item, or write "not yet".
- Read it cold at the end. The last group asks whether someone who has not seen the work could follow it.
The Checklist
Before You Start: Where to Put Effort
Three questions about the shape of the idea. The answers change the order you write in, not what you include.
Is the screen part of how it works?
Is part of how the idea works what a person sees and does at a screen, so that the mechanism cannot be described without it? If yes, give item 10 the same care as the parts and steps, and describe each screen at the point in the sequence where it appears.
Does a reader need background first?
Would someone in the idea's field need a problem, a setting or a concept explained before the mechanism makes sense? If yes, put that explanation in a short section of its own, before items 4 to 11.
Steps or parts?
Is the core of the idea a sequence of operations, rather than an arrangement of parts? If yes, lead with the steps (items 5 to 7) and describe each part where a step uses it. If it is an arrangement of parts, lead with the parts (item 4) and how they connect.
What It Is, and What It Answers
1. A short statement of what it is and does
A few sentences a colleague could read first. Say what it does and how it is built (its steps, or its parts and how they fit), not only what it achieves. Write: the statement, then check that it names a mechanism and not just a result.
2. The problem, and which part of the idea answers which part of it
Name each difficulty on its own, then point to the part of the idea that deals with it. A difficulty with no matching part, or a part with no difficulty, is worth a second look. Write: one line per difficulty, each ending with the part that answers it.
3. How it differs from the way it was done before, why it works, and what it costs
Describe the earlier way you know of in a sentence or two, then what changes, and why the change produces the effect. Include what it gives up: speed, memory, accuracy, simplicity. Write: before, after, why, and the cost.
How It Works
4. Each part
What it is made of, what it does, what it connects to, with its properties, its modes and how many there may be. Write: a list of the parts, and under each one those points, leaving a visible blank where you do not know.
5. Each step
How it is carried out, in what order, and what starts it. Naming a step is not describing it. Write: for each step, a sentence on how it is done. If a sentence only names the step ("the records are normalized"), add how.
6. Each decision or computed value
What it is based on and how it is worked out. For a threshold, a formula, a lookup or a ranking, give the rule and its values. If the decision is learned, say what the model takes in, what it predicts and any threshold applied to its output. Write: one entry per decision or value.
7. Conditions
What changes under which condition, what is skipped in which case, and what always holds. Write: each "if" in plain words with what happens otherwise, then the things that are true in every case.
8. The data
What each item holds, in what form, where it comes from, where it is kept and where it goes. Write: one line per item of data that passes between parts or is stored.
9. What each part runs on, and where it runs, where that choice matters
Name the hardware, software or service when the choice changes how a part works. When it does not, say the part works the same wherever it runs. Write: for each part, what it runs on and where, or "any".
10. What a person sees and does at each point
Wherever a person is involved, what is shown to them and what they do next. Write: walk through one session from the user's side, screen by screen or command by command.
11. How it can fail, and what guards against it
Bad input, an absent value, a step that times out, a service that is down. Write: for each failure you know of, what the idea does then.
One Version, Then the Others
12. One version described end to end
One whole version, from its first part to its last, with nothing left as "and so on". Write: pick one version and describe it fully before you describe any alternative.
13. A worked case
One input followed to its output with real values, and what has been built or measured. Write: one example with actual data at each step, then what exists today (a prototype, a test, a benchmark) and what it showed.
14. The version you use or would build first, and why
Where the text describes more than one way, say which one you use or would build first, and the reason. Write: the version, and a sentence or two on why.
15. More than one way, and what each general part can be
A general term (a store, a device, a model) is paired with what it can be in practice. Other ways of building it tell a builder which substitutions still work. Write: for each general term, the concrete things it can be; then any other way the whole idea could be built.
16. The values that still work, and which values a person can set
For each value the idea depends on (a size, a rate, a threshold, a count), the range in which it still works, and whether a person can change it. Write: the value, its working range, its default, and whether it is a setting.
Read It Cold
17. Terms that mean one thing
Each term is defined where it is first used and used in one sense. Write: the terms a newcomer would not know, each with a one-line definition; then find every use of each term and check it means the same thing every time.
18. Drawings where they help, each drawn part described in words
A block diagram, a flowchart, a sequence diagram or a screen, where a reader would follow it more easily than prose. Every part shown in a drawing is also described in the text. Write: a list of drawings, and for each labelled part, where the text describes it.
19. The description stands on its own
What it relies on is in the text, not only in a linked document, a repository or the code. Write: every link, repository, document or dataset the text points to, and for each one, in words, what the reader needs from it.
20. Buildable from the text
Someone in the idea's field could make it and run it from the description alone. Write: give it to a colleague who has not seen the work and list every question they have to ask. Each question marks something the text does not yet say.
Where the list comes from
The twenty items are derived from a reading of 32 US software patent families, each a provisional application and the non-provisional that followed it. Seventeen restate kinds of content those documents carried; three (items 12, 14 and 20) restate what the rules on a technical description's content set out, which does not make this checklist a test of those rules.
The sampling, the definitions and the limits are on How we read these filings. It is 32 families of software filings, not a survey of practice.
Why these properties
For 24 of those 32 families, the reading compared the provisional with the application that followed it, element by element, and recorded which content in the later document the earlier one had not stated. After a provisional written as an informal technical write-up, definitions of terms were the kind most often classified as additional, ahead of examples of what a general part can be, descriptions of what each figure shows, and alternative ways of doing something. Items 17, 15 and 18 ask for those. Calculation and mapping rules, and descriptions of how an operation is carried out, were less frequent but stood out sharply against the other forms; items 6 and 5 ask for those.
"Additional" there means the later document said something the earlier one did not. It does not mean the earlier one was deficient, and nothing on that page or this one measures what any document needed. The figures, each with its own denominator, are on What real provisional applications contain.
Frequently Asked Questions
Who is this checklist for?
Engineers, founders and researchers who have written, or are about to write, a description of something they built. It works on any technical write-up. The idea is to find the questions a reader would ask before anyone else has to ask them.
Does a description that answers every item get me a patent?
No. The checklist describes properties of a piece of writing. Whether anything is worth protecting, and whether a description supports what a practitioner later writes, are decisions for a patent attorney or agent. Answering every item tells you the writing has these twenty properties, and nothing more.
How is this different from the Disclosure Quality Check?
This checklist works on the technical description itself, property by property: parts, steps, decisions, data, versions and terms. The Disclosure Quality Check is a final pass over the whole disclosure before you hand it off: an enablement self-check, wording, figures, inventorship, public-disclosure dates and ownership. Its enablement self-check overlaps item 20 here. Use this one while you write, and that one when you are done.
Do I have to answer all twenty items?
No. Some will not apply to your idea, and a visible "not yet" is more useful than a guess. The three effort questions at the top help decide which items carry the most weight for the idea you have.
Related
- Idea Disclosure Template, the plain-language form this checklist can be run against
- Disclosure Quality Check, a final pass over the whole disclosure before handoff
- What real provisional applications contain, the figures behind "why these properties"
- How we read these filings, the sampling, the definitions and the limits
- How to write a patent disclosure
- What software applications carry, kind by kind: the inventory behind the checklist, with counts
Scope. Completing this checklist does not create patent rights, establish a filing date, or show that a description is enough for any purpose. It describes properties of a piece of writing. Rules can differ by country.
Disclaimer. This checklist is used solely to document, organize, and describe a technical idea. It and any output are for informational and technical-documentation purposes only and are not a substitute for advice from qualified intellectual property counsel. Use of this checklist does not constitute legal services or legal, patent, patentability, inventorship, ownership, claim-drafting, filing-strategy, deadline, or freedom-to-operate advice, and does not create an attorney-client relationship with Obviously Not. Intellectual-property protection can be time-sensitive: public disclosure, product release, open-source publication, sale, offer for sale, demo, or other external sharing may affect available rights. You are solely responsible for promptly consulting qualified intellectual property counsel about any legal or IP issue.