Sunday, July 11, 2010

First BPAI decision after Bilski v. Kappos

Takeaway: It took about two weeks for the BPAI to release the first decision applying Bilski v. Kappos: Ex parte Proudler. In this decision, the Board entered a new ground of rejection under § 101. Citing Bilski v. Kappos for the proposition that abstract ideas are unpatentable, the Board determined that the "computer apparatus" claim was directed to an abstract idea. "The manner in which the so-called 'computer apparatus' of the preamble of independent claim 50 is recited in the body of this claim is characterized as directly reciting in its two clauses 'programming for' achieving a certain abstract functionality. Thus, no true hardware structure is recited."

Details:
Ex parte Proudler
Appeal 2009-006599, Serial No. 10/643,306, Tech. Center 2400
Decided July 7, 2010

This application involves secure computing, and the claims are directed to applying individualized security rules to data items. On appeal were four independent claims: two method claims, a computer readable medium claim, and a computer apparatus claim. The Board vacated the prior art rejections, raised a new rejection under § 101, and remanded to the Examiner.

The Board found that:
[The] claimed invention is directed to software per se, abstract ideas, abstract concepts, and the like, including data per se, data items, data structures, usage rules, and the abstract intellectual processes associating them within the claims on appeal.
The Board said that the language of the computer apparatus claim clearly showed that the claim was directed to an abstract idea:
The manner in which the so-called 'computer apparatus' of the preamble of independent claim 50 is recited in the body of this claim is characterized as directly reciting in its two clauses 'programming for' achieving a certain abstract functionality. Thus, no true hardware structure is recited."
In making this determination, the Board seemed to rely on two statements in the specification. One was the Abstract, which restated the method claim and mentioned a "computing entity." Another statement in the specification said that "A computing entity, either hardware or software, is often called a 'node' and this term will appear hereinafter."

The Board used the same reasoning to find that the method claim was directed to an abstract idea, since it recited "computing entity" in the body. The Board used different reasoning to reject the computer readable medium claim: that claim encompassed signals per se, which are unpatentable under In re Nuijten.

My two cents: I have two comments about Proudler. First, the BPAI did not use the Machine-or Transformation test in it's § 101 analysis, and instead used "abstract ideas." Yet the Board's stated reason for finding that the computer apparatus claim was directed to an abstract idea was "no true hardware structure was required." How is this any different than applying the Machine-or-Transformation test? Is "abstract idea" just another way of stating "not tied to a particular machine" ?

My second comment about Proudler: this case shows the danger of being vague about what you mean by "software." Examiners, the BPAI, and the courts seem to think that the term "software" implies "not tied to hardware." If your claim sounds like "software" – even if the claim doesn't contain that term – the BPAI will redesignate them as "software per se." By which they seem to mean "software in the abstract," or as I call it, "software floating in the ether."

Speaking as a former POSITA, that's not what the term "software" means to me. I say "software" means "instructions executing on a processor." That is, software is tied to hardware, and as such, is not "abstract."

I suppose you can try making this argument in an expert declaration. But I think a better approach to avoid/overcome a § 101 rejection for "software per se" is a specification that explains what is meant by the terms "software" and "hardware," and explains the relationship between the two.

Other Posts on Ex parte Proudler:  This decision has generated a fair amount of discussion in the blogosophere. If you want some other viewpoints, including some from non-patent attorneys, check out these posts:
Patents4Software
Visae Patentes
Groklaw
Software Freedom Law Center
ArsTechnica


