How to Patent an App Idea

Here’s the uncomfortable truth: you cannot patent an “app idea” in the way most first-time founders mean it. You can’t patent “Tinder for plumbers” or “Uber for laundry.” What you can patent is the specific technical machinery underneath an app — the novel data structures, the unusual architecture, the UX flow tied to a particular hardware capability, the algorithm that does something measurably better than what came before. The trick is reframing your idea from a product pitch into a patent claim, and that reframing is the entire job.

What “patenting an app” actually means

The USPTO doesn’t issue patents on apps. It issues patents on processes, machines, manufactures, and compositions of matter — the four statutory categories under 35 U.S.C. § 101. An app, examined as a whole, is too abstract for that vocabulary. What fits is the underlying method the app implements, or the systemof computer components configured to do the new thing. So when an inventor says “patent my app,” what they actually need to file is one or more of the following:

• A method patent— a sequence of steps the software performs to transform input into output (e.g. “a method of detecting fraudulent transactions comprising…”).
• A system patent— the configuration of hardware + software that implements the method (e.g. “a server, a client device, and a database configured to…”).
• A computer-readable medium patent — instructions stored on a tangible medium that, when executed, perform the method.
• A design patent — the ornamental appearance of a graphical user interface or icon, separate from any functional claim.

A real app filing usually combines two or three of these in a single application. That gives you multiple shots at allowance during examination — if the method claims get rejected, the system claims may survive.

The post-Alice two-step eligibility test

In 2014, the Supreme Court decided Alice Corp. v. CLS Bank International and instantly invalidated thousands of software patents. The decision created a two-step test the USPTO now applies to every software-related application:

• Step 1 — Is the claim directed to an abstract idea? Mathematical concepts, mental processes, methods of organizing human activity, and fundamental economic practices all count as “abstract.” If your claim is essentially “use a computer to do something a person could do with pen and paper,” you’re in trouble.
• Step 2 — Does the claim recite “significantly more”? Even an abstract claim survives if it adds an inventive concept that transforms the abstraction into a patent-eligible application — improving computer functionality itself, solving a problem rooted in the technology, or applying the abstract idea in a specific, novel hardware/software configuration.

The way you survive the Alice test is by drafting your claims to emphasize the technical improvement — the data structure that’s 10× faster, the architecture that uses 90% less bandwidth, the security model that’s structurally impossible to defeat. The USPTO’s own examples in MPEP § 2106 spell out exactly which framings the office treats as eligible. Read them before drafting.

What part of your app is patentable (and what isn’t)

Walk through your product mentally. For each component, ask: would a competent competitor be able to build this in a weekend after seeing the released app?If yes, it’s probably not patentable. The patentable pieces almost always look like one of these:

• Patentable:a novel algorithm (compression, ranking, matching, ML inference architecture); a data structure that solves a known performance problem; a network protocol that does something new; a hardware-software integration (sensor fusion, device-specific calibration); a security mechanism that’s structurally new (e.g. zero-knowledge proof of a specific predicate).
• Not patentable:the business model (“subscription for $9.99/mo”); the value proposition (“easier than competitor X”); the target audience; the marketing positioning; a UI “look” copied from convention; a function that’s pure data presentation; a feature that simply ports an offline activity to a screen.

The rule of thumb: if a senior engineer could ship your feature in a sprint using only off-the-shelf libraries, it isn’t inventive enough to patent. That’s not a defeat — it just means your moat is execution, brand, distribution, and trade-secret know-how, not a USPTO grant.

Design patent vs. utility patent for software

Most app founders should consider filing both kinds in parallel — they protect completely different things and the design filing is dramatically cheaper.

• Utility patent protects what the software does: the algorithm, method, or system. 20-year term from filing. Costs $5,000–$15,000 with attorney help; provisional placeholder runs $65–$325. This is the asset with the real moat — and the higher rejection risk.
• Design patent protects how the UI looks: the icon, the screen layout, the animated transition, the hardware enclosure. 15-year term from grant. Costs $1,500–$3,000 typically and grants in 12–24 months — much faster than utility. Apple has used design patents devastatingly against Samsung; they’re not symbolic.

For a deeper comparison of provisional vs. utility timing — including when to file each and what a provisional buys you — see our hub on provisional vs. utility patents.

10 real granted software patents and what they teach you

Read the claims in any of these — they’re short, and they show how successful app patents frame their inventive contribution as a technical improvement, not a business one.

