Software patent applications are routinely rejected as patent-ineligible subject matter under 35 USC 101 as claiming a judicial exception, such as an abstract idea, without significantly more. See, e.g., MPEP 2106.07(a); Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961).
This article presents a two-step approach to responding to software patent-ineligible subject matter rejections under 35 USC 101 and drafting patent-eligible subject matter software patent applications having claims to an “improvement in computer functionality”. The first example describes the approach for responding to 101 rejections. The second example describes the approach for drafting patent-eligible subject matter software patent applications.
I. Responding to 101 Rejections
Step 1: Overcoming the “Abstract” part of a 101 Rejection
Particularize the claims. This helps overcome the “abstract” part of a 101 rejection. Put details into the claims to define the steps performed in the software and hardware to a granular degree. Don’t claim a result; claim the steps performed in accomplishing the result. That is, define the software computer program and hardware in discrete steps. Define what’s going on in each step of the computer program code. Go to the level of a software design engineer that annotates their code, to inform others as to what’s going on in the code. If there is an algorithm claimed, particularize the claims to include the steps performed in implementing the algorithm.
- Define Steps of the Software and Hardware to a Granular Degree
Pour over the specification and drawings to glean as much detail as possible to define the steps performed by the software and hardware to a granular degree. Glean these details from the specification, flow charts, data structures, data flow diagrams, tables and hardware figures in the patent application. Put these details into the claims. For example, instead of describing a software function as a high-level result-oriented function, such as “drive to Dallas”, describe the actual discrete code steps that implement the function. That is, claim the step by step driving directions from the starting point to the destination for every turn in the trip. The same philosophy is applied for particularizing the hardware in the claims. Describe data transformations that occur in software and hardware between input and output along with the data structures involved in the claimed process. Particularization helps to overcome the abstract part of the 101 rejections.
- Claim Technical Improvements
Novel software programs that are not just novel/nonobvious, but are also technical improvements in computer functionality, are patent-eligible subject matter when they are expressed as claimed technical improvements. Focus on data transformations and data structures. What happens to the data between the inputs and the outputs. Describe any data structures created and how are they used. Draft detailed computer readable claims, data structure claims, process and system claims.
- Claim Data Structures
Novel data structures and the processes that use them are patent-eligible subject matter when the data structure defines an improvement in the computer functionality. Draft computer readable claims, data structure claims, process and system claims. Many software programs create data structures that improve a computer’s functionality.
- Argue a Technical Improvement in Computer Functionality
After drafting the claims as described above, describe how the claims recite a technical improvement in computer functionality and are thus patent-eligible subject matter under 35 USC 101.
Step 2: Overcoming the “without significantly more” part of a 101 Rejection
Focus on what’s novel/nonobvious in the claims to overcome the “without significantly more” part of the 35 USC 101 rejection. The inventive concept can overcome the “without significantly more” part of the rejection. Use your 102 and 103 arguments to focus on what’s novel and particularize these novel and nonobvious aspects of the invention in the claims. Describe how the novel aspects of the software and/or hardware improve over, i.e., are “significantly more” than the abstract idea stated by the Examiner. This requires a meta vision of the functionality of the software and hardware. Back away from the details of the code and discuss the bigger picture improvements provided by the process. Describe how the claimed invention improves upon and solves problems encountered with the abstract idea.
II . Drafting Patent-Eligible Subject Matter Software Patents
Step 1: Avoid Abstraction
Particularize the description, drawings and the claims to avoid an “abstract idea” rejection. Focus on data transformations. Describe what happens to the data between data inputs and data outputs. Draft detailed computer readable claims, data structure claims, process and system claims. Show details of the hardware and software in the drawings. Include flow charts, data structure drawings, data flow diagrams and a detailed hardware diagram showing data flow and data transformations. Describe any data structures created and how are they used. Draft detailed computer readable claims, data structure claims, method claims and system claims. Step one helps obviate the abstract part of a possible 35 USC 101 rejection.
Step 2: Focus on Novelty, That Which is “Significantly More.”
Focus on what’s novel/nonobvious in drafting the specification, drawings and claims. That is, that which is “significantly more” than an abstract idea. Provide details of the computer program and how it is an improvement over the prior art. Again, this requires a meta vision of the software’s functionality. Put details in the specification to define the steps of the software and hardware to a granular degree. Draft the specification to support the details of the particularized claims. Put these details in the figures in flow charts, data structures and hardware figures. Step two helps obviate the “without significantly more” part of a possible 35 USC 101 rejection.
Image Source: Deposit Photos.