by Zachary Hadd*
Despite decades of Federal Circuit precedent, a clear definiteness rubric for functional patent claims covering software inventions remains evasive. Questions persist on what constitutes sufficient structure to absolve these claims of means-plus-function treatment. The level of algorithmic specificity required to ensure definiteness for claims that are drafted in means-plus-function form is similarly abstruse. In this Contribution, Zachary Hadd (’21) argues that even software-specific “structure” is best interpreted under the means-plus-function framework and that according definiteness to anything less than step-by-step algorithmic de-tail is not only unjustified, but ultimately inconsistent with Federal Circuit precedent.
The patent system is based on a bargain between the patentee and the public.2 What the patentee receives in this bargain is clear: the right to exclude others from making, using, or selling the invention covered by the patent.3 In exchange for this exclusive right, the patentee must fulfill two duties. The first duty is to provide the public with a description of the invention that enables one skilled in the art to make and use it.4 The second duty is to clearly define what the invention is so that the public understands what technology they may practice without infringing on the patentee’s rights.5 The patentee fulfills both of these duties through the disclosures that they make in the patent document.
The patent document consists of two parts. The first part is the specification, which includes a written description and drawings of the invention.6 The specification provides the enabling disclosure of the invention and fulfills the patentee’s first duty under the patent bargain.7 The second part of the patent document is the claims section.8 The claims define the invention that the patentee has the exclusive right to practice and fulfills the patentee’s second duty under the patent bargain.9 If the patentee drafts their claim such that the ordinarily skilled person cannot determine the patent’s scope of protection with reasonable certainty, the claim is invalid for indefiniteness under § 112(b).10
Ordinarily, a patentee claims their invention using structural language that describes what the invention is. The patentee is also free, however, to claim their invention by the function that it performs, rather than by the structure that performs that function.11 Historically, patent drafters have claimed functional features by claiming a “means” for performing the desired function.12
The patentee who chooses this route of functional claiming, however, is not absolved of their duty to clearly communicate to the public what the claim does and does not cover.13 Indeed, when Congress gave statutory approval for this practice—known as means-plus-function claiming under 35 U.S.C. § 112(f)—it restricted the scope of coverage provided by the claimed “means” to only those structures that the patentee disclosed in the specification as corresponding to the claimed function.14 The structure must be clearly linked or associated with the claimed function.15 If a person of ordinary skill in the art would be unable to recognize the structure disclosed in the specification and associate it with the appropriate function, the means-plus-function limitation is indefinite and the claim is invalid.16
Congress provided the statutory basis for means-plus-function claiming in the 1952 Patent Act.17 By 1960, nearly fifty percent of issued patents included at least one claim with a “means for” limitation.18 This practice continued for the next forty years. Through the 1980s, the percentage of issued independent patent claims utilizing means-plus-function language hovered around—and sometimes eclipsed—sixty percent.19 But over time, patentees recognized that courts interpreting these claims honored the statutory strictures of § 112(f) and interpreted means-plus-function claims as covering only those “means” for performing the function that were described in the patent document. The result was that means-plus-function claims were construed narrowly. Potential infringers could avoid liability by finding a “means” for performing the claimed function that was not disclosed in the specification. Worse yet, failure to describe in the patent document any structure for performing the claimed function rendered the claim invalid as indefinite. Recognizing that means-plus-function claiming was a trap for the unwary drafter, the practice fell out of favor as patent applicants sought to avoid the risk of a narrow claim construction or invalidity.20 By 2014, fewer than ten percent of issued patent claims were written in means-plus-function form.21
But even as the practice of means-plus-function claiming declined, patentees continued to claim their inventions by the functions that those inventions performed. As patent drafters attempted to preserve their ability to claim an invention by what it did without falling into the “trap” of § 112(f) means-plus-function claiming, other forms of “functional claiming” proliferated.22 By 2014, approximately half of the independent claims in issued patents utilized functional language by claiming some form of “structure” for “performing a given function.”23 More recently, patent drafters have utilized “configured to” language in an attempt to capture functional features of an invention.24 Indeed, approximately thirty percent of issued independent claims recited structure “configured to” perform a given function in 2014.25
Software patents are one of the bastions of functional claiming.26 Frequently, software engineers can describe what they want software to do before they can explain precisely how the software will do it.27 Accordingly, “[s]oftware patents typically . . . describe, in intentionally vague and broad language, a particular goal or objective [of the software].”28 Unsurprisingly, functional claiming is particularly well-suited to the task of protecting software-based inventions by describing what the software does.
But not all functional software claims are created equal. The oldest computer-implemented patent claims being litigated today would have been drafted when explicit “means for” language was still used in nearly thirty percent of issued patent claims.29 These claims presumptively fall within the purview § 112(f), leaving it up to the patentee’s litigators to extract the claims from the teeth of the means-plus-function trap. Even claims drafted with an eye toward avoiding the narrowing effects of means-plus-function claiming are not free and clear of § 112(f), as district courts and the Federal Circuit have wrestled with how to handle the clever drafter that, instead of using the word “means,” instead uses terms like “mechanism,” “module,” and other nonce words. When claims cannot escape the purview of § 112(f), litigants argue about the precise level of structure that must be disclosed in the specification to preserve the claim’s definiteness and validity.
This Contribution will argue that claiming software-implemented inventions is not only facilitated by—but in fact requires—the use of functional claiming. While Federal Circuit guidance on the issue suggests that patentees may avoid the ambit of § 112(f) by replacing the word “means” with a software-specific placeholder, the preemption risk associated with software patents requires a higher standard. Software inventions claimed using functional language should be interpreted under § 112(f) even if software-specific “means” are recited in the claim, and patentees’ protection should be limited to the specific, step-by-step algorithm disclosed in the specification.
*****
The Federal Circuit has laid out a two-step process for determining how to ultimately treat a claim suspected of falling into means-plus-function territory under § 112(f).30 At the first step, a court must determine whether a claim is drafted in means-plus-function format. Only if the claim is found to be a means-plus-function claim does the inquiry proceed to the second step.
Determining whether a claim is written in means-plus-function format in the first part of the inquiry goes beyond simply determining if the claim recites the phrase “means for.” A claim that includes the word “means” is presumed to be a means-plus-function claim and subject to interpretation under § 112(f). A claim that does not include the word “means” is presumed to avoid interpretation as a means-plus-function claim and to not invoke § 112(f). But both of these presumptions are rebuttable. The presumption that a claim falls under § 112(f) can be rebutted by showing that, despite using the word “means,” the claim recites sufficient structure to perform the entirety of the claimed function.31 The presumption that a claim does not fall under § 112(f) can be rebutted by showing that the claim term used—while not the word “means”—either fails to recite structure that is sufficiently definite, or fails to recite structure that can perform the claimed function.32
When the word “means” is not used, the discussion quickly turns to whether whatever word is used is a “nonce word” that simply takes the place of the word “means”—perhaps in a deliberate attempt to avoid to the purview of § 112(f). The Federal Circuit has held that generic terms such as “mechanism,” “element,” “module,” and “device” are merely verbal constructs whose use is tantamount to use of the word “means” because they do not connote sufficiently definite structure and therefore invoke § 112(f).33
Patent applicants seeking to claim software inventions face particular difficulty when trying to draft claims using functional language without invoking § 112(f). Referring to the software as a “module” or “element” is almost certain to subject the claim to § 112(f) analysis. But software itself lacks a physical form; attempting to describe it in a manner that imparts structure can be difficult. What is the software patent applicant to do?
The Federal Circuit recently offered some guidance in Zeroclick, LLC v. Apple Inc.34 The Zeroclick court was confronted with claims directed to a “program” and to a “user interface code,” each for performing various functions. The district court had treated the claimed “program” and “user interface code” as nonce words, and accordingly interpreted the claims as means-plus-function claims. On appeal, the Federal Circuit vacated the district court’s decision on several grounds. Most notable was the Federal Circuit’s explanation that the claimed “program” and “user interface code” were not used as “generic terms or black box recitations of structure or abstractions, but rather as specific references to conventional graphical user interface programs or code, existing in prior art at the time of the inventions.”35 Importantly, the Federal Circuit did not explicitly say that the terms “program” and “code” were not nonce terms. The court merely held that the district court’s dismissal of them as nonce terms was improper.
The term “engine,” like the terms “program” and “code,” is frequently used in the software context to describe computer programs. In the computing context, Merriam-Webster defines an “engine” as “computer software that performs a fundamental function especially of a larger program.”36 The Federal Circuit has not yet taken up a case in which the propriety of treating the term “engine” as a nonce word was at issue. But when the Eastern District of Texas confronted that language in a claim to a network-based database system, it found that “the term ‘engine’ conveys structure to one of ordinary skill in the art” in the software context.37 Noting that the ordinarily skilled person would recognize an “engine” as a software application or software module, the district court passed on the opportunity to construe the term as a nonce word and found that it did not invoke § 112(f).38
The risk of preemption associated with software patents imparts importance to these distinctions. If a claim to a software-implemented invention uses functional language but is not interpreted in means-plus-function form, the claim presumably covers all means for performing the claimed function that fall within the claim as interpreted under Phillips v. AWH Corp.39 By not tying the claimed function to any structure—algorithmic, or otherwise—broad software claims of this sort amount to purely functional claiming and exclude others based on a desired effect, rather than the means for achieving that effect.
The claim terms at issue in Zeroclick illustrate this point well. In Zeroclick, the claimed “program” performed the function of operating the movement of a pointer over a screen in the context of a graphical user interface for a computer or mobile phone.40 The Federal Circuit found error in how the district court disregarded “program” as a nonce term.41 But how else could one operate the movement of a pointer in a GUI if not by use of a program of some sort? Similarly, the claimed “user interface code” performed two functions: detecting locations touched by the user’s finger on a screen without requiring the exertion of pressure, and determining a selected operation based on the locations touched.42 If not through user interface code, how else would one detect a user’s interactions with a user interface? Is code directed to the user interface (i.e., user interface code) not the only means?
In both of these examples, the “structure” for performing the claimed function is necessary for any implementation of the claimed function. It is too general to have real meaning. As Professor Mark Lemley argues, the purpose of § 112(f) can only be realized if its structural requirement demands more than the recitation of inherently necessary technology.43 While the words “program” and “user interface code” are different from the word “computer,” the practical effect is the same: all are necessary for performing the claimed function. Allowing terms such as “program” and “code” to fall outside of § 112(f) is tantamount to purely functional claiming and effectively precludes all possible manner of performing the claimed function.
This is not a criticism of functional claiming. In fact, it demonstrates why functional claiming is necessary to claim software-implemented inventions: given the difficulty of claiming these inventions in physical terms—or coming up with any sort of term for the software that does not envelop every means for performing the claimed function—the invention must be described by what it does. Scope limitation is then achieved through the second step in the analysis of computer-implemented means-plus-function claims, which limits functional claims according to the algorithms for performing the functions disclosed in the patent document. This prevents preemption and encourages robust disclosure on behalf of the patent applicant.
*****
During the second step of the means-plus-function claim analysis, courts examine the written description of the patent for the structure that corresponds to the claimed “means” and is capable of performing the claimed function. If the structure is disclosed such that the ordinarily skilled person would know and understand the structure, the requirements of § 112(f) are met. If structure for performing the claimed function is absent from the specification, the claim is indefinite under § 112(b).44 It is well-settled that in the context of computer-implemented inventions, the structure corresponding to a means-plus-function claim is an algorithm disclosed in the patent document for performing the claimed function.45 A computer-implemented means-plus-function claim that does not correspond to an algorithm in the written description fails to recite the corresponding structure required by § 112(f) and is therefore indefinite under § 112(b).46
This requirement ensures compliance with § 112(b) and prevents the preemption of all potential methods of performing a given function. But because a computer-implemented means-plus-function claim without an algorithm in the specification corresponding to the claimed means is indefinite, patent applicants and litigants alike often find themselves arguing about whether the specification includes the requisite algorithmic disclosure.47 So what is sufficient “algorithmic structure” in the computer-implemented means-plus-function context? The Federal Circuit has addressed this question on numerous occasions, but the answer remains unclear.
Here is what we do know: if the claimed function is basic and consists of no more than the simple functions that a general purpose computer can perform—receiving, storing, and processing data—then disclosing a general purpose computer in the specification is sufficient structure for the claimed means and satisfies § 112(b) and (f)—even if the specification discloses no algorithm.48 But this is the exception—not the rule.49 If the claimed function is not coextensive with the basic functions of a microprocessor and requires special programming, disclosure of a mere general purpose computer is insufficient.50 The algorithm for performing the function must be disclosed.51 But at what level of abstraction?
A patentee may disclose the required algorithm in “any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure.”52 But stating that a general purpose computer or standard microprocessor with “appropriate programming” can perform the claimed function is not sufficient.53 Likewise, a generic disclosure that “software” can be used to program a generic computer to perform the claimed function—without providing some detail about the means to accomplish the function—is not enough to meet the algorithm disclosure requirement.54
Aside from these baseline qualifications, one line of Federal Circuit cases indicates that, ultimately, the standard for definiteness in computer-implemented means-plus-function claims is not a lofty one.55 In Medical Instrumentation Diagnostics Corp. v. Elekta AB, the Federal Circuit confirmed that software could be the corresponding structure in a computer-implemented means-plus-function claim.56 The court went on to suggest that as long as one skilled in the art would know the kind of software program to use to perform the claimed function, the specific program code of the software need not be disclosed.57 The Medical Instrumentation court went so far as to state that even suggesting that the claimed function “can be performed by software programs known to those of skill in the art” may be sufficient structural disclosure to satisfy the requirements of § 112(f).58 And while the Medical Instrumentation court repeatedly noted the specification’s disclosure of commercially available software, the court lamented that there was nothing in the specification to tie these commercially available software programs to the claimed function.59 If the patent-in-suit in Medical Instrumentation had simply disclosed that one of these commercially available software programs could be used to perform the claimed function, would the Federal Circuit have found the requirements of § 112(f) met? The court seems to contemplate—and even suggest—that the answer is “yes.”60
Despite decades of caselaw on the books, Federal Circuit precedent leaves the owners of software-based patents with uncertainty regarding how their claims will be interpreted. Still, patentees debate the level of specificity at which they must describe the software-implemented “structure” of the invention to ensure validity. If a patentee does find themselves bound by the strictures of § 112(f)—be it intentionally, or by accident—does disclosing software that the ordinarily skilled person could use to perform the claimed function guarantee the claim’s definiteness? Despite the open-ended nature of Federal Circuit caselaw on these issues, the broader context of the court’s decisions and the underlying public policy rationales demonstrate that the actual burdens on software patentees are greater than anything the Federal Circuit has put in writing.
While acknowledging that “algorithm” has broad meaning in the computer arts, the Federal Circuit defines the term today much the same as it did forty years ago: “a step-by-step procedure for accomplishing a given result.”61 With this definition in mind, the Federal Circuit’s precedent on computer-implemented means-plus-function claiming is rightly read as requiring a step-by-step procedure in the specification for performing the claimed function with a computer. The scope of those claims is limited to that step-by-step procedure.
It is true that a patentee may “express that algorithm in any understandable terms.”62 The algorithm need not be disclosed in the form of computer code and need not even be “highly detailed.”63 In Typhoon Touch Techs., Inc. v. Dell, Inc., the court characterized the state of Federal Circuit precedent as requiring that “the patent need only disclose sufficient structure for a person of skill in the field to provide an operative software program for the specified function.”64 In light of the court’s seemingly forgiving approach in Medical Instrumentation, it is easy to read this passage as blessing any computer-implemented means-plus-function claim as long as an ordinarily skilled artisan could provide some software program for performing the function. This would seem to cover commercially available software available to the skilled artisan, at least as long as that software is disclosed in the specification.
However, a more careful reading of Typhoon Touch illustrates why this is not the case. The patent must disclose sufficient structure for the skilled artisan to provide an operative software program for the claimed function.65 The structure is the algorithm.66 The algorithm is a step-by-step procedure for performing the function.67 The instruction of Typhoon Touch, then, is that the step-by-step procedure must be disclosed with such specificity that the skilled artisan could provide software to perform the function.
This interpretation makes sense in light of both the Federal Circuit’s decision in Typhoon Touch and the court’s precedent leading up to that case. The Typhoon Touch court ultimately found that the claims in the patent-in-suit were definite and valid after returning to the specification, identifying a four-step algorithm for performing the claimed function, and finding that those steps could be readily implemented by those skilled in the art using known computer-implemented operations—even after the patentee’s statement that “the specific algorithm connoting the structure of the means for [the function] is not explicitly disclosed in the specification.”68
This line of reasoning is actually a common thread through the Federal Circuit’s precedent on computer-implemented means-plus-function claiming. Before the Federal Circuit’s computer-implemented means-plus-function doctrine was distilled down to the “structure is the algorithm,”69 the court’s understanding of what § 112(f) required in the context of computer-implemented inventions was rooted in an understanding of the technology itself. The court acknowledged that a microprocessor programmed to carry out an algorithm creates a “new machine”: “[t]he instructions of the software program in effect ‘create a special purpose machine for carrying out the particular algorithm.’”70 In other words, the algorithm and the software that instructs the computer to perform the algorithm are two different things. And the notion that the algorithm is structural is more than mere metaphor: the Federal Circuit grounded this precedent on the manner in which “[t]he instructions of the software program that carry out the algorithm electrically change the general purpose computer by creating electrical paths within the device.”71 The court envisioned the microprocessor’s individual transistors opening and closing as electronic switches in accordance with the instructions of the software program, thereby carrying out the desired function according to the algorithm.72 The algorithm dictates the actual, physical structure of the microprocessor.
The purpose of the algorithmic disclosure requirement is to fulfill the statutory burden of § 112(b) and “particularly point[] out and distinctly claim[] . . . the invention.”73 Does disclosing an algorithm really fulfill that end any better than disclosing a specific software program? After all, the algorithm is supposed to provide the corresponding structure to the claim. But it is “[t]he instructions of the software program [that] cause the switches [of the transistor] to either open or close.”74 The software program creates the electrical paths within the computer.75 The software program thus actually “create[s] a special purpose machine for carrying out the particular algorithm.”76 Since “general purpose computers can be programmed to perform very different tasks in very different ways,”77 wouldn’t disclosure of the software—the specific programming used to perform the claimed task—actually point out and claim the invention as particularly and distinctly as possible?
Possibly. But the requirement that the algorithm itself be disclosed—and that the requirement cannot be met by only disclosing the software that performs the algorithm—is still the better approach for two reasons.
The first involves the “equivalents” provision of § 112(f). Under § 112(f), means-plus-function claims cover the corresponding structure in the specification and equivalents thereof.78 If software—even if disclosed as a specific program—were allowed to define the corresponding structure, courts would be left to determine the equivalents of the specific program disclosed. This would open the door for patentees to convince courts that a broad swath of software programs—even those that use unrelated algorithmic logic—were equivalent to the software disclosed by the patentee and therefore fall within the scope of the patent’s protection.79 A patentee successful in this strategy would inch closer to—and perhaps break through—the barrier to purely functional claiming that § 112(f) sought to erect.
The second reason is directed to fulfilling the notice function of the patent system. Patents are public documents and serve to inform others in the same technological space as the patentee about those technologies the patentee has the exclusive right to practice. If a patentee discloses a software program as the means for performing the claimed function, then all potential infringers will be on notice that using that program to perform the claimed function would fall within the patentee’s rights. But what about alternatives that are not disclosed in the patent document? Are potential infringers expected to dig into the source code of the named software to determine the inner workings of the program, determine all software that may be deemed equivalent, and avoid the entire bunch? This seems like an unrealistic burden to place on the public.
Requiring disclosure of an algorithm—a step-by-step process for performing the claimed function—resolves both of these issues simply. Because an algorithm will generally be a broader concept than even the code used to implement the algorithm, the scope of the patentee’s invention will be broader. But this means that it will also be easier to identify what falls within the doctrine of equivalents, as well as algorithmic means that are not equivalent to what was disclosed by the patentee. The notice requirement is also easily fulfilled: the algorithm disclosed by the patentee is protected. Other means for performing the claimed function, using different algorithms, are not.
*****
In Williamson v. Citrix Online, LLC, the Federal Circuit noted the recent “proliferation of functional claiming untethered to § 112, para. 6 and free of the strictures set forth in the statute.”80 It has long been the Federal Circuit’s goal to “avoid pure functional claiming.”81 Purely functional claiming preempts all possible ways of performing a given function, grants patentees protection for accomplishing the function using means that they did not conceive of, and ultimately hinders innovation.
Inventors of software-implemented inventions do face an uphill battle when seeking patent protection. But decisions like that of the Federal Circuit in Zeroclick and the Eastern District of Texas in Stragent risk allowing the pendulum to swing too far in the opposite direction. Claim terms like “program,” “code,” and “engine” should be interpreted as nonce words devoid of any structure and subject claims to means-plus-function interpretation under 35 U.S.C. § 112(f).
For computer-implemented means-plus-function claims, the Federal Circuit has been clear on one point: the algorithm is the structure. But in order to understand what the Federal Circuit blesses as an algorithm, cases like Medical Instrumentation and Typhoon Touch must be read in context. Despite passages in these cases suggesting that the disclosure of software usable for performing the claimed function protects the claim’s definiteness, the touchstone of the Federal Circuit’s inquiry is its understanding of an algorithm from 40 years ago: “a step-by-step procedure for accomplishing a given result.”82 In order to clearly define the metes and bounds of the patented invention, as well as equivalent alternatives, the step-by-step procedure for achieving the claimed function must be disclosed with specificity.
* Zachary Hadd is a J.D. Candidate (2021) at New York University School of Law. This piece is a commentary on the 2020 problem presented at the Giles Sutherland Rich Memorial Moot Court Competition in Boston, MA. Oral argument was held remotely due to ongoing efforts to stem the spread of COVID-19. The problem addressed the definiteness requirements for computer-implemented means-plus-function claims. The views expressed in this article do not necessarily represent the views of the author on this point of law. Rather, this article is a distillation of the arguments made by the team on one side of the issue at the Giles Sutherland Rich Memorial Moot Court Competition.
2. See 35 U.S.C. § 101 (“Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.”); 35 U.S.C. § 112 (defining disclosure requirements).
3. See 35 U.S.C. § 271(a) (defining the statutory conditions of patent infringement).
4. 35 U.S.C. § 112(a).
5. See Warner-Jenkinson Co. v. Hilton Davis Chemical Co., 520 U.S. 17, 33 (1997) (discussing “the role of claims in defining an invention and providing public notice”); 35 U.S.C. § 112(b) (“The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.”).
6. See, e.g., General Foods Corp. v. Studiengesellschaft Köhle mbH, 972 F.2d 1272, 1274 (Fed. Cir. 1992) (describing the specification and the claims as the “two primary parts” of the patent document).
7. See id.; 35 U.S.C. § 112(a).
8. General Foods, 972 F.2d at 1274.
9. See id.; 35 U.S.C. § 112(b).
10. Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 901 (2014).
11. See 35 U.S.C. § 112(f) (“An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.”).
12. See Warner-Jenkinson Co. v. Hilton Davis Chemical Co., 520 U.S. 17, 18 (1997) (explaining the history of means-plus-function claiming relative to the 1952 Patent Act); Continental Paper Bag Co. v. Eastern Paper Bag Co., 210 U.S. 405, 417 (1908) (evaluating functional “means for” language in a claim to a paper bag machine).
13. See Northrop Grumman Corp. v. Intel Corp., 325 F.3d 1346, 1350–51 (Fed. Cir. 2003) (explaining claim construction of means-plus-function claims).
14. See id.
15. See Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1219 (Fed. Cir. 2003) (“The requirement that structure must be clearly linked or associated with the claimed function is the quid pro quo for the convenience of claiming in functional terms.”).
16. See Noah Sys., Inc. v. Intuit Inc., 675 F.3d 1302, 1311–12 (Fed. Cir. 2012) (citations omitted).
17. 35 U.S.C. § 112(f).
18. See Dennis Crouch, The Frequency of Means-Plus-Function Claims, PatentlyO (Jul. 25, 2011), https://patentlyo.com/patent/2011/07/the-frequency-of-means-plus-function-claims.html.
19. See Dennis Crouch, Functional Claim Language in Issued Patents, PatentlyO (Jan. 23, 2014), https://patentlyo.com/patent/2014/01/functional-language-patents.html.
20. See id.
21. See id.
22. See id.
23. For example, “a fastener for coupling a first part to a second part.”
24. For example, “a fastener configured to couple a first part to a second part.”
25. See Crouch, supra note 19.
26. See Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1327–28 (Fed. Cir. 2016) (Mayer, J., concurring) (noting “the vast number of software patents—most of which are replete with broad, functional claims”).
27. See id. at 1327 (“Engineers can describe what they want software to do—in terms that have been sufficient for the PTO—well before they have made it work.” (quoting Wendy Seltzer, Software Patents and/or Software Development, 78 Brook. L. Rev. 929, 972 (2013))).
28. Id. at 1327 (citing Dan L. Burk & Mark A. Lemley, Is Patent Law Technology-Specific?, 17 Berkeley Tech. L. J. 1155, 1164–65 (2002)).
29. See Crouch, supra note 19.
30. See Apple Inc. v. Motorola, Inc., 757 F.3d 1286, 1296 (Fed. Cir. 2014), overruled on other grounds by Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015).
31. Personalized Media Commc’ns, LLC v. Int’l Trade Comm’n, 161 F.3d 696, 703–04 (Fed. Cir. 1998) (citing Sage Prods. v. Devon Indus., Inc., 126 F.3d 1420, 1427–28 (Fed. Cir. 1997)).
32. Williamson, 792 F.3d at 1349 (quoting Watts v. XL Sys., Inc., 232 F.3d 877, 880 (Fed. Cir. 2000)).
33. Id. at 1350 (citing Mass. Inst. of Tech. v. Abacus Software, 462 F.3d 1344, 1354 (Fed. Cir. 2006)).
34. Zeroclick, LLC v. Apple Inc., 891 F.3d 1003, 1008 (Fed. Cir. 2018).
35. Id.
36. Engine, Merriam-Webster.com, https://www.merriam-webster.com/dictionary/engine.
37. Stragent, LLC v. Amazon.com, Inc., No. 6:10CV225 LED-JDL, 2011 WL 13152568, at *2, *4 (E.D. Tex. June 27, 2011).
38. Id. at *4.
39. Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005).
40. Zeroclick, LLC v. Apple Inc., 891 F.3d 1003, 1005 (Fed. Cir. 2018).
41. Id. at 1008.
42. Id. at 1006.
43. Mark A. Lemley, Software Patents and the Return of Functional Claiming, 2013 Wis. L. Rev. 905, 946 (2012).
44. See Atmel Corp. v. Info. Storage Devices, Inc., 198 F.3d 1374, 1381–82 (Fed. Cir. 1999).
45. See Harris Corp. v. Ericsson Inc., 417 F.3d 1241, 1253 (Fed. Cir. 2005) (“A computer-implemented means-plus-function term is limited to the corresponding structure disclosed in the specification and equivalents thereof, and the corresponding structure is the algorithm.”).
46. See EON Corp. IP Holdings LLC v. AT & T Mobility LLC, 785 F.3d 616, 622 (Fed. Cir. 2015) (affirming invalidity of means-plus-function claims with no corresponding algorithmic in the specification); Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1338 (Fed. Cir. 2008) (same).
47. See, e.g., Harris, 417 F.3d at 1253–54 (considering arguments regarding algorithmic disclosure).
48. See EON, 785 F.3d at 621 (citing In re Katz Interactive Call Processing Patent Litig., 639 F.3d 1303 (Fed. Cir. 2011)).
49. See id. (“[T]he ‘narrow’ Katz exception . . . .”).
50. See id. at 622.
51. See id. at 623.
52. Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340 (Fed. Cir. 2008) (internal citations omitted).
53. See Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1334 (Fed. Cir. 2008) (“The term ‘appropriate programming’ simply references a computer that is programmed so that it performs the function in question, which is to say that the function is performed by a computer that is capable of performing the function.”)
54. See Finisar, 523 F.3d at 1340–41 (“Simply reciting ‘software’ without providing some detail about the means to accomplish the function is not enough [to ensure definiteness].”).
55. See id. at 1341 (citing Med. Instrumentation & Diagnostics Corp. v. Elekta AB, 344 F.3d 1205, 1214 (Fed. Cir. 2003)).
56. Med. Instrumentation, 344 F.3d at 1214.
57. Id.
58. Id. at 1217.
59. Id. at 1217–18.
60. See Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1337 (Fed. Cir. 2008) (“[T]he proper inquiry for purposes of section 112 paragraph 6 analysis is to ‘look at the disclosure of the patent and determine if one of skill in the art would have understood that disclosure to encompass software [to perform the function] and been able to implement such a program, not simply whether one of skill in the art would have been able to write such a software program.’” (quoting Med. Instrumentation, 344 F.3d at 1212)).
61. Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1385 (Fed. Cir. 2011) (quoting In re Freeman, 573 F.2d 1237, 1246 (C.C.P.A. 1978)).
62. Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340 (Fed. Cir. 2008) (quoting In re Freeman, 573 F.2d at 1245–46).
63. Typhoon Touch, 659 F.3d at 1385–86 (quoting Aristocrat, 521 F.3d at 1338).
64. Id. at 1385 (citing Finisar, 523 F.3d at 1340).
65. See id.
66. Harris Corp. v. Ericsson Inc., 417 F.3d 1241, 1253 (Fed. Cir. 2005).
67. Typhoon Touch, 659 F.3d at 1385.
68. Id. at 1386.
69. Harris, 417 F.3d at 1253.
70. Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008) (citing WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1348 (Fed. Cir. 1999)).
71. WMS, 184 F.3d at 1348.
72. Id. at 1348 n.3 (citing Neil Randall, Dissecting the Heart of Your Computer, PC Mag., June 9, 1998, at 254–55).
73. 35 U.S.C. § 112(b)
74. WMS, 184 F.3d at 1348 n.3.
75. Id. at 1348.
76. Id.
77. Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008).
78. 35 U.S.C. § 112(f).
79. See Lemley, supra note 43, at 951.
80. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1349 (Fed. Cir. 2015).
81. Aristocrat, 521 F.3d at 1333.
82. Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1385 (Fed. Cir. 2011) (quoting In re Freeman, 573 F.2d 1237, 1246 (C.C.P.A. 1978)).