1. Snap — image-overlay augmented reality. Snap’s lens-overlay patent claims a specific pipeline for detecting facial landmarks and warping a 3D mesh in real time on a mobile device. The claim is grounded in computer-vision technique, not “put a hat on a face.”
2. Slack — channel-based threading. Notice how the claim is a method of associating a reply with a parent message and propagating it to a thread view, not “chat for teams.”
3. Uber — surge pricing engine. The claim describes how supply/demand signals from driver and rider devices feed a pricing function in real time across a geo-fenced area. Pure economics wouldn’t pass Alice; the technical implementation does.
4. Amazon — one-click ordering. US 5,960,411 — Method and system for placing a purchase order via a communications network. Filed in 1997 and now expired. The claim was famously broad (it’s why this patent is taught in every law school). Today the same claim language would almost certainly fail step 1 of Alice.
5. Google — PageRank. US 6,285,999 — Method for node ranking in a linked database. The patent that built the entire $2T company. The claim isn’t “rank websites” — it’s a recursive eigenvector calculation over a link graph. Now expired.
6. Netflix — adaptive bitrate streaming. The claim describes detecting client bandwidth and switching among pre-encoded quality tiers mid-stream. A textbook example of “solves a problem rooted in the technology.”
7. Stripe — declined-card retry network. An ML-driven decision engine that decides whether and when to retry a declined card based on issuer-specific patterns. Eligibility argued on “structural improvement to payment networks.”
8. Apple — slide-to-unlock. US 8,046,721 — Unlocking a device by performing gestures on an unlock image. Originally granted, partially invalidated in 2016 — a useful study in how an app patent can erode under post-grant review. (See our hub on rejected and invalidated patents for more.)
9. Spotify — collaborative-playlist conflict resolution. The claim solves the operational-transform problem for two users editing the same playlist offline — a classic “technical solution to a technical problem.”
10. Tinder — swipe-based matchmaking. US 9,733,811 — Matching process system and method. The patent that protects double-opt-in match logic with the swipe gesture as the input modality. Tinder has used this aggressively against Bumble and others.

The provisional-first strategy that makes sense for app founders

Almost every successful app startup files a provisional patent application first, then decides whether to convert to a full utility application within the 12-month priority window. Here’s why that sequence is dominant for software:

• Cost.A provisional is $65 at the micro-entity tier and $130–$325 at small-entity. A full utility filing — done well — is $5,000–$15,000. You pay the cheap fee first to lock in the priority date.
• The 12-month window.Once filed, you can mark the product “patent pending,” raise from investors, talk publicly, and gather usage data without losing your priority date. Most app inventors discover during this year that their actual defensible claim is different from what they thought on day one.
• Iterate then commit.When you do file the utility application, you can incorporate everything you learned during the provisional year. The provisional doesn’t lock you into specific claim language — only the technical disclosure.
• Fail cheaply.If at month 11 you decide the patent isn’t worth pursuing, you let the provisional lapse and walk away having spent under $300. That’s a much better outcome than spending $12,000 on a utility filing that ends up commercially worthless.

Five filing mistakes that get app patents rejected

• Claiming the business idea, not the implementation.“A method of selling X online” gets rejected on day one. “A method of detecting Y using Z data structure” has a chance.
• Skipping the technical-improvement framing.If your claim doesn’t state what the algorithm does betterthan prior art, the examiner will say it’s an abstract idea with nothing more.
• Public disclosure before filing.If you launched the app, posted on Product Hunt, or pitched at a public demo day before filing your provisional, the U.S. gives you a 12-month grace period — but you’ve killed your foreign filing rights everywhere else.
• Vague specifications.If a competent engineer can’t build your invention from your specification alone, the application fails the enablement requirement under 35 U.S.C. § 112.
• Not searching prior art first.Two hours on Google Patents and a keyword search on the USPTO database is the cheapest insurance you can buy. If someone already filed it, you’ll learn fast.

What to do this week

1. Run your idea through our free originality scanner — it surfaces the most-similar prior art in seconds and gives you a 1–100 originality score so you know where you stand.
2. Do a focused two-hour Google Patents search using the keywords from your scan results. Read the top three matching applications carefully.
3. Write a one-page disclosure of what your software does, framed as a sequence of steps. Don’t worry about claim language yet — just describe the technical mechanism in plain English with enough detail that an engineer could rebuild it.
4. File a provisional. The cheapest option is the USPTO’s online Patent Center ($65 micro-entity), but if you want a registered patent attorney to draft proper claim language, services like LegalZoom run a patent-prep flow with attorney review for around $299.
5. Use the 12-month window to talk to a patent attorney about whether a full utility filing makes sense. By month 9 at the latest.

File a provisional patent application with LegalZoom →

(Affiliate link — we may earn a commission at no extra cost to you. For complex algorithm patents we still recommend a registered patent attorney over any DIY service.)

Read next

• How much does it cost to patent an idea? — full 2026 fee breakdown including software-specific attorney rates.
• Provisional vs. utility patent — when to file each, with worked examples for software.
• Famously rejected patents — what gets killed under Alice and how to avoid it.