UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`Palo Alto Networks, Inc.
`Petitioner
`
`v.
`
`Finjan, Inc.
`Patent Owner
`
`U.S. Patent No. 7,647,633
`Filing Date: June 22, 2005
`Issue Date: January 12, 2010
`
`Title: Malicious Mobile Code Runtime Monitoring System and Methods
`
`Inter Partes Review No. 2015-01974
`
`
`
`PETITIONER PALO ALTO NETWORKS, INC.’S
`REQUEST FOR REHEARING UNDER 37 C.F.R. § 42.71(c)
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`Palo Alto Networks, Inc.
`Petitioner
`
`v.
`
`Finjan, Inc.
`Patent Owner
`
`U.S. Patent No. 7,647,633
`Filing Date: June 22, 2005
`Issue Date: January 12, 2010
`
`Title: Malicious Mobile Code Runtime Monitoring System and Methods
`
`Inter Partes Review No. 2015-01974
`
`
`
`PETITIONER PALO ALTO NETWORKS, INC.’S
`REQUEST FOR REHEARING UNDER 37 C.F.R. § 42.71(c)
`
`
`
`
`
`
`
`Table of Contents
`
`
`Page
`
`
`INTRODUCTION AND STATEMENT OF RELIEF REQUESTED .......... 1
`I.
`FACTUAL BACKGROUND AND PROCEDURAL POSTURE ................ 3
`II.
`III. LEGAL STANDARDS .................................................................................. 4
`IV. BASIS FOR RELIEF REQUESTED ............................................................. 5
`A.
`The Petition offers a detailed explanation of how Shin discloses
`three specific “determining” methods and, in particular, looking
`for a “magic byte sequence.” ................................................................ 5
`The ’633 Patent specification expressly identifies Shin’s “magic
`byte sequence” method as an example of the claimed
`“determining” step. ............................................................................... 7
`CONCLUSION ............................................................................................. 10
`
`V.
`
`B.
`
`
`
`
`
`-i-
`
`
`
`
`
`Table of Authorities
`
`
`Page(s)
`
`
`Cases
`Cutsforth, Inc. v. MotivePower, Inc.,
`Case No. 2015-1316, 2016 WL 279984 (Fed. Cir. Jan. 22, 2016) ............. 4, 5, 10
`
`In re Sang-Su Lee,
`277 F.3d 1338 (Fed. Cir. 2002) ........................................................................ 4, 5
`
`Stevens v. Tamai,
`366 F.3d 1325 (Fed. Cir. 2004) ........................................................................ 3, 4
`
`Statutes
`
`35 U.S.C. § 325(d) ................................................................................................. 1, 3
`
`Administrative Procedure Act, Pub. L. No. 404, § 8(b) (1946) ................................ 4
`
`Other Authorities
`
`37 C.F.R.
`§ 42.71(c) .............................................................................................................. 1
`§ 42.71(d) .............................................................................................................. 4
`
`
`
`
`
`
`
`-ii-
`
`
`
`
`
`Pursuant to 37 C.F.R. § 42.71(c), Petitioner Palo Alto Networks, Inc.
`
`(“Petitioner” or “PAN”) moves for rehearing of the Patent Trial & Appeal Board’s
`
`(“Board”) Decision (hereafter the “Decision”) denying institution of inter partes
`
`review of claims 1-4, 6-8, and 13 of U.S. Patent No. 7,647,633 (“the ’633 patent”).
`
`(Paper 7.) Rehearing of the Board’s denial of institution is warranted because the
`
`Decision was based on the clearly erroneous conclusion that the teachings of Insik
`
`Shin & John C. Mitchell, “Java Bytecode Modification and Applet Security,” (Ex.
`
`1009) are substantially the same as the teachings of U.S. Patent No. 5,983,348 to Ji
`
`(Ex. 2006). (Decision at 9-11.)
`I.
`
`INTRODUCTION AND STATEMENT OF RELIEF REQUESTED
`
`Petitioner Palo Alto Networks respectfully moves for rehearing because the
`
`Board misapprehended Shin’s teachings, and its denial of institution under §
`
`325(d) resulted from clearly erroneous findings regarding the similarity of the
`
`teachings in the Shin and Ji prior art references.
`
`Grounds 1 and 3 of the Petition rely on Shin’s teaching of searching for a
`
`Java class header called a “magic byte code sequence” to satisfy the limitation in
`
`the ’633 patent claims that requires “determining . . . whether the downloadable
`
`information includes executable code”. (Petition at 4, 29-30, 48-50.) The ’633
`
`patent specification specifically identifies the very same method Shin teaches—
`
`searching a Java class header—as one embodiment that satisfies the “determining”
`
`
`
`
`
`-1-
`
`
`
`
`
`limitation. (Petition at 29-30, 48 (“File-reader 502 can, for example, be configured
`
`to analyze a received potential-Downloadable for a file header, which is typically
`
`included in accordance with conventional data transfer protocols, such as a
`
`portable executable or standard “.exe” file format for Windows OS application
`
`programs, a Java class header for Java applets, and so on for other applications,
`
`distributed components, etc.”) (emphasis added); see also Rubin Decl., Ex. 1002,
`
`at ¶¶ 111, 114.)
`
`The Board overlooked Shin’s express disclosure of searching for a Java class
`
`header, and the ’633 patent’s disclosure that searching for a Java class header
`
`satisfies the “determining” limitation, when it erroneously concluded that Shin’s
`
`teachings are substantially the same as Ji’s teachings. The Board’s factual finding
`
`is incorrect. Shin’s teaching expressly matches the ’633 patent’s disclosure for the
`
`“determining” limitation. In contrast, the Board found in a related proceeding
`
`concerning Finjan’s ’822 patent that Ji’s method of scanning for <applet> tags to
`
`determine whether a downloadable includes executable code does not satisfy the
`
`“determining” limitation. (Ex. 2002 at 4-6.) A prior art teaching that expressly
`
`matches an embodiment of a claim element described in the specification of a
`
`challenged patent cannot, as a matter of law, be “substantially the same as” a
`
`teaching in another prior art reference that fails to disclose a key claim element.
`
`
`
`
`
`-2-
`
`
`
`
`
`The Board’s sole basis for denying institution of claims 1-4, 6-8, and 13 of
`
`the ’633 patent under Grounds 1 and 3 was its determination that Shin’s teachings
`
`and Ji’s teachings are substantially the same with respect to the “determining”
`
`limitation. That fact finding is clearly erroneous, so the denial of institution as to
`
`those claims and grounds warrants rehearing and institution of inter partes review
`
`on those claims and grounds. Stevens v. Tamai, 366 F.3d 1325, 1329 (Fed. Cir.
`
`2004) (holding that clearly erroneous findings of fact or law warrant rehearing).
`II.
`
`FACTUAL BACKGROUND AND PROCEDURAL POSTURE
`
`The Board denied institution of ’633 patent claims 1-4, 6-8, and 13, 28, and
`
`34 under 35 U.S.C. § 325(d) in light of the FireEye ex parte reexamination after
`
`concluding that the Petition presents substantially the same prior art and arguments
`
`concerning two issues: (1) whether detecting an applet satisfies the “determining”
`
`limitation; and (2) whether a Java file consisting of the instrumented applet code
`
`satisfies the “sandboxed package” limitations.
`
`The second basis for denial—the “sandboxed package” limitation—is only
`
`found in ’633 patent claims 28 and 34, which were challenged in Grounds 2 and 4
`
`of the Petition. While Petitioner respectfully disagrees with the Board’s denial of
`
`institution on claims 28 and 34, it does not seek rehearing on those claims.
`
`Therefore, this motion for rehearing does not address the Board’s second finding
`
`
`
`
`
`-3-
`
`
`
`
`
`regarding the “sandboxed package” limitation, which solely concerned claims that
`
`are not at issue in this motion for rehearing.
`
`Petitioner respectfully requests that the Board reconsider its denial of
`
`institution of claims 1-4, 6-8, and 13 under Grounds 1 and 3 because it
`
`misapprehended Shin’s disclosure regarding the “determining” limitation.
`III. LEGAL STANDARDS
`
`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).
`
`“[T]he Board must articulate its reasoning for making its decision,” as well
`
`as “develop and explain the basis for its findings.” Cutsforth, Inc. v. MotivePower,
`
`Inc., Case No. 2015-1316, 2016 WL 279984, at *3 (Fed. Cir. Jan. 22, 2016)
`
`(reversing the Board’s Final Written Decision where it did not provide enough
`
`explanation to support its finding of obviousness); In re Sang-Su Lee, 277 F.3d
`
`1338, 1342-45 (Fed. Cir. 2002) (reversing denial of a patent application and
`
`remanding so that the Board could provide “reasoned decisionmaking”); see also
`
`Administrative Procedure Act, Pub. L. No. 404, § 8(b) (1946). “Broad, conclusory
`
`
`
`
`
`-4-
`
`
`
`
`
`statements are not enough to satisfy the Board’s obligation to provide reasoned
`
`explanation for its decision.” Cutsforth, 2016 WL 279984, at *3 (citing In re Sang-
`
`Sue Lee, 277 F.3d at 1343-45).
`IV. BASIS FOR RELIEF REQUESTED
`
`The Board erroneously concluded that Shin’s teachings regarding the
`
`“determining” limitation are substantially similar to the teachings in the Ji patent
`
`that was considered during reexamination. (Decision at 9-11.) In fact, Petitioner
`
`and its expert, Dr. Rubin, explained that Shin discloses precisely what was found
`
`to be missing in Ji—that is, determining whether or not downloadable information
`
`includes executable code by scanning for a magic byte sequence in the file header.
`
`(Petition at 29-30, 48; Rubin Decl., Ex. 1002, at ¶¶ 109-14, 125, 127.)
`
`A. The Petition offers a detailed explanation of how Shin discloses
`three specific “determining” methods and, in particular, looking
`for a “magic byte sequence.”
`
`During the preliminary proceeding, the Board and Patent Owner addressed
`
`only one of Shin’s “determining” methods—looking for <applet> tags. As
`
`explained in the Petition, Shin also discloses searching a Java class header for a
`
`“magic byte sequence” to determine whether downloadable information includes
`
`executable code. The Petition establishes that Shin discloses not only looking for
`
`<applet> tags, but also looking for a “magic byte sequence that is required at the
`
`beginning of every [Java] class file”:
`
`
`
`
`
`-5-
`
`
`
`
`
`“A few techniques are considered to try to block Java applets at the
`firewall. . . . Another idea is to detect Java class files at the firewall by
`a magic byte sequence that is required at the beginning of every class
`file or by their name which will end in .class.” (Ex. 1009 at 17-18.)
`
`(Petition at 29; see also Petition at 26.) Dr. Rubin explained that this magic byte
`
`sequence corresponds to a specific Java class sequence that appears at the
`
`beginning of every Java class file:
`
` “In downloading or receiving information, firewalls and proxy
`servers receive an incoming stream of data bytes. (Ex. 1075 at 6, col.
`1, “Firewall Design”; Ex. 1009 at 17-18.) The firewall disclosed in
`Shin scans this incoming data stream for a ‘magic byte sequence,’ a
`specific sequence of bytes that is known to appear in Java applets.
`(Ex. 1009 at 17-18.) Therefore, when Shin’s firewall scans for this
`known ‘magic byte sequence,’ it is scanning the downloadable-
`information to determine whether it includes a Java applet or
`executable code.”
`
`(Rubin Decl., Ex. 1002, at ¶ 111.) Dr. Rubin further clarifies that the “magic byte
`
`sequence” disclosed in Shin corresponds to “a Java class header” that is known to
`
`appear in Java applets:
`
`“Shin discloses at least one of the same techniques for detecting
`executable code that are disclosed in the ’633 patent, namely looking
`for ‘a Java class header for Java applets,’ which is the ‘magic byte
`sequence’ discussed above. (Ex. 1075 at 12; Ex. 1001 at 14:60-65
`(‘File-reader 502 can, for example, be configured to analyze a
`-6-
`
`
`
`
`
`
`
`
`
`received potential-Downloadable for a file header . . . such as . . . a
`Java class header for Java applets.’) (emphasis added).)”
`
`(Rubin Decl., Ex. 1002, at ¶ 114 (bolded emphasis added); see also id. at ¶ 111.)
`
`Accordingly, the Petition and Dr. Rubin established that Shin discloses looking for
`
`a Java class header—the magic byte sequence—in Java applets. (Petition at 29-30,
`
`48; Rubin Decl., Ex. 1002, at ¶¶ 111, 114, 125, 127.)
`
`B.
`
`The ’633 Patent specification expressly identifies Shin’s “magic
`byte sequence” method as an example of the claimed
`“determining” step.
`
`As explained in the Petition and by Dr. Rubin, the ’633 patent specification
`
`provides examples of “determining” methods used by the claimed system to
`
`determine whether downloadable information includes executable code. (Petition
`
`at 29-30; see also id. at 48; Rubin Decl., Ex. 1002, at ¶ 114.) Petitioner and Dr.
`
`Rubin cite directly to the patent for their assertion that detecting a “magic byte
`
`sequence” known to be in Java applets—that is, a Java class header, (Rubin Decl.,
`
`Ex. 1002, at ¶ 114)—satisfies the “determining” limitation:
`
`“File type detector 502 receives and determines whether the potential-
`Downloadable (likely) is or includes an executable file type. File-
`reader 502 can, for example, be configured to analyze a received
`potential-Downloadable for a file header, which is typically included
`in accordance with conventional data transfer protocols, such as a
`portable executable or standard “.exe” file format for Windows OS
`application programs, a Java class header for Java applets, and so
`
`
`
`
`
`-7-
`
`
`
`
`
`on for other applications, distributed components, etc. (Ex. 1001 at
`15:3-8; emphasis added.)”
`
`(Petition at 29-30; see also id. at 48; Rubin Decl., Ex. 1002, at ¶ 114.) The Petition
`
`explained that Shin’s disclosure of looking for the “magic byte sequence” in the
`
`beginning of a Java class file corresponds to the ’633 patent’s express example:
`
`“Shin’s disclosure regarding how to detect Java class files exactly
`matches one of the examples provided in the ’633 patent for
`determining whether or not downloadable information includes
`executable code . . . .”
`
`(Petition at 29; see also Rubin Decl., Ex. 1002, at ¶ 114.)
`
`
`
`Dr. Rubin, a doctor of computer science and engineering, with more than
`
`twenty years of experience in Internet and computer security, explained and cited
`
`supporting evidence that Shin discloses “at least one of the same techniques for
`
`detecting executable code that are disclosed in the ’633 patent, namely looking for
`
`‘a Java class header for Java applets,’ which is the ‘magic byte sequence’
`
`discussed above.” (Rubin Decl., Ex. 1002, at ¶ 114; see also id. at ¶ 111, 125, 127.)
`
`Shin’s disclosure regarding specific “determining” methods, and the “magic byte
`
`sequence” method in particular, is the very reason Petitioner relied on Shin rather
`
`than any Poison Java-related reference for the “determining” limitation. Shin’s
`
`disclosure is the key difference that sets it apart from the Ji reference and makes it
`
`non-cumulative prior art.
`
`
`
`
`-8-
`
`
`
`
`
`
`
`Patent Owner did not address Petitioner’s evidence concerning Shin’s
`
`teaching to search for the Java class header in its Preliminary Response. (Patent
`
`Owner Preliminary Response (“POPR”) at 17-18, 21-22, 30-32.) Patent Owner
`
`highlighted the key feature missing in Ji: “Ji receives and instruments applets
`
`without ever determining whether downloadable-information includes executable
`
`code.” (POPR at 18.) Ignoring Shin’s teaching of searching the Java class header,
`
`Patent Owner then argued that Shin was “substantially the same” as Ji, because it
`
`teaches “discriminating Java applets from non-applets.” (POPR at 21-22, 30-32.)
`
`
`
`Patent Owner’s characterization was misleading and incomplete. Shin does
`
`precisely what Ji failed to do, which is to disclose a specific method of
`
`“determining” that unambiguously satisfies the limitation even in the form it was
`
`construed by the Board in the ’822 patent FireEye reexamination. (Petition at 29-
`
`30, 48-50.) Patent Owner never addressed Shin’s disclosure of examining a Java
`
`class header for a magic byte sequence because that method of satisfying the
`
`“determining” step is expressly tied to the ’633 patent specification. (Petition at 29-
`
`30, 48; Rubin Decl., Ex. 1002, at ¶¶ 111, 114.) Accordingly, Petitioner’s proof that
`
`Shin discloses the “determining” limitation by examining the Java class header for
`
`a magic byte sequence is uncontested.
`
`
`
`Despite the lack of Patent Owner’s response (or possibly because of), the
`
`Board overlooked or misapprehended Shin’s disclosure of a “determining” method
`
`
`
`
`
`-9-
`
`
`
`
`
`that matches an express example of “determining” provided by the ’633 patent.
`
`The APA and Federal Circuit precedent require that the Board “develop and
`
`explain the basis for its findings.” Cutsforth, 2016 WL 279984, at *3. In
`
`concluding that Shin is substantially similar to Ji, the Board only considered one of
`
`Shin’s three methods of determining whether a downloadable contains executable
`
`code. (Decision at 9-11.) The Board only addressed Shin’s disclosure of detecting
`
`applets by looking for <applet> tags, which is the only “determining” method that
`
`was specifically contested by Patent Owner’s Preliminary Response. (Decision at
`
`10-11; POPR at 21-22, 30-32.) The Board then concluded that Shin’s teachings are
`
`substantially similar to Ji’s teachings, without addressing Shin’s uncontested
`
`“magic byte sequence” teaching, or the fact that searching a Java class header for a
`
`magic byte sequence is an embodiment of “determining” described in the ’633
`
`patent. (See Decision at 9-11.) The Board’s conclusion that Shin’s teachings are
`
`substantially the same as Ji’s teachings is contradicted by the ’633 patent itself.
`
`(Petition at 29-30, 48; Rubin Decl., Ex. 1002, at ¶¶ 111, 114, 125, 127.)
`V. CONCLUSION
`
`Petitioner presented uncontested evidence that Shin’s disclosure of searching
`
`a Java class header for a magic byte sequence satisfies the “determining” limitation
`
`of the ’633 patent. This evidence is uncontested and uncontestable because it
`
`matches the disclosure of the ’633 patent.
`
`
`
`
`
`-10-
`
`
`
`
`
`The Board abused its discretion by failing to credit or by misapprehending
`
`Shin’s disclosure of the “magic byte sequence” method of “determining . . .
`
`whether the downloadable information includes executable code”. The Board’s
`
`findings of fact on that limitation were the sole basis for its denial of institution of
`
`inter partes review of Grounds 1 and 3 on claims 1-4, 6-8, and 13 of U.S. Patent
`
`No. 7,647,633. Palo Alto Networks therefore respectfully requests that the Board
`
`reconsider its Decision and institute inter partes review on those claims and
`
`grounds.
`
`
`
`Respectfully submitted,
`
`/Orion Armon/
`Orion Armon
`Reg. No. 65,421
`Lead Counsel for Petitioner
`Palo Alto Networks, Inc.
`
`
`
`
`
`By:
`
`
`
`
`
`Dated: April 12, 2016
`
`COOLEY LLP
`ATTN: Patent Group
`1299 Pennsylvania Ave., NW, Suite 700
`Washington, DC 20004
`T: 720 566 4119
`F: 720 566 4099
`
`
`
`
`
`
`
`
`
`
`
`-11-
`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 CFR §§ 42.6(e)(4) and 42.105(b), the undersigned certifies
`
`
`
`
`
`that on April 12, 2016, a complete and entire copy of this Request for Rehearing
`
`Under 37 C.F.R. § 42.71(c) was provided via email to the Patent Owner by serving
`
`the correspondence email address of record as follows:
`
`James Hannah (jhannah@kramerlevin.com)
`Jeffrey H. Price (jprice@kramerlevin.com)
`Michael Kim (mkim@finjan.com)
`svdocketing@kramerlevin.com
`
`
`
`/Orion Armon/
`Orion Armon
`Reg. No. 65,421
`
`
`
`
`
`-12-
`
`
`
`DATED: APRIL 12, 2016
`
`COOLEY LLP
`ATTN: Orion Armon
`Patent Docketing
`1299 Pennsylvania Ave. NW,
`Suite 700
`Washington, D.C. 20004
`T: 720 566 4119
`F: 720 566 4099
`
`
`
`
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
