throbber

`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`PALO ALTO NETWORKS, INC.,
`Petitioner
`
`v.
`
`FINJAN, INC.,
`Patent Owner
`
`Patent No. 8,141,154
`
`_______________
`
`Inter Partes Review No. IPR2016-00151
`
`____________________________________________________________
`
`PETITIONER’S OPENING BRIEF
`ON REMAND
`
`
`
`
`
`
`
`va-532786
`
`

`

`TABLE OF CONTENTS
`
`Page
`
`B.
`
`INTRODUCTION .............................................................................................. 1
`I.
`II. ARGUMENT ...................................................................................................... 1
`A.
`The asserted prior art discloses the “input variable[s] includ[ing] a
`call to an additional function” limitation of claims 9 and 12 of the
`’154 patent. ............................................................................................... 1
`The Board misapprehended Calder’s disclosure relating to the
`interception of DLLs as failing to teach or suggest “wherein the
`modified input variable includes a call to a modified additional
`function instead of a call to the additional function,” as recited in
`claims 9 and 12. ........................................................................................ 5
`The Board improperly required that the teachings of Calder be
`bodily incorporated into the teaching of Ross to establish a prima
`facie case of obviousness. ........................................................................ 7
`III. CONCLUSION ................................................................................................... 9
`
`C.
`
`va-532786
`
`-i-
`
`

`

`I.
`
`INTRODUCTION
`
`Petitioner Palo Alto Networks, Inc. submits this brief, per the Board’s January
`
`23, 2019 order, to address the patentability of claims 9 and 12 of the ’154 patent in
`
`light of the prior art, arguments presented in its original petition (“Petition”), and the
`
`Board’s discussion of those arguments in its original institution decision (“Institution
`
`Decision”). For the reasons discussed below, the evidence and arguments presented
`
`in the Petition show that claims 9 and 12 are invalid over Ross in view of Calder.
`
`II.
`
`ARGUMENT
`
`The Board’s Institution Decision concluded that Petitioner had not
`
`sufficiently shown that the combination of Ross and Calder teach the following
`
`limitations of claims 9 and 12 : (1) “an input that itself includes a call to an additional
`
`function as in the ʼ154 patent” (Institution Decision at 15); and (2) “modified input
`
`variable includes a call to a modified additional function instead of a call to the
`
`additional function” (id. at 17). The Board also found that Petitioner made an
`
`inadequate showing of “what modification of Ross’s hook script generator (or
`
`injector) would be needed . . . to achieve the recursive function alleged to be the
`
`result of Calder” (id. at 16-17). None of these issues should defeat institution.
`
`A.
`
`The asserted prior art discloses the “input variable[s] includ[ing] a
`call to an additional function” limitation of claims 9 and 12 of the
`’154 patent.
`
`va-532786
`
`1
`
`

