Today's Date: October 31, 2014 Search | Home | Contact | Services | Patent Attorney | Patent Search | Provisional Patent Application | Patent Application | Software Patent | Confidentiality Agreements

Building Better Software Patent Applications: Embracing Means-Plus-Function Disclosure Requirements in the Algorithm Cases


Written by Gene Quinn
President & Founder of IPWatchdog, Inc.
Patent Attorney, Reg. No. 44,294
Zies, Widerman & Malek
Blog | Twitter | Facebook | LinkedIn
Posted: June 18, 2012 @ 12:15 pm
Tell A Friend!



The Ramifications of a Political Patent System
Join Gene Quinn, Judge Michel & Richard Baker for a discussion about the politics of patents
CLICK HERE to REGISTER. Thurs, Nov. 13, 2014, 12pm ET ~ Sponsored by Innography


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.

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.

- - - - - - - - - -

For information on this and related topics please see these archives:

Tags: , , , , , , , , , , , , , , , , ,
Posted in: Gene Quinn, IP News, IPWatchdog.com Articles, Patents, Software, Software Patent Basics

About the Author

is a Patent Attorney and the founder of the popular blog IPWatchdog.com, which has for three of the last four years (i.e., 2010, 2012 and 2103) been recognized as the top intellectual property blog by the American Bar Association. He is also a principal lecturer in the PLI Patent Bar Review Course. As an electrical engineer with a computer engineering focus his specialty is electronic and computer devices, Internet applications, software and business methods.

 

9 comments
Leave a comment »

  1. It is always sensible to go back to the statute:

    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.

    If the claim specifies a set of elements it is always good practice to identify the corresponding structures or acts in the description, setting out in detail the particular structures or acts corresponding to each element with an explanation of alternative features and advantages. Under 112(6) it is mandatory in a means or step + function situation, but it is good practice for every invention.

    The software field is notorious for “arm-waving” disclosures and flow charts with black boxes with nothing to tell you what is in the box. If readers are in any doubt, readers are invited to download the State Street specification and see whether a software engineer could have created such a system straightforwardly from such a disclosure, or whether it would be merely the outset of a prolonged and difficult research task. Judging from experience of making software items work together, I strongly suspect that the latter is the case. Mere disclosure of a black box coupled with a vague hope that the skilled person will know what is needed to provide the function identified in relation to that box will not do, and that should not surprise anyone familiar with the section.

    I do not think that the CAFC is being pro-patent or anti-patent, merely insisting on compliance with the statute. If people have got away with non-compliance for a long time, that is no reason to let the situation continue. Having said that, it is not sufficient to blame the attorney: the drafting team includes the inventor and if a patent is required he or she must be prepared to put in the necessary work to produce a good disclosure

  2. Paul,

    You forget that PHOSITA is a very powerful animal and the “arm-waiving” and flow charts with black boxes only needs to inform a PHOSITA to the extent neccesary.

    It is clear that you do not practice in this field and do not know what PHOSITA knows. It is not a “vague hope,” bit rather, one would hope that otheriwse knowledgeable members of the patent bar would do more than their own “vague hop[ing]” when discussing fields that are foreign to them.

  3. @Blind Dogma

    May I suggest that you check out Amtel v Information Storage Devices which was a 1999 opinion of the Federal Circuit. The disputed language was “high voltage generating means disposed on said semiconductor circuit for generating a high voltage from a lower power voltage supply connected to said semiconductor circuit.” There was no dispute that on-chip voltage doubler circuits were known when the invention was made. However, all that appeared on in the specification was a black box rejoicing in the label HIGH VOLTAGE GENERATING CIRCUIT, which arguably did not satisfy 35 USC 112(6) because there was no disclosure of the structure. Fortunately for the patentees there was a cross-reference to a journal article describing such circuits (which would not in itself have been enough) and the title which referred to NMOS integrated circuits using an improved voltage multiplier technique was according to Amtel’s expert sufficient to disclose to a skilled person the structure of the means recited in the specification. So the patentees escaped by the skin of their teeth. The fact that the circuits were well-known and incidental to the invention being claimed was immaterial.

    Whether you are a US attorney or an attorney such as myself practising in Europe, it is essential to know and fully understand the requirements of 35 USC 112(6). I am not aware of any professional malpractice claim by a disgruntled client with an application refused under this section, but as the best professional practice is defensive practice we should all take the requirements of that sub-section very seriously indeed.

    So you are WRONG. The disclosure must be more than enabling. Structure or acts sufficient to support the claimed feature must be disclosed. The recent flowchart cases in the CAFC merely reiterate principles long familiar in other technical fields.

  4. but as the best professional practice is defensive practice we should all take the requirements of that sub-section very seriously indeed.

    So you are WRONG

    No Paul, you are wrong – from a legal standpoint. And it was the legal standpoint that my comment was directed to.

    You are correct from a practical, best practices standpoint. But that was not the point of my post. It is important to know the difference between legal and best practice. Your post missed that difference.

    You can apologize at your convenience.

  5. Re: the expressed view that some CAFC judges seem to dislike means-function claims so much that they demand a clear teaching within the spec. of how to do it even if how to do it would be obvious to one of ordinary skill in the art.
    I think that is missing the vital point that the specification support for a “means-function” claim element is not just to meet an ordinary 112 “enablement” issue. Per 112 itself, that spec description also defines the SCOPE of the means-function claim element, incluudng its legal equivalents [which would otherwise be ambiguous]. That is a reason to treat spec support differently for means-function claims.
    Some other case law beside In re Donaldson is Aristocrat Technologies Australia PTY Ltd. v. International Game Technology (521 F.3d 1328, 1334 (Fed Cir. 2008). In re Aoyama, No. 10-1552 (Fed. Cir. Aug. 29, 2011) and Typhoon Touch v. Dell Inc., No. 09-1589 (Fed. Cir. Nov. 4, 2011) and Harris Corp. v. Ericsson Inc., 417 F.3d 1241 (Fed. Cir. 2005),

  6. @ Blind Dogma

    I will be glad to apologize when you find case law that establishes that the propositions I have put forward are wrong. We can have a progressive debate based on reasoned argument. Mere assertion, however, gets us nowhere.

  7. Thanks Paul,

    Perhaps when you realize the difference between your naked assertions, the case law you presented, and my rebuttal, you will open your eyes and come to your senses.

    There is more to making your point then just putting out a case cite. You reached too far. You were wrong. Sorry that you felt so easily offended that someone pointed out that you were legally wrong.

  8. @ Blind Dogma

    I may well be wrong, but what matters is the legal and factual reasons that establish that I am wrong and the authorities that make this clear.

    So far you have alleged that I do not practice in the field so do not know what I am talking about from the technical standpoint, and that the skilled person is cleverer that I believe to be the case. I am not sure that either of these allegations effectively refutes the points made in previous postings, but if I am indeed wrong it would be good to have a fuller explanation why.

  9. [...] Software Patent Applications Building Better Software Patent Applications Patent Drafting: Defining Computer Implemented Processes Patenting Business Methods and Software in [...]