`
`
`
`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
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
