Finjan, Inc.v.FireEye, Inc.

Patent Trial and Appeal Board

Jul 10, 2015

13423057 (P.T.A.B. Jul. 10, 2015)

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