Invention disclosure form: editable template and worked example
May 8, 2026
An engineering team may have a working prototype, design slides, and test results without a usable invention disclosure. Patent counsel then has to reconstruct the mechanism, identify each person's contribution, and recover disclosure dates from scattered records. A reusable form gives that conversation a structure. A completed engineering example shows how to separate supported facts, proposed variants, and unanswered questions, while AI-assisted intake can help organize the materials your team already has.
Scope: This educational intake starting point supports counsel's matter- and jurisdiction-specific review.
What is an invention disclosure form?
An invention disclosure form (IDF) is an internal record that explains a proposed invention and preserves the facts needed for technical and legal review. It connects research and development (R&D) work to your intellectual property (IP) team and patent counsel: what problem arose, how the proposed approach works, who contributed what, and what has already been shared.
It is separate from a patent application. It is also separate from a U.S. Information Disclosure Statement, which submits patents, publications, or other information for patent-office consideration during prosecution.
Forms vary by organization. For example, Stanford's disclosure process captures the technology, people involved, sponsorship, and disclosure history, with a separate sponsorship review. Your form should preserve those kinds of facts without asking engineers to make legal determinations.
Patlytics' Invention Disclosures (IDF) module supports document-based or spoken intake and template-driven sections. The same factual discipline applies whether you complete a form manually or review an AI-generated draft.
Editable invention disclosure form template
Download the editable Word form, or copy the plain-text Markdown form. Both include expandable responses, contributor and disclosure-event tables, a source register, an open-question log, factual confirmations, and a counsel-handoff record.
Use exact dates where known and label estimates. Use unknown, not provided, pending, or not applicable when appropriate. “None” means the relevant facts support that answer. Keep confidential technical material in your organization's approved intake environment.
| Field | Blank response and prompt |
|---|---|
| 1. Record and contact | Response: ______ Title, internal record ID, project, submitter, work contact, submission date, version, and internal access designation. |
| 2. Technical problem | Response: ______ What failed or limited the current approach? Describe the operating environment, baseline, and constraints. |
| 3. Technical solution and operation | Response: ______ Identify components or process steps, inputs, interfaces, parameters, outputs, and failure behavior. Explain the sequence in enough detail for a technical discussion. |
| 4. Candidate distinguishing features | Response: ______ What specific differences does the team see relative to its known baseline? Separate observed results from expected benefits. Add a source locator for each difference. |
| 5. Embodiments and alternatives | Response: ______ Describe the implemented version, necessary and optional elements, substitutes, and other uses. Label each version tested, proposed, or speculative. |
| 6. People and contributions | Response: ______ For each person, record name, employer or affiliation, work contact, technical contribution or activity, date, and source. Separately identify people for counsel to consider as possible inventors. |
| 7. Development chronology | Response: ______ Record important design, build, test, and revision events, their dates and locations, and supporting record owners. Identify approximate or disputed dates. |
| 8. Evidence and limitations | Response: ______ Record test setup, measured results, failed cases, untested conditions, and attachment locations. State what the evidence does and does not support. |
| 9. Known related work | Response: ______ List known products, publications, patent documents, or internal approaches, with identifiers and relevant passages. Record any search already performed and its scope, or state that no search is reported. |
| 10. Business, funding, and agreements | Response: ______ Intended use, development plans, business owner, known sponsors or grants, outside collaborators, third-party materials, and agreement references. Record unresolved funding or rights context. |
| 11. Actual and planned external events | Response: ______ For every publication, presentation, demonstration, sale, offer, customer discussion, or other release: date, recipients, channel, material shared, access restrictions, and known confidentiality-agreement reference. Include planned events. |
| 12. Source register and missing information | Response: ______ Assign each attachment an ID, version, owner, and page or section locator. For every gap, record the question, answer owner, needed record, and follow-up date. |
| 13. Factual confirmation and counsel handoff | Response: ______ Record each contributor's factual confirmation, corrections, and limits. Identify the counsel recipient, handoff date, questions requiring legal review, and authorized next step. |
Keep the contribution roster broader than a tentative inventor list. In U.S. practice, inventorship depends on conception of claimed subject matter. Give counsel the contribution narratives and supporting records for a claim-specific inventorship assessment.
Completed hypothetical engineering example
All names, records, dates, results, and confirmation entries in this example are invented. No actual engineering tests or legal reviews occurred. The example illustrates a completed intake record with explicit unknowns, rather than a patentability conclusion.
Download the completed Word example to keep the responses and source trace together.
Example source packet
The hypothetical source packet contains the underlying sample records. Its identifiers make each answer traceable:
- S1: Project brief, version 1, April 3, 2026. Problem, current approach, and intended use.
- S2: Controller design note, version 2, April 9, 2026. Inputs, sequence, parameters, alternatives, and limits.
- S3: Bench-test report, version 1, May 2, 2026. Setup, observations, and untested conditions.
- S4: Contribution and development log, version 1, May 4, 2026. People, activities, dates, and sample confirmation entries.
- S5: Project administration and event log, version 1, May 4, 2026. Funding context, external events, and handoff state.
Completed form and source-to-field trace
| Field | Completed hypothetical response | Source and remaining gap |
|---|---|---|
| 1. Record and contact | Title: Pressure-aware filter-maintenance controller for an electronics cabinet. ID: HYP-026. Project: Cabinet cooling. Submitter: Priya Rao, controls engineer, Example Engineering Group; priya@example.invalid. Submitted: May 4, 2026. Version: 1. Access: Internal, restricted to the project and IP team. | S5 §1. Contact and company are fictional. |
| 2. Technical problem | The existing cabinet uses scheduled filter replacement. A pressure reading during fan operation can reflect filter restriction or sensor offset. The team wants a maintenance signal that distinguishes these conditions. Fan pauses are permissible only in the bench setup; live-cabinet thermal constraints are unresolved. | S1 §§1–2; S2 §4. Live-cabinet operating limits are pending. |
| 3. Technical solution and operation | A differential-pressure sensor measures across the filter. The controller samples pressure with the fan stopped, then at a known fan speed. It subtracts the stopped-fan reading from the running reading and compares the corrected value with a speed-indexed threshold. At 2,000 revolutions per minute (RPM), a value above 50 pascals (Pa) for 30 seconds triggers a maintenance alert; below 40 Pa for 60 seconds clears it. A stopped-fan reading outside ±5 Pa instead raises a sensor-review flag and suppresses the filter alert. | S2 §§1–3. Other-speed calibration entries are not provided. |
| 4. Candidate distinguishing features | Relative to the team's scheduled-replacement baseline, the proposed differences are a stopped-fan offset sample, a speed-indexed comparison, separate fault handling, and persistence periods before alert changes. The team expects more informative maintenance signals. No comparative field-performance result or novelty assessment is reported. | S1 §1; S2 §§2–3; S3 §3. Benefit remains an expectation beyond the bench cases. |
| 5. Embodiments and alternatives | Bench-tested: 24-volt fan, differential-pressure sensor, and controller with the stated thresholds. Proposed: calibration at other fan speeds. Speculative: 2 separate pressure sensors replacing the differential sensor. Pressure sampling, comparison logic, and output states are central to this design; display location is optional. | S2 §4; S3 §1. The separate-sensor variant and other speeds are untested. |
| 6. People and contributions | Priya Rao: proposed stopped-fan offset sampling on April 3. Julian Chen, firmware engineer: proposed persistence timing and implemented state logic on April 9. Morgan Ellis, test engineer: assembled the rig and ran specified tests. All are fictional employees of Example Engineering Group; work contacts are recorded in S4. The submitter asks counsel to consider Priya and Julian as possible inventors and includes Morgan's activities for review. | S4 §§1–2. No legal inventorship determination has been made. |
| 7. Development chronology | April 3: problem and sampling proposal recorded. April 9: controller design revised. April 20: rig assembled. May 2: bench cases run. May 4: intake record prepared. All events occurred in the fictional team's Lab A. These are record dates, with no earlier idea date asserted. | S4 §2. Earlier undocumented discussions are unknown. |
| 8. Evidence and limitations | At 2,000 RPM and 23°C, corrected pressure was 20 Pa with a clean filter and 65 Pa with a restriction screen. The restricted case triggered after 30 seconds. An injected +8 Pa sensor offset produced a sensor-review flag and suppressed the filter alert. The clean case cleared the alert after 60 seconds. Only 1 rig, 1 speed, and 1 temperature were tested; leakage, thermal safety, and long-term drift were not evaluated. | S3 §§1–3. No production reliability or general performance claim is supported. |
| 9. Known related work | The team knows its scheduled-replacement cabinet design, documented in S1. No external patent or publication references have been supplied, and no prior-art search is reported. This is an information gap, not evidence that relevant work is absent. | S1 §1; S5 §2. Related-work collection is assigned to the project team for counsel's scoped search. |
| 10. Business, funding, and agreements | Intended use: filter-maintenance indication in industrial electronics cabinets. Business owner: fictional product manager Alex Park, alex@example.invalid. A live-cabinet evaluation is proposed; cost and schedule are unapproved. Internal project funding is reported. No grant, sponsor, or outside collaborator is listed in the project ledger. Purchased sensor terms have not been provided. | S1 §3; S5 §2. Agreement review and third-party terms are pending. |
| 11. Actual and planned external events | April 28: Morgan emailed an assembly drawing to a fictional outside machining vendor. The vendor's confidentiality-agreement reference is unknown. May 15: a customer demonstration is planned; recipients and final slides are pending. The team reports no publication, sale, or offer in the event log, but has not reconciled every participant's calendar. | S5 §3. Obtain the sent drawing, agreement, recipient list, and final demonstration materials. |
| 12. Sources and missing information | S1–S5 are listed with owners, versions, and locators. Open items: fan-pause safety, other-speed calibration, earlier discussions, purchased-component terms, vendor disclosure facts, and demonstration details. Owners and requested response dates appear in the gap log below. | S2 §4; S3 §3; S5 §§2–4. No blank answer has been treated as “none.” |
| 13. Factual confirmation and counsel handoff | Sample confirmation entries dated May 4: Priya confirms the sampling description and flags thermal limits; Julian confirms the implemented thresholds and marks other-speed calibration pending; Morgan confirms only the reported bench observations and requests vendor-document follow-up. Counsel recipient: organizational IP intake queue, individual unassigned. Handoff requested May 4. Counsel review has not occurred; no search or drafting is authorized in this example's process. | S4 §3; S5 §4. Contribution, disclosure, agreement, and next-step questions remain open. |
The trace prevents a plausible design proposal from becoming an asserted result. For example, S2 supports the proposed multiple-speed embodiment. S3 supports observations at only 2,000 RPM. Combining them into “tested across fan speeds” would misstate the record.
Missing-information checklist and review handoff
A useful checklist records an actionable question for every unknown. For the hypothetical example, the open-question log is:
| Missing information | Question and needed record | Owner and requested date |
|---|---|---|
| Operating limits | Under what live-cabinet conditions can the fan pause? Provide the thermal assessment. | Priya, May 6. |
| Untested embodiments | Which speeds have calibration values, and were they tested? Provide the calibration table and any reports. | Julian, May 6. |
| Development history | Were there earlier discussions or technical contributions? Provide dated notes and individual accounts. | All contributors, May 6. |
| Third-party terms | What purchased-component or vendor agreements apply? Provide the relevant terms and agreement records. | Alex, May 5. |
| External events | Exactly what was sent on April 28, to whom, and under what access terms? What will be shown on May 15? | Morgan and Alex, May 5. |
| Legal next step | Which contribution, timing, and rights questions require follow-up before a scoped search or drafting assignment? | Assigned patent counsel, upon handoff. |
Use these recommended organizational checkpoints before commissioning prior-art analysis or application drafting.
1. Obtain factual inventor and contributor confirmation
Each proposed inventor and relevant contributor reviews their own contribution narrative and the technical facts within their knowledge. Record the name, date, corrections, and unresolved points. A reusable confirmation is:
I have reviewed the technical description, my recorded contribution, and the development and disclosure events within my knowledge. My corrections and uncertainties are recorded in the open-question log. This confirmation concerns factual accuracy, not a legal inventorship determination.
This intake confirmation is separate from the U.S. application-stage inventor oath or declaration. Avoid asking someone to confirm measurements they did not observe or events they cannot account for.
2. Hand the record to patent counsel
Send the versioned form, source packet, confirmation record, gap log, and actual or planned external-event details to the named counsel recipient. Flag imminent events immediately, even if technical responses remain incomplete.
Counsel reviews the contribution narratives, disclosure facts, jurisdictional context, agreements, and proposed next step. Capture dates as facts for that review. The legal effect of a disclosure differs across jurisdictions, as WIPO's patent guidance explains; a form should not calculate a universal filing deadline.
3. Record the scoped next assignment
Counsel may request more facts, authorize a defined prior-art search, or assign drafting with documented limits. Record the recipient, reviewed version, permitted task, scope, and remaining questions. Give counsel the search results and technical record to assess relevant earlier disclosures, evaluate patentability, and set the drafting scope. Application preparation requires a separate patent-drafting review.
How AI-assisted invention intake fits the process
Inventors often describe their work through presentations, drawings, test reports, and technical discussions. Asking them to recreate every detail in a questionnaire adds a translation step. AI-assisted intake can organize supplied material into a draft and support follow-up questions, while inventors confirm the facts and attorneys retain review and decision authority.
Keep the source register and open-question log with the draft. Label a proposed embodiment as proposed. Preserve conflicts between records until the relevant person resolves them. An unanswered field should remain visible instead of being filled with a plausible assumption.
Where Patlytics fits
Patlytics' Invention Disclosures (IDF) module supports the intake workflow:
- Capture facts with document or spoken intake: Start a blank disclosure, upload DOCX, PDF, or PPT materials, or speak an idea. Guided intake asks clarifying questions and organizes responses into structured sections.
- Standardize the record with custom templates: Use the default template or a custom DOCX or PDF template. Add, rearrange, or remove sections to match your organization's form.
- Review editable drafts and status: Edit the generated draft inline, mark the disclosure “drafted” for submission, and track status in the editor.
- Review related submissions with cross-disclosure deduplication: The module flags overlapping disclosures across submissions for corporate IP teams to review.
- Hand off with DOCX export and Patent Drafting: Export a DOCX for offline review or upload to an intellectual property management system (IPMS). Launch Patent Drafting from the same workspace for the next assignment.
Inventors confirm the technical facts; attorneys review the disclosure and direct the next assignment.
See how Patlytics turns inventor slides, test reports, or a spoken idea into a disclosure counsel can act on. Book a demo.
Invention disclosure form: editable template and worked example
An engineering team may have a working prototype, design slides, and test results without a usable invention disclosure. Patent counsel then has to reconstruct the mechanism, identify each person's contribution, and recover disclosure dates from scattered records. A reusable form gives that conversation a structure. A completed engineering example shows how to separate supported facts, proposed variants, and unanswered questions, while AI-assisted intake can help organize the materials your team already has.
Scope: This educational intake starting point supports counsel's matter- and jurisdiction-specific review.
What is an invention disclosure form?
An invention disclosure form (IDF) is an internal record that explains a proposed invention and preserves the facts needed for technical and legal review. It connects research and development (R&D) work to your intellectual property (IP) team and patent counsel: what problem arose, how the proposed approach works, who contributed what, and what has already been shared.
It is separate from a patent application. It is also separate from a U.S. Information Disclosure Statement, which submits patents, publications, or other information for patent-office consideration during prosecution.
Forms vary by organization. For example, Stanford's disclosure process captures the technology, people involved, sponsorship, and disclosure history, with a separate sponsorship review. Your form should preserve those kinds of facts without asking engineers to make legal determinations.
Patlytics' Invention Disclosures (IDF) module supports document-based or spoken intake and template-driven sections. The same factual discipline applies whether you complete a form manually or review an AI-generated draft.
Editable invention disclosure form template
Download the editable Word form, or copy the plain-text Markdown form. Both include expandable responses, contributor and disclosure-event tables, a source register, an open-question log, factual confirmations, and a counsel-handoff record.
Use exact dates where known and label estimates. Use unknown, not provided, pending, or not applicable when appropriate. “None” means the relevant facts support that answer. Keep confidential technical material in your organization's approved intake environment.
| Field | Blank response and prompt |
|---|---|
| 1. Record and contact | Response: ______ Title, internal record ID, project, submitter, work contact, submission date, version, and internal access designation. |
| 2. Technical problem | Response: ______ What failed or limited the current approach? Describe the operating environment, baseline, and constraints. |
| 3. Technical solution and operation | Response: ______ Identify components or process steps, inputs, interfaces, parameters, outputs, and failure behavior. Explain the sequence in enough detail for a technical discussion. |
| 4. Candidate distinguishing features | Response: ______ What specific differences does the team see relative to its known baseline? Separate observed results from expected benefits. Add a source locator for each difference. |
| 5. Embodiments and alternatives | Response: ______ Describe the implemented version, necessary and optional elements, substitutes, and other uses. Label each version tested, proposed, or speculative. |
| 6. People and contributions | Response: ______ For each person, record name, employer or affiliation, work contact, technical contribution or activity, date, and source. Separately identify people for counsel to consider as possible inventors. |
| 7. Development chronology | Response: ______ Record important design, build, test, and revision events, their dates and locations, and supporting record owners. Identify approximate or disputed dates. |
| 8. Evidence and limitations | Response: ______ Record test setup, measured results, failed cases, untested conditions, and attachment locations. State what the evidence does and does not support. |
| 9. Known related work | Response: ______ List known products, publications, patent documents, or internal approaches, with identifiers and relevant passages. Record any search already performed and its scope, or state that no search is reported. |
| 10. Business, funding, and agreements | Response: ______ Intended use, development plans, business owner, known sponsors or grants, outside collaborators, third-party materials, and agreement references. Record unresolved funding or rights context. |
| 11. Actual and planned external events | Response: ______ For every publication, presentation, demonstration, sale, offer, customer discussion, or other release: date, recipients, channel, material shared, access restrictions, and known confidentiality-agreement reference. Include planned events. |
| 12. Source register and missing information | Response: ______ Assign each attachment an ID, version, owner, and page or section locator. For every gap, record the question, answer owner, needed record, and follow-up date. |
| 13. Factual confirmation and counsel handoff | Response: ______ Record each contributor's factual confirmation, corrections, and limits. Identify the counsel recipient, handoff date, questions requiring legal review, and authorized next step. |
Keep the contribution roster broader than a tentative inventor list. In U.S. practice, inventorship depends on conception of claimed subject matter. Give counsel the contribution narratives and supporting records for a claim-specific inventorship assessment.
Completed hypothetical engineering example
All names, records, dates, results, and confirmation entries in this example are invented. No actual engineering tests or legal reviews occurred. The example illustrates a completed intake record with explicit unknowns, rather than a patentability conclusion.
Download the completed Word example to keep the responses and source trace together.
Example source packet
The hypothetical source packet contains the underlying sample records. Its identifiers make each answer traceable:
- S1: Project brief, version 1, April 3, 2026. Problem, current approach, and intended use.
- S2: Controller design note, version 2, April 9, 2026. Inputs, sequence, parameters, alternatives, and limits.
- S3: Bench-test report, version 1, May 2, 2026. Setup, observations, and untested conditions.
- S4: Contribution and development log, version 1, May 4, 2026. People, activities, dates, and sample confirmation entries.
- S5: Project administration and event log, version 1, May 4, 2026. Funding context, external events, and handoff state.
Completed form and source-to-field trace
| Field | Completed hypothetical response | Source and remaining gap |
|---|---|---|
| 1. Record and contact | Title: Pressure-aware filter-maintenance controller for an electronics cabinet. ID: HYP-026. Project: Cabinet cooling. Submitter: Priya Rao, controls engineer, Example Engineering Group; priya@example.invalid. Submitted: May 4, 2026. Version: 1. Access: Internal, restricted to the project and IP team. | S5 §1. Contact and company are fictional. |
| 2. Technical problem | The existing cabinet uses scheduled filter replacement. A pressure reading during fan operation can reflect filter restriction or sensor offset. The team wants a maintenance signal that distinguishes these conditions. Fan pauses are permissible only in the bench setup; live-cabinet thermal constraints are unresolved. | S1 §§1–2; S2 §4. Live-cabinet operating limits are pending. |
| 3. Technical solution and operation | A differential-pressure sensor measures across the filter. The controller samples pressure with the fan stopped, then at a known fan speed. It subtracts the stopped-fan reading from the running reading and compares the corrected value with a speed-indexed threshold. At 2,000 revolutions per minute (RPM), a value above 50 pascals (Pa) for 30 seconds triggers a maintenance alert; below 40 Pa for 60 seconds clears it. A stopped-fan reading outside ±5 Pa instead raises a sensor-review flag and suppresses the filter alert. | S2 §§1–3. Other-speed calibration entries are not provided. |
| 4. Candidate distinguishing features | Relative to the team's scheduled-replacement baseline, the proposed differences are a stopped-fan offset sample, a speed-indexed comparison, separate fault handling, and persistence periods before alert changes. The team expects more informative maintenance signals. No comparative field-performance result or novelty assessment is reported. | S1 §1; S2 §§2–3; S3 §3. Benefit remains an expectation beyond the bench cases. |
| 5. Embodiments and alternatives | Bench-tested: 24-volt fan, differential-pressure sensor, and controller with the stated thresholds. Proposed: calibration at other fan speeds. Speculative: 2 separate pressure sensors replacing the differential sensor. Pressure sampling, comparison logic, and output states are central to this design; display location is optional. | S2 §4; S3 §1. The separate-sensor variant and other speeds are untested. |
| 6. People and contributions | Priya Rao: proposed stopped-fan offset sampling on April 3. Julian Chen, firmware engineer: proposed persistence timing and implemented state logic on April 9. Morgan Ellis, test engineer: assembled the rig and ran specified tests. All are fictional employees of Example Engineering Group; work contacts are recorded in S4. The submitter asks counsel to consider Priya and Julian as possible inventors and includes Morgan's activities for review. | S4 §§1–2. No legal inventorship determination has been made. |
| 7. Development chronology | April 3: problem and sampling proposal recorded. April 9: controller design revised. April 20: rig assembled. May 2: bench cases run. May 4: intake record prepared. All events occurred in the fictional team's Lab A. These are record dates, with no earlier idea date asserted. | S4 §2. Earlier undocumented discussions are unknown. |
| 8. Evidence and limitations | At 2,000 RPM and 23°C, corrected pressure was 20 Pa with a clean filter and 65 Pa with a restriction screen. The restricted case triggered after 30 seconds. An injected +8 Pa sensor offset produced a sensor-review flag and suppressed the filter alert. The clean case cleared the alert after 60 seconds. Only 1 rig, 1 speed, and 1 temperature were tested; leakage, thermal safety, and long-term drift were not evaluated. | S3 §§1–3. No production reliability or general performance claim is supported. |
| 9. Known related work | The team knows its scheduled-replacement cabinet design, documented in S1. No external patent or publication references have been supplied, and no prior-art search is reported. This is an information gap, not evidence that relevant work is absent. | S1 §1; S5 §2. Related-work collection is assigned to the project team for counsel's scoped search. |
| 10. Business, funding, and agreements | Intended use: filter-maintenance indication in industrial electronics cabinets. Business owner: fictional product manager Alex Park, alex@example.invalid. A live-cabinet evaluation is proposed; cost and schedule are unapproved. Internal project funding is reported. No grant, sponsor, or outside collaborator is listed in the project ledger. Purchased sensor terms have not been provided. | S1 §3; S5 §2. Agreement review and third-party terms are pending. |
| 11. Actual and planned external events | April 28: Morgan emailed an assembly drawing to a fictional outside machining vendor. The vendor's confidentiality-agreement reference is unknown. May 15: a customer demonstration is planned; recipients and final slides are pending. The team reports no publication, sale, or offer in the event log, but has not reconciled every participant's calendar. | S5 §3. Obtain the sent drawing, agreement, recipient list, and final demonstration materials. |
| 12. Sources and missing information | S1–S5 are listed with owners, versions, and locators. Open items: fan-pause safety, other-speed calibration, earlier discussions, purchased-component terms, vendor disclosure facts, and demonstration details. Owners and requested response dates appear in the gap log below. | S2 §4; S3 §3; S5 §§2–4. No blank answer has been treated as “none.” |
| 13. Factual confirmation and counsel handoff | Sample confirmation entries dated May 4: Priya confirms the sampling description and flags thermal limits; Julian confirms the implemented thresholds and marks other-speed calibration pending; Morgan confirms only the reported bench observations and requests vendor-document follow-up. Counsel recipient: organizational IP intake queue, individual unassigned. Handoff requested May 4. Counsel review has not occurred; no search or drafting is authorized in this example's process. | S4 §3; S5 §4. Contribution, disclosure, agreement, and next-step questions remain open. |
The trace prevents a plausible design proposal from becoming an asserted result. For example, S2 supports the proposed multiple-speed embodiment. S3 supports observations at only 2,000 RPM. Combining them into “tested across fan speeds” would misstate the record.
Missing-information checklist and review handoff
A useful checklist records an actionable question for every unknown. For the hypothetical example, the open-question log is:
| Missing information | Question and needed record | Owner and requested date |
|---|---|---|
| Operating limits | Under what live-cabinet conditions can the fan pause? Provide the thermal assessment. | Priya, May 6. |
| Untested embodiments | Which speeds have calibration values, and were they tested? Provide the calibration table and any reports. | Julian, May 6. |
| Development history | Were there earlier discussions or technical contributions? Provide dated notes and individual accounts. | All contributors, May 6. |
| Third-party terms | What purchased-component or vendor agreements apply? Provide the relevant terms and agreement records. | Alex, May 5. |
| External events | Exactly what was sent on April 28, to whom, and under what access terms? What will be shown on May 15? | Morgan and Alex, May 5. |
| Legal next step | Which contribution, timing, and rights questions require follow-up before a scoped search or drafting assignment? | Assigned patent counsel, upon handoff. |
Use these recommended organizational checkpoints before commissioning prior-art analysis or application drafting.
1. Obtain factual inventor and contributor confirmation
Each proposed inventor and relevant contributor reviews their own contribution narrative and the technical facts within their knowledge. Record the name, date, corrections, and unresolved points. A reusable confirmation is:
I have reviewed the technical description, my recorded contribution, and the development and disclosure events within my knowledge. My corrections and uncertainties are recorded in the open-question log. This confirmation concerns factual accuracy, not a legal inventorship determination.
This intake confirmation is separate from the U.S. application-stage inventor oath or declaration. Avoid asking someone to confirm measurements they did not observe or events they cannot account for.
2. Hand the record to patent counsel
Send the versioned form, source packet, confirmation record, gap log, and actual or planned external-event details to the named counsel recipient. Flag imminent events immediately, even if technical responses remain incomplete.
Counsel reviews the contribution narratives, disclosure facts, jurisdictional context, agreements, and proposed next step. Capture dates as facts for that review. The legal effect of a disclosure differs across jurisdictions, as WIPO's patent guidance explains; a form should not calculate a universal filing deadline.
3. Record the scoped next assignment
Counsel may request more facts, authorize a defined prior-art search, or assign drafting with documented limits. Record the recipient, reviewed version, permitted task, scope, and remaining questions. Give counsel the search results and technical record to assess relevant earlier disclosures, evaluate patentability, and set the drafting scope. Application preparation requires a separate patent-drafting review.
How AI-assisted invention intake fits the process
Inventors often describe their work through presentations, drawings, test reports, and technical discussions. Asking them to recreate every detail in a questionnaire adds a translation step. AI-assisted intake can organize supplied material into a draft and support follow-up questions, while inventors confirm the facts and attorneys retain review and decision authority.
Keep the source register and open-question log with the draft. Label a proposed embodiment as proposed. Preserve conflicts between records until the relevant person resolves them. An unanswered field should remain visible instead of being filled with a plausible assumption.
Where Patlytics fits
Patlytics' Invention Disclosures (IDF) module supports the intake workflow:
- Capture facts with document or spoken intake: Start a blank disclosure, upload DOCX, PDF, or PPT materials, or speak an idea. Guided intake asks clarifying questions and organizes responses into structured sections.
- Standardize the record with custom templates: Use the default template or a custom DOCX or PDF template. Add, rearrange, or remove sections to match your organization's form.
- Review editable drafts and status: Edit the generated draft inline, mark the disclosure “drafted” for submission, and track status in the editor.
- Review related submissions with cross-disclosure deduplication: The module flags overlapping disclosures across submissions for corporate IP teams to review.
- Hand off with DOCX export and Patent Drafting: Export a DOCX for offline review or upload to an intellectual property management system (IPMS). Launch Patent Drafting from the same workspace for the next assignment.
Inventors confirm the technical facts; attorneys review the disclosure and direct the next assignment.
See how Patlytics turns inventor slides, test reports, or a spoken idea into a disclosure counsel can act on. Book a demo.
The Premier AI-Powered Patent Platform
Reduce cycle times. Increase margins. Deliver winning IP outcomes.
Book a DemoThe Premier AI-Powered
Patent Platform
Reduce cycle times. Increase margins. Deliver winning IP outcomes.
