Ex Parte McLachlan et al

Patent Trial and Appeal Board

Mar 14, 2017

13893463 (P.T.A.B. Mar. 14, 2017)

United States Patent and Trademark Office
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
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
04860.P19370 8139
EXAMINER
NAGHDALI, KHALIL
ART UNIT PAPER NUMBER
2438
MAIL DATE DELIVERY MODE
13/893,463 05/14/2013 Jon McLachlan
03/15/201745217 7590
APPLE INC./BSTZ
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE, CA 94085-4040
03/15/2017 PAPER
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.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte JON MCLACHLAN, JULIEN LEROUGE, DANIEL F.
REYNAUD AND ERIC D. LASPE
Appeal 2016-004695
Application 13/893,463
Technology Center 2400
Before CAROLYN D. THOMAS, JEFFREY S. SMITH, and
TERRENCE W. McMILLIN, Administrative Patent Judges.
THOMAS, Administrative Patent Judge.
DECISION ON APPEAL
Appellants seek our review under 35 U.S.C. § 134(a) from the
Examiner Finally Rejecting claims 1—25, all the claims pending in the
application. We have jurisdiction over the appeal under 35 U.S.C. § 6(b).
We REVERSE.
Appeal 2016-004695
Application 13/893,463
The present invention relates generally to “detecting unauthorized
calls to software routines,” and more specifically to “detecting direct calls
into a function without calling the instructions that should be executed
beforehand in a specific order” (Spec. 11).
Claims 1 and 14 are illustrative:
1. A computer implemented method comprising:
identifying a set of function execution paths through a
program to a protected function;
generating a polynomial based at least in part on the set
of function execution paths; and
embedding, via a processor, instructions throughout the
program that allow proper execution of the protected function upon
determining that a runtime call order to the protected function matches
at least one of the set of function execution paths, the matching
determined by evaluating the polynomial using a runtime generated
secret corresponding to the runtime call order.
14. A computer implemented method comprising:
executing, via a processor, a sequence of functions on a
path, wherein each function in the sequence of functions pushes a
secret onto a runtime stack;
calling a protected function, wherein the protected
function executes properly when a runtime call order of the sequence
of functions matches at least one authorized path;
tracing up the runtime stack to identify a set of secrets
comprising each of the secrets pushed onto the runtime stack by each
function in the sequence of functions;
combining the set of secrets to generate a representation
of the path to the protected function; and
verifying the representation of the path to the protected
function matches the at least one authorized path.
2
Appeal 2016-004695
Application 13/893,463
Appellants appeal the following rejections:
Rl. Claims 1—25 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Haga et al. (US 8,307,354 B2, Nov. 6, 2012), Johnson et
al. (US 8,752,032 B2, June 10, 2014), and Sato et al. (US 8,312,297 B2,
Nov. 13, 2012).
ANALYSIS
Claims 1—13
We have reviewed Appellants’ arguments in the Briefs, the
Examiner’s rejections, and the Examiner’s response to Appellants’
arguments. We concur with Appellants’ conclusion that the Examiner erred
in finding that the combination of Haga, Johnson, and Sato teaches or
suggests the claimed “generating a polynomial based at least in part on the
set of function execution paths,” (see claim 1, emphasis added).
Here, the Examiner finds that Haga teaches identifiers uniquely
identifying functions, and Johnson teaches employing polynomials to access
identities (see Final Act. 6—7; see also Ans. 2-4).
As identified by Appellants, the claimed invention requires that the
polynomial is generated “based on ‘the set of function execution paths [to a
protected function]’” (App. Br. 9). Appellants’ Specification details an
exemplary embodiment describing identifying “the possible execution paths
to a protected function” (Spec. 126), and generating “a representation of an
authorized path to the protected function” (Spec. 129), and that “[o]nce the
CPE has generated a representation for each authorized path on the whitelist,
the CPE can construct a polynomial that represents the whitelist for the
protected function” (Spec. 130). We find that the claimed “generating a
3
Appeal 2016-004695
Application 13/893,463
polynomial based at least in part on the set of function execution paths” after
“identifying a set of function execution paths through a program to a
protected function,” in light of Appellants’ Specification, requires that the
polynomial is generated using or from the set of function execution paths to
a protected function. Here, we agree with Appellants that “the polynomial
in Johnson is created based on values computed in a single basic block” and
“is not based on ‘the set of function execution paths’” (App. Br. 9). We find
that, although Johnson provides obfuscation through polynomials (see
Johnson col. 52,11. 10—14), it requires merely polynomial creation using
values (see Johnson col. 55,11. 15—20) as opposed to polynomial creation
using an identified set of function execution paths through a program to a
protected function.
Thus, we disagree with the Examiner’s finding that Johnson’s
polynomial creation reads on the claimed “generating a polynomial based at
least in part on the set of function execution paths,” as recited in
independent claim 1 with commensurate limitations in independent claim 8.
Because we agree with at least one of the arguments advanced by
Appellants, we need not reach the merits of Appellants’ other arguments.
Accordingly, we will not sustain the Examiner’s § 103(a) rejection of
claims 1—13.
Claims 14—25
We further concur with Appellants’ conclusion that the Examiner
erred in finding that the combination of Haga, Johnson, and Sato teaches or
suggests the claimed “executing, via a processor, a sequence of functions on
a path, wherein each function in the sequence of functions pushes a secret
4
Appeal 2016-004695
Application 13/893,463
onto a runtime stack... tracing up the runtime stack to identify a set of
secrets comprising each of the secrets pushed onto the runtime stack by each
function in the sequence offunctions', combining the set of secrets to
generate a representation of the path to the protected function” (see claim 14,
emphasis added).
Here, the Examiner finds that Haga generates “a random number (a
secret) and write the random number [sic] into the execution path (pushes a
secret onto a stack)” (Ans. 6); Johnson “introduces pointers and values and
stores the link data structure (tracing up) in an encoded array (sequence,
series)” (Ans. 8) and “checksum of arrays (series or sequences of functions)
which this is not a regular checksum, it is a combined checksum which this
value represent the array (sequence of series of functions)” (Ans. 9); and
Sato “teaches runtime for each path calculated and a secret value is
generated” (Ans. 9).
As identified by Appellants, the claimed invention requires “tracing
up the runtime stack to identify a set of secrets comprising each of the
secrets pushed onto the runtime stack by each function in the sequence of
functions” and “combining the set of secrets to generate a representation of
the path to the protected function” (see App. Br. 14—15). Appellants’
Specification details an exemplary embodiment describing “[w]hen a CPE
protected program executes an authorized path function, the function can
push a secret value on the runtime stack” and “[a]fter calling the protected
function, the CPE protected program can trace up the runtime stack to
identify any secret values pushed on the stack by previous functions,” and
“[t]he CPE protected program can combine any identified secret values to
generate a representation of the runtime execution path to the protected
5
Appeal 2016-004695
Application 13/893,463
function” (Spec. ]Hf 58—59). We find that the claimed “tracing up the
runtime stack to identify a set of secrets comprising each of the secrets
pushed onto the runtime stack by each function in the sequence of functions”
and “combining the set of secrets to generate a representation of the path to
the protected function,” in light of Appellants’ Specification, requires that
tracing up the runtime stack is for the purpose of identifying a set of secret
values from the secret values pushed onto the runtime stack by functions and
then combining the identified set of secret values to create a representation
of the path to the protected function. Here, we agree with Appellants that
Johnson’s “protecting pointers by encoding them in the linked data
structures” for the purpose of “protecting software from hackers” does not
teach the claimed “tracing up the runtime stack to identify a set of secrets
comprising each of the secrets pushed onto the runtime stack,” and
Johnson’s checksum computation is not relevant to the claimed “combining
the set of secrets [pushed onto the runtime stack by a sequence of functions]
to generate a representation of the path to the protected function” (App. Br.
14—15). We find that, although Johnson provides for obfuscation and
prevention of software tampering, Johnson merely provides protecting
pointers by using values in an encoded data structure (see Johnson col. 73,11.
11—21) and code checksumming (see Johnson col. 69,11. 27—30, 34-46) as
opposed to identifying a set of secrets pushed onto the runtime stack and
combining those secrets to create path representation.
Thus, we disagree with the Examiner’s finding that Johnson’s pointer
protection and checksumming reads on the claimed “tracing up the runtime
stack to identify a set of secrets comprising each of the secrets pushed onto
the runtime stack by each function in the sequence offunctions', combining
6
Appeal 2016-004695
Application 13/893,463
the set of secrets to generate a representation of the path to the protected
function,” as recited in independent claim 14 with commensurate limitations
in independent claim 19. Because we agree with at least one of the
arguments advanced by Appellants, we need not reach the merits of
Appellants’ other arguments.
Accordingly, we will not sustain the Examiner’s § 103(a) rejection of
claims 14—25.
DECISION
The decision of the Examiner to reject claims 1—25 is reversed.
REVERSED
7