The National Association of Patent Practitioners forum recently posted a 'claims checklist' which is good enough that we reproduce it here.
1. You must start by identifying “the invention.” You have to have a “story.”
i. There’s an intuitive, snappy a sound bite, so you know where the claim is going. Usually it will be a simple phrase, like “controlling an [abc] of a car based on feedback of [xyz], computed in a microprocessor.” The important characteristic here is a snappy, focused idea that you can state in informal terms. It has to be simple enough that it’s right there in the front of you mind at every moment you’re working on this application.
iii. The broadest idea that excludes the prior art—usually, you want the claim to be broad enough that removing any single word results in covering the prior art (though there are exceptions). This is the single most important point in this entire memo—in the predictable arts, every word of every claim is there for one reason: to distinguish prior art (or to provide the grammatical structure for limitations that distinguish the art).
i. Elements unrelated to the idea from 1.a.i and 1.a.iii go to dependent claims.
A. For “controlling [abc] via [xyz] feedback,” as our base claim, transport protocols (fiber optic or copper? bit serial or parallel?), microprocessor guts, etc. are irrelevant to the invention. Move that kind of thing to dependent claims.
i. Claim the exact structural and cause-and-effect interrelationships, in a straightforward way. Say what you mean, in black-and-white words, in a way that an examiner will see it. There’s no such thing as implication, only the words of the claim.
ii. Be careful of accidental anticipation.
Iterate steps 1.a.ii, 1.a.iii, 1.a.iv, 1.b , and 1.c to home in on the invention of 1.a.i.
The choice of individual words is a tertiary concern (we don’t get there until steps 13, 14, and 15). Don’t start there. Word choice is context-dependent, and follows from the choices made in items 1 through 8, and it’s counterproductive to think about wordsmithing if concerns 1 through 8 are not fixed first.
a. In apparatus claims for an embedded microprocessor for control of something, claim the microprocessor as a general purpose microprocessor, not as a collection of circuits specially designed for application-specific purposes. If the invention is “controlling [abc] based on feedback of measurement [xyz],” then don’t say anything about the internal circuits of the microprocessor.
b. In method claims, claim the action of the microprocessor accurately. Microprocessors only do three things: accpt signals on input pins, execute instructions, and put signals on output pins. Microprocessors don’t know whether the stuff they’re processing is apples for grocery stores or light intensity signals for LEDs.
a. A claim has to stand on its own two feet. Under “broadest reasonable interpretation,” the following terms get weight:
i. Established, universally-recognized, common term of art, that have only one relevant meaning. (If a term has more than one meaning, you can use it, but you have to make sure that the term gets the one of those meanings you intend for it to have.)
ii. Language in the claim, e.g., “a processor circuit, having an adder, program counter (PC), a plurality of operand registers addressable by instructions…” Depending on context, a term like “processor circuit” could cover a NOR gate.
iii. A definition in the specification, using definitive language, “Term x means y.” A definition by implication won’t count under “broadest reasonable interpretation.”
If you don’t want the claim limited in one of these three specific ways, should you remove the language or move it to a dependent claim?
i. You can’t rely on “mere labels” like “first input information,” “input circuit,” and “output information”—they’re so broad that they’re too easy to satisfy. You have to “connect it” and “say what it does.” Standign naked, “input circuit” and “output circuit” could cover the logic that writes data into a register in one instruction, and reads it out in the next. If you use “input circuit” and “output circuit,” then you must include further language that is genuinely limiting, for example to make clear that it’s input and output for transferring information from some specific source to some specific destination. For example, “input circuit designed to measure [xyz] and produce a signal for delivery to a microprocessor input port”—name it, connect it, say what it does—specificed specifically enough that it can’t be disregarded.
ii. Terms that are kind of known in the art, but not tip-of-tongue with a single meaning in the art (examples: “glitch filtering,” “signature modulated” and “kernel filtering” for signature processing, “list box” for user interfaces), are not so universally known with a single meaning that you can rely on them. They essentially drop out of the claim, and will not confer patentability. To use them in a claim, the claim has to name it, connect it, and say what it does: “a list box, being a user interface control designed to display a list of items, from which a user can select.” The word “list box” won’t cut it standing alone.
The problems I see over and over:
a. Claims with intra-claim cause-and-effect connections that are too tenuous. The claim has to be really clear: “the [ghi] circuit being designed to receive the [def] signal, and in response, compute a [jkl].”
b. Relying on labels or names, without specifying the function (see 3.b).
c. Use words that are specific to what you mean: “having a signal channel to…” rather than “coupled to” (“coupled” how? by Scotch tape? physically coupled on the same IC wafer substrate? coupled by co-mounting on the same PC board? Commercially coupled because on the same page of Intel’s web site?) “Coupled to” is rarely useful.
a. Any component of a hardware microprocessor “designed to” perform anything relating to an application-specific area is too narrow. The microprocessor is designed to execute instructions. That’s all. Any application-specific function is in the software, not the microprocessor hardware.
b. What you recite explicitly depends on context—the purpose of a claim is to disclaim the prior art (see 1.a.iii). So for a microprocessor invention, if you are after a 1970 priority date, the internals of the microprocessor are important, because “microprocessor” as a concept was not well-crystallized. After about 1975, reciting internals of a microprocessor is unnecessary and counterproductive.
a. Single infringer. As a practical matter, joint infringement (induced and contributory) is.
i. Do not directly recite stuff that isn’t done by your infringer, that comes from the external world—for example,
B. If your invention is directed to a set-top box, your claim must not recite “generating a television signal.” “Generating” is done by someone else, NetFlix or ABC or the like. Your set-top box receives the signal, it doesn’t “generate” it.
C. For a computer payment routing system, do not recite the payor or payee computers. Your intended infringer does not own the payor or payee computers. Claim the routing computer, or the user interface on the customer’s computer.
b. Direct infringement. As a practical matter, induced and contributory infringement are essentially nullified by early-2000s case law. Your claim must recite actions and properties of a single computer. You may recite interactions of your computer programmed to act with and react to other computers, but your claim can’t require those other computers.
c. Any verb (like “generating a television signal”) should unambiguously be an act of the single infringer you have in mind, preferably something done by the microprocessor rather than by the human that owns it. Your claim must not recite actions of an external agent such as Netflix.
d. Most of your method claims should be directed to steps performed by the device as it operates by the end user, not setup or manufacture steps. Helpful if the claim is framed from a single component’s point of view (typically the microprocessor).
e. Most of your apparatus claims should be device as it sits on the import dock at Long Beach, as delivered by the OEM, as sold but not as operating, etc. “Programmed to…” or “designed to…” perform actions, NO “ing” verbs describing the device in action. The claim is all from a single component’s point of view, as that computer is sitting in the box on the end-user’s receiving dock.
7. Losing coverage because of divergence between Markman “in light of the specification and file history” post-issue claim construction vs. “broadest reasonable interpretation” intra-PTO
a. The main way to prevent this is technique 3.a.ii: make the claim say exactly what you mean, with no requirement to look below the surface of the claim for any interpretive inference. That’s the way we keep close control of what the claims will be interpreted to mean.
b. Arguments should be focused exactly on the claim language (acknowledging broadest reasonable interpretation), never on “the invention,” rarely on the specification.
9. IPXL/Lyell “hybrid claim” indefiniteness—in an apparatus claim, all verbs must be “verb in waiting” (infinitive “to compute” or “for computing”), no “ing” verbs in motion.
10. Method claims are less valuable than they were, because of recent changed in the law of induced infringement
If language isn’t there intentionally to limit and exclude prior art, let’s cut it./contributory infringement are (as a practical matter) gone, but still important if the device has a low sell price, and the real value is created by use. Method claims can be used to establish damages.
11. Inadvertently steering into means-plus-function (or step-plus-function) territory
a. Risk can be reduced by using specific, concrete words like “computing” (instead of “generating”), “in signal connection with” (instead of “coupled to” that could be by means of scotch tape) and the like
Stay away from wishy-washy words like “generating” or “determining,” use hardware-oriented words like “computing” (that has the important additional discipline to keep within 6.c, staying with the one point of view for the claim).
a. “in response to” connotes “in response to a discrete edge-sensitive event” rather than a level-sensitive static state
b. Instructions should be “executed,” not wishy-washy words that don’t functiaonlly couple the microprocessor an instruction.
c. For dependencies on information and similar static things, subsequent actions are “based at least in part” not “in response to”
d. I would use “in response to” only for state transition-sensitive discrete events—for static level-sensitive states, “based at least in part on” is more idiomatic. Not the most important point, but it demonstrates the relevant level of care in word-choice.
a. “each”—almost always dangerous. If you use “each” at all, it must be “each of the [jkl] items…” where you already selected down to jkl earlier in the claim. If there’s any way to read “each” to require “each and every,” throughout the device (and thereby eliminate infringement because one edge part doesn’t do the recited thing) you have to assume that that’s what will happen.
b. Can a “bit” position have three signal levels? By definition “bit” means “binary information” having “two” levels?
Risks that are low
16. Written description/new matter for amending the specification to add a definition of a somewhat-known (but less than universally known) term of art—not quite zero, but low relative to the alternatives
Non-risks:
17. Written description issues of these classes:
a. Introducing a word like “designed to” or “configured to” when the spec doesn’t use these words (risk is as close to zero as anything I can think of—remember in the U.S. you can draw on the figures for “written description”, in a way you can't in other countries)
b. Collecting specific species into a genus—for example, if you specifically describe “residential dwelling,” “factory,” and “office building,” and do not state that these three are the only possibilities, there is no written description barrier to reciting the genus “building.”
Comments