Ex Parte Pardoe et alDownload PDFPatent Trial and Appeal BoardApr 20, 201812421649 (P.T.A.B. Apr. 20, 2018) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE 12/421,649 04/10/2009 69316 7590 04/24/2018 MICROSOFT CORPORATION ONE MICROSOFT WAY REDMOND, WA 98052 FIRST NAMED INVENTOR Andrew J. Pardoe UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www .uspto.gov ATTORNEY DOCKET NO. CONFIRMATION NO. 326614.01 4882 EXAMINER GIROUX, GEORGE ART UNIT PAPER NUMBER 2182 NOTIFICATION DATE DELIVERY MODE 04/24/2018 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): usdocket@microsoft.com chriochs@microsoft.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte ANDREW J. PARDOE, MICHAEL M. MAGRUDER, KUMAR GAURA V KHANNA, DIANA MILIRUD, and GA YE ONCUL KOK Appeal2017-010381 Application 12/421,649 1 Technology Center 2100 Before DEBRA K. STEPHENS, DANIEL J. GALLIGAN, and DAVID J. CUTITTA II, Administrative Patent Judges. CUTITTA II, Administrative Patent Judge. DECISION ON APPEAL Appellants appeal under 35 U.S.C. § 134(a) from a final rejection of claims 1-20, which are all of the claims pending in the application. We have jurisdiction under 35 U.S.C. § 6(b ). We AFFIRM. 1 Appellants identify Microsoft Technology Licensing, LLC as the real party in interest. See App. Br. 1. Appeal2017-010381 Application 12/421,649 STATEMENT OF THE CASE According to Appellants, the claims are directed to classifying and handling corrupt application state exceptions. Spec. ,r 19, Abstract. Claim 1, reproduced below, is illustrative of the claimed subject matter: 1. A computer-implemented method for handling software and hardware exceptions, the method comprising: executing a software application; detecting an exception that indicates an error encountered by the software application; determining that the detected exception is one of a predefined class of exceptions, predefined by a developer of the software application, that indicates a corrupt or potentially corrupt application state; identifying a first exception handler of an ordered set of exception handlers on a program call stack within the software application, the identified first exception handler being closest to the detected exception on the program call stack; determining that the first exception handler does not have an attribute associated therewith that indicates a corrupted exception handler; determining that the identified first exception handler cannot successfully recover from the detected exception based on the determination that the first exception handler does not have the attribute associated therewith; identifying a second exception handler of the ordered set within the software application; determining that the second exception handler has the attribute associated therewith; and invoking the second exception handler and delivering the detected exception that indicates the corrupt or potentially corrupt application state to the second exception handler for recovery from the exception, the preceding steps being performed by at least one processor. 2 Appeal2017-010381 Application 12/421,649 REFERENCES AND REJECTIONS Claims 1-3, 5, and 9-19 stand rejected under 35 U.S.C. § I03(a) as being unpatentable over Selitrennikoff (US 2006/0101411 Al; published May 11, 2006) and Conti (US 2007 /0226795 Al; published Sept. 27, 2007). Final Act. 2-16. Claims 4 and 8 stand rejected under 35 U.S.C. § I03(a) as being unpatentable over Selitrennikoff, Conti, and Fruja (Nicu G. Fruja and Egon Borger, Modeling the .NET CLR Exception Handling Mechanism for a Mathematical Analysis, 5 Journal of Object Technology 5 (April 2006)). Id. at 17-20. Claim 6 stands rejected under 35 U.S.C. § I03(a) as being unpatentable over Selitrennikoff, Conti, and Vo (Kiem-Phong Vo and Yi- Min Wang, Xept: A Software Instrumentation Method for Exception Handling, 60 (IEEE 1997)). Id. at 20-21. Claim 7 stands rejected under 35 U.S.C. § I03(a) as being unpatentable over Selitrennikoff, Conti, and England (US 6,775,779 Bl; issued Aug. 10, 2004). Id. at 22-23. Claim 20 stands rejected under 35 U.S.C. § I03(a) as being unpatentable over Selitrennikoff, Conti, and Neiger (US 2006/0005084 Al; Jan. 5, 2006). Id. at 23-24. Our review in this appeal is limited only to the above rejections and the issues raised by Appellants. Arguments not made are waived. See MPEP § 1205.02; 37 C.F.R. §§ 4I.37(c)(l)(iv) and 4I.39(a)(l). 3 Appeal2017-010381 Application 12/421,649 ANALYSIS Appellants contend the Examiner erred in finding the combination of Selitrennikoff and Conti teaches "determining that the detected exception is one of a predefined class of exceptions, predefined by a developer of the software application," as recited in claim 1 and similarly recited in claims 10 and 18. App. Br. 10-18; Reply Br. 3-8. Specifically, Appellants argue "Conti only discloses types of security attacks and violations," but the "types of security attacks disclosed in Conti are, by definition, very different from exceptions, and that the use in Conti of exception handlers to thwart unwanted accesses due to the attacks does not mean that the attacks are themselves exceptions." App. Br. 11; Reply Br. 4. Appellants further argue "the types of security violations disclosed in Conti are not predefined by a developer of the software application" because the "security measures disclosed in Conti are not aware of how malicious attacks will occur, nor is it possible to know how malicious code will be written," i.e., the "attacks disclosed in Conti that result in security violations are intentional attempts to breach device security by an outside entity, not issues with the code of an application." App. Br. 16; Reply Br. 7. Additionally, Appellants argue "Selitrennikoff discloses either well-known, standard exceptions, or undefined exceptions, but not a predefined class of exceptions, predefined by a developer of the software application." App. Br. 13-14; Reply Br. 6. We are not persuaded. The Examiner finds (Ans. 5), and we agree, Conti' s security violations teach "exceptions" that "are grouped by severity level with appropriate security neutralization strike-back responses" (Conti ,r 441 ). The Examiner further finds (Final Act. 5---6), and we agree, Conti teaches "a particular type of Security Violation ... [that] would cause 4 Appeal2017-010381 Application 12/421,649 damage to memory contents or corrupt the MPU processor state" is handled "by activating an appropriate exception handler," e.g., an "External Data/Prefetch Abort generation" (Conti ,r 439). Appellants' arguments (App. Br. 11; Reply Br. 4), alleging that Conti distinguishes between security violations and exceptions, are not persuasive because Conti's security violations are exceptions within the meaning of the term as described by the Specification. During examination, "claims ... are to be given their broadest reasonable interpretation consistent with the specification." In re Bond, 910 F.2d 831, 833 (Fed.Cir.1990). The Specification discloses that an "exception is the signal raised when a condition is detected that was not expected in the normal execution of a program thread." Spec. ,r 2. Conti teaches "violation signals are generated" for conditions not expected in normal program execution such as "Instruction Read Channel Violations ... when the [ microprocessor unit (MPU)] 2610 tries to execute in non-allowed memory," "Data Read Channel Violations ... when the MPU 2610 tries to perform a Read Data transfer in non-allowed memory," "Data Write Channel Violations ... when the MPU 2610 performs a Write Data transfer in non-allowed memory," and "Data Write Channel Violations ... [when] MPU 2610 performs a Write Data transfer in non-allowed memory." Conti ,r,r 441--446. Accordingly, each of Conti's security violations describes a detected condition that is not expected in the normal execution of the program thread, and thus, teaches an "exception" as recited in the claim. Further, Appellants' arguments that Conti does not predefine classes of exceptions by a developer of the software application are also not persuasive. The claims recite "a predefined class of exceptions," which is 5 Appeal2017-010381 Application 12/421,649 "predefined by a developer of the software application," but do not otherwise require any particular method for predefining exception classes. In particular, the claims do not recite, and therefore do not require, predefining exception classes using any particular knowledge of malicious code or otherwise, e.g., "malicious third-party code" (Reply Br. 5, 7), "code of an application," or "know[ing] how malicious code will be written" (App. Br. 16-17). Further, the Specification does not define, let alone use, the term "predefined" when discussing classes of exceptions. As such, the only requirement for predefining exception classes is that the developer of the software application defines the exception classes. Turning again to Conti, as discussed supra, Conti teaches predefined groups, i.e., classes of different security violation types for classifying the security violation and respectively responding to the security violation based on that classification. Conti ,r,r 441--446; see Conti ,r 439 ("particular type[ s] of Security Violation[s]"). And because Conti's system functions by way of coded software and defines its security violation types in code, those predefined security violation classifications are predefined by Conti' s software developer, and thus, Conti teaches "predefined class of exceptions, predefined by a developer of the software applications," as recited in the claim. See Conti ,r 98 ("The Monitor mode operates as software"), Tables 27-28. Furthermore, Appellants' arguments that Conti only flags invalid exceptions and that invalid exceptions are not a predefined classes of exceptions because those exceptions are not "known" (App. Br. 17-18 (citing Conti Table 33); Reply Br. 7-8) are not persuasive. As an initial matter, Appellants' discussion of the invalid exceptions in Table 33 of Conti 6 Appeal2017-010381 Application 12/421,649 does not address the Examiner's finding that Conti's security violations teach exceptions grouped into predefined exception classes, discussed supra. In any event, contrary to Appellants' argument that only invalid exceptions are flagged, Conti teaches "exceptions occurring in Monitor Mode are validity-checked in firewall 4830 to determine that they are expected exceptions" (Conti ,r 507); i.e., Conti's exceptions include valid, expected exceptions. Moreover, an "invalid exception" is itself a predefined class of exception-the claims do not preclude invalid exceptions, i.e., exceptions that are not "known," from predefined exception classes. Indeed, Appellants' Specification teaches such a catch-all exception, "Exception e" which "could be catching anything ... the program or process is in an unknown state." Spec. ,r 36 (emphasis added). Accordingly, Conti's security violation classifications, defined by the type of action attempted, teaches "a predefined class of exceptions, predefined by a developer of the software application," within the meaning of the claims. Additionally, Appellants' argument that Selitrennikoff does not teach "a predefined class of exceptions, predefined by a developer of the software application" (App. Br. 13-14; Reply Br. 7) does not address the Examiner's finding that Conti teaches the disputed limitation, as discussed supra. Appellants further contend the Examiner improperly combined Selitrennikoff and Conti. App. Br. 18-19; Reply Br. 8. Specifically, Appellants argue the Examiner's combination "is based on impermissible hindsight reconstruction using the Appellants' disclosure as a template" because "the claim[ ed] feature at issue is broken into multiple discrete parts that are rejected by separate, unrelated portions of different cited 7 Appeal2017-010381 Application 12/421,649 references," i.e., "the exception handling of Selitrennikoff and the unrelated security violations of Conti." App. Br. 18-19; Reply Br. 8. We are not persuaded. As discussed supra, Conti' s security violations teach "exceptions" within the scope of the claims. As such, Appellants' argument, which is premised on the argument that Conti' s security violations do not teach exceptions, is not persuasive. Here, the Examiner has articulated reasoning with some rational underpinning why an ordinarily skilled artisan would have combined the teachings of Selitrennikoff and Conti at the time of the invention, namely, "provid[ing] added security to the system and allow[ing] the system to neutralize malicious software and recover." Final Act. 6. See In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006) ("[R]ejections on obviousness grounds [require] some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness") (cited with approval in KSR Int'! Co. v. Teleflex Inc., 550 U.S. 398,418 (2007). Accordingly, we are not persuaded the Examiner improperly combined Selitrennikoff and Conti. Therefore, we sustain the rejection of independent claims 1, 10, and 18 under 35 U.S.C. § 103(a) as being unpatentable over Selitrennikoff and Conti. Dependent claims 2-9, 11-17, 19, and 20 are not separately argued. See App. Br. 19-23. Therefore, we sustain the rejection of claims 2, 3, 5, and 9, 11-17, and 19 under 35 U.S.C. § 103(a) as being unpatentable over Selitrennikoff and Conti, the rejection of claims 4 and 8 under 35 U.S.C. § 103(a) as being unpatentable over Selitrennikoff, Conti, and Fruja, the rejection of claim 6 under 35 U.S.C. § 103(a) as being unpatentable over Selitrennikoff, Conti, and Vo, the rejection of claim 7 under 35 U.S.C. § 103(a) as being unpatentable over 8 Appeal2017-010381 Application 12/421,649 Selitrennikoff, Conti, and England, and the rejection of claim 20 under 35 U.S.C. § 103(a) as being unpatentable over Selitrennikoff, Conti, and Neiger. DECISION For the reasons above, we affirm the Examiner's decision rejecting claims 1-20. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 41.50(±). AFFIRMED 9 Copy with citationCopy as parenthetical citation