Passionate about IP! Since June 2003 the IPKat weblog has covered copyright, patent, trade mark, info-tech and privacy/confidentiality issues from a mainly UK and European perspective. The team is David Brophy, Birgit Clark, Merpel, Jeremy Phillips, Eleonora Rosati, Darren Smyth, Annsley Merelle Ward and Neil J. Wilkof. You're welcome to read, post comments and participate in our community. You can email the Kats here

For the half-year to 30 June 2015, the IPKat's regular team is supplemented by contributions from guest bloggers Suleman Ali, Tom Ohta and Valentina Torelli.

Regular round-ups of the previous week's blogposts are kindly compiled by Alberto Bellan.

Friday, 19 April 2013

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

4 comments:

Anonymous
said...

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.

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.

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.

@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