Software Patents: When is enough enough?[1]

Developing a Disclosure for Software Patents:

• Discuss with the inventor the technological underpinnings of the novel functional aspects of the software and how those technological considerations support that function.
• Discuss with the inventor details that link the novel functional aspects of the software description to those technological underpinnings.
• Ask the inventor to explicitly describe why the invention is more than the expected sum of its parts. Why couldn’t a software engineer, faced with the same problem, come up with the same solution?
• When drafting, include these details explicitly in the specification.

Clients often ask how much detail they need to provide when working with an attorney to draft a patent application for an invention that includes software. In the United States, applications related to software may face a subject matter eligibility rejection under 35 U.S.C. § 101 during prosecution (sometimes colloquially referred to as an “Alice Rejection”). For these applications, an ounce of prevention is worth a pound of cure. The best time to address a potential Alice rejection is when drafting the application. Arguments, details, and reasoning found within the patent application itself are often given more weight than any post hoc argument not directly supported by the application. Ultimately, a specification should be drafted as if the first office action will include an Alice rejection. However, determining what the appropriate “ounce of prevention” can be difficult. While there is no precise answer to how much detail an inventor should provide, the following provides a framework to help determine when an inventor has provided enough.

In a recent subject matter eligibility decision[2], the Court of Appeals for the Federal Circuit held that the claims of several patents regarding authentication technology were not patent eligible. However, the Court provided a discussion of how the claims failed. In this instance, the Court noted that “patent eligibility often turns on whether the claims provide sufficient specificity to constitute an improvement to computer functionality itself.”[3] While the phrase “improvement to computer functionality itself” is opaque, Federal Circuit provided some guidance through the lens of other failed claims.

First, the Court discussed Secured Mail Solutions LLC v. Universal Wilde, Inc.[4] In that case, the claims were directed to using a marking affixed to the outside of a mail object to, for example, verify the authenticity of the mail object. The Court held that the claims recited well-known and conventional ways to verify an object using a barcode and to allow generic communication between a sender and recipient using generic computer technology. There were, however, two potential avenues that the claims could have passed the threshold. The claims may have fared better if there were specific details of the barcode or the equipment for generating and processing the barcode. Also, the claims could have included a description of how the barcode was generated or how the barcode was different from long-standing identification practices.

Second, the Court discussed Electronic Communication Technologies, LLC v. ShoppersChoice.com, LLC.[5] In that case, the claims where directed to monitoring the location of a mobile thing and using authentication software to increase security. However, the specification of the patent at issue ultimately helped doom the claims. The specification stated that the claimed “authentication information” could be essentially any information recognizable to the party being contacted. In an attempt for broadness, the specification was written with generality instead of specificity. The claims did not include the specificity of the technical underpinnings to achieve the functional aspects of the claimed invention.

Third, the Court discussed Solutran, Inc. v. Elavon, Inc.,[6] the Court invalidated claims that recited a method for electronically processing checks, which included electronically verifying the accuracy of a transaction to avoid check fraud. While the claims recited hardware (e.g., a general purpose computer and a scanner), the claims did not link the functionality of the software to the hardware components other than to merely use them.

Finally, the Court discussed Prism Technologies LLC v. T-Mobile USA, Inc.,[7] the Court invalidated claims broadly reciting “receiving” identity data of a client computer, “authenticating” the identity of the data, “authorizing” the client computer, and “permitting access” to the client computer. The claims recited generic steps typical of any conventional process for restricting access without providing a concrete, specific, technical solution.

Ultimately, the Court found that the claims at issue in Universal Secure Registry LLC v. Apple Inc. were not patent eligible. The Court found nothing in the claims or any discussion in the patent of a specific technical solution by which the information used by the authentication system was generated or transmitted. The claims set forth a user using conventional tools and generating and transmitting authentication information without improving the underlying technology.[8] Further, the Court noted that nothing in the specification suggested that the claimed combination of these conventional authentication techniques achieved more than the expected sum of the security provided by each technique.[9]

While there are no bright line rules to know how much detail is enough, an application for a software-based invention should describe the technological underpinnings of the functional aspects of the software and how those technological considerations support the novel function of the software. That is, the functionality should be linked to an improvement of how the underlying system operates. An inventor has likely provided enough information when the application can describe and claim the software functionality and a use case for software functionality in terms of how the underlying technology enables these uses beyond mere inputs and outputs. Additionally, the inventor has likely provided enough information when the application can describe how the software achieves more than the expected sum of its parts.

[1] This article does not constitute legal advice. Inventors should consult an experienced attorney to meaningfully consider their patent prosecution options.

[2] Universal Secure Registry LLC v. Apple Inc., No. 2020-2044, 2021 WL 3778395 (Fed. Cir. Aug. 26, 2021)

[3] Id. at *2

[4] 873 F.3d 905, 907, 910–11 (Fed. Cir. 2017)

[5] 958 F.3d 1178, 1181 (Fed. Cir. 2020)

[6] 931 F.3d 1161, 1163, 1167 (Fed. Cir. 2019)

[7] 696 F. App’x 1014, 1016 (Fed. Cir. 2017)

[8] USR at *7

[9] Id. at *8