Packet Intelligence LLC

Patent Trials and Appeals Board

Sep 8, 2021

IPR2020-00338 (P.T.A.B. Sep. 8, 2021)

Trials@uspto.gov Paper 48
571-272-7822 Entered: September 8, 2021

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

JUNIPER NETWORKS, INC. and PALO ALTO NETWORKS, INC.,
Petitioner,
v.
PACKET INTELLIGENCE LLC,
Patent Owner.

IPR2020-00338
Patent 6,839,751 B1

Before CHARLES J. BOUDREAU, JOHN D. HAMANN, and
KRISTI L. R. SAWERT, Administrative Patent Judges.
BOUDREAU, Administrative Patent Judge.

JUDGMENT
Final Written Decision
Determining All Challenged Claims Unpatentable
35 U.S.C. § 318(a)

IPR2020-00338
Patent 6,839,751 B1
2
I. INTRODUCTION
This is a Final Written Decision in an inter partes review challenging
the patentability of claims 1, 2, 5, 10, 14, 15, and 17 (“the challenged
claims”) of U.S. Patent No. 6,839,751 B1 (Ex. 1004, “the ’751 patent”). We
have jurisdiction under 35 U.S.C. § 6 and enter this Decision pursuant to
35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons set forth below,
we determine that Petitioner has shown, by a preponderance of the evidence,
that all of the challenged claims are unpatentable. See 35 U.S.C. § 316(e).
II. BACKGROUND
A. Procedural History
Juniper Networks, Inc. and Palo Alto Networks, Inc. (collectively
“Petitioner”) filed a Petition (Paper 3, “Pet.”) requesting inter partes review
of claims 1, 2, 5, 10, 14, 15, and 17 of the ’751 patent pursuant to 35 U.S.C.
§ 311. Petitioner supported its Petition with the Declaration of Dr. Jon B.
Weissman. Ex. 1006. Packet Intelligence LLC (“Patent Owner”) filed a
Preliminary Response. Paper 7 (“Prelim. Resp.”).1
On September 9, 2020, pursuant to 35 U.S.C. § 314(a), we instituted
trial to determine whether any challenged claim of the ’751 patent is
unpatentable based on the grounds raised in the Petition:

1 On our authorization (Paper 9), Petitioner also filed a Preliminary Reply
(Paper 10), and Patent Owner filed a Preliminary Sur-reply (Paper 11)
related to discretionary denial of institution under 35 U.S.C. § 314(a).
IPR2020-00338
Patent 6,839,751 B1
3
Claims Challenged 35 U.S.C. §2 References
1, 2, 5, 10, 14, 15, 17 103(a) Riddle,3 Ferdinand4
1, 2, 5, 10, 14, 15, 17 103(a) Riddle, Ferdinand, Yu5
1, 2, 5, 10, 14, 15, 17 103(a) Riddle, Ferdinand, RFC19456
Paper 22, 7, 56 (“Institution Decision” or “Inst. Dec.”).7
Patent Owner filed a Response. Paper 27 (“PO Resp.”). Patent
Owner supported its Response with the Declaration of Cathleen T. Quigley.
Ex. 2061. Petitioner filed a Reply to Patent Owner’s Response. Paper 31
(“Reply”). Patent Owner filed a Sur-reply. Paper 32 (“Sur-reply”).
A combined oral hearing in this proceeding, IPR2020-00339, and
IPR2020-00486, involving a related patent, was held on June 9, 2021. A
transcript of the hearing is included in the record. Paper 46 (“Tr.”). The
transcript of an oral hearing held the same day in cases IPR2020-00336 and
IPR2020-00337, also involving patents related to the ’751 patent, also is
included in the record of this proceeding.8 Paper 47.

2 The Leahy-Smith America Invents Act (“AIA”) included revisions to
35 U.S.C. § 103 that became effective on March 16, 2013. Because the
’751 patent issued from an application filed before March 16, 2013, we
apply the pre-AIA version of the statutory basis for unpatentability.
3 Riddle et al., US 6,412,000 B1 (issued June 25, 2002) (Ex. 1008).
4 Ferdinand et al., WO 92/19054 (published Oct. 29, 1992) (Ex. 1009).
5 Yu, US 6,625,150 B1 (issued Sept. 23, 2003) (Ex. 1011).
6 T. Berners-Lee et al., Hypertext Transfer Protocol -- HTTP/1.0, Request
for Comments: 1945, Network Working Group (May 1996) (Ex. 1010).
7 Patent Owner filed a Request for Rehearing of the Institution Decision
(Paper 25), which we denied (Paper 28).
8 The parties had no objection to entering into this record the transcript from
the oral hearing for IPR2020-00336 and IPR2020-00337. Tr. 5:22–6:10; see
also Paper 47, 7:15–8:5.
IPR2020-00338
Patent 6,839,751 B1
4
Following oral hearing, we ordered the parties to provide additional
briefing on the claim-construction arguments presented in the briefs and at
oral hearing. Paper 41 (“Order”). Petitioner and Patent Owner each filed
respective Opening Briefs on claim construction. See Paper 42
(“Petitioner’s Opening Brief” or “Pet. Br.”); Paper 43 (“Patent Owner’s
Opening Brief” or “PO Br.”). Petitioner filed a Responsive Brief to Patent
Owner’s Opening Brief, Paper 44 (“Petitioner’s Responsive Brief” or “Pet.
Resp. Br.”), and Patent Owner filed a Responsive Brief to Petitioner’s
Opening Brief, Paper 45 (“Patent Owner’s Responsive Brief” or “PO Resp.
Br.”).
B. Real Parties in Interest
Petitioner identifies Juniper Networks, Inc. and Palo Alto Networks,
Inc. as its real parties in interest. Pet. 1. Patent Owner identifies Packet
Intelligence LLC and Packet Intelligence Holdings LLC as its real parties in
interest. Paper 5, 2.
C. Related Matters
The parties identify two district court litigations as related matters that
involve the ’751 patent: Packet Intelligence LLC v. Juniper Networks, Inc.,
3:19-cv-04741 (N.D. Cal.) and Palo Alto Networks, Inc. v. Packet
Intelligence LLC, No. 3:19-cv-02471 (N.D. Cal). Pet. 1; Paper 5, 2. The
parties also identify Packet Intelligence LLC v. NetScout Systems, Inc., 2:16-
cv-230-JRG (E.D. Tex.) and Packet Intelligence LLC v. NetScout Sys., Inc.,
No. 19-2041 (Fed. Cir.) as related matters. Pet. 1; Paper 5, 2.
The parties also identify as related matters IPR2017-00451 and
IPR2019-01289, no longer pending before the Board, which challenged
certain claims of the ’751 patent, as well as certain other earlier proceedings
that challenged claims of various related patents. Pet. 2; Paper 5, 3–5.
IPR2020-00338
Patent 6,839,751 B1
5
D. The ’751 Patent (Ex. 1004)
The ’751 patent, titled “Re-using Information from Data Transactions
for Maintaining Statistics in Network Monitoring,” discloses a “method of
and monitor apparatus for analyzing a flow of packets passing through a
connection point on a computer network.” Ex. 1004, codes (54), (57). The
’751 patent explains that there was a need in the art for “a real-time network
monitor that can provide details as to the application programs being used.”
Id. at 1:54–59. The disclosed monitor receives packets passing in either
direction through its connection point on the network and “elucidate[s] what
application programs are associated with each packet” by extracting
information from the packet, using selected parts of the extracted
information to “build[] a signature for identifying the conversational flow of
the packet,” and performing a lookup of “a database of flow records for
previously encountered conversational flows to determine whether [the]
signature is from an existing flow.” Id. at 2:11–42, 6:5–19, Fig. 1.
Figure 3 of the ’751 patent is reproduced below.
IPR2020-00338
Patent 6,839,751 B1
6

Figure 3, above, depicts various components of network packet monitor 300,
including parser subsystem 301, analyzer subsystem 303, and database of
known flows 324. Ex. 1004, 8:47–9:2. Parser subsystem 301 “parses the
packet and determines the protocol types and associated headers for each
protocol layer that exists in the packet 302,” “extracts characteristic portions
(signature information) from the packet 302,” and builds the “unique flow
signature (also called a ‘key’) for this flow.” Id. at 9:16–10:39, 29:9–31:6
(describing an example of how the disclosed monitor builds signatures and
flow states in the context of a Sun Remote Procedure Call (RPC), where,
after all of the required processing, “KEY-2 may . . . be used to recognize
packets that are in any way associated with the application ‘a2’”), Fig. 2.
Analyzer system 303 then determines whether the packet has a
matching flow-entry in database of flows 324, and processes the packet
IPR2020-00338
Patent 6,839,751 B1
7
accordingly, including, for example, determining whether the packet belongs
to an existing conversational flow or a new (i.e., not previously encountered)
flow and, in the case of the latter, performing state processing to determine
whether the conversational flow has been “fully characterized” and should
be finalized. Ex. 1004, 10:56–13:44. The ’751 patent discloses that
[f]uture packets that are part of the same conversational flow
have their state analysis continued from a previously achieved
state. When enough packets related to an application of interest
have been processed, a final recognition state is ultimately
reached, i.e., a set of states has been traversed by state analysis
to completely characterize the conversational flow. The
signature for that final state enables each new incoming packet
of the same conversational flow to be individually recognized in
real time.
In this manner, one of the great advantages of the present
invention is realized. Once a particular set of state transitions has
been traversed for the first time and ends in a final state, a short-
cut recognition pattern—a signature—an [sic] be generated that
will key on every new incoming packet that relates to the
conversational flow. Checking a signature involves a simple
operation, allowing high packet rates to be successfully
monitored on the network.
Id. at 13:11–27.
E. The Challenged Claims
Petitioner challenges claims 1, 2, 5, 10, 14, 15, and 17 of the
’751 patent, of which claims 1 and 17 are independent. Pet. 7. Claim 1,
reproduced below, illustrates the claimed subject matter.
1. A method of analyzing a flow of packets passing through a
connection point on a computer network, the method comprising:
(a) receiving a packet from a packet acquisition device
coupled to the connection point;
(b) for each received packet, looking up a flow-entry
database for containing one or more flow-entries for
IPR2020-00338
Patent 6,839,751 B1
8
previously encountered conversational flows, the looking
up to determine if the received packet is of an existing
flow, a conversational flow including an exchange of a
sequence of one or more packets in any direction between
two network entities as a result of a particular activity
using a particular layered set of one or more network
protocols, a conversational flow further having a set of one
or more states, including an initial state;
(c) if the packet is of an existing flow, identifying the last
encountered state of the flow, performing any state
operations specified for the state of the flow, and updating
the flow-entry of the existing flow including storing one
or more statistical measures kept in the flow-entry; and
[(]d) if the packet is of a new flow, performing any state
operations required for the initial state of the new flow and
storing a new flow-entry for the new flow in the flow-entry
database, including storing one or more statistical
measures kept in the flow-entry,
wherein every packet passing though the connection point is
received by the packet acquisition device, and
wherein at least one step of the set consisting of of [sic] step (a)
and step (b) includes identifying the protocol being used in the
packet from a plurality of protocols at a plurality of protocol
layer levels,
such that the flow-entry database is to store flow entries for a
plurality of conversational flows using a plurality of protocols, at
a plurality of layer levels, including levels above the network
layer.
Ex. 1004, 50:23–60.
III. ANALYSIS
We have reviewed the parties’ respective briefs as well as the relevant
evidence discussed in those papers. For the reasons discussed in detail
below, we determine that Petitioner has shown by a preponderance of the
IPR2020-00338
Patent 6,839,751 B1
9
evidence that claims 1, 2, 5, 10, 14, 15, and 17 of the ’751 patent are
unpatentable under 35 U.S.C. § 103 as having been obvious.
A. Legal Standards
To prevail in its challenges to the patentability of claims 1, 2, 5, 10,
14, 15, and 17 of the ’751 patent, Petitioner must demonstrate by a
preponderance of the evidence that the claims are unpatentable. 35 U.S.C.
§ 316(e); 37 C.F.R. § 42.1(d) (2019). “In an [inter partes review], the
petitioner has the burden from the onset to show with particularity why the
patent it challenges is unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815
F.3d 1356, 1363 (Fed. Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (2012)
(requiring inter partes review petitions to identify “with particularity . . . the
evidence that supports the grounds for the challenge to each claim”)). This
burden of persuasion never shifts to patent owner. See Dynamic Drinkware,
LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015); see also
In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1375–78 (Fed. Cir. 2016)
(discussing the burden of proof in inter partes review).
A claim is unpatentable for obviousness if, to one of ordinary skill in
the pertinent art, “the differences between the subject matter sought to be
patented and the prior art are such that the subject matter as a whole would
have been obvious at the time the invention was made.” 35 U.S.C. § 103(a)
(2006); see also 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 ordinary skill in the art; and (4) when in evidence, objective evidence of
IPR2020-00338
Patent 6,839,751 B1
10
nonobviousness.9 Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966). A
petitioner cannot satisfy its burden of proving obviousness by employing
“mere conclusory statements.” Magnum Oil, 829 F.3d at 1380. Moreover, a
decision on the ground of obviousness must include “articulated reasoning
with some rational underpinning to support the legal conclusion of
obviousness.” KSR, 550 U.S. at 418 (citing In re Kahn, 441 F.3d 977, 988
(Fed. Cir. 2006)).
We analyze Petitioner’s asserted grounds of unpatentability in
accordance with the above-stated principles.
B. Level of Ordinary Skill in the Art
We consider the asserted grounds of unpatentability in view of the
understanding of a person of ordinary skill in the art and, thus, begin with
the level of ordinary skill in the art. The level of ordinary skill in the art is
“a prism or lens through which . . . the Board views the prior art and the
claimed invention” to prevent hindsight bias. Okajima v. Bourdeau, 261
F.3d 1350, 1355 (Fed. Cir. 2001). In assessing the level of ordinary skill in
the art, various factors may be considered, including the “type of problems
encountered in the art; prior art solutions to those problems; rapidity with
which innovations are made; sophistication of the technology; and
educational level of active workers in the field.” In re GPAC Inc., 57 F.3d
1573, 1579 (Fed. Cir. 1995). “[O]ne or more factors may predominate.” Id.
Petitioner contends that an ordinarily skilled artisan would have “had
a bachelor’s degree in electrical engineering, computer engineering,
computer science, or a related field (or its equivalent), and one to two years

