A Strategy for Protecting Software Claims from Invalidation Under the Algorithm Requirement

In 1972, the Supreme Court stated clearly that Congress should address how patent law applies to the new field of software. Gottschalk v. Benson, 409 U.S. 63, 73 (1972). Unfortunately, Congress has since then been largely silent on the question of when software is, and is not, patentable. Someone who defends software patents might interpret this silence as a positive sign that software is patentable, because software methods and products easily fall within the text of 35 U.S.C. §§ 100 and 101. Nevertheless, the reality is more complicated, because the courts have identified numerous judicial exceptions to the plain text of the Patent Act, including the “abstract idea” exception. In general, Congress has also remained silent on these judicial exceptions. In fact, in the America Invents Act, Congress repeatedly included “rules of construction” making it clear that Congress had no intention of disturbing judicial decisions on patent eligible subject matter. See America Invents Act (AIA), Pub L. No. 112-29, 125 Stat. 328, 331.

In the roughly 40 years since the Supreme Court in Benson invited Congress to clarify how patent law applies to software, software has become a major force in the global economy. Simultaneously, critics of software patents have argued that software raises unique policy concerns that did not apply to Industrial Age inventions. These critics raise concerns about patents that claim functions without disclosing or claiming appropriate techniques for performing the functions, a lack of clear definitions in the software literature, and overlong patent terms in a field with rapid technological turnover. Moreover, these critics have also identified concerns about business method patents, which often include software patents.

In the absence of congressional action, the courts have attempted to address these concerns with mixed success. First, the courts have endorsed a more muscular application of the “abstract idea” exception to 35 U.S.C. § 101. Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014). The Supreme Court refuses to define the term “abstract idea” but has traditionally applied it to mathematical algorithms and fundamental business practices such as hedging and intermediated settlement. Second, the courts have dramatically limited the ability of patent owners to obtain a permanent injunction for business method patents (which often include software claims, as mentioned above). eBay Inc. v. MercExchange, LLC, 547 U.S. 388 (2006). Third, the courts have created an “algorithm” requirement for software claims that invoke 35 U.S.C. § 112(f). Aristocrat Techs. Australia v. Intern. Game Tech., 521 F.3d 1328 (Fed. Cir. 2008). These three judicial developments all appear to respond to Congressional inaction rather than action. But all have proven to be potent weapons for killing and diluting software patents. (The law has developed against software patents in other ways too, both subtle and unsubtle.)

In this article, we present a strategy for responding to the third judicial development cited above: the algorithm requirement. Three years ago, one of us argued that the algorithm requirement is “illogical” and “arbitrary” from a policy perspective. See The Illogic of the Algorithm Requirement for Software Patent Claims by Kip Werking. The article further stated that the algorithm requirement, if taken to its logical conclusion, results in “algorithms and functions [] nested within each other like Russian Matryoshka dolls.” In summary, the article argued that:

The problem is not that the concern about broad software claims is unjustified. . . . The problem is that, even if the concern is justified, the algorithm requirement does not solve it.

Just recently, we were happy to see Professor Kevin Emerson Collins of Washington University Law School endorse essentially the same view in the Patently-O blog. See Guest Post by Prof. Collins – Williamson v. Citrix Online: And Now Comes the Difficult Part. Professor Collins stated that the algorithm requirement “makes no sense from a policy perspective because the level of generality specified in a claim is often arbitrary.” Similarly, he compares the consequences of the algorithm requirement to “nested Russian dolls.”

For brevity, we refer the reader to the earlier articles linked above to see detailed reasons why the algorithm requirement is bad policy. Nevertheless, a brief summary follows. In general, the courts distinguish between functions and algorithms, and they require patent applicants to disclose algorithms to cure perceived deficiencies in functions. The problem with this line of reasoning is that both algorithms and functions under 35 U.S.C. § 112(f) are composed of the same things: steps. So the result of the algorithm requirement is to simply make patent applicants “fix” one step by specifying more steps. Accordingly, if the algorithm requirement is taken to its logical conclusion, then each step would be fixed with more steps, and each of those steps would be fixed with even more steps, like Russian dolls. Instead, the courts do not take the algorithm to its logical conclusion and, instead, only require a single layer: the original step and the further steps (i.e., algorithm) for it. This is arbitrary, confusing for patent applicants and examiners, and a poorly calibrated solution to concerns about software patents.

The following example illustrates how the algorithm requirement works today. Consider this software claim as a toy example (putting aside concerns about prior art):

1. A system comprising:

a reception module programmed to receive a security authorization request;
a storage module programmed to store the received security authorization request;
a signature module programmed to digitally sign the received security authorization request using a private key;
a transmission module programmed to transmit the digitally signed security authorization request to an authentication server.

