Method Claims in Mobile App Patents: What They Cover and How They Work

A utility patent application for a mobile app almost always includes method claims alongside system or device claims. Method claims get less attention than they deserve — and that gap costs founders when they try to enforce their rights or evaluate a competitor's position. Here is what method claims do, why they matter for software, and where they create problems you should anticipate.

What a Method Claim Actually Protects

A method claim defines an invention as an ordered series of steps rather than a physical object or a system of components. A valid method claim requires at least a preamble identifying what kind of method it is and a sequence of steps written in active verb form: "receiving," "comparing," "transmitting," "generating."

The claim covers any party who performs every step in the claimed sequence. If your patent claims a method of authenticating a user by collecting a behavioral pattern, comparing it against a stored baseline, and generating a session token — then anyone who performs all three steps in that order, using any implementation, is potentially infringing.

This is important for mobile apps: method claims can reach the behavior of the software regardless of what language it is written in, what hardware runs it, or whether the product is delivered as a native app, a web app, or an API endpoint.

The Divided Infringement Problem

Method claims have a well-known weakness called divided infringement. A single party must perform every step of the claim for direct infringement to occur. If your method claim has five steps and your competitor's system handles three of them while the end user performs the other two, no single actor has committed all five steps.

For mobile apps, this matters constantly. Many app workflows split actions between a server, the device, and the user. If the claim as drafted treats each of those as separate steps without tying them to a single controlling entity, enforcing it becomes much harder.

Drafting around this problem usually means: - Attributing all steps to a single actor ("a server computer performing steps A through E") - Writing a claim that captures only the server-side steps as a complete, independently infringing sequence - Writing a parallel claim that covers only the device-side steps as a complete sequence - Including a claim directed at a system configured to perform the full workflow, so divided infringement is not an issue

None of these is a perfect fix for every fact pattern, which is why reviewing claim structure before filing — not after — matters.

How Method Claims Interact With Patent Eligibility

Software method claims face Section 101 eligibility scrutiny. The USPTO evaluates whether a claimed method is directed to an abstract idea and, if so, whether it adds something significantly more than routine implementation on generic hardware.

The strongest method claims for mobile apps tend to: - Recite specific inputs, transformations, or outputs tied to a technical problem - Avoid language that reads as pure data manipulation with no connection to hardware or network conditions - Include steps that reflect how the invention actually solves a technical problem, not just what result it achieves

A claim written as "receiving user input; processing the input; returning a result" will face rejection because those steps describe almost any software interaction. A claim written around the specific mechanism by which the processing works — particularly if that mechanism solves a technical problem like reducing latency, conserving battery, or handling unreliable connectivity — stands on firmer ground.

Combining Method Claims With Other Claim Types

Most app patents include multiple claim types in parallel: method claims, system or device claims, and sometimes computer-readable medium claims (which cover the software stored on a disk or in memory). Each type can reach a different potential infringer.

• A competitor who operates a server running the patented process infringes a method claim performed on that server
• A competitor who sells an app configured to perform the method may infringe a system or device claim
• A distributor who sells or distributes the software may be reached by a medium claim

Using all three in parallel gives an enforcement posture that covers more of the actual supply chain for a typical mobile product.

Practical Takeaways

• Method claims protect sequences of steps, not physical objects — they can reach software behavior across implementations and platforms
• Every step in a method claim must be performed by a single actor for direct infringement; check whether your workflow splits steps across the server, the device, and the user before you finalize claim language
• Claims tied to a specific technical mechanism hold up better under Section 101 scrutiny than claims describing a generic input-process-output sequence
• Filing system claims and medium claims alongside method claims gives you more options when you identify a potential infringer
• Reviewing how a competitor's product actually works — step by step — is the right starting point for evaluating whether your method claim reaches their product

This guide is general education, not legal advice, and does not create an attorney–client relationship. For your specific situation, talk to a registered patent attorney.