9 The parties do not direct our attention to any evidence of objective indicia
of nonobviousness.
IPR2020-00338
Patent 6,839,751 B1
11
of experience working in networking environments, including at least some
experience with network traffic monitors and/or analyzers.” Pet. 7–8 (citing,
inter alia, Ex. 1006 ¶¶ 195–201). In our Institution Decision, we adopted
Petitioner’s articulation of the level of skill in the art, which we determined
was consistent with the ’751 patent and the asserted prior art. Inst. Dec. 24–
25. In its Response, Patent Owner states that it “generally does not object to
this finding.” PO Resp. 22.
We apply Petitioner’s definition of the level of ordinary skill in the
art, as we did in the Institution Decision. Inst. Dec. 24–25. We also
maintain our determination that the definition offered by Petitioner is
consistent with the teachings of the ’751 patent and the prior art of record.
Cf. Okajima, 261 F.3d at 1355 (noting that the prior art itself may reflect an
appropriate level of skill in the art).
C. Claim Construction
In interpreting the claims of the ’751 patent, we “us[e] the same claim
construction standard that would be used to construe the claim[s] in a civil
action under 35 U.S.C. [§] 282(b).” 37 C.F.R. § 42.100(b). The claim
construction standard includes construing claims in accordance with the
ordinary and customary meaning of such claims as would have been
understood by one of ordinary skill in the art and the prosecution history
pertaining to the patent. See id.; Phillips v. AWH Corp., 415 F.3d 1303,
1312–14 (Fed. Cir. 2005) (en banc). We need not explicitly interpret every
claim term for which the parties propose a construction. See 35 U.S.C.
§ 314(a) (2012); Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
803 (Fed. Cir. 1999) (“[O]nly those terms need be construed that are in
controversy, and only to the extent necessary to resolve the controversy.”);
see also Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d
IPR2020-00338
Patent 6,839,751 B1
12
1013, 1017 (Fed. Cir. 2017) (applying Vivid Techs. in the context of an inter
partes review).
1. Incorporation by reference of previous disclosures
The ’751 patent claims the benefit of U.S. Provisional Application
No. 60/141,903, filed on June 30, 1999 (Ex. 1016, “the provisional
application”). See Ex. 1004, code (60). The ’751 patent states that the
contents of the provisional application, as well as the contents of several
other U.S. patent applications, including Application No. 09/608,237, filed
June 30, 2000, which issued as U.S. Patent No. 6,651,099 on November 18,
2003 (Ex. 1001, “the ’099 patent”), “are incorporated herein by reference.”
See id. at 1:8–12 (incorporating by reference the provisional application),
1:17–20 (incorporating by reference the application leading to the
’099 patent), 1:21–25 (incorporating by reference U.S. Patent Application
No. 09/609,179), 1:26–30 (incorporating by reference U.S. Patent
Application No. 09/608,266), 1:31–34 (incorporating by reference U.S.
Patent Application No. 09/608,267). Throughout their papers, the parties
refer to the disclosures of the ’099 patent and the provisional application,
and state that the ’751 patent incorporates the entire contents of those
disclosures. See, e.g., PO Resp. 2 n.1; Reply 2 n.1, 3–4.
We agree with the parties that the ’751 patent incorporates the
disclosures of the ’099 patent and the provisional application by specific
reference to those documents. Ex. 1004, code (60), 1:8–12, 1:17–20; see
also 37 C.F.R. § 1.57. Thus, we also refer to the ’099 patent and the
provisional application when discussing claim construction—not only for
consistency with the parties, but also for consistency throughout our final
decisions involving related inter partes proceedings between these parties.
See Advanced Display Sys., Inc. v. Kent State Univ., 212 F.3d 1272, 1282
IPR2020-00338
Patent 6,839,751 B1
13
(Fed. Cir. 2000) (stating that material incorporated by reference is
“effectively part of the host document as if it were explicitly contained
therein”); see also Trs. of Columbia Univ. v. Symantec Corp., 811 F.3d
1359, 1365–66 (Fed. Cir. 2016) (using statements in a provisional
application to construe claim terms in a patent incorporating the provisional
application by reference).
2. Overview
The only claim-construction dispute remaining in this proceeding
concerns the meaning of “conversational flow[s],” as recited in independent
claims 1 and 17. See, e.g., Ex. 1004, 50:28–30 (claim 1 reciting “looking up
a flow-entry database for containing one or more flow-entries for previously
encountered conversational flows”). At the heart of the parties’ dispute is
the following passage from the ’099 patent:
A conversational flow, on the other hand, is the sequence of
packets that are exchanged in any direction as a result of an
activity—for instance, the running of an application on a server
as requested by a client. It is desirable to be able to identify and
classify conversational flows rather than only connection flows.
The reason for this is that some conversational flows involve
more than one connection, and some even involve more than one
exchange of packets between a client and server.
Ex. 1001, 2:37–45 (emphases added). In our Institution Decision, we
preliminarily construed “conversational flow” as a “sequence of packets that
are exchanged in any direction as a result of an activity.” Inst. Dec. 28. We
declined to include the phrases “for instance, the running of an application
on a server as requested by a client” and “some conversational flows involve
more than one connection,[10] and some even involve more than one

10 The ’099 patent expressly defines “connection flow”: “The term
‘connection flow’ is commonly used to describe all the packets involved
IPR2020-00338
Patent 6,839,751 B1
14
exchange of packets between a client and server” in the construction of
“conversational flow,” as Patent Owner had requested. Id. We explained
that those passages, because they begin with the phrases “for instance,”
“where some,” and “some,” are “merely exemplary and non-limiting.” Id.
Petitioner does not challenge our preliminary construction. Tr. 7:23–
9:7. Patent Owner, however, argues that our construction captures only a
“part of the definition in the specification,” and improperly “excludes some
of the clarifying language that is also part of the explicit definition in the
specification.” PO Resp. 23. According to Patent Owner, “[t]hat clarifying
language is important for understanding the nature of a conversational flow.”
Id.
Specifically, Patent Owner argues that the written description of the
’751 patent provides an express definition of the term “conversational flow”
and that the express definition controls even though it contains exemplary
language. Id. at 23–24 (citing Sinorgchem Co., Shandong v. Int’l Trade
Comm’n, 511 F.3d 1132, 1137 (Fed. Cir. 2007)). Patent Owner argues that
the language following “for instance” is necessary for understanding a
“conversational flow,” because that language “makes apparent that
‘conversational flow’ must relate to a conversation” and “involves an
application activity involving the same client.” Id. at 26 (emphasis added);
see also Sur-Reply 1 (arguing that an “‘activity’ occurs between specific
entities”); PO Br. 1 (arguing that an activity “must relate to the actions of a
particular client or end user”). “Ignoring that language,” Patent Owner

