Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`
`Paper 8
`Entered: July 25, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`FINJAN, INC.,
`Petitioner,
`
`v.
`
`FIREEYE, INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00492
`Patent 8,171,553 B2
`
`
`
`Before BRYAN F. MOORE, LYNNE E. PETTIGREW, and
`FRANCES L. IPPOLITO, Administrative Patent Judges.
`
`IPPOLITO, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`571-272-7822
`
`
`
`
`
`
`
`Paper 8
`Entered: July 25, 2014
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`FINJAN, INC.,
`Petitioner,
`
`v.
`
`FIREEYE, INC.,
`Patent Owner.
`____________
`
`Case IPR2014-00492
`Patent 8,171,553 B2
`
`
`
`Before BRYAN F. MOORE, LYNNE E. PETTIGREW, and
`FRANCES L. IPPOLITO, Administrative Patent Judges.
`
`IPPOLITO, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`I. INTRODUCTION
`
`Finjan, Inc. filed a Corrected Petition (“Pet.”) on March 21, 2014,
`
`requesting an inter partes review of claims 1–30 of U.S. Patent No.
`
`8,171,553 B2 (“the ’553 patent”). Paper 4. Patent Owner FireEye, Inc. filed
`
`a Preliminary Response (“Prelim. Resp.”) to the Petition. Paper 7. We have
`
`jurisdiction under 35 U.S.C. § 314.
`
`Pursuant to 35 U.S.C. § 314, we conclude there is a reasonable
`
`likelihood that Petitioner would prevail with respect to claims 1, 3–8, 12–14,
`
`16–20, and 22–30 of the ’553 patent. Additionally, we conclude that
`
`Petitioner has not shown a reasonable likelihood that it would prevail with
`
`respect to claims 2, 9–11, 15, and 21 on the asserted grounds.
`
`A. Related Proceedings
`
`Related U.S. Patent No. 8,291,499 (“the ’499 patent”) is involved in
`
`an inter partes review designated IPR2014-00344. The ’499 patent is a
`
`continuation of the ’553 patent.
`
`B. The ’553 Patent
`
`The ’553 patent describes an authorized activity capture or detection
`
`system that analyzes copied network data with a heuristic to determine 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 ’553 patent is reproduced below.
`
`
`
`
`2
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`
`
`Figure 7 depicts an embodiment of an unauthorized activity detection system
`
`described in the ’553 patent. 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 col. 26, ll. 21–26.
`
`Tap 715 is further coupled to controller 725. Id. at col. 26, ll. 25–26. In
`
`operation, tap 715 monitors network data and provides a copy of the network
`
`data to controller 725. Id. at col. 26, ll. 35–37.
`
`Figure 7 also shows controller 725, which “can be any digital device
`
`or software that receives network data from the tap 715.” Ex. 1001, col. 27,
`
`ll. 1–2. “In some embodiments, controller 725 is contained within computer
`
`worm sensor 105.” Id. at col. 27, ll. 2–4. Controller 725 may also be
`
`contained within separate traffic analysis device 135 or may be a stand-alone
`
`digital device. Id. at col. 27, ll. 4–6. Controller 725 can comprise virtual
`
`machine pool 745, analysis environment 750, heuristic module 730, and
`
`policy engine 755. Ex. 1001, col. 27, ll. 6–9. “[V]irtual machine pool 745 is
`
`
`
`
`3
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`configured to store virtual machines [and] . . . can be any storage capable of
`
`storing software.” Id. at col. 28, ll. 51–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 col. 28, ll. 59–62.
`
`Heuristic module 730 can receive copied network data from tap 715 and
`
`apply heuristic and/or probability analysis to determine if the network data
`
`contains suspicious activity. Id. at col. 27, ll. 12–15.
`
`C. Illustrative Claim
`
`Of the challenged claims, claims 1, 8, 17, and 28 are independent.
`
`Claim 1, reproduced below, is illustrative of the subject matter of the ’553
`
`patent:
`
`1. An unauthorized activity capture system comprising:
`
`to copy network data from a
`tap configured
`a
`communication network; and
`
`a controller coupled to the tap and configured to receive
`the copy of the network data from the tap, analyze the copy of
`the network data with a heuristic 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 environment based upon
`the heuristic determination that the at least a portion of the
`analyzed 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.
`
`D. The Prior Art
`
`Petitioner relies on the following prior art:
`
`1. Peter M. Chen, et al., When Virtual Is Better Than Real,
`Department of Electrical Engineering and Computer
`
`
`
`
`4
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`Science, University of Michigan (May 21, 2001) (Ex. 1009,
`“Chen”).
`
`2. 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,
`2002) (Ex. 1008, “Dunlap”);
`
`3. Paul Venezia, NetDetector Captures Intrusions, InfoWorld
`Issue 27 (July 14, 2003) (Ex. 1005, “Venezia”);
`
`4. 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”); and
`
`5. Merike Kaeo, Designing Network Security, Cisco Press
`(Nov. 2003) (Ex. 1006, “Kaeo”).
`
`E. The Asserted Grounds
`
`Petitioner asserts that the challenged claims are unpatentable based on
`
`the following grounds:
`
`
`
`Reference[s]
`
`Basis
`
`§ 102
`
`§ 103
`
`Claims Challenged
`
`17, 22, 24, 25, 26, 28
`
`1–5, 7, 17, 21, 22, 25–28,
`30
`
`§ 103
`
`8–13, 15, 16, 18, 20, 29
`
`§ 103
`
`6, 8–14, 16, 18, 19, 29
`
`§ 103
`
`1–5, 7, 17, 21–28
`
`§ 103
`
`§ 103
`
`8–13, 15, 16, 18, 20, 29,
`30
`1–14, 16–19, 21–30
`
`Venezia
`
`Kaeo and
`Venezia
`
`Kaeo, Venezia,
`and Dunlap
`
`Kaeo, Venezia,
`and Chen
`Kaeo and
`Liljenstam
`Kaeo, Liljenstam,
`and Dunlap
`Kaeo and Chen
`
`
`
`
`5
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`II. ANALYSIS
`
`A. Claim Construction
`
`In an inter partes review, claim terms in an unexpired patent are given
`
`their broadest reasonable construction in light of the specification of the
`
`patent in which they appear. 37 C.F.R. § 42.100(b); see also Office Patent
`
`Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). Under
`
`the broadest reasonable construction 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). Any special definition for a
`
`claim term must be set forth with reasonable clarity, deliberateness, and
`
`precision. In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994).
`
`For the purposes of this decision, we construe the following terms,
`
`which we previously construed in Case IPR2014-00344:
`
`
`
`Term
`
`Broadest Reasonable
`Construction
`
`Identify
`
`Flag
`
`Virtual machine pool Any storage capable of storing
`one or more virtual machines.
`
`Analysis environment An environment in which analysis
`of the effect of the network data
`upon a destination device is
`performed.
`Software that is configured to
`mimic the performance of a
`switch.
`
`Virtual switch
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`As set forth in greater detail in the Claim Construction discussion in our
`
`Decision on Institution in Case IPR2014-00344, these constructions are
`
`
`
`
`6
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`consistent with the Specification.1 Finjan v. FireEye, IPR2014-00344, slip.
`
`op. at 6–10 (PTAB Jul. 21, 2014) (Paper 17); see also Ex. 1001, col. 28, ll.
`
`6–8, 50–55, 59–61, col. 29, ll. 54–61, col. 30, ll. 12–15.
`
`B. Claims 17, 22, 24–26, and 28 – Anticipation by Venezia (Ex. 1005)
`
`Petitioner argues that claims 17, 22, 24–26, and 28 are unpatentable
`
`under 35 U.S.C. § 102(b) over Venezia. Pet. 13–19. Upon review of the
`
`arguments and evidence presented, we conclude that Petitioner has not
`
`established a reasonable likelihood of prevailing on this ground for claims
`
`17, 22, 24–26, and 28. Below, we discuss independent claim 17, which is
`
`illustrative of claims 22, 24–26, and 28.
`
`1. 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
`
`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
`
`
`1 We note that, although the pagination may be different, the specification of
`the ’553 patent is essentially the same as the specification of the ’499 patent
`at issue in IPR2014-00344.
`
`
`
`
`7
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`signature has been identified, every packet comprising that event is
`
`available. Id.
`
`2. Analysis
`
`Independent claim 17 recites “analyzing the copied network data with
`
`a heuristic to determine if the copied network data has one or more
`
`characteristics of a computer worm.” Petitioner asserts that Venezia
`
`discloses this limitation because the Snort IDS engine can monitor a selected
`
`segment of traffic “based on filtering rules,” and “it’s possible to select a
`
`specific . . . capture and reprocess that traffic stream through the IDS
`
`engine.” Pet. 15 (citing Ex. 1005, 2). Petitioner also relies on Venezia’s
`
`disclosure of interactive graphs and Venezia’s teaching that “[o]nce a
`
`particular attack or signature has been identified, every packet comprising
`
`that event is available in raw packet form.” Id.
`
`We are not persuaded by Petitioner’s arguments. Although Petitioner
`
`has alleged that Venezia’s Snort IDS engine can limit the traffic it monitors
`
`based on filtering rules, Petitioner has not explained sufficiently how these
`
`same filtering rules are used “to determine if the copied network data has
`
`one or more characteristics of a computer worm,” as required by claim 17.
`
`Furthermore, Petitioner has not explained how Venezia’s description of
`
`selecting a specific capture meets this limitation. For example, Petitioner
`
`has not identified what it considers to be the “heuristic” disclosed by
`
`selecting a specific capture and reprocessing a traffic stream through the
`
`IDS.
`
`Further, Petitioner’s assertion that Venezia’s interactive graph teaches
`
`the recited analyzing step is not supported sufficiently by the record.
`
`Petitioner asserts that Venezia shows a graphical view where “NetDetector
`
`analyzes packets to characteristics of a worm by evaluating the IP Level
`
`
`
`
`8
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`Packet Count of the packets.” Pet. 16 (referring to a graph of a CodeRed
`
`attack on page 2 of Venezia). However, Petitioner has not explained
`
`sufficiently what packets (or how packets) are analyzed by evaluating the IP
`
`Level Packet Count for a CodeRed worm attack. Facially, Venezia indicates
`
`that the graphical view shows a CodeRed attack and the “graphs are
`
`interactive; to select the timeframe.” Ex. 1005, 2. Based on the current
`
`record, we are not persuaded that these alleged teachings of Venezia disclose
`
`an analysis of packets to CodeRed’s IP Level Packet Count, or that
`
`NetDetector performs this analysis.
`
`Additionally, Petitioner’s reliance on Venezia’s identification of an
`
`attack or signature is not persuasive because Petitioner has not explained,
`
`and the cited passage does not indicate, how the described attack was
`
`identified, whereas claim 17 requires the step of analyzing the copied
`
`network data with a heuristic to determine if the copied network data has
`
`one or more characteristics of a computer worm.
`
`Thus, Petitioner has not shown sufficiently that Venezia discloses the
`
`analyzing step required by claim 17 and its dependent claims 22 and 24–26.
`
`For the same reasons, we conclude that Petitioner has not shown sufficiently
`
`that Venezia discloses a computer readable code configured to direct a
`
`processor to “analyze the copied network data with a heuristic to determine
`
`if the copied network data has one or more characteristics of a computer
`
`worm,” which is recited in claim 28.
`
`C. Claims 1–5, 7, 17, 21, 22, 25–28, and 30 – Obviousness over Kaeo
`(Ex. 1006) and Venezia (Ex. 1005)
`
`For this ground, we have considered the arguments and evidence
`
`presented, and are persuaded that there is a reasonable likelihood that
`
`Petitioner would prevail on its assertion that claims 1, 5, 7, 17, 22, and 25–
`
`
`
`
`9
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`27 are unpatentable over Kaeo and Venezia. For claims 2–4, 21, 28, and 30
`
`we conclude that Petitioner has not established a reasonable likelihood of
`
`prevailing on the same asserted ground.
`
`1. 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, 361. 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 362, Fig. 8-2.
`
`2. Analysis
`
`a. Claims 1, 5, 7, 17, 22, and 25–27
`
`Petitioner contends that Kaeo and Venezia disclose all the limitations
`
`of claims 1, 5, 7, 17, 22, and 25–27. Pet. 20–59. Below, we discuss
`
`independent claim 1, which is illustrative of claims 5, 7, 17, 22, and 25–27
`
`challenged in this ground.
`
`Claim 1 recites “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 disclosure of cable taps or a SPAN/mirror port coupled to a network
`
`intrusion detection system meets these limitations. Pet. 30–32. On the
`
`
`
`
`10
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`record before us, we are persuaded that Petitioner has shown sufficiently that
`
`Kaeo teaches these limitations.
`
`Claim 1 further recites a controller that is configured to “analyze the
`
`copy of the network data with a heuristic to determine if the copy of the
`
`network data has one or more characteristics of a computer worm.” We are
`
`persuaded by Petitioner’s assertion that Kaeo’s disclosure of a network
`
`intrusion detection system that performs IDS rule-based analysis and
`
`statistical analysis satisfies this limitation. Pet. 33–35.
`
`Additionally, claim 1 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 heuristic determination that the at least a portion of the
`analyzed 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. 14 (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 in raw
`
`packet form with the option to replay the session just as it was recorded. Id.
`
`Patent Owner argues that NetDetector only enables post-attack
`
`
`
`
`11
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`manual analysis by enabling the administrator, and not the controller or
`
`analysis environment, to reconstruct the attack. Prelim. Resp. 17–19. We
`
`are not persuaded by Patent Owner’s arguments because 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. We
`
`also are not persuaded by Patent Owner’s assertion that Petitioner misquotes
`
`Venezia’s AIM chat session (Prelim. Resp. 20) for replay. Additionally, we
`
`are persuaded that Petitioner has provided sufficient rationale to combine the
`
`teachings of Kaeo and Venezia. Pet. 22-23.
`
`Further, Petitioner provides detailed explanations of how each
`
`limitation of claims 5, 7, 17, 22, and 25–27 is taught or suggested by the
`
`combination of Kaeo and Venezia. Pet. 42–45, 51–54, 58, 59. Thus, upon
`
`consideration of the Petition’s analysis and supporting evidence and the
`
`Preliminary Response, we are persuaded that Petitioner has demonstrated
`
`that there is a reasonable likelihood that it would prevail with respect to
`
`claims 1, 5, 7, 17, 22, and 25–27 on this ground.
`
`b. Claims 2, 3, and 21
`
`Claims 2 and 21 both recite that “the heuristic is configured to detect
`
`unknown source devices.” Claim 3 recites “the heuristic is configured to
`
`detect the network data sent to an unassigned internet protocol address.”
`
`We are not persuaded by Petitioner’s assertion that Kaeo’s disclosure of a
`
`Cisco router satisfies these limitations. See Pet. 40–41 (citing Ex. 1006,
`
`656). Petitioner has not explained sufficiently how or why one of ordinary
`
`skill in the art would have modified Kaeo’s network intrusion detection
`
`system (Ex. 1006, 360–61) with features from Kaeo’s separately described
`
`router (id. at 656). Accordingly, Petitioner has not demonstrated that there is
`
`
`
`
`12
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`a reasonable likelihood that it would prevail on its assertion that claims 2, 3,
`
`and 21 would have been obvious over Kaeo and Venezia.
`
`c. Claim 4
`
`Claim 4 depends from claim 1 and recites “the heuristic is configured
`
`to detect the network data sent to an unassigned port address.” We are not
`
`persuaded by Petitioner’s assertion that Kaeo’s firewall disclosure satisfies
`
`this limitation. Pet. 42; Prelim. Resp. 52–54. Thus, Petitioner has not
`
`demonstrated a reasonable likelihood that it would prevail on the ground that
`
`claim 4 would have been obvious over Kaeo and Venezia.
`
`d. Claims 28 and 30
`
`Additionally, we are not persuaded that Petitioner has shown
`
`sufficiently that Venezia teaches a computer readable code configured to
`
`direct a processor to “identify unauthorized activity based on playback of
`
`the flagged suspicious at least a portion of the analyzed copied network
`
`data,” required in claims 28 and 30. Specifically, Petitioner argues that
`
`Venezia’s NetDetector stores every packet to permit an administrator to
`
`reconstruct the attack and determine the exact commands issued by the
`
`attacker. Pet. 17; see also id. at 52, 60 (relying on “Ground 1” and “Ground
`
`2” analysis of claim 17). However, Petitioner has not explained sufficiently
`
`how the described human administrator teaches or suggests computer
`
`readable code that directs a processor to perform the “identify” function
`
`recited in claims 28 and 30. Thus, Petitioner has not demonstrated a
`
`reasonable likelihood that it would prevail on the ground that claims 28 and
`
`30 would have been obvious over Kaeo and Venezia.
`
`
`
`
`13
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`D. Claims 8–13, 15, 16, 18, 20, and 29 – Obviousness over Kaeo,
`Venezia, and Dunlap
`
`We have considered the arguments and evidence presented for this
`
`ground, and conclude that Petitioner has not established a reasonable
`
`likelihood of prevailing on this ground for claims 8–13, 15, and 16. For
`
`claims 18, 20, and 29, we exercise our discretion and determine that this
`
`ground is redundant to the grounds of unpatentability on which we institute
`
`inter partes review for the same claims. See infra Sections E and G.
`
`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
`
`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
`
`Petitioner argues that independent claim 8 and its dependent claims 9–
`
`13, 15, and 16 would have been obvious over Kaeo, Venezia, and Dunlap.
`
`Pet. 45–51.
`
`Independent claim 8 recites a controller configured to “identify
`
`unauthorized activity by analyzing a behavior of the virtual machine in
`
`response to the replication of the at least a portion of the analyzed copy of
`
`
`
`
`14
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`the network data.” Petitioner has not explained sufficiently how Dunlap
`
`teaches a controller configured to perform this function. Pet. 47–49. As
`
`Patent Owner points out, Dunlap indicates that the authors of the article
`
`manually stopped replay in order to diagnose the methods and effects of the
`
`intrusion. Prelim. Resp. 28–29 (citing Ex. 1008, 12). Thus, Petitioner has
`
`not demonstrated a reasonable likelihood that it would prevail on the ground
`
`that claim 8 and dependent claims 9–13, 15, and 16 would have been
`
`obvious over Kaeo, Venezia, and Dunlap.
`
`Further, as mentioned, for claims 18, 20, and 29, we exercise our
`
`discretion and determine that this ground is redundant to the grounds of
`
`unpatentability on which we institute inter partes review for the same
`
`claims. See infra Sections E and G.
`
`E. Claims 6, 8–14, 16, 18, 19, and 29 – Obviousness over Kaeo, Venezia,
`and Chen (Ex. 1009)
`
`Based on the current record, we are persuaded that there is a
`
`reasonable likelihood that Petitioner would prevail on its assertion that
`
`claims 6, 8, 12–14, 16, 18, and 19 are unpatentable over Kaeo, Venezia, and
`
`Chen. We conclude that Petitioner has not established a reasonable
`
`likelihood of prevailing on the same asserted ground for claims 9–11. For
`
`claim 29, we exercise our discretion and determine that this ground is
`
`redundant to the ground of unpatentability on which we institute inter partes
`
`review for claim 29. See infra Section G.
`
`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.
`
`
`
`
`15
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`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 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.
`
`2. Analysis
`
`a. 6, 8, 12–14, 16, 18, and 19
`
`For this ground, Petitioner asserts that Chen teaches a virtual machine
`
`or clone that can be used to test a suspicious input event. Pet. 45–46.
`
`Petitioner explains that an intrusion preventer (such as Venezia’s
`
`NetDetector) could forward a suspicious packet to a clone “and see if it
`
`crashes any running processes.” Id. at 47. Further, Petitioner contends that
`
`Chen teaches “there is no need to log message data received from computers
`
`that are themselves being logged, because these computers can be replayed
`
`to reproduce the sent message data.” Id. (citing Ex. 1009, 3). Petitioner
`
`argues that “Chen’s replay performs a simulation because the replaying is
`
`intended to reproduce the sent message data.” Id. at 57. Petitioner’s
`
`declarant, Dr. Jaeger, adds that the claimed simulation is demonstrated by
`
`“Chen’s forwarding of suspicious packets to a virtual machine that is a clone
`
`of the real system.” Ex. 1003 ¶ 327. Additionally, Petitioner points to
`
`Chen’s disclosure of running a clone as a “hot standby” or “on the fly” to
`
`meet the limitation of a “virtual machine pool” recited in claims 6 and 14.
`
`Pet. 43, 51. Petitioner further asserts that a combination with Chen would
`
`enhance Venezia’s and Kaeo’s systems by minimizing the risk of
`
`
`
`
`16
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`compromising the real system and reducing false positives through
`
`verification. Id. at 25–26; Ex. 1003 ¶¶ 277–78.
`
`Patent Owner argues that Petitioner’s ground relies on too many
`
`alternative arguments (Prelim. Resp. 32) and the combination of Chen with
`
`Kaeo and Venezia is unworkable because Kaeo and Venezia teach network
`
`intrusion detection systems and Chen is a host-based intrusion detection
`
`system (id. at 37–38). Patent Owner adds that Chen does not teach
`
`“flagging” (Prelim. Resp. 22) or a virtual machine pool (id. at 55).
`
`These arguments are unpersuasive because we understand Petitioner’s
`
`argument to be that Chen’s disclosure of a virtual machine can be used to
`
`modify Venezia’s NetDetector to replay data flagged by NetDetector. Pet.
`
`35, 43–44. We further are unpersuaded that the proposed combination
`
`would change the principle of operation of the underlying systems.
`
`Moreover, under the broadest reasonable construction of the term, “virtual
`
`machine pool,” does not require the pool to store multiple virtual machines.
`
`See supra Claim Construction.
`
`Based on the current record, we are persuaded that Petitioner has
`
`demonstrated that there is a reasonable likelihood that it would prevail on its
`
`assertion that claims 6, 8, 12–14, 16, 18, and 19 are unpatentable over Kaeo,
`
`Venezia, and Chen.
`
`b. Claim 9–11
`
`Claims 9–11 recite limitations essentially the same as those recited in
`
`claims 2–4. For the same reasons discussed above, we are not persuaded
`
`that Kaeo’s router and firewall systems disclose the claimed heuristic recited
`
`in claims 9–11. Pet. 49. Thus, Petitioner has not demonstrated a reasonable
`
`likelihood that it would prevail on the ground that claims 9–11 would have
`
`been obvious over Kaeo, Venezia, and Chen.
`
`
`
`
`17
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`c. Claim 29
`
`For claim 29, we exercise our discretion and determine that this
`
`ground is redundant to the ground of unpatentability on which we institute
`
`inter partes review for claim 29. See infra Section G.
`
`F. Claims 1–5, 7, 17, and 21–28 – Obviousness based on Kaeo and
`Liljenstam (Ex.1007)
`
`Based on the current record, we are persuaded that there is a
`
`reasonable likelihood that Petitioner would prevail on its assertion that
`
`claims 1, 3–5, 7, 17, and 22–28 are unpatentable over Kaeo and Liljenstam.
`
`For claims 2 and 21, we conclude that Petitioner has not established a
`
`reasonable likelihood of prevailing on the same asserted ground.
`
`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,
`
`the Dartmouth ICMP BCC: System/Tracking and Fusion Engine
`
`(DIB:S/TRAFEN) system. Ex. 1007, 1. The DIB:S/TRAFEN system can
`
`collect copies of ICMP type 3 (ICMP-T3) unreachable messages with a
`
`select group of participating or instrumented routers that forward all the
`
`ICMP-T3 messages that they generate to an analysis station. Id. at 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
`
`
`
`
`18
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`the same port and protocol, which most likely indicates a propagating worm.
`
`Id.
`
`Liljenstam also discloses that the DIB:S/TRAFEN system
`
`performance 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, 3–5, 7, 17, and 22–28
`
`As discussed, claim 1 requires that the recited 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 heuristic determination that the at least a portion of the
`analyzed 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 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. 36–38. Petitioner points to
`
`
`
`
`19
`
`
`
`IPR2014-00492
`Patent 8,171,553 B2
`
`Liljenstam’s collection of ICMP messages from instrumented routers and
`
`Liljenstam’s worm simulation model where 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 t
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
