Invention Disclosure Template: The Complete Starter Pack

Not legal advice. For best results, review with a registered patent attorney.

Who is this for

  • R&D teams needing a repeatable intake format
  • In‑house IP managers coordinating multiple business units
  • Outside counsel alignment to reduce back‑and‑forth and cycle time

What is an Invention Disclosure

  • An internal, technical document used to capture the substance of an invention so counsel can evaluate patentability and draft claims.
  • It is not a patent application and does not require claim language or formal legal citations.
  • Goal: completeness, clarity, and enablement so a person skilled in the art can practice the invention once claims are scoped.
  1. Title and Summary
    • 1–2 sentences that capture the inventive concept and the problem it solves.
    • Elevator pitch for IP review boards.
  2. Problem, Prior Art, and Advantages
    • Describe the problem and current approaches (papers, products, known methods).
    • Explain limitations in prior art and the measurable advantages of your approach.
  3. Technical Details and Embodiments
    • Architecture, components, data flows, materials, parameters, control logic.
    • At least one complete working embodiment, with steps and dependencies.
  4. Variations, Alternatives, and Edge Cases
    • Implementation variants, fallbacks, tunable parameters, trade‑offs.
  5. Drawings/Diagrams
    • Block diagrams, flowcharts, sequence/state diagrams, mechanical drawings.
    • Label parts and reference them in text for consistency.
  6. Enablement considerations
    • Materials, methods, parameter ranges, tolerances, environmental conditions.
    • Negative results and boundary conditions that informed the design.
  7. Commercial Context (optional)
    • Intended use cases, target users, deployment constraints, regulatory notes.

Writing Guidance and Prompts

  • Be specific: replace “fast” with “reduces latency from 120ms to 35–50ms under load X.”
  • Define terms once; add a simple glossary if domain‑specific jargon is used.
  • Reference artifacts: dataset versions, firmware versions, CAD filenames, API spec commits.
  • Prompts to get started:
    • Problem framing: “What concrete failure or cost exists in today’s solutions?”
    • Prior art: “Name 3 closest methods/products and their weaknesses.”
    • Enablement: “List parameters (with ranges) that materially affect outcomes.”
    • Variants: “If component A were unavailable, how else could we achieve B?”

Industry Variants

  • Software
    • Include: system topology, data schemas, API contracts, time/space complexity, concurrency, caching/consistency model, security boundaries.
    • Artifacts: sequence diagrams, REST/gRPC specs, benchmark scripts and results.
  • Medical devices
    • Include: materials, sensors/actuators, power limits, latency bounds, sterilization/biocompatibility notes, human‑factors constraints.
    • Artifacts: bench test protocols, calibration data, risk mitigations.
  • Biotech
    • Include: organism/strain/cell line, media, temperature/pH ranges, timings, controls, readouts, statistical methods.
    • Artifacts: lab notebook references, assay protocols, sequencing IDs.
  • Mechanical/Robotics
    • Include: tolerances, loads, duty cycles, kinematics, control loops, environmental ratings.
    • Artifacts: exploded diagrams, BOM, firmware versioning, simulation files.

Minimal Working Example (MWE)

Provide one fully‑specified path to practice the invention:

  • Inputs and preconditions
  • Step‑by‑step procedure (numbered)
  • Expected outputs and acceptance criteria
  • Failure modes and recovery

Downloadable Templates

  • General template (DOCX/PDF) – coming soon
  • Software variant – coming soon
  • Medical device variant – coming soon

Next Steps