Print

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

[IntelProp007]

If the spec describes that functions of the invention, for example relaying a communicaiton, can be carried out by loading either firmware or softwreinto memory, is a claim which recites for example "a relay section for relaying the communication..." patent eligible? It seems to me hte claim would not be patent eligible since the broadest reasonable interpretation incluides soeftware implementation. On the other hand, since Bilski v Kappos potentially changed the game for claiming software, I am wondering if such a claim could clear the Bilski hurdle if for example some machine-type elements were added into the claim that provided context for the "a relay section for relaying the communication..." There was a recent Fed Cir opinion (this year) which said that context in the spec, for example where machine implementation is described, can guide the patent-eligibitlty of a claim, although I can not recall the name of the case at the moment.

[khazzah]

If the spec describes that functions of the invention, for example relaying a communicaiton, can be carried out by loading either firmware or software into memory ...

I've got news for you: firmware is a specific kind of software. Both terms refer to instructions executing on a processor. The difference is that a device that runs "firmware" (e.g., your DSL modem, your Tivo, your automobile's engine controller, etc.) cannot easily be configured to run other programs, ie, sets of instructions.

There was a recent Fed Cir opinion (this year) which said that context in the spec, for example where machine implementation is described, can guide the patent-eligibitlty of a claim, although I can not recall the name of the case at the moment.

It must have been RCT v. Microsoft, since that's the only post-Bilski Fed. Cir. case.

It definitely hurt Bilski that no computers were described in the application and definitely helped RCT that computers were described as a mechanism for implementing the algorithms.

I am wondering if such a claim could clear the Bilski hurdle if for example some machine-type elements were added into the claim that provided context for the "a relay section for relaying the communication..."

Nobody knows yet what language will clear Bilski and what won't. But what you describe is a common strategy to clear Bilski.

[JimIvey]

If the spec describes that functions of the invention, for example relaying a communicaiton, can be carried out by loading either firmware or software into memory ...

I've got news for you: firmware is a specific kind of software. Both terms refer to instructions executing on a processor. The difference is that a device that runs "firmware" (e.g., your DSL modem, your Tivo, your automobile's engine controller, etc.) cannot easily be configured to run other programs, ie, sets of instructions.

My antiquated recollection is that firmware is installed in PROM -- making it somewhat between software and hardware.  That may not be the only defining characteristic, but the mention of memory, which has a connotation of RAM, seems a bit off.  Perhaps you do what I do, define "memory" in the spec to include all kinds of computer-readable media, including (P)ROM.

I am wondering if such a claim could clear the Bilski hurdle if for example some machine-type elements were added into the claim that provided context for the "a relay section for relaying the communication..."

Nobody knows yet what language will clear Bilski and what won't. But what you describe is a common strategy to clear Bilski.

I'll just note that it's not clear to me without more context what a "relay section" is.  That clause might invoke 112p6.  In that case, what you describe in the spec takes on significant importance.  Generally, I think that's true for most (if not all) software applications.

FWIW, I use "logic" and define it to include software and/or digital circuitry.  And, I avoid "for ____ing" in the claims, unless I intend to invoke 112p6.

If Bilski is applied reasonably, I don't see any problem in getting around it.  In fact, I don't think any of my claims pre-Bilski would have any problems post-Bilski.

Regards.

[khazzah]

My antiquated recollection is that firmware is installed in PROM

That's certainly part of the classic connotation of "firmware". But lots of firmware is stored on Flash these days. I maintain my original distinction: firmware is code with a single-purpose, and it's hard to make a device that runs firmware run other code instead.

-- making it somewhat between software and hardware. 

I think I part company with you there. The instructions are not the hardware. The processor is the hardware. As is, I suppose, the storage for the instructions.

I do think that saying "firmware is 'close to' the hardware" is a statement most firmware/embedded systems developers would agree with -- if that's what you were getting at.

I'll just note that it's not clear to me without more context what a "relay section" is.  That clause might invoke 112p6.  In that case, what you describe in the spec takes on significant importance.  Generally, I think that's true for most (if not all) software applications.

I second Jim's concern.

[JimIvey]

-- making it somewhat between software and hardware. 

I think I part company with you there. The instructions are not the hardware. The processor is the hardware. As is, I suppose, the storage for the instructions.

I do think that saying "firmware is 'close to' the hardware" is a statement most firmware/embedded systems developers would agree with -- if that's what you were getting at.

Here's what I meant by "somewhat between software and hardware."

There's a general evolution of software into hardware.  The one that I'm most familiar with is computer graphics.  I used to write graphics primitives like rasterizing lines and polygons, anti-aliasing, 3-D projections, hidden surface removal, etc.  Now, many graphics chips do all that in hardware.

