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.
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.
"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.