Written by: Mark Terry

In a straightforward decision today, the Board of Patent Appeals and Interferences (BPAI) affirmed an Examiner’s obviousness rejection of a software invention based on a common prosecution mistake – the Appellant arguing limitations that are not in the claim. This post highlights a basic requirement of responding to Examiner rejections, especially when procuring software patents.

The case of Ex parte Kreiner (Appeal No. 2010-004976) involved a software invention used to design circuits. The disputed claim included the following limitation: “a software-based development environment for designing circuits or systems.” In responding to a 103 obviousness rejection, the Appellant argued that the cited reference was directed to software design tutorials and could not be used to design circuits, as claimed by the inventor. In short, the Appellant provided a standard “the cited reference does not teach the claim language” argument. The Appellant also asserted a standard “the proposed modification would render the cited reference unsatisfactory for its intended purpose” argument.

The Board decided:

“We do not see error with the Examiner’s position that Wood discloses a software-based development environment for designing circuits or systems including a plurality of functional units. Wood’s interactive tutorial software runs on a computer, includes tutorials on digital analysis for digital logic design, and has a demonstration of user interaction in which the user controls relevant parameters and then observes the effects of parameter changes on, for example, various filters that can be used in digital logic design, which the Examiner equates to circuit design.”

I initially did not agree with the Board’s decision, because as a former software developer, I know there is a significant difference between a circuit design software package and a tutorial for students. But I continued reading the Board’s decision and they convinced me when they construed the claim language at issue:

The Board wrote:

“Appellant’s Specification does not expressly define a software-based development environment for designing circuits or systems; nor does Appellant’s Specification otherwise narrow the definition of a software based development environment for designing circuits or systems to exclude interactive software tutorials on digital analysis for digital logic design.”

The Appellant tried to argue that the claimed “software-based development environment” meant a lot of things that were not listed in the claims but were described in the specification. The Board responded:

“We decline to read limitations into a claim from preferred embodiments described in the Specification. See In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). Accordingly, a software-based development environment for designing circuits or systems does not necessarily exclude interactive tutorial software on digital analysis for digital logic design.”

And that is how it came to pass that the central issue in this case became one of claim construction. This is in keeping with fellow blogger Karen Hazzah’s assertion that in the end, it’s usually about claim construction.

What does this mean for practitioners? This decision means that if you’re going to argue that your claim includes certain limitations, then you better make sure those limitations are embedded in the claims, especially when procuring software patents. Ideally, the limitations you argue should be explicitly spelled out in the claim language. And if not explicitly in the claim language, then the limitations should be explicitly spelled out in the specification in way that is directly tied to claim language. For example, if your claim term is a “signal processing module” and the specification states “the term signal processing module specifically refers to a digital signal processing unit.” The Board prefers clear and concise claim language and is reluctant to read implicit limitations into your claim. Therefore, when you identify a winning argument on Appeal, make sure your claim explicitly states the limitations you are arguing.