My understanding of computer task evolution is that things start as high-level software, eventually become libraries, might be implemented as microcode or in some firmware implementation, then as an FPGA, and eventually fabricated directly in silicon.  Along that continuum, firmware is between software and hardware.

Incidentally, that's one of the largest difficulties I see with opposing patentability of software.  Aside from the manner of implementation, there really isn't all that much difference between a pure software software implementation and a pure hardware implementation -- e.g., either burning an FPGA or fabricating an ASIC or other direct fabrication in silicon.  Many of my claims cover all those embodiments.  I don't see a reason to exclude some embodiments and allow patents on other embodiments.  Yeah, I realize that patentability of software isn't really much in doubt right now, but it was when I started in the early 1990s.  Perhaps that training is why I don't have much problem with Bilski.

Regards.

[khazzah]

Here's what I meant by "somewhat between software and hardware."

There's a general evolution of software into hardware.  The one that I'm most familiar with is computer graphics.  I used to write graphics primitives like rasterizing lines and polygons, anti-aliasing, 3-D projections, hidden surface removal, etc.  Now, many graphics chips do all that in hardware.

My understanding of computer task evolution is that things start as high-level software, eventually become libraries, might be implemented as microcode or in some firmware implementation, then as an FPGA, and eventually fabricated directly in silicon.  Along that continuum, firmware is between software and hardware.

Ahh. OK, I agree that firmware is "between" software and hardware in that sense. Probably irrelevant for most of what we're discussing, but I'm glad to understand your position.

Incidentally, that's one of the largest difficulties I see with opposing patentability of software.  Aside from the manner of implementation, there really isn't all that much difference between a pure software software implementation and a pure hardware implementation -- e.g., either burning an FPGA or fabricating an ASIC or other direct fabrication in silicon. 

Amen. You've eloquently expressed my biggest objection to the anti-software-patent position. I think most software patent detractors have never ever considered this because they simply don't view the stuff in software patents as ever being implemented in silicon.

However, the fact that many of the inventions which are implemented in software are *unlikely candidates* for being implemented in silicon is irrelevant for deciding what subject matter is appropriate for patent protection.

[Isaac]

Amen. You've eloquently expressed my biggest objection to the anti-software-patent position. I think most software patent detractors have never ever considered this because they simply don't view the stuff in software patents as ever being implemented in silicon.

Some haven't, but I have discussed software patents with detractors that are a little more sophisticated in their objections.  They expect that a method claim involving a silicon or hardware implementation would recite aspects of hardware on which they are implemented.  They would object to naked method claims that don't recite machine components or a transform of a material object as well as claims that recite only components of a general purpose computer.   If those limitations were enforced, then claims might never read on software written for a general purpose computer.

Of course the end result would be weak patents that could easily be worked around by using software/firmware, but many people don't give a hoot about that.

[IntelProp007]

The "relay section" refers to part of a program which, when executed by a processor, relays a communication from one wireless device to another wireless device. The description can be similar althuogh with more detail about the stuctures and algorightms used. The RCT v. Microsoft case is the case I had in mind. I remember reading some commentary that suggested, now here I change my original quesiton just slightly, the Bilski hurdle could more easily be overcome by adding some machine-type elements into the detailed description (earlier I said claim) that provide context for the "a relay section for relaying the communication..." This is what I meant by "context" in the subject line, and shuold have mentioend earlier. Really what I am trying to avoid is having to recite a recording medium every time there is a program (or a "section" of a program) cited in a claim. So, for example, in the present example, I am wondering if, in view of SCt Bilski and RCT v. Microsoft, the claim could recite  "a relay section for relaying the communication..." without having to define in the claim that the relay section is part of a program encoded in a recording medium. In otehr words, just recite the relay section and leave it to the detailed description to explain that the relay section may be configured as a program as part of software in a recordning medium or alternatively as hardware (choose your hardware - ASIC?). I recognize no one really knows the reach of Bilski, but do you think RCT suggests a more lenient and interpret-patent-eligibility-in-view-of-the-spec approach (thus affording us an opportunity to drop the recordning medium clauses)? Another matter I mentioned in my original question, albeit not so clearly, was that the claim when interpreted under the broadest reasobale std would encompass both software and hardware, and because software is part of the scope, thus patent ineligible. Thank you for your earlier comments, and I look forward to your future comments.

[JimIvey]

The "relay section" refers to part of a program which, when executed by a processor, relays a communication from one wireless device to another wireless device.

I don't think you have a 101 problem. 

