Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JimIvey]

Is there a reason you could not just say in the disclosure that device Y generates a visual output. For example, the visual output can include a display, such as a liquid-crystal display (LCD), as known in the art.

Now that I think about it more, I think it's a bit odd that device Y generates an LCD.

I think I'd say something like "a video display device, which can be generally any display device such as a CRT or LCD or LED display device and which is an LCD display device in this illustrative embodiment."

I think it complicates things. For example, say I have device 100, it may either include generate visual output, or be connected to means for generating visual output. In such a case I need to describe two options - one in which the device has the ability to generate visual output, and second in which the device is connected to visual output means. Why not say that the device either includes or is connected to visual output means?

It's really not that complicated.  You're allowed to assume that artisans of ordinary skill are not idiots.  If you say a computer presents a display to a human user through a display device that can be an LCD display, for example, people know that there can be a graphics card and a separate monitor that can display images generated by the graphics card.

However, if there's some reason in your application to treat display generation as distinct from display presentation, then define those as separate devices, though they can be in the same physical housing in some embodiments.

I still don't get what's so wrong about "means", especially if I define them and give examples.

Do what you want.  It's your application.

However, "means" is defined by statute.  If you insist on using it differently, you're just causing problems for yourself.  While you can avoid invocation of Section 112, paragraph 6, you can't render it inapplicable by defining "means" differently in your spec.

Regards.

[oddtimeflux]

Do what you want.  It's your application.

However, "means" is defined by statute.  If you insist on using it differently, you're just causing problems for yourself.  While you can avoid invocation of Section 112, paragraph 6, you can't render it inapplicable by defining "means" differently in your spec.

Regards.

I'm not insisting
I just want to understand the objection.

So let's simplify my query as much as I can:
Say I have different embodiments of a device. The device may have any of several elements for different purposes - visual output, sensing (e.g. proximity, motion, etc.), user manipulation (e.g. keys), communications...
Instead of using "means" - such as "visual output means", "communication means"... - what term would you suggest for substituting that specific word while still providing the broadest interpretation?

[JimIvey]

So let's simplify my query as much as I can:
Say I have different embodiments of a device. The device may have any of several elements for different purposes - visual output, sensing (e.g. proximity, motion, etc.), user manipulation (e.g. keys), communications...
Instead of using "means" - such as "visual output means", "communication means"... - what term would you suggest for substituting that specific word while still providing the broadest interpretation?

Well, looks like "device" is a good candidate.  There's also "apparatus", "module", "system", etc.  It depends entirely on the specific types of things you want to describe generically.  You could also use "visual display", "commincator", "sensor", etc.  If it were as simple as a list of magic words we all can use in prescribed situations, many of us would be out of a job.

But, really, just about anything other than "means" would be better than "means" in my opinion.

Regards.

[OMG IP]

Is there a reason you could not just say in the disclosure that device Y generates a visual output. For example, the visual output can include a display, such as a liquid-crystal display (LCD), as known in the art.

I think it complicates things. For example, say I have device 100, it may either include generate visual output, or be connected to means for generating visual output. In such a case I need to describe two options - one in which the device has the ability to generate visual output, and second in which the device is connected to visual output means. Why not say that the device either includes or is connected to visual output means?

I still don't get what's so wrong about "means", especially if I define them and give examples.

I think the point has been made clear: most practitioners would not look at it as a best practice (generalizing); however, there is nothing "wrong" with it.  Just like there is nothing wrong with my continuing to use "may"

[oddtimeflux]

Right. Thank you. I will try to find a specific alternative to each element.
By the way, my last practitioner used "mechanism", I guess to avoid the issues involved with "means", while still getting the broad definition without too much hassle. What do you think?

Relatedly - is it wise to use "means" in defining each element?
For example:
"...which may include any means for facilitating communication..."
or
"...which can facilitate or establish communications..."

[oddtimeflux]

Bump, please.

[Blutarsky]

Just don't use claim terms of art in the spec.  It's just not a good idea.
Regards.

I have heard this from other practitioners before.  Can you explain why?  Seems to be that using "comprising" in the claim and "having" or "including" in the spec only functions to raise questions, even if those words have been construed as being synonymous.

Even beyond that, certain foreign offices such as the EPO require explicit support in your spec for claim terms.  So if your client decides to foreign file and you have no explicit support in your spec for your claim terms you are in big trouble.

Maybe I'm misunderstanding?

[DogDayPM 9er9er9er]

...Seems to be that using "comprising" in the claim and "having" or "including" in the spec only functions to raise questions, even if those words have been construed as being synonymous.

Even beyond that, certain foreign offices such as the EPO require explicit support in your spec for claim terms.  So if your client decides to foreign file and you have no explicit support in your spec for your claim terms you are in big trouble.

I don't think it raises any questions.  As for why we do it, probably falls into the category of "we've always" combined with the notion that the claims are the "special" part of the application because they are the part with legal effect, so only there should special legal phraseology be used.

As for the EPO, yes, expressis verbis support for claim terms is required.  However, it is required for technical features appearing in the claims, not administrative terms.  Nearly any US-to-EPO filing gets words added to the claims, which appear no where in the spec, without trouble.  The best example I can think of is the phrase "characterized in that" which EPO examiners usually require you to add.

[Blutarsky]

I don't think it raises any questions.  As for why we do it, probably falls into the category of "we've always" combined with the notion that the claims are the "special" part of the application because they are the part with legal effect, so only there should special legal phraseology be used.

That's what I was thinking.  I assume that it's a "this is what we do" reason, rather than it being grounded in Fed. Ct. case law.

[JimIvey]

That's what I was thinking.  I assume that it's a "this is what we do" reason, rather than it being grounded in Fed. Ct. case law.

Well, I'm not aware of any on point Fed. Cir. case law, but I'd rather not be the test case either.

Aside from the potential of circular definitions from "means" plus function language in the spec, my rationale is to avoid having language in the spec that might too closely mirror a particular claim but either (i) is different in some way that might influence the interpretation of the claim or (ii) has parts that are elaborated in subsequent portions of the spec that invite one to treat those as elaborations on the mirrored language in the claim.

I'm not saying you should never do it, but it's a bit like playing with fire.  Just be careful.  Do you really want to see how closely you can mirror a claim in the spec without imparting unintentional limitations on the claim?  This work is hard enough as it is without these sorts of additional headaches.

Regards.

[Isaac]

I use the word "means" in the specification to introduce the description supporting a means plus function claim element but I do not always use it even in those cases.   I cannot remember the last time I used it for that purpose.  I'm sure it was sometime this century.