If you want to patent an app, prepare a clear account of the technical work before commissioning a full product build. This checklist helps founders and engineers assemble a review pack for a patent professional. “Patent app” is used here to mean patent preparation for a mobile app, not software for submitting patent applications.
Written by the Esperto Technologies engineering team. Sources checked 4 October 2026. This is general educational information, not a legal opinion on your invention. Ask a qualified patent professional in your intended filing countries to assess eligibility, disclosure and filing deadlines.
What this pack is for
The objective is to make the implementation understandable. An engineer should be able to distinguish the proposed mechanism from routine app features, reproduce any experiments and identify what remains unresolved. Your patent professional decides whether and how that material supports an application. A technical pack is not a drafted patent specification or a filing.
Patent applications have formal disclosure requirements. For example, the USPTO nonprovisional utility application guide describes the specification, claims and drawings. The checklist below is our engineering preparation framework, not a substitute for those requirements.
1. Define the problem and the baseline
Write down the operating conditions in which the current approach fails. Name the device type, network conditions, data size and user action. Replace “the app is faster” with a question that can be investigated, such as which processing step consumes time and how it is measured.
Keep baseline implementation notes separate from the proposed change. If the team only has an idea, label it as a proposal. If a mechanism is implemented, identify the corresponding release or commit. This prevents future plans from being described as completed evidence.
2. Map the system and the sequence
Prepare a component diagram covering the phone, local storage, backend, external services and relevant sensors or devices. Add a sequence diagram showing an input, each processing step and the output. Document retries, failure conditions, timing assumptions and permission boundaries.
A useful review asks what each component contributes. If a third-party SDK performs the central operation, identify that dependency explicitly. The distinction matters to the technical explanation even before any legal analysis begins.
3. Describe the proposed mechanism
Use plain technical prose alongside pseudocode or a flowchart. Specify inputs, state changes, decision conditions and outputs. Explain what varies between implementations and which parts are essential to the behaviour you are investigating.
For example, a fictional network-resilience experiment could document how a client queues operations, detects an interrupted transfer, resolves conflicting versions and resumes delivery. Do not present this familiar problem area as automatically novel. Its purpose here is to show the detail needed for an intelligible engineering review.
4. Keep an evidence table
| Record | What to include | Common mistake |
|---|---|---|
| Experiment | Version, test setup, input data and procedure | Keeping only a successful demo video |
| Baseline | Reference implementation and conditions | Comparing different devices or workloads |
| Result | Measured values, repeated runs and limits | Reporting a best-case number as typical |
| Failure | Conditions where the mechanism does not work | Deleting inconvenient test runs |
| Change | What changed after the previous review | Sending several unlabelled document versions |
These records can improve the quality of a technical discussion. They do not certify patentability. Use synthetic or appropriately authorised test data, and remove access tokens and customer information from material circulated for review.
5. Record known work and contributor history
List related products, papers, standards, repositories and patent publications already known to the team. For each, record the link, the feature you examined and your technical observations. Avoid writing “no competitors” because an app-store search found nothing similar.
Maintain a separate contributor log: name, date, technical contribution and relevant document or code reference. Let the patent professional assess inventorship and ownership. Job title, founder status and repository access alone are not a useful substitute for recording what each person contributed.
6. Build a disclosure timeline
Record demonstrations, pitches, releases, publications and repository visibility changes. Include what was shared, with whom, when and under what conditions. Send existing disclosures to the adviser even if they seem minor. Do not try to decide their legal effect by deleting a public page later.
A US provisional application needs substantive disclosure and does not itself become an issued patent. The usual 12-month follow-on period should be managed with counsel; do not treat a thin placeholder filing as a reservation for features to invent later. See USPTO guidance on provisional applications.
7. Separate legal and engineering work
- Founder: business objectives, intended markets, contributor information and disclosure history.
- Engineering team: architecture, implementation explanations, prototype scope, experiments and versioned evidence.
- Patent professional: eligibility assessment, search advice, claim drafting, filing strategy, deadlines and representation.
Ask for a review meeting before deciding which experiments to build. Some questions can be answered by an architecture walkthrough. Others need a small technical demonstration. A polished production application may add cost without answering the question the reviewer actually has.
Suggested folder structure
app-technical-review/
01-problem-and-baseline/
02-system-and-sequence-diagrams/
03-mechanism-and-alternatives/
04-prototype-and-test-results/
05-known-work-and-dependencies/
06-contributions-and-disclosures/
07-review-questions-and-change-log/Add an index identifying the owner, version and access level of each document. Keep a read-only snapshot of the exact pack sent for each review. New development work should produce a new version, so the adviser can see what changed without reconstructing the repository history.
Frequently asked questions
Do I have to provide all my source code?
Agree the required material and secure sharing method with your adviser. Start with an intelligible technical description. Do not paste secrets or unpublished mechanisms into a general enquiry form.
How long does technical preparation take?
It depends on the maturity of the idea, available documentation and experiments required. Scope the outputs first; neither a universal turnaround time nor a patent approval promise is appropriate.
What should I read before commissioning the pack?
Read patent eligibility for mobile applications and the distinction between patents, copyright and trademarks. They help separate the questions for your developer from those for your legal adviser.
Turn the technical idea into a reviewable system
Esperto can help document architecture, develop a focused prototype and organise implementation evidence for your patent professional. Explore our mobile app patent technical support or mobile app development services. Start with a non-confidential summary; arrange the appropriate confidentiality terms before sharing unpublished technical details.