Takeaway: In Ex parte Miyata, the Board rejected a Jepson style system claim under 112 § 2nd (indefiniteness). The Board paraphrased the claims as follows:
In a video camera system capable of [performing specified functions], the video camera system being characterized in that [under certain circumstances, specified phenomena occur].The Board concluded that "it is simply not reasonably clear what statutory class claim 5 is intended to be directed."
Details:Ex parte Miyata
Appeal 2009-008927, App. No. 10/347,865, Tech. Center 2600
Decided: February 25, 2010
The claim at issue read:
5. In a video camera system capable of carrying out panning/tilting control of a camera device and capable of displaying a video imaged by the camera device on a monitor as well as superimposing a mask image on an arbitrary area within a range of imaging with the camera device,
the video camera system being characterized in that
in a case where the mask image is moved, the size of the mask image is corrected both forward and backward or either forward or backward in the direction of movement, the amount of correction of said mask image is adjusted depending on the movement speed thereof and the amount of correction increases as the movement speed increases.
The Board first explained that "system" can be either an apparatus or a method, quoting a dictionary definition ("system: any formulated, regular, or special method or plan of procedure") for support of this statement. The Board then noted that often the body of a claim clarified which statutory class was intended, but found no clarification here.
Rather, the balance of claim 5 merely states that the “system”—or field in which the invention is used – possesses certain characteristics. One of ordinary skill in the art, then, is not put on reasonable notice of whether claim 5 is intended to be directed towards process steps (e.g., changing the sizes of mask images) or alternatively directed towards structural elements (e.g., a video camera, a pan/tilt controller, a video monitor, and specially programmed processor).The Board then assumed that the claim was an apparatus, and that the entire "video camera system" was not claimed, since the claim recited "in a video camera system." The Board still found that it was not clear exactly what structure was being claimed:
- A processor programmed to perform the claimed functions, but not the other components mentioned (video camera, pan/tilt controller, and/or video display monitor)?
- A computer-readable medium encoded with software to perform the claimed functions, but not the processor which executes the software?
- The software per se?
- The corrected, enlarged mask image?
My two cents: I gotta admit this is one of the most incomprehensible claims I've ever seen. Perhaps a bad translation is to blame: the application claims priority to a Japanese application.
The Board's focus on statutory classes in the context of indefiniteness is a bit unusual. I usually see this sort of analysis in § 101 rejections. The claim's real problem is the confusion about the structural elements. So I'd reject as indefinite for that reason alone, and not bother with any discussion of statutory classes.
I certainly agree with the Board's refusal to rule on the prior art rejections — you need some degree of certainty about claim scope in order to discuss the prior art.
The Board's holding that the preamble term "system" could be interpreted as a method in this application is ridiculous. (Same issue came up in a previous BPAI decision, see my previous post here.)
"I certainly agree with the Board's refusal to rule on the prior art rejections — you need some degree of certainty about claim scope in order to discuss the prior art."
ReplyDeleteI completely disagree. I think the meaning of the claim is reasonably clear once the method/system question is resolved. Further I agree that BPAI's position on the statutory class of the claim is way off base.
I don't see any obstacle here to addressing the prior art rejections, unless the spec won't support fixing up the claim.
>meaning of the claim is reasonably clear
ReplyDelete>once the method/system question is resolved.
Are you saying can answer the specific questions in the post, ie, processor claimed? video camera claimed? crm claimed? image claimed?
Or you're saying that even if you can't tell whether or not a specific component is actually claimed, you handle this in the prior art rejection ... by, what, requiring the prior art to teach all of the possible elements that may or may not be claimed?
>meaning of the claim is reasonably clear
>once the method/system question is resolved.
>BPAI's position on the statutory class of
>the claim is way off
I see those two statements as being in tension. That is, I see the Board's focus on statutory class as being irrelevant precisely *because* the real problem with the claim is not method vs. system (it's a system), but rather which structural components are covered by the claim.
>I don't see any obstacle here to addressing
ReplyDelete>the prior art rejections, unless the spec
>won't support fixing up the claim.
And by that you mean, "unless no claim construction is possible even after interpreting the claims in light of the spec"?
I agree with that: prior art rejections are to addressed except when no claim construction is possible.
And I admit I didn't look at the spec to see whether the claims made sense in light of the spec. If they do, the claim is not indefinite, and the prior art rejections should be addressed.
I view the spec as being helpful in interpreting individual claim terms/phrases. Yet that's not the problem here. I know what a video camera is, and what a mask image is, and what correcting the size of a mask image is.
What I *don't* know is whether the Applicant intended to claim a video camera, a processor, etc. How does a spec help you figure this out?
"The Board concluded that "it is simply not reasonably clear what statutory class claim 5 is intended to be directed." "
ReplyDeleteHappens all the time sadly.
"As I've said before, the Board's holding that a system could be a method is ridiculous."
ReplyDeleteYou are aware that "system" is routinely used in some arts to designate a method, right?
>>As I've said before, the Board's holding that a
ReplyDelete>>system could be a method is ridiculous."
>>
>You are aware that "system" is routinely used
>in some arts to designate a method, right?
Really? You're saying that the word system is used to described an entity whose constituents are steps?
No, I wasn't aware that some arts use system in this way. There are many arts I know nothing about. And your comment is a good reminder not to overgeneralize. So I'll revise my statement to be more specific...
The Board's holding that a "system" could be reasonably interpreted as a method in the field of video cameras (Miyata, this post) or in the telecomm field (White, the previous post I referred to) is ridiculous. Nor do I see anything in White's spec or in Miyata's spec to suggest that system means method.
"Really? You're saying that the word system is used to described an entity whose constituents are steps? "
ReplyDeleteYes, ret arded I know rite? I don't know what the possible reason to do it is other than to create confusion.
"Nor do I see anything in White's spec or in Miyata's spec to suggest that system means method. "
If you go slappin' down method steps in the claim then guess what? The spec doesn't really matter. You've got method steps up in ya claim.
Oh, and I still disagree with you on that other case as well. The "ING"'s should be your first tip off that you have method steps in your claim. And that claim has them in spades. Bill was right.
ReplyDeleteYour problem, as I think I may have noted before, is likely that you've spent too much time in mamby pamby computer land where supposedly machines perform method steps and these are recited as "functional language". No, functional language is reserved to describe what the machine is functional to do, not what it is CURRENTLY doing. There is a difference. One is talking about the function of the device, one is talking about a method step that is currently happening.
ReplyDelete>Your problem ... is likely that you've spent too
ReplyDelete>much time in mamby pamby computer land
>where supposedly machines perform method >steps and these are recited as "functional
>language".
You're right that I live in computer land. That probably colors my viewpoint of everything to some extent.
>There is a difference. One is talking about
>the function of the device, one is talking
>about a method step that is currently
>happening.
I do appreciate the difference between a device that is functional to do X and a device Xing. And the importance of claiming things the right way.
Though my appreciation of this comes mostly from worrying about infringement rather than from concerns during prosecution/examination. Many examiners are very lax on this sort of distinction.
>you go slappin' down method steps in the
ReplyDelete>claim then guess what? The spec doesn't
>really matter. You've got method steps up in
>ya claim.
I agree with what you're saying: a claim is a method when it recites "what is currently happening", regardless of the presence of "system" in the preamble.
>you go slappin' down method steps in the
>claim then guess what? The spec doesn't
>really matter.
My reference to the spec was in connection with the Board looking to the "statutory class" descriptor in the preamble -- here, system -- to determine that system really meant method. In response to that position, I said that a) in general, system doesn't mean method and b) in the specific case at issue, the spec didn't support to this position. *That's* how/when the spec matters.
"Many examiners are very lax on this sort of distinction. "
ReplyDeleteOh I know, but occasionally the board will catch someone, like Bill did in that previous app we were talking about that you linked to.
'My reference to the spec was in connection with the Board looking to the "statutory class" descriptor in the preamble -- here, system -- to determine that system really meant method."
O, I gotcha. Idk why or how they did that, but I haven't read the spec either.
The claim recites a video camea system having the particular functionality recited in the "characterized in" clause. I don't see any method steps in the claim.
ReplyDelete>I don't see any method steps in the claim.
ReplyDeleteAgreed. I don't think anyone actually said there were, though these comment threads get confusing at times.
One Anonymous commenter did talk about method steps in a system leading to indefiniteness, but I think he was talking either hypothetically or about another decision I blogged about.
The Board never actually said there were steps either, only that (paraphrase) "sometimes system means method and we're still confused even after reading the body of the claim".
>The claim recites a video camea system
>having the particular functionality
Yeah, but exactly what structural elements are claimed in the system? Can anyone answer the four specific questions raised by the Board as to what was/was-not claimed?
"in that
ReplyDeletein a case where the mask image is moved"
A video camera system that is characterized in a case? In a case of what? In a case of a method step.
That is your method step, it's just hard to spot since it is all jumbled together due to bad translation. I see this nonsense all the time with foreign apps.
The whole claim is a big ol' mishmash of functional language followed by a "characterization" in terms of method steps performed.
I'm rather surprised that this went to the board, all of these kinds of cases I get are promptly amended into proper claim language.