Monday, October 10, 2011

BPAI broadly interprets "hardware error" as "error related to hardware" rather than "error in hardware"

Takeaway: In Ex parte Yamada, the BPAI agreed with Examiner that "hardware error" read on memory usage reaching a critical threshold because memory was a type of hardware. The Applicant presented a definition of "hardware error" as "an error caused by malfunction of a physical component of the computer," then argued an error in memory usage was a software error rather than an error in a physical component. The Board characterized this argument as irrelevant for not being within the scope of the recited claim limitations.


Details:
Ex parte Yamada
Appeal 2008005668; Appl. No. 10/607,158; Tech. Center 2100
Decided  December 9, 2009

The first independent claim read:

1. A method of terminating an affected application program thread, comprising:
     receiving an indication of a hardware error associated with an application program thread;
     determining the application program thread to be in a user operation mode; and
     terminating the application program.

At issue was the proper construction of the term "hardware error."

The Examiner rejected the claims as anticipated. The Applicant argued that the reference taught prompting a user when memory usage reaches a critical threshold rather than when a hardware error occurs.  In a Final Office Action, the Examiner explained that "since this error affects memory which is hardware, then Mathur discloses a hardware error."

On appeal, the Applicant referred to a definition of "hardware error" from an online dictionary: "error resulting from a malfunction of some physical component of the computer." The Applicant then argued that memory usage above a threshold is not caused by a malfunction of a physical component. The Applicant then explained that under the Examiner's interpretation, even an error that occurred when software allocated more memory than was currently available would be considered a "hardware error."
[T]he above example shows that the Examiner's asisertion is not consistent with the plain meaning of a hardware error as would be understood by one of ordinary sklll in the art.

In the Answer, the Examiner switched position and argued that it was the "system freeze" described in the reference that corresponded to the claimed "hardware error."
Examiner brings to the attention of the Appellant that a system freeze is equivalent to a hardware error. It is hardware error for many reasons. First, it is well known that a system is hardware. An error message that tells the user that the system is out of memory and freezes the rest of the system is a notification of a hardware error (freezing). ... The Examiner also brings to the attention of the Applicant that a physical component was never part of the claim language. As a result, a system freeze reads on a hardware error.

The BPAI first interpreted "hardware error" and found that its broadest reasonable interpretation was "an error related to computer system hardware, e.g., system memory." The Board further found that this interpretation was consistent with the Applicant's specification. In particular, the Board noted that the specification referred to a machine check abort (MCA) signal as a "hardware error signal” and that the specification further stated that the MCA signal "may occur when an error occurs in reading and loading memory data, i.e., from corrupted memory."

Applying this interpretation to the teachings of the reference, the Board found that:
Exceeding a memory usage threshold (causing unstable system performance (FF 3)) and a system “freeze” are system errors related to system hardware (memory), i.e., system hardware error. Appellant’s claimed limitation – receiving an indication of a hardware error – is structurally and functionally equivalent to the method described by Mathur. Appellant’s argument that a hardware error is an “error caused by malfunction of a physical component of the computer” is not within the scope of the recited claim limitations, and is therefore irrelevant.

The Board then affirmed the anticipation rejection.

My two cents: The Board got this one wrong. Certainly memory is a type of hardware. But the term "hardware error" is best understood as an error in a hardware component, not simply an error associated with or related to a hardware component. That is, I agree with the definition presented by the Applicant in the Appeal Brief.

The Board incorrectly characterized the Applicant's argument about the meaning of a claim term ("a hardware error is an 'error caused by malfunction of a physical component of the computer' ") as arguing outside the claims.  You're not arguing outside the claims if the stuff you're arguing about is captured in the meaning of a claim term. 

Once "hardware error" is properly understood as "error in the hardware," it's clear to a POSITA that the reference doesn't teach. While memory usage reaching a critical point may qualify as an error related to memory, it is not an error in the memory itself. The Applicant tried to make this point in the Appeal Brief, but apparently didn't explain the point well enough.

