Print

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

[oddtimeflux]

I'm currently drafting my application, and for some elements I want to be as broad as I can. What I've done is described them as "[purpose] means" (e.g. "visual output means"), and then elaborated on their function (e.g. "...for generating visual output..."). Then provided more specific examples.

I that a wise strategy? What should I look out for?

[OMG IP]

The use of "Means +" claim language has become a no-no because 112,6th limits the claim meaning to what is disclosed/enabled in the spec.  However, I don't think that case is on point as to use of the word 'means' in the application.  Regardless, I avoid use of that word at all times because of any potential inferences.  Is it wise?  Can't really say.  Are there a multitude of other ways to convey the point?  assuredly.

[khazzah]

I [using Means Plus Function] wise strategy? What should I look out for?

There have been two recent discussions here that discuss means-plus-function issues in detail:

http://www.intelproplaw.com/ip_forum/index.php/topic,15640.0.html
http://www.intelproplaw.com/ip_forum/index.php/topic,15731.0.html

[khazzah]

I'm currently drafting my application, and for some elements I want to be as broad as I can. What I've done is described them as "[purpose] means" (e.g. "visual output means"), and then elaborated on their function (e.g. "...for generating visual output..."). Then provided more specific examples.

I that a wise strategy? What should I look out for?

Huh. I re-read and perhaps I missed the point.

So oddtimeflux, you're talking about using means in the specification, but not in the claims?

[JimIvey]

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

With respect to "means", remember that it covers the means in the spec and equivalents thereof.  Using "means" in the spec results in a circular definition.  For example, "visual output means" in the spec refers to the means for providing visual output described in the spec, which is "visual output means", which in turn refers to the means for providing visual output described in the spec, which ... .  It's like when people tell me that a business method patent is a patent for a method of doing business.  Doesn't tell me anything.

Regards.

[oddtimeflux]

I'm currently drafting my application, and for some elements I want to be as broad as I can. What I've done is described them as "[purpose] means" (e.g. "visual output means"), and then elaborated on their function (e.g. "...for generating visual output..."). Then provided more specific examples.

I that a wise strategy? What should I look out for?

Huh. I re-read and perhaps I missed the point.

So oddtimeflux, you're talking about using means in the specification, but not in the claims?

Indeed.

[oddtimeflux]

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

With respect to "means", remember that it covers the means in the spec and equivalents thereof.  Using "means" in the spec results in a circular definition.  For example, "visual output means" in the spec refers to the means for providing visual output described in the spec, which is "visual output means", which in turn refers to the means for providing visual output described in the spec, which ... .  It's like when people tell me that a business method patent is a patent for a method of doing business.  Doesn't tell me anything.

Regards.

True. Yet, as I've mentioned, I try to make it clear in the specs what the "means" are, regarding their function. I also provide examples, which are for both clarifying the meaning of the "means", and also to allow for narrower claims if needed.
For example, I describe "visual output means X, which may be any components of device Y for generating visual output. For example, visual output means X may be, or include, a display, such as a liquid-crystal display (LCD), as known in the art."
I don't see a problem with that, but I might be wrong.

Note that today it is very hard to be more specific than "means" while including all the variants and equivalents. OMG IP said there are surely other ways to convey the point other than using "means"... so I'm wondering what they might be.

[OMG IP]

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

With respect to "means", remember that it covers the means in the spec and equivalents thereof.  Using "means" in the spec results in a circular definition.  For example, "visual output means" in the spec refers to the means for providing visual output described in the spec, which is "visual output means", which in turn refers to the means for providing visual output described in the spec, which ... .  It's like when people tell me that a business method patent is a patent for a method of doing business.  Doesn't tell me anything.

Regards.

True. Yet, as I've mentioned, I try to make it clear in the specs what the "means" are, regarding their function. I also provide examples, which are for both clarifying the meaning of the "means", and also to allow for narrower claims if needed.
For example, I describe "visual output means X, which may be any components of device Y for generating visual output. For example, visual output means X may be, or include, a display, such as a liquid-crystal display (LCD), as known in the art."
I don't see a problem with that, but I might be wrong.

Note that today it is very hard to be more specific than "means" while including all the variants and equivalents. OMG IP said there are surely other ways to convey the point other than using "means"... so I'm wondering what they might be.

Just one example:  The visual output device may be, for example, an electronic display.  In a particular embodiment, the visual output may be a LCD.  However, the type o VOD is not meant to be limited, and may be other comparable devices as known to one of ordinary skill in the art for generating visual output.

*I didn't take time to perfect that - meant for example only.

[JimIvey]

To quote the incomparably Miss Ronstadt, "Whoooaaaa, I'm gonna say it again...."

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

There, I said it again.

Just one example:  The visual output device may be, for example, an electronic display.  In a particular embodiment, the visual output may be a LCD.  However, the type o VOD is not meant to be limited, and may be other comparable devices as known to one of ordinary skill in the art for generating visual output.

"Video output device" is not the same as using "video output means" in the spec.  So, I don't have a big problem with the example.

Well, except that I don't like "may" (connotes uncertainty whereas "can" connotes ability).  "May" vs. "can" has been discussed at length herein.  And, if you use "may or may not" in every clause of every sentence and I have to read your work, I may have to come find you and hurt you.

Regards.

[OMG IP]

To quote the incomparably Miss Ronstadt, "Whoooaaaa, I'm gonna say it again...."

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

There, I said it again.

Just one example:  The visual output device may be, for example, an electronic display.  In a particular embodiment, the visual output may be a LCD.  However, the type o VOD is not meant to be limited, and may be other comparable devices as known to one of ordinary skill in the art for generating visual output.

"Video output device" is not the same as using "video output means" in the spec.  So, I don't have a big problem with the example.

Well, except that I don't like "may" (connotes uncertainty whereas "can" connotes ability).  "May" vs. "can" has been discussed at length herein.  And, if you use "may or may not" in every clause of every sentence and I have to read your work, I may have to come find you and hurt you.

Regards.

Interesting about can/may -- I think it depends on what you're taught.  The firm I worked at previously was vehemently anti-can, so that's what I learned.  Another practitioner I've worked with recently was the opposite - she mentioned she thought it was case law based, but I have never seen/heard such a thing.  You?

[oddtimeflux]

"Video output device" is not the same as using "video output means" in the spec.  So, I don't have a big problem with the example.

Exactly. It's not. So I don't really see how this example helps me. If it was a device, I would have termed it as such. However, I honestly mean "means".
For example: "A human having food consuming means for facilitating consumption of food, such as a mouth."
I could term it as a mechanism or apparatus for consumption of food, but what's the difference? I can also call it a "food consumption unit which facilitates consumption of food / which may include any means for food consumption..."... still, I see no difference.
Shouldn't the difference be in how I describe it?
And if so,

[JimIvey]

Interesting about can/may -- I think it depends on what you're taught.  The firm I worked at previously was vehemently anti-can, so that's what I learned.  Another practitioner I've worked with recently was the opposite - she mentioned she thought it was case law based, but I have never seen/heard such a thing.  You?

Here's a lengthy discussion of may vs. can.

Regards.

[Yak]

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.

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

Nope, no reason at all.

Regards.

[oddtimeflux]

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.