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.

www.xkcd.com

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.