Finjan, Inc.v.FireEye, Inc.Download PDFPatent Trial and Appeal BoardJul 10, 201513423057 (P.T.A.B. Jul. 10, 2015) Copy Citation Trials@uspto.gov Paper 39 571-272-7822 Entered: July 10, 2015 UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ FINJAN, INC., Petitioner, v. FIREEYE, INC., Patent Owner. ____________ Case IPR2014-00344 Patent 8,291,499 B2 Before BRYAN F. MOORE, LYNNE E. PETTIGREW, and FRANCES L. IPPOLITO, Administrative Patent Judges. IPPOLITO, Administrative Patent Judge. FINAL WRITTEN DECISION Inter Partes Review 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73 IPR2014-00344 Patent 8,291,499 B2 2 I. INTRODUCTION Finjan, Inc. filed a Corrected Petition (“Pet.”) on January 29, 2014, requesting an inter partes review of claims 1–30 of U.S. Patent No. 8,291,499 B2 (“the ’499 patent”). Paper 6. Patent Owner FireEye, Inc. filed a Preliminary Response (“Prelim. Resp.”) to the Petition. Paper 16. On July 21, 2014, we instituted an inter partes review of claims 1–4, 6–8, 19– 25, and 27–29 on the following grounds of unpatentability alleged in the Petition: A. Claims 1–3, 6, 8, 19, 23, 24, 27, and 29 are unpatentable under 35 U.S.C. § 103 over Kaeo1 and Venezia2; B. Claims 20 and 22 are unpatentable under 35 U.S.C. § 103 over Kaeo, Venezia, and Dunlap3; C. Claims 7, 20, and 21 are unpatentable under 35 U.S.C. § 103 over Kaeo, Venezia, and Chen4; and D. Claims 1–4, 6, 8, 19, 23–25, and 27–29 are unpatentable under 35 U.S.C. § 103 over Kaeo and Liljenstam5. 1 Merike Kaeo, Designing Network Security, Cisco Press (Nov. 2003) (Ex. 1006, “Kaeo”). 2 Paul Venezia, NetDetector Captures Intrusions, InfoWorld Issue 27 (July 14, 2003) (Ex. 1005, “Venezia”). 3 George W. Dunlap, et al., ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay, Proceeding of the 5th Symposium on Operating Systems Design and Implementation, USENIX Association (Dec. 9–11, 2002) (Ex. 1008, “Dunlap”). 4 Peter M. Chen, et al., When Virtual Is Better Than Real, Department of Electrical Engineering and Computer Science, University of Michigan (May 21, 2001) (Ex. 1009, “Chen”). IPR2014-00344 Patent 8,291,499 B2 3 Paper 17 (“Dec.”), 35. After institution of trial, Patent Owner filed a Patent Owner Response (“PO Resp.,” Paper 29) and Petitioner filed a Reply thereto (“Pet. Reply,” Paper 31). An oral argument was held on March 31, 2015. The transcript of the oral hearing has been entered into the record. Paper 36 (“Tr.”). We have jurisdiction under 35 U.S.C. § 6(c). This Final Written Decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. Petitioner has shown, by a preponderance of the evidence, that claims 1–4, 6–8, 19, 20, 22–25, and 27–29 of the ’499 patent are unpatentable. Petitioner has not shown, by a preponderance of the evidence, that claim 21 is unpatentable. A. Related Proceedings Petitioner indicates that the parties are involved in a related proceeding, Finjan, Inc. v. FireEye, Inc., No. 4:13-cv-03133-SBA, filed in the United States District Court for the Northern District of California, where Petitioner’s U.S. Patent Nos. 6,804,780; 8,079,086; 7,975,305; 8,225,408; 7,058,822; 7,647,633; and 6,154,844 are at issue. Pet. 1. Petitioner also is involved in Case IPR2014-00492, directed to U.S. Patent No. 8,171,553 B2, which shares a common disclosure with the ’499 patent. B. The ’499 Patent The ’499 patent describes an authorized activity capture or detection system that compares copied network data to at least one policy to determine 5 Michael Liljenstam, et al., Simulating Realistic Network Worm Traffic for Worm Warning System Design and Testing, Institute for Security Technology Studies, Dartmouth College (Oct. 27, 2003) (Ex. 1007, “Liljenstam”). IPR2014-00344 Patent 8,291,499 B2 4 if the copied network data has the characteristics of a computer worm. See Ex. 1001, Claim 1. If the compared network data has a characteristic of a computer worm, the system flags the compared network data for replay in an analysis environment. Id. Figure 7 of the ’499 patent is reproduced below. Figure 7 depicts an embodiment of an unauthorized activity detection system described in the ’499 patent. As shown in Figure 7, unauthorized activity detection system 700 includes source device 705, destination device 710, and tap 715, each of which is coupled to communication network 720. Id. at 26:20–22. Tap 715 is further coupled to controller 725. Id. at 26:22–23. In operation, tap 715 monitors network data and provides a copy of the network data to controller 725. Id. at 26:32–34. Figure 7 also shows controller 725, which “can be any digital device or software that receives network data from the tap 715.” Ex. 1001, 26:65– 66. “In some embodiments, controller 725 is contained within computer worm sensor 105.” Id. at 26:66–27:1. Controller 725 also may be contained IPR2014-00344 Patent 8,291,499 B2 5 within separate traffic analysis device 135 or may be a stand-alone digital device. Id. at 27:1–3. Controller 725 can comprise virtual machine pool 745, analysis environment 750, and policy engine 755. Ex. 1001, 27:3–6. “[V]irtual machine pool 745 is configured to store virtual machines [and] can be any storage capable of storing software.” Id. at 28:50–52. Additionally, “analysis environment 750 simulates transmission of the network data between the source device 705 and the destination device 710 to analyze the effects of the network data upon the destination device 710.” Id. at 28:59– 62. Policy engine 755 can identify network data as suspicious based upon policies contained within policy engine 755. Id. at 29:4–6. For example, destination device 710 can be a computer designed to attract hackers and/or worms (e.g., a “honey pot”). Id. at 29:6–9. Policy engine 755 can contain a policy to flag any network data directed to the “honey pot” as suspicious since the “honey pot” should not be receiving any legitimate network data. Id. at 29:6–13. C. Illustrative Claim Of the challenged claims, claims 1 and 19 are independent. Claim 1 is illustrative of the subject matter of the ’499 patent, and is reproduced below: 1. An unauthorized activity capture system comprising: a tap configured to copy network data from a communication network; and a controller coupled to the tap and configured to receive the copy of the network data from the tap, compare the copy of the network data to at least one policy to determine if the copy of the network data has one or more characteristics of a computer worm, flag at least a portion of the copy of the network data as suspicious by flagging the at least a portion of the copy of the network data for replay in an analysis IPR2014-00344 Patent 8,291,499 B2 6 environment based upon the determination that the at least a portion of the compared copy of the network data has one or more characteristics of a computer worm, and replay transmission of the suspicious, flagged network data copied from the communication network to a destination device. II. ANALYSIS A. Claim Construction During a review before the Board, we construe claims in an unexpired patent in accordance with the broadest reasonable interpretation in light of the specification of the patent in which they appear. 37 C.F.R. § 42.100(b); see In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1278–82 (Fed. Cir. 2015) (“Congress implicitly adopted the broadest reasonable interpretation standard in enacting the AIA,” and “the standard was properly adopted by PTO regulation.”); see also Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). Under the broadest reasonable interpretation standard, claim terms are given their ordinary and customary meaning as would be understood by one of ordinary skill in the art in the context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). An inventor may rebut that presumption by providing a definition of the term in the specification with reasonable clarity, deliberateness, and precision. In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a definition, limitations are not to be read from the specification into the claims. In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993). 1. flag or flagging (Claims 1 and 19) For the purposes of our Decision to Institute, we determined that the broadest reasonable interpretation of the terms “flag” and “flagging” is IPR2014-00344 Patent 8,291,499 B2 7 “identify” and “identifying.” Dec. 7. Neither party disputes this interpretation. Pet. 5; PO Resp. 12. Based on the complete record now before us, we discern no reason to change the interpretation; thus, we adopt our previous analysis and interpret “flag” and “flagging” to mean “identify” and “identifying,” respectively. 2. virtual machine pool (claims 7 and 21) In the Decision instituting trial, we construed “virtual machine pool” to include “any storage capable of storing one or more virtual machines.” Dec. 7–8. Patent Owner contests this construction and argues that the “notion that ‘any storage’ is a virtual machine pool would mean that any hard drive is a virtual machine pool regardless of whether it stores potential virtual machines.” PO Resp. 12 n.1. We do not agree with Patent Owner’s arguments. Our construction in the Decision to Institute does not include “any storage,” as Patent Owner suggests, but “storage capable of storing one or more virtual machines.” Dec. 7–8. This construction is consistent with the Specification, which discloses that “virtual machine pool 745 can be any storage capable of storing software” and “virtual machine pool 745 is configured to store virtual machines.” Ex. 1001, 28:50–52. Thus, under the broadest reasonable interpretation, we construe “virtual machine pool” to mean “any storage capable of storing one or more virtual machines.” 3. analysis environment (claims 1 and 19) In the Decision to Institute, we determined, based on the preliminary record, that the term “analysis environment” means “an environment in IPR2014-00344 Patent 8,291,499 B2 8 which analysis of the effect of the network data upon a destination device is performed.” Dec. 8–10. In Patent Owner’s Response, Patent Owner disagrees with our construction because it “permits an analysis environment to be a passive location or one in which a human being performs analysis.” PO Resp. 14. Patent Owner asserts that a person of ordinary skill in the art would not consider an “analysis environment” to be an environment where analysis is performed by either the analysis environment or some other actor. Id. Patent Owner adds that the “analysis environment” is described throughout the ’499 patent as an actor rather than merely a passive component enabling actions by others. Id. at 14–15 (citing Ex. 1001, 29:24–25, 30:3–4, 30:8, 31:17–19). Although the ’499 patent provides examples where analysis environment 750 “determines,” “simulates,” “can react,” or “replays,” as noted by Patent Owner in the cited sections above (Ex. 1001, 29:24–25, 30:3–4, 30:8, 31:17–19), the Specification also indicates these descriptions of analysis environment 750 are non-limiting examples that disclose “some embodiments” or “one embodiment.” Ex. 1001, 29:22–23, 29:36–37, 30:65–67. This disclosure in the Specification is consistent with the language of the challenged claims, which do not require explicitly that the analysis environment actively perform any action. For example, claim 1 requires that the recited controller “flag at least a portion of the copy of the network data as suspicious by flagging the at least a portion of the copy of the network data for replay in an analysis environment.” (Emphasis added). In claim 1, the analysis environment provides a location for replay, which does not require that the network data is replayed by the analysis IPR2014-00344 Patent 8,291,499 B2 9 environment. Further, looking back to the Specification, the ’499 patent provides that “in accordance with one embodiment of the present invention . . . the analysis environment 750 replays transmission of the network data.” Ex. 1001, 30:65–66, 31:17–18 (emphasis added). This disclosure, along with the express language of claim 1, indicates that, in the context of the ’499 patent, a distinction exists between an analysis environment that provides a location for replaying data versus an analysis environment that itself performs replay. Thus, we do not find that the recited “analysis environment” requires that the environment perform the analysis. Although claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993). Moreover, even assuming Patent Owner is correct that the ’499 patent only describes the analysis environment as actively performing analysis, claims generally are not limited to any particular embodiment disclosed in the specification, even where only a single embodiment is disclosed. Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1117 (Fed. Cir. 2004); see, e.g., Silicon Graphics, Inc. v. ATI Techs., Inc., 607 F.3d 784, 792 (Fed. Cir. 2010) (“A construing court’s reliance on the specification must not go so far as to import limitations into claims from examples or embodiments appearing only in a patent’s written description unless the specification makes clear that the patentee intends for the claims and the embodiments in the specification to be strictly coextensive.” (internal quotation marks omitted)). IPR2014-00344 Patent 8,291,499 B2 10 Accordingly, we construe “analysis environment” to mean “an environment in which analysis of the effect of the network data upon a destination device is performed.” 4. virtual switch (claim 22) In the Decision to Institute, we determined that under the broadest reasonable interpretation, the term “virtual switch” means “software that is configured to mimic the performance of a switch.” Dec. 10. The parties do not dispute this construction. PO Resp. 12; Pet. Reply 2–5. Based on the complete record now before us, we discern no reason to change the interpretation; we adopt our previous analysis for this non-disputed claim term. 5. replay transmission of the suspicious, flagged network data copied from the communication network to a destination device (claim 1); and replaying transmission of the flagged at least a portion of the compared copied network data which was copied from the communication network to a destination device (claim 19) In distinguishing the challenged claims over the asserted prior art, Patent Owner argued at the oral hearing that the replay/replaying phrases (shown above) recited in independent claims 1 and 19 require replay of data to a destination device. JUDGE IPPOLITO: Before you do, I would just like to go back to my original question about the claim construction that you are proposing for the replaying step. I just want to get on the record what exactly are you using for support for that claim construction that the replaying is done to a destination device as opposed to replaying transmission that originally was to a destination device. IPR2014-00344 Patent 8,291,499 B2 11 MR. McCOMBS: Your Honors, the only discussion in the entire specification of the patent is, when there is a replaying transmission, that it is done to a virtual machine. And that's described in the specification at column 29, line 36 through 42, and then at column 29, line 56 through 60. What is happening is the replaying, it is a simulation of a transmission where it is a virtual machine that is simulating the destination device. That’s the only time that there is any replaying done in the patent in an analysis environment to a destination device, which is a virtual machine that is simulating the original destination device. There is not a discussion of actually replaying transmission back out onto the communications network to some original destination. That is never described in the patent. Tr. 48:3–24. We understand Patent Owner’s reading of these claim phrases to be that replaying the transmission of data requires replaying the transmission to a destination device such as a virtual machine. However, we do not agree that this is the broadest reasonable interpretation of these phrases. For example, claim 19 recites “replaying transmission of . . . copied network data which was copied from the communication network to a destination device.” The term “replaying” appears logically and grammatically to apply to the term “transmission,” which immediately follows “replaying.” Further, the term “transmission” is modified by the following phrase “of the flagged at least a portion of the compared copied network data,” which describes the “transmission” as a transmission of copied network data. Claim 19 further describes the “copied network data” as that “which was copied from the communication network to a destination device.” Thus, we read the phrase “which was copied from the communication network to a destination IPR2014-00344 Patent 8,291,499 B2 12 device” as applying to “copied network data,” and not requiring that “replaying” occurs to a destination device. Similarly, we read the corresponding language in claim 1 as applying the phrase “copied from the communication network to a destination device” to the “flagged network data.” Our reading of the claim language is consistent with the disclosure of the ’499 patent. The ’499 patent uses the term “destination device” to describe original destination device 710 that receives the transmission of data from Source Device 705 via Communication Network 720. Ex. 1001, 26:18–43, 29:56–60, Figs. 7, 10. Further, the sections of the ’499 patent cited by the Patent Owner do not support Patent Owner’s proposed interpretation of these phrases. Column 29, lines 36 through 42 do not refer to a destination device. Column 29, lines 56 through 60 disclose that virtual machine 815 simulates destination device 710. In other words, the ’499 patent does not teach that virtual machine 815 is “a destination device,” but instead teaches that a virtual machine may simulate or mimic the original destination device. Ex. 1001, 29:56–60, Fig. 10. Additionally, we note that, to the extent Patent Owner contends the recited replay phrases require replay to a virtual machine, the claim language does not recite a virtual machine. 6. Other Claim Terms Patent Owner further proposes constructions for “determine” and “determination” recited in claims 1 and 19. PO Resp. 16. Nonetheless, based on the evidence of record, these terms do not require express construction for the purposes of this Decision. B. Claims 1–3, 6, 8, 19, 23, 24, 27, and 29 – Obviousness over Kaeo (Ex. 1006) and Venezia (Ex. 1005) Petitioner argues that claims 1–3, 6, 8, 19, 23, 24, 27, and 29 are IPR2014-00344 Patent 8,291,499 B2 13 unpatentable under 35 U.S.C. § 103(a) over Kaeo and Venezia. Pet. 20–60. As explained in further detail below, we have considered the arguments and evidence presented, and we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claims 1–3, 6, 8, 19, 23, 24, 27, and 29 are unpatentable over Kaeo and Venezia. 1. Relevant Legal Principles A 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; (3) the level of skill in the art; and, (4) where in evidence, so-called secondary considerations, including commercial success, long-felt but unsolved needs, failure of others, and unexpected results. Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966) (“the Graham factors”). The level of ordinary skill in the art usually is evidenced by the references themselves. See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978). For an obviousness analysis, prior art references must be “considered together with the knowledge of one of ordinary skill in the pertinent art.” In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994) (quoting In re Samour, 571 F.2d 559, 562 (CCPA 1978)). Moreover, “it is proper to take into IPR2014-00344 Patent 8,291,499 B2 14 account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom.” In re Preda, 401 F.2d 825, 826 (CCPA 1968). That is because an obviousness analysis “need not seek out precise teachings directed to the specific subject matter of the challenged claim, for a court can take account of the inferences and creative steps that a person of ordinary skill in the art would employ.” KSR, 550 U.S. at 418; see also In re Translogic Tech., Inc., 504 F.3d at 1259. 2. Level of Ordinary Skill in the Art The parties agree that a person of ordinary skill in the art would have the following education and/or experience: a recent degree in a field such as computer science or computer networking and two or more years of experience in the computer networking or computer security industry. PO Resp. 17; Ex. 1030 ¶ 33. “Alternatively, in lieu of recent formal education, a person of ordinary skill in the art would have had six or more years of relevant experience in the computer networking or computer security industry.” Id. This level of ordinary skill in the art is consistent with the ordinary skill reflected in the prior art of record, which is directed to computer networking and computer security systems. For example, Venezia and Kaeo both disclose intrusion-detection-systems. Ex. 1005; Ex. 1006. With this level of ordinary skill in mind, we now turn to the analysis of the differences between the asserted prior art references and the subject matter recited in the claims-at-issue. 3. Summary of Venezia (Ex. 1005) Venezia discloses the performance of NetDetector, an intrusion- detection-system (“IDS”). Ex. 1005, 1. Venezia states that “[r]ather than IPR2014-00344 Patent 8,291,499 B2 15 simply capturing the packet headers of monitored data streams, and examining them for possible attacks, the NetDetector stores every packet, from header to payload, in an indexed database.” Id. Venezia adds that NetDetector notifies an administrator of an attack and allows the administrator to playback or “reconstruct the attack, keystroke by keystroke, packet by packet.” Id. Venezia further indicates that NetDetector relies on Snort, an open source IDS, for intrusion detection. Id. at 2. Snort is described as being able to “monitor all traffic or a selected segment (based on filtering rules) on any given interface.” Id. Venezia also states that “it’s possible to select a specific time frame or capture and reprocess that traffic stream through the IDS engine.” Id. Venezia explains that once an attack or signature has been identified, every packet comprising that event is available. Id. 4. Summary of Kaeo (Ex. 1006) Kaeo describes various design options for network security, including intrusion detection systems based on statistical analysis and rule-based methods. Ex. 1006, 126. Kaeo indicates that the rule-based analysis method “uses rules that characterize known security attack scenarios and raise an alarm if observed activity matches any of its encoded rules.” Id. “This analysis can also detect intruders who exhibit specific patterns of behavior known to be suspicious or in violation of site security policy.” Id. Kaeo adds that most rule-based systems are user configurable so that the user can define her own rules based on her own corporate environment. Id. Kaeo also describes network intrusion detection systems with cable taps that serve as “[p]assive Ethernet taps . . . where ‘copies’ of the frames are sent to a second switch dedicated to IDS sensors.” Id. at 127, Fig. 8-2. Additionally, IPR2014-00344 Patent 8,291,499 B2 16 Kaeo teaches that “honey pots” are locations to send suspected traffic to/from an attack. The data then can be analyzed collectively to mitigate some possible attacks. Id. at 128. 5. Analysis a. Claims 1 and 19 Petitioner contends that Kaeo and Venezia teach or suggest all the limitations of independent claim 1 and its dependent claims 2, 3, 6, and 8, and independent claim 19 and its dependent claims 23, 24, 27, and 29. Pet. 20–59. We have reviewed the Petition, the Patent Owner’s Response, and Petitioner’s Reply, as well as the evidence discussed in each of those papers, and are persuaded, by a preponderance of the evidence, that claims 1 and 19 would have been obvious based on Kaeo and Venezia. Our discussion below focuses on the limitations of independent claim 1, which are illustrative and largely overlap with limitations recited in independent claim 19. However, to the extent the limitations of independent claim 19 require separate treatment, those limitations are discussed separately below. Additionally, dependent claims 2, 3, 6, 8, 23, 24, 27, and 29 are discussed in in a following section. Claim 1 is directed to an unauthorized activity capture system that includes “a tap configured to copy network data from a communication network” and “a controller coupled to the tap and configured to receive the copy of the network data from the tap.” Petitioner asserts that Kaeo’s disclosures of cable taps or a SPAN/mirror port coupled to a network intrusion detection system meet these limitations. Pet. 24 (citing Ex. 1006, 127–28). On the record before us, we are persuaded that Petitioner has shown sufficiently that Kaeo teaches these limitations. IPR2014-00344 Patent 8,291,499 B2 17 Claim 1 further recites that the controller is configured to “compare the copy of the network data to at least one policy to determine if the copy of the network data has one or more characteristics of a computer worm.” Petitioner asserts that Kaeo’s network intrusion detection system performs IDS rule-based analysis and statistical analysis, which satisfies this limitation. Pet. 29. We determine that Petitioner’s position is supported sufficiently by the record. Claim 1 additionally requires that the controller is configured to flag at least a portion of the copy of the network data as suspicious by flagging the at least a portion of the copy of the network data for replay in an analysis environment based upon the determination that the at least a portion of the compared copy of the network data has one or more characteristics of a computer worm, and replay transmission of the suspicious, flagged network data copied from the communication network to a destination device. For these limitations, Petitioner asserts that Venezia’s NetDetector “stores every packet, from header to payload, in an indexed database,” which “not only permits an administrator to be notified when an attack has occurred but also to reconstruct the attack, keystroke by keystroke, packet by packet, and determine the exact commands issued by the attacker, in addition to any files or other data that was transmitted to or from the compromised system.” Pet. 15 (citing Ex. 1005, 1). Petitioner adds that Venezia further teaches that once NetDetector has identified a particular attack or signature, every packet comprising that event is available both in raw packet form with the option to replay the session just as it was recorded. Pet. 15. Patent Owner argues that Venezia does not disclose “flagging . . . for replay” because NetDetector’s replay occurs at the option of an IPR2014-00344 Patent 8,291,499 B2 18 administrator and does not occur automatically after NetDetector identifies network data matching an attack signature. PO Resp. 19 (citing Ex. 2009 ¶ 69). Patent Owner adds that the replay decision is made by a human administrator and NetDetector does not have the ability to decide whether or not to replay data. Id. Patent Owner further argues that Venezia’s examples of replay involve data that was not identified as suspicious. Id. at 20. Specifically, there is no indication of an attack for the replay of an AIM session (Ex. 1005) or the replay discussed in the Niksun white paper (Ex. 1012).6 Id. We do not agree with Patent Owner’s arguments. First, as written, claim 1 requires “flagging . . . for replay” but does not indicate expressly that the replay occurs automatically after flagging. Further, Patent Owner has not explained sufficiently how the claim language requires automatic replay otherwise. Second, we also do not agree that the “flagging” limitation excludes a replay decision made by a human administrator. Claim 1 requires that the recited controller is configured to “flag . . . data as suspicious by flagging . . . the network data for replay.” However, claim 1 does not indicate that the controller (or any other component) must decide whether or when the replay occurs. Third, we are not persuaded that Venezia does not teach or suggest the replay of data that has been identified as suspicious. Specifically, as Petitioner argues, Venezia describes the replay of the AIM session as an example of how data is replayed once it has been recorded. This example is 6 The Petition refers Ex. 1012 (“Niksun”), titled “Network Security – NetDetector Intrusion Forensic System,” as further describing the operation of the NetDetector system disclosed in Venezia. See Pet. 31. IPR2014-00344 Patent 8,291,499 B2 19 given in the context of having first identified an attack prior to replay. Ex. 1005, 2 (“Once a particular attack or signature has been identified, every packet comprising that event is available . . . in raw packet form.”) Moreover, Petitioner points to Venezia’s teaching that an administrator can reconstruct an attack, keystroke by keystroke, packet by packet, after being notified of an attack. Pet. 15. Thus, we find that Venezia teaches that once an attack event has been identified, the data for that event is recorded such that it can be reconstructed or replayed, as described in the example of the recorded AIM session. Id. Next, Patent Owner argues that Venezia does not teach an “analysis environment” because (1) an administrator, rather than the environment, performs the analysis; and (2) Venezia’s NetDetector does not provide any ability to replay the packets to a destination device and then reconstruct or otherwise display the effect of those packets on the destination device. PO Resp. 21–22 (citing Ex. 2009 ¶ 77). As discussed, we find that the language of claim 1 does not exclude manual analysis and, further, does not require the analysis environment to perform the analysis under the broadest reasonable construction of “analysis environment.” See supra Claim Construction. Further, we do not agree that the claim term “analysis environment” requires replay to a destination device. As discussed above, we construe “analysis environment” to mean “an environment in which analysis of the effect of the network data upon a destination device is performed.” The “analysis environment” provides an environment for analyzing the effects on a destination device, but does not require that the data must be replayed to a destination device. Further, as discussed in the context of the of the claim phrase “replay transmission of IPR2014-00344 Patent 8,291,499 B2 20 the suspicious, flagged network data copied from the communication network to a destination device” (e.g., claim 1), the ’499 patent consistently describes “destination device” as the device receiving data in the original transmission, and not a separate device receiving the replayed data (e.g., virtual machine). Ex. 1001, 26:18–43, 29:56–60, Figs. 7, 10. Thus, we do not agree with Patent Owner that an “analysis environment” requires replay to a destination device. Patent Owner further asserts that Venezia’s ability to reconstruct an attack does not teach replay in an analysis environment because NetDetector’s reconstruction does not contain information about the effect of packets on a destination device after an administrator replays them. PO Resp. 23. Petitioner responds that Venezia’s ability to reconstruct an attack teaches playback or replay because the screenshot on page 1 of Exhibit 1005 shows analysis of “retrieve” operations upon a “compromised server.” Pet. Reply 7–8 (citing Ex. 1005, 1; Ex. 1031 ¶¶ 65–66). Petitioner’s declarant, Dr. Trent Jaeger, testifies that “NetDetector’s attack reconstruction screenshot . . . demonstrates that NetDetector also evaluates and shows analysis of the effects of the data (e.g., operations resulting from an attacker’s transmitted commands) upon the destination device (e.g., a compromised server).” Ex. 1031 ¶ 65. Dr. Jaeger further testifies that the screenshot on page 1 of Exhibit 1005 shows the reconstructed commands from the attacker (i.e., “User Interaction”) resulted in computer operations (“Retrieve smurf.c” and “Retrieve newones”) being executed upon a compromised server. Id. We are persuaded by Petitioner’s assertion that Venezia’s reconstruction satisfies the limitation “replay in an analysis environment.” IPR2014-00344 Patent 8,291,499 B2 21 Referring to the screenshot on page 1 of Exhibit 1005, Venezia teaches NetDetector dissects attacks and allows administrators to reconstruct them. Here we see that an attacker used FTP to pull the files ‘smurf.c’ and ‘newones’ to a compromised server. By clicking on the file names, we can even view the contents of the transmitted files. Ex. 1005, 1 (screenshot on left). Further, in describing reconstruction, Venezia teaches that NetDetector stores every packet, from header to payload, in an indexed database. This not only permits an administrator to be notified when an attack has occurred but also to reconstruct the attack, keystroke by keystroke, packet by packet, and determine the exact commands issued by the attacker, in addition to any files or other data that was transmitted to or from the compromised system. Id. (emphasis added). Additionally, with respect to claim 19, Patent Owner argues that Kaeo and Venezia fail to disclose replaying transmission of the flagged at least a portion of the compared copied network data which was copied from the communication network to a destination device to identify unauthorized activity based on playback of the flagged suspicious at least a portion of the compared copy of the network data. PO Resp. 24–25. Patent Owner asserts that the replay examples provided in Venezia and the Niksun white paper (Ex. 1012) involve replay of data that is not suspicious. Id. at 24. As Petitioner points out, Venezia discloses that attack reconstruction is based on “NetDetector’s playback capability,” and that the attack reconstruction feature is used to “determine the exact commands issued by the attacker” or identify “that an attacker used FTP to pull the files ‘smurf.c’ and ‘newones’ to a compromised server.” Pet. 18–19; Pet. Reply 8. We IPR2014-00344 Patent 8,291,499 B2 22 agree with Petitioner that this described reconstruction of the attack, such as that shown in the screenshot on page 1 of Exhibit 1005, allows an administrator to “identify unauthorized activity based on the playback of the flagged . . . data.” Next, Patent Owner argues that Petitioner has not provided a reason for why a person of ordinary skill in the art would modify Venezia to (1) flag for replay and (2) include an analysis environment. PO Resp. 25– 26. Nonetheless, Petitioner has explained sufficiently how Venezia teaches both flagging for replay and an analysis environment. Thus, Petitioner does not rely on a modification of Venezia to disclose these features. Additionally, we are persuaded that Petitioner has provided sufficient rationale to combine the teachings of Kaeo and Venezia. Pet. 26. These rationales include combining Venezia’s replay features with Kaeo’s IDS to minimize false positives in Kaeo’s IDS through further verification of suspicious packets with Venezia’s replay. Id. Accordingly, based on the evidence and arguments presented, Petitioner has shown, by a preponderance of the evidence, supported by articulated reasoning with rational underpinning, that claims 1 and 19 would have been obvious over Kaeo and Venezia. b. Claims 2, 3, 6, 8, 23, 24, 27, and 29 In addition, Petitioner provides detailed explanations of how each limitation of dependent claims 2, 3, 6, 8, 19, 23, 24, 27, and 29 is taught or suggested by the combination of Kaeo and Venezia. Pet. 36–37, 39–41, 51– 54, 58–59. These claims are discussed below. Claim 2 depends from claim 1 and claim 23 depends from claim 19. Claim 2 recites “[t]he unauthorized activity capture system of claim 1 IPR2014-00344 Patent 8,291,499 B2 23 wherein the at least one policy is configured to detect network data directed to a honey pot.” Similarly, claim 23 is directed to a policy “configured to detect network data directed to a honey pot.” Petitioner argues that Kaeo teaches these limitations because Kaeo discloses that [h]oney pots may also provide a useful tool. These are locations to send suspected traffic to/from an attack. For example, all traffic destined for a certain protocol that is known to [be] characteristic of an attack is sent to a collection host or NIDS. The data can then be collectively analyzed to mitigate some possible attacks. Pet. 36–37, 58 (citing Ex. 1006, 128). We find Petitioner’s arguments persuasive. Claim 3 depends from claim 1, and claim 24 depends from claim 19. Both dependent claims are directed to a policy “configured to detect network data directed to a device that includes trade secret data.” Petitioner asserts that Kaeo teaches trade secret assets as a part of a Site Security Policy. Pet. 37, 58 (citing Ex. 1006, 64). Petitioner’s arguments are persuasive. Claim 6 depends from claim 1, and claim 27 depends from claim 19. Both dependent claims are directed to a policy “configured to detect network data attempting to gain rights within the communication network.” Petitioner asserts that Kaeo discloses statistical analysis to “detect intruders masquerading as legitimate users.” Pet. 39, 58 (citing Ex. 1006, 126). Based on the evidence and arguments presented, Petitioner’s arguments are persuasive. Claim 8 depends from claim 1, and claim 29 depends from claim 19. Both claims additionally recite “wherein the one or more characteristics of a computer worm include being configured to duplicate itself for IPR2014-00344 Patent 8,291,499 B2 24 propagation.” Petitioner asserts that Kaeo teaches these limitations because Kaeo discloses Planning and developing procedures to handle incidents before they occur is a critical piece of any security policy…The Sapphire worm (also called Slammer[)] was the fastest computer worm in history…As the worm began spreading throughout the Internet, it doubled in size every 8.5 seconds and infected more than 90 percent of vulnerable hosts within 10 minutes.” Pet. 40–41 (citing Ex. 1006, 120–122). Petitioner’s arguments are persuasive. Accordingly, upon consideration of the Petition’s analysis and supporting evidence, the Patent Owner’s Response, Petitioner’s Reply, and the evidence and arguments presented, we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claims 2, 3, 6, 8, 23, 24, 27, and 29 would have been obvious over Kaeo and Venezia. C. Claims 20 and 22 – Obviousness over Kaeo, Venezia, and Dunlap (Ex. 1008) Petitioner argues that claims 20 and 22 are unpatentable under 35 U.S.C. § 103(a) over Kaeo, Venezia, and Dunlap. Pet. 54–58. As explained in further detail below, we have considered the arguments and evidence presented, and are persuaded that Petitioner has shown, by a preponderance of the evidence, that claims 20 and 22 would have been obvious over Kaeo, Venezia, and Dunlap. 1. Summary of Dunlap (Ex. 1008) Dunlap is an article titled “ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay.” Dunlap describes ReVirt as a post-intrusion analysis system capable of encapsulating the target system inside a virtual machine. Ex. 1008, 3. “ReVirt is able to replay the IPR2014-00344 Patent 8,291,499 B2 25 complete, instruction-by-instruction execution of the virtual machine, even if that execution depends on non-deterministic events such as interrupts and user input. An administrator can use this type of replay to answer arbitrarily detailed questions about what transpired before, during, and after an attack.” Id. “Replay can be conducted on any host with the same processor type as the original host. Replaying on a different host allows an administrator to minimize downtime for the original host.” Id. at 8. 2. Analysis Claim 20 depends from claim 19 and further recites wherein replaying the transmission of the flagged at least a portion of the compared copied network data comprises: retrieving a virtual machine configured to receive the flagged at least a portion of the compared copied network data; configuring a replayer to transmit the flagged at least a portion of the compared copied network data to the virtual machine; and performing a simulation by transmitting the flagged at least a portion of the compared copied network data to the virtual machine. For these limitations, Petitioner asserts that once Venezia’s NetDetector identifies a particular attack or signature, Dunlap’s ReVirt system can receive Venezia’s captured packets flagged for replay. Pet. 54. Petitioner explains that Dunlap’s ReVirt system uses a virtual machine called UMLinux with which ReVirt can replay the execution of a computer before, during, and after the intruder compromises the system. Id. at 23, 54; Ex. 1008, 9. Petitioner adds that Dunlap’s replay performs a simulation because it re-creates the sent data and replays the complete instruction-by- IPR2014-00344 Patent 8,291,499 B2 26 instruction execution of the virtual machine. Pet. 57. Moreover, Petitioner’s declarant, Dr. Jaeger, states that one of ordinary skill in the art would understand “[t]his simulation is demonstrated by . . . ReVirt’s . . . TUN/TAP virtual Ethernet device that emulates the network card. Thus, the transmission of flagged copied network data to the virtual machine is over an emulated or virtual network.” Ex. 1030 ¶ 269. Patent Owner argues that claims 20 and 22 would not have been obvious over Kaeo, Venezia, and Dunlap for the same reasons it argues independent claim 19 would not have been obvious over Kaeo and Venezia. PO Resp. 29. However, for the reasons discussed above, we find Petitioner has shown, by a preponderance of the evidence, that claim 19 is unpatentable over Kaeo and Venezia. Patent Owner further argues Dunlap does not teach how or why to configure ReVirt to replay data from NetDetector. PO Resp. 30. Patent Owner adds that Dunlap uses a virtual machine but does not teach how to retrieve a virtual machine configured to receive flagged data from NetDetector. Id. Petitioner explains that Dunlap teaches retrieval of a virtual machine because the “VMM module is called before and after each signal and system call to/from the virtual-machine process.” Pet. 54 (citing Ex. 1008, 4). Petitioner further asserts that Dunlap’s ReVirt is configured to replay Venezia’s captured packets because one of skill in the art would have understood how to convert data in pcap format into syslog format. Pet. 42– 43; Reply 14–15. Petitioner’s expert, Dr. Jaeger, further testifies that no technical impediment existed for Dunlap’s ReVirt to replay the Venezia’s captured packets. For example, Dunlap’s ReVirt replay logged records saved to disk in syslog format. Dunlap at IPR2014-00344 Patent 8,291,499 B2 27 7 (“Log records are added and saved to disk in a manner similar to that used by the Linux syslogd daemon.”)(FJN 1008). Similarly, Venezia also stores its captured packets to disk and can export any capture in standard pcap format. Venezia at 2 (“The internal storage of the unit I received is a JBOD (just a bunch of disks)…”)(FJN 1005); see also Venezia at 2 (“You can export any capture in standard pcap (packet capture) format…”)(FJN 1005). Notably, one of skill in art at the time understood that data in pcap format can be easily converted into syslog format. See Boubalos (FJN 1013). Thus, no technical impediment existed for Dunlap’s ReVirt to replay Venezia’s captured packets. Ex. 1030 ¶ 216. Based on the evidence and arguments presented, we find Petitioner has explained sufficiently how Dunlap teaches “retrieving a virtual machine configured to receive the flagged at least a portion of the compared copied network data.” Patent Owner further argues that Kaeo, Venezia, and Dunlap do not teach how to “configure a replayer” to transmit flagged network data to the virtual machine. PO Resp. 31–33. Patent Owner argues that Dunlap does not teach or suggest configuration of a replayer, because Dunlap’s X-proxy is not a replayer and the X-server is not a virtual machine (GUI). Id. at 32. Patent Owner explains that the purpose of the X-proxy is to act as a new X-client that sends display messages to the X-server, and that the X-server is outside the control of the ReVirt virtual machine. Id. Although we agree with Patent Owner that Dunlap discloses the X-server can be outside of a virtual machine, we note that Petitioner also explains that Dunlap states “we could move the X server into another virtual machine.” Pet. 45–46, 54–55 (referring to claim 9 discussion); see Ex. 1008, 7. Moreover, we understand Petitioner’s argument to be that the described communication features between the X-proxy and X-server teach or suggest IPR2014-00344 Patent 8,291,499 B2 28 how one of ordinary skill in the art would configure a replayer to transmit data to a virtual machine. Tr. 81:1–22. Thus, we find Petitioner has explained sufficiently how the asserted references satisfy this limitation. Patent Owner further argues that Kaeo, Venezia, and Dunlap do not teach or suggest “performing a simulation by transmitting the flagged . . . network data to the virtual machine,” because Venezia does not teach transmitting data to a virtual machine and Dunlap’s virtual machine cannot receive data from Venezia. PO Resp. 33–34. However, we find that Petitioner has explained sufficiently that Venezia discloses flagging data that could be transmitted to Dunlap’s virtual machine for performing a simulation. Pet. 54–57. Additionally, Patent Owner argues that Petitioner has provided flawed reasons for combining Dunlap, Kaeo, and Venezia. PO Resp. 36–38. Patent Owner asserts that Kaeo does not encourage integrating Network Intrusion Detection System (NIDS) and Host Intrusion Detection Systems (HIDS) functionality into a single system and Dunlap is not a HIDS. Id. at 36–37. Patent Owner further contends “the fact that ReVirt has better protection for its log files is irrelevant to the claims and does not help NetDetector, which is located on a network periphery and is not subject to the same kind of attacks.” Id. at 37. Upon consideration of the evidence and arguments, we find Petitioner’s position persuasive. Petitioner asserts that the combination of Dunlap’s virtual machine with Venezia’s replay and Kaeo’s IDS enhances the capability of each system by, for example, providing Dunlap’s HostIDS- like verification to Kaeo’s IDS and encapsulating Venezia’s replay inside a virtual machine to maintain the integrity of the compromised system. IPR2014-00344 Patent 8,291,499 B2 29 Pet. 42–43, 55 (referring to rationales for combination of applied references presented for claim 9); Pet. Reply 15. Further, Petitioner does not assert that Dunlap is a HIDS, but rather that Dunlap teaches “HostIDS-like verification of suspicious packets by providing the ability to use its replay to examine the system state in diagnosing . . . intrusion.” Pet. 42. Moreover, Petitioner does not argue Kaeo and Dunlap’s systems must be integrated into a single system. Instead, Petitioner argues one of ordinary skill in the art would understand the advantages of combining features of host and network IDSs. Pet. 42; Ex. 1006, 112 (“an effective strategy would be to use a combination of host and network IDSs”). Accordingly, we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claim 20 would have been obvious over Kaeo, Venezia, and Dunlap. For claim 22 (which depends from claim 20), Petitioner further asserts that Dunlap’s TUN/TAP virtual Ethernet device meets the limitations of a virtual switch. Pet. 57. We find Petitioner’s arguments persuasive. Thus, we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claim 22 is unpatentable over Kaeo, Venezia, and Dunlap. D. Claims 7, 20, and 21 – Obviousness over Kaeo, Venezia, and Chen (Ex. 1009) Petitioner argues that claims 7, 20, and 21 are unpatentable under 35 U.S.C. § 103(a) over Kaeo, Venezia, and Chen. Pet. 40, 54–57. As explained in further detail below, we have considered the arguments and evidence presented, and are persuaded that Petitioner has shown, by a preponderance of the evidence, that claim 7 is unpatentable over Kaeo, Venezia, and Chen. We are not persuaded of the same for claims 20 and 21. IPR2014-00344 Patent 8,291,499 B2 30 1. Summary of Chen (Ex. 1009) Chen is a position paper titled “When Virtual is Better than Real,” which proposes that “the operating system and applications currently running on a real machine should relocate into a virtual machine.” Ex. 1009, 1. Chen provides a virtual-machine structure that runs on the host machine. Id. at Fig. 1. Rather than running suspicious events on the real system, which risks compromising the system, Chen suggests safely conducting “this type of a test on a clone of the real system.” Id. at 4. Chen adds that: [v]irtual machines make it easy to clone a running system, and an intrusion preventer can use this clone to test how a suspicious input event would affect the real system. The clone can be run as a hot standby by keeping it synchronized with the real system (using primary-backup techniques), or it can be created on the fly in response to suspicious events. In either case, clones admit more powerful intrusion preventers by looking at the response of the system to the input event rather than looking only at the input event. Because clones are isolated from the real system, they also allow an intrusion preventer to run potentially destructive tests to verify the system’s health. For example, an intrusion preventer could forward a suspicious packet to a clone and see if it crashes any running processes. Or it could process suspicious input on the clone, then see if the clone still responds to shutdown commands. Id. Chen teaches that “[l]ike a network-based intrusion detector, virtual- machine-based intrusion detectors are separate from the guest operating systems and applications. Unlike network intrusion detectors, however, virtual-machine intrusion detectors can see all events occurring in the virtual machine they monitor.” Id. IPR2014-00344 Patent 8,291,499 B2 31 2. Analysis a. Claims 20 and 21 Claim 20 depends from claim 19 and further recites, inter alia, “configuring a replayer to transmit the flagged at least a portion of the compared copied network data to the virtual machine.” For this limitation, Petitioner argues that Chen teaches that “an intrusion preventer could forward a suspicious packet to a clone and see if it crashes any running processes” and cooperative logging can be used to replay data. Pet. 56 (citing Ex. 1009, 3–4; Ex. 1030 ¶¶ 327–332). Patent Owner contends that Chen’s forwarding of packets or cooperative logging does not teach or suggest configuration of a replayer. PO Resp. 43–45. Moreover, Patent Owner contends Petitioner’s arguments conflate the Chen logging server with the Chen intrusion preventer without explaining why the two can be combined. Id. Upon consideration of the evidence and arguments presented, we determine Petitioner’s arguments are not persuasive. Although Chen discloses forwarding suspicious packets to a clone, Petitioner has not explained sufficiently how forwarding packets teaches or suggests “configuring a replayer to transmit . . . data to the virtual machine.” Moreover, Petitioner does not explain how Chen’s logging disclosure (Ex. 1009, 2–3) applies to configuring a replayer. At the oral hearing, Petitioner was asked to explain its reliance on Chen for this limitation. JUDGE IPPOLITO: For Chen what are you relying on for the configuring step? I assume you are talking about claim 20 for the ’499 patent, for example. MR. HANNAH: Thank you, yes. For the configuring step it would be loading up, creating on-the-fly, in response to IPR2014-00344 Patent 8,291,499 B2 32 the suspicious events, the loading of the virtual machine. So that is retrieving a virtual machine, loading it up and then, also, causing the replay to happen is by sending those packets to the clone and watching what the clone does. So that is actually replaying the packet within the virtual environment, looking at its behavior to determine whether it crashes or not. So Chen is very descriptive in terms of how it works in terms of the virtual machine and is spot-on to what is described in the ’499 and the ’553. JUDGE IPPOLITO: Well, I recall in the petition that there was some reliance on what is described as cooperative logging, is that correct, for Chen? I want to get a better sense of how that fits into your argument. MR. HANNAH: Sure. The cooperative logging was one example of how you could have these messages sent to each other in terms of the packets, and just showing, it was showing that it can retrieve and be able to manipulate and look at network traffic in terms of packets specifically. And that’s referred to on page 8 of Chen. Tr. 33:5–34:4. We agree with Petitioner that Chen runs a virtual machine on hot standby and can create a clone of the real system “on the fly” in response to suspicious events, which allows the virtual machine to be retrieved to receive flagged data. However, we are not persuaded that the retrieval of the virtual machine teaches the step of configuring a replayer, such as Venezia’s NetDetector, to transmit data to a virtual machine. Moreover, although Petitioner points to cooperative logging as showing how messages can be sent by the Chen system, Petitioner does not explain sufficiently how the logging relates to configuring a replayer. We decline to speculate on how the cited disclosure in Chen supports Petitioner’s position. Additionally, we note that in Petitioner’s Reply, Petitioner states IPR2014-00344 Patent 8,291,499 B2 33 Patent Owner’s attorney arguments “cannot overcome the evidence supporting the Board’s decision.” Pet. Reply 13. For clarity, we reiterate that in an inter partes review, the burden is on the Petitioner to show, by a preponderance of the evidence, that a claim under review is unpatentable. Our discussion in the Decision to Institute was based on a preliminary record at that stage of the proceeding and any decision to institute review of a claim under any ground does not create a presumption of unpatentability, nor does it absolve the Petitioner of the burden ultimately to satisfy its required showing. Based on the complete record before us, we are not persuaded Petitioner has met its burden for claim 20. Accordingly, we are not persuaded that Petitioner has shown, by a preponderance of the evidence, that claim 20 would have been obvious over Kaeo, Venezia, and Chen. Claim 21 depends from claim 20. For the same reasons, we are not persuaded that Petitioner has shown claim 21 is unpatentable over Kaeo, Venezia, and Chen. b. Claim 7 Claim 7 depends from claim 1 and further recites that “the controller further comprises a virtual machine pool configured to store a virtual machine.” For claim 7, Petitioner asserts that Chen’s disclosure of running a clone as a “hot standby” or “on the fly” indicates that Chen stores a virtual machine in a virtual machine pool. Pet. 40. Petitioner’s declarant, Dr. Jaeger, adds that “[t]he ability to run a virtual machine on hot standby or on the fly in response to suspicious events meets the claimed virtual machine pool because one of skill in the art understood that at least one virtual machine had to be stored in order to perform such functionality.” Ex. 1030 IPR2014-00344 Patent 8,291,499 B2 34 ¶ 290. Petitioner further asserts that Chen teaches it was widely known to have multiple virtual machines running multiple operating systems as demonstrated by commercial products such as VMware and VirtualPC. Pet. 40 (citing Ex. 1009, 1). Additionally, Petitioner asserts that a combination with Chen would enhance Venezia’s and Kaeo’s systems by minimizing the risk of compromising the real system and reducing false positives through verification. Id. at 45; Ex. 1030 ¶ 280. Patent Owner argues that claim 7 would not have been obvious over Kaeo, Venezia, and Chen for the same reasons that independent claim 1 is non-obvious over Kaeo and Venezia. PO Resp. 38–39. However, these arguments are unpersuasive for the same reasons discussed above for claim 1. Patent Owner further argues that Petitioner has not provided sufficient reason to combine the teachings of Kaeo, Venezia, and Chen. Specifically, Patent Owner asserts that adding Chen’s virtual machine-based intrusion detection would not enhance Venezia’s replay by minimizing risk to the real system, because NetDetector and Chen operate in entirely different locations in the network which traditionally employ different security solutions. NetDetector monitors traffic for the entire network; Chen’s intrusion preventer focuses on a single host. PO Resp. 47 (citing Ex. 2009 ¶¶ 65, 116). More specifically, Patent Owner argues that the combination of Venezia and Chen raises several unanswered questions as to how a person of ordinary skill in the art would incorporate Chen’s virtual machine with Venezia’s NetDetector. PO Resp. 48–49 (citing Ex. 2009 ¶¶ 154–164). For example, Patent Owner questions (1) the implications and costs of moving Chen’s clone to “the network periphery”; (2) whether every host system IPR2014-00344 Patent 8,291,499 B2 35 needs to be virtualized and clonable at the periphery; (3) whether end host systems are protected when NetDetector “cannot block the original packets from being delivered”; (4) why the NetDetector/Chen combination would be moved to a host; and (5) whether initiating replay by a human administrator to protect a system as described by Petitioner is “really worth that price.” Id. at 48–49. Patent Owner’s arguments are based on various combinations of the references that have not been asserted by the Petitioner for claim 7. Petitioner has not argued that Chen’s clone must be added to a network periphery or that NetDetector must be physically incorporated into Chen’s system. Rather, Petitioner asserts that it would have been obvious to one of ordinary skill in the art to modify Venezia to have a controller that includes a virtual machine pool configured to store a virtual machine because Chen teaches the use of virtual machine-based intrusion detection and storage for storing multiple virtual machines. Pet. 40. Additionally, we are not persuaded by Patent Owner’s questions regarding the costs and practicality of modifying the NetDetector or Chen system as Petitioner proposes. For example, Patent Owner relies on the testimony of its declarant, Dr. Tal Garfinkel, who testifies that for the asserted combination [t]he person of skill would either need to replay traffic from the IDS to the clone, or they would need to copy the clone over to the NIDS, and then send the traffic. Both options involve significant amounts of novel engineering. If the person of skill sent flagged data to the Chen clone, they would need to modify Venezia to, at the appropriate time, permit the administrator to communicate to the Chen virtual machine monitor to make a clone of the “real” virtual machine available (we don't know how to do this without a substantial performance impact on the IPR2014-00344 Patent 8,291,499 B2 36 real destination host; it’s not even clear if this could be made practical, and certainly not with the hardware constraints present in 2003). Ex. 2009 ¶ 159. However, the mere existence of disadvantages resulting from a modification does not refute the obviousness of the modification, especially when the prior art indicates that the modification also offers an advantage. Tradeoffs regarding features, costs, manufacturability, or the like, do not necessarily prevent the combination. See Medichem, S.A. v. Rolabo, S.L., 437 F.3d 1157, 1165 (Fed. Cir. 2006) (“[A] given course of action often has simultaneous advantages and disadvantages, and this does not necessarily obviate motivation to combine.” (citations omitted)); Winner Int’l Royalty Corp. v. Wang, 202 F.3d 1340, 1349 n.8 (Fed. Cir. 2000) (“The fact that the motivating benefit comes at the expense of another benefit, however, should not nullify its use as a basis to modify the disclosure of one reference with the teachings of another. Instead, the benefits, both lost and gained, should be weighed against one another.”). Further, to the extent that Patent Owner argues the asserted references are non-enabling, we note that although “a prior art reference cannot anticipate a claimed invention if the allegedly anticipatory disclosures cited as prior art are not enabled,” In re Antor Media Corp., 689 F.3d 1282, 1289 (Fed. Cir. 2012) (citations and internal quotation marks omitted), a non- enabling reference can qualify as prior art for the purpose of determining obviousness, Symbol Techs., Inc. v. Opticon, Inc., 935 F.2d 1569, 1578 (Fed. Cir. 1991) (citations omitted); see Geo. M. Martin Co. v. Alliance Mach. Sys. Int’l LLC, 618 F.3d 1294, 1302 (Fed. Cir. 2010) (“Under an obviousness analysis, a reference need not work to qualify as prior art; it qualifies as prior art, regardless, for whatever is disclosed therein.” (citations and internal IPR2014-00344 Patent 8,291,499 B2 37 quotation marks omitted)); Beckman Instruments, Inc. v. LKB Produkter AB, 892 F.2d 1547, 1551 (Fed. Cir. 1989) (“Even if a reference discloses an inoperative device, it is prior art for all that it teaches.” (citations omitted)). Further, upon consideration of the evidence and arguments presented, we determine that Petitioner has articulated sufficient reasons for why one of ordinary skill in the art would combine the teachings of Kaeo, Venezia, and Chen. These include that the combination enhances the capability of each system to minimize the risk of compromising the real system by using a clone to test inputs, that the combination would have yielded nothing more than predictable results because Chen’s virtual machine already received network data in the form of suspicious packets, and that each prior art reference in the combination is directed towards intrusion detection and, thus, the references share a similar goal. Pet. 45. Accordingly, we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claim 7 would have been obvious over Kaeo, Venezia, and Chen. E. Claims 1–4, 6, 8, 19, 23–25, and 27–29 – Obviousness over Kaeo and Liljenstam (Ex.1007) Petitioner argues that claims 1–4, 6, 8, 19, 23–25, and 27–29 are unpatentable under 35 U.S.C. § 103(a) over Kaeo and Liljenstam. Pet. 24– 36, 41–57. As explained in further detail below, we have considered the arguments and evidence presented, and are persuaded that Petitioner has shown, by a preponderance of the evidence, that claims 1–4, 6, 8, 19, 23–25, and 27–29 are unpatentable over Kaeo and Liljenstam. 1. Summary of Liljenstam (Ex. 1007) Liljenstam discloses a worm simulation model that generates realistic input traffic for a working prototype worm detection and tracking system, IPR2014-00344 Patent 8,291,499 B2 38 the Dartmouth ICMP BCC: System/Tracking and Fusion Engine (DIB:S/TRAFEN) system. Ex. 1007, 1. Liljenstam describes the DIB:S/TRAFEN system as capable of detecting and classifying “active Internet worms in their earliest stages of propagation.” Id. at 2. To do so, the DIB:S/TRAFEN system collects copies of ICMP type 3 (ICMP-T3) unreachable messages. Id. at 4. Liljenstam explains that worms spread by randomly probing IP addresses and that “[t]his random scanning, however, will probe many unassigned IP addresses . . . that are not associated with a reachable computer.” Id. at 2. “[R]outers that receive a packet destined for an unreachable IP address will drop the packet and return an ICMP Destination Unreachable (ICMP Type 3) message to the original originator.” Id. These ICMP-T3 messages include the source and destination IP addresses. Id. To collect the ICMP-T3 messages, the DIB:S system includes a select group of participating or instrumented routers that forward all the ICMP-T3 messages that they generate to an analysis station. Ex. 1007, 2, 5, Fig. 3. Instrumented routers in the Internet send copies of ICMP-T3 messages to the DIB:S system, which correlates and analyzes the data. Id. at 5, Fig. 3. As the ICMP-T3 messages arrive at the DIB:S analysis station, they are sorted and analyzed according to the embedded source and destination addresses and ports. Id. DIB:S generates a scan alert for worm detection when a single source machine uses the same protocol to contact the same port on target machines within a certain time interval. Id. at 2. TRAFEN detects whether there is an exponential increase in the number of alerts for the same port and protocol, which most likely indicates a propagating worm. Id. Liljenstam discloses that the DIB:S/TRAFEN system performance IPR2014-00344 Patent 8,291,499 B2 39 was evaluated by feeding simulated ICMP-T3 unreachable traffic into the working DIB:S/TRAFEN prototype. Ex. 1007, 7. All packets arriving to the DIB:S system in the model are dumped to a file in binary tcpdump format. Id. at 4. Using the tcpreplay tool, the packet streams are replayed into the real DIB:S system to simulate the ICMP packets observed during the attack. Id. at 5. The system analyzes the ICMPs to identify scanning activity, and correlates that scanning activity to track worm infection. Id. 2. Analysis a. Claims 1 and 19 Below we discuss independent claim 1, which is illustrative of the subject matter of independent claim 19. Petitioner relies on Kaeo’s disclosure of cable taps and a SPAN/mirror port to teach the tap recited in claim 1. Pet. 24. Petitioner further asserts that Kaeo’s disclosure of a NIDS coupled to a SPAN or cable tap meets the limitation of “a controller coupled to the tap and configured to receive the copy of the network data from the tap.” Id. Petitioner also argues that “Kaeo’s detection of incidents using (1) IDS rule-based analysis; (2) IDS Statistical analysis; and (3) sending traffic to a honeypot if the traffic is destined for a certain protocol that is known to characteristic of an attack” meets the limitation of a controller configured to “compare the copy of the network data to at least one policy to determine if the copy of the network data has one or more characteristics of a computer worm,” recited in claim 1. Id. at 29. Based on the record, Petitioner’s arguments are persuasive. Claim 1 also requires that the controller is configured to flag at least a portion of the copy of the network data as suspicious by flagging the at least a portion of the copy of the network data for replay in an analysis environment based upon IPR2014-00344 Patent 8,291,499 B2 40 the determination that the at least a portion of the compared copy of the network data has one or more characteristics of a computer worm, and replay transmission of the suspicious, flagged network data copied from the communication network to a destination device. Petitioner asserts that Liljenstam discloses collecting copies of ICMP-T3 messages that are suspicious of worm scanning activity and organizing such packets into a binary tcpdump format to be replayed into the real DIB:S system for simulation of the ICMP packets observed during the attack. Pet. 32–33. Petitioner points to Liljenstam’s teaching that ICMP-T3 messages are collected from instrumented routers and copies of the ICMP messages are sent to the DIB:S system for analysis. Id. at 34 (citing Ex. 1007, 4–5). Petitioner also refers to Liljenstam’s described worm simulation model where all packets arriving to the DIB:S system are dumped into tcpdump format and replayed by a tcpreplay tool into the DIB:S system to simulate the ICMP packets observed during the attack. Id. Petitioner also argues adding Liljenstam’s replay to Kaeo’s system minimizes false positives “by simulating the suspicious packets observed during the attack via replay to the real DIB:S system.” Id. at 27. Patent Owner responds that the combination of Kaeo and Liljenstam does not teach or suggest an “analysis environment” because (1) Liljenstam does not teach that the DIB:S/TRAFEN system can monitor or analyze the behavior of a destination device; and (2) Liljenstam does not teach how a computer or human being uses the DIB:S/TRAFEN system to analyze the effect of network traffic on a destination device. PO Resp. 53–54. Patent Owner further argues a person of skill in the art considering Liljenstam would understand that ICMP-T3 packets do not have any meaningful effect IPR2014-00344 Patent 8,291,499 B2 41 on computer behavior. Id. at 54–55 (citing Ex. 2009 ¶ 180). Dr. Garfinkel testifies that ICMP-T3 messages simply provide notice that a host was unreachable; they do not cause a computer to behave in any unexpected or unpredictable way. Second, even if the ICMP- T3 messages could impact the behavior of a destination device, DIB:S would not be able to observe that behavior, since it only sorts the ICMP-T3 packets and looks for patterns that suggest scanning behavior. Ex. 2009 ¶ 180. Patent Owner also contends Petitioner’s expert, Dr. Jaeger, has not explained consistently what in Liljenstam teaches an “analysis environment.” In its Reply, Petitioner argues that “flagging the at least a portion of the copy of the network data for replay in an analysis environment” does not require a “meaningful effect on computer behavior.” Pet. Reply 9. Petitioner argues that a person of ordinary skill in the art would understand that Liljenstam discloses a DIB:S analysis that includes replaying (e.g., tcpreplay tool) to simulate the ICMP packets observed during the attack and that “[t]his particular worm detection system collects copies of ICMP messages generated by random scanning and tries to recognize signatures of early worm propagation by correlating the collected messages.” Id. at 10. Petitioner also asserts that Dr. Jaeger provided a range of environments in Liljenstam that satisfy an “analysis environment.” Id. at 12. Petitioner’s arguments are persuasive. First, our construction of “analysis environment” does not require the analysis environment to actively perform an analysis. Second, our construction also does not require that the “analysis environment” analyze a meaningful effect of the network data upon a destination device. Moreover, Petitioner has explained sufficiently IPR2014-00344 Patent 8,291,499 B2 42 how the DIB:S system provides an “analysis environment” for analyzing the effect of the network data upon a destination device. Pet. 32–34; see Tr. 26:4–19. In particular, Liljenstam teaches that “[u]sing the tcpreplay tool, we can then replay the packet stream into the real DIB:S system to simulate the ICMP packets observed during the attack.” Ex. 1007, 4–5. Liljenstam further discloses that the “system analyzes the ICMPs to identify scanning activity, and correlates that scanning activity to track worm infection.” Id. at 5. Patent Owner further asserts that Kaeo and Liljenstam do not teach flagging the at least a portion of the copy of the network data for replay in an analysis environment based upon the determination that the at least a portion of the compared copy of the network data has one or more characteristics of a computer worm. PO Resp. 58. Patent Owner argues that Petitioner relies on Kaeo for the determination limitation during the compare/comparing step, but relies on a completely different function in Liljenstam for the flagging limitation. Id. at 58–59. We do not agree with Patent Owner. In its Reply, Petitioner explains that the Petition shows that Liljenstam alone, as well as the combination of Liljenstam and Kaeo, disclose that flagging can be based on the claimed comparison. Pet. Reply 11. Petitioner argues that Liljenstam states that it can perform a policy comparison before sending the ICMP-T3 message to the analysis station, or that it would have been obvious for the flagging operation to utilize Kaeo’s compared copied network data teachings. Id. (citing Pet. 33–35); see Tr. 28:13–31:10. Upon consideration of the evidence and arguments of record, we find Petitioner’s assertions are persuasive. IPR2014-00344 Patent 8,291,499 B2 43 Patent Owner also argues that Petitioner’s articulated reasons for the combination of Kaeo and Liljenstam are inadequate. PO Resp. 59–60. Specifically, Patent Owner asserts that a person of skill in the art would not couple Liljenstam’s DIB:S system to a tap or span port in order to see both sides of a network conversation and to reduce false positives, because this would result in a substantial and probably overwhelming load on the link between the tap and the DIB:S station. Id. Patent Owner further asserts that because DIB:S/TRAFEN only collects ICMP-T3 host unreachable messages, it would not know what to do with any other network data that was collected from a network tap. Id. Petitioner responds that even if the combination of Kaeo and Liljenstam results in an inefficient system, the system still renders claim 1 obvious because the evidence presented establishes that adding Liljenstam’s replay to Kaeo’s system reduces false positives and adding Kaeo’s tap to Liljenstam provides better visibility of a full-duplex conversation. Pet. Reply 12–13; Pet. 27. Petitioner’s arguments are persuasive. Again, tradeoffs regarding features, costs, manufacturability, or the like, do not necessarily prevent the combination. See Medichem, 437 F.3d at 1165; Winner, 202 F.3d at 1349 n.8. Accordingly, we are persuaded that Petitioner has shown, by a preponderance of the evidence, that claims 1 and 19 would have been obvious over Kaeo and Liljenstam. b. Claims 2, 3, 6, 8, 23, 24, 27, and 29 Petitioner also provides detailed explanations of how each limitation of claims 2–4, 6, 8, 23–25, and 27–29 is taught or suggested by the combination of Kaeo and Liljenstam. Pet. 36–41, 51–54, 58–59. More IPR2014-00344 Patent 8,291,499 B2 44 specifically, Petitioner relies on the disclosure in Kaeo, discussed above in connection with the obviousness ground based on Kaeo and Venezia, to demonstrate Kaeo teaches or suggests the required limitations. As discussed above, we are persuaded by Petitioner’s arguments regarding the teachings of Kaeo. Accordingly, we determine that Petitioner has shown, by a preponderance of the evidence, that claims 2, 3, 6, 8, 23, 24, 27, and 29 would have been obvious over Kaeo and Liljenstam. c. Claims 4, 25, and 28 Claim 4 depends from claim 1, and claim 25 depends from claim 19. Both dependent claims are directed to a policy “configured to detect an identity of a device to which network data is directed.” Petitioner asserts that Liljenstam teaches this limitation because it discloses detection of a packet destined for an unreachable IP address. Pet. 38 (citing Ex. 1007, 1). Petitioner’s arguments are persuasive. Claim 28 depends from claim 19 and further recites “wherein identifying the unauthorized activity includes identifying malware associated with the network data.” Petitioner argues that Kaeo discloses malware as a type of attack or vulnerability that can be dealt with at the policy level. Pet. 49–50, 58 (referring to analysis of claim 15). Petitioner’s arguments are persuasive. Accordingly, for claims 4, 25, and 28, we determine that Petitioner has shown, by a preponderance of the evidence, that these claims would have been obvious over Kaeo and Liljenstam. III. CONCLUSION Petitioner has shown, by a preponderance of the evidence, that claims 1–4, 6–8, 19, 20, 22–25, and 27–29 of the ’499 patent are unpatentable. IPR2014-00344 Patent 8,291,499 B2 45 IV. ORDER In consideration of the foregoing, it is hereby: ORDERED that claims 1–4, 6–8, 19, 20, 22–25, and 27–29 of the ’499 patent have been shown, by a preponderance of the evidence, to be unpatentable; FURTHER ORDERED that claim 21 of the ’499 patent has not been shown by a preponderance of the evidence to be unpatentable; and FURTHER ORDERED that because this is a final written decision of the Board under 35 U.S.C. § 318(a), parties to the proceeding seeking judicial review of the decision must comply with the notice and service requirements of 37 C.F.R. § 90.2. IPR2014-00344 Patent 8,291,499 B2 46 PETITIONER: James R. Hannah Michael Lee KRAMER LEVIN NAFTALIS & FRANKEL LLP jhannah@kramerlevin.com mhlee@kramerlevin.com PATENT OWNER: David L. McCombs Thomas B. King Gregory P. Huh HAYNES AND BOONE, LLP David.mccombs.ipr@haynesboone.com ipr.thomas.king@haynesboone.com gregory.huh.ipr@haynesboone.com Copy with citationCopy as parenthetical citation