`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`PALO ALTO NETWORKS, INC.
`Petitioner
`
`v.
`
`FINJAN, INC.
`Patent Owner
`
`
`
`Inter Partes Review No. 2015-019791
`U.S. Patent No. 8,141,154
`
`______________________
`
`PALO ALTO NETWORKS, INC.’S
`REQUEST FOR REHEARING OF FINAL WRITTEN DECISION
`UNDER 37 C.F.R. § 42.71(d)(2)
`
`
`1 Case IPR2016-00919 has been joined with this proceeding.
`
`
`
`
`
`
`
`
`Table of Contents
`
`
`Page
`
`
`I.
`II.
`
`INTRODUCTION .......................................................................................... 1
`LEGAL STANDARD .................................................................................... 4
`A.
`Standard for rehearing .......................................................................... 4
`B.
`Claim construction ............................................................................... 4
`III. ARGUMENT .................................................................................................. 5
`A. Khazan teaches modifying the second/target function so that
`when it is called, control immediately transfers to a
`first/substitute function that prevents execution of any
`instructions in the second/target function until it is checked for
`safety..................................................................................................... 5
`The Petition and Reply argued that Khazan renders obvious the
`“invoking a second function with the input” limitation because
`the second/target function is invoked with the input only if the
`input is safe ........................................................................................... 7
`The Board erred by focusing on when the second/target
`function is “invoked” rather than on when the second/target
`function is “invoked with the input” .................................................. 10
`The evidentiary bases for the Board’s findings are mistaken or
`irrelevant ............................................................................................. 11
`The Board should construe the term “call to a first function” the
`same way in this case and in IPR2016-00151 .................................... 13
`IV. CONCLUSION ............................................................................................. 14
`
`B.
`
`C.
`
`D.
`
`E.
`
`
`
`
`
`-i-
`
`
`
`
`
`
`
`TABLE OF AUTHORITIES
`
`
`
`Page(s)
`
`Cases
`Ethicon Endo-Surgery, Inc. v. U.S. Surgical Corp.,
`93 F.3d 1572 (Fed. Cir. 1996) ........................................................................ 4, 10
`Markman v. Westview Instruments, Inc.,
`517 U.S. 370 (1996) ...................................................................................... 13, 14
`Stevens v. Tamai,
`366 F.3d 1325 (Fed. Cir. 2004) ...................................................................... 4, 10
`
`
`
`
`
`
`
`
`
`
`
`
`
`-ii-
`
`
`
`
`
`
`
`Pursuant to 37 C.F.R. § 42.71(d)(2), Petitioner Palo Alto Networks, Inc.2
`
`moves for rehearing of the Final Written Decision (Paper No. 62) on claims 1-5 of
`
`U.S. Patent No. 8,141,154 (hereafter the “Decision”).
`
`I.
`
`INTRODUCTION
`Rehearing of the Decision on claims 1-53 is warranted because the Board
`
`misapprehended the plain and ordinary meaning of the limitation “invoking a
`
`second function with the input, only if a security computer indicates that such
`
`invocation is safe” (hereafter the “invoking a second function with the input”
`
`limitation).4 The crucial aspect of this limitation that was misapprehended by the
`
`Board is that it refers to invoking the second/target function with the input – i.e.,
`
`both the second/target function and the input must be invoked.
`
`
`2 Petitioner Symantec Corporation in joined Case IPR2016-00919 joins this
`
`Request.
`
`3 Petitioner reserves the right to appeal any and all aspects of the findings of fact
`
`and conclusions of law contained in the Decision, regardless whether they are
`
`addressed in this motion.
`
`4 Claim 4 contains immaterial differences in the wording of the limitation. It states,
`
`“invoke the second function with the input only if the indicator indicates that such
`
`invocation is safe.”
`
`
`
`
`
`-1-
`
`
`
`
`
`
`
`The “with the input” portion of the limitation is important because it realizes
`
`the benefits that are allegedly provided by the ’154 patent. The ‘154 patent is
`
`directed at inspecting dynamically generated function call inputs at runtime to
`
`determine if they contain malicious code. (See generally Paper 2 at 8; Ex. 1001
`
`Title (“System and Method for Inspecting Dynamically Generated Executable
`
`Code”).) As the patent explains, it is only at runtime that dynamically generated
`
`malicious
`
`input
`
`takes
`
`the
`
`determinate
`
`form
`
`<SCRIPT>malicious
`
`JavaScript</SCRIPT> that can be inspected. (Ex. 1001 at Col 4:46-50; Ex. 1002 at
`
`¶¶ 49-51 (describing risks of dynamically generated content).) Because the input is
`
`dynamically generated at runtime and potentially malicious, the claims prohibit
`
`“invoking the second/target function with the input” until a security computer
`
`determines that the input generated at runtime is safe. (Paper 2 at 6-7.)
`
`The Decision is erroneous because it fails to give effect to the clause “with
`
`the input.” The Decision reads-out the clause “with the input” from the claims.
`
`Rather than considering whether the Khazan reference delays invoking the
`
`second/target function with the input until after a security computer determines if
`
`the input is safe, the Decision analyzed whether Khazan “invokes” the
`
`second/target function before the security computer determines it is safe. (Paper 62
`
`at 51 (“the claims require invocation of the second function only if a security
`
`computer or the indicator indicates that the invocation is safe.”); Paper 62 at 52
`
`
`
`
`
`-2-
`
`
`
`
`
`
`
`(“The claims require, however, that the second function be invoked only if it is
`
`safe.”).) The Decision misapprehended the plain meaning of claims 1-5.
`
`As a result of mistakenly reading-out the “with the input” clause in claims 1-
`
`5, the Board mistakenly concluded that Khazan does not render the “invoking a
`
`second function with the input” limitation obvious. The Decision reasoned Khazan
`
`does not satisfy the limitation because Khazan “always invokes the second
`
`function.” (Paper 62 at 51.) But this finding answers the wrong question. The
`
`question is not whether Khazan always invokes the second function; it is whether
`
`Khazan invokes the second/target function with the input only if the security
`
`computer deems the input to be safe.
`
`As explained below, Khazan teaches that no execution of any instruction in
`
`the second/target function occurs until after a security computer determines the
`
`function and its inputs are safe. Khazan’s teaching that no instructions are executed
`
`in the second/target function until verification has occurred conclusively
`
`establishes that Khazan teaches the “invoking a second function with the input”
`
`limitation. The earliest point at which the input to the second/target function could
`
`be invoked is when the first instructions in the second/target function are
`
`executed—and Khazan expressly teaches that the first instructions in the
`
`second/target function are not executed until after verification occurs.
`
`
`
`
`
`-3-
`
`
`
`
`
`
`
`Palo Alto Networks respectfully requests that the Board should find claims
`
`1-5 invalid as obvious because Khazan teaches the “invoking a second function
`
`with the input” limitation in claims 1-5, and that limitation was the only limitation
`
`that the Board found missing in the combined teachings of Khazan and Sirer. Palo
`
`Alto Networks also respectfully requests that the Board should grant rehearing to
`
`harmonize the construction of “call to a first function” by applying the correct
`
`construction entered in this case to its final written decision in IPR2016-00151.
`
`II. LEGAL STANDARD
`Standard for rehearing
`A.
`A request for rehearing “must specifically identify all matters the party
`
`believes the Board misapprehended or overlooked, and the place where each
`
`matter was previously addressed in a motion, an opposition, or reply.” 37 C.F.R.
`
`§ 42.71(d). Clearly erroneous fact findings and erroneous conclusions of law are
`
`abuses of discretion that warrant reconsideration. Stevens v. Tamai, 366 F.3d 1325,
`
`1329 (Fed. Cir. 2004).
`
`B. Claim construction
`Parties and the Board must give meaning to all the words in a patent claim.
`
`Ethicon Endo-Surgery, Inc. v. U.S. Surgical Corp., 93 F.3d 1572, 1582 (Fed. Cir.
`
`1996) (citing Exxon Chemical Patents, Inc. v. Lubrizol Corp., 64 F.3d 1553, 1557
`
`(Fed. Cir. 1995) (“we must give meaning to all the words in the claims.”)).
`
`
`
`
`
`-4-
`
`
`
`
`
`
`
`III. ARGUMENT
`A. Khazan teaches modifying the second/target function so that when
`it is called, control immediately transfers to a first/substitute
`function that prevents execution of any instructions in the
`second/target function until it is checked for safety
`As explained in the Petition, Khazan discloses the same type of dynamic
`
`analysis (i.e., runtime analysis) recited in claims 1-5 of the ‘154 patent. The first
`
`lines of the second/target function are replaced with a call to a substitute function,
`
`and when the second/target function is called at runtime, control immediately
`
`transfers to the substitute function, which checks the target function input for
`
`safety:
`
`Khazan also discloses dynamic analysis (i.e., run-time
`analysis). During execution, when the target function is called,
`the wrapper function (first function) is invoked instead. (Ex.
`1003 at [0088].) The wrapper function performs the pre-
`processing security checks to validate the security of the target
`function and its inputs prior to execution of the target
`function. (Id. at [0071], [0083]-[0085], [0088].) If the
`verification is successful, the target function is executed. (Id.
`at [0059].) Otherwise, the dynamic analyzer returns an error
`code and the application executable may not execute the target
`function. (Id. at [0099].)
`
`(Paper 2 at 15-16 (emphasis added).)
`
`
`
`
`
`-5-
`
`
`
`
`
`
`
`Khazan paragraphs [0084], [0085], and [0088], cited above, explain three
`
`key points about the operation of Khazan’s preferred embodiment:
`
`First, paragraph [0084] explains that “the wrapper or stub function [is]
`
`executed prior to the execution of the body of the intercepted routine or
`
`function.” (Ex. 1003 at 22 ¶ 84 (emphasis added); see also Decision at 41 and 43
`
`(finding that the second/target function is intercepted, and its body is not executed
`
`until after the first/substitute function checks the input parameters for safety).)
`
`Second, paragraph [0085] explains that if it is determined that malicious
`
`code (“MC”) is present, the system may perform malicious code processing
`
`without executing the routine called. (Ex. 1003 at 22 ¶ 85 (“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.”) (emphasis added).)
`
`Third, paragraph [0088] explains that none of the instructions in the
`
`second/target function—including the “first instructions”—are executed until after
`
`the security of function and its inputs are checked:
`
`Prior to writing over the first instruction(s) of the target
`function, the first instruction(s) of the target function are copied
`or preserved in a save area which is included in the trampoline
`function. These first instructions are executed as part of the
`trampoline function after the pre-monitoring code has been
`
`
`
`
`
`-6-
`
`
`
`
`
`
`
`executed and is indicated by the control transfer 206 to the
`trampoline function. Subsequently, control transfers back to
`the target function to continue execution of the target
`function body as indicated by arrow 208.
`
`(Ex. 1003 at 22 ¶ 88 (emphasis added).)
`
`The following figure, annotated by Dr. Rubin, illustrates that the “first
`
`instructions”—i.e., 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:
`
`
`
`(Paper 2 at 24; Ex. 1002 at ¶ 91; Ex. 1003 at FIG. 7 (annotated).)
`
`B.
`
`The Petition and Reply argued that Khazan renders obvious the
`“invoking a second function with the input” limitation because the
`second/target function is invoked with the input only if the input
`is safe
`Consistent with Khazan’s teachings summarized above, the Petition argued
`
`that Khazan teaches the “invoking a second function with the input” limitation
`
`-7-
`
`
`
`
`
`
`
`
`because the intercepted (i.e., the second/target) function is not allowed to execute
`
`until after the pre-monitoring code verifies it is safe:
`
`Khazan discloses element 1[f] in the form of “execution of the
`intercepted” function if the pre-monitoring code verifies the
`intercepted function. (Ex. 1003 at [0085].) As discussed above,
`the intercepted function discussed in Khazan is the wrapped
`function.
`
`(Paper 2 at 29.) Khazan paragraph [0085], cited in the excerpt above, contains the
`
`crucial disclosure explaining that if the call is verified, “execution of the
`
`intercepted routine may proceed,” but that if the pre-monitoring code finds a
`
`malicious code segment, it may “perform MC processing without executing the
`
`routine called.” (Ex. 1003 at 22 ¶ 85.)
`
`The Reply reiterated these arguments, emphasizing that Khazan teaches the
`
`“invoking a second function with the input” limitation because none of the
`
`instructions and none of the body of the second/target function are allowed to
`
`execute until after the pre-monitoring code determines that the input is safe:
`
`invoking the second (original)
`Khazan discloses only
`function if it is safe. (Ex. 1003 at 1, Abstract, at 22 [0088]
`(“after the call has been verified by the pre-monitoring code,
`the trampoline routine corresponding to API_A is invoked as
`indicated by arrow 207.”).) Khazan teaches: “upon detecting
`[malicious code], such as a failed call verification in the pre-
`monitoring and post-monitoring code,” the system “may stop
`-8-
`
`
`
`
`
`
`
`
`
`
`application execution and cause an error message.” (Ex.
`1003 at 24 [0099]) (emphasis added); see also id. at 11 (Fig. 9),
`at 23, [0094], Ex. 1002 at 58-62; Ex. 2005 at 52 (206:14-
`207:11).)
`
`Khazan does not “always invoke[] the ‘second function’” as
`Finjan claims. (Response at 37-38.) By default, Khazan stops
`execution and causes an error message if malicious code is
`detected. (Ex. 1003 at 11, at 23-24, [0094], [0099]; Ex. 1038 at
`11 (38:10-39:5)); see Hewlett–Packard Co. v. Mustek Sys., Inc.,
`340 F.3d 1314, 1326 (Fed. Cir. 2003) (“[A] prior art product
`that sometimes, but not always, embodies a claimed method
`nonetheless teaches that aspect of the invention.”).
`
`(Paper 35 at 15-16 (emphasis added).) The Reply cites and summarizes the portion
`
`of Khazan paragraph [0088] which explains that none of the instructions in the
`
`second/target function are executed until the trampoline function is executed. (Id.)
`
`That disclosure conclusively shows that the input to the second/target function is
`
`not invoked until after a security computer determines it is safe.
`
`Khazan’s teachings in paragraphs [0085] and [0088] each independently
`
`demonstrate that Khazan satisfies the “invoking a second function with the input”
`
`limitation. Paragraph [0085] unequivocally states that detection of a malicious
`
`code segment results in “MC processing without executing the routine called,”—
`
`i.e., without executing any portion of the second/target function. (Ex. 1003 at 22 ¶
`
`
`
`
`
`-9-
`
`
`
`
`
`
`
`85.) And paragraph [0088] explains that not even the “first instructions” in the
`
`second/target function are allowed to execute until after the function is verified.
`
`(Ex. 1003 at 22 ¶ 88.) In light of these teachings, there is no question that the input
`
`to the second/target function is not and could not be invoked until after a security
`
`computer indicates it is safe. Invoking the input requires execution of at least one
`
`instruction, and no instructions in the second/target function are executed until
`
`after verification occurs. (Ex. 1003 at 22 ¶¶ 85, 88.)
`
`C. The Board erred by focusing on when the second/target function
`is “invoked” rather than on when the second/target function is
`“invoked with the input”
`The Decision misapprehended the plain language of claims 1-5 and
`
`misapplied precedent by failing to give meaning to every word in the “invoking a
`
`second function with the input” limitation. Ethicon Endo-Surgery, Inc., 93 F.3d at
`
`1582 (“we must give meaning to all the words in the claims.”).
`
`The Decision erred as a matter of law by reading-out the clause “with the
`
`input” from the “invoking a second function with the input” limitation. This error
`
`resulted in the entry of clearly erroneous findings of fact that mistakenly focused
`
`on when the second/target function is “invoked.” (Paper 62 at 51-52.) Stevens v.
`
`Tamai, 366 F.3d 1325, 1329 (Fed. Cir. 2004) (reconsideration required by
`
`erroneous conclusions of law or clearly erroneous findings of fact).
`
`
`
`
`
`-10-
`
`
`
`
`
`
`
`The errors in the Decision caused the Board to reach the wrong result. As
`
`Khazan explains in paragraphs [0084] and [0088], the body of the second/target
`
`function, including all of its instructions and inputs—even the “first instruction(s)
`
`of the target function”—are not executed until after the first/substitute pre-
`
`monitoring code performs a safety check. (Paper 2 at 15-16, 29; Paper 35 at 15-16;
`
`Ex. 1003 at 22, ¶¶ 84, 85, 88.) Additionally, as Khazan explains in paragraph
`
`[0085], if malicious code is discovered, the pre-monitoring code “may perform MC
`
`processing without executing the routine called”—i.e., if malicious code is present
`
`in the function or its inputs, the second/target function is not executed at all. (Ex.
`
`1003 at 22 ¶ 85; Paper 2 at 29; Paper 35 at 15-16.) These teachings demonstrate
`
`that the input to the second/target function cannot be invoked until after a security
`
`computer indicates that such invocation is safe. Accordingly, Khazan renders
`
`obvious the “invoking a second function with the input” limitation.
`
`D. The evidentiary bases for the Board’s findings are mistaken or
`irrelevant
`The Decision offers two rationales to support the conclusion that Khazan
`
`fails to render obvious the “invoking a second function with the input” limitation.
`
`The first is mistaken and the second is irrelevant.
`
`First, the Decision finds that “Khazan describes the execution of the second
`
`function after the verification check as ‘continuing’ execution.” (Paper 62 at 52
`
`(citing Ex. 1003 Fig. 9 and ¶ 94).) The Decision reasons that if Khazan describes
`
`
`
`
`
`-11-
`
`
`
`
`
`
`
`execution of the second function as “continuing,” Khazan’s system must
`
`impermissibly begin execution of the second/target function prior to the security
`
`computer determining whether the input is safe. (Id.)
`
`The Decision misinterprets Khazan’s disclosure. Paragraph [0094] explains
`
`that “[f]lowchart 400 summarizes the processing steps that may be performed in an
`
`embodiment as part of dynamic analysis in connection with an MC detection
`
`system 100 during application execution.” (Ex. 1003 at 23, ¶ 94 (emphasis
`
`added).) In light of this earlier explanatory statement, the statement that “control
`
`proceeds to step 410 to continue execution of the target routine,” plainly means
`
`that application execution is continuing—not that the target routine is continuing
`
`to execute. (Ex. 1003 at 23 ¶ 94.) This conclusion—i.e., that it is application
`
`execution that is ongoing, and that the execution of the target routine is newly
`
`beginning—is reinforced by another portion of paragraph [0094]. Paragraph [0094]
`
`notes that it summarizes “the run time processing previously described in
`
`connection with illustration 200 of Figure 7.” (Ex. 1003 at 23 ¶ 94 (emphasis
`
`added).) Figure 7 is described in paragraphs [0084], [0085], and [0088], which
`
`unequivocally state that none of the instructions or inputs to the second/target
`
`function are executed until after a security check is performed, and that if
`
`malicious code is detected, the routine is not executed at all. (Ex. 1003 at 22 ¶¶ 84,
`
`85, 88.) These disclosures apply equally to Figures 7 and 9, and are only consistent
`
`
`
`
`
`-12-
`
`
`
`
`
`
`
`with the interpretation offered here, that it is application execution that is ongoing,
`
`not function execution.
`
`Second, the Decision finds that, “in order for the stub or wrapper function to
`
`be executed, the target function must be invoked first.” (Paper 62 at 52.) This
`
`finding is irrelevant to whether Khazan teaches the “invoking a second function
`
`with the input” limitation. The finding arises out of the Decision’s failure to give
`
`meaning to the “with the input” limitation, and mistakenly focuses on when the
`
`second/target function is “invoked,” rather than when the second/target function is
`
`“invoked with the input.” As Khazan explains in paragraphs [0084], [0085], and
`
`[0088], none of the instructions in the second/target function are executed until
`
`after the stub/wrapper function verifies it is safe. (Ex. 1003 at 22 ¶¶ 84, 85, 88.)
`
`The input to the second/target function cannot be invoked until some instruction in
`
`the second/target function is executed, and that does not occur until after
`
`verification occurs.
`
`E.
`
`The Board should construe the term “call to a first function” the
`same way in this case and in IPR2016-00151
`As argued in the motion for rehearing in IPR2016-00151, the Board should
`
`construe the term “call to a first function” consistently in this case and the co-
`
`pending -00151 case by applying the claim construction entered in this case to the
`
`‘00151 case. In Markman v. Westview Instruments, Inc., the Supreme Court
`
`explained that the purpose of patent claims is to apprise the public of what is and is
`
`
`
`
`
`-13-
`
`
`
`
`
`
`
`not protected by a particular patent, and emphasized the “importance of
`
`uniformity” in the treatment (i.e., the claim construction) of a given patent.
`
`Markman v. Westview Instruments, Inc., 517 U.S. 370, 390 (1996). Uniformity in
`
`claim construction serves the public interest: “the limits of a patent must be known
`
`for the protection of the patentee, the encouragement of the inventive genius of
`
`others and the assurance that the subject of the patent will be dedicated ultimately
`
`to the public.” Id. (quoting General Elec. Co. v. Wabash Appliance Corp., 304
`
`U.S. 364, 369 (1938)). The Board’s inconsistent constructions of the term “call to a
`
`first function” create an impermissible “zone of uncertainty” for the parties and
`
`public. Id. Rehearing should be granted to eliminate that uncertainty by
`
`harmonizing the construction of “call to a first function” in the -00151 case with
`
`the correct construction entered in this case. Id.
`
`IV. CONCLUSION
`The Decision’s finding that Khazan fails to teach the “invoking a second
`
`function with the input” limitation is based on an erroneous claim construction and
`
`clearly erroneous findings of fact. Palo Alto Networks respectfully requests that
`
`the Board grant rehearing, reconsider its Decision, and enter a modified Decision
`
`finding (1) that Khazan renders obvious the “invoking a second function with the
`
`input” limitation, and (2) that claims 1-5 of the ‘154 patent are invalid as obvious
`
`in light of the teachings of Khazan and Sirer.
`
`
`
`
`
`-14-
`
`
`
`
`
`
`
`Palo Alto Networks also respectfully requests that the Board harmonize the
`
`construction of “call to a first function” in this case and IPR2016-00151 by
`
`applying the construction entered in this case to the -00151 case.
`
`
`
`
`
`
`
`
`
`
`
`-15-
`
`
`
`
`
`
`
`
`
`
`By:
`
`
`
`
`
`
`By:
`
`
`
`
`Respectfully submitted,
`COOLEY LLP
`
`/Orion Armon/
`Orion Armon
`Reg. No. 65,421
`Counsel for Palo Alto
`Networks, Inc.
`
`QUINN EMANUEL URQUHART
`& SULLIVAN, LLP
`
`/Nathaniel A. Hamstra/
`Nathaniel Hamstra
`Reg. No. 65,680
`Counsel for Symantec Corp..
`
`Dated: April 14, 2017
`
`COOLEY LLP
`ATTN: Patent Group
`1299 Pennsylvania Ave., NW, Suite 700
`Washington, DC 20004
`Tel: (703) 456-8000
`Fax: (202) 842-7899
`
`
`
`
`
`
`
`Quinn Emanuel Urquhart & Sullivan , LLP
`500 West Madison Street, Suite 2450
`Chicago, IL 60661
`Tel.: (312)705-7400 Fax: (312)705-7401
`
`
`
`
`
`
`
`
`-16-
`
`
`
`
`
`
`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §§ 42.6(e), the undersigned certifies that on April 14,
`
`2017, a complete and entire copy of this Motion for Rehearing was served by
`
`filing this document through the E2E System, as well as delivering via electronic
`
`Jeffrey H. Price
`KRAMER LEVIN NAFTALIS &
`FRANKEL LLP
`1177 Avenue of the Americas
`New York, NY 10036
`Phone: (212) 715-7502
`Fax: (212) 715-8302
`jprice@kramerlevin.com
`
`Nathaniel A. Hamstra
`David Nelson
`Kenneth K. Suh
`QUINN EMANUEL
`500 W. Madison St., Suite 2450
`Chicago, IL 60661
`nathanhamstra@quinnemanuel.com
`davenelson@quinnemanuel.com
`kennethsuh@quinnemanuel.com
`
`By:
`
`
`
`/Orion Armon/
`Orion Armon
`Reg. No. 65,421
`
`
`
`mail to the following counsel of record:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`James Hannah
`KRAMER LEVIN NAFTALIS &
`FRANKEL LLP
`
`
`
`990 Marsh Road
`
`
`
`Menlo Park, CA 94025
`
`
`Phone: (650) 752-1712
`
`
`Fax: (650) 752-1812
`
`
`jhannah@kramerlevin.com
`
`
`
`
`
`Michael Kim
`
`
`
`Finjan, Inc.
`2000 University Ave., Ste. 600
`E. Palo Alto, CA 94303
`
`Phone: 650.397.9567
`
`
`mkim@finjan.com
`
`
`USPTO Reg. No. 40,450
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`-3-
`
`
`
`
`
`144129860 v2
`
`
`
`
`
`
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
