Ex Parte Pardoe et al

Patent Trial and Appeal Board

Apr 20, 2018

12421649 (P.T.A.B. Apr. 20, 2018)

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