`
`
`
`
`
`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
`
`
`
`
`
`