During the prosecution of software patent applications, the two most common rejections are patent eligibility rejections under 35 U.S.C. § 101 and indefiniteness rejections under 35 U.S.C. § 112(b), including indefiniteness rejections based on claim language that triggers a means-plus-function interpretation under 35 U.S.C. § 112(f).  Often these patent eligibility and indefiniteness rejections are found in the same Office Action.  This is not surprising given that these rejections appear to be rooted in the functional language of software patent claims. 

In the past, these rejections could be easily overcome by simply amending the claims to link the functional language to general structures described in boilerplate language at the end of the specification.  In view of Alice Corporation v. CLS Bank International, 134 S. Ct. 2347 (2014), such a strategy is less effective during patent prosecution; and even if it is effective, the issued patent may not be able to withstand an attack in post-grant patent proceedings or in litigation.  Also, claim elements may be interpreted under 35 U.S.C. § 112(f) when the applicant or patentee may never have intended such an interpretation, which could lead to indefiniteness issues because the specification does not clearly disclose structures corresponding to functions recited in the claims.  See, e.g., Robert Bosch, LLC v. Snap-On, Inc., 769 F.3d 1094 (Fed. Cir. 2014). 

Thus, software patent applications need to be drafted with an eye towards addressing potential patent eligibility and indefiniteness rejections.  One approach to addressing both of these potential rejections is to include varying levels of structure in both the specification and claims.  This approach may include the following:

  • Include an independent claim having one or more elements that would trigger an interpretation under 35 U.S.C. § 112(f).
  • In the specification, describe specific structures and algorithms corresponding to the function of the means-plus-function claim elements. Describe as many specific structures and algorithms as possible to potentially increase the scope of the means-plus-function elements.
  • Include at least another independent claim that does not have language triggering an interpretation under 35 U.S.C. § 112(f). Specifically, avoid non?structural terms such as "device", "unit", "module", "element", "configured to", and "so that".
  • In the specification, describe the software functions in terms of the specific structures that perform the functions (e.g., servers) or the specific structures that relate to those functions (e.g., a display). Do not simply add a "boilerplate" figure showing general structures and a corresponding boilerplate description.
  • Describe other "physical" applications or environments of the software and include relevant structures in the claims. For example, describe and claim a user's or machine's interactions with the software.

Following this approach in drafting the specification and claims should increase the likelihood that (1) an Applicant can avoid patent eligibility and indefiniteness rejections and (2) withstand an attack in post-grant patent proceedings or in litigation.