Ex parte Blaker
Appeal 2009011364; Appl. No. 09/852,562; Tech. Center 2400
Decided: October 17, 2011
The subject matter of the application related to cryptographic systems. A representative claim on appeal read:
15. A method of operating a cryptographic data processing system that comprises a host processor, a system memory coupled to the host processor, and a cryptographic processor integrated circuit that is coupled to the host processor and the system memory, the method comprising:
providing a command queue in the system memory;
loading a command block into the command queue using the host processor;
setting a value of an interrupt field in the command block to request an interrupt when the command block has been executed;
executing the command block using the cryptographic processor; and
invoking an interrupt using the cryptographic processor after executing the command block if the interrupt field in the command block is set to the value to request the interrupt.
In a first Office Action, the independent claims were all rejected as either anticipated or obvious. In the anticipation rejection of claim 15, the entire text of the claim was reproduced, followed by a cite to four sections of the reference.
In response, the Applicant argued that "invoking an interrupt using the cryptographic processor" was not taught. According to the Applicant, the final relied-upon portion of the reference "pertains to the rendering engine 104 generating an interrupt for the host processor rather than the graphics processor 114. The rendering engine 104 is used for address translation (Hussain, col. 4, lines 2-8) and, therefore, is unrelated to a cryptographic processor as recited in Claim 15." (Emphasis added.)
All rejections were maintained in the final Office Action. The final Office Action included a more detailed explanation of how the reference taught the invoking limitation:
The argument presented is based on the assertion that Hussain fails to teach the feature of ["invoking an interrupt using a cryptoprocessor ..."] Yet a careful reading of Hussain shows that such is indeed taught at the passages cited in the rejection; in col. 6 1ine 59 through col. 7 line 6; where a rendering engine is able to interrupt a host processor using sent values of a "ready variable".
The Applicant appealed and argued the "invoking using a cryptographic processor" language in claim 15. Specifically, the Applicant argued that the reference's rendering engine was not a cryptographic processor.
The aforementioned passage of Hussain cited in the First Action pertains to the rendering engine 104 generating an interrupt for the host processor rather than the graphics processor 114. The rendering engine 104 is used for address translation (Hussain, col. 4, lines 2 - 8) and, therefore, is unrelated to a cryptographic processor as recited in Claim 15. The Final Action continues to maintain the rejection based on the operation of the rendering engine 104 (Final Action, page 3), but Appellants continue to maintain that the rendering engine 104 of Hussain is not a cryptographic processor as recited in Claim 15.
The Examiner's Answer included an explanation of why the claimed "cryptographic processor" corresponded to the rendering engine in the reference:
[Hussain] col.4 lines 25-33 Rendering Engine and Back-End Graphics processor are taught as components of a "Graphic Processor." This reads on a cryptographic processor by virtue of its ability to undertake graphics processing of the type commonly used in steganography and the watermarking or encoding of graphical data.
The Applicant did not file a Reply Brief.
The Board summarily affirmed the anticipation rejection with little explanation:
[W]e adopt the Examiner’s findings as our own. See Ans. 9-10, 19. Additionally, we reiterate that Hussain discloses the rendering engine 104 and the graphics back end processor 114 can collectively be a graphics processor (see FF 1-2).
My two cents: The Examiner's interpretation was ridiculous. The Examiner's reasoning goes like this: reference teaches a graphics processor; a graphics processor can be used in steganography (hiding messages in images); therefore, a graphics processor is a cryptographic processor.
While the logic is appealing, it flies in the face of what these terms mean to a POSITA. That is, a POSITA understands a cryptographic processor to be one type of processor and a graphic processor to be quite a different type of processor.
The error made by the Examiner – and ratified by the Board – is in parsing the claim term too finely. A "cryptographic processor" is not merely a processor that happens to do cryptography, but is instead one that is designed to do cryptography. I've been using a PC to connect to secure web sites for many years, and that involves cryptographic functions. Yet despite the fact that my x86 did SSL, it did so with a general purpose microprocessor, not a cryptographic processor. (Intel recently added special instructions to enable fast and secure data encryption and decryption, so maybe the latest x86 chips are "cryptographic processors.")
The Board makes this mistake far too often. I've blogged about two other decisions where the Board made showed a lack of basic understanding about differences in processor types: digital signal processor (see my post here on Ex parte Giacalone) and graphics processor. (see my post here on Ex parte Brunner).
Finally, the Applicant made a big mistake by not filing a Reply Brief. Since the first real explanation of the Examiner's interpretation didn't appear until the Answer, the Applicant could have properly raised this point in the Reply Brief. Unfortunately, the rules won't let you evidence at this late stage, only dictionary definitions. If you need more of a technical explanation than would be supported by a dictionary definition, you'd have to go with attorney argument and hope that the Board didn't have a problem with this. Maybe you just stick with the more basic claim construction rule that you can't pick apart or deconstruct individual words in a claim term when the term itself has meaning.
The other option is to pull the case from appeal in order to introduce evidence. And that involves paying an RCE fee, since an Examiner making claim construction explicit probably isn't a New Ground of Rejection which gives the Applicant the right to reopen pros without an RCE. But until Examiners are required to put an explicit claim construction on the record, we'll have to deal with situations like this.