(The unfortunate) future of software patents under 35 USC [section] 101 and [section] 112.

• Author: Teska, Kirk

Introduction

After the Supreme Court's decision in Bilski (2), the viability of many business method patents was called in to question. (3) In Bilski, computer software was not at issue since the Bilski claims were method claims not tied to any particular computer algorithm. (4) Commentators split over whether Bilski had any real effect on software patents. (5) Two years later, however, the Supreme Court's decision in Alice (6) renders the future of software patents somewhat bleak. (7) The prestigious ABA Journal, for example, published an article entitled "Business Method and Software Patents May Go through the Looking Glass after Alice Decision" (February 2015). (8)

Besides 35 USC [section] 101 subject matter issues, computer software patent claims have also become problematic under 35 USC [section] 112 during the last few years. (9) So, patent attorneys drafting patent applications for software will need to understand and keep abreast of both the [section] 101 and [section] 112 body of case law. (10)

My thesis (which I hate) is that software patent claims will have to be narrower than in the past or else they will be invalid under 35 U.S.C. [section] 101 and/or [section] 112. To evaluate this thesis, we will break the case law into five categories each of which we will explore in further detail in this article.

I.

Does the software patent claim recite an abstract idea? If yes, the claim is broad but probably invalid. (11) If no, the claim is valid but probably narrow. (12)

Alice basically held that if a claim broadly recites an abstract idea, then the claim is invalid under 35 U.S.C. [section] 101. (13) In Alice, the claim at issue covered the abstract idea of an "intermediated settlement", i.e., the use of the third party to mitigate settlement risk. (14) This abstract idea was implemented using well understood, routine, and conventional computer functions previously known to the industry. (15) "In short, each step does no more than require a generic computer to perform generic computer functions." (16)

In other words, if a claim recites only conventional, well understood, routine, or generic computer functions implementing an abstract idea, then the claim is invalid. (17)

Conversely then, a valid patent claim for software must be limited to covering either 1) a concrete idea or 2) an abstract idea carried out using non-conventional and specific computer instructions. (18) Either way, a valid claim under 35 U.S.C. [section] 101 is narrow. (19) Hence, broad computer software claims are probably invalid post Alice and only narrower claims will be held valid. (20)

Citing Alice, several Federal Circuit cases have further illuminated the fact that only narrower software claims will now survive the [section] 101 hurdle. (21) In Planet Bingo, (22) the abstract idea at issue related to solving a tampering problem and minimizing other security risks during bingo ticket purchases carried out via a computer program employing purely conventional and generic functions. (23)

In Ultramercial, (24) the abstract idea at issue was offering media content in exchange for viewing an advertisement (25) and the claimed sequence of steps comprised only conventional steps specified at a high level of generality and added nothing of practical significance to the underlying abstract idea. (26)

In both Planet Bingo and Ultramerical, such abstract ideas broadly claimed were held invalid. (27)

DDR Holdings is the only post Alice Federal Circuit case where a software claim survived the [section] 101 analysis. (28) The abstract idea at issue (making two web pages look the same) was protected by narrower claims, which specified how certain interactions with the internet are manipulated to yield a desired result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyper-link. (29)

Thus, broad claims reciting an abstract idea are likely invalid and only narrower claims, drawn to concrete ideas or abstract ideas carried out using specific, non-conventional steps, will likely be valid. (30)

II.

Is the claim broad and have all implementations of software been described? If not, then the claim is probably invalid. (31)

It is not only [section] 101 that disfavors broad software patent claims: [section] 112 has been used to invalidate them as well. (32) As a shorthand, my hypothesis is this: if the software claim is broad enough to cover versions A and B of the software at issue, but only version A is enabled, then claim is invalid.

For example, in the Lizard Tech case, (33) the software claims at issue recited a seamless discrete wavelength transform (DWT) based compression process. (34) There were two different ways to create a seamless DWT but the specification at issue described only one way. (35) As a result the claim was held invalid under 35 USC [section] 112:

[A] patentee cannot always satisfy the requirements of [section] 112, in supporting expansive claim language, merely by clearly describing one embodiment of the thing claimed. For that reason, we hold that the description of one method for creating a seamless DWT does not entitle the inventor ... to claim any and all means for achieving that objective. (36) In Sitrick v. Dreamworks LLC, (37) the software claims at issue covered a way to incorporate a person's audio and/or image data into both video games and movies. (38) The specification was enabled for video games but not for movies. (39) In invalidity the claims, the court held:

Because the asserted claims are broad enough to cover both movies and video games, the patents must enable both embodiments. Even if the claims are enabled with respect to video games--an issue we need not decide--the claims are not enabled if the patents are not also enabled for movies. (40) So, narrow software claims, for example a claim covering only version A of the computer software, may be valid (where version A of the computer software is enabled) but broader claims covering other possible versions of the software which are not enabled will likely be held invalid. (41) This result is highly problematic especially for computer software claims since, for any computer software algorithm, there are likely numerous ways to draft the appropriate computer instructions. (42) And, no matter how many versions of the instructions are enabled in a given patent, you can be sure a defendant competitor will be able to implement computer instructions which are not enabled in the patent but still carry out the same basic functionality. (43) Broad software claims covering different possible implementations are thus likely invalid unless all the implementations are enabled which is probably impossible. (44)

III.

Does the claim employ 35 USC [section] 112(f) and is the disclosure broad? (45) If so, the claim is probably invalid. (46)

The other way a software claim can be broad but invalid is when the claim is subject to 35 USC [section] 112(f) (previously [section] 112, [paragraph] 6), i.e., the claim is drafted in a means plus function format. (47)

In several cases, a claim subject to [section] 112(f) was held invalid when the disclosure failed to disclose specific computer instructions for carrying out the claimed system. In the Ergo Licensing case, (48) for example, the claim at issue recited "programmable control means" for controlling a "fluid flow adjustment means". (49) In the specification, there was very little disclosure about the "programmable control means" or how it functioned. (50) As a result, the claim...