Packet Intelligence LLC

Patent Trials and Appeals Board

Sep 9, 2021

IPR2020-00486 (P.T.A.B. Sep. 9, 2021)

Trials@uspto.gov Paper 47
571-272-7822 Date: September 9, 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-00486
Patent 6,954,789 B2

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

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

IPR2020-00486
Patent 6,954,789 B2
2
I. INTRODUCTION
This is a Final Written Decision in an inter partes review challenging
the patentability of claims 31, 33, and 34 (“the challenged claims”) of U.S.
Patent No. 6,954,789 B2 (Ex. 1005, “the ’789 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 claims 31 and 33 are unpatentable, but has not shown by a
preponderance of the evidence that claim 34 is 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 an inter partes
review of claims 31, 33, and 34 of U.S. Patent No. 6,954,789 B2 (Ex. 1005,
“the ’789 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 10, 2020, pursuant to 35 U.S.C. § 314(a), we instituted
trial to determine whether any challenged claim of the ’789 patent is
unpatentable based on the grounds raised in the Petition:

1 On our authorization (Paper 8), Petitioner also filed a Preliminary
Reply (Paper 9) and Patent Owner filed a Preliminary Sur-Reply (Paper 10)
related to discretionary denial of institution under 35 U.S.C. § 314(a).
IPR2020-00486
Patent 6,954,789 B2
3
Claim(s) Challenged 35 U.S.C. §2 References
31 103(a) Riddle,3 Ferdinand,4 Baker5
33, 34 103(a) Riddle, Ferdinand, Wakeman6
31 103(a) Riddle, Ferdinand, Baker, Yu7
33, 34 103(a) Riddle, Ferdinand, Wakeman,
Yu
31 103(a) Riddle, Ferdinand, Baker,
RFC19458
33, 34 103(a) Riddle, Ferdinand, Wakeman,
RFC1945
Paper 20, 9, 53 (“Institution Decision” or “Inst. Dec.”).9

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
’789 patent issued from an application filed before March 16, 2013, we
apply the pre-AIA version of the statutory basis for unpatentability.
3 U.S. Patent No. 6,412,000 B1 (issued June 25, 2002) (“Riddle”)
(Ex. 1008).
4 PCT Published Application No. WO 92/19054 (published Oct. 29,
1992) (“Ferdinand”) (Ex. 1009).
5 PCT Published Application No. WO 97/23076 (published
June 26, 1997) (“Baker”) (Ex. 1013).
6 U.S. Patent No. 5,740,175 (issued April 14, 1998)
(“Wakeman”) (Ex. 1014).

7 U.S. Patent No. 6,625,150 B1 (issued Sept. 23, 2003) (“Yu”)
(Ex. 1011).

8 T. Berners-Lee et al., Hypertext Transfer Protocol -- HTTP/1.0,
Request for Comments 1945, Network Working Group (May 1996)
(“RFC1945”) (Ex. 1010).
9 Patent Owner filed a Request for Rehearing of the Institution
Decision (Paper 24), which we denied (Paper 26).
IPR2020-00486
Patent 6,954,789 B2
4
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 30
(“Reply”). Patent Owner filed a Sur-Reply. Paper 31 (“Sur-Reply”).
A combined oral hearing in this proceeding, IPR2020-00338
(involving a patent related to the ’789 patent), and IPR2020-00339
(involving other claims of the ’789 patent) was held on June 9, 2021. A
transcript of the hearing is included in the record. Paper 45 (“Tr.”). A
transcript of an oral hearing held the same day in cases IPR2020-00336 and
IPR2020-00337, also involving patents related to the ’789 patent, is also
included in the record of this proceeding.10 Paper 46.
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 40 (“Order”). Petitioner and Patent Owner each filed
respective Opening Briefs on claim construction. See Paper 41
(“Petitioner’s Opening Brief” or “Pet. Br.”); Paper 42 (“Patent Owner’s
Opening Brief” or “PO Br.”). Petitioner filed a Responsive Brief to Patent
Owner’s Opening Brief, Paper 43 (“Petitioner’s Responsive Brief” or “Pet.
Resp. Br.”), and Patent Owner filed a Responsive Brief to Petitioner’s
Opening Brief, Paper 44 (“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

10 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 46, 7:15–8:5.
IPR2020-00486
Patent 6,954,789 B2
5
Intelligence LLC and Packet Intelligence Holdings LLC as its real parties in
interest. Paper 5, 2.
C. Related Matters
The parties identify three district court litigations as related matters
that involve the ’789 patent or a related patent: Packet Intelligence LLC v.
Juniper Networks, Inc., 3:19-cv-04741 (N.D. Cal.); Palo Alto Networks, Inc.
v. Packet Intelligence LLC, No. 3:19-cv-02471 (N.D. Cal); and Packet
Intelligence LLC v. NetScout Systems, Inc., 2:16-cv-230-JRG (E.D. Tex.).
Pet. 1; Paper 5, 2. The parties also identify Packet Intelligence LLC v.
NetScout Sys., Inc., No. 19-2041 (Fed. Cir.) as involving patents related to
the ’789 patent. Pet. 1; Paper 5, 2.
In addition to the present proceeding, the ’789 patent is also the
subject of an inter partes review proceeding in IPR2020-00339, which
challenges claims 1, 2, 13–17, 19, 20, 42, 44, 48, and 49 of the ’789 patent.
A Final Decision in that proceeding is issued concurrently with this Final
Decision.
Related U.S. Patent 6,839,751 B1 is the subject of an inter partes
review proceeding in IPR2020-00338; related U.S. Patent 6,665,725 B1 is
the subject of an inter partes review proceeding in IPR2020-00336; and
related U.S. Patent 6,771,646 B1 is the subject of an inter partes review
proceeding in IPR2020-00337. Pet. 1–2; Paper 5, 2–3. Final Written
Decisions in those proceedings are issued concurrently with this Final
Decision.
Lastly, the parties identify the following related matters that are no
longer pending before the Board: (i) IPR2017-00629; IPR2017-00630; and
IPR2019-01293, which challenged claims of the ’789 patent; and
(ii) IPR2017-00450; IPR2017-00451; IPR2017-00769; IPR2017-00862;
IPR2020-00486
Patent 6,954,789 B2
6
IPR2017-00863; IPR2019-01289; IPR2019-01290; IPR2019-01291;
IPR2019-01292; IPR2020-00335; and IPR2020-00485, which challenged
claims of patents related to the ’789 patent. Pet. 1–2; Paper 5, 3–5.
D. The ’789 Patent (Ex. 1005)
The ’789 patent, titled “Method and Apparatus for Monitoring Traffic
in a Network,” relates to “[a] monitor for and a method of examining
packets passing through a connection point on a computer network.”
Ex. 1005, codes (54), (57). The ’789 patent states that “[t]here has long
been a need for network activity monitors.” Id. at 1:55. According to the
’789 patent, a network activity monitor monitors interconnected networks
and collects data on objective information, such as “which services (i.e.,
application programs) are being used, who is using them, how often they
have been accessed, and for how long.” Id. at 1:63–66. This information,
the ’789 patent states, “is very useful in the maintenance and continued
operation of these networks.” Id. at 1:66–67. A real-time network monitor
may also “provide alarms notifying selected users of problems that may
occur with the network or site.” Id. at 2:3–5.
The ’789 patent’s network activity 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 identify this packet as part of a flow, “build[ing] a unique
flow signature (also called a ‘key’) for this flow,” and “matching this flow in
a database of known flows.” Id. at 9:6–9, 13:21–28, 13:60–65.
Figure 3, reproduced below, depicts various components of the
network packet monitor 300, including parser subsystem 301, analyzer
subsystem 303, and database of known flows 324. Id. at 11:49–16:52.
IPR2020-00486
Patent 6,954,789 B2
7

Figure 3 “is a functional block diagram of a process embodiment
of the present invention that can operate as the packet monitor.”
Ex. 1005, 7:56–59.
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 “build[s] a unique flow signature (also called a ‘key’)
for this flow.” Id. at 12:19–24, 13:27–29; see also id. at 32:38–34:20
(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-00486
Patent 6,954,789 B2
8
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. Id. at 13:60–16:52. The ’789 patent discloses that:
Future 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—can 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 16:17–34.
E. The Challenged Claims
Petitioner challenges claims 31, 33, and 34 of the ’789 patent. Pet. 8.
Each of these claims depends, directly or indirectly, from independent claim
19 of the ’789 patent. Although claim 19 is challenged in co-pending
IPR2020-00339 (see supra § II.B), not in this proceeding, claim 19 is
illustrative of the subject matter claimed in the ’789 patent and is reproduced
below to provide context for the challenged claims. Claim 19 recites:
19. A packet monitor for examining packets passing through a
connection point on a computer network, each packets [sic]
conforming to one or more protocols, the monitor comprising:
IPR2020-00486
Patent 6,954,789 B2
9
(a) a packet acquisition device coupled to the connection point
and configured to receive packets passing through the connection
point;
(b) an input buffer memory coupled to and configured to accept
a packet from the packet acquisition device;
(c) a parser subsystem coupled to the input buffer memory and
including a slicer, the parsing subsystem configured to extract
selected portions of the accepted packet and to output a parser
record containing the selected portions,
(d) a memory for storing a database comprising none or more
flow-entries for previously encountered conversational flows,
each flow-entry identified by identifying information stored in
the flow-entry;
(e) a lookup engine coupled to the output of the parser subsystem
and to the flow-entry memory and configured to lookup whether
the particular packet whose parser record is output by the parser
subsystem has a matching flow-entry, the looking up using at
least some of the selected packet portions and determining if the
packet is of an existing flow; and
(f) a flow insertion engine coupled to the flow-entry memory and
to the lookup engine and configured to create a flow-entry in the
flow-entry database, the flow-entry including identifying
information for future packets to be identified with the new flow-
entry, the lookup engine configured such that if the packet is of
an existing flow, the monitor classifies the packet as belonging
to the found existing flow; and if the packet is of a new flow, the
flow insertion engine stores a new flow-entry for the new flow in
the flow-entry database, including identifying information for
future packets to be identified with the new flow-entry,
wherein the operation of the parser subsystem depends on one or
more of the protocols to which the packet conforms.
Ex. 1005, 36:30–37:2.
Of the claims challenged in this proceeding, claim 31 depends directly
from claim 19. Claim 31 recites:

IPR2020-00486
Patent 6,954,789 B2
10
31. A packet monitor according to claim 19, further comprising:
a compiler processor coupled to the parsing/extraction operations
memory, the compiler processor configured to run a compilation
process that includes:
receiving commands in a high-level protocol description
language that describe the protocols that may be used in packets
encountered by the monitor and any children protocols thereof,
and
translating the protocol description language commands into a
plurality of parsing/extraction operations that are initialized into
the parsing/extraction operations memory.
Id. at 37:61–38:6.
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
evidence that claims 31 and 33, but not claim 34, of the ’789 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 the challenged
claims of the ’789 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
IPR2020-00486
Patent 6,954,789 B2
11
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
nonobviousness.11 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

11 The parties do not direct our attention to any evidence of objective
indicia of nonobviousness.
IPR2020-00486
Patent 6,954,789 B2
12
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
of experience working in networking environments, including at least some
experience with network traffic monitors and/or analyzers.” Pet. 8–9 (citing
Ex. 1056, 13–14; 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 ’789 patent and the asserted prior art.
Inst. Dec. 26–27. 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. 26–27. We also
maintain our determination that the definition offered by Petitioner is
consistent with the teachings of the ’789 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).
IPR2020-00486
Patent 6,954,789 B2
13
C. Claim Construction
In interpreting the claims of the ’789 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
1013, 1017 (Fed. Cir. 2017) (applying Vivid Techs. in the context of an inter
partes review).
1. Incorporation by reference of previous disclosures
The ’789 patent claims the benefit of two U.S. patent applications:
(1) Provisional Application No. 60/141,903, filed on June 30, 1999
(Ex. 1016, “the provisional application”), and (2) 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”). See
Ex. 1005, code (60), (63). The ’789 patent states that “the contents” of these
documents “are incorporated herein by reference.” See id. at 1:6–12
(incorporating by reference the application leading to the ’099 patent), 13–
17 (incorporating by reference the provisional application). Throughout
their papers, the parties refer to the disclosures of the ’099 patent and the
IPR2020-00486
Patent 6,954,789 B2
14
provisional application, and state that the ’789 patent incorporates the entire
contents of those disclosures. See, e.g., PO Resp. 2 n.1; Reply 2 n.1, 4.
We agree with the parties that the ’789 patent incorporates the
disclosures of the ’099 patent and the provisional application by specific
reference to those documents. Ex. 1005, code (60), (63), 1:6–17; 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 (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
claim 19.12 See Ex. 1005, 36:45–48 (claim 19 reciting “a memory for
storing a database comprising none or more flow-entries for previously
encountered conversational flows, each flow-entry identified by identifying
information stored in the flow-entry”). At the heart of the parties’ dispute is
the following passage from the ’099 patent:

12 As noted above, challenged claims 31, 33, and 34 depend—directly
or indirectly—from claim 19. As such, the challenged claims also include
the “conversational flow[s]” limitation of claim 19.
IPR2020-00486
Patent 6,954,789 B2
15
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. 30. 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,[13] and some even involve more than one
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.

13 The ’099 patent expressly defines “connection flow”: “The term
‘connection flow’ is commonly used to describe all the packets involved
with a single connection.” Ex. 1001, 2:35–37. Neither party disputes this
definition of “connection flow.”
IPR2020-00486
Patent 6,954,789 B2
16
Specifically, Patent Owner argues that the written description of the
’789 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
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.
Id. at 24–25. 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
IPR2020-00486
Patent 6,954,789 B2
17
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 claim 19 recites a “a memory for storing a database
comprising none or more flow-entries for previously encountered
conversational flows.” Ex. 1005, 36:45–47 (claim 19). 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 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 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
IPR2020-00486
Patent 6,954,789 B2
18
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. 24 (citing Ex. 1001, 2:42–43). Similarly
here, while “conversational flow” certainly may involve the running of an
application on a server as 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
IPR2020-00486
Patent 6,954,789 B2
19
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.
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
IPR2020-00486
Patent 6,954,789 B2
20
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
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
IPR2020-00486
Patent 6,954,789 B2
21
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
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
IPR2020-00486
Patent 6,954,789 B2
22
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. 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
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–27, 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”
IPR2020-00486
Patent 6,954,789 B2
23
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:
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)).
IPR2020-00486
Patent 6,954,789 B2
24
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.
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.
IPR2020-00486
Patent 6,954,789 B2
25

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. Id. at 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-00486
Patent 6,954,789 B2
26
Figure 4A is reproduced below.

Figure 4A illustrates a flowchart 401 of processing steps for
automatically classifying traffic. Ex. 1008, 12:42–43.
In a step 402 of Figure 4A, a flow specification is parsed from the
flow being classified. Id. at 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-00486
Patent 6,954,789 B2
27
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 a step 420 of Figure 4B, an instance of saved traffic is received
from a saved traffic list 308. Id. at 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 step 423, the
IPR2020-00486
Patent 6,954,789 B2
28
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. Baker (Ex. 1013)
Baker relates to systems and methods for parsing, filtering, generating
and analyzing data (or frames of data) transmitted over a data
IPR2020-00486
Patent 6,954,789 B2
29
communications network. Ex. 1013, 3:32–35. Figure 1 of Baker is
reproduced below.

Figure 1 illustrates a network interface system. Ex. 1013, 8:11–
13.
Baker describes a network interface system 10 implemented in a
network device including input devices 12, data storage devices 14, analysis
control logic 16 for facilitating input, storage, retrieval and analysis of
network frames, and output devices 18 for forwarding frames or displaying
or orienting the results of frames. Id. at 10:10–17. A data storage device 14
includes a data file 20 of network frames having n protocol data records. Id.
at 10:17–19. Protocol description files 22 also are stored in the data storage
device 14, where the protocol description files 22 describe a subset of a
network protocol and include rules for analyzing that protocol. Id. at 10:21–
25. The network device control logic 16 retrieves a subset of network
frames from the input devices 12 or data files 20 which satisfy criteria based
upon extracted field values and filtering criteria contained in the protocol
description files 22. Id. at 10:26–31. The network device control logic 16
IPR2020-00486
Patent 6,954,789 B2
30
also determines frames and protocol header lengths, gathers statistics,
performs verifications and error checks, determines routes, varies values,
and formats output. Id. at 10:31–35.
Baker further describes that the network interface system parses
successive protocol headers and further parses remaining information as
application data and a frame pad. Id. at 26:27–32. Baker also describes that
the network interface system parses fixed and optional fields in a selected
protocol. Id. at 26:32–35. Baker additionally describes that the network
interface system performs operations on extracted field values. Id. at 26:35–
27:3. Baker further describes that the network interface system makes
branching, next protocol determination, and validity decisions based on the
extracted field values. Id. at 27:3–7.
4. Wakeman (Ex. 1014)
Wakeman relates to a local access network (LAN) network switch that
includes a random access memory (RAM) forwarding database (FDB)
containing address-to-port mappings for all devices connected to the
switch’s ports, as well as at least one CAM-cache connected to one or more
of the switch’s ports. Ex. 1014, codes (54), (57). By way of background,
Wakeman explains that LAN network switches typically include a switch
engine (SE), an FDB, and one or more dozens of ports, where the FDB may
be implemented either as a hardware CAM or as a RAM. Id. at 1:18–23,
1:55–56. According to Wakeman, a hardware CAM is “very fast,” but “can
be prohibitively expensive,” whereas RAM “can be implemented at a
fraction of the cost of such hardware CAM” but is “typically too slow to
keep up” with a network switch’s SE. Id. at 1:56–67. By including both a
RAM FDB and a CAM-cache having an access time much faster than that of
the FDB, Wakeman’s switch purportedly overcomes the problems in the
IPR2020-00486
Patent 6,954,789 B2
31
prior art. Id. at 2:22–30; see also id. at 2:15–18 (citing a need for a network
switch that is “not confined by the rigid balancing between the superior
performance of a CAM database and the cost savings of a RAM database”).
5. 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
components: (i) an application “such as a firewall, virtual private network
(VPN), or traffic management,” (ii) a “policy engine,” and (iii) an API
between these two components. Id. at 2:51–62.
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.” Id.
at 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.
IPR2020-00486
Patent 6,954,789 B2
32
6. 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,”
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 in View of Ferdinand and Baker
Petitioner contends that claim 31 would have been obvious over
Riddle in view of Ferdinand and further in view of Baker. Pet. 18–75.
Patent Owner opposes. PO Resp. 34–46; Sur-Reply 13–16, 19–20. Having
considered the totality of the arguments and evidence, we find that Petitioner
has shown by a preponderance of the evidence that claim 31 is unpatentable
as having been obvious over Riddle in view of Ferdinand and Baker.
Claim 31 depends from claim 19. Ex. 1005, 37:61–62. Claim 19 is
not before us in this proceeding, but is at issue in related case IPR2020-
00339. Petitioner repeats its analysis of claim 19 from the Petition in
IPR2020-00339, and then provides its arguments and evidence for
dependent claim 31. We first analyze Petitioner’s arguments and evidence
for claim 19, and then turn to claim 31.
1. Independent Claim 19
a) Preamble
The preamble of claim 19 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.” Ex. 1005, 36:30–32.
IPR2020-00486
Patent 6,954,789 B2
33
To the extent that the preamble is limiting, Petitioner persuasively shows
that it is taught by Riddle. See Pet. 30–34 (citing Ex. 1006 ¶¶ 263–269,
618–623, 736, 866, 892).
Specifically, Petitioner persuasively shows that Riddle’s classifier
operates 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) and parses and examines traffic flow packets passing through a
network. Id. at 30–31 (citing Ex. 1008, code (57), 1:57–61, 4:6–17, 5:53–
67, 12:27–41, 14:22–40, Fig. 3; Ex. 1006 ¶¶ 262–264). Thus, we agree with
Petitioner that Riddle teaches a “method of examining packets . . . on a
computer network” and a “packet monitor” for doing the same.
As to the claimed “connection point,” Petitioner contends, and we
agree, that “the ’789 [p]atent acknowledges these points are where the
packet monitor connects to the network.” Id. at 31–32 (citing Ex. 1005,
8:69–9:19, Fig. 1 (showing connection points 121–125). Petitioner
persuasively shows that Riddle’s packet monitor “connects to [a] network
connection . . . via a system gateway” and thus teaches a “connection point”
as claimed and described in the ’789 patent. Id. at 31 (citing Ex. 1008, 5:53–
67, 6:9–15, 7:21–24, Figs. 1A, 1B; Ex. 1006 ¶ 265). Further, for 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. Ex. 1008, 7:10–
34, Figs. 1C, 3; Pet. 32; Ex. 1006 ¶ 266.
Finally, as to the packets “conforming to one or more protocols,” we
agree with Petitioner that Riddle teaches this feature. Pet. 33–34. Riddle’s
system “relates to digital packet telecommunications, and particularly to
management of network bandwidth based on information ascertainable from
IPR2020-00486
Patent 6,954,789 B2
34
multiple layers of OSI network model.” Ex. 1008, 1:54–57. Riddle’s
Figure 1D shows the ISO network model diagramming the relationship
between layers of the TCP/IP protocol suite (e.g., the application, transport,
network, data link, and physical layers (80–88)). Id. at 7:35–8:46, Fig. 1D;
Ex. 1006 ¶¶ 621–622; Pet. 34. Thus, we agree with Petitioner that an
ordinarily skilled artisan would have understood that the packets disclosed in
Riddle conform to the OSI-described protocols. Pet. 34 (citing Ex. 1006 ¶
623).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose the subject matter recited in
the preamble of claim 19. For the reasons detailed above, we are persuaded
that Petitioner has shown by a preponderance of the evidence that Riddle
teaches this subject matter and adopt the contentions set forth in the Petition
and in Dr. Weissman’s Declaration as mapped to the preambles 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).
b) Packet Acquisition Device Limitation
Next, claim 19 recites “a packet acquisition device” limitation: “a
packet acquisition device coupled to the connection point and configured to
receive packets passing through the connection point.” Ex. 1005, 36:34–36.
Petitioner persuasively shows that Riddle teaches this subject matter. See
Pet. 34–36 (citing Ex. 1006 ¶¶ 263–269, 273, 624–626, 737, 867, 892).
Specifically, Petitioner identifies various “packet acquisition device[s]
coupled to [a] connection point” in Riddle, including network interface 40,
which is connected to the system gateway depicted in Riddle’s Figures 1A
IPR2020-00486
Patent 6,954,789 B2
35
and 1B, and “network routing means” and router 75 depicted in Riddle’s
Figure 1C. Id. at 34–35 (citing Ex. 1008, 6:5–15, 7:21–24, 16:54–17:15
(claim 8), Figs. 1A–1C; Ex. 1006 ¶¶ 624–625).
As to “receiv[ing] packets,” Petitioner persuasively shows that Riddle
describes automatically classifying packet flows to help allocate bandwidth
resources. Id. at 36. We agree with Petitioner and Dr. Weissman that, for
this reason, an ordinarily skilled artisan “would have understood that
Riddle’s packet acquisition device is configured to receive packets.” Id.
(citing Ex. 1008, code (57), 4:7–17; Ex. 1006 ¶ 626).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose the subject matter recited in
the packet acquisition device limitation of claim 19. For the reasons detailed
above, we are persuaded that Petitioner has shown by a preponderance of the
evidence that Riddle teaches this subject matter and adopt the contentions set
forth in the Petition and in Dr. Weissman’s Declaration as mapped to that
undisputed limitation as our own findings. NuVasive, 841 F.3d at 974.
c) Input Buffer Memory Limitation
Next, claim 19 recites “an input buffer memory coupled to and
configured to accept a packet from the packet acquisition device.” Ex. 1005,
36:37–38. Petitioner persuasively shows that Riddle teaches this subject
matter, or that an input buffer memory would have been obvious over the
combination of Riddle and Ferdinand. Pet. 36–38 (citing Ex. 1006 ¶¶ 270–
276, 689–691, 893).
Specifically, Petitioner contends, and we agree, that Riddle’s memory
subsystem 35a “acts as an input buffer memory by holding data in
preparation for parsing and examination.” Id. at 37 (citing Ex. 1008, 6:5–15,
Figs. 1A–1B; Ex. 1006 ¶¶ 271–273). In addition, Riddle’s Figure 1A
IPR2020-00486
Patent 6,954,789 B2
36
illustrates the memory subsystem 35a coupled to the network interface 40
(i.e., a packet acquisition device) via the system gateway, and is thus
“coupled to and configured to accept a packet from the packet acquisition
device.” Ex. 1008, 6:1–23, 16:54–17:15 (claim 8), Fig. 1A; Ex. 1006 ¶ 272.
We further agree with Dr. Weissman that an ordinarily skilled artisan would
have understood that Riddle’s memory subsystem 35a acts as “an input
buffer memory” as claimed because the TCP/IP protocol allows for
temporary storage in packet-buffer memory. Ex. 1006 ¶ 274 (citing
Ex. 1027, 71–72). Petitioner also contends, and we agree, that an ordinarily
skilled artisan would have understood Riddle’s router queues packets, and
that a queue functions as a buffer memory within the router. Pet. 37 (citing
Ex. 1008, 2:51–54, 7:21–24, 16:54–17:15 (claim 8); Ex. 1006 ¶¶ 273–274).
Alternatively, relying on the testimony of Dr. Weissman, Petitioner
contends that an ordinarily skilled artisan “would have been motivated and
found it obvious to include an input buffer memory in Riddle’s memory
storage based either upon [an artisan’s] own knowledge of network devices
or Ferdinand’s teachings.” Id. at 37–38 (citing Ex. 1006 ¶ 275). We agree.
Specifically, Petitioner provides persuasive evidence in Riddle and in
Dr. Weissman’s testimony that an ordinarily skilled artisan “would have
known that input buffer memories, such as queues, were found in every
routing device.” Id. at 37 (citing Ex. 1008, 2:51–55; Ex. 1006 ¶ 275).
Petitioner also provides persuasive evidence that an ordinarily skilled artisan
“would have understood that an input buffer memory temporarily stores
incoming packets until the device is ready to process the packets” so as to
avoid the loss of packets. Id. (citing Ex. 1009, 49:2–12; Ex. 1006 ¶ 275).
For example, Ferdinand teaches a frame buffer (i.e., input buffer memory)
IPR2020-00486
Patent 6,954,789 B2
37
that is used to accept packets in network monitors. Ex. 1009, 26:2–7, 41:17–
31, 49:11–12; Ex. 1006 ¶ 275.
We agree with Petitioner that an ordinarily skilled artisan would have
been motivated, based on Ferdinand’s teachings, to “modify Riddle’s
monitor with an input buffer memory to temporarily store received packets
and improve performance by limiting packet drops,” and that including such
input buffer memory in a packet acquisition device in accordance with
Riddle’s and Ferdinand’s teachings “amounts to nothing more than
combining known prior-art technologies used in their ordinary and
predictable manner to queue packet traffic.” Pet. 38 (citing Ex. 1006 ¶ 276).
Moreover, we agree with Petitioner that “Riddle and Ferdinand are in the
same field of endeavor and 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” such as
buffers. Id. at 28–29 (citing Ex. 1009, 19:8–12, 20:22–22:12, 26:2–7,
28:14–17, Figs. 5, 7A–7C; Ex. 1006 ¶ 258).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle, either alone or in combination with
Ferdinand, fails to disclose or suggest the input buffer memory limitation
recited in claim 19. Accordingly, for the reasons detailed above, we are
persuaded that Petitioner has shown by a preponderance of the evidence that
Riddle and/or the combination of Riddle and Ferdinand teaches or suggests
this subject matter, and that an ordinarily skilled artisan would have been
motivated to combine the teachings of the prior art as Petitioner proposes.
We therefore adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to this undisputed limitation of
claim 19 as our own findings. NuVasive, 841 F.3d at 974.
IPR2020-00486
Patent 6,954,789 B2
38
d) Parser Subsystem Limitation
Claim 19 recites “a parser subsystem coupled to the input buffer
memory and including a slicer, the parsing subsystem configured to extract
selected portions of the accepted packet and to output a parser record
containing the selected portions.” Ex. 1005, 36:39–44. Relying on
disclosure in Riddle of a processor programmed to perform
parsing/extraction operations and coupled to memory, Petitioner
persuasively shows that Riddle discloses a parser subsystem (including a
slicer) as recited in claim 19. Pet. 38–42 (citing Ex. 1006 ¶¶ 279–280, 692–
700, 868, 894–896).
Specifically, Riddle teaches “a processor means operative to: parse a
packet into a first flow specification” and illustrates in Figure 1A that the
processor 30 is coupled to memory subsystem 35. Ex. 1008, 6:1–15,
Fig. 1A. Riddle teaches that the parser applies “individual instances of
traffic classification paradigms to packet network flows based on selectable
information obtained from a plurality of 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. And Riddle
teaches that the parser extracts identifying characteristics (i.e., a signature
for the flow) such as patterns and/or reference strings from headers. Id. at
8:67–9:27; 12:42–59. Thus, we agree with Petitioner that Riddle teaches a
parser subsystem (including a slicer) coupled to memory that parses and
extracts packet portions. Pet. 39–40 (citing Ex. 1008, 4:10–15, 9:28–42,
9:48–49, 12:26–41, 12:42–53, 15:55–16:14 (claim 1), 16:54–17:15 (claim
8), 17:21–18:16 (claim 11), Fig. 4A; Ex. 1006 ¶¶ 693–694, 279–280).
Further, Petitioner persuasively shows that Riddle teaches outputting the
parser records containing the selected identifying characteristics in the same
IPR2020-00486
Patent 6,954,789 B2
39
way as disclosed by the ’789 patent. Id. at 40–41 (citing Ex. 1005, 13:44–
54; Ex. 1008, 8:67–9:27; 12:42–59, Fig. 4A; Ex. 1006 ¶¶ 697–698).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose the subject matter recited in
the parser record limitation of claim 19. For the reasons detailed above, we
are persuaded that Petitioner has shown by a preponderance of the evidence
that Riddle teaches this subject matter.
e) Flow-Entry Database Limitations
Claim 19 recites “a memory for storing a database comprising none or
more flow-entries for previously encountered conversational flows, each
flow-entry identified by identifying information stored in the flow-entry.”
Ex. 1005, 36:45–48.
(1) The Parties’ Arguments
Petitioner contends that Riddle alone or in view of Ferdinand renders
the flow-entry database limitations obvious. Pet. 43–58 (citing Ex. 1006
¶¶ 301–339, 342, 371–372, 628–636). As to the recited “memory for
storing . . . flow-entries” feature, Petitioner contends that Riddle’s packet
monitor includes a storage subsystem 35 that stores flow-entry lists of
previously encountered flows in a series of lists that include a plurality of
flow-entries encountered by the monitor. Id. at 43–44 (citing Ex. 1008, 6:1–
23, 6:43–50, 12:37–59, Figs. 1A, 1B, 3; Ex. 1006 ¶¶ 328–339, 628).
According to Petitioner, Riddle incorporates the saved lists into a
classification tree, where each node of the tree represents a traffic class. Id.
(citing Ex. 1008, 8:47–50, 9:28–33, 2:37–41, Fig. 3: Ex. 1006 ¶ 329).
Relying on the testimony of Dr. Weissman, Petitioner contends that an
ordinarily skilled artisan would have understood that Riddle’s saved lists
308 “store flow-entries in memory.” Id. at 44–45 (citing Ex. 1006 ¶ 334).
IPR2020-00486
Patent 6,954,789 B2
40
Further, Petitioner contends that “Riddle identifies a ‘service
aggregate’ which is one type of traffic.” Id. at 45 (citing Ex. 1008, 11:10–
22, 13:53–59; Ex. 1006 ¶ 632). Petitioner contends that Riddle’s “service
aggregate links together into a ‘conversation’ multiple connection flows
based on specific software program activity (e.g., PointCast traffic),” and
therefore, “Riddle teaches storing separate entries for encountered
conversational flows.” Id. (citing Ex. 1006 ¶ 636; Ex. 1008, 11:60–63).
Additionally, Petitioner contends that Riddle, in Figure 4B, “illustrates
processing of the flow-entries of Figure 4A 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 (i.e.,
“conversational flow”), and if so, creates a traffic class that “will match all
components of the service aggregate.” Id. at 46–47 (citing Ex. 1008, 4:49–
51, 13:35–14:6, Fig. 4B; Ex. 1006 ¶¶ 332–334).
According to Petitioner, an ordinarily skilled artisan would have been
motivated and would have found it obvious to store Riddle’s lists and related
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 47–49 (citing, e.g., Ex. 1006 ¶¶ 335, 338–339, 629–631; Ex. 1008,
6:1–15, 10:1–18 (Table 2); 12:32–35, 12:37–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, 29:4–
30:10, 39:23–40:16, 54:13–17, 60:10–15, Figs. 7A–7C, 22).
Petitioner further contends that Riddle discloses flow-entries of
“previously encountered conversational flows” in at least two ways:
IPR2020-00486
Patent 6,954,789 B2
41
“(a) classifying based on service aggregates and (b) classifying based on
PointCast.” Id. at 50 (citing Ex. 1006 ¶¶ 301–327, 632–636). As to 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. (citing
Ex. 1006 ¶¶ 302–303). Indeed, Petitioner contends, Riddle’s claims 1 and 2
teach that the service aggregates are conversational flows. Id. at 53–55
(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).
Regarding “PointCast Traffic,” Petitioner contends that the
provisional application, from which the ’789 patent claims priority and
which is incorporated by reference, expressly “specifies that PointCast
traffic flows include an identification signature, and that identifying
PointCast traffic is an example of identifying a conversational flow.”
Pet. 56–57 (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.
IPR2020-00486
Patent 6,954,789 B2
42
(citing Ex. 1006 ¶¶ 322–324; Ex. 1008, 11:57–12:9). Petitioner contends
that an inventor of the ’789 patent previously testified that creating a single
flow to describe such disjointed flows is a type of conversational flow. Id. at
57 (citing Ex. 1068, 55:11–57:15; Ex. 1071 ¶ 4; Ex. 1072, 3). Petitioner also
contends that “Riddle teaches that one of its autoclassification processes
identifies PointCast traffic using the outside service field of the class,”
specifying that “certain traffic may be distinguished by a signature,” and
“[a]ccordingly, based on Riddle’s teachings, [an ordinarily skilled artisan]
would have understood that Riddle stores flow-entries for ‘previously
encountered conversational flows” such as PointCast traffic.’” Id. at 57–58
(citing Ex. 1008, 11:50–53, 14:54–63, 15:28–31; Ex. 1006 ¶¶ 325, 326–
327). Finally, Petitioner contends that Riddle teaches “each flow-entry
identified by identifying information stored in the flow-entry” as claimed,
because Riddle enters characteristics of the traffic flow into the saved list
(step 408), which identifying information includes “a flow specification and
indicators.” Id. at 58 (citing, e.g., Ex. 1008, 12:42–59, Figs. 4A–4B;
Ex. 1006 ¶¶ 342, 628).
In response to Petitioner’s contentions, Patent Owner argues, first, that
Riddle fails to teach “conversational flows,” see PO Resp. 34–45, and
second, that the combination of Riddle and Ferdinand does not teach the
claimed flow-entry database, see id. at 45–46. As to “conversational flows,”
Patent Owner argues 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 ’789 patent “which require specific operations involving
IPR2020-00486
Patent 6,954,789 B2
43
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 ’789 [p]atent,
which is narrowly focused on conversational flows.” Id. at 41–42. Patent
Owner argues that “Riddle combines flows based on the type of activity,”
but “the ’789 [p]atent inventions recognize separate conversational flows
even when these different flows are based on the same type of activity.” Id.
at 42. Still further, Patent Owner argues that “‘conversational flows’ include
bidirectional exchanges of packets,” but Riddle “expressly teaches that its
traffic classes are limited to unidirectional traffic.” Id. at 44 (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–45.
Regarding the claimed flow-entry database limitations, Patent Owner
argues that Riddle does not use conversational flows, and accordingly, “fails
to disclose multiple limitations present in the claims of the ’789 [p]atent,”
such as the recited flow-entry database “comprising none or more flow-
entries for previously encountered conversational flows.” Id. at 45 (citing
Ex. 2061 ¶ 87). Further, Patent Owner argues, although the Petition relies
on the combination of Riddle and Ferdinand as teaching this limitation,
“Ferdinand gathers statistics on network traffic” 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,” and “[i]t can do so by the standard
statistical measures described in the specification.” Id. at 45–46.
IPR2020-00486
Patent 6,954,789 B2
44
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 8–10.
Regardless, Petitioner contends, Riddle discloses “conversational flows”
even under Patent Owner’s 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
between a client and a server.’” Id. (citing Ex. 1008, 11:10–19). For
example, Petitioner contends, “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. at 11–12 (citing
Ex. 1008, 2:13–21, 7:12–21, 13:8–26, Fig. 1C; Ex. 1006 ¶¶ 311–312, 823).
Further, Petitioner contends that “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. 62–63).
In response to Patent Owner’s argument that Riddle classifies inbound
and outbound flows only separately, rather than 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. Id. at 13 (citing Ex. 1008, 11:12–15; Pet. 46–47). 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 contends refers to all packets exchanged in either
direction. Id. at 13–14 (citing Ex. 1008, 11:13–19, 12:1–12, 13:54–59;
Pet. 48). Still further, Petitioner argues that “Riddle isn’t limited to flow
classification based on port or server identity,” but discloses, for example,
IPR2020-00486
Patent 6,954,789 B2
45
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 14 (citing Ex. 1008, 11:50–53; Pet. 71). 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. (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
or suggests storing ‘flow-entries for previously encountered conversational
flows’” (PO Resp. 45–46), Petitioner contends that Patent Owner does not
address the Petition’s contention that, “based upon [an ordinarily skilled
artisan’s] knowledge of network devices, [that artisan] would have been
motivated and found it obvious to store Riddle’s classification information,
such as flow-entry lists 308, in a database.” Reply 15 (citing Pet. 25–29,
47–49). Petitioner further contends 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 that
Patent Owner’s arguments with respect to Ferdinand individually are
irrelevant to Petitioner’s asserted ground of unpatentability. Id. at 16 (citing
Pet. 25–29, 48–49). Citing arguments presented in the Petition, Petitioner
contends 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. 25–29, 47–49).
In the Sur-Reply, Patent Owner argues that Riddle fails to disclose
“conversational flows,” because Riddle does not classify activities based on
a particular client, Riddle categorizes inbound and outbound traffic
IPR2020-00486
Patent 6,954,789 B2
46
separately, and 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:
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 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, 19–20; EX2061 ¶¶ 62–65,
81–83.
Id. at 14. 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 15. 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,
IPR2020-00486
Patent 6,954,789 B2
47
“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 19. 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 an ordinarily
skilled artisan “would have understood the statistics database of Ferdinand
to serve a very different purpose than the claimed flow-entry database.” Id.
at 19–20.
(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 contentions, which we adopt, are
supported by the cited evidence and are persuasive. Moreover, we are
persuaded that an ordinarily skilled artisan 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. 28–29 (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, PO
Resp. 40–43; Sur-Reply 13, 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
IPR2020-00486
Patent 6,954,789 B2
48
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. 44–45;
Sur-Reply 15–16), neither the Board’s construction of “conversational flow”
nor Patent Owner’s proposed construction requires “bidirectional”
exchanges of packets (see supra § III.C; PO Resp. 23–26). Indeed, 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 testimony of
Ms. Quigley, who states that conversational flows “can,” rather than “must,”
include bidirectional exchanges. Ex. 2061 ¶ 83; Reply 13 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 13 (citing
Ex. 1008, 11:12–19, 12:1–12, 13:54–59); see also Pet. 52 (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 claimed “conversational
flows,” we are further persuaded by Petitioner’s contentions that an
ordinarily skilled artisan 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. 48–49.
Riddle discloses storing flow entries in its series of lists 308 that include a
IPR2020-00486
Patent 6,954,789 B2
49
plurality of flow-entries encountered by the monitor, and Petitioner
persuasively shows, with the support of Dr. Weissman’s testimony, that an
ordinarily skilled artisan would have been motivated, based either on
Riddle’s own disclosure of relational database 306 or on the teachings of
Ferdinand, 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. Id. at 47–49 (citing, e.g., Ex. 1006 ¶¶ 335, 338–339, 629–631;
Ex. 1008, 6:1–15, 10:1–18 (Table 2); 12:32–35, 12:37–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,
29:4–30:10, 39:23–40:16, 54:13–17, 60:10–15, Figs. 7A–7C, 22).
Finally, 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, for these reasons, we are persuaded that Petitioner has
shown by a preponderance of the evidence that the recited flow-entry
database limitations are taught by the combination of Riddle and Ferdinand.
f) Lookup Engine Limitation
Claim 19 recites “a lookup engine coupled to the output of the parser
subsystem and to the flow-entry memory and configured to lookup whether
IPR2020-00486
Patent 6,954,789 B2
50
the particular packet whose parser record is output by the parser subsystem
has a matching flow-entry, the looking up using at least some of the selected
packet portions and determining if the packet is of an existing flow.”
Ex. 1005, 36:49–55. Petitioner persuasively shows that Riddle and/or
Riddle in view of Ferdinand renders this limitations obvious. Pet. 58–60
(citing Ex. 1006 ¶¶ 328–339, 342, 627–636, 652, 705–706, 739–741, 868,
899).
Specifically, while referring back to its contentions with respect to the
flow-entry database limitation, see supra § III.E.1.e.1., Petitioner contends
that “Riddle looks up whether a received packet belongs to a flow-entry
using its processor and memory subsystem, which is the claimed ‘lookup
engine.’” Specifically, Petitioner contends that “Riddle’s operations run on
a processor having programming code performing lookup functions to match
parsed flow specifications to a traffic class.” Pet. 58–60 (citing Ex. 1008,
5:53–57, 11:10–23, 12:42–49, 13:36–62. 16:54–17:15 (claim 8); Fig. 4A;
Ex. 1006 ¶¶ 333, 342, 706). We agree with Petitioner and Dr. Weismann
that an ordinarily skilled artisan “would have understood Riddle’s processor
and memory include a lookup engine,” because Riddle’s lookup engine is
configured to determine whether a received packet belongs to a flow-entry in
the flow-entry lists. Id. at 60 (citing Ex. 1006 ¶ 706).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle, either alone or in combination with
Ferdinand, fails to disclose or suggest the lookup engine limitation recited in
claim 19. Accordingly, for the reasons detailed above, we are persuaded that
Petitioner has shown by a preponderance of the evidence that Riddle and/or
the combination of Riddle and Ferdinand teaches or suggests this subject
matter, and that an ordinarily skilled artisan would have been motivated to
IPR2020-00486
Patent 6,954,789 B2
51
combine the teachings of the prior art as Petitioner proposes. We therefore
adopt the contentions set forth in the Petition and in Dr. Weissman’s
Declaration as mapped to these undisputed limitations of claim 19 as our
own findings. NuVasive, 841 F.3d at 974.
g) Flow Insertion Engine Limitation
Claim 19 recites, in part, “a flow insertion engine coupled to the flow-
entry memory and to the lookup engine and configured to create a flow-
entry in the flow-entry database, the flow-entry including identifying
information for future packets to be identified with the new flow-entry.”
Ex. 1005, 36:56–60. Petitioner persuasively shows that Riddle teaches this
subject matter of claim 19. Pet. 61–62 (citing Ex. 1006 ¶¶ 715–720, 900–
903).
Specifically, while referring back to its contentions with respect to the
flow-entry database limitation of claim 19, see supra § III.E.1.e.1., Petitioner
contends that, as shown in Figure 4B, “Riddle describes looking up whether
a particular packet has a matching entry for a stored service aggregate flow
(i.e., ‘conversational flow’) at step 426, and if not, creates a new flow-entry
at step 425 for further packets to be identified with the new flow-entry.”
Pet. 61 (citing Ex. 1008, 11:10–23, 13:36–62, Fig. 4B; Ex. 1006 ¶ 716). We
agree with Petitioner and Dr. Weissman that an ordinarily skilled artisan
“would have understood that Riddle’s processor and the corresponding code
performing the functions above constitute the claimed ‘flow insertion
engine,’” given Riddle’s teachings that a new flow-entry is created if the
packet does not have a matching entry in a service aggregate. Id. at 62
(citing Ex. 1006 ¶ 706).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose or suggest the flow insertion
IPR2020-00486
Patent 6,954,789 B2
52
engine limitation recited in claim 19. Accordingly, for the reasons detailed
above, we are persuaded that Petitioner has shown by a preponderance of the
evidence that Riddle teaches this subject matter and adopt the contentions set
forth in the Petition and in Dr. Weissman’s Declaration as mapped to this
undisputed limitation of claim 19 as our own findings. NuVasive, 841 F.3d
at 974.
h) Classifying Flows Limitations
Next, claim 19 recites limitations relating to the classification of
packets as belonging to an existing flow or a new flow, depending on
whether the packet “is of an existing flow,” or “is of a new flow.” See
Ex. 1005, 36:60–67. Relying on the testimony of Dr. Weissman, and
reiterating its contentions with respect to the flow-entry database limitation
(supra § III.E.1.e.1), Petitioner persuasively shows that Riddle teaches each
of these remaining limitations. Pet. 63–65 (citing, e.g., Ex. 1008, 5:53–57,
9:28–41, 10:19–56, 12:42–60, 13:36–62, 15:16–27, Figs. 2A–2B, 3, 4A–4B;
Ex. 1006, 650–652, 655, 705–706, 721–728, 742, 870–871, 904–905).
Specifically, as explained above (supra §§ III.E.1.f–g), Riddle’s
lookup engine looks up whether a flow is a new flow or an existing flow,
and if the packet is of a new flow, Riddle’s flow insertion engine creates a
new flow-entry and identifying information to associate future packets with
the new flow-entries. Ex. 1008, 12:42–60, 13:36–62, Fig. 4A (step 408),
Fig. 4B (step 425).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose or suggest the classifying
flows limitations recited in claim 19. Accordingly, for the reasons detailed
above, we are persuaded that Petitioner has shown by a preponderance of the
evidence that Riddle teaches this subject matter and adopt the contentions set
IPR2020-00486
Patent 6,954,789 B2
53
forth in the Petition and in Dr. Weissman’s Declaration as mapped to these
undisputed limitations of claim 19 as our own findings. NuVasive, 841 F.3d
at 974.
i) Protocol Limitation
The final limitation of claim 19 specifies that the “operation of the
parser subsystem depends on one or more of the protocols to which the
packet conforms.” See Ex. 1005, 37:1–2. We agree with Petitioner that
Riddle teaches this limitation. Pet. 66–67 (citing Ex. 1006 ¶¶ 729–733, 872,
906; Ex. 1008, 4:10–15, 9:28–42, 9:48–49, 9:64–65, 11:48–67, 12:3–12,
12:26–41).
Specifically, Riddle teaches that its packet applies “individual
instances of traffic classification paradigms to packet network flows based
on selectable information obtained from a plurality of layers of a multi-
layered communication protocol in order to define a characteristic class,
then mapping the flow to the defined traffic class.” Ex. 1008, 4:10–15
(emphasis added). Thus, we agree with Petitioner that an ordinarily skilled
artisan “would have understood that the operation of Riddle’s parsing
subsystem depends on the one or more protocols of the received packets.”
Pet. 67 (citing Ex. 1003 ¶ 733).
Patent Owner does not substantively address Petitioner’s contentions
or otherwise argue that Riddle fails to disclose or suggest the protocol
limitations recited in claim 19. Accordingly, we are persuaded that
Petitioner has shown by a preponderance of the evidence that Riddle teaches
this subject matter and adopt the contentions set forth in the Petition and in
Dr. Weissman’s Declaration as mapped to these undisputed limitation of
claim 19 as our own findings. NuVasive, 841 F.3d at 974.
IPR2020-00486
Patent 6,954,789 B2
54
2. Dependent Claim 31
We now turn to claim 31. Claim 31 recites that the packet monitor
further comprises:
a compiler processor coupled to the parsing/extraction operations
memory, the compiler processor configured to run a compilation
process that includes:
receiving commands in a high-level protocol description
language that describe the protocols that may be used in packets
encountered by the monitor and any children protocols thereof,
and
translating the protocol description language commands into a
plurality of parsing/extraction operations that are initialized into
the parsing/extraction operations memory.
Ex. 1005, 37:61–38:6.
In support of its contentions as to the combination of Riddle and
Baker, Petitioner provides a detailed mapping of Baker’s teachings of
“compilation processes that (a) receive commands in a high-level protocol
description language describing protocols and (b) translate those commands
into parsing/extraction operations.” Pet. 70–75 (citing Ex. 1013, 2:63–3:8,
11:26–12:6, 17:7–18, 21:32–24:5 (Tables 12–13) 128:20–132:24; Ex. 1006
¶¶ 408–421, 589–594, 918–919). Patent Owner does not substantively
address Petitioner’s contentions or otherwise argue that the prior art fails to
disclose or suggest the limitations recited in dependent claim 31. We have
reviewed Petitioner’s contentions and supporting evidence regarding these
limitations, and are persuaded that Petitioner has shown by a preponderance
of the evidence that Riddle teaches this subject matter and adopt the
contentions set forth in the Petition and in Dr. Weissman’s Declaration as
mapped to these undisputed limitation of claim 19 as our own findings.
NuVasive, 841 F.3d at 974.
IPR2020-00486
Patent 6,954,789 B2
55
Moreover, as explained above in Section III.E.1.e.2, we are persuaded
that an ordinarily skilled artisan 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. 28–29 (citing Ex. 1006 ¶¶ 256–
257, 259). And, as to reasons for adding the teachings of Baker, we agree
with Petitioner that “Riddle, Ferdinand, and Baker are in the same field of
endeavor and contain overlapping disclosures with similar purposes.” Id.
at 69 (citing Ex. 1013, 1:2–2:10, 3:32–4:6; Ex. 1006 ¶¶ 400–402). We
further credit the unrebutted testimony of Dr. Weissman that an ordinarily
skilled artisan would have been motivated to modify Riddle’s processor with
compilation processes that (a) “receive[] commands in a high-level protocol
description language describing protocols” and (b) “translate[] those
commands into parsing/extraction operations.” Ex. 1006 ¶¶ 403–404.
3. Summary
After having analyzed the entirety of the trial record, we determine
that Petitioner has shown by a preponderance of the evidence that claim 31
is unpatentable over the combination of Riddle, Ferdinand, and Baker. In
particular, we find that Petitioner has demonstrated sufficiently that the
teachings of the prior art account for all limitations of the claims, have been
properly combined, and that an ordinarily skilled artisan would have found it
obvious to combine these teachings in the manner proposed by Petitioner.
F. Obviousness Over Riddle in View of Ferdinand and Further in View
of Wakeman
Petitioner contends that claims 33 and 34 would have been obvious
over Riddle in view of Ferdinand and further in view of Wakeman. Pet. 75–
81. Claims 33 and 34 depend from claim 31 and further recites a “cache
subsystem.” Ex. 1005, 38:22–30. In claim 33, the cache subsystem “is
IPR2020-00486
Patent 6,954,789 B2
56
coupled to and between the lookup engine and the flow-entry database
memory providing for fast access of a set of likely-to-be-accessed flow-
entries from the flow-entry database.” Id. at 38:22–27. In claim 34, the
cache subsystem “is an associate cache subsystem including one or more
content addressable memory cells (CAMS).” Id. at 38:29–30.
Petitioner contends that using a cache subsystem “to speed up flow
processing was well known in the art.” Pet. 79 (citing Ex. 1006 ¶¶ 640,
648). Petitioner points to Ferdinand as disclosing various examples of
caches, such as sets of 64KB caches, and contends that Ferdinand teaches
the coupling of a flow-entry database to a cache. Id. (citing Ex. 1006
¶¶ 640, 648; Ex. 1009, 18:27–29, 28:14–21). Petitioner also points to
Wakeman as disclosing “a CAM-cache at length.” Id. at 80 (citing
Ex. 1014, 1:20–28, 2:31–49, 3:36–45, Fig. 2; Ex. 1006 ¶ 645).
Relying on Dr. Weissman’s Declaration, Petitioner also contends that
an ordinarily skilled artisan would have been motivated to combine the
teachings of the references with a reasonable expectation of success. Id. at
80–81. In particular, Petitioner contends that the skilled artisan would have
been motivated “to modify the flow-entry database of the Riddle-Ferdinand
combination to improve the database by providing faster access and retrieval
of likely-to-be-accessed flow-entries, such as Ethernet packet source and
destination addresses.” Id. at 80 (citing Ex. 1006 ¶ 648).
We address each of these dependent claims individually below.
1. Claim 33: Cache Subsystem Limitation
As to claim 33, we find that Petitioner persuasively maps the
limitations of these dependent claims to the cited art (and to the testimony of
Dr. Weissman in support of the combination of references). Specifically
Petitioner contends, and we agree, that Riddle in view of Ferdinand or
IPR2020-00486
Patent 6,954,789 B2
57
Wakeman renders cache subsystem limitation obvious, based on Riddle’s
disclosure of examining flow-entries from stored flow-entry lists (see supra
§ III.E.1.e), together with Ferdinand’s or Wakeman’s cache systems.
Pet. 79–80 (citing Ex. 1006 ¶¶ 637–653, 707–714, 922; Ex. 1008, 13:40–47;
Ex. 1009, 18:27–29, 28:14–21; Ex. 1014, 1:20–28, 1:55–67, 2:31–49, 3:36–
45, 4:31–40, 5:22–27, Figs. 2, 3). 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 or Wakeman as proposed by Petitioner
and supported by the testimony of Dr. Weissman. See id. at 28–29 (citing
Ex. 1006 ¶¶ 256–257, 259–261), 77–78 (citing Ex. 1006 ¶¶ 613–616, 921).
Again, Patent Owner does not present separate and specific arguments for
any of these dependent claims. See generally PO Resp. We adopt the
contentions set forth in the Petition and in Dr. Weissman’s Declaration as
mapped to the limitations of the challenged claims as our own findings.
NuVasive, 841 F.3d at 974.
2. Claim 34: Associative Cache Subsystem Limitation
As noted above, Petitioner contends that Riddle in view of Ferdinand
and Wakeman renders obvious the subject matter of claim 34. Pet. 81
(citing Ex. 1006 ¶¶ 681–685, 923–924; Ex. 1005, 24:17–31). Petitioner
contends that “[c]onsistent with the ’789 [p]atent’s cache design paradigm
including CAMs,” an ordinarily skilled artisan “would have understood that
an associative cache was a well-known cache design paradigm.” Id. (citing
Ex. 1005, 24:17–31; Ex. 1006 ¶ 682). Petitioner contends that an ordinarily
skilled artisan would have understood that Wakeman’s CAM cache “is a
fully associative cache due to Wakeman’s lack of a cache placement policy
indicating there are no constraints on placement within Wakeman’s cache.”
Id. (citing Ex. 1006 ¶ 683). Petitioner further contends that it would have
IPR2020-00486
Patent 6,954,789 B2
58
been obvious to modify Riddle’s monitor with a cache subsystem as taught
by Ferdinand, Wakeman, or by the common knowledge of [an ordinarily
skilled artisan], to improve performance and reduce look-up times of source
and destination addresses of Ethernet packets.” Id. (citing Ex. 1006 ¶ 684).
Patent Owner contends that the asserted prior art fails to teach or
suggest the associative cache subsystem recited in claim 34. PO Resp. 53–
55. In particular, Patent Owner argues:
Petitioners argue that the use of an associative cache
subsystem in ’789 Claim 34 is obvious, because: “a [person of
ordinary skill in the art] would have understood that an
associative cache was a well-known cache design paradigm in
which a memory block can appear in any cache line and that the
cache line is a form of a content addressable memory.” Petition
at 75–76. Petitioners provide no support for this beyond a
citation to Dr. Weissman, and Dr. Weissman provides only a
conclusion that “Wakeman’s CAM cache can be a fully
associative cache,” despite Wakeman not identifying what kind
of cache it uses. Petitioners further argue “a [person of ordinary
skill in the art] would have understood that Wakeman’s CAM
cache is fully associative due to Wakeman not disclosing a cache
placement policy indicating there are no constraints on
placement within Wakeman’s cache.” Id. Dr. Weissman does
not explain why the absence of a discussion of a cache placement
policy in Wakeman would lead a [person of ordinary skill in the
art] to just assume that Wakeman was teaching using of an
associative cache placement policy.
First, Dr. Weissman did not provide any facts or analysis
underlying his opinion, and therefore his analysis is entitled to
little weight. 37 CFR § 42.65(a). His conclusory statement that
Wakeman could be modified to utilize an associative cache does
not demonstrate that a [person of ordinary skill in the art] would
have been motivated to implement Wakeman’s cache as a fully
associative cache. “The mere fact that the prior art could be so
modified would not have made the modification obvious unless
the prior art suggested the desirability of the modification.” In
IPR2020-00486
Patent 6,954,789 B2
59
re Mills, 916 F.2d 680, 682 (Fed. Cir. 1990) (quoting In re
Gordon, 733 F.2d 900, 902 (Fed. Cir. 1984)) (emphasis added).
Second, even if an associative cache were a “common type
of cache” as Dr. Weissman claims, its mere existence does not
mean its use with the specific combination of elements claimed
in ’646 Patent Claim 3 would have been obvious. Ex. 1006
¶ 683; Ex. 2061 ¶¶ 88–90. Associative caches are more
expensive than direct mapping caches due to the requirement that
every potential cache location must be searched in parallel when
checking whether a value is already in the cache. Ex. 2061 ¶ 89.
Wakeman asserts that “[c]hoosing an appropriate network switch
[] requires a balancing between cost and performance”—it does
not espouse the use of an associative caching policy over any
other policy, and in light of Wakeman’s emphasis on balancing
cost, a [person of ordinary skill in the art] would not simply
assume Wakeman to be teaching the use of the more expensive
associative cache (as Dr. Weissman appears to argue). EX1014
(Wakeman) at 2:1–2; Ex. 2061 ¶ 90. If the use of an associative
cache was truly as “common” in the field as Petitioners assert,
then Petitioners would have offered a reference or at least some
form of evidence demonstrating that its use was common in the
field, or that a [person of ordinary skill in the art] would have
assumed the use of an associative cache in the absence of any
discussion on cache placement policy. They did not, and for at
least these reasons Petitioners have not shown claim 3 to be
invalid.
Id.
In its Reply, Petitioner responds that Patent Owner and Ms. Quigley
“concede that an associative cache was a known cache design that predates
the challenged claims” and “don’t dispute that the prosecution history
illustrates that using an associative cache was readily understood in the art to
expedite memory accesses to and from processors.” Reply 26 (citing PO
Resp. 54; Ex. 2061 ¶ 88). Petitioner further contends that “Dr. Weissman
and the Petition refer to the prosecution history in which the Examiner
discussed how associative caches were known in the art,” and
IPR2020-00486
Patent 6,954,789 B2
60
“Dr. Weissman explains it would have been obvious to use associative
caches because they expedite memory access for databases, particularly
when storing Ethernet packet addresses, as taught in Riddle and Ferdinand.”
Id. at 26–27 (citing Ex. 1006 ¶¶ 643–648, 683, 684, 923; Pet. 75–78, 81).
Still further, Petitioner argues that Ms. Quigley’s testimony on which Patent
Owner bases its lack-of-motivation argument “is bereft of any evidentiary
support and is conclusory,” and therefore is entitled to little weight. Id. at 28
(citing Ex. 2061 ¶ 89; PO Resp. 54–55; 37 CFR § 42.65(a)). According to
Petitioner, the fact that other cache types existed does not lessen the
obviousness of using an associative cache in Riddle’s system, and
Ms. Quigley’s testimony that Wakeman teaches away from using an
associative cache “overlooks unrebutted testimony from Dr. Weissman that
‘[associative] caches were well-known to reduce look-up times’ and thus
would have improved the performance of Riddle’s system.” Id. at 28–29
(citing In re Mouttet, 686 F.3d 1322, 1334 (Fed. Cir. 2012); Pet. 81;
Ex. 1006 ¶¶ 684, 923).
Having reviewed the full trial record, we conclude that Petitioner has
not established by a preponderance of the evidence that claim 34 is
unpatentable over the combination of Riddle, Ferdinand, and Wakeman. We
agree with Patent Owner that Petitioner provides insufficient evidence to
support its contentions. Indeed, the Petition’s discussion with respect to the
“associative cache subsystem” limitation of claim 34 does not even cite
Wakeman but instead cites only the testimony of Dr. Weissman and the
specification of the ’789 patent. See Pet. 81.14 And neither Dr. Weissman’s

