10232543 (B.P.A.I. Sep. 14, 2011)

Ex Parte Doraisamy

Board of Patent Appeals and InterferencesSep 14, 2011

10232543 (B.P.A.I. Sep. 14, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES ____________ Ex parte RAJA DORAISAMY ____________ Appeal 2009-008708 Application 10/232,543 Technology Center 2100 ____________ Before JOSEPH L. DIXON, JOHN A. JEFFERY, and DEBRA K. STEPHENS, Administrative Patent Judges. Opinion for the Board filed by DIXON, Administrative Patent Judge. Opinion dissenting filed by JEFFERY, Administrative Patent Judge. DIXON, Administrative Patent Judge. DECISION ON APPEAL Appeal 2009 – 008708 Application 10/232,543 2 STATEMENT OF THE CASE The Patent Examiner rejected claims 1-20. The Appellant appeals therefrom under 35 U.S.C. § 134(a). We have jurisdiction under 35 U.S.C. § 6(b). We reverse. A. INVENTION The invention at issue on appeal relates to the field of thin-client computing systems. In an embodiment, a thin-client device having an application program obtains a copy of an application update having a version number via a network. The thin-client device compares the version number to a barrier level value corresponding to a minimum application version necessary to maintain support for a critical feature. In an embodiment, the critical feature is support for an enterprise network. If the version number of the application update is greater than or equal to the barrier level value, the thin-client device updates its application program. (Spec. 6, ll. 10-15). B. ILLUSTRATIVE CLAIM Claim 1, which further illustrates the invention, follows. 1. A method for updating an application program stored in a memory storage device associated with an information processing device, the method comprising the steps of: obtaining a copy of an application update having an update barrier level number and an update version via an information network; Appeal 2009 – 008708 Application 10/232,543 3 comparing the update barrier level number to a barrier level value necessary to maintain support for a critical feature; and updating the application program stored in the memory storage device to the update version if the update barrier level number of the application update is greater than or equal to the barrier level value. C. REFERENCE The Examiner relies on the following reference as evidence: Goodman US 2002/0091807 Al July 11, 2002 D. REJECTIONS Claims 1-4, 6-14, and 16-20 stand rejected under 35 U.S.C 102(a) as being anticipated by Goodman. Claims 5 and 15 stand rejected under 35 U.S.C. 103(a) as being unpatentable over Goodman. PRINCIPLES OF LAW In rejecting claims under 35 U.S.C. §§ 102 and 103, it is incumbent upon the Examiner to establish a factual basis to support the prior art rejection – the so-called “prima facie” case. See In re Piasecki, 745 F.2d 1468, 1472 (Fed. Cir. 1984) (the USPTO has the initial burden of proof “to produce the factual basis for its rejection of an application under sections 102 and 103” (quoting In re Warner, 379 F.2d 1011, 1016 (CCPA 1967))). “[T]he examiner bears the initial burden, on review of the prior art or on any other ground, of presenting a prima facie case of unpatentability.” In re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992). Appeal 2009 – 008708 Application 10/232,543 4 Appellants have the opportunity on appeal to the Board of Patent Appeals and Interferences (BPAI) to demonstrate error in the Examiner’s position. See In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 2006) (citing In re Rouffet, 149 F.3d 1350, 1355 (Fed. Cir. 1998)). ANALYSIS ANTICIPATION The Examiner sets forth a detailed explanation of the anticipation rejection in the Examiner’s Answer with respect to Appellant’s claims so rejected. (Ans. 3-9). The Examiner also sets forth a detailed explanation of the obviousness rejection in the Examiner’s Answer with respect to Appellant’s claims so rejected. (Id. at 10). Therefore, we look to the Appellant’s Brief to show error in the proffered conclusions. See Kahn, 441 F.3d at 985-86. Appellant contends that the Goodman reference does not teach “obtaining a copy of an application update having associated with it an update barrier level number and an update version. Claim 1 further recites comparing the update barrier level number to a barrier level value necessary to maintain support for a critical feature. Claim 1 also recites updating an application program to the update version if the update barrier level number of the application update is greater than or equal to the barrier level value.” (App. Br. 5). Appellant further contends that “Goodman does not teach or suggest a barrier level value or barrier level number that is distinct from an update version, as recited in Claim 1.” (Id.). While the Examiner has clearly set forth the Examiner’s teachings and application of the Goodman reference, the Examiner has not specifically Appeal 2009 – 008708 Application 10/232,543 5 identified “update version,” “barrier level number,” and “barrier level value” with different specific teachings in the Goodman reference. The Examiner identifies that firmware is interpreted as an update version as taught in Goodman, paragraph [0025], lines 5-8. (Ans. 3). Our understanding of the teachings of paragraph [0025] is that the node determines the version number from the code signature and compares this version to the code level indicated in the Location Parameter. Subsequently, the Examiner relies upon the same teachings to correspond to the barrier level number and the barrier level value thereby using the same teaching or multiple claimed features. More specifically, the Examiner identifies the “firmware is interpreted as an update version” (Ans. 3-4), but the firmware is not obtained yet in Goodman only the code signature is received – which indicate the firmware version number. The claim requires “a copy of an application update [obtained] having an update barrier level number and an update version” as disclosed in Appellant’s Specification and the Summary of the Claimed Subject Matter in the Appeal Brief at page 3. Appellant’s Specification states: The thin-client parameters received in step 505 include a firmware update location. The firmware update location indicates a network location containing a firmware update. At step 510, the thin-client device downloads a copy of the firmware update stored at the indicated firmware update location. After downloading a copy of the firmware update, in step 515 the thin-client device checks whether the thin-client parameters received in step 505 include a network barrier level. (Spec. 11). Clearly, in the Examiner’s interpretation relying upon the “firmware” as the claimed “update version,” the Examiner is missing either Appeal 2009 – 008708 Application 10/232,543 6 the application update which has been obtained or the “update version” in the application update. In Goodman, only the code signature is sent, and even if the “firmware” is sent, it does not have both the update barrier level and the update version. Indeed if we use the Examiner’s mapping, the firmware would have to have both the version number of the firmware at the original node (stored in the Location Parameter stored in RAM) and the version number at the “other node.” Hence, we are left to speculate relative to the Examiner’s finding of anticipation. We therefore find the Examiner’s correlation of the teachings of Goodman to fall short of clearly evidencing all the claimed elements of independent claim 1 in the manner recited since the Examiner relies upon the same version number as both the version number and the barrier level number. Additionally, the Examiner does not identify how the code level indicated in the Location Parameter of Goodman describes the claimed “barrier level value necessary to maintain support for a critical feature” (claim 1) (emphasis added). Goodman only discusses the higher code level, but a higher code level may render certain functionality unusable, thus, the comparison to a level necessary to maintain support for a critical feature. Clearly, this is an unreasonable interpretation of the teachings of Goodman, and we cannot sustain the Examiner’s rejection of independent claim 1 based upon anticipation. Independent claim 11 contains similar limitations and therefore we cannot sustain the rejection thereof. Appeal 2009 – 008708 Application 10/232,543 7 OBVIOUSNESS The Examiner’s statement of rejection for dependent claims 5 and 15 does not resolve the above noted deficiency in the anticipation rejection of independent claims 1 and 11. Therefore, we cannot sustain the rejection of these claims. CONCLUSION For the aforementioned reasons, the Examiner has not shown that all the features of independent claims 1 and 11 are taught by the Goodman reference. ORDER We reverse the anticipation rejection of claims 1-4, 6-14, and 16-20 and the obviousness rejections of claims 5 and 15. REVERSED Appeal 2009 – 008708 Application 10/232,543 1 JEFFERY, Administrative Patent Judge, DISSENTING I respectfully dissent from the majority’s reversing the Examiner’s anticipation rejection of claim 1. The majority finds that the Examiner does not identify the recited “update version,” “barrier level number,” and “barrier level value” with different specific teachings in Goodman. Maj. Op. 4-5. The majority also finds the Examiner’s correlating Goodman’s teachings to the claimed invention problematic since the Examiner is said to “rel[y] upon the same version number as both the version number and the barrier level number.” Id. at 6. The Examiner, however, unambiguously maps the key disputed limitations of claim 1 to distinct elements in Goodman as follows: Disputed Limitation in Claim 1 Corresponding Element in Goodman “update barrier level number” code level in code signature “barrier level value” code level in Location Parameter “update version” firmware Ans. 13. The Examiner also unambiguously indicates that, unlike the “update barrier level number” and “barrier level value,” the recited “update version” is not a level of code, but rather is “firmware.” Id. Claim 1 recites, in pertinent part, (1) obtaining a copy of an “application update” having a “update barrier level number” and an “update Appeal 2009 – 008708 Application 10/232,543 2 version” via an information network; (2) comparing the “update barrier level number” to the “barrier level value” necessary to maintain support for a critical feature; and (3) updating a stored application program to the update version if the “update barrier level number” is greater than or equal to the “barrier level value.” I agree with the Examiner that Goodman’s firmware level comparison and firmware update procedure fully meets these disputed limitations. First, both the Location Parameter and the code signature contain a firmware code level (i.e., firmware version). Goodman, ¶¶ 0022-23. These code-level values are compared to determine if the code-level value in a code signature received from another node is greater than the code-level value in the receiving node’s Location Parameter. Id. at ¶ 0025; Fig. 2 (steps 220-30). If so, the receiving node updates its firmware to match that of the transmitting node’s higher-level firmware. Id. at ¶¶ 0025-27; Fig. 2 (steps 230-50, 270- 80). This firmware update detailed in Goodman’s Figure 3 involves (1) receiving a copy of the other node’s higher-level firmware image, and (2) rewriting the receiving node’s memory with the received firmware image. Id. at ¶ 0027; Fig. 3 (steps 310-30). I see no reason why this new higher-level firmware image that replaces the receiving node’s lower-level firmware does not correspond to the recited “update version” which is consistent with the Examiner’s mapping this limitation to “firmware” noted above. That is, the higher-level firmware—not its corresponding code-level value—is the “update version” according to the Examiner’s mapping: a position that I find reasonable on this record. Appeal 2009 – 008708 Application 10/232,543 3 Although claim 1 requires obtaining a copy of an “application update” having an “update barrier level number” and an “update version,” nothing in claim 1 precludes Goodman’s obtaining an “update barrier level number” (code level) first from the received code signature, and later obtaining an “update version” (i.e., receiving higher-level firmware from another node after comparing code levels). In my view, the recited “obtaining a copy of an application update” does not require the “update barrier level number” and “update version” be obtained together or simultaneously as the majority seems to suggest.1 Rather, nothing in the claim precludes obtaining both application update components (i.e., the “update barrier level number” and “update version”) at different times. Nor does the scope of the comparing step (i.e., “to a barrier level value necessary to maintain support for a critical feature”) preclude the “critical” functions that each node shares by virtue of their installed firmware. See Goodman ¶ 0020. Since the claim does not specify which “critical” feature the barrier level value maintains support for, I do not see why these shared functions cannot be deemed “critical features” given the limitation’s scope and breadth. Although Appellant asserts that the Examiner fails to evidence that the code levels in Goodman’s code signature and Location Parameter correspond to the recited “update barrier level number” and “barrier level value,” respectively (Br. 6-7), I find this assertion unpersuasive given the 1 See Maj. Op. 5-6 (finding the Examiner’s interpretation deficient in lacking the obtained application update, or the “‘update version’ in the application update”); see also id. at 6 (“In Goodman, only the code signature is sent, and even if the ‘firmware’ is sent, it does not have both the update barrier level and the update version.”) (emphases added). Appeal 2009 – 008708 Application 10/232,543 4 terms’ broadest reasonable interpretation. While Appellant refers to various passages on pages 11-13 of the Specification in connection with these terms,2 Appellant identifies no concrete definitions of “update barrier level number” and “barrier level value” to confine their interpretation to such definitions. Rather, the cited passages from the Specification in this regard are replete with exemplary terms that hardly limit their interpretation to those embodiments.3 I therefore see no error in the Examiner’s interpreting “update barrier level number” and “barrier level value” to read on the code levels in Goodman’s code signature and Location Parameter, respectively, given the terms’ broadest reasonable interpretation in light of the Specification. Nor does the claim preclude Goodman’s obtaining an “application update” having an “update barrier level number” and “update version” obtained at different times consistent with the Examiner’s mapping. I would therefore affirm. llw 2 See Br. 3 (referring to pages 11 and 12 of the Specification and Figure 5 in the Brief’s Summary of Claimed Subject Matter); see also id. at 5 n.1 (referring to pages 11-13 of the Specification). 3 See, e.g. Spec. 11 (“In an embodiment, the default barrier level value is an integer number corresponding to the minimum firmware version necessary to maintain enterprise network functionality.”); see also id. (“In [an] example, firmware versions are represented by a three digit integer. It should be noted that the default barrier level does not necessarily correspond to the version number of the thin-client device’s current firmware.”) (emphases added).