However, there are examiners who will argue that you and I are wireless devices, the our brains are processors and the behavior of the speech processing regions of our brains are "relay sections" that "relay communication" (speak, or even as I'm doing here, type) from one to the other.  Given that our synapses work, at least in part, using electrical charges, we are also electronic wireless devices.  They might go so far as to argue that people who have swallowed some sand at the beach are "silicon-based" and can similarly communicate through their "relay sections".

But, you should be able to prevail over such BS.

Ahh. OK, I agree that firmware is "between" software and hardware in that sense. Probably irrelevant for most of what we're discussing, but I'm glad to understand your position.

I don't quite see it as irrelevant.  Each migration toward direct implementation in silicon is a significant change in expression toward one capable of implementation in silicon:  ruby -> C++ -> assembler -> microcode -> FPGA -> chip spec (also functional blocks that are converted to a layout using some automated process, ala Cadence).  In other words, each successive expression requires additional details until all the details needed for a hardware-only expression are provided.  To turn it around, each expression is successively less abstracted from a hardware-only expression.  I'd place "firmware" (as I understand it) very close to microcode on that continuum, and I'm not sure whether microcode is properly considered "software" or "hardware" or perhaps a little of both.

They expect that a method claim involving a silicon or hardware implementation would recite aspects of hardware on which they are implemented.  They would object to naked method claims that don't recite machine components or a transform of a material object as well as claims that recite only components of a general purpose computer.   If those limitations were enforced, then claims might never read on software written for a general purpose computer.

Yes, but why is the covering a pure software implementation where the line ought to be drawn?

To arbitrarily carve out software as a patent-free zone requires leaving open clear and easy workarounds for would-be infringers.  Given that software methods can be implemented in hardware and that hardware methods can be implemented in software, any method claim reading only on hardware elements can be circumvented by pure software implementations.

In computer science, the distinction between hardware and software implementations is really just an implementation choice.  Technologically, they're largely indistinguishable.  As to why the law ought to treat indistinguishable things as distinguishable is beyond me.

Regards.

[Isaac]

Yes, but why is the covering a pure software implementation where the line ought to be drawn?

It is not.  But the heart wants what the heart wants.

[IntelProp007]

JimIvey, I recall in one of your earleir posts you mentioning ways to claim software included by way of a computer readable medium, or as part of a module stored in memory, etc. I think this is persuasive in getting around the "software is not patent eligible" doctrine. However, if there is no mention of a comptuer readable medium or memory module in the claim, but some machine-type elements are described in the spec, then what result? For example, if the claim recites "a relay section for relaying the communication..." and the description states that the relay section can be realized/implemented/whatever by way of software instructions embedded in a recording medium, etc., then is this sufficient "context" under the recent RCT v Microsoft decision? It seems to me that the language the Fed. Cir. used in RCT suggests a more lenient approach on patent eligibility.

khazzah mentioned, "It definitely hurt Bilski that no computers were described in the application and definitely helped RCT that computers were described as a mechanism for implementing the algorithms." Frankly, I think this is a key distinction between the two cases, and suggests that "context" will indeed play a larger role. It also suggests that the Fed. Cir. may interpret questions of patent eligibility by reading terms from the spec into the claim to give a claim term "context".

[JimIvey]

However, if there is no mention of a comptuer readable medium or memory module in the claim, but some machine-type elements are described in the spec, then what result? For example, if the claim recites "a relay section for relaying the communication..." and the description states that the relay section can be realized/implemented/whatever by way of software instructions embedded in a recording medium, etc., then is this sufficient "context" under the recent RCT v Microsoft decision?

I don't believe that computer readable media are required by Section 101.  Not all inventions are computer-related.

I think what you've described is probably sufficient, though I would say a lot more about that in the spec -- particularly how the relay section does what it does.

It seems to me that the language the Fed. Cir. used in RCT suggests a more lenient approach on patent eligibility.

I don't think RCT changed the law of Section 101 at all.  I forget which judge/justice said it, but one said during oral argument in some case, "If I can throw my pen at it and hit it, it's not abstract."  Half-toning (the technology in RCT) transforms matter by putting black dots on white paper and requires a particular machine to do that.

The problem with the claims in Bilski was that you'd have to read a bunch of contracts and/or receipts from purchases and sales to see if you infringed.  The claim as written could conceivably be infringed by human traders on the floor of an exchange doing no more than buying and selling.

I still don't think that made the technology a law of nature or too abstract, but it was really pushing the envelope in that direction.

But, by comparison, the claims in RCT are on solid footing vis-a-vis Section 101.

Regards.