14 To be sure, the discussion of claim 34 in the Petition also includes
an internal cross-reference to the “discuss[ion] for claim 33,” discussed at
pages 79–80 of the Petition. Pet. 81. Although the discussion of that
IPR2020-00486
Patent 6,954,789 B2
61
testimony nor the ’789 patent provides persuasive support for Petitioner’s
assertion that the artisan “would have understood that Wakeman’s CAM
cache is fully associative due to Wakeman’s lack of a cache placement
policy indicating there are no constraints on placement within Wakeman’s
cache.” Id. We agree with Patent Owner that Dr. Weissman “does not
explain why the absence of a cache placement policy in Wakeman would
lead [an ordinarily skilled artisan] to just assume that Wakeman was
teaching using of an associative cache placement policy.” PO Resp. 54.
Thus, we determine that Dr. Weissman’s testimony in this regard is entitled
to little, if any, weight. 37 CFR § 42.65(a). Moreover, as Patent Owner
argues and we agree, Dr. Weissman’s statement that Wakeman could be
modified to utilize an associative cache does not demonstrate that an
ordinarily skilled artisan would have been motivated to implement
Wakeman’s cache as a fully associative cache. PO Resp. 54–55 (citing In re
Mills, 916 F.2d 680, 682 (Fed. Cir. 1990)). Although we agree with
Petitioner that there is no indication that Wakeman disparages the use of an
associative cache (Reply 28–29), there still needs to be “some rational
underpinning to support the legal conclusion of obviousness” (KSR, 550
U.S. at 418). We do not find such underpinning on the record before us.
Accordingly, we determine that Petitioner has not shown by a preponderance
of the evidence that claim 34 is unpatentable over Riddle in view of
Ferdinand and further in view of Wakeman.

