Means-plus-function claiming has been disfavored (by and large) since at least 1994 when the Federal Circuit handed down its decision in In re Donaldson, where the Federal Circuit sitting en banc explained:
If one employs means plus function language in a claim, one must set forth in the specification an adequate disclosure showing what is meant by that language. If an applicant fails to set forth an adequate disclosure, the applicant has in effect failed to particularly point out and distinctly claim the invention as required by the second paragraph of section 112.
In other words, if it is not in the specification then the fact that it may be a “means” to accomplish the function does not save you. Means that accomplish the recited function that are not within the specification of a patent application are not captured by the claims.
Means-plus-function claiming is not very popular in many technical disciplines because of how narrowly limited the claims are to what is specifically disclosed. Over the years, however, mean-plus-function claiming has continued with various levels of popularity for those who deal with computer-implemented methods (i.e., software). After all, software is just a series of steps directing a machine (typically a computer) to perform certain processes to accomplish a result. Thus, “means for” doing something remained a rather descriptive way, at least generally speaking.
Before jumping straight into computer-implemented methods, let’s take a step back in time. In 1999 the Federal Circuit explained in Atmel Corp. v. Information Storage Devices, Inc. that the proper test for meeting the definiteness requirement is that the corresponding structure (or material or acts) of a means (or step)-plus-function limitation must be disclosed in the specification itself in a way that one skilled in the art will understand what structure (or material or acts) will perform the recited function. Judge Lourie would write in Atmel:
That the “one skilled in the art” analysis should apply in determining whether sufficient structure has been disclosed to support a means-plus-function limitation flows naturally from the relationship between claim construction and § 112, ¶ 2.
Unfortunately, the recent algorithm cases are a substantial departure from traditional jurisprudence relative to § 112, ¶ 6. The algorithm cases say that it is immaterial whether one of skill in the art would understand from the disclosure, which is almost unfathomable. After all, isn’t the whole point of an adequate disclosure to teach the invention to a person of skill in the art? Yes, but that is not enough for software patents if you are going to be employing means-plus-function claims.
In Noah Systems, Inc. v. Intuit, Inc. (2012), which interpreted means-plus-function claims related to a computer-implemented method, Judge O’Malley wrote:
[T]he algorithm requirement is necessary because general purpose computers can be programmed to perform very different tasks in very different ways. Without disclosing any corresponding structure, one of skill simply cannot perceive the bounds of the invention.
Yet Judge O’Malley and the rest of the panel refused to inquire what one of skill in the art would have understood because they determined that the algorithms present were incomplete. Judge O’Malley did recognize that “whether a claim is indefinite is based on how the claim limitation would be understood by one of skill in the art”, but then went on to say that the knowledge of one of skill in the art cannot overcome the lack of structure, and an incomplete algorithm is the equivalent of complete lack of structure.
Do you have a software related invention?
If you need assistance with a software patent, Internet technology,
computer device or other invention IPWatchdog founder and patent attorney
Gene Quinn can help. CLICK HERE to CONTACT GENE.
It seems logically inconsistent to say that the ultimate question is what one of skill in the art would understand and then have the a Judge (who is not skilled in the art) supplant their own lack of understanding for that of the one skilled in the art. But I am not on the Federal Circuit and I was not consulted about the wisdom of the rule. So while I have written in the past about why I think this rule doesn’t make sense (see Show Me the Algorithms and CAFC Kills Means Plus Function and A Primer on Means Plus Function) at the end of the day we must accept that the rule in algorithm cases is now that the algorithm needs to be complete and clear to even an unskilled artisan (i.e., a Judge) before you will be allowed to submit evidence about what a skilled artisan would understand. This means that the disclosure requirements are far more detailed than they once were (although these latest algorithm cases are not the first to raise this issue).
In reality, the Federal Circuit doesn’t like means-plus-function claims and this is just the latest attempt to do away with them. More concerning is that there seems to be a diverging law associated with what is an adequate disclosure in software patent cases depending up on whether you use means-plus-function claims. What is particularly worrisome is the thought that these means-plus-function disclosure requirements might weave their way into disclosure requirements even absent means-plus-function claiming.
The disclosure requirements for these types of patent applications has been a moving target for years, which means that whatever the most stringent disclosure requirements are should become the target regardless of the types of claims you file. To ensure your software patent application has appropriate disclosure of the invention you should accept — even embrace — the requirements for having an appropriate means-plus-function disclosure. By meeting the strict standards set forth in the mean-plus-function algorithm cases you will file more detailed applications that have better disclosure and which will undoubtedly support more claims, thus making the resulting patent or patents more valuable.
Computer-Implemented Means-Plus-Function Limitations
For at least the time being (and likely evermore) means-plus-function claiming should not be the primary claiming technique employed in a software patent application. It doesn’t hurt to have some means-plus-function claiming because then you know that you have claims that extend to the limits of whatever you disclosed, but they are fragile and need to be supplementary claims, not primary claims.
If you are going to include means-plus-function claims, which you may well want to do if the client is willing to pay for supplementary claims, it is important to understand the basics that will govern examination and interpretation of the claim. When a computer-implemented method invokes means-plus-function under § 112, ¶ 6, the corresponding structure is required to be more than simply a general purpose computer or microprocessor. To claim a means for performing a particular computer-implemented function and then to disclose only a general purpose computer as the structure designed to perform that function amounts to pure functional claiming. The structure corresponding to such a means-plus-function claim for a computer-implemented function must include the algorithm needed to transform the general purpose computer or microprocessor disclosed in the specification.
This is all well and good, but begs the question. What is an algorithm?
An algorithm is defined, for example, as a finite sequence of steps for solving a logical or mathematical problem or performing a task. The applicant may express the algorithm in any understandable terms including as a mathematical formula, in prose, in a flow chart, or in any other manner that provides sufficient structure. With computer-implemented methods (i.e., software) flow charts are worth their weight in gold. Flow charts that show the overview of the processes are good, but ever more detailed flow charts that break down the various constituent processes in greater detail are also extremely helpful.
Detailed flow charts coupled with quality, descriptive text and a bit of code or pseudo-code are useful not only when means-plus-function claims are at issue, but also when they are not employed. If you are looking to create a foundational patent that could successfully be the parent of a patent family then having disclosure, disclosure and more disclosure is critical. So even if you do not plan on filing means-plus-function claims it would be wise to make sure that the disclosure in the specification you do file could support means-plus-function claims. That will ensure that algorithms are disclosed with sufficient detail.
What’s the Big Deal About Algorithms?
I will occasionally get calls from rather “knowledgeable” prospective clients who tell me they are interested in obtaining a software patent. This group of individuals I am referring to now are a subset of those who have previous software patenting experience, having obtained one or more software patents already at some point in time in the past. In several occasions when I have explained the importance of flow charts and why we need them I have been told something like: “Well… I have experience with this and we didn’t need flow charts in the past so we don’t need them now either.” The conversation frequently disintegrates from there, with me being told that if I don’t understand software patents enough to understand that flow charts are not necessary then they will go elsewhere. These folks seem to believe that because they had to submit little or no evidence associated with the internal workings of the individual algorithms in the past that they simply don’t need that kind of detail now, and certainly aren’t willing to pay for someone to “overkill” their application.
These individuals are destined to fail! The disclosure requirements have only continued to get more and more onerous in the software area over time. Most recently with the machine-or-transformation test in Bilski and now with a series of algorithm cases. Admittedly, these algorithm cases do deal with means-plus-function, but who is to say that the disclosure requirements won’t continue to tighten over time? In many instances if you do not file for Track One acceleration it will take 4 to 5 years to get a software patent, perhaps longer. What will be the disclosure requirements applied to you and your application in 4 years time when examination commences? What will be the disclosure requirements in 10 to 15 years time when you might wind up trying to license or litigate? This is one reason why you want to disclose as much as possible and attempting to satisfy the onerous means-plus-function disclosure requirements makes sense even if you are not going to use means-plus-function claims. Of course, the other reason is to create one whale of an omnibus disclosure that will spawn an entire patent portfolio, which will be the client’s goal if they are successful and making real money with the invention.
It is critical to remember that in several Federal Circuit case the patentee has unsuccessfully argued that the requirement for the disclosure of an algorithm can be avoided if one of ordinary skill in the art is capable of writing the software to convert a general purpose computer to a special purpose computer to perform the claimed function. These arguments have been found to be unpersuasive because the understanding of one skilled in the art does not relieve the patentee of the duty to disclose sufficient structure when means-plus-function claiming is employed. The specification must explicitly disclose the algorithm for performing the claimed function, and simply reciting the claimed function in the specification will not be a sufficient disclosure for an algorithm which, by definition, must contain a sequence of steps.
And for goodness sake, if you are trying to create a disclosure that will support an eventual patent family why would you ever want to file a disclosure that doesn’t give you the ability to make all kinds of acceptable claims? Means-plus-function claims are limited — no argument there. But if you can ultimately wind up with hundreds or thousands of claims in a patent family the entire family is more valuable. Invalidating claims must go claim by claim. So if your competitors want to safely enter the market they will need to engineer around your entire claim footprint or invalidate all those various claims you have received, which may be a monumental task if you have a variety of claims written from a variety of different perspectives with a variety of different claiming techniques.