`
`
`
`Paper 64
`Entered: May 19, 2017
`
`
`
`Trials@uspto.gov
`Tel: 571-272-7822
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`PALO ALTO NETWORKS, INC.,
`Petitioner,
`
`v.
`
`FINJAN, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-019791
`Patent 8,141,154 B2
`____________
`
`
`
`Before THOMAS L. GIANNETTI, RICHARD E. RICE, and
`MIRIAM L. QUINN, Administrative Patent Judges.
`
`
`
`QUINN, Administrative Patent Judge.
`
`
`
`DECISION
`ON PETITIONER’S REQUEST FOR REHEARING
`37 C.F.R. § 42.71(d)
`
`
`1 Case IPR2016-00919 has been joined with this proceeding.
`
`
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`
`On March 15, 2017, the Board issued the Final Written Decision in
`this proceeding. Paper 62 (“Final Dec.”). On April 14, 2017, Palo Alto
`Networks, Inc. (“Petitioner”) filed a Request for Rehearing. Paper 63 (Req.
`Reh’g.). Petitioner’s Request focuses on our findings concerning the claim
`limitation “a content processor . . . for invoking a second function with the
`input, only if a security computer indicates that such invocation is safe”
`(claim 1) and “invoke the second function with the input only if the indicator
`indicates that such invocation is safe” (claim 4). Id.; (hereinafter “second
`function” limitation). Petitioner’s Request also addresses an asserted
`inconsistency in claim construction of the term “a call to a first function”
`with regard to another proceeding dealing with the patent-at-issue. Id. at
`13−14 (referring to the Final Written Decision in IPR2016-001512). We
`address each of the raised issues in turn.
`INVOCATION OF THE SECOND FUNCTION LIMITATION
`A.
`Petitioner argues that the Board misapprehended the plain meaning of
`the claim when finding that Khazan does not teach the second function
`limitation. Req. Reh’g 2−3. In particular, the issue is whether our findings
`regarding Khazan adequately considered that the claim requires invoking the
`second function with the input, only if the invocation is safe. Id. 3−12. We
`are not persuaded by Petitioner’s argument that we misapprehended the
`claim language in our findings of fact regarding this limitation.
`In the Final Written Decision we made several findings of fact
`relevant to this issue, the most relevant being that,
`
`
`2 Palo Alto Networks, Inc., v. Finjan, Inc., IPR2016-00151, Paper 51 (PTAB
`Mar. 15, 2017).
`
`2
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`
`1) Khazan teaches or suggests that the call to the target function
`includes inputs in order to pass the parameters to the wrapper
`function (second function). Final Dec. 47−48.
`2) Khazan discloses that in order for the wrapper function to be
`executed, the target function must be invoked first. Id. at 52.
`3) When Khazan describes intercepting the target function, it
`refers to invoking the target function first, in order for the code
`inserted in the instrumented content to transfer control to the
`wrapper function. Id. at 52.
`4) Although we agree with Petitioner that the target function is
`verified during pre-monitoring and execution is suspended, the
`verification only occurs after invocation of the target function.
`Id. at 53.
`5) Petitioner has failed to point out any teaching in Khazan where
`the target function is not invoked first. Id.
`6) The Petition only maps Khazan to the second function
`limitation. Id.
`Petitioner’s first argument, provided at pages 15−16 of the Petition,
`relies on an overview of Khazan to assert that certain passages of paragraphs
`84, 85, and 88 teach the second function limitation. Req. Reh’g 5−7. We
`are not persuaded by this first argument that rehearing should be granted,
`because the argument was not presented in the Petition or the Reply. These
`passages of Khazan are explained for the first time on rehearing to assert a
`point that was not made in the Petition: that the target function is invoked
`“with the input,” only after Khazan’s pre-monitoring verification is
`successful. Pages 15 and 16 of the Petition provide a summary or overview
`
`3
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`of Khazan that is devoid of any explanation as to how the disclosures of
`Khazan there summarized teach or suggest any of the limitations of the
`challenged claims. We could not have misapprehended the cited content of
`Khazan that was not particularly tied to any claim limitation, as our rules
`require that the Petition “must specify where each element of the claim is
`found in the prior art patents or printed publications relied upon.” 37 C.F.R.
`§ 42.104(b)(4).3 It would be patently unfair to Patent Owner if we were to
`consider new citations to Khazan and arguments regarding those citations,
`addressing this claim element, when those arguments were not presented
`properly by Petitioner.
`To be sure, the Petition addresses the second function limitation at
`pages 29−30 (addressing limitation “1[f]”: “and (ii) for invoking a second
`function with the input” (emphasis added)). Pet. 29−30; see Final Dec. 49
`(noting that Petitioner’s arguments concerning the limitation are in pages
`29−30 of the Petition). The Petition there points to paragraph 85, where
`Khazan describes “‘execution of the intercepted’ function if the pre-
`monitoring code verifies the intercepted function.” Id. at 29. That
`paragraph is reproduced below:
`
`
`3 Petitioner also raises for the fist time an argument that Dr. Rubin’s
`annotated Figure 7 supports its argument, but that annotated Figure 7 was
`not submitted either in the Petition or Reply as supporting the second
`function limitation, and does not explain in any detail how the input is not
`included in the intercepted target function. Req. Reh’g 7. Indeed, we find
`the argument presented on rehearing entirely inconsistent with the position
`that Dr. Rubin takes regarding the “call including an input” for which he
`opined that parameters would be passed from the wrapped function to the
`wrapper function in order to verify the parameter information. See Final
`Dec. 47 (crediting Dr. Rubin’s testimony on this point, Ex. 1002 ¶¶ 100−02).
`
`4
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`
`The verification process of the pre-monitoring code may
`include examining the list of target and invocation
`locations 106 previously obtained during static analysis to
`verify that this call instance has been identified in the pre-
`processing step described elsewhere herein. In the event
`that the call is verified as being on the list 106, execution
`of the intercepted routine may proceed. Otherwise, the
`verified call processing code portion of the pre-monitoring
`portion may determine that this is an MC segment and may
`perform MC processing without executing the routine
`called.
`
`
`Ex. 1003 ¶ 85. This paragraph does not support Petitioner’s argument that
`the target function is not invoked with the input when it is intercepted. See
`Req. Reh’g 6 (“the system may perform malicious code processing without
`executing the routine called”); 8 (characterizing paragraph 85 as a “crucial
`disclosure”). To the contrary, we note that this paragraph is consistent with
`our findings in the Final Written Decision, at pages 49−53, that Khazan’s
`pre-monitoring code verifies the list of target functions and invocation
`locations after the target routine is intercepted, i.e., after the target routine
`(the alleged second function) is intercepted, which means that the target
`routine has been invoked. And considering our finding that the target
`function includes inputs that are passed to the wrapper function (Final Dec.
`47−48), the target routine is invoked “with the input” when it is intercepted.
`We agree that paragraph 85 states that the routine called may not
`
`executed if the pre-monitoring code finds malicious code. However, that
`passage cannot be read in isolation from the rest of Khazan, which describes
`that the target routine was already invoked, and that it continues operation of
`the invoked target routine, including its parameters, if no malicious code is
`found. See Final Dec. 52; see also Ex. 1003 ¶ 88 (“After post-monitoring
`
`5
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`code, the control transfers back 212 to the source function, to the location
`that follows LOC_A from which function API_A was invoked.” (emphasis
`added)); ¶ 94 (describing a call to a target routine is intercepted, current call
`is verified, if verification successful, “continue execution” of the target
`routine, if not successful, determination is made that malicious code has
`been detected and related processing may be performed); ¶ 96 (additional
`processing may include obtaining call-related information such as parameter
`information). In other words, we do not agree with Petitioner’s
`characterization of paragraph 85. The Reply arguments (allegedly
`addressing paragraph 88) were also considered and found unpersuasive for
`the same reasons. Id. at 52−53.
`
`Petitioner further argues that the “earliest possible point at which the
`input to the second/target function could be invoked—are executed as part of
`the trampoline function after verification occurs.” Req. Reh’g 7. This
`argument was considered and found unpersuasive. Final. Dec. 52. We
`stated in our Final Written Decision that the explanation provided was
`“insufficient to rebut Patent Owner’s argument and contrary to the facts of
`Khazan.” Id. Further, to the extent Petitioner attempts to make a distinction
`that the “input” is “invoked” only after verification, that argument is not
`only new argument, but is also unpersuasive because the claims do not
`require the “input” to be invoked. The claims require invoking the second
`function with the input.
`
`Finally, we address Petitioner’s argument that we misapprehended
`Khazan’s disclosures relied on for our determination that Khazan does not
`teach the second function limitation. Req. Reh’g 10−13. Petitioner argues
`that our application of the claims to the disclosure of Khazan “reads out” the
`
`6
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`requirement of invoking the second function “with the input.” Id. at 10−11.
`And Petitioner argues that our interpretation of Khazan is erroneous. Id. at
`11−12. We are not persuaded by either argument. First, we credited Dr.
`Rubin’s testimony that parameters (inputs) in Khazan are passed from the
`wrapped function (target or second function) to the wrapper function (first
`function) in order for Khazan to verify parameter information. See Final
`Dec. 47−48 (crediting Dr. Rubin’s testimony on this point, Ex. 1002 ¶¶
`100−02). The input that is passed is the same input that is verified. See Ex.
`1002, 56 (“Khazan also discusses ‘[v]erifying the parameter information’ of
`the wrapped function”).4 Petitioner has never explained in any detail its
`theory that Khazan passes the inputs such that when the target function is
`intercepted during runtime, the invocation of that target function does not
`include any of the inputs or parameters to be verified. Indeed such a theory
`would be unpersuasive because Khazan instruments the application or
`library to modify the code of the function that is being verified. See Final
`Dec. 52−53 (citing Ex. 1003 ¶¶ 82, 90, 92, 93 94); see also Reply 14 (“The
`call 202 included in the jump command 204 includes the same parameters as
`the original call.”). But there is no evidence that Khazan modifies the call to
`the target function such that the original inputs would be removed, changed,
`or otherwise not included in the call to the target function that is invoked
`before interception occurs.
`
`Furthermore, we note that Khazan’s description of dynamic analysis
`during application execution is consistent with our findings that Khazan
`
`
`4 Citation to this portion of the Rubin Declaration refers to the page number
`because the cited page omits paragraph numbers.
`
`7
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`invokes the target function in the application in order for the wrapper
`function to be executed. See Req. Reh’g 12 (arguing that paragraph 94 does
`not refer to the target routine because it refers to the application execution).
`Putting it plainly, the call to the target routine is a program statement or
`instruction in the original (and unaltered) application. Final Dec. 51 (citing
`Ex. 1003 ¶ 83). When the application is executed, the call to the target
`routine is processed (for example, a particular library file is loaded), causing
`a wrapper function which was inserted in the body of the application or
`library file to be executed before the rest of the program code for the target
`routine is processed. Id. at 51−52 (citing Ex. 1003 ¶ 83). The call to the
`target routine, again, must be processed first, i.e., the target routine will be
`invoked. Id. at 52. And to the extent it needs to be said, though it is implied
`in our Final Written Decision, when the application is executed, the call to
`the target routine would include the inputs to that target routine, inputs
`which have been or are passed to the verification code. See Ex. 1002
`¶¶ 101−02 (stating, for example, that “for proper interception the prototype,
`target, trampoline, and detour functions must all have the same call signature
`including number of arguments and calling conventions”); Final Dec. 46−48
`(addressing Petitioner’s argument, and finding persuasive evidence, that
`parameters are passed from the original function to the wrapper function,
`citing Ex. 1012 at 5 and opinion of Dr. Rubin that “identical parameters” are
`passed from the calling code to the detoured function and then to the original
`target function).
`
`In sum, we are not persuaded that Petitioner’s arguments show an
`abuse of discretion in deciding the issue presented. Rather, we view
`Petitioner’s arguments as expressing a disagreement with our findings
`
`8
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`concerning Khazan’s disclosure. In our Final Written Decision we stated the
`reasons why we disagree with Petitioner’s view of Khazan, and are not
`persuaded by Petitioner’s rehearing request that the passages cited and
`explained during rehearing should alter our findings that Khazan does not
`teach invoking the second function with the input, only if that input is
`deemed safe. We reiterate our conclusion that Khazan invokes the target
`function, with its parameters as stated above, before any pre-monitoring
`code verifies those parameters. Final Dec. 49−53. Therefore, Khazan does
`not teach invoking the second function with the input, only if such
`invocation is deemed safe.
`CLAIM CONSTRUCTION ISSUE
`B.
`Petitioner argues that claim construction for the term “call to a first
`function” should be consistent across proceedings addressing the patent-at-
`issue. Req. Reh’g 13−14. We agree with Petitioner’s contention that the
`claim construction should be consistent. Petitioner, however, does not allege
`that the construction we have given the term in this proceeding should be
`altered or modified in any way. Accordingly, we have not been directed to
`any particular issue that we misapprehended or overlooked in this
`proceeding concerning the claim construction of a “call to a first function.”
`
`
`ORDER
`For the reasons stated above, Petitioner’s Request for Rehearing is
`denied because Petitioner failed to meet its burden of showing that the Final
`Written Decision should be modified as requested. 37 C.F.R. § 42.71(d).
`
`9
`
`
`
`
`
`IPR2015-01979
`Patent 8,141,154 B2
`
`
`PETITIONER:
`Orion Armon (Lead Counsel)
`Christopher Max Colice (Back-up Counsel)
`Jennifer Volk (Back-up Counsel)
`Brian Eutermoser (Back-up Counsel)
`oarmon@cooley.com
`mcolice@cooley.com
`jvolkfortier@cooley.com
`beutermoser@cooley.com
`
`Nathaniel A. Hamstra (Back-up Counsel)
`nathanhamstra@quinnemanuel.com
`
`PATENT OWNER:
`
`James Hannah (Lead Counsel)
`Jeffrey H. Price (Back-up Counsel)
`Michael Kim (Back-up Counsel)
`jhannah@kramerlevin.com
`jprice@kramerlevin.com
`mkim@finjan.com
`
`
`
`10
`
`