with a single connection.” Ex. 1001, 2:35–37. Neither party disputes this
definition of “connection flow.”
IPR2020-00338
Patent 6,839,751 B1
15
argues, “risks losing the basic and fundamental requirement of a
‘conversation.’” PO Resp. 26
Patent Owner also argues our construction is incorrect because, prior
to this inter partes review, “every tribunal to have considered the proper
construction for ‘conversational flow’ has accepted . . . the same
construction advanced by Patent Owner” here:
the sequence of packets that are exchanged in any direction as a
result of an activity—for instance, the running of an application
on a server as requested by a client—and where some
conversational flows involved more than one connection, and
some even involve more than one exchange of packets between
a client and server.
PO Resp. 24. As an example, Patent Owner argues that the District Court
for the Eastern District of Texas adopted this construction in Packet
Intelligence LLC v. NetScout Systems, Inc., and that the Court of Appeals for
the Federal Circuit “addressed conversational flows and connection flows
when affirming the jury’s infringement verdict in NetScout, which
necessarily hinged on applying the court’s claim construction of
‘conversational flow.’” Id. at 25 (citing Ex. 2060, 3).
3. Analysis
Independent claims 1 and 17 each recite a database for containing
“flow-entries for previously encountered conversational flows.” Ex. 1004,
50:28–30 (claim 1), 52:4–6 (claim 17). As explained above, the parties
agree that “conversational flow” includes “the sequence of packets that are
exchanged in any direction as a result of an activity,” but disagree about
whether the phrases “for instance, the running of an application on a server
as requested by a client” and “some conversational flows involve more than
one connection, and some even involve more than one exchange of packets
IPR2020-00338
Patent 6,839,751 B1
16
between a client and server” should limit the meaning of “conversational
flow.” Patent Owner argues that those phrases are necessary because they
make clear that a conversational flow is client-specific. Thus, the parties’
basic dispute is whether a conversational flow is limited to a specific client
or user, as Patent Owner argues, or may include multiple clients or users, as
Petitioner contends. Compare, e.g., PO Resp. 26 (arguing that “the basic
and fundamental requirement” of a “conversational flow” is that it “involves
an application activity involving the same client”), with Reply 3 (contending
that “[t]he definitional language of ‘conversational flow’ doesn’t contain any
requirement for identifying flows based on a particular user or client”).
Starting with the passage reproduced above that we identified as the
heart of the parties’ dispute (Ex. 1001, 2:37–45), we determine that the “for
instance” phrase is exemplary and does not limit a “conversational flow” to
a specific client or user. The phrase “for instance” is synonymous with “for
example,” and necessarily indicates that “the running of an application on a
server as requested by a client” exemplifies, but does not limit, the
conversational flow to a server and a specific client or user.
Our determination that the “for instance” phrase is exemplary and
non-limiting is consistent with Patent Owner’s argument in its Preliminary
Response that the “some” phrase (“some conversational flows involve more
than one connection, and some even involve more than one exchange of
packets between a client and server”) is non-limiting. Specifically, Patent
Owner argued that the use of the word “some” necessarily means that “some
conversational flows involve multiple connections, while, some involve a
single connection.” Prelim. Resp. 25. Similarly here, while “conversational
flow” certainly may involve the running of an application on a server as
IPR2020-00338
Patent 6,839,751 B1
17
requested by a single client or user, “conversational flow” is not limited to a
single client or user.
Indeed, the ’099 patent and the provisional application expressly
contemplate classifying connection flows from different clients into the
same conversational flow when those connections involve the same activity.
These documents describe, in the context of identifying packets as part of a
conversational flow, a client/server protocol known as Service Advertising
Protocol (SAP), which is “used to identify the services and addresses of
servers attached to a network.” Ex. 1016, 3:12–14; Ex. 1001, 2:49–52. The
provisional application describes a packet exchange between a client and the
server in which the client sends a SAP request to a server for print service,
and the server sends a SAP reply that identifies the print service address:
In a first exchange, a client sends a SAP request to a server, for
example, for print service. The server sends a SAP reply that
identifies a particular address, for example, SAP #5, as the print
service on that server. Such may be responses used to update a
table, for example in a router, known as the Server Information
Table.
Ex. 1016, 3:14–18; see also Ex. 1001, 2:53–58. The provisional application
then describes a client who has “inadvertently seen” the SAP reply, and
therefore does not need to make a SAP request, but may send a print request
directly to SAP #5:
A client who has inadvertently seen this reply or who has access
to the table (via the router that has the Server Information Table,
for example) would know that SAP #5 for such this [sic] server
is a print service. Therefore, in order to print data on the server,
such a client does not need to make the request for a print service,
but simply to send data to be printed specifying SAP #5.
Ex. 1016, 3:18–23; see also Ex. 1001, 2:58–64.
IPR2020-00338
Patent 6,839,751 B1
18
The provisional application explains that the packet exchange between
the client who has “inadvertently seen” the print service address and SAP #5
is not connected to the initial packet exchange, “which was with a different
client”:
This sending of data to be printed again involves an exchange of
data between a client and a server, disjoint [sic] from the previous
exchange which was with a different client setting up that
SAP #5 is a print service on this server is a second connection.
Ex. 1016, 3:23–25 (emphasis added). Similarly, the ’099 patent describes
this packet exchange as “independent of the initial exchange.” Ex. 1001,
2:64–67.
The provisional application states that “[i]t is desirable for a network
packet monitor to be able to ‘virtually concatenate’ the first exchange that
defines SAP #5 as the print service on the server with the second exchange
that uses the print service.” Ex. 1016, 3:25–28. In this case, the provisional
application explains, the two packet exchanges (the first between a client
and the server and the second between a client and SAP #5) “would then be
correctly identified as being part of the same flow if the clients were the
same,” but also, “[t]hey would even be recognized if the clients were not the
same.” Id. at 3:28–30 (emphasis added). Similarly, the ’099 patent states
that “because one features [sic] of the invention is to correctly identify the
second exchange as being associated with a print service on that server, such
exchange would even be recognized if the clients were not the same.”
Ex. 1001, 3:44–48 (emphasis added).
We interpret the SAP description in the provisional application and
’099 patent as describing two seemingly disjointed packet exchanges
involving two different clients or users (the first packet exchange between a
client and the server and the second packet exchange between the client who
IPR2020-00338
Patent 6,839,751 B1
19
has “inadvertently seen” the print service address and SAP #5) as belonging
to the same “conversational flow.” And because Patent Owner’s proposed
construction—that a “conversational flow” is client-specific—is inconsistent
with the written description, we decline to limit a “conversational flow” to a
specific client or user.
Patent Owner argues that our interpretation of the SAP example is
incorrect because “[t]he second sentence” of that example—i.e., “such
exchange would even be recognized if the clients were not the same”—
merely “illustrates how a later print request by a different client can also be
recognized as a print request activity because it uses the now known address
of the print service.” Sur-reply 7 (emphasis added). We are not persuaded.
In the provisional application, this description of the second client follows
the statement that “[i]t is desirable to be able to identify and classify
conversational flows,” Ex. 1016, 3:7–8 (emphasis added), and is followed by
statements describing “[o]ther protocols that are similar in that they may
lead to disjointed conversational flows,” id. at 4:1–5 (emphasis added). The
provisional application also states that “[p]rior art network monitors do not
presently have the ability to recognize such disjointed flows as belonging to
the same conversational flow.” Id. at 4:13–14. Similarly, in the ’099 patent,
the phrase “such exchange would even be recognized if the clients were not
the same” is soon followed by the statement that “[w]hat distinguishes this
invention from prior art network monitors is that it has the ability to
recognize disjointed flows as belonging to the same conversational flow.”
Ex. 1001, 3:48–51 (emphasis added). We view these statements, in context,
as reinforcing the notion that the disclosed invention sought to classify
disjointed connection flows—even those involving more than one client or
IPR2020-00338
Patent 6,839,751 B1
20
user—into the same conversational flow based on a specific activity, such as
print service.
We are not persuaded by Patent Owner’s argument that Sinorgchem
compels a different result here. See PO Resp. 23–24. In Sinorgchem, the
claim language at issue was “controlled amount,” of which the patent stated:
A ‘controlled amount’ of protic material is an amount up to that
which inhibits the reaction of aniline with nitrobenzene, e.g., up
to about 4% H2O based on the volume of the reaction mixture
when aniline is utilized as the solvent.
511 F.3d at 1136. The International Trade Commission “agreed that the
patentee had expressly defined the term ‘controlled amount’ in the
specification but held that the language ‘e.g., up to about 4% H2O based on
the volume of the reaction mixture when aniline is utilized as the solvent’
should not be considered part of that definition,” in part because the
Commission considered “the 4% limit as merely an example that did not
apply to all situations in which aniline was used as the solvent.” Id. at 1137.
The Federal Circuit rejected the Commission’s construction, holding that
“[w]hen aniline is used as the solvent, the express definition is neither
ambiguous nor incomplete—the ‘controlled amount’ is ‘up to about 4% H2O
based on the volume of the reaction mixture’—and we need look no further
for its meaning.” Id. at 1138.
Patent Owner argues that Sinorgchem stands for the proposition that
an express definition in the specification controls even if it contains
exemplary language. PO Resp. 23–24. According to Patent Owner, the
phrase “for instance, the running of an application on a server as requested
by a client” is the express definition of “conversational flow” that we must
accept, even though it contains the exemplary language “for instance.” Id.
We do not agree because, in Sinorgchem, the patent at issue described “at
IPR2020-00338
Patent 6,839,751 B1
21
least six different solvents,” of which aniline was just one example. The
Federal Circuit reasoned that, when aniline was used as the solvent, then the
upper limit of protic material was “up to about 4% H2O.” Sinorgchem, 511
F.3d at 1138. In other words, the use of aniline was a condition precedent
(“when aniline is utilized”) that, when satisfied, triggered the condition
subsequent upper limit of protic material (“up to about 4% H2O”). Id. The
language in the ’099 patent (“for instance, the running of an application on a
server as requested by a client”)—unlike that in Sinorgchem—is not
conditional. Thus, we find Sinorgchem to be inapposite to the facts of this
case.
Finally, Patent Owner’s argument that “[b]efore the Institution
Decisions in this and the related IPRs, every tribunal to have considered the
proper construction for ‘conversational flow’ has accepted . . . the same
construction advanced by Patent Owner,” PO Resp. 24–25, does not
persuade us that our construction here is erroneous.
Despite Patent Owner’s argument, neither the District Court nor the
Federal Circuit appears to have expressly analyzed “conversational flow”
and determined that the claim term necessarily includes the language recited
within the “for instance,” “where some,” and “some” phrases. In Packet
Intelligence LLC v. NetScout Systems, for example, the District Court merely
adopted Patent Owner’s construction without analysis after the parties
“reached agreement” at a hearing dated March 2, 2017. Ex. 1067, 6. And
the Federal Circuit, if anything, appears to have relied on a definition of
“conversational flow” lacking the additional phrases Patent Owner advances
here. Ex. 2060, 3. Specifically, in describing “conversational flows,” the
court stated that:
IPR2020-00338
Patent 6,839,751 B1
22
The specifications explain that it is more useful to identify and
classify “conversational flows,” defined as “the sequence of
packets that are exchanged in any direction as a result of an
activity.”
Id. (citing Ex. 1001, 2:45–47) (emphasis added). Finally, we also observe
that the Board’s constructions of “conversational flow” in prior proceedings
were made in institution decisions and, thus, were merely preliminary. See,
e.g., Ex. 1056, 10 (interpreting “conversational flow” “for purposes of this
Decision” (emphasis added)).
For these reasons, we have considered the constructions of the other
panels and tribunals, but are not persuaded that our construction of
“conversational flow” is mistaken or inconsistent with those other
constructions. See 37 C.F.R. § 42.100 (b) (“Any prior claim construction
determination concerning a term of the claim in a civil action, or a
proceeding before the International Trade Commission, that is timely made
of record in the inter partes review proceeding will be considered.”
(emphasis added)).
4. Summary
In summary, having considered the totality of the arguments and
evidence anew at the close of trial, we determine that “conversational
flow[s]” means a “sequence of packets that are exchanged in any direction
as a result of an activity,” without the additional restriction that the
conversational flow must be client- or user-specific.
D. The Prior Art
Before turning to Petitioner’s asserted grounds of unpatentability, we
provide a brief summary of the asserted references.
IPR2020-00338
Patent 6,839,751 B1
23
1. Riddle (Ex. 1008)
Riddle relates to a method for automatically classifying packet flows
for use in allocating bandwidth resources by a rule of assignment of a
service level. Ex. 1008, 4:6–10. The method comprises applying individual
instances of traffic classification paradigms to packet network flows based
on selectable information obtaining from layers of a multi-layered
communication protocol in order to define a characteristic class, then
mapping the flow to the defined traffic class. Id. at 4:10–15. Figure 3 is
reproduced below.

Figure 3 illustrates a system for automatically classifying traffic.
Ex. 1008, 12:27–28.
With reference to Figure 3, traffic tree 302 classifies new traffic under
a particular member class node. Ex. 1008, 12:28–30. Traffic classifier 304
detects services for incoming traffic. Id. at 12:30–31. Knowledge base 306
contains heuristics for determining traffic classes. Id. at 12:32–33. A
plurality of saved lists 308 stores classified traffic pending incorporation into
traffic tree 302. Id. at 12:37–38.
IPR2020-00338
Patent 6,839,751 B1
24
Figure 4A is reproduced below.

Figure 4A illustrates a flowchart 401 of processing steps for
automatically classifying traffic. Ex. 1008, 12:42–43.
In step 402 shown in Figure 4A, a flow specification is parsed from
the flow being classified. Ex. 1008, 12:43–44. Then in step 404, the flow
specification parsed from the flow in step 402 is compared with the traffic
specifications in each node of the classification tree. Id. at 12:44–47. In
decisional step 406, a determination is made of whether traffic matches one
of the classes being classified. Id. at 12:48–50. If this is so, then in
step 408, an entry is made in a list of identifying characteristics, such as
protocol type, IP protocol number, server port, traffic type, MIME type, or
time of occurrence of traffic. Id. at 12:50–53.
IPR2020-00338
Patent 6,839,751 B1
25
Figure 4B is reproduced below.

Figure 4B illustrates a flowchart 403 of the processing steps for
integrating traffic classes into a classification tree. Ex. 1008,
13:36–38.
In step 420 of Figure 4B, an instance of saved traffic is received from
a saved traffic list 308. Ex. 1008, 13:40–42. Next, in decisional step 422,
the instance of saved traffic is examined to determine whether it is
well-known and a name representing its type exists. Id. at 13:42–45. If this
is so, then processing continues with a test of whether the saved traffic
belongs to a service aggregate in step 426. Id. at 13:45–47. Otherwise, in
IPR2020-00338
Patent 6,839,751 B1
26
step 423, the instance of saved traffic is examined to determine whether it
appears to be a server connection port of an unregistered IP port. Id.
at 13:47–50. If this is not so, then processing continues with the next traffic
class in the saved list in step 420. Id. at 13:51–52. In decisional step 426,
the instance of saved traffic is examined to determine whether it belongs to a
service aggregate. Id. at 13:52–54. If the traffic does belong to a service
aggregate, then, in step 428, a traffic class is created which will match all
components of the service aggregate. Id. at 13:57–59. In further step 425, a
new traffic class is created to match the instance of saved traffic. Id.
at 13:59–62.
2. Ferdinand (Ex. 1009)
Ferdinand relates to a system for “monitoring and managing
communication networks for computers.” Ex. 1009, code (54), 1:3–4.
Ferdinand discloses a monitoring system with “a Network Monitor 10 and a
Management Workstation 12.” Id. at 11:32–12:1. In monitoring the
network, Ferdinand indicates that a “statistical object represents a network
parameter for which performance information is gathered,” and that
Monitor 10 keeps information about monitored statistical objects in
“Statistics Module (STATS) 36.” Id. at 22:18–22. STATS 36 is a database
(id. at 19:5–11) and “defines the database and it contains subroutines for
updating the statistics which it keeps” (id. at 28:14–15). Examples of data
the database stores include records “per ip address,” “per ip pair,” “per udp
pair,” “per ftp control connection,” and “per ftp data connection.” Id.
at 29:3–30:7.
3. Yu (Ex. 1011)
Yu relates to “an architecture 100 for applying policies to network
data traffic.” Ex. 1011, 2:46–50. The architecture includes three
IPR2020-00338
Patent 6,839,751 B1
27
components: (i) an application “such as a firewall, virtual private network
(VPN), or traffic management,” (ii) a “policy engine 106,” and (iii) an
API 104 between these two components. Id. at 2:51–5.
Yu describes a “flow classification specification 203a provides the
screening criteria for the flow classifier logic 204 to sort network traffic into
flows,” that “[a]ll packets that match the same flow classification
specification 203a form a flow,” that “a flow is a stream of correlated
packets to which policy decisions apply,” and that “a flow classifier 204
classifies the packet according to one or more classification
specifications 203a and finds one or more corresponding action
specifications 203b.” Ex. 1011, 3:32–59. Yu further describes that a
“stream is an ‘instantiation’ of a flow-packets that have the same source and
destination address, source and destination port, and protocol type,” and
“[p]ackets may be sorted into streams, and a flow may include one or more
streams,” where “[a]ll packets belonging to the same stream are to be
regulated by the same policy.” Id. at 4:2–9.
In Yu, “the stream classifier 207 matches the packets to a particular
stream specification 208 and then, using the corresponding action
specifications 210, activates the proper action processors 206.” Ex. 1011,
5:8–11.
4. RFC1945 (Ex. 1010)
RFC1945 is an informational specification, published by the Network
Working Group, and concerns Hypertext Transfer Protocol 1.0. Ex. 1010, 1.
The publication “reflects common usage of the protocol referred to as
‘HTTP/1.0’.” Id. The RFC defines several message headers, such as
“Referer,” which “allows the client to specify, for the server’s benefit, the
address (URI) of the resource from which the Request-URI was obtained,”
IPR2020-00338
Patent 6,839,751 B1
28
and “Server,” which “contains information about the software used by the
origin server to handle the request.” Id. at 44–45.
E. Obviousness over Riddle and Ferdinand
Petitioner contends that claims 1, 2, 5, 10, 14, 15, and 17 would have
been obvious over the combination of Riddle and Ferdinand. Pet. 17–77.
Patent Owner opposes. PO Resp. 34–45, 53–57; Sur-reply 13–16, 19–22.
Having considered the totality of the arguments and evidence, we find that
Petitioner has shown by a preponderance of the evidence that claims 1, 2, 5,
10, 14, 15, and 17 are unpatentable as having been obvious over Riddle in
view of Ferdinand.
1. Independent Claims 1 and 17
a. Preamble
The preamble of claim 1 of the ’751 patent recites “[a] method of
analyzing a flow of packets passing through a connection point on a
computer network.” Ex. 1004, 50:23–24. The preamble of claim 17
similarly recites “[a] packet monitor for examining packets passing through
a connection point on a computer network, each packets [sic] conforming to
one or more protocols.” Id. at 51:52–54.
To the extent that the preamble recitations are limiting, Petitioner
persuasively shows that they are taught by Riddle. See Pet. 27–31 (citing
Ex. 1006 ¶¶ 263–269, 618–623, 765, 840, 841). In particular, Petitioner
contends, Riddle describes a classifier, operating in a network-connected
computer system (e.g., in a server acting as a packet monitor and a network
interface acting as a packet acquisition device), that parses and examines (or
analyzes) traffic flow packets passing through a network. Id. at 27–28
(citing Ex. 1008, code (57), 1:57–61, 3:67–4:2, 4:6–17, 5:53–67, 12:27–41,
13:30–31, 14:22–40, Figs. 1A, 1B, 3; Ex. 1006 ¶¶ 263, 264). Regarding
IPR2020-00338
Patent 6,839,751 B1
29
“connection point[s],” Petitioner contends, “the ’751 [p]atent acknowledges
that these are simply the points where the packet monitor connects to the
network,” and Riddle “details that its packet monitor connects to [a] network
connection . . . via a system gateway to analyze passing-through packets.”
Id. at 29 (citing Ex. 1004, 5:65–6:19, Fig. 1; Ex. 1008, 5:53–67, 6:9–15,
7:21–24, Figs. 1A, 1B; Ex. 1006 ¶ 265). Further, Petitioner contends, “[f]or
networks connecting multiple clients and servers . . . , Riddle teaches
examining packets via ‘network routing means’ and/or routers,” which we
agree with Petitioner also serve as “connection point[s]” as claimed. Id.
(citing Ex. 1008, 7:10–34, Figs. 1C, 3; Ex. 1006 ¶ 266). Still further,
Petitioner contends that “Riddle analyzes packets in real-time to manage
network bandwidth based on flow classification,” that “[Riddle’]s monitor
determines a packet’s traffic class, e.g., Real Time Protocol,” and that
“Riddle also teaches allocating bandwidth based on information
ascertainable from multiple OSI layers of each flow, i.e., based on analyzing
the flow of packets passing through a network’s connection point.” Id. at 30
(citing Ex. 1008, code (57), 1:54–61, 2:4–13, 2:66–67, 3:32–39, 3:67–4:2,
4:6–9, 10:57–59, 12:3–12; Ex. 1006 ¶¶ 267, 268).
Patent Owner does not substantively address these assertions or
otherwise contend that the art lacks any of the preamble features, and we are
persuaded that Petitioner has shown by a preponderance of the evidence that
they are taught by Riddle and adopt the contentions set forth in the Petition
and in Dr. Weissman’s Declaration as mapped to these undisputed
limitations of claims 1 and 17 as our own findings. See In re NuVasive, Inc.,
841 F.3d 966, 974 (Fed. Cir. 2016) (explaining that the Board need not make
specific findings about claim limitations that a patent owner does not dispute
are disclosed in the prior art).
IPR2020-00338
Patent 6,839,751 B1
30
b. Packet Acquisition Device Limitations (Claims 1 and 17)
Claim 1 of the ’751 patent recites, in part, “receiving a packet from a
packet acquisition device coupled to the connection point.” Ex. 1004,
50:26–27. Claim 17 similarly recites “a packet acquisition device coupled to
the connection point and configured to receive packets passing through the
connection point.” Id. at 52:1–3.
Petitioner demonstrates by a preponderance of the evidence that
Riddle teaches these limitations. See Pet. 31–32 (citing Ex. 1006 ¶¶ 624–
626, 766, 820–824, 842). In particular, Petitioner identifies various “packet
acquisition devices coupled to a connection point” in Riddle, including
network interface 40 connected to the system gateway depicted in Riddle’s
Figures 1A and 1B, as well as the “network routing means” and router 75
depicted in Riddle’s Figure 1C. Id. at 31 (citing Ex. 1008, 6:5–15, 7:21–24,
16:54–17:15 (claim 8), Figs. 1A–1C; Ex. 1006 ¶¶ 264–266). Citing
disclosure in Riddle describing “automatically classify[ing] packet flows to
help allocate bandwidth resources” and “to classify a complete enumeration
of the possible traffic,” and further relying on U.S. Patent No. 6,046,980 to
Packer (Ex. 1031), incorporated by reference in Riddle,11 and the testimony
of Dr. Weissman, Petitioner contends that a person of ordinary skill in the art
“would have understood that, in order to classify packet flows, Riddle’s
acquisition device receives packets.” Id. at 32 (citing Ex. 1008, code (57),
4:7–17, 4:55–60; Ex. 1006 ¶¶ 482, 486, 626; Ex. 1031, 4:12–16). Patent
Owner does not dispute Petitioner’s contentions regarding these limitations.
See generally PO Resp.

11 See Ex. 1008, 1:29–31, 1:37–41.
IPR2020-00338
Patent 6,839,751 B1
31
Petitioner’s assertions are supported by the cited evidence and are
persuasive. Accordingly, we are persuaded that Petitioner has shown by a
preponderance of the evidence that the recited limitations are taught by
Riddle and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these undisputed limitations of
claims 1 and 17 as our own findings. NuVasive, 841 F.3d at 974.
c. Flow-Entry Database Limitations (Claims 1 and 17)
Claim 1 of the ’751 patent recites, in part, “for each received packet,
looking up a flow-entry database for containing one or more flow-entries for
previously encountered conversational flows, the looking up to determine if
the received packet is of an existing flow.” Ex. 1004, 50:28–32. Claim 17
similarly recites “a memory for storing a database for containing one or
more flow-entries for previously encountered conversational flows to which
a receive packet may belong.” Id. at 52:4–6.
(1) The Parties’ Arguments
Petitioner contends, and we agree, that Riddle alone or in view of
Ferdinand renders these limitations obvious. Pet. 33–47 (citing Ex. 1006
¶¶ 328–339, 767–769, 843). According to Petitioner, “Riddle looks up flow-
entries based on service aggregates or PointCast flows, which both meet the
claimed ‘previously encountered conversational flows.’” Id. at 33. With
respect to reasons to combine the teachings of Riddle and Ferdinand,
Petitioner contends that “Riddle and Ferdinand are in the same field of
endeavor,” “contain overlapping disclosures with similar purposes,” and
illustrate that it was well-known and ubiquitous in the art for networking
devices to include database storage structures and distinct processing
engines. Id. at 25 (citing Ex. 1008, 4:7–17, 9:14–27, 12:37–59, Figs. 3, 4A,
4B; Ex. 1009, 12:3–9; Ex. 1006 ¶¶ 256, 257, 764). Relying on the testimony
IPR2020-00338
Patent 6,839,751 B1
32
of Dr. Weissman, Petitioner contends that a person of ordinary skill in the art
“would have been motivated and found it obvious to store Riddle’s
hierarchical classification trees and flow-entries in a database such as the
database taught by Ferdinand,” including to provide increased functionality
(e.g., searching, analyzing, and modifying the flow-entries), to allow
multiple network operators to access classification information
simultaneously, and in accordance with “Riddle’s desired goal of managing
data entries to determine whether the examined packets belong to a service
aggregate, such as an FTP session.” Id. at 26 (citing Ex. 1008, 11:9–24,
12:34–35, 12:65–13:7; Ex. 1009, 41:32–42:3, 44:8–14, 47:3–48:11;
Ex. 1006 ¶ 259).
Further, Petitioner contends, “Riddle identifies a ‘service aggregate’
which is one traffic-type.” Pet. 35 (citing Ex. 1006 ¶¶ 133, 308, 816;
Ex. 1008, 11:10–22, 13:53–59). Petitioner argues that Riddle’s “service
aggregate links together into a ‘conversation’ multiple connection flows
based on specific software program activity (e.g., PointCast traffic),” and,
“[a]ccordingly, Riddle teaches storing separate entries for encountered
conversational flows.” Id. at 35–36 (citing Ex. 1006 ¶¶ 331; Ex. 1008,
11:60–63). Additionally, Petitioner contends, Riddle illustrates processing
of the flow-entries to determine whether a traffic class, such as a service
aggregate, needs to be created for the flow, and that Riddle’s monitor
retrieves previously stored data from the saved lists, tests whether the
retrieved traffic belongs to a service aggregate, and if so, creates a traffic
class that “will match all components of the service aggregate.” Id. at 36
(citing Ex. 1006 ¶¶ 332, 333; Ex. 1008, 4:49–51, 13:35–14:6, Fig. 4B).
According to Petitioner, a person of ordinary skill in the art would have been
motivated and would have found it obvious to store Riddle’s lists and related
IPR2020-00338
Patent 6,839,751 B1
33
tree in a flow-entry database, based either on the artisan’s own knowledge of
network devices or on Ferdinand’s teachings, in order, for example, to
increase functionalities in furtherance of Riddle’s desired goal of
determining whether the packet monitor has received duplicate flow-entries.
Id. at 37–39 (citing, e.g., Ex. 1006 ¶¶ 335–339; Ex. 1008, 6:1–15, 12:32–35,
12:53–57, 15:1–15, Fig. 4A; Ex. 1009, 28:14–17).
Petitioner further contends that Riddle discloses flow-entries of
“previously encountered conversational flows” in at least two ways:
“(a) classifying based on service aggregates and (b) classifying based on
PointCast.” Pet. 39–40 (citing Ex. 1006 ¶¶ 301–327, 769). Regarding the
former, Petitioner contends that “Riddle teaches identifying whether packets
are part of ‘service aggregates,’ i.e., traffic classes linking separate
connection flows based on the associated application,” and that “these
‘service aggregates’ meet the claimed ‘conversational flows.’” Id. at 40
(citing Ex. 1006 ¶¶ 302–327). Indeed, Petitioner contends, Riddle’s
claims 1 and 2 teach that the service aggregates are conversational flows. Id.
at 43–44 (citing Ex. 1008, 15:56–16:14 (claim 1) (reciting “said network
having any number of flows” and “parsing a packet into a first flow
specification”), 16:15–26 (claim 2) (reciting “for at least a second flow
having a second flow specification, recognizing said second flow
specification and said first flow specification to comprise together a service
aggregate” and “associating said first flow specification and said second
flow specification with a newly-created classification tree node, said newly-
created classification tree type node having a first traffic specification
corresponding to said first flow specification and a second traffic
specification corresponding to said second flow specification”); Ex. 1006
¶ 313).
IPR2020-00338
Patent 6,839,751 B1
34
Regarding “PointCast Traffic,” Petitioner contends that the
provisional application, from which the ’751 patent claims priority and
which is incorporated by reference in the ’751 patent, expressly “specifies
that PointCast traffic flows include an identification signature, and that
identifying PointCast traffic is an example of identifying a conversational
flow.” Pet. 45 (citing Ex. 1016, 7:16–25; Ex. 1006 ¶¶ 320, 321). Because
Riddle “creates a single traffic class for disjointed PointCast connection
flows by searching headers for URLs that begin with ‘/FIDO-1/,’” Petitioner
contends, “Riddle thus teaches identifying a conversational flow.” Id. at 45–
46 (citing Ex. 1006 ¶¶ 323, 324; Ex. 1008, 11:57–12:9). Indeed, Petitioner
asserts, one of the inventors of the ’751 patent previously testified that
creating a single flow to describe such disjointed flows is a type of
conversational flow. Id. at 46 (citing Ex. 1068, 55:11–57:15; Ex. 1071 ¶ 4;
Ex. 1072, 3). Finally, Petitioner contends, “Riddle teaches that one of its
autoclassification processes identifies PointCast traffic using the outside
service field of the class,” specifying that “[c]ertain traffic may be
distinguished by a signature,” and “[a]ccordingly, based on Riddle’s
teachings, a [person of ordinary skill in the art] would have understood that
Riddle stores flow-entries for ‘previously encountered conversational flows’
such as PointCast traffic.” Id. at 46–47 (citing Ex. 1008, 11:50–53, 14:54–
63, 15:16–20, 15:28–31; Ex. 1006 ¶¶ 325, 329–335, 769).
Lastly, Petitioner contends that Riddle teaches “looking up to
determine if the received packet is of an existing flow,” as recited in claim 1,
because Riddle discloses entering traffic characteristics of the traffic flow
into the saved list (step 408) and identifying conversational flows in the
form of service aggregates and PointCast flows (step 426), and also specifies
that each flow-entry includes “a flow specification and indicators.” Pet. 47
IPR2020-00338
Patent 6,839,751 B1
35
(citing, e.g., Ex. 1008, 12:42–59; Ex. 1006 ¶¶ 330, 332). In particular,
Petitioner points out, “Riddle’s monitor ‘parse[s] flow specification from a
packet of the flow’ (step 402), and ‘compare[s] flow specification with
existing classification tree’ (step 404), [to] determine if ‘traffic matches a
class?’ (step 406)),” as shown in Riddle’s Figure 4A; and “Riddle’s step 426
looks up flow-entries to determine if the received packet is of an existing
conversational flow,” to determine if “saved traffic belongs to a service
aggregate,” as shown in Figure 4B. Id. (citing Ex. 1008, 13:36–62,
Figs. 4A, 4B; Ex. 1006 ¶ 333).
In response to Petitioner’s contentions, Patent Owner asserts, first,
that Riddle fails to teach “conversational flows” (PO Resp. 34–44), and
second, that the combination of Riddle and Ferdinand does not teach the
claimed flow-entry database (id. at 44–45). Regarding the first point, Patent
Owner contends that Riddle classifies traffic into generic traffic classes, but
does not perform any more granular analysis. Id. at 40. According to Patent
Owner, Riddle has no need or ability to recognize whether a particular group
of packets in one direction relate to another flow or may form part of a
conversational flow implicating an activity, unlike the claims of the
’751 patent “which require specific operations involving conversational
flows.” Id. Further, according to Patent Owner, “just because Riddle
discloses a traffic classification activity does not mean that it discloses or
suggests the specific activity required in the ’751 Patent, which is narrowly
focused on conversational flows.” Id. at 41. Patent Owner contends,
“Riddle combines flows based on the type of activity,” and “[a]t best, . . .
combines flows of the same type into a traffic class,” whereas “the
’751 Patent inventions recognize separate conversational flows even when
these different flows are based on the same type of activity.” Id. at 42–43.
IPR2020-00338
Patent 6,839,751 B1
36
Still further, Patent Owner argues, “‘conversational flows’ include
bidirectional exchanges of packets,” but “Riddle, however, expressly
teaches that its traffic classes are limited to unidirectional traffic.” Id. at 43–
44 (emphasis omitted) (citing Ex. 1008, 8:50–53, 11:28–29, 13:57–59;
Ex. 2061 ¶¶ 64, 65, 83). According to Patent Owner, “[b]ecause Riddle’s
traffic classes are unidirectional, they cannot satisfy the ‘conversational
flow’ element required in every challenged claim.” Id. at 44.
Regarding the recited flow-entry database, Patent Owner contends
that Riddle does not use conversational flows and accordingly has no
disclosure of the recited flow-entry database “comprising flow-entries for
previously encountered flows.” PO Resp. 45 (citing Ex. 2061 ¶ 87).
Further, Patent Owner contends, although the Petition relies on the
combination of Riddle and Ferdinand as teaching this limitation,
“Ferdinand . . . focuses on a ‘technique of organizing and displaying
network performance statistics” and “never discloses or suggests storing
‘flow-entries for previously encountered conversational flows.’” Id. (citing
Ex. 1009, 7:17–18, 8:3–5). “Nor would Ferdinand have reason to implement
such a solution,” according to Patent Owner, “because its goal is merely to
keep count,” which “it can do . . . by the standard statistical measures
described in the specification.” Id..
In its Reply, Petitioner contends that Patent Owner’s arguments do not
analyze Riddle under the Board’s construction of “conversational flows,”
but instead under Patent Owner’s own incorrect construction. Reply 10–11.
Regardless, Petitioner argues, Riddle discloses “conversational flows” even
under Patent Owner’s incorrect construction. Id. at 11. First, according to
Petitioner, “Riddle specifies that its service aggregate ‘is provided for certain
applications that use more than one connection in a particular conversation
IPR2020-00338
Patent 6,839,751 B1
37
between a client and a server.’” Id. (citing Ex. 1008, 11:10–19). For
example, “Riddle describes listing service aggregates based on their source
and/or destination, e.g., ‘host1,’ where host1 can represent a client or a
server involved in an FTP flow.” Id. (citing Ex. 1008, 2:13–21, 7:12–21,
13:8–26, Fig. 1C; Ex. 1006 ¶¶ 311, 312). Further, Petitioner contends,
“Riddle teaches defining a traffic class by URI-pattern (e.g., ‘/sales/*’) and
by the specific client/server pair involved (e.g., from ‘client Z’ to
‘server Y’).” Id. at 12 (citing Ex. 1008, 8:58–9:11; Pet. 63–64, 90).
In response to Patent Owner’s contention that Riddle classifies
inbound and outbound flows only separately, not bidirectionally, Petitioner
contends that Riddle in fact discloses that all traffic in a particular
conversation between a client and a service is classified into a single service
aggregate. Reply 12–13 (citing Ex. 1008, 11:12–15; Pet. 40). Petitioner
cites, for example, disclosure in Riddle that the service aggregate for an FTP
session contains “each conversation” between the client and server for the
session, which Petitioner argues refers to all packets exchanged in either
direction. Id. at 12–13 (citing Ex. 1008, 11:13–19, 12:1–12, 13:54–59;
Pet. 41). Still further, Petitioner argues that “Riddle isn’t limited to flow
classification based on port or server identity,” but discloses, for example,
that “flow classification can use port numbers and can further ‘extend to
examination of the data contained in a flow’s packets’ via signature-based
analysis.” Id. at 13–14 (citing Ex. 1008, 11:50–53). Petitioner contends that
“Telnet traffic’s multi-packet ‘option negotiations’ ‘may indicate an
appropriate class,’ an example of classification from exchanged data, not
port number.” Id. at 14 (citing Ex. 1008, 11:66–67).
Lastly, in response to Patent Owner’s arguments that “Riddle . . . has
no disclosure of a flow-entry database” and that “Ferdinand never discloses
IPR2020-00338
Patent 6,839,751 B1
38
or suggests storing ‘flow-entries for previously encountered conversational
flows’” (PO Resp. 45–46), Petitioner argues, first, that Patent Owner does
not address the Petition’s contention that, “based upon a [person of ordinary
skill in the art’s] knowledge of network devices, a [person of ordinary skill
in the art] would have been motivated and found it obvious to store Riddle’s
classification information, such as flow-entry lists 308, in a database.”
Reply 20 (citing Pet. 33–39; Ex. 1006 ¶¶ 328–335). Petitioner further points
out that the Petition alleges that the “flow-entry database” limitations would
have been obvious over “Riddle alone or in combination with Ferdinand,”
not based on Ferdinand alone, and accordingly, Petitioner contends, Patent
Owner’s attack on Ferdinand individually is irrelevant to the trial ground.
Id. at 21 (citing Pet. 23, 38–39). Citing the arguments presented in the
Petition, Petitioner argues that “[t]he ‘flow-entry database limitations’ would
have been obvious in view of Riddle’s teachings regarding flow-entries and
relational databases based on Ferdinand’s teachings regarding statistics
databases for storing flow classification information.” Id. (citing Pet. 33–
39).
In the Sur-reply, Patent Owner argues again that Riddle fails to
disclose “conversational flows,” contending that Riddle does not classify
activities based on a particular client, that Riddle categorizes inbound and
outbound traffic separately, and that Riddle fails to distinguish between
different activities of the same type. Sur-reply 13–16. First, according to
Patent Owner, Petitioner’s contention that a service aggregate can
distinguish between the same type of activity between different clients
(Reply 11–12) “hinges on an extrapolation of how a single connection
example is classified that is not supported by the rest of the specification.”
Sur-reply 14. According to Patent Owner:
IPR2020-00338
Patent 6,839,751 B1
39
In Riddle, service aggregates are a “common traffic class” that
are “created with a plurality of traffic specifications.” EX1008
at 11:15–23. Riddle notes “[a] traffic class is broadly defined as
traffic between one or more clients and one or more servers.”
Id. at 8:48–49, 14:18–20 (“[A]nother method of identifying an
individual traffic class is to detect simultaneous connections to
the same host port from different clients.”). Thus, Riddle does
not classify traffic per user, but by the type of traffic based on
properties such as the ports being used. This understanding
reflects Riddle’s stated purpose—bandwidth management.
Petitioner also suggests that, because a traffic class can be
defined in terms of a specific source or destination IP
address, . . . Riddle discloses “classifying traffic into client-
specific conversational flows.” Reply at 11–12 (citing Riddle
at 8:58–9:11, 10:1–17). That is incorrect. A rule written
specifically for a client’s IP address would not distinguish one
client activity from another; it would simply aggregate all traffic
for that client. Defining a traffic class in terms of a specific
source or destination address is an implementation of the
conventional technique of matching one or more parts of a
5-tuple—but not a conversational flow. PO [Resp.] 6, 18–19;
EX2061 ¶¶62–65, 81–83.
Id. at 14–15. Further, Patent Owner argues, “Riddle expressly teaches that
its traffic classes are limited to unidirectional traffic, and that service
aggregates are traffic classes.” Id. at 16. Finally, with regard to the recited
“flow-entry database,” Patent Owner responds that, notwithstanding
Petitioner’s arguments that implementing these limitations would have been
obvious, “Petitioner provided no evidence or argument to show it would
have been ‘unusually simple’ to add the claimed limitations, nor that the
technology is ‘particularly straightforward.’” Id. at 21–22. According to
Patent Owner, “[t]he challenged claims do not recite a database generally,
but recite a flow-entry database specifically adapted for use in a packet
monitor,” and a person of ordinary skill in the art “would have understood
IPR2020-00338
Patent 6,839,751 B1
40
the statistics database of Ferdinand to serve a very different purpose than the
claimed flow-entry database.” Id.
(2) Analysis
Having considered the full trial record, we are persuaded that
Petitioner has shown by a preponderance of the evidence that the
combination of Riddle and Ferdinand renders obvious the recited flow-entry
database limitations in view of the proper construction of “conversational
flow.” See supra § III.C. Petitioner’s assertions, which we adopt, are
supported by the cited evidence and are persuasive. Moreover, we are
persuaded that a person of ordinary skill in the art would have been
motivated to combine the teachings of Riddle and Ferdinand as proposed by
Petitioner and supported by the testimony of Dr. Weissman. See Pet. 25–26
(citing Ex. 1006 ¶¶ 256–257, 259).
As an initial matter, for the reasons set forth in Section III.C above,
we conclude that the term “conversational flow” is not client- or user-
specific. Further, notwithstanding Patent Owner’s arguments that Riddle is
concerned with bandwidth management rather than network monitoring (see
PO Resp. 40–43; Sur-reply 13–14), obviousness does not require that the
prior art address the same problem identified by the patent. See KSR, 550
U.S. at 419 (“[N]either the particular motivation nor the avowed purpose of
the patentee controls . . . . What matters is the objective reach of the claim.
If the claim extends to what is obvious, it is invalid.”); Outdry Techs. Corp.
v. Geox S.p.A., 859 F.3d 1364, 1371 (Fed. Cir. 2017) (“The motivation
supported by the record . . . need not be the same motivation articulated in
the patent.”).
Further, contrary to Patent Owner’s contentions (PO Resp. 43–44;
Sur-reply 16), neither the Board’s construction of “conversational flow” nor
IPR2020-00338
Patent 6,839,751 B1
41
Patent Owner’s proposed construction requires “bidirectional” exchanges of
packets (see supra § III.C; PO Resp. 23–26). Both the Board’s adopted
construction and Patent Owner’s proposed construction recite, inter alia,
“the sequence of packets that are exchanged in any direction as a result of an
activity.” Supra § III.C (emphasis added); PO Resp. 23–26. The phrase “in
any direction” is not limited to bidirectional packet flows but also
encompasses unidirectional flows. As Petitioner points out, this
interpretation is consistent with the declaration of Patent Owner’s expert,
Ms. Quigley, stating that conversational flows “can,” rather than “must,”
include bidirectional exchanges. Ex. 2061 ¶ 83 (cited in Reply 12 n.41).
Regardless, we further agree with Petitioner that Riddle’s disclosure that all
traffic in a particular conversation between a client and a server is classified
into a single service aggregate teaches bidirectional exchange. Reply 12–13
(citing Ex. 1008, 11:12–19, 12:1–12, 13:54–59); see also Pet. 40–42
(mapping Riddle’s service aggregates to the claimed conversational flows
and stating that Riddle’s “Table 3 specifies detecting services in ‘both
directions’”).
Having concluded that Riddle teaches the recited conversational
flows, we are further persuaded by Petitioner’s arguments that a person of
ordinary skill in the art would have found it obvious in view of the combined
teachings of Riddle and Ferdinand to store flow-entries for previously
encountered conversational flows in a database. See Pet. 37–39. Riddle
discloses storing flow entries in its series of lists 308 that include a plurality
of flow-entries encountered by the monitor, and Petitioner persuasively
argues with the support of Dr. Weissman’s testimony that a person of
ordinary skill in the art would have been motivated, based either on Riddle’s
own disclosure of relational database 306 or on the teachings of Ferdinand,
IPR2020-00338
Patent 6,839,751 B1
42
to implement Riddle’s saved flow-entries in a database, in order, for
example, to increase functionalities in furtherance of Riddle’s desired goal
of determining whether the packet monitor has received duplicate flow-
entries. See id. (citing, e.g., Ex. 1008, 6:1–15, 10:1–18 (Table 2), 12:32–38,
12:53–57, 12:61–13:9, 14:1–5, 15:1–15, Fig. 4A; Ex. 1009, 23:19–23,
27:16–19, 28:14–24, 54:13–17, 60:10–15, Fig. 22; Ex. 1006 ¶¶ 335–339,
768). Because the asserted ground is based on the combination of Riddle
and Ferdinand, Patent Owner’s arguments that Ferdinand does not
individually teach storing flow-entries in a database are unpersuasive. See
Bradium Techs. LLC v. Iancu, 923 F.3d 1032, 1050 (Fed. Cir. 2019)
(holding that arguments that “attack the disclosures of the two references
individually” cannot overcome a ground premised on the combination of
those references (citing In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir.
1986) (“Non-obviousness cannot be established by attacking references
individually where the rejection is based upon the teachings of a
combination of references.”))).
Accordingly, we are persuaded that Petitioner has shown by a
preponderance of the evidence that the recited limitations are taught by the
combination of Riddle and Ferdinand.
d. Conversational Flow State Limitations (Claims 1 and 17)
Claims 1 and 17 of the ’751 patent each further recite, in part,
a conversational flow including an exchange of a sequence of
one or more packets in any direction between two network
entities as a result of a particular activity using a particular
layered set of one or more network protocols, a conversational
flow further having a set of one or more states, including an
initial state.
Ex. 1004, 50:32–38 (claim 1), 52:7–12 (claim 17). Claim 1 further recites,
IPR2020-00338
Patent 6,839,751 B1
43
(c) if the packet is of an existing flow, identifying the last
encountered state of the flow, performing any state operations
specified for the state of the flow, and updating the flow-entry of
the existing flow including storing one or more statistical
measures kept in the flow-entry; and
(d) if the packet is of a new flow, performing any state operations
required for the initial state of the new flow and storing a new
flow-entry for the new flow in the flow-entry database, including
storing one or more statistical measures kept in the flow-entry.
Ex. 1004, 50:40–50. Similarly, claim 17 further recites,
(c) an analyzer subsystem coupled to the packet acquisition
device configured to lookup for each received packet whether a
received packet belongs to a flow-entry in the flow-entry
database, to update the flow-entry of the existing flow including
storing one or more statistical measures kept in the flow-entry in
the case that the packet is of an existing flow, and to store a new
flow-entry for the new flow in the flow-entry database, including
storing one or more statistical measures kept in the flow-entry if
the packet is of a new flow.
Ex. 1004, 52:13–22.
(1) The Parties’ Arguments
Petitioner persuasively argues that Riddle teaches “a conversational
flow . . . having a set of one or more states, including an initial state,” as
recited in claim 1. Pet. 49. First, Petitioner argues that Riddle teaches a
monitor that “classifies flows by ‘a series of steps through a traffic class
tree.’” Pet. 49 (citing Ex. 1008, 9:20–25; Ex. 1006 ¶ 129). According to
Petitioner, “[s]uch class trees are a common data classification structure,”
which include flow states. Id. (citing Ex. 1006 ¶ 348). Riddle’s Figure 2A,
shown below as annotated by Petitioner, illustrates an exemplary
classification tree. Ex. 1008, 4:43–44; see also Pet. 51 (annotating Ex. 1008,
Fig. 2A).
IPR2020-00338
Patent 6,839,751 B1
44

Figure 2A depicts a “representative division[] of bandwidth,” in accordance
with Riddle’s teachings. Ex. 1008, 4:43–44. Petitioner argues that Riddle
teaches department checks (shown in yellow). Pet. 50. More specifically,
Petitioner argues that Riddle’s “classifier[, inter alia,] initially tests if the
flow is intended for Department B (204) by comparing the packet’s source
(client) IP to the range of IP addresses defined for subnet B.” Id. (citing
Ex. 1008, 10:19–39; Ex. 1006 ¶ 349). If so, the classifier proceeds to the
next step (shown in blue) to test if the flow is for File Transfer Protocol
(“FTP”) (210), according to Petitioner. Id.
Petitioner also argues, and we agree, that Riddle teaches displaying a
hierarchical classification tree that lists state operations related to FTP (e.g.,
to host 1, tcp, and FTP). Pet. 57 (citing Ex. 1008, 13:11–22;
Ex. 1006 ¶¶ 351, 780, 781). According to Petitioner, one of ordinary skill in
the art would have understood that this hierarchy involves state operations.
Id. (citing Ex. 1006 ¶¶ 351, 781). Further, Petitioner contends, Packer,
incorporated by reference in Riddle, “describes traversing a set of predefined
IPR2020-00338
Patent 6,839,751 B1
45
states by recursively processing though matching child-class definitions.”
Id. at 52–53 (citing Ex. 1008, 1:38–44; Ex. 1031, 18:1–26, Fig. 5F; Ex. 1006
¶ 777).
Regarding the “existing flow” recitations of claims elements 1(c)
and 17(c) reproduced above, Petitioner contends that “Riddle teaches
performing state operations of determining statistical metrics such as
duplicate count, most recent encounter with traffic with same identifying
characteristics, and byte count” and further “teaches identifying and storing
such metrics for existing conversation flows.” Pet. 56 (citing Ex. 1008,
12:42–13:8, 14:1–5, Fig. 4A; Ex. 1006 ¶¶ 778, 779). Further, Petitioner
contends, Riddle describes displaying a hierarchical classification tree that
shows state operations related to FTP, and a person of ordinary skill in the
art would have understood that transitioning from one class to the next in
Riddle’s hierarchy involves state operations. Id. at 57 (citing Ex. 1008,
13:11–22; Ex. 1006 ¶¶ 351, 780, 781). Petitioner argues that Riddle’s
Figure 4A “describes analyzing information identifying the characteristics of
the traffic as the classifier parses the flow’s packets and matching the parsed
packets to a class.” Id. (citing Ex. 1008, 12:42–48). According to
Petitioner, “Riddle’s classifier advances through the sequence of packets of a
particular flow to parse and classify those packets” in accordance with the
classification tree, “result[ing] in Riddle’s classifier performing a
corresponding state operation at each node to update the identifying
characteristics of the flow.” Id. (citing Ex. 1006 ¶ 782). According to
Petitioner, Riddle thus teaches the recited elements because Riddle’s
monitor identifies the last encountered state of the flow and performs any
state operations specified for the state of the flow for existing flows. Id.
IPR2020-00338
Patent 6,839,751 B1
46
at 57–58 (citing Ex. 1008, 12:53–13:8, 13:42–47, 14:1–5, 16:40–48
(claim 5), Figs. 4A, 4B; Ex. 1006 ¶¶ 778–783, 846).
Regarding the “new flow” recitations of claims elements 1(d)
and 17(c), Petitioner contends that Riddle alone or in view of Ferdinand
renders these recitations obvious. Pet. 58–59. In particular, Petitioner
contends that, “[f]or new flow-entries, Riddle discloses the state operation of
creating a new flow-entry such as Figure 4A’s step 408 and new class in
Figure 4B’s step 425 for service aggregate classes.” Id. at 58. Relying on
Dr. Weissman’s testimony, Petitioner contends that a person of ordinary
skill in the art “would have understood that Riddle’s creation of a new flow-
entry and a new class are examples of state operations for the initial state of
the newly encountered conversational flow.” Id. (citing Ex. 1006 ¶¶ 780,
784–786). According to Petitioner, for new flow-entries, “Riddle teaches
performing state operations of determining statistical metrics such as
duplicate count, most recent encounter with traffic with same identifying
characteristics, and byte count.” Id. at 56 (citing Ex. 1008, 12:42–13:8,
14:1–5, Fig. 4A; Ex. 1006 ¶¶ 778, 779). Petitioner further contends that
“Riddle discloses the state operations of updating flow-entries and
determining metrics (e.g., determining whether flow matches a traffic class
in relation to classifying a service aggregate, duplicate count, most recent
encounter with traffic with same identifying characteristics, and byte
count),” and that “these metrics are stored in the saved list.” Id. at 58–59
(citing Ex. 1008, 12:30–59). Petitioner argues that the ’751 patent and
related patents “acknowledge that determining metrics is a state operation,”
and, relying on Dr. Weissman’s testimony, that a person of ordinary skill in
the art would have understood that each of such state operations “is an
IPR2020-00338
Patent 6,839,751 B1
47
example of state operations for the initial state of a new conversation.” Id.
at 59 (citing Ex. 1006 ¶¶ 770–783, 787, 788), 59 n.184.
With respect specifically to the “analyzer subsystem” recited in
claim 17, Petitioner contends that Riddle alone or in view of Ferdinand
renders obvious a packet acquisition device configured to look up whether a
received packet belongs to a flow-entry in the flow-entry database. Pet. 54
(citing Ex. 1006 ¶¶ 340–344, 649–653, 766–769, 842, 843, 845). For
example, according to Petitioner, Figure 4B of Riddle shows that “Riddle
looks up whether a flow matches a traffic class in relation to classifying a
service aggregate based on a plurality of indicators,” while steps 410 and
412 of Riddle’s Figure 4A shows that “Riddle checks if the flow is a new
flow or an existing flow.” Id. (citing Ex. 1008, 12:53–60, 13:42–47,
Figs. 4A, 4B; Ex. 1006 ¶¶ 132, 342). Further, Petitioner contends, Riddle
discloses the recited “analyzer subsystem,” citing Riddle’s disclosure of “a
processor means operative to: parse a packet into a first flow specification.”
Id. at 55 (quoting Ex. 1008, 16:61–62 (claim 8)). According to Petitioner,
“Riddle’s processor has programming code for performing lookup functions,
and performs the function of matching a parsed flow specification to a traffic
class” and “Riddle’s Figure 1A shows that its system includes processor 30
coupled to memory subsystem 35.” Id. (citing Ex. 1008, 5:53–57, 6:1–15,
16:54–17:15 (claim 8), Fig. 1A; Ex. 1006 ¶¶ 343, 409).
In response to Petitioner’s arguments, Patent Owner contends that the
prior art does not teach conversational flow state-based analysis. PO
Resp. 53–57. According to Patent Owner, “Riddle relates to classifying
traffic based on an individual packet in the flow, rather than on a state of
the flow (i.e., evaluation across multiple packets).” Id. at 53. More
particularly, Patent Owner contends, “Riddle views each packet as an
IPR2020-00338
Patent 6,839,751 B1
48
independent and unique occurrence and focuses on evaluating that packet—
in isolation—to determine whether a given category of traffic has
encountered a ‘hit.’” Id. (citing Ex. 2061 ¶¶ 62–65, 80–83). According to
Patent Owner, “[t]he teachings of Riddle relied on by Petitioner[] show
Riddle stepping through a hierarchical traffic class tree to classify a packet,”
but “this analysis turns solely on an individual packet’s information and
‘multiple orthogonal classification attributes.’” Id. (citing Ex. 1008,
Fig. 2A, 9:16–18, 9:20–25, 10:20–39). Patent Owner contends, “Riddle
does not analyze a packet based on the context provided by previously
encountered packets.” Id. at 53–54. Because “Riddle’s evaluation turns
based on the ‘information’ and ‘attributes’ in an individual packet, as
opposed to relying on the context and relationship of various packets with
one another,” Patent Owner argues, “Riddle has no concept of ‘state of the
flow.’” Id. at 55–56. Finally, citing the Board’s findings in related
proceedings that Riddle does not teach state transition patterns or “the state
of [a] conversational flow of [a] packet being indicative of the sequence of
any previously encountered packet of the same conversational flow,” Patent
Owner further contends that the Board already rejected arguments mirroring
those raised by Petitioner in this proceeding with respect to this limitation.
Id. at 56–57 (citing IPR2020-00335, Paper 19 at 19–20 (PTAB Aug. 27,
2020); IPR2020-00336, Paper 21 at 48–49 (PTAB Sept. 10, 2020)).
In its Reply, Petitioner points out that, in contrast to the limitations at
issue in the related proceedings cited by Patent Owner, claim 1 [of the
’751 patent] recites “[receiving a packet] . . . a conversational flow including
an exchange of one or more packets . . . (c) if the packet is of an existing
flow, identifying the last encountered state of the flow, . . . [and] (d) if the
packet is of a new flow, performing any state operations required . . . .”
IPR2020-00338
Patent 6,839,751 B1
49
Reply 15. Thus, Petitioner contends, “[c]laim 1 recites a method of
receiving only a first packet for a new flow that has an initial state; the
operations of step (c) aren’t required, as a result of the ‘if’ statement.” Id.
Similarly, Petitioner contends, “independent claim 17 merely specifies that a
conversational flow has ‘one or more states,’ such as an initial state.” Id.
Petitioner contends that “[t]hese limitations refer to the [’751] patent’s
embodiments whereby information from an individual packet is sufficient
for the state-based analysis of a conversational flow” and “[n]one of these
limitations requires state transitions to occur across a sequence of packets.”
Id. at 15–16. Furthermore, Petitioner argues, even if the state-related
limitations required analyzing more than one packet, Riddle would meet
them by its disclosure of classifying service aggregates based on a plurality
of indicators across multiple packets. Id. at 16–18 (citing, e.g., Ex. 1008,
11:11–20, 11:66–67, 12:42–63, 13:40–59, Fig. 4B, claim 5; Ex. 1006
¶¶ 120, 121, 132, 291, 299, 330, 332, 351, 353–357, 360, 361, 366–369,
556, 568).
In its Sur-reply, Patent Owner responds that “Riddle’s analysis turns
solely on evaluating the characteristics of an individual packet, rather than
processing a packet in light of the context provided by previously
encountered packets.” Sur-reply 19 (citing Ex. 1008, Fig. 2A, 9:16–18,
9:20–25, 10:20–39). Again citing the Board’s non-institution decision in
IPR2020-00335, Patent Owner further contends that “[t]he Board confirmed
in a related proceeding that ‘although Riddle teaches classifying multiple
packets in a flow, this classification occurs serially on an individual packet
by packet basis, rather than relying on state transitions across multiple
packets.’” Id. (citing IPR2020-00335, Paper 19 at 19–20). Further,
responding to Petitioner’s citation of Riddle’s “classification process” as
IPR2020-00338
Patent 6,839,751 B1
50
teaching the state limitations of claim 1 (Reply 16–18), Patent Owner argues
that “simply recording ‘identifying characteristics’ about each packet
received does not equate to identifying the last state of a conversational
flow.” Id. at 20. To the contrary, Patent Owner contends, “Riddle’s analysis
and categorization of packets turns solely on an individual packet’s
information and ‘multiple orthogonal classification attributes.’” Id. at 20–21
(citing Ex. 1008, Fig. 2A, 9:16–18, 9:20–25, 10:20–39).
(2) Analysis
Having considered the parties’ respective contentions, we find that
Petitioner’s assertions are supported by the cited evidence and are persuasive
that the combination of Riddle and Ferdinand teaches the recited limitation
for the reasons presented by Petitioner, which we adopt. We agree with
Petitioner that the disputed limitations differ substantially from the
limitations that were at issue in the related proceedings cited by Patent
Owner and that the differences are significant with respect to our analysis.
Notably, the Board did not find in either of those related proceedings that
Riddle fails to disclose conversational flows “having . . . states,” as recited in
independent claims 1 and 17 of the ’751 patent, or “identifying” such states
and “performing . . . [specified] state operations,” as recited in claim 1.
Instead, the Board found, for example, that Petitioner had not sufficiently
shown that the asserted prior art teaches or suggests “state transition
patterns” across multiple packets (IPR2020-00335, Paper 19 at 14–22
(emphasis added)). That limitation does not appear in claim 1 or claim 17 of
the ’751 patent. Moreover, we agree with Petitioner that information only
from an individual packet is required for the state-based analysis recited in
claim 1 and that the claim does not require state transitions to occur across a
sequence of packets. See Reply 15. In particular, claims 1 and 17 recite “a
IPR2020-00338
Patent 6,839,751 B1
51
conversational flow including an exchange of a sequence of one or more
packets.” Ex. 1004, 50:32–33, 52:7–8 (emphasis added). And thus
information only from an individual packet is required (i.e., “one” packet is
covered) for claims 1 and 17 of the ’751 patent. In contrast, the
corresponding limitation that was at issue in the related proceedings recited
“a sequence of packets” (i.e., in plural form). See Ex. 1001, 35:34–35
(reciting limitation in claim 1 of the ’099 patent).
Accordingly, we are persuaded that Petitioner has shown by a
preponderance of the evidence that the recited limitations are taught by the
combination of Riddle and Ferdinand.
e. Remaining Limitations of Claims 1 and 17
Supported by the testimony of Dr. Weissman, Petitioner contends, and
we agree, that Riddle discloses each of the remaining limitations of claims 1
and 17. Pet. 59–61 (citing Ex. 1006 ¶¶ 266–268, 270–276, 624–626, 789–
794; Ex. 1008, 4:1–2, 4:16–17, 6:5–15, 7:21–34, 10:52–11:9, 12:30–41,
12:50–59, 13:1–31, 13:59–60, 16:54–17:15 (claim 8), Figs. 1A–1C, 3;
Ex. 1031, 4:12–16, 18:58–62), 62–65 (citing Ex. 1006 ¶¶ 283–293, 795–
802, 848; Ex. 1008, code (57), 1:54–57, 3:36–39, 4:7–15, 4:60–66, 7:35–
8:67, 9:1–27, 9:64–65, 10:57–11:6, 12:64–13:23); Pet. 66 (citing Ex. 1006
¶¶ 767–777, 803–805, 849, 850). Patent Owner does not dispute Petitioner’s
contentions regarding these limitations. See generally PO Resp.
Petitioner’s assertions are supported by the cited evidence and are
persuasive. Accordingly, we are persuaded that Petitioner has shown by a
preponderance of the evidence that each of the recited limitations is taught
by Riddle and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these undisputed limitations of
claims 1 and 17 as our own findings. NuVasive, 841 F.3d at 974.
IPR2020-00338
Patent 6,839,751 B1
52
2. Dependent Claim 2
Claim 2 of the ’751 patent depends from claim 1 and further recites,
“wherein step (b) includes extracting identifying portions from the packet,
wherein the extracting at any layer level is a function of the protocol being
used at the layer level, and wherein the looking up uses a function of the
identifying portions.” Ex. 1004, 50:61–67. Petitioner contends, and we
agree, that Riddle discloses each of these further limitations. Pet. 67–71
(citing Ex. 1008, code (57), 1:54–57, 4:7–15, 4:60–66, 7:35–9:27, 9:64–65,
12:42–59, 13:36–62, Figs. 1D, 4A, 4B; Ex. 1006 ¶¶ 806–816).
Patent Owner does not dispute Petitioner’s contentions regarding the
limitations recited in claim 2. See generally PO Resp.
Petitioner’s assertions are supported by the cited evidence and are
persuasive. We are persuaded that Petitioner has shown by a preponderance
of the evidence that these undisputed limitations are taught by the asserted
prior art and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these limitations as our own
findings. NuVasive, 841 F.3d at 974.
3. Dependent Claim 5
Claim 5 of the ’751 patent depends from claim 1 and further recites,
“further including reporting one or more metrics related to the flow of a
flow-entry from one or more of the statistical measures in the flow-entry.”
Ex. 1004, 51:9–12. Relying on disclosure in Riddle of reporting metrics by
displaying results to a network manager, Petitioner contends, and we agree,
that Riddle teaches this further limitation. Pet. 71–72 (citing Ex. 1008,
12:64–13:1, 14:1–5; Ex. 1006 ¶¶ 817, 818).
Patent Owner does not dispute Petitioner’s contentions regarding the
limitation recited in claim 5. See generally PO Resp.
IPR2020-00338
Patent 6,839,751 B1
53
Petitioner’s assertions are supported by the cited evidence and are
persuasive. We are persuaded that Petitioner has shown by a preponderance
of the evidence that the recited limitation is taught by the asserted prior art
and adopt the contentions set forth in the Petition and in Dr. Weissman’s
Declaration as mapped to this undisputed limitation as our own findings.
NuVasive, 841 F.3d at 974.
4. Dependent Claim 10
Claim 10 of the ’751 patent depends from claim 1 and further recites,
wherein step (c) includes if the packet is of an existing flow,
identifying the last encountered state of the flow and performing
any state operations specified for the state of the flow starting
from the last encountered state of the flow; and wherein step (d)
includes if the packet is of a new flow, performing any state
operations required for the initial state of the new flow.
Ex. 1004, 51:25–31. Petitioner contends, and we agree, that Riddle
discloses each of these further limitations, relying in part on its contentions
discussed in Sections III.E.1.d above. Pet. 72–74 (citing Ex. 1008, 11:25–
31, 12:30–59, 13:1–8, 13:11–22, 13:36–62, 14:1–5, Figs. 4A, 4B; Ex. 1006
¶¶ 778–788, 819–825). Petitioner contends that these limitations are taught
by Riddle, asserting that Riddle discloses “pars[ing] packet portions to
identify a signature (i.e., identifying information) and stor[ing] the signature
extracted from [the] parsed packet portion[s] for identifying future packets,”
as well as “using identifying information that includes selected portions of
the packet to identify future packets to suppress duplicates of previously
identified packet flows.” Pet. 79–80 (citing Ex. 1006 ¶¶ 746–750; Ex. 1008,
12:42–59, Fig. 4A).
Apart from its arguments with respect to the conversational flow state
limitations recited in claim 1, discussed above (see supra § III.E.1.d), Patent
IPR2020-00338
Patent 6,839,751 B1
54
Owner does not dispute Petitioner’s contentions regarding the limitations
recited in claim 10. See generally PO Resp.
Petitioner’s assertions are supported by the cited evidence and are
persuasive. We are persuaded that Petitioner has shown by a preponderance
of the evidence that these undisputed limitations are taught by the asserted
prior art and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these limitations as our own
findings. NuVasive, 841 F.3d at 974.
5. Dependent Claim 14
Claim 14 of the ’751 patent depends from claim 10 and further recites
“wherein the state operations include updating the flow-entry, including
storing identifying information for future packets to be identified with the
flow-entry.” Ex. 1004, 51:41–44. Petitioner contends, and we agree, that
Riddle teaches this further limitation, relying in part on its contentions
discussed in Section III.E.1.d above. Pet. 74–75 (citing Ex. 1008, 12:53–59,
13:36–62, Figs. 4A, 4B; Ex. 1006 ¶¶ 826–831).
Apart from its arguments with respect to the conversational flow state
limitations recited in claim 1, discussed above (see supra § III.E.1.d), Patent
Owner does not dispute Petitioner’s contentions regarding the limitation
recited in claim 14. See generally PO Resp.
Petitioner’s assertions are supported by the cited evidence and are
persuasive. We are persuaded that Petitioner has shown by a preponderance
of the evidence that the recited limitation is taught by the asserted prior art
and adopt the contentions set forth in the Petition and in Dr. Weissman’s
Declaration as mapped to this undisputed limitation as our own findings.
NuVasive, 841 F.3d at 974.
IPR2020-00338
Patent 6,839,751 B1
55
6. Dependent Claim 15
Claim 15 of the ’751 patent depends from claim 14 and further recites
“further including receiving further packets, wherein the state processing of
each received packet of a flow furthers the identifying of the application
program of the flow.” Ex. 1004, 51:45–48. Relying on disclosure in Riddle
of receiving multiple packets of a flow and classifying such packets based
on both a transport-layer protocol and an application-layer protocol,
Petitioner contends, and we agree, that Riddle teaches these further
limitations. Pet. 75–77 (citing Ex. 1008, 2:2–29, 10:1–18, 10:59–65,
Figs. 1B, 1C; Ex. 1006 ¶¶ 832–839).
Apart from its arguments with respect to the conversational flow state
limitations recited in claim 1, discussed above (see supra § III.E.1.d), Patent
Owner does not dispute Petitioner’s contentions regarding the limitations
recited in claim 15. See generally PO Resp.
Petitioner’s assertions are supported by the cited evidence and are
persuasive. We are persuaded that Petitioner has shown by a preponderance
of the evidence that these undisputed limitations are taught by the asserted
prior art and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these limitations as our own
findings. NuVasive, 841 F.3d at 974.
7. Conclusion Regarding Ground 1
For the foregoing reasons, we conclude that Petitioner has shown by a
preponderance of the evidence that the subject matter of claims 1, 2, 5, 10,
14, 15, and 17 is unpatentable as obvious over the combination of Riddle
and Ferdinand.
IPR2020-00338
Patent 6,839,751 B1
56
F. Obviousness over Riddle, Ferdinand, and Yu, or over Riddle,
Ferdinand, and RFC1945
Petitioner contends that claims 1, 2, 5, 10, 14, 15, and 17 also would
have been obvious over the combination of Riddle and Ferdinand in further
view of Yu or RFC1945. See Pet. 77–83 (Riddle in view of Ferdinand and
Yu); id. at 83–92 (Riddle in view of Ferdinand and RFC1945). Having
determined that Petitioner establishes by a preponderance of the evidence
that the subject matter of each of the challenged claims would have been
obvious over the combination of Riddle and Ferdinand, we need not address
Petitioner’s additional grounds challenging these claims. See SAS Inst. Inc.
v. Iancu, 138 S. Ct. 1348, 1359 (2018) (holding that a petitioner “is entitled
to a final written decision addressing all of the claims it has challenged”);
Boston Sci. Scimed, Inc. v. Cook Grp. Inc., 809 F. App’x 984, 990 (Fed. Cir.
2020) (nonprecedential) (“We agree that the Board need not address
[alternative grounds] that are not necessary to the resolution of the
proceeding.”).
IV. CONCLUSION12
Based on the evidence presented with the Petition, the evidence
introduced during the trial, and the parties’ respective arguments, Petitioner

12 Should Patent Owner wish to pursue amendment of the challenged claims
in a reissue or reexamination proceeding subsequent to the issuance of this
decision, we draw Patent Owner’s attention to the April 2019 Notice
Regarding Options for Amendments by Patent Owner Through Reissue or
Reexamination During a Pending AIA Trial Proceeding. 84 Fed. Reg.
16,654 (Apr. 22, 2019). If Patent Owner chooses to file a reissue application
or a request for reexamination of the challenged patent, we remind Patent
Owner of its continuing obligation to notify the Board of any such related
matters in updated mandatory notices. See 37 C.F.R. § 42.8(a)(3), (b)(2).
IPR2020-00338
Patent 6,839,751 B1
57
has shown by a preponderance of the evidence that each of claims 1, 2, 5,
10, 14, 15, and 17 of the ’751 patent is unpatentable.
V. ORDER
Accordingly, it is
ORDERED that claims 1, 2, 5, 10, 14, 15, and 17 of U.S. Patent
No. 6,839,751 B1 are held unpatentable under 35 U.S.C. § 103 as obvious;
and
FURTHER ORDERED that, because this is a Final Written Decision,
parties to the proceeding seeking judicial review of this decision must
comply with the notice and service requirements of 37 C.F.R. § 90.2.
In summary:

13 As explained above, we do not reach this ground. See supra § III.F.
14 As explained above, we do not reach this ground. See supra § III.F.
Claim(s)

35
U.S.C. §
Reference(s)/Basis Claims
Shown
Unpatentable
Claims
Not shown
Unpatentable
1, 2, 5, 10, 14,
15, 17
103(a) Riddle, Ferdinand 1, 2, 5, 10, 14,
15, 17

1, 2, 5, 10, 14,
15, 17
103(a) Riddle, Ferdinand,
Yu13

1, 2, 5, 10, 14,
15, 17
103(a) Riddle, Ferdinand,
RFC194514

Overall
Outcome
1, 2, 5, 10, 14,
15, 17

IPR2020-00338
Patent 6,839,751 B1
58
FOR PETITIONER:
Joseph F. Edell
Adam A. Allgood
FISCH SIGLER LLP
joe.edell.ipr@fischllp.com
adam.allgood@fischllp.com

Scott A. McKeown
James R. Batchelder
Mark D. Rowland
Andrew Radsch
ROPES & GRAY LLP
scott.mckeown@ropesgray.com
james.batchelder@ropesgray.com
mark.rowland@ropesgray.com
andrew.radsch@ropesgray.com

FOR PATENT OWNER:
R. Allan Bullwinkel
Michael Heim
HEIM PAYNE & CHORUSH, LLP
abullwinkel@hpcllp.com
mheim@hpcllp.com