[email protected] Paper No.11 571-272-7822 Filed: April 3, 2018 UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ CISCO SYSTEMS, INC., Petitioner, v. FINJAN, INC., Patent Owner. ____________ Case IPR2017-02155 Patent 8,677,494 B2 ____________ Before ZHENYU YANG, CHARLES J. BOUDREAU, and SHEILA F. McSHANE, Administrative Patent Judges. BOUDREAU, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 37 C.F.R. § 42.108 IPR2017-02155 Patent 8,677,494 B2 I. INTRODUCTION Cisco Systems, Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) requesting inter partes review of claims 10, 11, and 14–16 of U.S. Patent No. 8,677,494 B2 (Ex. 1001, “the ’494 patent”). Pet. 1. Finjan, Inc. (“Patent Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”). With authorization from the Board, Petitioner additionally filed a Reply to Patent Owner’s Preliminary Response (Paper 8, “Reply”), to address Patent Owner’s arguments concerning application of the Board’s decision in General Plastic Industrial Co. v. Canon Kabushiki Kaisha, Case IPR2016-01357 (PTAB Sept. 6, 2017) (Paper 19), which was designated as a precedential decision after the filing of the Petition; and Patent Owner filed a Corrected Sur-reply (Paper 10, “Sur-reply”). We review the Petition under 35 U.S.C. § 314, which provides that an inter partes review may not be instituted “unless . . . there is a reasonable likelihood that the petitioner would prevail with respect to at least 1 of the claims challenged in the petition.” 35 U.S.C. § 314(a). For the reasons that follow and on this record, we are not persuaded that Petitioner demonstrates a reasonable likelihood of prevailing in showing the unpatentability of any of the challenged claims on the asserted grounds. Accordingly, we deny Petitioner’s request to institute an inter partes review. A. Related Proceedings The parties report that the ’494 patent is the subject of several district court actions, including Finjan, Inc. v. Cisco Systems, Inc., 5:17-cv-00072 (N.D. Cal. 2017). Pet. 4–5; Paper 4, 1. 2 IPR2017-02155 Patent 8,677,494 B2 Certain claims of the ’494 patent were challenged previously in petitions for inter partes review filed by Sophos, Inc. (Case IPR2015-01022), Symantec Corp. (Cases IPR2015-01892 and IPR2015-01897), Palo Alto Networks, Inc. (Case IPR2016-00159), and Blue Coat Systems, Inc. (Cases IPR2016-00890, IPR2016-01174, and IPR2016-01443). We denied the petitions in IPR2015-01022 on Sept. 24, 2015, IPR2015-01897 on February 26, 2016, and IPR2016-01443 on January 23, 2017. We instituted a trial in IPR2015-01892, to which we later joined Blue Coat as a petitioner on a motion for joinder filed in IPR2016-00890, and we issued a final written decision on March 15, 2017. We also instituted a trial in IPR2016-00159, to which we also later joined Blue Coat as a petitioner on a motion for joinder filed in IPR2016-01174, and we issued a final written decision on April 11, 2017. Both final written decisions are currently on appeal to the U.S. Court of Appeals for the Federal Circuit, in Appeal Nos. 17-2034 and 17-2543, respectively. In addition to the instant Petition, Petitioner also has filed a petition seeking inter partes review of related U.S. Patent No. 6,154,844, which also is involved in the above-referenced Finjan, Inc. v. Cisco Systems, Inc. district court action. IPR2017-02154, Paper 1. B. The ’494 Patent The ’494 patent describes protection systems and methods “capable of protecting a personal computer (‘PC’) or other persistently or even intermittently network accessible devices or processes from harmful, 3 IPR2017-02155 Patent 8,677,494 B2 undesirable, suspicious or other ‘malicious’ operations that might otherwise be effectuated by remotely operable code.” Ex. 1001, 2:51–56. “[R]emotely operable code that is protectable against can include,” for example, “downloadable application programs, Trojan horses and program code groupings, as well as software ‘components’, such as Java™ applets, ActiveX™ controls, JavaScript™/Visual Basic scripts, add-ins, etc., among others.” Id. at 2:59–64. C. Illustrative Claim Of the challenged claims, only claim 10, reproduced below, is independent. 10. A system for managing Downloadables, comprising: a receiver for receiving an incoming Downloadable; a Downloadable scanner coupled with said receiver, for deriving security profile data for the Downloadable, including a list of suspicious computer operations that may be attempted by the Downloadable; and a database manager coupled with said Downloadable scanner, for storing the Downloadable security profile data in a database. Ex. 1001, 22:7–16. 4 IPR2017-02155 Patent 8,677,494 B2 D. Asserted Grounds of Unpatentability Petitioner asserts the following grounds of unpatentability: Claims Basis References 10, 11, 14–16 § 103 Shear 1 and Kerchen 2 10, 11, 14–16 § 103 Crawford 91 3 and the knowledge of a person of ordinary skill in the art Pet. 24. Petitioner also relies on a Declaration of Dr. Paul Clark, filed as Exhibit 1003. II. DISCUSSION A. Claim Construction Based on the ’494 patent’s claim of priority from U.S. Patent Application No. 08/790,097, filed January 29, 1997, the ’494 patent expired no later than January 29, 2017. See 35 U.S.C. § 154(a)(2). In an inter partes review, we construe claims of an expired patent according to the standard applied by the district courts. See In re Rambus Inc., 694 F.3d 42, 46 (Fed. Cir. 2012). Specifically, we apply the principles set forth in Phillips v. AWH Corp., 415 F.3d 1303, 1312–17 (Fed. Cir. 2005) (en banc). 1 US 6,157,721, issued Dec. 5, 2000 (filed Aug. 12, 1996) (Ex. 1004). 2 Paul Kerchen et al., Static Analysis Virus Detection Tools for UNIX Systems, Proc. 13th Nat’l Computer Security Conf. 350 (1990) (Ex. 1019). 3 R. Crawford et al., A Testbed for Malicious Code Detection: A Synthesis of Static and Dynamic Analysis Techniques, Proc. 14th Ann. Conf. Dep’t Energy Computer Security Group (1991) (Ex. 1011). 5 IPR2017-02155 Patent 8,677,494 B2 Under that standard, the words of a claim are generally given their “ordinary and customary meaning,” which is the meaning the term would have to a person of ordinary skill at the time of the invention, in the context of the entire patent including the specification. See Phillips, 415 F.3d at 1312–13. Only those terms in controversy need to be construed, and only to the extent necessary to resolve the controversy. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999). Petitioner contends that each of the claim terms in the challenged claims should be given its plain and ordinary meaning and that no specific construction of any term is required. Pet. 11. Petitioner nonetheless addresses the phrase “a list of suspicious computer operations,” as recited in independent claim 10, “in light of arguments that Patent Owner has made in previous proceedings.” Id. Patent Owner responds to Petitioner’s arguments concerning this phrase and additionally proposes that the term “database,” which also is recited in independent claim 10, should be construed. Prelim. Resp. 4–11. 1. “a list of suspicious computer operations” Petitioner contends, in particular, that although neither the previous petitioners nor Patent Owner explicitly sought a construction of the phrase “a list of suspicious computer operations” in prior inter partes review proceedings, Patent Owner “implicitly sought a narrow claim construction in [IPR2015-01894] . . . by arguing that this element . . . excludes the identification of non-suspicious operations, code or functions in the DSP.” 6 IPR2017-02155 Patent 8,677,494 B2 Pet. 11. Petitioner points out that the Board determined in that earlier case that no terms required express construction and contends that, “[c]onsistent with [the IPR2015-01894] decision, there is no support for Patent Owner’s attempt to limit this claim term such that the DSP lists only suspicious operations.” Id. at 11–12 (citing IPR2015-01894, slip op. at 9 (PTAB Mar. 11, 2016) (Paper 7)). Petitioner further contends, “[t]he claims are written with the transitional phrase ‘comprising’ which is well recognized in patent practice to mean ‘including but not limited to,’ making improper the restrictive construction of ‘only.’” Id. at 12. Patent Owner responds that, under the Phillips standard, a “list of suspicious operations” means “a list of computer operations deemed suspicious.” Prelim. Resp. 5. Patent Owner recognizes, however, that the Board in the final written decisions in both IPR2015-01892 and IPR2016-00159 rejected that construction and determined that the correct construction of this phrase is “a list of all operations that could ever be deemed potentially hostile,” based on disclosure in the specification of the U.S. Patent No. 6,092,194, incorporated by reference in the ’494 patent, that “[t]he code scanner 325 may generate the DSP data 310 as a list of all operations in the Downloadable code which could ever be deemed potentially hostile and a list of all files to be accessed by the Downloadable code. . . .” Id. at 6–7 (quoting IPR2016-01892, slip op. at 11 (PTAB Mar. 15, 2017) (Paper 58) (quoting ’194 patent, 5:50–54)). Patent Owner asserts that the Board’s construction in those cases was erroneous, alleging, inter alia, that “every computer operation the Downloadable may attempt 7 IPR2017-02155 Patent 8,677,494 B2 would be on such a list” and that “the embodiments of the ’494 Patent describing deriving ‘a list of suspicious computer operations[’] by ‘determin[ing] whether the resolved command is suspicious’ would not result in the claimed ‘list . . . .’” Id. at 7–10. We disagree with Patent Owner’s contentions that the Board’s construction in IPR2015-01892 and IPR2016-00159 was erroneous and that such construction would exclude a preferred embodiment of the ’494 patent. See id. Regardless, because our determination not to institute trial in this proceeding does not depend on the construction of “a list of suspicious operations,” we conclude that there is no need to construe that phrase for purposes of this Decision. See Vivid Techs., Inc., 200 F.3d at 803. 2. “database” Patent Owner contends that the term “database” means “a collection of interrelated data organized according to a database schema to serve one or more applications.” Prelim. Resp. 11. Patent Owner argues that this construction has been applied by every panel of the Board that has considered this term with respect to the ’494 patent and related patents, as well as the district court in Finjan, Inc. v. Sophos, Inc., No. 14-cv-01197 (N.D. Cal. 2014), and has been agreed to by “numerous [p]etitioners considering this term in the context of the ’494 Patent and patents related thereto.” Id. (citations omitted). On this record and for purposes of this Decision, we adopt Patent Owner’s proposed construction. As Patent Owner points out (id.), this 8 IPR2017-02155 Patent 8,677,494 B2 construction was applied by the Board in prior proceedings, and it also has been adopted by the U.S. District Court for the Northern District of California in litigation involving the ’494 patent. See, e.g., Finjan, Inc. v. Sophos, Inc., No. 14-cv-01197 (Dkt. No. 73 (Claim Construction Order), 3– 7) (N.D. Cal. Mar. 2, 2015) (Ex. 2001, 3–7); Symantec Corp. v. Finjan, Inc., Case IPR2015-01892, slip op. at 16 (PTAB March 15, 2017) (Paper 58) (Ex. 2007); Palo Alto Networks, Inc. v. Finjan, Inc., Case IPR2016-00159, slip op. at 12 (PTAB Apr. 11, 2017) (Paper 50) (Ex. 2008); Sophos, Inc. v. Finjan, Inc., Case IPR2015-01022, slip op. at 9–10 (PTAB Jan. 28, 2016) (Paper 9) (Ex. 2009); Sophos, Inc. v. Finjan, Inc., Case IPR2015-00907, slip op. at 8–10 (PTAB Sept. 24, 2015) (Paper 8). We discern no reason to deviate from those previous determinations here. B. Discussion of Asserted Grounds 3. Principles of Law A patent claim is unpatentable under 35 U.S.C. § 103(a) if the differences between the claimed subject matter and the prior art are “such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). The question of obviousness is resolved on the basis of underlying factual determinations, including (1) the scope and content of the prior art; (2) any differences between the claimed subject matter and the prior art; 9 IPR2017-02155 Patent 8,677,494 B2 (3) the level of skill in the art; 4 and (4) objective evidence of nonobviousness, i.e., secondary considerations. 5 Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966). “To satisfy its burden of proving obviousness, a petitioner cannot employ mere conclusory statements. The petitioner must instead articulate specific reasoning, based on evidence of record, to support the legal conclusion of obviousness.” In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016). We analyze the asserted grounds with the principles stated above in mind. 4. Obviousness over Shear and Kerchen a. Overview of Shear Shear, titled “Systems and Methods Using Cryptography to Protect Secure Computing Environments,” is directed to protection of “[s]ecure computation environments” from “bogus or rogue load modules, executables and other data elements through use of digital signatures, seals and certificates issued by a verifying authority.” Ex. 1004, [54], [57]. Shear describes various harmful computer programs and other computer security risks, including “Trojan horses” such as computer viruses, and discloses that 4 Relying on the testimony of Dr. Clark, Petitioner proposes a definition of a person of ordinary skill in the art of the ’494 patent in the November 1996 timeframe. Pet. 12–13 (citing Ex. 1003 ¶ 22). Patent Owner does not challenge this definition. For purposes of this Decision and to the extent necessary, we adopt Petitioner’s definition. 5 Patent Owner does not contend in its Preliminary Response that any such secondary considerations are present. 10 IPR2017-02155 Patent 8,677,494 B2 “[c]omputer security risks of all sorts—including the risks from computer viruses—have increased dramatically as computers have become increasingly connected to one another over the Internet and by other means.” Id. at 1:56–2:14. Shear further discloses that “[c]omputer viruses are by no means the only computer security risk made even more significant by increased computer connectivity,” pointing out that the “download and execute” capability of the Java computer language, which “allow[s] computers to interactively and dynamically download computer program code fragments (called ‘applets’) over an electronic network such as the internet, and execute the downloaded code fragments locally,” not only “has great potential,” but also “raises significant computer security concerns.” Id. at 2:27–46. In view of such risks, Shear purports to provide “improved techniques for protecting secure computation and/or execution spaces . . . from unauthorized (and potentially harmful) load modules or other ‘executables’ or associated data.” Id. at 4:51–56. According to Shear, “[i]n accordance with one aspect provided by the present invention, one or more trusted verifying authorities validate load modules or other executables by analyzing and/or testing them.” Id. at 4:61–64. A verifying authority then “digitally ‘signs’ and ‘certifies’ those load modules or other executables it has verified.” Id. at 4:64–66. Shear explains that protected processing environments and other protected execution spaces “can be programmed or otherwise conditioned to accept only those load modules or other executables bearing a digital signature/certificate of an accredited (or 11 IPR2017-02155 Patent 8,677,494 B2 particular) verifying authority”; that “[t]amper resistant barriers may be used to protect this programming or other conditioning”; and that “[a] web of trust may stand behind a verifying authority” and “prevent[] value chain participants from conspiring to defraud other value chain participants.” Id. at 5:1–25. “In accordance with another aspect,” Shear discloses, “each load module or other executable has specifications associated with it describing the executable, its operations, content, and functions.” Id. at 5:26–29. According to Shear, A verifying authority analyzes, validates, verifies, inspects, and/or tests the load module or other executable, and compares its results with the specifications associated with the load module or other executable. A verifying authority may digitally sign or certify only those load modules or other executables having proper specifications and may include the specifications as part of the material being signed or certified. A verifying authority may instead, or in addition, selectively be given the responsibility for analyzing the load module and generating a specification for it. Such a specification could be reviewed by the load module’s originator and/or any potential users of the load module. A verifying authority may selectively be given the authority to generate an additional specification for the load module, for example by translating a formal mathematical specification to other kinds of specifications. . . . Additionally, a verifying authority may selectively be empowered to modify the specifications to make it accurate— but may refuse to sign or certify load modules or other executables that are harmful or dangerous irrespective of the accuracy of their associated specifications. The specifications 12 IPR2017-02155 Patent 8,677,494 B2 may in some instances be viewable by ultimate users or other value chain participants . . . . In accordance with another aspect provided by the present invention, an execution environment protects itself by deciding—based on digital signatures, for example—which load modules or other executables it is willing to execute. A digital signature allows the execution environment to test both the authenticity and the integrity of the load module or other executables, as well permitting a user of such executables to determine their correctness with respect to their associated specifications or other description of their behavior, if such descriptions are included in the verification process. Id. at 5:40–6:15. b. Overview of Kerchen Kerchen is an article directed to the analysis of computer programs to identify suspicious code before the code is installed on a user’s computer. Ex. 1019, 350. Kerchen discloses two “heuristic tools” for detecting computer viruses, referred to as a “detector” tool and a “filter” tool. Id. at 350–63. The detector tool examines a computer program to determine if it contains any duplicate calls to operating system services. Id. at 351. According to Kerchen, “duplicated calls might be . . . indicative of a virus that has linked itself to the program.” Id. Kerchen discloses that the detector tool first disassembles the computer program being examined and then finds all instances of code that perform some operating system service. Id. If two different pieces of code are found to include the same service calls, this condition is flagged. Id. at 351–52. 13 IPR2017-02155 Patent 8,677,494 B2 The filter tool is designed to analyze an executable computer program to identify “the files that the program could write to.” Id. at 354. Using this methodology, the filter first identifies “all open calls in the program” and then “enumerate[s] the possible filename arguments to these calls.” Id. at 354–55. “Upon being presented with the names of files that the program could write, the user could determine if the program is suspicious.” Id. at 355. In summary, according to Kerchen, the “filter tries to determine the names of all files which might be modified by the program,” and “[b]y comparing the enumeration of names and the specified restriction, the virus filter can claim the program is safe or is suspicious.” Id. at 356. c. Analysis Petitioner contends that Shear discloses the preamble and the “receiver for receiving an incoming Downloadable” recited in independent claim 10. Pet. 37–39 (citing Ex. 1003 ¶¶ 100–103). In particular, Petitioner maps Shear’s verifying authority to the recited “receiver” and Shear’s load module to the recited “incoming Downloadable.” Id. at 38 (citing Ex. 1004, 9:45–48, Fig. 2; Ex. 1003 ¶ 101). Petitioner relies on Shear in combination with Kerchen as disclosing “a Downloadable scanner coupled with said receiver, for deriving security profile data for the Downloadable,” as recited in claim 10. Id. at 39–43 (citing Ex. 1003 ¶¶ 105–110). Petitioner contends, in particular, that Shear’s “specification ‘describing the executable, its operations, content, and functions’” corresponds to the recited “security profile data,” and that Shear 14 IPR2017-02155 Patent 8,677,494 B2 discloses that its verification authority—corresponding to the recited receiver—“can generate, add to, or modify these specifications.” Id. at 39– 40 (citing Ex. 1004, 5:26–29, 5:48–50, 5:53–55, 5:61–63; Ex. 1003 ¶ 105). Petitioner further contends that “[t]o ensure ‘the specifications are both accurate and complete,’ Shear discloses that the verifying authority (receiver) uses software tools in order to determine whether the load executable is a virus or includes detectable bugs or other harmful functionality (suspicious operations).” Id. at 40–41 (citing Ex. 1003 ¶ 106; Ex. 1004, 10:12–22). According to Petitioner, “Shear describes that the verifying authority uses known tools to inspect the code and known techniques to test the load module in the preparation/verification of the specification” and a person of ordinary skill in the art (“POSA”) “would understand that Shear’s reference to the use of known tools would include a conventional scanner.” Id. at 41 (citing Ex. 1004, 10:12–31; Ex. 1003 ¶ 107). Further, Petitioner contends, “[t]o the extent Patent Owner argues that Shear does not sufficiently disclose a scanner to a POSA, Kerchen discloses that the detector tool scans a computer program (a Downloadable scanner) to determine if it contains any duplicate instances of operating system service calls (such as file operations like read and write), which would be flagged as suspicious code,” and “[i]t would have been obvious to combine the detector . . . of Kerchen with Shear.” Id. at 42 (citing Ex. 1019, 351; Ex. 1003 ¶ 108). More particularly, “[i]t would be obvious to a POSA to combine the detector disclosed in Kerchen with the verifying authority in 15 IPR2017-02155 Patent 8,677,494 B2 Shear that receives the executable in order to use a conventional technique for examining code to identify suspicious code,” “consistent with the mere reference to ‘conventional’ scanning techniques in the ’494 Patent . . . .” Id. at 43 (citing Ex. 1003 ¶ 109). Regarding the requirement in claim 10 that the security profile data “includ[es] a list of suspicious computer operations that may be attempted by the Downloadable,” Petitioner contends that “[a] POSA would have understood that both the code and the operations contained or performed in the executable are analyzed in Shear and would be identified in Shear’s specification, including well-known operations such as ‘read’, ‘write’, ‘rename’, ‘delete’, ‘open’ etc.,” and that “[a] POSA also would have understood that these operations . . . may be considered to have harmful functionality and would be identified as suspicious so that appropriate action can be taken.” Id. at 43–44 (citing Ex. 1003 ¶ 111). Further, “[t]o the extent that the Patent Owner argues that Shear does not sufficiently identify the operations that would be considered suspicious, Kerchen identifies how and why to analyze code to identify suspicious operations (as an example of ‘one or more computer-based software testing techniques and/or tools’ to be used with Shear).” Id. at 44 (citing Ex. 1004, 10:18–19; Ex. 1003 ¶ 113). Finally, regarding the recited “database manager coupled with said Downloadable scanner, for storing the Downloadable security profile data in a database,” Petitioner contends that “Shear discloses the specification 110 includes data in a number of fields of information preferably in a data file,” and “[i]n view of a POSA, it is implicit in the Shear patent that the data file 16 IPR2017-02155 Patent 8,677,494 B2 representing the specification 110 is stored in a ‘database.’” Id. at 45–46 (citing Ex. 1003 ¶¶ 114, 116). According to Petitioner, Figure 4 of Shear illustrates that “the name of the load module, the author, and the functions are all included [in] the specification 110 in an organized structure,” and “[a] POSA would have understood the corresponding data file described by Shear would also be so structured.” Id. at 46. Further, Petitioner contends, “Shear incorporates by reference the entirety of Ginter et al, 6 which explicitly discloses the use of a ‘database’ to store structured data.” Id. (citing Ex. 1:8–15; Ex. 1005, 12:21–13:10; Ex. 1003 ¶ 116). Through Ginter, Petitioner contends, “Shear . . . discloses that a ‘database manager 730 may then be used to organize, store, and retrieve the records,” and “the ‘database manager 730 may maintain the secure database 610.” Id. (citing Ex. 1005, 15:1–2, 11:14–18; Ex. 1003 ¶ 117). Moreover, “to the extent that Patent Owner argues that Shear does not sufficiently disclose that the specification is stored in a database, it would have been obvious to a POSA to modify Shear to store the generated specification in a database, consistent with the ’494 Patent specification’s admission that a database was a well-known, interchangeable store structure,” “(1) in order to preserve the structure nature of the data . . . [and] (2) [because] the use of databases was commonly used in virus detection technologies to store structured information derived from an analysis of the executable code as described in Kerchen.” Id. at 47–48 (citing Ex. 1003 ¶¶ 120–121). Petitioner concludes, 6 U.S. Patent Application No. 08/388,107, filed Feb. 13, 1995 (Ex. 1005). 17 IPR2017-02155 Patent 8,677,494 B2 “because Kerchen discloses that the output of its detector tool would be stored in a database, the combination of the teachings of Shear with the teachings of Kerchen discussed above . . . also results in satisfying the ‘storing the Downloadable security profile data in a database’ limitation.” Id. at 48 (citing Ex. 1003 ¶ 121). Patent Owner responds that Shear in view of Kerchen fails to disclose either the recited “Downloadable scanner . . . for deriving Downloadable security profile data, . . . including a list of suspicious computer operations” or the recited “database manager . . . for storing Downloadable security profile data in a database.” Prelim. Resp. 30–44. First, according to Patent Owner, Petitioner’s argument that “Shear describes that the verifying authority uses known tools to inspect the code and known techniques to test the load module in the preparation/verification of the specification” is “based on an inaccurate reading of Shear because Petitioner conflates what is provided in the specification and what Shear’s ‘verifying authority’ does with the specification and Downloadable after the specification is already generated.” Id. at 30 (quoting Pet. 41). Patent Owner contends that the portion of Shear quoted by Petitioner in support of its argument demonstrates that Shear’s “‘analyzing tool(s)’ are not used ‘in the preparation’ of the specification that Petitioner equates with the DSP, but rather to verify that a load module ‘performs as specified by its associated specifications.’” Id. at 31 (quoting Ex. 1003, 10:12–22). Thus, Patent Owner contends, “whether generated by the developer or at the verifying authority, there is no indication . . . Shear teaches a Downloadable scanner 18 IPR2017-02155 Patent 8,677,494 B2 for deriving DSP data, including a list of suspicious computer operations that may be attempted by the Downloadable.” Id. Second, Patent Owner contends “Petitioner does not attempt to construe what the term Downloadable scanner encompasses or point to any disclosure in Shear that meets such a construction.” Id. Whereas “Petitioner conclusorily states a ‘POSA would understand that Shear’s reference to the use of known tools would include a conventional scanner,” Patent Owner argues, Petitioner does not “explain how these alleged ‘known tools’ used to verify the load module qualify as a ‘Downloadable scanner.’” Id. (quoting Pet. 41). Further, notwithstanding Petitioner’s assertion that “[t]he ’494 patent acknowledges that scanners and the tools for deriving the data for the security profile were known in the art” (Pet. 41), Patent Owner contends that “[t]he ’494 Patent discloses that ‘code scanner 325 uses conventional parsing techniques to decompose the code,’ not that such a scanner or such techniques were known to be used in order to derive Downloadable security profile data for a Downloadable, let alone DSP data that includes a list of suspicious computer operations” (Prelim. Resp. 31– 32). Third, Patent Owner contends, Shear does not state that its “specification” includes a list of suspicious computer operations that may be attempted by a Downloadable, but Shear’s specification instead “simply ‘describ[es] the executable, its operations, content, and functions.’” Id. at 32 (quoting Ex. 1004, 5:26–29). In response to Petitioner’s assertion that “[a] POSA would have understood that both the code and the operations 19 IPR2017-02155 Patent 8,677,494 B2 contained or performed in the executable are analyzed in Shear and would be identified in Shear’s specification, including well-known operations such as ‘read,’ ‘write,’ ‘rename,’ ‘delete,’ ‘open,’ etc. (a list of suspicious computer operations that may be attempted by the Downloadable)” (Pet. 43), Patent Owner argues that Petitioner cites no evidence to support this assertion other than the declaration of Dr. Clark, which “merely repeats the same argument and is likewise devoid of citation to any evidence to support this point.” Prelim. Resp. 33–34 (citing Ex. 1003 ¶ 111). Further, Patent Owner contends, “[n]ot only does Shear not disclose that those operations [are] identified in its specification,” but “the inclusion of those operations in the specification [would] not mean that Shear’s specification includes a list of suspicious computer operations that may be attempted by the Downloadable.” Id. at 34. According to Patent Owner, “Kerchen also fails to cure the deficiencies of Shear at least because it also does not teach or suggest [a] downloadable scanner for deriving DSP data, including a list of suspicious computer operations that may be attempted by a Downloadable.” Id. While acknowledging that Kerchen states that its “approach involves the analysis of a program prior to installation, the analysis attempting to identify suspicious code,” Patent Owner argues that “the question to be resolved is not whether it was known in the prior art to identify suspicious code,” but instead “whether it was known to use a scanner to derive DSP data that includes a list of suspicious computer operations that may be attempted by a Downloadable and a database manager for storing the DSP data in a 20 IPR2017-02155 Patent 8,677,494 B2 database.” Id. at 35 (quoting Ex. 1019, 351). According to Patent Owner, Kerchen does not do so, but “merely ‘applies static analysis techniques to detect the presence of a virus’ without generating any DSP.” Id. (quoting Ex. 1019, 354). Thus, Patent Owner contends, “Kerchen does not disclose compiling a list of suspicious computer operations that a program might attempt or otherwise deriv[e] a DSP that includes such as list,” but “[i]n contrast, once Kerchen detects an infected program, it merely prevents that program’s installation.” Id. Further, Patent Owner contends, even if “one or more computer-based software tools” were imported into Shear from Kerchen as proposed by Petitioner, those tools would not be used to “derive a DSP that includes a list of suspicious computer operations that may be attempted by the Downloadable but to verify that the load module matches its specification.” Id. at 36 (citing Ex. 1003, 10:18–22 (stating that “one or more computer- based software testing techniques and/or tools” are used by Shear’s verifying authority “to verify that the load module performs as expected, matches specifications 110, is not a ‘virus,’ and includes no significant detectable ‘bugs’ or other harmful functionality”)). Finally, Patent Owner argues that it would not have been obvious to modify Shear and Spafford with Kerchen to arrive at the claimed invention, except as the product of impermissible hindsight. Id. at 36–39. Regarding the claimed “database manager” limitation, Patent Owner contends that although Petitioner points to disclosure in Ginter, incorporated by reference in Shear, indicating that “records” and “wrappered records” are 21 IPR2017-02155 Patent 8,677,494 B2 stored in a “database” that may be maintained by a “database manager,” “Petitioner does not explain how such ‘records’ and ‘wrappered records’ correspond in any way to the specification disclosed in Shear, which [Petitioner] contends corresponds to the claimed DSP data.” Id. at 40 (citing Pet. 46–47; Ex. 1005, 15:1–2). Patent Owner also points out that Petitioner has provided only pages 172–80, 221, 253–56, 410, 411, and 694, and Figures 10 and 11, of Ginter, depriving Patent Owner of a “reasonable opportunity to assess the evidence itself.” Id. Citing a printout from the Office’s Patent Application Information Retrieval (“PAIR”) website, indicating that Ginter was abandoned in favor of file wrapper continuation application, Patent Owner contends “[t]his lack of disclosure is egregious given that Ginter was abandoned before publication.” Id. (citing Ex. 2016). Patent Owner additionally points out that Petitioner has not adduced any evidence that Ginter was publicly available before the effective date of the ’494 patent, such that a person of ordinary skill in the art could have read Shear and Ginter as an integrated document. Id. at 40–41. Finally, Patent Owner contends that Shear and Kerchen fail to disclose a “database,” as that term has been construed in all prior inter partes review proceedings involving the ’494 patent. Id. at 41; see supra Section II.A.2. While acknowledging Shear’s disclosure of storing specifications as “a data file associated with and/or attached to the load module,” Patent Owner contends that “[a] data file is not a database,” however, and that a person of ordinary skill in the art “would understand Shear’s specification data files to indicate that Shear utilizes a ‘typical 22 IPR2017-02155 Patent 8,677,494 B2 file-processing system,’ rather than a database and database manager.” Id. at 42. Still further, Patent Owner contends, although “Petitioner suggests that a POSA would have been motivated to store the specification disclosed in Shear in a database . . . as described in Kerchen,” “Kerchen is utterly silent with respect to storing any data in a database, and Petitioner cites no evidence that Kerchen discloses storing anything in a database.” Id. at 44 (citing Pet. 47–48). We agree with Patent Owner that Petitioner has not demonstrated a reasonable likelihood of showing that the combination of Shear and Kerchen teaches or suggests either “a Downloadable scanner coupled with [a] receiver, for deriving security profile data for [a] Downloadable, including a list of suspicious computer operations that may be attempted by the Downloadable,” or “a database manager . . . for storing the Downloadable security profile data in a database.” Id. at 30–44. Whereas Petitioner identifies Shear’s verifying authority as the claimed “receiver,” Shear’s load module as the claimed “Downloadable,” and Shear’s specification as the claimed “security profile data for the Downloadable” (Pet. 37–40), Petitioner does not persuasively establish that Shear’s specification “includ[es] a list of suspicious computer operations that may be attempted by the Downloadable” or that it would have been obvious in view of Kerchen to modify Shear’s teachings such that the specification would include such a list. As Patent Owner points out, Shear’s verifying authority analyzes a load module to determine whether the specifications attached to it, if any, 23 IPR2017-02155 Patent 8,677,494 B2 are “accurate and complete,” and once the verifying authority is satisfied with load module, it affixes a “digital ‘seal of approval’ 106 to the load module.” Ex. 1004, 10:12–16, 10:55–56 (quoted in Prelim. Resp. 37). We find no indication that such a “seal of approval” includes a list of suspicious computer operations. Although Petitioner quotes portions of Shear indicating that the verifying authority itself can generate a specification or modify an existing specification for a load module (see Pet. 40 (citing Ex. 1004, 5:48–50, 5:53–55, 5:61–63)), we find no suggestion in Shear that the generated or modified specification would include a list of suspicious computer operations. Indeed, just following the last of those quoted passages, Shear expressly states that the verifying authority “may refuse to sign or certify load modules or other executables that are harmful or dangerous irrespective of the accuracy of their associated specifications.” Ex. 1004, 5:61–65; see also id. at 9:45–51 (explaining that “a verifying authority may affix a digital ‘seal of approval’ . . . to the load module” if the load module passes tests “to make sure they do what they are supposed to do and do not compromise or harm [the] system” (emphases added)). Similarly, as also quoted by Petitioner, Shear discloses that the verifying authority uses “testing techniques and/or tools” for various purposes, including “to verify that the load module performs as expected, matches specifications 110, is not a ‘virus,’ and includes no significant detectable ‘bugs’ or other harmful functionality.” Id. at 10:12–22 (quoted in Pet. 41). We understand these statements only to reinforce that Shear’s specifications are used to verify accuracy and completeness of an associated load module 24 IPR2017-02155 Patent 8,677,494 B2 and not to “list . . . suspicious computer operations that may be attempted” by them. Notwithstanding Petitioner’s assertion that “[t]o ensure ‘the specifications are both accurate and complete,’ Shear discloses that the verifying authority (receiver) uses software tools in order to determine whether the load executable is a virus or includes detectable bugs or other harmful functionality (suspicious operations)” (Pet. 40), we do not find in Shear any suggestion that any determination whether a load module is a virus or includes bugs or other harmful functionality factors into the determination whether the “specifications are accurate and complete.” Although the verifying authority may also be able to identify viruses and detect bugs and other harmful functionality, we do not discern in Shear any logical connection between those functions and the generation or modification of specifications. Indeed, Shear’s disclosures that “a verifying authority . . . may refuse to sign or certify load modules or other executables that are harmful or dangerous” (Ex. 1004, 5:61–64) and that load modules may be required to pass tests “to make sure they . . . do not compromise or harm [the] system” before receiving a “digital ‘seal of approval’” (see id. at 9:45–51) suggests just that a verifying authority may choose not to generate or modify a specification if it identifies suspicious computer operations. Accordingly, we find no teaching or suggestion that Shear’s specification “includes a list of suspicious computer operations that may be attempted” by the load module. 25 IPR2017-02155 Patent 8,677,494 B2 We also agree with Patent Owner that Kerchen does not cure the deficiencies of Shear with regard to the “list of suspicious computer operations.” See Prelim. Resp. 34–39. We are persuaded by Patent Owner’s argument that even if Kerchen’s “tools” were incorporated into Shear as proposed by Petitioner, those tools would not be used to derive a DSP that includes a list of suspicious computer operations that may be attempted by the Downloadable, but instead would be used to verify that a load module matches its specification (Prelim. Resp. 36)—or perhaps to confirm that the load module “is not a ‘virus’” (Ex. 1004, 10:18–22). Notwithstanding Petitioner’s argument—supported only by a verbatim recitation by Dr. Clark—that “[a] POSA would have understood that Shear would implement the specific details of identifying suspicious code taught by Kerchen and include the identified suspicious code when generating a specification, because doing so provides the end user with an identification of suspicious code that they may want to block from affecting their computer” (Pet. 37 (citing Ex. 1003 ¶ 98)), we find that both Shear and Kerchen distinguish the use of a specification for verification from identification of suspicious code (see, e.g., Ex. 1004, 10:18–22 (“[V]erifying authority 100 . . . preferably uses one or more computer-based software testing techniques and/or tools to verify that the load module . . . matches specifications 110, is not a ‘virus,’ and includes no significant detectable ‘bugs’ or other harmful functionality.”); Ex. 1019, 354 (“Verification entails proving a program with respect to a specification – a statement of what function the program is intended to compute. For the purpose of detecting 26 IPR2017-02155 Patent 8,677,494 B2 suspicious code, we are assuming no specification will be provided.”). In light of Shear’s and Kerchen’s teachings, we are persuaded by Patent Owner’s arguments that a person of ordinary skill in the art would not have had reason to combine Shear and Kerchen in the manner proposed by Petitioner in the absence of impermissible hindsight. See Prelim. Resp. 37– 39; see also Interconnect Planning Corp. v. Feil, 774 F.2d 1132, 1143 (Fed. Cir. 1985) (“When prior art references require selective combination by the court to render obvious a subsequent invention, there must be some reason for the combination other than the hindsight gleaned from the invention itself.”). Lastly, we agree with Patent Owner that Petitioner has not demonstrated that the combination of Shear and Kerchen teaches or suggests the recited “database manager . . . for storing Downloadable security profile data in a database.” Prelim. Resp. 39–44. We agree, in particular, that Petitioner’s reliance on Shear’s incorporation by reference of Ginter is deficient at least insofar as Petitioner does not sufficiently explain how the “records” disclosed by Ginter as being stored in a database maintained by a database manager correspond with Shear’s “specifications.” See id. at 40; see also In re Kotzab, 217 F.3d 1365, 1371 (Fed. Cir. 2000) (explaining that a finding of obviousness “cannot be predicated on the mere identification in [the prior art] of individual components of claimed limitations”). Further, notwithstanding Petitioner’s contention that “Kerchen discloses that the output of its detector tool would be stored in a database” (Pet. 48), for which Petitioner cites no evidence other than a verbatim assertion in Dr. Clark’s 27 IPR2017-02155 Patent 8,677,494 B2 declaration (compare id., with Ex. 1003 ¶ 121), we also agree with Patent Owner that Petitioner has not demonstrated that Kerchen discloses storing anything in a database. Prelim. Resp. 44. Accordingly, we are unpersuaded by Petitioner’s conclusion that such that “the combination of the teachings of Shear with the teachings of Kerchen discussed above . . . also results in satisfying the ‘storing the Downloadable security profile data in a database’ limitation.” Pet. 48. For the foregoing reasons, Petitioner has not shown that the combination of Shear and Kerchen teaches or suggests either “a Downloadable scanner coupled with [a] receiver, for deriving security profile data for [a] Downloadable, including a list of suspicious computer operations that may be attempted by the Downloadable,” or “a database manager . . . for storing the Downloadable security profile data in a database,” as recited in claim 10. Consequently, we are not persuaded that Petitioner demonstrates a reasonable likelihood that it would prevail at trial with respect to claim 10 or its dependent claims 11 and 14–16 over the asserted combination of references. 5. Obviousness over Crawford 91 and the Knowledge of a Person of Ordinary Skill in the Art a. Overview of Crawford 91 Crawford 91 describes a “Malicious Code Testbed” (“MCT”) based on static and dynamic analysis tools used in a complementary fashion to detect certain types of malicious code. Ex. 1011, 17-1. Crawford 91 discloses that the MCT “allows administrators and security analysts to check 28 IPR2017-02155 Patent 8,677,494 B2 a program before installation, thereby avoiding any damage a malicious program might inflict.” Id. According to Crawford 91, despite an “absence of a decision procedure for malicious code,” the MCT “would allow one to examine a program to ascertain whether or not it is suspicious.” Id. at 17-2. “The MCT will employ heuristics to analyze and simplify a program,” and “[a]lthough these techniques may not always succeed, they should cover all ‘tricks’ thought to be employed by malicious code.” Id. According to Crawford 91, in a first operating mode the MCT “will attempt to act as a coarse filter, identifying those programs worthy of closer examination.” Id. at 17-12. “A program will be analyzed and its properties summarized to allow the analyst to understand the possible effects of its execution.” Id. “The MCT will identify suspicious code, but it is up to the user to make the final decision regarding whether or not the code is malicious.” Id. In a second mode of operation, the MCT supports a “more detailed examination of a suspicious program,” “will investigate the exact nature of the previously identified suspicious property,” and “should assist the user in producing ‘signatures’ – static or dynamic characteristics that may aid in discovering identical or similar malicious logic in other programs.” Id. Figure 2 of Crawford 91 is reproduced below. 29 IPR2017-02155 Patent 8,677,494 B2 Figure 2, above, depicts the architecture of Crawford 91’s MCT. b. Analysis Petitioner maps Crawford 91’s MCT to the “receiver” of claim 10, alleging that Figure 2 of Crawford 91 shows that executable programs are “received by the MCT ‘before installation’ and before execution on a ‘target CPU and operating system’ (user’s computer), to ‘avoid any damage a malicious program might inflict.’” Pet. 59 (citing Ex. 1011, Abstract, 17-12, Fig. 2; Ex. 1003 ¶ 144). According to Petitioner, “Crawford 91 discloses that a computerized system MCT performs this function.” Id. at 60 (citing Ex. 1003 ¶ 145). 30 IPR2017-02155 Patent 8,677,494 B2 Petitioner further contends “Crawford 91 discloses a scanner analyzing the executable program using static and dynamic analysis techniques.” Id. (citing Ex. 1011, 17-11; Ex. 1003 ¶ 146). According to Petitioner, Crawford 91 discloses “providing a summary of the executable program (security profile data), which identifies suspicious code and indicates the operations that the executable program performs” (id. at 61–62 (citing Ex. 1011, 17-12; Ex. 1003 ¶ 147)), as well as “the well-known use of a Downloadable scanner to perform the above descried [sic] static analysis (id. at 62 (citing Ex. 1011, 17-3; Ex. 1003 ¶ 149)). Petitioner asserts that “[a] POSA would have understood the static search in the MCT is performed by a scanner” and that “the scanner needs to be operationally connected to a receiver in order to receive the executable program in order to perform the static analysis.” Id. at 63 (citing Ex. 1003 ¶¶ 150, 151). Petitioner further contends that “[t]o the extent Patent Owner argues that Crawford 91 does not disclose this relationship, it would have been obvious to a POSA to operationally connect the scanner of Crawford to the receiver of Crawford in order to perform static analysis on the executable program,” and “[s]uch a modification would be nothing more that applying routine knowledge and common sense. Id. (citing Ex. 1003 ¶ 151). With respect to the “database manager” limitation of claim 10, Petitioner contends “Crawford 91 discloses using an ‘elaborate data structure’ to store information ‘computed by either static or dynamic analysis techniques, or both’ and ‘representations of every Memory Address in a suspicious program’s code segment will be stored in a table in the 31 IPR2017-02155 Patent 8,677,494 B2 MCT,’” and “[a] POSA would have understood that the “elaborate data structure” of Crawford 91 is a database. Id. at 63–64 (citing Ex. 1011, 17-15, 17-16; Ex. 1003 ¶ 152). “As further proof of this point,” Petitioner asserts, “this elaborate data structure is called an ‘execution history database’ in Crawford 93.[7]” Id. at 64 n.2 (citing Ex. 1017, 5; Ex. 1003 ¶ 152). Further, Petitioner contends, the following disclosure of Crawford 91 “further discloses the need for the database structure”: [T]he MCT must store much more than just that string of syntax. To adequately represent even a 1-byte instruction of the original machine code, the MCT must use an elaborate data structure that will also store the original (Memory_Address, Memory_Contents) 2-tuple, along with various auxiliary fields to record dataflow and other information that may be computed by either static or dynamic analysis techniques, or both . . . Representations of every Memory_Address in a suspicious program’s code segment will be stored in a table in the MCT. Id. at 64 (quoting Ex. 1011, 17-15, 17-16; citing Ex. 1003 ¶ 153). According to Petitioner, “[a] POSA would understand that, almost by definition, the type of data structure described above would (or, at the very least, could) be stored in a database.” Id. (citing Ex. 1003 ¶ 154). Petitioner admits that “Crawford 91 does not explicitly disclose a database manager coupled to the scanner by which to store the summary,” but contends, “[a] POSA would have understood that the storage and 7 R. Crawford et al., Automated Assistance for Detecting Malicious Code, Preprint for submission to 6th Int’l Computer Security & Virus Conf. & Expo (1993) (Ex. 1017). 32 IPR2017-02155 Patent 8,677,494 B2 retrieval of data were routinely accomplished with a program operating on a computer,” which, Petitioner asserts, is a “database manager.” Id. at 65 (citing Ex. 1003 ¶ 155). According to Petitioner, “[t]o the extent that a database manager is not disclosed in Crawford 91, it would have been obvious to a POSA to use the known technique of a database manager in order to effectively manage the storage of information/data collected by the scanner of Crawford 91 to the database of Crawford 91,” and “[s]uch a modification would be nothing more than applying routine knowledge and common sense with predictable results.” Id. (citing Ex. 1003 ¶ 155). Patent Owner responds that Crawford 91 fails to disclose any element in the body of claim 10. Prelim. Resp. 45–49. First, with respect to the recited “receiver for receiving an incoming Downloadable,” Patent Owner contends that Petitioner conflates claim elements by pointing to Crawford 91’s MCT as both the “system for managing Downloadables” recited in the preamble of claim 10, as well as the recited “receiver.” Id. at 45. Moreover, Patent Owner contends, “Petitioner points to no disclosure of any receiver receiving an incoming Downloadable.” Id. at 46. Patent Owner argues that “[a]lthough Petitioner points to Figure 2 of Crawford []91, there is no indication that the executable in that Figure is ‘incoming’ from anywhere.” Id. Second, regarding the recited “Downloadable scanner,” Patent Owner contends that Crawford 91 explains that its “simple scanners” operate by “search[ing] a binary program for patterns (bit-strings) that match those of known malicious programs” and that “these scanners boast a very good 33 IPR2017-02155 Patent 8,677,494 B2 record in defending against known malicious programs but they cannot be applied in general to finding new or mutated malicious code.” Id. (quoting Ex. 1011, 17-2). Thus, Patent Owner argues, “these ‘simple scanners’ do not perform that ‘static analysis’ that Petitioner states searches the translated code and creates the summary.” Id. (citing Pet. 62). Lastly, Patent Owner contends Petitioner has failed to show that Crawford 91 discloses a “database,” as that term has been construed in all prior inter partes review proceedings involving the ’494 patent, and also has not met its burden to demonstrate that Crawford 91 discloses a “database manager for storing the DSP data in a database.” Id. at 47–48. Regarding the database, Patent Owner contends “Petitioner’s citation to Crawford 93 does not cure this deficiency because, contrary, to Petitioner’s argument, the ‘elaborate data structure’ in Crawford 91 is not ‘called an “execution history database” in Crawford 93.’” Id. at 48 (citing Pet. 64 & n.2). Rather, Patent Owner asserts, “the ‘execution history database’ records ‘events – occurrences of interesting activities during the execution of the suspicious program.” Id. (quoting Ex. 1017, 4–5). “Accordingly, these events that are recorded in the ‘execution history database’ are not the result of ‘the static search in the MCT [that Petitioner states] is performed by a scanner.’” Id. (citing Pet. 63). Regarding the “database manager,” Patent Owner argues “Petitioner only states conclusorily that ‘it would have been obvious to a POSA to use the known technique of a database manager in order to effectively manage the storage of information/data collected by the scanner of Crawford 91 to the database of Crawford 91,’” but “as demonstrated 34 IPR2017-02155 Patent 8,677,494 B2 above, Crawford 91 discloses neither a Downloadable scanner nor a database.” Id. at 48–49 (citing Pet. 65). “Moreover, this same conclusory argument was rejected by the Board in the two Final Written Decisions previously issued regarding the ‘494 Patent.” Id. at 49 (citing Ex. 2007, 50– 51). We agree with Patent Owner that Petitioner has not demonstrated a reasonable likelihood of showing that the combination of Crawford 91 with the knowledge of a person of ordinary skill in the art as of November 1996 teaches or suggests either “a receiver for receiving an incoming Downloadable” or a “database manager . . . for storing the Downloadable security profile data in a database,” as recited in claim 10. Id. at 45–49. Whereas Petitioner identifies the MCT of Crawford 91 as the claimed “receiver” and maps the executable programs illustrated in Figure 2 of Crawford 91 to the claimed “incoming Downloadable” (Pet. 59–60), we agree with Patent Owner that Petitioner does not persuasively establish that the MCT “receives” the executable programs or that the executable programs are “incoming” or “received.” Indeed, although neither party proposed a construction of the term “Downloadable” in this case, we note that Petitioner argued in its petition in IPR2017-02154, filed the same day as the instant Petition and concerning a related patent, that Downloadable should be construed as “an executable application program that is downloaded from a source computer and run on the destination computer.” IPR2017-02154, Paper 1 at 18 (emphasis added). That construction is similar to an express definition of Downloadable that is set forth in 35 IPR2017-02155 Patent 8,677,494 B2 U.S. Provisional Application No. 60/030,639 (Ex. 1021), incorporated by reference in the ’494 patent, and was adopted by the Board in IPR2015-01022, also concerning the ’494 patent. See Ex. 1021, 2:1–4 (“A Downloadable is an executable application program which is automatically downloaded from a source computer and run on the destination computer.”); IPR2015-01022, slip op. at 7 (PTAB Sept. 24, 2015) (Paper 7) (construing “Downloadable” under the broadest reasonable interpretation standard as “an executable application program which is automatically downloaded from a source computer and run on a destination computer”). Notably, Petitioner makes no persuasive showing that the executable programs analyzed in Crawford 91 are “downloaded from a source computer.” Accordingly, we are not persuaded that Crawford 91 teaches or suggests a “Downloadable” at all, let alone “a receiver for receiving an incoming Downloadable.” Moreover, Petitioner does not rely on “knowledge of a POSA” with respect to this claim element. See Pet. 59–60. Although Petitioner includes citations to Dr. Clark’s declaration, the cited testimony merely repeats verbatim Petitioner’s contentions and does not cite any evidence apart from Crawford 91. Compare id., with Ex. 1003 ¶¶ 144–145. Therefore, we are not persuaded that the combination of Crawford 91 with the knowledge of a person of ordinary skill in the art teaches or suggests “a receiver for receiving an incoming Downloadable,” as recited in claim 10. We also agree with Patent Owner that Petitioner has not adduced sufficient evidence to establish that the combination of Crawford 91 with the 36 IPR2017-02155 Patent 8,677,494 B2 knowledge of a person of ordinary skill in the art teaches or suggests a “database manager . . . for storing the Downloadable security profile data in a database.” Prelim. Resp. 47–49. We agree, in particular, that Petitioner has made no persuasive showing that the “elaborate data structure” of Crawford 91 is a “database” as that term has been construed here and in previous proceedings involving the ’494 patent, including “organiz[ation] according to a database schema to serve one or more applications.” See supra Section II.A.2; Prelim. Resp. 47–48. We also agree, for the reasons stated by Patent Owner, that Petitioner has not shown that Crawford 93 cures the deficiency. Id. at 48. Lastly, because Petitioner has not established that the combination of Crawford 91 with the knowledge of a person of ordinary skill in the art teaches or suggests a database, and because we further agree with Patent Owner that Petitioner has not otherwise identified a database manager in Crawford 91 (see id.), we conclude that Petitioner has not demonstrated that the combination of Crawford 91 with the knowledge of a person of ordinary skill in the art teaches or suggests a “database manager . . . for storing the Downloadable security profile data in a database,” as recited in claim 10. For the foregoing reasons, Petitioner has not shown that the combination of Crawford 91 with the knowledge of a person of ordinary skill in the art as of November 1996 teaches or suggests either “a receiver for receiving an incoming Downloadable” or a “database manager . . . for storing the Downloadable security profile data in a database,” as recited in claim 10. Consequently, we are not persuaded that Petitioner demonstrates a 37 IPR2017-02155 Patent 8,677,494 B2 reasonable likelihood that it would prevail at trial with respect to claim 10 or its dependent claims 11 and 14–16 over the asserted combination. C. Additional Considered Arguments Patent Owner additionally has advanced arguments that the Petition should be denied under 35 U.S.C. §§ 314(a) and 325(d) in view of prior petitions for inter partes review of the ’494 patent filed by other petitioners. Prelim. Resp. 1–2, 12–29. Patent Owner’s arguments under § 314(a) were the subject of further authorized briefing. Reply 1–5; Sur-reply 1–5. We have considered the parties’ respective arguments, but in view of our determination not to institute trial on the basis of Petitioner’s substantive grounds asserted in the Petition, we do not address those arguments further herein. III. CONCLUSION On this record, we are not persuaded that Petitioner demonstrates a reasonable likelihood that it would prevail in showing the unpatentability of any of claims 10, 11, and 14–16 of the ’494 patent on the grounds asserted in the Petition. Consequently, the Petition is denied. IV. ORDER Accordingly, it is: ORDERED that the Petitioner is denied, and no inter partes review is instituted as to any of claims 10, 11, and 14–16 of the ’494 patent. 38 IPR2017-02155 Patent 8,677,494 B2 For PETITIONER: Patrick D. McPherson Patrick Muldoon DUANE MORRIS LLP
[email protected] [email protected] For PATENT OWNER: James Hannah Jeffrey H. Price Michael Lee KRAMER LEVIN NAFTALIS & FRANKEL LLP
[email protected] [email protected] [email protected] 39