With regard to the system freeze, the Examiner's statement that "a system is hardware" glosses over the fact that a computer system includes software and hardware, and the term "system freeze" doesn't itself say whether the error is an error in a hardware component or in a software component. However, the reference itself clearly taught that the system freeze was an error in memory allocation, which is a software error and not a hardware error. Unfortunately, the Applicant didn't address the system freeze teaching, since the Examiner didn't bring it up until the Answer, and the Applicant didn't file a Reply Brief. As a result, the Applicant may well have lost on this system freeze teaching even if the Applicant did a better job of arguing about the memory usage threshold teaching.

Finally, the Applicant might have strengthened his position by making arguments for dependent claims which more clearly spelled out the type of error meant by "hardware error," e.g., memory read error.

17 comments:

  1. I agree with you, Karen. The examiner's definition here is unreasonably broad.

    ReplyDelete
  2. A couple things. First, although I haven't read the opinion, my guess is that the new Federal Circuit cases about new grounds of rejection apply -- as I am highly doubtful that the Examiner presented this claim construction during examination.

    Second, I've seen these games played before by the BPAI and this game in particular. The interpretation of "hardware error" as "error related to hardware" essentially reads the term "hardware" out of the claim. I assume that the term "hardware error" was used to distinguish from "software error." However, any software error is, in some (even very minor) respects, related to hardware. As such, what the BPAI did was transform the term "hardware error" into "error."

    The practice tip out of this is to make sure to define, within the specification, any important term that you believe is open to interpretation. I know patent prosecutors don't like to define terms because they are limited (and therefore narrowed). However, broad claims/terms are worthless if the Examiner/BPAI plays the broadest (un)reasonable interpretation game and you don't get allowed claims.

    ReplyDelete
  3. Given the Examiner's position switch in the Answer, I think the Applicant had a window of opportunity to submit a declaration from "one of ordinary skill" that undermined the Examiner's interpretation and bolstered the Applicant's. As I understand it, while the declaration would have been "new" evidence, the rules would still allow it to be submitted based on the justification that the Examiner had switched positions in the Answer and brought up a new interpretation.

    ReplyDelete
  4. I think that there can several "hardware error" types - in hardware, caused by hardware etc.
    Also, there are a numerous types of "software error" - error is source code, infinite loops, etc.
    Software products work with different types of hardware - memory, processor, scanner, etc. So, if my software don't work, it can be due to "software error" and/or "hardware error". For example, i have a software that use scanner to get image to the HDD. If i suddenly turn off scanner during work of this software - it will be a "hardware error".

    So i don't think that the Board got this wrong.

    ReplyDelete
  5. "If i suddenly turn off scanner during work of this software - it will be a 'hardware error'."

    No ... even the software crashes, then it is a software error. The hardware didn't fail (i.e., there wasn't an error in the hardware).

    If the hardware shut down because it was broken, then that is a hardware error.

    If there was a hardware error, and the software didn't know how to handle the scanner shutting down, then there is both a hardware error and a software error.

    You have to be able to distinguish a hardware error from a software error. Otherwise, nobody will know what you are talking about.

    ReplyDelete
  6. note that the claim never said anything being broken, if the system is out of memory, that is not a software problem per se but may be a physical limitation ("error") of the hardware, and so the board's interpretation of this being an "error" is not so far out there

    ReplyDelete
  7. "so the board's interpretation of this being an 'error' is not so far out there."

    If you think the BPAI's interpretation is OK, then explain to me what is a software error versus what is a hardware error. Do so while distinguishing a hardware error from a software error.

    ReplyDelete
  8. Basically software is based hardware. Software code stored in memory, processed using processor , etc. So, every software error is based on hardware. Simply, i put a code that will perform a division by 0, then i caould say that the code is right - but my processor can't do this operation, so this is not a software error.

    We need clear definition of terms "software error" and "hardware error".

    ReplyDelete
  9. "every software error is based on hardware."

    Herein lies the problem. Applicants wanted to distinguish hardware error from software error. However, the BPAI simply rewrites the term to just "error." In essense, they ignored claim limitations as a result of their interpretation -- which it why I believe the BPAI's interpretation is unreasonable.

    ReplyDelete
  10. "Herein lies the problem. Applicants wanted to distinguish hardware error from software error."

    They wanted to but failed to? Meh, happens all the time. We can't just go around being easy on applicant's now can we?

    ReplyDelete
  11. "If you think the BPAI's interpretation is OK, then explain to me what is a software error versus what is a hardware error. Do so while distinguishing a hardware error from a software error."

    2ez

    a software error is something like bugs, glitches, etc. It is not based on a limitation of the hardware - the hardware works as intended but improper instructions for the use thereof produce unintended results. Ex. hardware is perfectly capable of calculating 1+1 or 1+2, if you programmed 1+1 but wanted 1+2 that is a software error. Running out of memory may very well be a hardware error as a program may be coded to use a certain amount, but the system simply doesn't have enough (physical) resources. This could also be a software error if poorly coded but the fact remains it can be a result of limitations in hardware, hence hardware error.

    ReplyDelete
  12. >Running out of memory may very well be a
    >hardware error as a program may be coded to
    >use a certain amount, but the system simply
    >doesn't have enough (physical) resources.

    Disagree (strongly). This scenario is not hardware error because it is not an error *in the hardware*. The hardware is not malfunctioning.

    You suggest that it's a "software error" only if the program didn't *handle* the error properly.

    Disagree. An error code returned by malloc/OS-specific alloc/etc. is a "software error". Regardless of whether the program *handled* the error invisibly (so that user never knew), gracefully (error message), or not at all (system crash).

    ReplyDelete
  13. >Applicants wanted to distinguish hardware
    >error from software error.

    Who thinks that changing the claim to "error in hardware" captures the distinction? I think "hardware error" MEANS "error in hardware" -- but I think a claim that reads "error in hardware" BETTER captures the distinction.

    To those that say "software runs on hardware, therefore even a software error is a hardware error at its core" -- then how would you express the distinction? Or is it inexpressible in your world?

    ReplyDelete
  14. As a former OS and hardware engineer, I can opine as one of ordinary skill: "hardware error" means malfunctioning hardware.

    Without reading the reference, a memory-related "system freeze" is almost certainly a software error. The operating system's memory management system erred by allowing itself to run out of physical memory.

    Requiring a defintion would be absurd. "Hardware error" is a term of art. The law can't seriously be that an applicant has to define every term in the claims, no matter how well established -- that's just a crazy thought.

    The applicant should request reconsideration. In light of Leithem and Stepan, this is clearly a "new ground." The Board itself has held that a new claim construction is a "new ground." See my comments at http://www.uspto.gov/ip/boards/bpai/procedures/rules/rule_comment_nov2010_boundy.pdf at page 17.

    As part of the reconsideration, the applicant can adduce new dictionary definitions -- both the Supreme Court and Federal Circuit have held that a court (and therefore presumably the Board) can *always* take judicial notice of dictionary definitions. See my comment letter at

    http://www.uspto.gov/ip/boards/bpai/procedures/rules/rule_comment_nov2010_boundy2.pdf

    ReplyDelete
  15. "This could also be a software error if poorly coded but the fact remains it can be a result of limitations in hardware, hence hardware error."

    A flat-head screw is halfway into a board. A user takes out a philips-head screwdriver, and attempts to finish screwing in the screw ... he fails. You say it is a hardware error because it is a result in the limitations of the hardware. I say it is a user error because it is a result in the failure of the user. The hardware was perfectly functional -- it was only being used improperly.

    ReplyDelete
  16. "Or is it inexpressible in your world?"

    6 is like a food critic that has never attempted to cook a meal. He thinks everything could be make better but doesn't understand how to do it.

    ReplyDelete
  17. " then how would you express the distinction?"

    A hardware failure?

    "6 is like a food critic that has never attempted to cook a meal. "

    It wasn't me that made the comment in this thread. Nor was it me that made this construction.

    Although I actually know very well how to do it.

    ReplyDelete