In this example, the critics of software patents could argue that this claim is invalid because of the algorithm requirement. First, the critics would argue that the claim invokes 35 U.S.C. § 112(f), even though the claim does not use the magic words “means for.” The Federal Circuit recently clarified that the presumption against such a claim interpretation is not strong, thereby lowering the bar to applying the algorithm requirement and invalidating the underlying patent. See the discussion in Professor Collins’ article at Patently-O. Second, the critics would argue that the specification of the patent does not disclose a corresponding algorithm for each of these “module” steps (or otherwise tie the “module” steps to appropriate algorithms).

Of course, in many cases, a software patent specification will fail to satisfy the requirement. Many software patent applications were filed years before the Federal Circuit solidified the algorithm requirement, so patent lawyers had no reasonable way to predict the future and draft their applications accordingly. (This “ex post facto” nature of the algorithm requirement is a common problem with most patent reform and undercuts reliance on property rights.) The algorithm requirement also makes little sense and deviates from established tradition, as explained above. Traditionally, applicants provide a flow diagram for their method claim, but do not provide second-order flow diagrams for each step of the first flow diagram. One flow diagram, at the appropriate level of generality, is typically enough and more would do little to improve the invention disclosure.

Instead of explaining how the algorithm requirement is bad policy (see the articles linked above), we here present a strategy for rendering it harmless. The first reaction of patent lawyers to the algorithm requirement is to suggest putting in narrower algorithms in the specification for each step of software claims. In the example above, the patent lawyer would say “for the reception module, you should put a 2+ step algorithm in the specification and then tie the algorithm to the module.” This is a natural suggestion. Indeed, this is probably how the Federal Circuit envisioned that the patent bar would try to satisfy the algorithm requirement.

We believe that there is a better solution. Instead of starting with what you have (the software claim) and then drafting one or more narrower algorithms for that claim, we suggest that you work in the opposite direction. Start from the end: the claim scope that you want. In this case, the claim scope that you want is the algorithm itself. From this end (i.e., the algorithm) work backwards to create a claim that corresponds to that algorithm.

An example helps illustrate how our strategy works. Let’s return to the example above. This claim already recites a kind of algorithm that represents the scope that we want. Accordingly, we need to move the claim itself to the specification, in the form of two or more algorithms, and then we need to craft a higher-level claim that corresponds to these algorithms.

In this case, we could transform our example claim into the following algorithms:

Algorithm 1:
Step 1: Receive a security authorization request
Step 2: Store the received security authorization request
Algorithm 2:
Step 1: Digitally sign the received security authorization request using a private key
Step 2: Transmit the digitally signed security authorization request to an authentication server

At the same time, we can craft a higher level claim that includes means-plus-function steps that invoke these two algorithms:

1*. A system comprising:

protection means for protecting a security authorization request;
processing means for processing the security authorization request.

In the specification, in clear terms, simply tie the “protection means” to Algorithm 1 and tie the “processing means” to Algorithm 2 (both listed above). Voila! You have now obtained the following benefits:

1. You have a means-plus-function claim. You can thereby argue, under claim differentiation, that the remaining independent claims do not invoke 35 U.S.C. § 112(f).
2. You have a means-plus-function claim that has the same scope as your other independent claims, except with the added benefit that this claim covers equivalents.
3. You have overcome the pressure to narrow the scope of your claims to some arbitrarily narrower algorithm. Instead, you have maintained essentially the same scope by tying the claim scope to an arbitrarily broader claim format.
4. You have protected your claim from invalidity under the algorithm requirement by clearly tying it to corresponding algorithms.

Of course, patent examiners do not like to allow claims that have only two lines. You can expect to get rejections of the short means-plus-function claim even when the other independent claims are allowable. But this obstacle should be easy to overcome in most cases. Simply call the examiner and walk him or her through the law on the algorithm requirement. Explain that the means-plus-function claim has essentially the same scope as the other claims and, therefore, is allowable for the same reasons.

Overall, you might think that it is silly to create an artificially broader means-plus-function claim and then tie its steps to “algorithms” formed by subsets of your original method claim steps. And it is silly. But that’s just because the algorithm requirement itself is silly (i.e., arbitrary). Silly judicial rules result in silly applicant behavior. In fact, the critic could allege that this strategy results in situations where patentability “depend[s] simply on the draftsman’s art.” Alice Corp., 134 S. Ct. at 2359 (citing Parker v. Flook, 437 U.S. 584, 594-595, 593 (1978)). In response, we would observe that, in one important sense, the patentability of all patent claims necessarily turns upon the skill of the draftsman. Moreover, although the Supreme Court has frowned on “draftsman’s” strategies in the past, we do not expect our strategy here to be similarly unsuccessful. Our strategy simply follows the Federal Circuit’s instruction to link software means stanzas to corresponding algorithms. At the very least, the strategy may draw attention to how problematic the algorithm requirement is from a policy perspective and motivate the Federal Circuit to revisit it. In the meantime, our strategy may help applicants to address the arbitrariness and the uncertainty posed by the current interpretation of 35 U.S.C. 112(f).