limitation does include citations to Wakeman (see Pet. 79–80 (citing
Ex. 1014, 1:20–28, 1:55–67, 2:31–49, 3:36–45, 4:31–40, 5:22–27, Figs. 2–
3)), notably absent from that discussion is any assertion that Wakeman
specifically suggests an associative cache.
IPR2020-00486
Patent 6,954,789 B2
62
3. Summary
After having analyzed the entirety of the trial record, we determine
that Petitioner has shown by a preponderance of the evidence that claim 33,
but not claim 34, is unpatentable over the combination of Riddle, Ferdinand,
and Wakeman. In particular, we find that Petitioner has demonstrated
sufficiently that the teachings of the prior art account for all limitations of
the claim 33, have been properly combined, and that an ordinarily skilled
artisan would have found it obvious to combine these teachings in the
manner proposed by Petitioner. As to claim 34, however, we find that
Petitioner has not provided sufficient and persuasive evidence and reasoning
that Wakeman (in combination with Riddle and Ferdinand) teaches or
suggests the associative cache limitation.
G. Obviousness Over Riddle in View of Ferdinand and Baker, and
Further in View of Yu or Further in View of RFC1945
Petitioner also contends that claim 31 would have been obvious over
Riddle, Ferdinand, and Baker, and further in view of Yu, or further in view
of RFC1945. See Pet. 82–84 (the combination of Riddle, Ferdinand, Baker,
and Yu), id. at 85–91 (the combination of Riddle, Ferdinand, Baker, and
RFC1945). Having determined that Petitioner establishes by a
preponderance of the evidence that the subject matter of claim 31 would
have been obvious over Riddle in view of Ferdinand and Baker, we need not
address Petitioner’s additional grounds challenging this claim. 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
IPR2020-00486
Patent 6,954,789 B2
63
address [alternative grounds] that are not necessary to the resolution of the
proceeding.”).
H. Obviousness Over Riddle in View of Ferdinand and Wakeman and
Further in View of Yu or Further in View of RFC1945
Petitioner also contends that claims 33 and 34 would have been
obvious over Riddle in view of Ferdinand and further in view of Wakeman
and Yu, or Riddle in view of Ferdinand and further in view of Wakeman and
RFC1945. Pet. 82–91.
1. Claim 33
As to claim 33, we have determined that Petitioner establishes by a
preponderance of the evidence that the subject matter of that claim would
have been obvious over Riddle in view of Ferdinand and Baker, and
therefore we need not address Petitioner’s additional grounds challenging
this claim. SAS Inst., 138 S. Ct. 1359; Boston Sci., 809 F. App’x at 990.
2. Claim 34
As to claim 34, Petitioner relies on Yu or RFC1945, rather than
Riddle, for the teaching of conversational flows. See Pet. 82 (stating that
“[w]hile Riddle itself discloses identifying the claimed ‘conversational
flows,’ Yu further demonstrates identifying conversational flows through its
‘flow classification’”); id. at 85 (stating that “[w]hile Riddle itself discloses
identifying the claimed ‘conversational flows,’ RFC1945 further
demonstrates identifying conversational flows based on the application-level
protocol”). Petitioner does not rely on Yu or RFC1945 to teach or suggest
the associative cache subsystem limitation of claim 34, instead relying on
Wakeman for this limitation. See id. at 84 (stating that “Riddle, Ferdinand,
and Wakeman (Ground 2) disclose all the remaining elements of the
Challenged Claims” other than a “conversational flow”). But, as explained
IPR2020-00486
Patent 6,954,789 B2
64
immediately above, we find that Petitioner fails to sufficiently show that
Wakeman teaches or suggests the associative cache subsystem limitation.
Accordingly, we determine that Petitioner has not shown by a preponderance
of the evidence that claim 34 is unpatentable over Riddle in view of
Ferdinand and further in view of Wakeman and Yu, or Riddle in view of
Ferdinand and further in view of Wakeman and RFC1945.
IV. CONCLUSION15
Petitioner establishes by a preponderance of the evidence that claims
31 and 33 of the ’789 patent are unpatentable. Petitioner fails to establish by
a preponderance of the evidence that claim 34 of the ’789 patent is
unpatentable.

