Introduction
The most common FTO approach for hardware products is relatively straightforward: identify the product features, map them against patent claims, assess whether each claimed element reads on a product feature. The question is always about things — components, structures, configurations.
Software patents change this. The majority of software patents are drafted as method claims rather than product claims. A method claim covers how something is done — a sequence of steps performed by a system, a user, or both. When the blocking patent is a method claim, standard feature-to-claim mapping produces the wrong framework. The question is not whether your software ‘has’ the claimed element. It is whether your software ‘performs’ the claimed steps — and who performs them.
This distinction matters because it affects both the scope of the FTO analysis and the infringement analysis that follows. As our piece on the difference between FTO and infringement analysis covers, FTO and infringement analysis ask structurally different questions — and for software method claims, the structural difference is even more pronounced than for hardware products.
Method Claims vs. Product Claims: What the Difference Means for FTO
What a method claim covers: A method claim covers a sequence of steps. Claim 1 of a typical software method patent might read: “A method comprising: receiving user data; processing the data according to algorithm X; generating an output based on the processed data.” The claim does not cover a product that has certain features. It covers the act of performing those steps. Anyone who performs all the steps of the method — in a jurisdiction where the patent is active — potentially infringes, regardless of what their product looks like.
Why method claims dominate software patents: Software patent drafters often prefer method claims because they can be broader than product claims. A product claim for a specific software implementation may be designed around by changing the implementation. A method claim covering the underlying process may not be so easily avoided, because it covers the process regardless of how it is implemented. This makes method claims the more commercially significant claim type for software FTO purposes — and the one that requires the most careful analysis.
Who performs the method matters: For method claim infringement, every step of the method must be performed by a single entity. If your software performs some steps and the user performs other steps, there may not be direct infringement of the method claim — because no single entity performs all the steps. This is the single-entity performance doctrine, and it is one of the most practically significant FTO considerations for software products where user interaction is part of the process the patent covers.
The Three FTO Scenarios Specific to Software Method Claims
Scenario 1: Your software performs all method steps automatically. No user action required to complete the method. The software receives input and performs every claimed step without human intervention. This is the highest-risk scenario: your software directly performs the patented method. Standard FTO mapping applies: map each claimed step to your software’s execution path and assess whether all steps are performed.
Scenario 2: Your platform enables a third party to perform the method. Your software is a platform. Users perform some or all of the claimed method steps using your platform. Direct infringement may not apply (no single entity performs all steps) but induced infringement may: if you specifically instruct users to perform the method and they do, you may be liable for inducing their infringement of the method claim.
Scenario 3: Your software runs on hardware that performs the method. The software is implemented in a device (IoT hardware, medical device, automotive system) and the hardware performs the method steps. The hardware manufacturer, the software developer, and the operator of the device may each have FTO exposure depending on who directs and benefits from each step of the method.
How to Structure FTO Claim Mapping for Method Claims
The methodology for software method claim FTO is covered in detail in our guide on FTO search best practices — and for method claims specifically, the claim mapping process has four steps that differ from standard product claim analysis.
- Break the claim into its individual method steps. Method claims are structured as a sequence. List every step separately, including the preamble. Identify which steps are performed by the system, which by the user, and which require interaction between them. This step-by-step breakdown is the foundation of accurate method claim mapping.
- Map each step to your software’s execution path. For each claimed step, identify the corresponding function in your software. What code, API call, or user interface action corresponds to each step? Where does your software execute the step? Where does the user execute it? Where is the boundary between system and user action for each step?
- Assess the single-entity performance question. After mapping every step, assess whether a single entity — your software system operating without user intervention — performs all the steps. If yes, the direct infringement analysis is straightforward. If no, identify which entity performs which steps and assess whether induced or contributory infringement is in play.
- Assess induced and contributory infringement separately. If your software enables users to perform a patented method, assess whether your documentation, user interface design, or marketing communications instruct users to perform the method in the way the patent claims. Induced infringement requires that you knew of the patent and specifically encouraged the infringing acts. Contributory infringement requires that a component of your software has no substantial non-infringing use in the context of the patent. Both are separate analyses from direct infringement.
The Alice/§101 Factor: What Software Patent Eligibility Means for FTO Risk
Alice does not eliminate method claim FTO risk: Since Alice Corp. v. CLS Bank International (2014), many software-implemented method patents have been invalidated under §101 as directed to abstract ideas. This does not mean all software method patents are invalid or that they can be ignored in FTO. A patent that survives Alice scrutiny — or that has not yet been challenged — carries blocking risk regardless of its ultimate validity. FTO identifies blocking patents; validity analysis is a separate assessment.
How to assess validity risk for software method patents: For each software method patent identified as a blocking candidate in the FTO, a validity pre-screen should assess the patent’s Alice exposure. Claims directed to a specific technical implementation rather than a generic abstract idea are more Alice-resilient. Claims that recite a specific technical improvement to computer functionality are the most defensible. A blocking patent with high Alice vulnerability is a candidate for IPR challenge — another tool in the FTO risk management toolkit that is separate from the FTO analysis itself.
How Our FTO Service Covers Software Method Claims
Our freedom to operate service covers software method claim analysis with step-by-step execution path mapping, single-entity performance assessment, and induced and contributory infringement evaluation. For software products where method claim exposure is a primary FTO risk, we structure the analysis around the three scenarios above — direct execution, platform-enabled user performance, and hardware-embedded method performance — giving product teams a clear picture of which method claims present genuine risk and what the most viable risk mitigation paths are.
Software FTO requires a different methodology when the blocking patent is a method claim. Our service covers step-level execution mapping, single-entity performance analysis, and induced infringement assessment — the three analyses that standard product claim FTO misses. → Contact Us
Conclusion: The Takeaway
Method claims are the dominant claim type in software patents. They cover processes, not products — which means the standard hardware FTO framework of feature-to-claim mapping does not produce accurate results when applied directly to software method claims. The correct framework breaks the method into individual steps, maps each step to the software’s execution path, assesses single-entity performance, and evaluates induced and contributory infringement separately.
The companies that get this right are the ones whose software FTO analysis actually reflects the method claim risk their products face. The ones that apply hardware FTO logic to software method claims are the ones that discover the gap — at the worst possible time — when a blocking method patent is asserted after launch. Method claim FTO is a methodological question, not just a search scope question. Getting the methodology right is the difference between a search that clears the product and one that misses the risk.