`

`IPR2016-00151
`
`As Patent Owner discussed in its preliminary response (See Preliminary
`
`Response at 23-24), the ’154 patent applicants explained in the specification what
`
`they meant by the “input variable[s] includ[ing] a call to an additional function”
`
`limitation. (Id.) This explanation is identical to what the Petition and the supporting
`
`declaration of Dr. Rubin (“Rubin Declaration”) set forth, explaining how Ross
`
`discloses this limitation in reference to Java code. The Petition additionally addresses
`
`Calder’s disclosure of this limitation. (Petition at 38-40.) The Board overlooked
`
`these arguments in denying institution. (Institution Decision at 15.)
`
`In its Preliminary Response, the Patent Owner cited to 12:28-42 of the ’154
`
`patent to explain what the patent applicants meant by the “input variable[s]
`
`includ[ing] a call to an additional function” limitation. (Preliminary Response at 15.)
`
`That portion of the ’154 patent discloses:
`
`Malicious code may be generated within further recursive
`levels of function calls. For example, instead of the function
`call (3), which invokes a single function to dynamically
`generate JavaScript, two levels of function calls may be
`used. Consider for example, the recursive function call
`
`Document.write(“<h1>Document.write(“<h1><SCRIPT>
`Some JavaScript</SCRIPT></h1”)</h1>”)
`
`Such a function call first calls Document.write() to generate
`the function call (3), and then calls Document.write() again
`to generate the JavaScript. If the inputs to each of the
`Document.write() invocations in (5) are themselves
`
`va-532786
`
`2
`
`

`

`IPR2016-00151
`
`dynamically generated at run-time, then one pass through
`input inspector may not detect the JavaScript.
`
`(‘154 patent at 12:28-42 (emphasis added).) In other words, the cited specification of
`
`the ’154 patent corroborates the point made by the Petition and Dr. Rubin that
`
`JavaScript code incorporates the ability to include a function as an input variable of
`
`another function.
`
`The ’154 patent confirms that recursive function calls was a known feature of
`
`Java, as stated in the Petition and by Dr. Rubin. The background section of the ’154
`
`patent, in discussing the context of the claimed invention, provides a nearly identical
`
`code example as the above specification disclosure. (’154 patent at 1:43-53.) The
`
`’154 patent explains in the background section that “[i]n the example above, the
`
`function document.write() is used to generate HTML header text, with a text string
`
`that is generated at run-time. If the text string generated at run-time is of the form
`
`<SCRIPTS-malicious JavaScript-/SCRIPTs then the document, write() function
`
`will insert malicious JavaScript into the HTML page that is currently being
`
`rendered by a web browser.” This admission of the capabilities of malicious code in
`
`the background section confirms that an “input variable [that] includes a call to an
`
`additional function,” was a well-known feature and not a point of novelty as
`
`contended by the Petition and the supporting declaration of Dr. Rubin.
`
`va-532786
`
`3
`
`

`

`IPR2016-00151
`
`Specifically, the Petition showed that “the ability of the inputs described in
`
`Ross to call additional functions is implied by its discussion of Java code,” and cited
`
`to Dr. Rubin’s declaration. (Petition at 37 (citing Rubin Declaration ¶ 158).) In the
`
`cited portion of his declaration, Dr. Rubin explained that “at the time of the ’154
`
`patent it was well known that HTTP/Java content contained functions that called
`
`other functions. These types of functions are known as recursive functions and are
`
`commonly employed in scripted languages such as Java which were widely available
`
`before the priority date of the ’154 patent.” (Rubin Declaration ¶ 158.) The
`
`background and specification of the ’154 patent confirm what the Petition argued and
`
`what Dr. Rubin explained: that Java code was known to include as a feature that a
`
`function could include a call to another function as an input.
`
`Having established that input variables that include calls to other functions was
`
`well-known and not a point of novelty, the Petition provided evidence that this feature
`
`was also taught by Calder. The Petition pointed to Calder’s disclosure regarding
`
`“making a memory page executable,” as an example of an input variable including a
`
`call to a second function.” (Petition at 40.) For instance, Calder at ¶ 200 states that
`
`“if the application 305 requests to make the pages executable, the process flow
`
`proceeds to step 3340, the pages are checked for improper sequence.” As explained
`
`in the Petition, this disclosure in Calder teaches that an application (i.e., the function)
`
`va-532786
`
`4
`
`

`

`IPR2016-00151
`
`can make a call to an additional function (i.e., a function that makes the pages
`
`executable.) Given that a person of skill in the art would know that functions can
`
`make calls to additional functions by including those calls as input variables to the
`
`function (as evidenced by the ’154 patent, the Petition, and the declaration of Dr.
`
`Rubin), Calder’s disclosure regarding making memory pages executable would have
`
`further suggested to a person of ordinary skill in the art (“POSITA”) the feature of
`
`“wherein the input variable includes a call to an additional function,” as recited in
`
`claims 9 and 12 of the ’154 patent.
`
`Petitioner respectfully submits that the Board overlooked the fact that the
`
`Patent Owner pointed to a portion of the ’154 patent in its Preliminary Response as
`
`disclosing “wherein the input variable includes a call to an additional function.”
`
`which confirmed the invalidity grounds that the Petition and Dr. Rubin’s declaration
`
`set forth as to claims 9 and 12. The Petition, Dr. Rubin’s declaration, the ’154 patent,
`
`and Calder all agree that this limitation was not a point of novelty and well-known in
`
`the prior art.
`
`B.
`
`The Board misapprehended Calder’s disclosure relating to the
`interception of DLLs as failing to teach or suggest “wherein the
`modified input variable includes a call to a modified additional
`function instead of a call to the additional function,” as recited in
`claims 9 and 12.
`
`va-532786
`
`5
`
`

`

`IPR2016-00151
`
`The Petition and the supporting declaration of Dr. Rubin point to Calder’s
`
`disclosure of initially loading a DLL for the interception module before any other
`
`DLL, as teaching or suggesting “wherein the modified input variable includes a call
`
`to a modified additional function instead of a call to the additional function,” as
`
`recited in claims 9 and 12. (See Petition at 41 and Rubin Declaration ¶ 165.) The
`
`Board stated that the Petition merely “relies on ‘rewriting DLLs loaded during
`
`program execution.” (Institution Decision at 17.) Applicant respectfully submits that
`
`the Board misapprehended what the Petition and Dr. Rubin’s declaration describe as
`
`teaching the above recited limitations of claims 9 and 12.
`
`The Petition does not merely assert that the act of “rewriting DLLs loaded
`
`during program execution,” teaches or suggests “wherein the modified input variable
`
`includes a call to a modified additional function instead of a call to the additional
`
`function,” as recited by claims 9 and 12, but rather explains that the method by which
`
`those DLLs are rewritten teaches this feature to a POSITA. The Petition points out
`
`that Calder “teaches initially loading a DLL for the inception module prior to any
`
`other DLL” and cites ¶ 105 of Calder in support. (Petition at 41.) That paragraph of
`
`Calder states “all DLL routines that are to be intercepted are redirected to a wrapper
`
`routine to intercept them. The interception module DLL performs its API patching
`
`for every DLL that has been loaded.” As Dr. Rubin further explained, “[r]ecognizing
`
`va-532786
`
`6
`
`

`

`IPR2016-00151
`
`the possibility that a malicious application could use an un-modified DLL to make
`
`improper system call, Calder teaches initially loading a DLL for the interception
`
`module prior to any other DLL. After the first module is executed, when the
`
`application attempts to load another DLL, Calder teaches that ‘all DLL routines that
`
`are to be intercepted are redirected to a wrapper routine to intercept them.’” (Rubin
`
`Decl. ¶ 165 (citing Calder ¶ 105).) Thus, as a result, once the initial DLL for the
`
`interception module is loaded, all subsequent DLL function calls will be rerouted
`
`(i.e., modified) so that they invoke the interception module first. (Rubin Declaration
`
`¶ 166.) Thus, even if a DLL call was included as an input variable to another DLL
`
`call, that input variable DLL call would also invoke the interception module (i.e., the
`
`modified additional function call).
`
`Thus, as set forth in the Petition, Calder teaches that no matter where the
`
`function call is made (i.e., as an input variable to a function, or as a call within a
`
`function), that call will result in a call to a modified additional function (i.e., the
`
`interception module). (See Petition at 41 and Rubin Declaration ¶ 165.)
`
`C.
`
`The Board improperly required that the teachings of Calder be
`bodily incorporated into the teaching of Ross to establish a prima
`facie case of obviousness.
`
`In its Institution Decision, the Board states that “[w]e do not see adequate
`
`explanation in the record regarding what modification of Ross’ hook script generator
`
`va-532786
`
`7
`
`

`

`IPR2016-00151
`
`(or injector) would be needed to dynamically generate the input and rewrite the
`
`binary (as done in Calder) in order to achieve the recursive function alleged in be the
`
`result of Calder.” (Institution Decision at 16-17.) Petitioner respectfully submits that
`
`this assertion by the Board misapprehends the arguments presented in the Petition.
`
`The Board appears to ask Petitioner to explain how Ross is to be modified to
`
`incorporate the system of Calder to establish a prima facie case for obviousness.
`
`(Institution Decision at 16-17.) However, claims 9 and 12 of the ’154 patent do not
`
`recite how to modify an input variable to include a call to a modified additional
`
`function. Accordingly, Petitioner should not be required to make this showing when
`
`establishing a prima facie case of obviousness as to clams 9 and 12 over Ross in view
`
`of Calder.
`
`In any event, “[t]he test for obviousness is not whether the features of a
`
`secondary reference may be bodily incorporated into the structure of the primary
`
`reference. Rather, the test is what the combined teachings of the references would
`
`have suggested to those of ordinary skill in the art.” In re Keller, 642 F.2d 413, 425
`
`(C.C.P.A. 1981); see also In re Sneed, 710 F.2d 1544, 1550 (Fed. Cir. 1983) (“[I]t is
`
`not necessary that the inventions of the references be physically combinable to render
`
`obvious the invention under review.”); and In re Nievelt, 482 F.2d 965, 968 (C.C.P.A.
`
`va-532786
`
`8
`
`

`

`IPR2016-00151
`
`1973) (“Combining the teachings of references does not involve an ability to combine
`
`their specific structures.”).
`
`Here, the Petition demonstrates what the disclosure of Calder suggests to a
`
`POSITA. (See Petition at 38-40.) Calder’s disclosure of a system which ensures that
`
`every call to a function (no matter where that call is executed) is modified so that it
`
`invokes an interception module, would have suggested to a POSITA to modify the
`
`system of Ross such that “the modified input variable includes a call to a modified
`
`additional function instead of a call to the additional function,” as recited in claims 9
`
`and 12. (Id.) Calder teaches to a POSITA, that the system of Ross should be
`
`modified to ensure that any calls to a function (even calls made as input variables to
`
`other functions) should be modified so they are routed to a security computer.
`
`(Petition at 40-41.)
`
`Therefore, the Petitioner respectfully submits that it established a reasonable
`
`likelihood that it would prevail in showing that claims 9 and 12 of the ’154 patent are
`
`unpatentable as obvious over the combination of Ross alone or in combination with
`
`Calder.
`
`III. CONCLUSION
`
`For the reasons set forth above, Petitioner respectfully requests that claims 9
`
`and 12 be found unpatentable per the grounds identified in the Petition.
`
`va-532786
`
`9
`
`

`

`IPR2016-00151
`
`Dated: February 13, 2019
`
`Respectfully submitted,
`
` / Shouvik Biswas /
`Shouvik Biswas
` Registration No.: 68,439
`MORRISON & FOERSTER LLP
`1650 Tysons Boulevard, Suite 400
`McLean, VA 22102
`Tel: (703) 760-7774
`Attorney for Petitioner Palo Alto
`Networks, Inc.
`
`va-532786
`
`10
`
`

`

`IPR2016-00151
`
`Certificate of Service (37 C.F.R. § 42.6(e)(4))
`
`I hereby certify that the attached PETITIONER’S OPENING BRIEF ON
`
`REMAND was served as of the below date via e-mail to the following counsel of
`
`record for the Patent Owner:
`
`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
`jprice@kramerlevin.com
`svdocketing@kramerlevin.com
`mkim@finjan.com
`
`Dated: February 13, 2019
`
`/ Shouvik Biswas /
`Shouvik Biswas
`
`va-532786
`
`11
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket