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.