Source: http://www.ipwatchdog.com/2015/07/22/a-strategy-for-protecting-software-claims-from-invalidation-under-the-algorithm-requirement/id=59586/
Timestamp: 2019-01-19 21:29:00
Document Index: 554085508

Matched Legal Cases: ['§ 100', '§ 101', '§ 112', '§ 112', '§ 112', '§ 112']

A Strategy for Protecting Software Claims from Invalidation Under the Algorithm Requirement - IPWatchdog.com | Patents & Patent Law
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):
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:
Step 1: Receive a security authorization request
Step 2: Store the received security authorization request
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:
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).
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.
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.
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).
Tags:algorithm cases, algorithm requirement, algorithms, Alice Corp., Alice v. CLS Bank, America Invents Act, Aristocrat Techs. Australia v. Intern. Game Tech, Ebay v. Mercexchange, Federal Circuit, Gottschalk v. Benson, Kevin Emerson Collins, means-plus-function, patent, patents, SCOTUS, Software, software patent, software patents, US Supreme Court, Williamson v. Citrix
Posted In:Courts, Federal Circuit, Guest Contributors, IP News, IPWatchdog Articles, Legislation, Technology & Innovation, US Supreme Court
Easwaran July 22, 2015 2:44 pm
Excellent article, and I think this is a valuable strategy to have in the toolkit.
I am glad you recognize that many Examiners will bristle at claims drafted this way. That is certainly true. My biggest fear with this strategy, though (as opposed to the alternative approach of building sub-steps into the specification for every claimed feature) is that this will bias the Examiner against your claims under Section 101.
It has been my experience that overcoming an Alice rejection via amendment or argument is very hard. Examiners tend to toss aside each amendment as not, of itself, “significantly more,” once the prior version of the claim has already been adjudged ineligible. In fact, this process often produces a result where overcoming an Alice rejection requires claims that are much narrower than the claims that may have evaded the Alice rejection in the first place. How does this apply here? Well, by removing mpf claims to a higher level of abstraction in the claim, you make the Examiner more likely to give the Alice rejection.
A third solution may be to build your specification in the manner you suggest, and then drop your mpf claims (at the higher level of abstraction) into the application after any 101 rejection has already been dealt with.
Jonnie B. Good July 23, 2015 2:39 am
Hear, hear. You two cats know a thing or two. Very creative and insightful. Thank you!
Edward Heller July 24, 2015 6:39 am
This article does point out that the Federal Circuit has a screw loose.
In reality, programs are described by steps. Steps are not structure per se, but actions. Thus the corresponding structure defined by a step is not another step, but the program itself.
What the Feds do not recognize is that there is a distinction between claiming steps and claiming results. If one claims a result, one has to disclose structure or steps for achieving that result.
1. processor configured to achieve result X.
2. processor configured to perform algorithm Y, where Y comprises steps A, B and C.
Once one understands the difference between claiming results and steps, the rest should be easy.
step back July 25, 2015 7:16 am
“the rest should be easy”
I still got my head spinning in confusion.
When programming your basic generic gyroscopes,
is it true that the optimal yute setting is 4 degrees off top dead center?