15 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-00486
Patent 6,954,789 B2
65
V. ORDER
Accordingly, it is
ORDERED that claims 31 and 33 of U.S. Patent No. 6,954,789 B2 are
held unpatentable under 35 U.S.C. § 103 as obvious;
ORDERED that claim 34 of U.S. Patent No. 6,954,789 B2 is not 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.

IPR2020-00486
Patent 6,954,789 B2
66
In summary:

16 As explained above, we do not reach this ground. See supra
§ III.G.
17 As explained above, we do not reach this ground, except with
respect to claim 34. See supra § III.H.
18 As explained above, we do not reach this ground. See supra
§ III.G.
19 As explained above, we do not reach this ground, except with
respect to claim 34. See supra § III.H.
Claim(s)

35
U.S.C. §
References Claims
Shown
Unpatentable
Claims
Not shown
Unpatentable
31 103(a) Riddle, Ferdinand,
Baker
31
33, 34 103(a) Riddle, Ferdinand,
Wakeman
33 34
31 103(a) Riddle, Ferdinand,
Baker, Yu16

33, 34 103(a) Riddle, Ferdinand,
Wakeman, Yu17
34
31 103(a) Riddle, Ferdinand,
Baker, RFC194518

33, 34 103(a) Riddle, Ferdinand,
Wakeman,
RFC194519
34
Overall
Outcome
31, 33 34
IPR2020-00486
Patent 6,954,789 B2
67
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