`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`
`
`Juniper Networks, Inc.,
`Petitioner
`
`v.
`
`Finjan, Inc.,
`Patent Owner
`
`
`___________
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`___________
`
`
`
`PETITIONER’S REQUEST FOR REHEARING
`
`
`
`
`
`
`Mail Stop: PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`10682004
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`
`
`TABLE OF CONTENTS
`
`Page(s)
`INTRODUCTION .................................................................................. 1
`
`LEGAL STANDARD ............................................................................ 1
`
`I.
`
`II.
`
`III. ARGUMENT ......................................................................................... 2
`
`
`
`
`
`
`
`
`10682004
`
`- i -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`I.
`
`INTRODUCTION
`On April 29, 2019, the Board denied institution of inter partes review of U.S.
`
`Patent No. 7,647,633 (“the ‘633 Patent”), rejecting Petitioner’s assertion that certain
`
`claims of the ‘633 Patent are unpatentable over prior art Sonnenberg in view of prior
`
`art Jensen (Ground 1). See Paper 7 (Institution Decision) at 13. In its Institution
`
`Decision, the Board misapprehended the critical difference between Petitioner’s and
`
`Patent Owner’s constructions of the term “mobile protection code” and, as a result,
`
`failed to resolve the key claim construction dispute between the parties as required.
`
`See Homeland Housewares, LLC v. Whirlpool Corp., 865 F.3d 1372, 1374-75 (Fed.
`
`Cir. 2017) (citing O2 Micro Int’l, Ltd. v. Beyond Innovation Tech. Co., 521 F.3d
`
`1351, 1360 (Fed. Cir. 2008)) (requiring the Board to resolve claim construction
`
`disputes when a disputed term is relied upon for a holding on the merits). As
`
`explained further below, the Board’s failure to resolve the key claim construction
`
`dispute led to a logically unsupportable holding regarding the purported deficiency
`
`in the prior art. Rehearing is therefore warranted to resolve the claim construction
`
`dispute between the parties and fix the plain error in the Institution Decision.
`
`II. LEGAL STANDARD
`“A party dissatisfied with a decision may file a request for rehearing without
`
`prior authorization from the Board” and must “specifically identify all matters the
`
`party believes the Board misapprehended or overlooked, and the place where each
`
`10682004
`
`
`- 1 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`matter was previously addressed in a motion, opposition, or a reply.” 37 C.F.R.
`
`§ 42.71(d). This request is timely filed within 30 days from the Institution Decision
`
`denying institution. See 37 C.F.R. § 42.71(d)(2).
`
`III. ARGUMENT
`The Board fundamentally misapprehended the dispute between the parties
`
`regarding the construction of the term “mobile protection code” (hereinafter,
`
`“MPC”). In the Institution Decision, the Board stated:
`
`According to Patent Owner, the difference between
`Petitioner and Patent Owner’s constructions is that
`Petitioner’s broader construction does not specify that the
`mobile protection code monitors and intercepts operations
`without modifying the executable code.
`
`Paper 7 (Institution Decision) at 5 (emphasis in original). The Board erred in
`
`adopting Patent Owner’s characterization of the claim construction dispute.1 The
`
`actual dispute between the parties is completely different and has nothing to do with
`
`whether MPC modifies the executable code or not.
`
`
`1 Petitioner does not oppose Patent Owner’s proposal that MPC operate
`
`“without modifying the executable code” and therefore there is no dispute with
`
`respect to this issue.
`
`10682004
`
`
`- 2 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`
`As background, the Petition proposed that the broadest reasonable
`
`interpretation of “mobile protection code” (MPC) is “code for causing one or more
`
`predetermined malicious operations or operation combinations of a Downloadable
`
`to be monitored or otherwise intercepted.” Paper 2 (Petition) at 9 (emphasis added).
`
`The Petition explained the practical import of this “for causing” language was that
`
`the MPC does not itself have to monitor or intercept operations but rather may work
`
`in conjunction with other software, such as the operating system, in order to cause
`
`monitoring or intercepting to occur. Id. at 9-10. The Petition then explained how,
`
`under this construction that does not require the MPC to itself monitor or intercept,
`
`prior art Jensen’s “protection wrappers” constitute MPC because Jensen’s protection
`
`wrappers cause monitoring or intercepting by the operating system’s Access Control
`
`Lists. See Paper 2 (Petition) at 25-27.
`
`In its argument distinguishing the prior art, Patent Owner implicitly disputed
`
`Petitioner’s claim construction of MPC with respect to whether MPC must “itself”
`
`monitor or intercept. Patent Owner argued that prior art Jensen did not teach MPC
`
`for the following reason:
`
`As Petitioner readily acknowledges, Jensen’s technique
`involves a “protection wrapper” that does not, itself
`“monitor[] or intercept[] actually or potentially malicious
`
`10682004
`
`
`- 3 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`
`code operations” but instead “rel[ies] on the protection
`mechanisms of the underlying operating system:
`
`
`Protection wrappers rely on the protection
`mechanisms of the underlying operating
`system, in our case primarily file access
`control implemented by Access Control Lists
`(ACLs). …
`
`Paper 6 (POPR) at 32-33 (emphasis added, alterations in original). Thus, Patent
`
`Owner clearly argued that prior art Jensen in Ground 1 did not teach MPC because
`
`Jensen does not “itself” monitor or intercept operations and instead relies on the
`
`operating system for such monitoring or intercepting.
`
`
`
`As discussed above, the Board misapprehended the claim construction dispute
`
`between the parties and erroneously believed that the dispute was only whether MPC
`
`operates “without modifying the executable code.” See Paper 7 (Institution
`
`Decision) at 5. As a result, the Board failed to resolve the real dispute between the
`
`parties of whether the MPC must “itself” monitor or intercept or if the MPC may
`
`instead cause monitoring or intercepting by other software.
`
`10682004
`
`
`- 4 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`
`The Board must resolve this dispute under Homeland because the Board relied
`
`on the fact that prior art Jensen did not “itself” monitor or intercept as its sole reason
`
`for denying Ground 1:
`
`Thus, the protection wrapper itself does not monitor or
`intercept any operation of the program. As Jensen
`explains, the protection wrapper relies on the protection
`mechanisms of the underlying operating system.
`
`Paper 7 (Institution Decision) at 11 (emphasis added). The Board’s holding is
`
`completely unsupportable because the Board did not adopt a construction of MPC
`
`that expressly required that the MPC “itself” monitor or intercept. See Paper 7
`
`(Institution Decision) at 6.
`
`The Board should resolve the key claim construction dispute in Petitioner’s
`
`favor because Patent Owner expressly agreed that MPC does not “itself” have to
`
`monitor or intercept and could rely on other software. See Paper 6 (POPR) at 7
`
`(“Petitioner explains that its proposed ‘construction means that the MPC may work
`
`in conjunction with other software, including the operating system, in order to effect
`
`monitoring and intercepting.’ [citation] This statement is accurate…” (emphasis
`
`added)). The Petition also sets forth several additional reasons why Petitioner’s
`
`proposed construction is correct, in particular that the construction is taken verbatim
`
`10682004
`
`
`- 5 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`from the specification and was repeatedly referred to as a “definition” by the Patent
`
`Owner. See Paper 2 (Petition) at 9. The Petition also demonstrates how prior art
`
`Jensen teaches MPC under Petitioner’s proper construction of the term, which
`
`includes code that causes monitoring or intercepting by working in conjunction with
`
`other software, such as the operating system. See Paper 2 (Petition) at 25-28.
`
`Petitioner therefore respectfully requests that the Board grant rehearing and institute
`
`IPR.
`
`May 23, 2019
`
`
`
`
`
`
`
`
`
`By: /Michael R. Fleming/
` Michael R. Fleming, Reg. No. 67,933
`
`Joshua Glucoft, Reg. No. 67,696
`
`IRELL & MANELLA LLP
`
`1800 Avenue of the Stars, Ste. 900
`
`Los Angeles, CA 90067
`
`Juniper-FinjanIPRs@irell.com
`
`
`10682004
`
`
`- 6 -
`
`
`
`IPR2019-00060
`Patent No. 7,647,633
`
`
`
`
`CERTIFICATE OF SERVICE
`
`I hereby certify, pursuant to 37 C.F.R. section 42.6, that on May 23, 2019, a
`
`complete copy of PETITIONER’S REQUEST FOR REHEARING is being
`
`served, by electronic mail, as agreed to by the parties, upon the following:
`
`
`KRAMER LEVIN NAFTALIS & FRANKEL LLP
`
`James Hannah
`jhannah@kramerlevin.com
`
`Jeffrey Price
`jprice@kramerlevin.com
`
`Michael Lee
`mhlee@kramerlevin.com
`
`
`
`
`
`
`
` /Susan M. Langworthy/
` Susan M. Langworthy
`
`
`
`
`
`
`
`
`
`10682004
`
`
`- 7 -
`
`