28 comments:

  1. "I say "software" means "instructions executing on a processor." "

    I think you meant to say: "the abstract idea of instructions executing on a processor."

    Didn't ya? Yes, you did.

    ReplyDelete
  2. Software, by definition, is distinct and separate from hardware.
    Just because they're the set of instructions you can use to make a computer achieve a result does not tie it to hardware.
    It's like a piano partiture you can use to play a particular piece of music on a piano.

    ReplyDelete
  3. >Software, by definition, is distinct and
    >separate from hardware.

    I don't disagree. But I still maintain that the word "software" as understood by a POSITA implies a *tie* to hardware. Software is tied to hardware while still being something different from hardware.

    >Software, by definition,

    You haven't actually presented a definition. Nor have I. I'm sure a wide variety of definitions are available. Some probably support your position, some probably support mine, and some are probably don't help resolve the question at all.

    >Just because they're the set of instructions
    >you can use to make a computer achieve a
    >result does not tie it to hardware.

    I suppose I don't disagree with this statement either. I don't assert that software is *tied* to hardware because it can execute on hardware. Instead, I make that assertion because I believe that's just how a POSITA understands the term.

    >It's like a piano partiture you can use to
    >play a particular piece of music on a piano.

    Even if sheet music is a good analogy to "software in the abstract", it's irrelevant to my argument, which is that the term "software" doesn't imply "in the abstract".

    ReplyDelete
  4. Software, without more -- without explicitly being tied, for example, to a storage medium or to a processor-like element -- is pure, disembodied code, and in that state is incapable of being executed to accomplish anything useful. We examiners are driven to this interpretation partly because the patenting community seeks to have the broadest meaning applied to the scope of the software, I guess, so they can find infringement anywhere, and in any circumstances, such as, for example, code being transmitted through RF or fiber optics. This scope, we are taught, exceeds statutory subject matter for program code.

    FYI, no criticism implied.

    ReplyDelete
  5. hmm...software is not actually tied to hardware until and unless it is compiled.

    Excuse me for being really very blunt, but the comment that comes after 'my two cents' is made by some one who has never written software, does not really understand what software is, and should really get a clue before commenting on this, as it is important stuff.

    ReplyDelete
  6. >hmm...software is not actually tied to hardware
    >until and unless it is compiled.

    I don't disagree. It all boils down to what someone means when they use the word "software".

    As I alluded to in my post, a large part of the problem is that folks use the term loosely without defining what they mean.

    ReplyDelete
  7. >Software, without more -- without explicitly
    >being tied, for example, to a storage medium or
    >to a processor-like element -- is pure,
    >disembodied code ...
    >We examiners are driven to this interpretation
    >partly because the patenting community seeks
    >to have the broadest meaning applied to the
    >scope of the software,

    By "driven to this interpretation", are you saying that stuff in the spec allows you to interpret broadly?

    If that's what you're saying, then yeah, based on a lot of specs I've read, I can see how you come out with a broad reading of "software" in certain cases. Absolutely.

    ReplyDelete
  8. "that's just how a POSITA understands the term. "

    POSITA's understanding cannot change reality pumpkin. Just because POSITA has deluded himself into thinking something is going on that isn't doesn't mean that reality will warp into that mold, and it certainly doesn't mean that a court should warp reality into that mold in order to come to their decision. In fact, it is indicative of a situation where the decision should simply go against the nonsensical notion that software, compiled or uncompiled is non-abstract.

    Just fyi, compiled code is just as abstract, and preempts just as many abstract ideas as non-compiled code is. Translating one string of 1's and 0's into another string of 1's and 0's doesn't change its abstractness in the least.

    I cannot believe the ridiculousness you people have brought into mah patent system. I will smite it at every opportunity given me.

    ReplyDelete
  9. The issue is not whether software is tied to hardware, but whether or not the software is tied to a "specific machine".

    Compiled software is merely a set of instructions for a "processor" that performs mathematical and logical operations on its input. That "processor" could be an Intel Pentium chip, a Motorola 6502 chip (the Apple II), or a human with an adding machine.

    Any of these "processors" are capable of doing the math, so the software isn't "tied" to a "specific machine".

    Please also recall that mathematics and logic are not patentable, so anything that could be reduced to instructions for a general purpose "processor" (which is only capable of performing math and logic operations) shouldn't have been patentable in the first place.

    ReplyDelete
  10. >The issue is not whether software is tied to
    >hardware, but whether or not the software is
    >tied to a "specific machine".

    Actually, I see that as a separate issue. To win on 101, it might turn out that an Applicant has to win on both prongs: not abstract; AND tied to a particular machine or transforming an article. Because the "abstract idea" analysis under Bilski v. Kappos seems to be separate from MoT.

    But in my view, if you are tied to *a machine*, you've left the realm of abstract. Which means that if software implies a tie to a machine, then claims to software pass the first prong.

    You're right that under the MoT test, the method must be tied to a "particular machine". We've yet to get a definitive answer on what that phrase means. The BPAI has already interpreted this phrase. The Federal Circuit will answer the question eventually.

    ReplyDelete
  11. I have some background on why I said that software is separate from hardware by definition, source wikipedia:
    "Computer software, or just software, is the collection of computer programs and related data that provide the instructions telling a computer what to do. The term was coined to contrast to the old term hardware (meaning physical devices). In contrast to hardware, software is intangible, meaning it "cannot be touched".[1] Software is also sometimes used in a more narrow sense, meaning application software only. Sometimes the term includes data that has not traditionally been associated with computers, such as film, tapes and records.[2]"
    The intangibility of software is what makes it abstract. So "software in the abstract" or "software floating in the ether" are actually pleonasms.
    If software were tied to hardware, it would be hardware.

    ReplyDelete
  12. The issue isn't so much that a particular set of instructions executing on a processor should be patentable--that's already covered by copyright laws. The issue is that the abstraction of those instructions is widely considered patentable--that is, the algorithm itself, which *is* an abstract concept. If you want to argue that instructions executing on the metal is patentable, I don't disagree, but that essentially proves nothing beyond the patentibability of the binary itself--saying that that covers separate implementations of those instructions in different high-level languages is roughly equivalent to patenting a new and innovative car and deriving from that the right to patent the process of "driving from A to B".

    ReplyDelete
  13. Then let's try to define software!

    "Software" may refer to a particular set of binary-encoded instructions to be executed on a particular processor. This is what is frequently cited as patentable. Unfortunately, patenting this is useless--it's already covered by copyright law. Patenting the very ones and zeros has never, and likely will never, be of interest.

    "Software" may also refer to the instructions that were written in a human-readable language (such as assembly, C, Perl, Java, &c) to be transformed into the above instructions. While this could be considered patentable by the same argument, it's also covered by copyright (that is, implementing precisely the same instructions in the same order in the same language is extrinsically identical to copying the program) and thus pretty much useless.

    Lastly, we can define software as the processes that the programmer effects when he writes the above instructions. These are commonly known as algorithms, which are pure mathematical entities, and, as we know, mathematics is not patentable.

    This is the difficulty--it's commonly cited that software is patentable at the lowest level, but the patentablility is applied at the highest level.

    ReplyDelete
  14. "I say "software" means "instructions executing on a processor." That is, software is tied to hardware, and as such, is not "abstract.""

    But then you fall into the trap that your software is a _particular_ set of instructions running on a _particular_ processor. So all one has to do to bypass the patent is to recompile the source code to run on a different CPU with different settings. The instructions running on the processor will be demonstrably different from the one in the patent.

    ReplyDelete
  15. Bringing in compilation is just a distraction. Compiling code doesn't tie it to a particular machine. Ever heard of an emulator? Compiling code just changes the language the software is expressed in.

    ReplyDelete
  16. This whole issue of whether software is tied to hardware is needlessly tedious. As long as a person of skill in the art would understand from reading the spec that what is claimed is software, that should be enough for determining whether the subject matter is patentable. Code should be patentable period.

    ReplyDelete
  17. I wonder if one way to get around Bilski is to describe hardware in the spec and include an example of the actual code. Then you write claims using means plus function language. No one can argue that you are not concretely claiming your process. Granted -- mpf will ended up making the scope narrow, but you'll still get a patent. Anyway... the S.Ct. still thinks DOE is still good law even if the Fed. Cir. doesn't.

    ReplyDelete
  18. >As long as a person of skill in the art would
    >understand from reading the spec that what is >claimed is software, that should be enough for
    >determining whether the subject matter is
    >patentable. Code should be patentable period.

    Sounds like you're commenting not on what the law currently is, but what it *should* be.

    I think the "needlessly tedious" discussions are a byproduct of what the law currently is -- namely, that "abstract ideas" are not patentable.

    ReplyDelete
  19. Right. My comment was about what the law should be.

    ReplyDelete
  20. Hi Karen,

    Just spotted your blog via a UK site and love it.

    Keep up the good work!

    The debate over what the indefinite word "software" means will go on probably forever. Blind men circling the elephant as usual.

    See one of my posts re that here:
    http://stepback-marks.blogspot.com/2010/07/3-x-3-blind-bilski-justices.html

    I'm also working on --but it's not yet ready for prime time-- a re-write of the B.v.K. decision As It Should Have Been Opined (AISHBO) here:
    http://stepback-marks.blogspot.com/2010/07/bilski-v-kappos-aishbo.html

    You can keep tabs of when and where the BPAI releases its post Bilski decisions with a simple filtered search:

    http://des.uspto.gov/Foia/DispatchBPAIServlet?Objtype=ser&SearchId=&SearchRng=decDt&txtInput_StartDate=06%2F01%2F2010&txtInput_EndDate=&docTextSearch=bilski&page=30

    As I said, keep up the good fight and good work !!

    ReplyDelete
  21. ">Software, by definition, is distinct and
    >separate from hardware.

    I don't disagree. "


    --@comment 3# above.

    Karen, well you should have disagreed.

    The term "hardware" has no clear and distinct definition, the term "software" has no clear and distinct definition, and the two can easily overlap.

    Consider for example, a one-time programmed FPGA. What is that? Hardware? Software? Firmware? The correct answer is yes, yes and yes. It's all three at once.

    Quite frankly, the electrons don't give a darn what we call it and the transistors don't give a darn. They do their thing irrespective of what meaningless noises we throw at them.

    The debate regarding "hardware" versus "software" is as much meaningless gobbledygook as is the debate in Gulliver's Travels over which end of the egg should be cracked open for breakfast.

    ReplyDelete
  22. @step back

    I'm not entirely sure what you mean by "hardware" having no distinct definition--the firmware you cite is clearly software, no question about it. Heck, firmware in general is software, albeit software that somebody would like you to think of as hardware. You might treat it as de facto hardware (that is, the end user can't change it once written), but it's software by any definition of the word.

    Technically speaking, hardware has nothing to do with data--it is the physical device on which the electrons move, regardless of what is transferred. Likewise, software has nothing to do with the physical device, since it is merely data that is encoded in the electrons moving on the hardware. The idea that something could be both hard- and software is patently absurd. Something could be implemented by both hard- and software means (e.g., a Turing machine designed for a particular task vs that same machine implemented by a universal Turing machine), but the fact remains that the two are distinct and different, and ought to be treated differently in patents (in the same way you can patent a new and innovative hammer, but you can't patent using somebody else's hammer to do the same work as your new one).

    Of course, considering you seem to want people to be able to patent anything and everything ad absurdum (most computer scientists would consider patenting algorithms absurd, BTW), I'm probably wasting my breath.

    ReplyDelete
  23. >a one-time programmed FPGA. What is that?
    >Hardware? Software? Firmware?

    The FPGA is hardware. If the FPGA includes a processor that executes instructions (which some do), then the instructions executing on the proc-inside-FPGA make up firmware. Since firmware means "permanently stored software", that means these same instructions are also software.

    >Quite frankly, the electrons don't give a
    >darn what we call it and the transistors
    >don't give a darn.

    It's true that a thing remains a thing no matter what you call it. But my position (stated above) is that the things in question are different things, i.e., hardware is different than software.

    ReplyDelete
  24. @ Bruce:
    You said that if I define software as instructions executing on a processor, then I
    "fall into the trap that your software is a _particular_ set of instructions running on a _particular_ processor."

    I disagree. My claims don't specify a particular processor or particular set of instructions. Nor does my spec. Therefore, the scope of my claims is not so limited -- for the same reason that a claim which recites a screw isn't limited to a Phillips or a slotted, but instead covers the generic term "screw" as understood by a POSITA.

    ReplyDelete
  25. Wow, "software vs. hardware" -- which is which, nobody knows. There's no consensus here, that's pretty clear. Here's a fact though, to be considered. Tannenbaum's "Structured Computer Organization, 3rd Ed" 1990, addresses this conundrum by saying, and I quote "A central theme of this book that will occur over and over again is: Hardware and software are logically equivalent. Any operation performed by software can also be built directly into the hardware and any instruction executed by the hardware can also be simulated in software." We've been using this piece of prior art to make 103 rejections for a long time now. The take away is that the community will have to, at some future point, resolve how it feels about the equivalence of hardware and software, however defined. That's just my 2 cents worth.

    ReplyDelete
  26. I've been out of the fray for a while. Now jumping back in.

    Anonymous said (sometime last week)

    >The issue isn't so much that a particular set
    >of instructions executing on a processor
    >should be patentable--that's already covered
    >by copyright laws.

    Not exactly.

    Copyright covers something quite different: it protects against the act of *copying*. A patent covers infringing behavior even if the infringer comes up with the widget/process on his own. [Which is no doubt why some folks are fundamentally opposed to patents as being "unfair".]

    ReplyDelete
  27. >Hardware and software are logically equivalent.

    Absolutely. Great point.

    That's exactly why I have a problem with someone telling me that if I come up with a new algorithm for performing FFTs, 101 prevents me from getting a claim to a processor which *executes* the algorithm as instructions, but 101 does not prevent me from getting a claim to an ASIC or FPGA which implements the same *algorithm*.

    The choice between implementing a function in hardware or in software is a often a design tradeoff. When technology such as FPGAs and ASICs is expensive, we put those functions in software instead. When FPGAS/ASICS get cheaper, we put those functions in hardware instead.

    ReplyDelete
  28. Karen,

    Please forgive me in that I have the advantage of looking up your bio (since you use your real name) and it doesn't go vise versa (since I don't).

    Relative to you, I'm an old geezer.
    I was around when words like "hardware" and "software" first began to become part of the more common lingo.

    Originally, "hard"-ware meant it was relatively hard to change the operation of the circuit. One had to wait for the vacuum tubes to cool down, the high voltage capacitors to safely discharge, and then to pull out the trusty soldering gun and begin rewiring the stuff in the under chassis.

    Then along came this thing called an analog computer where you simply simply turn the knobs on the potentiometers to vary their resistance and thus change function with less hardship, hence "soft"-ware.

    Oh. Sorry. You thought that in the beginning the Lord created the digital microprocessor with 1Gbyte embedded DRAM and saw that it was good? No. There were analog circuits that performed "computations" long before the Von Neuman digital computer architecture came into popular usage (thanks to the invention of those new fangled things called 'transistors' and 'printed circuit boards')

    Even then, in the beginning, memory devices were extremely expensive and extremely slow. Ah, if only I could have another 4Kbytes of UV-EPROM memory and I would be king. But who could afford those things? And besides you had to cook it under the UV lights forever and wait even more time before the new programming took inside the UV-EPROM chip. So changing programming was still "hard", but nonetheless "softer" than having to pull out one's trusty soldering iron (or one's "wire-wrap" undoing tool -yeah right, what the heck is wire wrap?) and make a change that way.

    Today's young folk are born with a silver spoon under the tongue and $5 scientific calculator clasped in their newborn hand. They are easily fooled into the notion the "software" is abstract and "hardware" is the box you buy at the Fry's or Best Buy Computer outlet. No concept of what lurks under the hood. Sheesh.

    Let's just cut the wire that brings electrical power to your CPU and we'll see how long your abstract "software" wants to be "free".

    ReplyDelete