Indefinitely maybe: Google's view on functional software claims

The IPKat saw a post this week from Google's Senior Patent Counsel, Suzanne Michel, summarising a submission filed with the USPTO on how to improve the clarity of patent claims which use functional language. The comments were filed in the context of a partnership between the USPTO and the software community in an effort to enhance the quality of software-related patents. Ms Michel (no relation to former Chief Judge Paul Michel) co-authored her company's comments with Daryl Joseffer and Adam Conrad of King & Spalding LLP. The IPKat limits himself in this post to presenting an appetizer, knowing that interested readers can consume the full submission at their leisure here, and if they're hungry for more, can work their way through a whole smorgasbord of submissions from other parties here.

Ms Michel and her fellow authors note that software patents which they regard as problematic typically claim the invention in purely functional terms, backed up by disclosures drafted in terms of high level flowcharts.
Once a functional claim element is found, they say, then regardless of whether or not the words "means for ..." are used, the provisions of 35 U.S.C. section 112(f) should apply, which has consequences both for validity and for infringement. Section 112(f) is the special provision governing "means for" claim elements:
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 a functional claim element is supported (as is often the case) with only a high level flowchart, they say the patent application ought to be rejected:
Some may object that an abstract, high-level flow chart is sometimes sufficient to allow skilled artisans to implement a claimed function. But that is a question of enablement under section 112(a), not a question of definiteness under section 112(f). “Enablement of a device requires only the disclosure of sufficient information so that a person of ordinary skill in the art could make and use the device. A [section 112(f)] disclosure, however, serves the very different purpose of limiting the scope of the claim to the particular structure disclosed, together with equivalents.” Aristocrat, 521 F.3d at 1336.
The authors say that in mechanical cases, if a claim element is drafted as a "mechanism for" or "means for" carrying out a mechanical task, then it will be construed as limited to the nuts and bolts disclosed and their mechanical equivalents. What the Google authors are urging is that the USPTO treat all purely functional claim elements in software cases in the same way, and they argue (rightly, in the IPKat's view) that whether or not a claim is considered to fall inside section 112(f) should not depend on whether the claim drafter omitted or employed "magic words" like "means for" or "step for". (In this regard, they dismiss the idea that one can evade the ambit of the section by coining terms that add nothing of consequence, such as "a validator for validating…".) If the "nuts and bolts" are missing from the specification, as is the case for a high level flowchart in their view, then the claim is indefinite.

If a high level flowchart operating on a general purpose computer is not good enough, what is required? The authors suggest that what is needed is an algorithm:
"an algorithm must identify the inputs, the outputs, and—critically—enough detail to allow someone to take the actions necessary to generate the outputs from the inputs. A purported algorithm that fails to satisfy these guideposts does little more than restate general functions and therefore lacks the implementation details required by section 112(f).
In some cases, applicants may satisfy this requirement by pointing to well-known algorithms in the prior art. Applicants can efficiently identify existing algorithms (or other structures) without adding unnecessary detail to the patent specification."
They give some examples of "good" patents, such as IBM's US 6,061,703, in which purely functional claims are accompanied by detailed algorithms. Interestingly for UK readers, one of the "bad" patents they analyse in detail and find to be indefinite is US 6,981,007, now owned by Computer Patent Annuities, Inc., a company which will be familiar to many readers and perhaps even part-owned by some of you, CPA having blossomed from a collaboration in the 1960s between UK patent agents.

The IPKat found the "good" examples to be less illuminating than the "bad" ones, because the really interesting stuff is going to be found somewhere in between the extremes cited by Google to make its point. Many real world cases have flowcharts which are more than simply a graphical rehash of the steps of claim 1, and provide implementation details showing how the claimed functionality is achieved while falling short of a formal, detailed algorithm.

At first glance, the approach suggested by Google seems specific to US law, being based on the unique consideration given to "means for" type claims under section 112(f). But maybe European practice has converged on a similar solution even though the law differs. It seems to this Kat (but perhaps it's just imagination) that in the last couple of years there has been an increasing push from EPO examiners to require applicants at the beginning of examination to import into functional software claims many more of the implementation details than previously, on the basis that these are "essential elements" which the examiner believes are required to achieve a claimed function. 

So, just as convergent evolution can produce new-world anteaters similar but unrelated to old-world aardvarks, the "structures, materials and acts" which Google wants to see examined are often explicitly found in granted EP claims because of how Article 84 EPC is applied. If the seemingly broader US claims are then construed in line with section 112(f) as Google suggests -- i.e. all purely functional elements must be construed as limited to the corresponding "structures, materials and acts" or their equivalents -- then a patentee will end up with a claim scope that is construed similarly under each system for infringement purposes, even though the claims may look very different because US law doesn't require the structures, materials and acts to be recited in the claim.
Indefinitely maybe: Google's view on functional software claims Indefinitely maybe: Google's view on functional software claims Reviewed by David Brophy on Friday, April 19, 2013 Rating: 5


  1. I can't say I've noticed a recent push by EPO examiners to demand that "essential features" be introduced to the claims, but they certainly do try it on from time to time. I usually point out that unless the feature is expressly said to be essential in the description, or is required in order to distinguish the invention from the prior art, then it is not "essential". It's for the applicant to define his invention, not the examiner. They usually don't maintain the objection.

  2. an 'essential' feature is one that the invention cannot be practiced without it, and is an objective, technical question, not a linguistic inquiry to what the inventor or his draftperson saw fit to describe in such adjectives... perhaps those objections withdrawn should not have been raised in the first place at all.

  3. This whole post looks very odd to my eyes. In the UK, if a claim says "means for X" then it covers anything which can/does do X - there's no implication that it is limited to things like the example shown in the description. For instance, if a claim includes "means for holding water" and the description shows a jug, the claim would nevertheless also cover saucepans, bathtubs and reservoirs.

  4. @Anonymous 22:37 - there are two sources of "essential" features: (i) those that are required to distinguish the invention over the prior art (the ones you are referring to); and (ii) those features that the applicant, for whatever reason, identifies as being essential.

    See EPO Guidelines F-IV, 4.5.2: "independent claim(s) should therefore contain all features explicitly described in the description as being necessary to carry out the invention".

    But the important point is that EPO practice is officially still be that: "A claim may broadly define a feature in terms of its function, i.e. as a functional feature, even where only one example of the feature has been given in the description, if the skilled reader would appreciate that other means could be used for the same function" - EPO Guidelines F-IV, 6.5


All comments must be moderated by a member of the IPKat team before they appear on the blog. Comments will not be allowed if the contravene the IPKat policy that readers' comments should not be obscene or defamatory; they should not consist of ad hominem attacks on members of the blog team or other comment-posters and they should make a constructive contribution to the discussion of the post on which they purport to comment.

It is also the IPKat policy that comments should not be made completely anonymously, and users should use a consistent name or pseudonym (which should not itself be defamatory or obscene, or that of another real person), either in the "identity" field, or at the beginning of the comment. Current practice is to, however, allow a limited number of comments that contravene this policy, provided that the comment has a high degree of relevance and the comment chain does not become too difficult to follow.

Learn more here:

Powered by Blogger.