AlterWAN, Inc.

Patent Trials and Appeals Board

Aug 12, 2021

IPR2020-00580 (P.T.A.B. Aug. 12, 2021)

Trials@uspto.gov Paper 41
571-272-7822 Date: August 12, 2021

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

UNIFIED PATENTS, LLC,
Petitioner,

v.

ALTERWAN, INC.,
Patent Owner.
_____________

IPR2020-00580
Patent 9,667,534 B2
____________

Before ROBERT J. WEINSCHENK, JOHN P. PINKERTON, and
STACY B. MARGOLIES, Administrative Patent Judges.

PINKERTON, Administrative Patent Judge.

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

IPR2020-00580
Patent 9,667,534 B2
2
I. INTRODUCTION
Unified Patents, LLC (“Petitioner”) filed a petition for inter partes
review of claims 1, 6, and 8 of U.S. Patent No. 9,667,534 B2 (Ex. 1001, “the
’534 patent”). Paper 2 (“Pet.”). AlterWAN, Inc. (“Patent Owner”) filed a
Preliminary Response. Paper 10 (“Prelim. Resp.”). We instituted trial on
claims 1, 6, and 8 of the ’534 patent on the asserted ground of
unpatentability. (Paper 11, “Inst. Dec.”). Subsequently, Patent Owner filed
a Patent Owner Response (Paper 15, “PO Resp.”), Petitioner filed a Reply
(Paper 21, “Reply”), and Patent Owner filed a Sur-reply (Paper 25, “Sur-
reply”).
An oral hearing was held on May 13, 2021, and a transcript of the
hearing is included in the record. Paper 40 (“Tr.”).
We have authority under 35 U.S.C. § 6. This Final Written Decision
is issued pursuant to 35 U.S.C. § 318(a). For the reasons discussed below,
we determine Petitioner has proven by a preponderance of the evidence that
claims 1, 6, and 8 of the ’534 patent are unpatentable. See 35 U.S.C.
§ 316(e) (2018) (“In an inter partes review instituted under this chapter, the
petitioner shall have the burden of proving a proposition of unpatentability
by a preponderance of the evidence.”).
II. BACKGROUND AND SUMMARY
A. Related Matters
The parties identify the following judicial proceeding in which the
’534 patent is or was asserted and which may affect, or be affected by, a
decision in this proceeding: AlterWAN, Inc. v. Amazon.com, Inc., Civil
Action No. 1:19-cv-01544 (D. Del). Pet. 89; Paper 4, 2; see 37 C.F.R.
§ 42.8(b)(2) (2020).
IPR2020-00580
Patent 9,667,534 B2
3
B. The ’534 Patent
The ’534 patent is titled “VPN Usage to Create Wide Area Network
Backbone Over the Internet.” Ex. 1001, code (54). The ’534 patent explains
that one type of prior art Wide Area Network (WAN) service provided by
telephone companies uses leased lines provided by an Interchange Carrier
(IXC) with a local loop provided by a Local Exchange Carrier (LEC). Id. at
1:24–32. The ’534 patent also explains that another WAN service is known
as a Virtual Private Network (VPN), which is intended for use by large
organizations with multiple users. Id. at 1:33–35. According to the ’534
patent, a VPN appears to the user to be a private leased line trunk network,
but it is not. Id. at 1:35–36. Instead, VPN services are generally arranged
with an IXC for the points from which data will be sent and received, with
telephone line circuits established between each network termination and the
closest IXC Point of Presence (POP). Id. at 1:37–43. The ’534 patent states
that connections between POPs “are established by routers using routing
tables to route the traffic over specified high-capacity transmission facilities
on a priority basis to ensure the level of service is adequate and equivalent to
a true private network using leased lines.” Id. at 1:43–48.
The ’534 patent also states that prior art attempts to implement a
private network using the Internet as a backbone to carry packets were
expensive and faced several quality of service problems, including latency or
delay on critical packets getting from source to destination, the number of
router hops and lack of available bandwidth, and lack of security or privacy.
Id. at 3:24–67. According to the ’534 patent, these problems are solved by
the disclosed configuration of a wide area network using the Internet as the
backbone, which is referred to in the patent as the AlterWAN network. Id.
IPR2020-00580
Patent 9,667,534 B2
4
at 4:3–15. The disclosed network routes encrypted packets along preplanned
high bandwidth, low hop-count routing paths between pairs of customer sites
that are geographically separated. Id. at 4:24–28. The encrypted packets are
sent through a high bandwidth, dedicated local loop connection to the first
participating internet service exchange/internet service provider (ISX/ISP)
facility, from which they are routed to the routers of only “preselected
ISX/ISP facilities . . . which provide high-bandwidth, low hop-count data
paths to the other ISX/ISP facilities along the private tunnel.” Id. at 4:29–
41.
Figure 1 of the ’534 patent is reproduced below.

Figure 1 is a block diagram of a wide area network using the Internet
as a backbone. Id. at 8:5–9. Figure 1 depicts source customer site 1 (in
dashed lines 20) and destination customer site 2 (in dashed lines 58). Id. at
8:28–30, 12:3–8. Figure 1 also depicts participating ISX/ISP providers 24,
IPR2020-00580
Patent 9,667,534 B2
5
48, and 54, and a “private tunnel” (identified by reference arrows) for
AlterWAN packets transmitted from customer site 1 to customer site 2. Id.
at 11:66–67, 12:3–5. As explained in the ’534 patent, the “private tunnel” is
implemented by dedicated high bandwidth local loop data paths 22 and 46,
and high bandwidth data paths 50 and 56 selected for AlterWAN packets by
the routing tables in ISX/ISP providers 24, 48, and 54. Id. at 12:3–8.
As shown in customer site 1 of Figure 1, work station 10 is coupled to
encrypting/decrypting firewall 12 by a local area network (LAN) represented
by LAN hub or switch 14. Id. at 8:9–12. Similarly, as shown in destination
site 2 of Figure 1, work station 68 is coupled to encrypting/decrypting
firewall 40 by LAN hub or switch 60. Id. at 12:12–19. One function of
firewall 12 and firewall 40 is to receive, and distinguish between, AlterWAN
packets, which are addressed to nodes at the destination site on the
AlterWAN network, and conventional internet protocol packets (IP packets),
which are addressed to some other IP address on the internet. Id. at 8:22–38.
The ’534 patent explains that the firewalls make this distinction by
examining the packet headers and using the destination address information,
and one or more lookup tables, to determine which packets are AlterWAN
packets addressed to nodes on the AlterWAN network and which packets are
addressed to any other IP address. Id. at 8:49–55. AlterWAN packets are
encrypted by the firewall and encapsulated in another IP packet having its
destination address as the IP address of the untrusted side of the firewall at
the other end of the private tunnel. Id. at 8:56–62. Conventional IP packets
are not encrypted. Id. at 8:45. All the packets are then sent to source router
18 (or destination router 42), which routes them. Id. at 11:13–14.
IPR2020-00580
Patent 9,667,534 B2
6
Both routers 18 and 42 route any AlterWAN packet, and any IP
packet, on a local loop path to the first participating ISX/ISP. Id. at 9:49–59.
For example, as shown in Figure 1, router 18 routes any AlterWAN packet
into the “private tunnel” of dedicated high bandwidth local loop path 22,
which guides these packets to first participating ISX/ISP 24. Id. AlterWAN
packets are routed from ISX/ISP 24 into high bandwidth data path 50 to the
next participating ISX/ISP 48, and then into high bandwidth path 56 to
ISX/ISP 54, in the AlterWAN network. Id. at 11:24–26; 11:66–12:8. Any
conventional IP packets are also routed on dedicated data path 22, other than
the AlterWAN private tunnel, to ISX/ISP 24. Id. at 11:14–17. At ISX/ISP
24, the conventional IP packets are routed out one of the data paths
represented by lines 32, 34, and 36 to the rest of the Internet. Id. at 11:17–
20.
C. Illustrative Claim
Among the challenged claims (claims 1, 6, and 8), claim 1 is
independent. Claim 1 is illustrative of the subject matter of the challenged
claims and reads as follows (with notations added to identify the preamble
and claim limitations consistent with those used by Petitioner):
1. [1.0] A method of routing packets at a machine
associated with a first network, the method comprising:
[1.1] receiving packets from one or more third party
sources;
[1.2] identifying the received packets as either associated
with a virtual private network or not associated with the virtual
private network;
[1.3] encapsulating packets identified as associated with
the virtual private network and [1.4] routing the encapsulated
packets via a dedicated connection to a specific destination
associated with the first network; and
IPR2020-00580
Patent 9,667,534 B2
7
[1.5] routing the packets received from the one or more
third party sources which are not associated with the virtual
private network exclusively over at least one second
connection, different than the dedicated connection;
[1.6] wherein the method further comprises storing a first
routing table and at least one second routing table, [1.7]
wherein one or more routes identified by the first routing table
are mutually-exclusive to one or more routes identified by the at
least one second routing table, [1.8] wherein routing the
encapsulated packets includes using only one or more routes of
the first routing table to route the encapsulated packets, and
[1.9] wherein routing the packets which are not associated with
the virtual private network includes using only one or more
routes of the at least one second routing table.
Id. at 16:5–29.
IPR2020-00580
Patent 9,667,534 B2
8
D. Prior Art and Asserted Ground of Unpatentability
Petitioner contends that claims 1, 6, and 8 of the ’534 patent are
unpatentable based on the following ground, and we instituted trial based on
this ground:
Claim(s) Challenged 35 U.S.C. §1 Reference(s)/Basis
1, 6, 8 103(a) Dantu,2 Aziz3
Petitioner relies on the testimony of Zygmunt Haas, Ph.D., in his
declaration (Ex. 1003) and his reply declaration (Ex. 1016). Patent Owner
relies on the declaration testimony of Michael Rabinovich, Ph.D. (Ex. 2004).
III. ANALYSIS
A. Applicable Law
To prevail in its challenge to the patentability of claims 1, 6, and 8 of
the ’580 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) (2020). “In an [inter partes review], the petitioner has the burden
from the onset to show with particularity why the patent it challenges is

1 The relevant sections of the Leahy-Smith America Invents Act (“AIA”),
Pub. L. No. 112–29, took effect on March 16, 2013. The application that
issued as the ’534 patent was filed February 4, 2015, but claims priority to a
series of applications, the earliest of which (U.S. Application 09/613,004)
was filed July 10, 2000. See Ex. 1001, codes (22), (63). Petitioner does not
contest the claimed priority date of July 10, 2000, for purposes of the
Petition. Pet. 1. Thus, we apply the pre-AIA version of these statutes. See
35 U.S.C. § 100(i).
2 U.S. Patent No. 6,532,088 B1, filed Sept. 10, 1999, issued Mar. 11, 2003
(Ex. 1004 “Dantu”).
3 U.S. Patent No. RE39,360 E, filed Aug. 19, 1998, issued Oct. 17, 2006
(Ex. 1005 “Aziz”).
IPR2020-00580
Patent 9,667,534 B2
9
unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (2012) (requiring inter partes
review petitions to identify “with particularity . . . the evidence that supports
the grounds for the challenge to each claim”)). This burden of persuasion
never shifts to patent owner. See Dynamic Drinkware, LLC v. Nat’l
Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015); see also In re
Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1375–78 (Fed. Cir. 2016)
(discussing the burden of proof in inter partes review).
A claim is unpatentable for obviousness if, to one of ordinary skill in
the pertinent art, “the differences between the subject matter sought to be
patented and the prior art are such that the subject matter as a whole would
have been obvious at the time the invention was made.” 35 U.S.C. § 103(a)
(2006); see also KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007).
The question of obviousness is resolved on the basis of underlying factual
determinations including: (1) the scope and content of the prior art; (2) any
differences between the claimed subject matter and the prior art; (3) the level
of ordinary skill in the art; and (4) when in evidence, objective evidence of
nonobviousness.4 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)).

4 The parties do not direct our attention to any evidence of objective indicia
of nonobviousness.
IPR2020-00580
Patent 9,667,534 B2
10
Even “[i]f all elements of the claims are found in a combination of
prior art references,” “the factfinder should further consider whether a
person of ordinary skill in the art would [have been] motivated to combine
those references, and whether in making that combination, a person of
ordinary skill would have [had] a reasonable expectation of success.” Merck
& Cie v. Gnosis S.P.A., 808 F.3d 829, 833 (Fed. Cir. 2015). The
“motivation to combine” and “reasonable expectation of success” factors are
subsidiary requirements for obviousness subsumed within the Graham
factors. Pfizer, Inc. v. Apotex, Inc., 480 F.3d 1348, 1361 (Fed. Cir. 2007).
We analyze Petitioner’s asserted ground of unpatentability in
accordance with the above-stated principles.
B. Level of Ordinary Skill in the Art
Relying on the testimony of its expert, Dr. Haas, Petitioner asserts the
following:
A person of ordinary skill in the art . . . for the ’534
Patent would have had at least a bachelor’s degree in electrical
engineering, computer science, or a related subject or the
equivalent, and two years of experience working with
networking, packet routing systems, and related technologies
. . . . More relevant experience could compensate for less
education and vice versa.
Pet. 10 (citing Ex. 1001, generally; Ex. 1003 ¶¶ 44–46).
Patent Owner does not specifically dispute Petitioner’s assertions
regarding the level of ordinary skill in the art. See generally PO Resp.
However, in his declaration, Dr. Rabinovich states the following:
Counsel has asked me to assume that a person of ordinary skill
in the art is one with at least a masters in electrical engineering
or computer science and several years of experience designing
wide area networks and/or technologies for those networks. I
IPR2020-00580
Patent 9,667,534 B2
11
understand that a higher level of experience in one area may
compensate for a lower level of experience in another.
Ex. 2004 ¶ 12.
As we determined in our Institution Decision, Petitioner’s use of the
term “at least” in its description of the level of ordinary skill is too open-
ended. Inst. Dec. 9. We determine that the level of ordinary skill proposed
by Petitioner, except for the reference to “at least,” is consistent with the
challenged claims of the ’534 patent and the level of ordinary skill in the art
at the time of the invention as reflected in the prior art in this proceeding.
See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001). The level
of skill assumed by Dr. Rabinovich is slightly higher in regard to the type of
college degree, and the number of years of design experience, but is
generally consistent with Petitioner’s level. Neither party asserts that the
patentability issues presented here turn on the differences between the two
proposals. See generally PO Resp. and Reply. Accordingly, for purposes of
this Decision, we continue to apply Petitioner’s assessment of the level of
ordinary skill in the art, except for the reference to “at least.”
C. Claim Construction
In an inter partes review based on a petition filed on or after
November 13, 2018, we apply the same claim construction standard that
would be used in a civil action under 35 U.S.C. § 282(b), following the
standard articulated in Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir.
2005) (en banc). 37 C.F.R. § 42.100(b). In applying this standard, claim
terms are generally given their ordinary and customary meaning, as would
be understood by a person of ordinary skill in the art, at the time of the
invention and in the context of the entire patent disclosure. Phillips, 415
F.3d at 1312–13. “In determining the meaning of the disputed claim
IPR2020-00580
Patent 9,667,534 B2
12
limitation, we look principally to the intrinsic evidence of record, examining
the claim language itself, the written description, and the prosecution
history, if in evidence.” DePuy Spine, Inc. v. Medtronic Sofamor Danek,
Inc., 469 F.3d 1005, 1014 (Fed. Cir. 2006) (citing Phillips, 415 F.3d at
1312–17).
Except for the terms “encapsulating” and “routing tables,” neither
party proposes a specific construction for any term or phrase of the
challenged claims. See Pet. 2–9, 19–88; PO Resp. 19–72. In particular, the
parties argue the meaning of “encapsulating” and “routing tables” in regard
to whether Dantu discloses “encapsulating packets,” as recited in limitation
1.3, and whether Dantu’s forwarding nodes store “routing tables,” as recited
in limitations 1.6–1.8. See infra §§ III.D.3.d., III.D.3.g., III.D.3.h. We note
that the district court in the related litigation construed “encapsulating” to
mean “packaging into packets,” and construed “encapsulated” to mean
“packaged into packets.” Ex. 2009, 2. However, we determine that no
claim terms require express construction because the issues raised
concerning the terms “encapsulating” and “routing tables” can be resolved in
the context of the analysis of the parties’ arguments with respect to
limitations 1.3 and 1.6–1.8, as set forth below. See, e.g., Nidec Motor Corp.
v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir.
2017) (explaining that construction is needed only for disputed terms, and
only as necessary to resolve the controversy).
D. Asserted Obviousness Over Dantu and Aziz
Petitioner contends that claims 1, 6, and 8 of the ’534 patent are
unpatentable under 35 U.S.C. § 103 as obvious over Dantu and Aziz. Pet. 2,
19–88. Relying in part on the testimony of Dr. Haas, Petitioner explains
IPR2020-00580
Patent 9,667,534 B2
13
how the references teach or suggest all of the limitations of the challenged
claims and provides reasoning for combining the teachings of the references.
Id. at 19–88; Reply 1–28; Ex. 1003 ¶¶ 48–152; Ex. 1016 ¶¶ 10–61. Patent
Owner, relying on the testimony of Dr. Rabinovich, disputes Petitioner’s
contentions. PO Resp. 19–72; Ex. 2004 ¶¶ 21–77; Sur-reply 1–30.
1. Overview of Dantu
Dantu is a U.S. patent titled “System and Method for Packet Level
Distributed Routing in Fiber Optic Rings.” Ex. 1004, code (54). Dantu
relates generally to data transmission in fiber optic ring networks, and more
particularly to the routing of IP packets through fiber optic ring networks,
including synchronous optical networks (SONET networks) and
synchronous digital hierarchy networks (SDH networks). Id. at 1:13–19.
IPR2020-00580
Patent 9,667,534 B2
14
Figure 8 of Dantu is reproduced below.

Figure 8 is a functional block diagram of a fiber optic ring network
having a plurality of nodes, each having a plurality of forwarding tables to
create virtual private networks according to a preferred embodiment of
Dantu. Id. at 14:63–66. Figure 8 shows central ingress node 800
communicatively coupled to nodes 804, 808, and 812 by way of fiber optic
ring 816 and fiber optic ring 820. Id. at 14:67–15:3. Ring 816 conducts user
traffic in the direction shown at 824 (i.e., clockwise), while ring 820
conducts user traffic in the direction shown at 828 (i.e., counter-clockwise).
Id. at 15:3–5. Each node includes a plurality of memories, each of which
IPR2020-00580
Patent 9,667,534 B2
15
stores a forwarding table for each of a plurality of virtual private networks.
Id. at 15:11–14. Dantu discloses that in a virtual private network, a
subscriber is allocated a path and supporting resources for the subscriber’s
exclusive use, and “a unique forwarding table is created for the subscriber
that defines the data packet forwarding for that particular subscriber.” Id. at
15:14–19. Dantu further discloses that each forwarding table specifies
whether the user traffic data packet is to be forwarded through the fiber optic
ring network or output to an external internet destination, such as an external
IP node. Id. at 15:26–29.
2. Overview of Aziz
Aziz is a U.S. reissue patent (RE39,360) titled “System for
Signatureless Transmission and Reception of Data Packets Between
Computer Networks.” Ex. 1005, code (54). Aziz relates generally to secure
transmission of data packets, and in particular to automatically encrypting
and decrypting data packets between sites on the Internet and other computer
networks. Id. at 1:15–19. Aziz discloses a “tunnelling bridge,” which is a
stand-alone computer with a processor and memory, positioned at the
interface between a private network and a public network (i.e., the internet).
Id. at 2:3–10. In each tunnelling bridge’s memory is a hosts table
identifying which hosts should have their data packets (sent or received)
encrypted. Id. at 2:7–10. Aziz explains that “[t]he tunnelling bridge for a
given private network (or subnetwork of a private network) intercepts all
packets sent outside the network, and automatically determines from the
tables whether each such packet should be encrypted.” Id. at 2:15–18. If a
packet is to be encrypted, Aziz states that the tunnelling bridge then
“encrypts the packet using an encryption method and key appropriate for the
IPR2020-00580
Patent 9,667,534 B2
16
destination host, adds an encapsulation header with source and destination
address information (either host address or IP broadcast address for the
network) and sends the packet out onto the internetwork.” Id. at 2:18–24.
3. Analysis of Claim 1
To begin, we evaluate the parties’ contentions regarding whether
Dantu and Aziz teach or suggest the limitations of claim 1. In its Response,
Patent Owner challenges Petitioner’s showing regarding limitations 1.3 and
1.6–1.9. PO Resp. 2–4, 21–60. In our analysis regarding limitation 1.3
below, we also evaluate whether a person of ordinary skill in the art would
have been motivated to modify Dantu with Aziz to achieve the claimed
invention with a reasonable expectation of success.
a) Preamble 1.0
The preamble of claim 1 recites “[a] method of routing packets at a
machine associated with a first network.” Ex. 1001, 16:5–6. Petitioner
argues that Dantu discloses this limitation because Dantu discloses “a
method of routing packets at a machine (a node containing a processor and
memory) associated with a first network (a fiber optic ring network).” Pet.
19–22 (citing Ex. 1004, Fig. 5 (showing node 512 containing processor 502
and memory 504), 4:39–42 (“invention contemplates . . . a plurality of fiber
optic ring networks that provide routing of IP traffic”), Fig. 9, 15:57–60
(Figure 9 “illustrates how the forwarding tables in a memory of a node
having VPNs relate to the routing and forwarding of packets through a
node”); Ex. 1003 ¶¶ 57–60) (emphasis omitted).
Patent Owner does not dispute that Dantu teaches the preamble. See
PO Resp. 21–26. Patent Owner states, however, that Dantu discloses and
“distinguishes between” two different types of nodes—a “central ingress
IPR2020-00580
Patent 9,667,534 B2
17
node” and a “forwarding node”—in form and function. Id. at 21–22 (citing
Ex. 1004, 8:1–8, 8:40–45, Fig. 3). Patent Owner argues that the differences
between these two types of nodes are illustrated in “Dantu’s Figure 4 of a
central ingress node and Figure 5 of a forwarding node.” Id. at 22. Patent
Owner then states that Petitioner chose Dantu’s “forwarding nodes” as “the
machine” recited in the claim, and Petitioner is bound by the position taken
in the Petition and on which we instituted inter partes review. Id. at 24–26
(citing Pet. 19–21; Figs. 5 and 9; Ex. 1003 ¶¶ 57–60; Henny Penny Corp. v.
Frymaster, LLC, 938 F.3d 1324, 1330–31 (Fed. Cir. 2019)).
Based on Petitioner’s arguments and evidence as summarized above,
we determine Petitioner has shown that Dantu teaches preamble 1.0.
Petitioner asserts that Dantu’s “machine” is “a node containing a processor
and memory” associated with a fiber optic ring network, rather than a
“forwarding node.” Pet. 19, 21. In that regard, Dantu teaches a machine
(node 512 containing processor 502 and memory 504) associated with a first
network (a fiber optic ring network). Ex. 1004, Fig. 5 (showing node 512
containing processor 502 and memory 504), 4:39–42 (“invention
contemplates . . . a plurality of fiber optic ring networks that provide routing
of IP traffic”). Petitioner’s declarant, Dr. Haas, likewise opines that a person
of ordinary skill in the art “would have understood Dantu to disclose a
method for routing packets at a machine (a node containing a processor and
memory) associated with a first network (a fiber optic ring network).” Ex.
1003 ¶ 60.
Patent Owner’s argument that Petitioner is “bound” with respect to
claim 1 to argue features of only Dantu’s “forwarding nodes” does not
concern the preamble of claim 1, but relates primarily to arguments made
IPR2020-00580
Patent 9,667,534 B2
18
with respect to limitation 1.3 regarding encapsulating data packets. Thus,
the argument is addressed below in the analysis of limitation 1.3. See infra
III.D.3.d. As explained infra, we do not agree with Patent Owner’s
argument that Petitioner is “bound” with respect to claim 1 to argue features
of only Dantu’s “forwarding nodes” because Petitioner’s contentions are not
so limited.
b) Limitation 1.1
Petitioner contends that Dantu discloses, or at least renders obvious,
limitation 1.1—“receiving packets from one or more third party sources.”
Pet. 22–26. Petitioner notes that the ’534 patent does not use the term “third
party source,” but does discuss packets being received from a customer site.
Id. at 22 (citing Ex. 1001, 9:49–53). Petitioner argues Dantu states that
“[o]nce a node is set up with forwarding tables, it is ready and begins to
receive user traffic in packet form (step 1006).” Id. at 23 (citing Ex. 1004,
16:24–25, Fig. 10; Ex. 1003 ¶ 62) (emphasis omitted). Petitioner also argues
Figure 9 shows that “each of the switches 916, 920 and 924 ‘include an input
to receive data packets for specified paths on the fiber optic ring network.’”
Id. at 24 (citing Ex. 1004, 15:45–48, Fig. 9; Ex. 1003 ¶ 63) (emphasis
omitted). Petitioner further argues that Dantu discloses data packets are
received from one or more third party sources because, for example, in
regard to Figure 2, Dantu states that “IP router 204 also is coupled to receive
user traffic and internet parameter data 124 from an external source (e.g.,
the internet),” and Figure 2 illustrates that “central router 204 receives user
traffic and routes it through the fiber ring network of IP routers.” Id. at 24–
25 (citing Ex. 1004, 7:41–43, 7:44–47, Fig. 2). Moreover, Petitioner argues
that annotated Figure 8 of Dantu shows “node 812 would receive user traffic
IPR2020-00580
Patent 9,667,534 B2
19
from external sources . . . similar to node 204 in Figure 2.” Id. at 25–26
(citing Ex. 1004, Fig. 8; Ex. 1003 ¶ 64). Thus, Petitioner asserts that Dantu
“discloses receiving packets from one or more third party sources (e.g., user
traffic from ‘an external source (e.g., the internet)’).” Id. at 26 (citing Ex.
1003 ¶¶ 61–65).
Although Patent Owner does not identify limitation 1.1 as one of the
“elements absent from the alleged prior art” (PO Resp. 2–3), Patent Owner
argues that three pieces of evidence from Dantu (relating to Figures 8–10)
on which Petitioner relies for this limitation “concern the forwarding
function at a forwarding node” and the fourth, concerning Figure 2, come
from “an entirely different and inapplicable network design” that is not part
of Dantu’s invention. Id. at 26–29. Patent Owner argues that Figure 2
“cannot be used to meet this element” because it “is a completely different
network design, discussed and criticized in just two short paragraphs before
the specification turns to its invention.” Id. at 28.
In Reply, Petitioner observes that Patent Owner “focuses on whether
the Petition relies on ‘forwarding nodes’ or ‘central ingress nodes’ and
argues that forwarding nodes cannot ‘receiv[e] packets from one or more
third party sources.’” Reply 3. Petitioner provides reasons for why Dantu
teaches that all of the nodes, including the forwarding nodes, can receive
data packets from outside the ring. Id. at 3–9.
Petitioner has shown that Dantu teaches limitation 1.1. First, as
discussed supra, the ’534 patent does not use the term “third party source,”
but does describe receiving packets from a customer site. Ex. 1001, 9:49–
53. Similarly, in describing Figure 10, Dantu states that “[o]nce a node is set
up with forwarding tables, it is ready and begins to receive user traffic in
IPR2020-00580
Patent 9,667,534 B2
20
packet form (step 1006).” See Pet. 23 (citing Ex. 1004, 16:24–25). Second,
we also agree with Petitioner that Dantu’s “user traffic in packet form” is
user IP traffic (i.e., IP data packets) “from one or more third party sources
(e.g., user traffic from ‘an external source (e.g., the internet)”).” See id. at
26 (citing Ex. 1003 ¶¶ 61–65).
Third, Petitioner argues, and we agree, that Dantu teaches that any of
its nodes, including the forwarding nodes, can receive data packets from
outside the ring network. Reply 2–9 (citing Ex. 1004, Figs. 4 and 5; Ex.
1016 ¶¶ 11–16). This is illustrated in Dantu’s Figures 4 and 5, which are
reproduced below as annotated by Petitioner:

Id. at 4. Figure 4 (shown on the left) is a diagram of central ingress node
400, and Figure 5 (shown on the right) is a diagram of node 500 for
forwarding data packets. Ex. 1004, 5:29–35, 9:37–48, 11:39–45. As
IPR2020-00580
Patent 9,667,534 B2
21
depicted in Figure 4, central ingress node 400 includes network interface
devices 412A, 412B, 412C, and 412D, with network interface 412A
connected by double-directional arrows to an IP router, and network
interface 412B connected by double-directional arrows to an IP node. Id. at
Fig. 4, 9:49–55. The IP router and IP node are located below node 400 and
annotated in green. Similarly, as depicted in Figure 5, forwarding node 500
includes network interface devices 512A, 512B, 512C, and 512D, with
network interface 512A connected by double-directional arrows to an IP
router, and network interface 512B connected by double-directional arrows
to an IP node. Id. at 11:49–51. As in Figure 4, the IP router and IP node in
Figure 5 are located below node 500 and annotated in green.
Petitioner persuasively shows that a person of ordinary skill in the art
would have understood such double-directional arrows to mean that data
packets can flow in both directions, i.e., “can be both sent to and received
from IP [r]outers (such as those on a local area network) or can be both sent
to and received from IP [n]odes (such as those directly connected to the ring
network nodes).” Ex. 1016 ¶ 15; see also id. ¶ 14 (noting that double-
directional arrows are commonly used to indicate a connection that allows
data flow in both directions). Patent Owner’s expert confirmed that Figure 5
(a forwarding node) and Figure 4 (a central ingress node) show the same
connection to an IP router. Ex. 1017, 79:17–24; see also id. at 28:24–29:18
(testifying that the double-sided arrow below 512A “reflects on the ability of
this interface to send and receive the data”)). Patent Owner’s declarant also
acknowledged that the existence of interfaces 512C and 512D—which are
shown as connected to first ring and second ring, respectively—suggests that
the 512A and 512B interfaces are connected to something elsewhere apart
IPR2020-00580
Patent 9,667,534 B2
22
from the nodes on the ring. Id. at 30:1–24. Thus, contrary to Patent
Owner’s arguments, Petitioner persuasively shows that a person of ordinary
skill in the art would have understood Dantu to teach that all of the nodes,
including the forwarding nodes, can receive data packets from outside the
ring, either via an IP router connection (i.e., through network interface 512A
in Figure 5 of Dantu) or a separate IP node connection (i.e., through network
interface 512B in Figure 5 of Dantu). Reply 5 (citing Ex. 1016 ¶¶ 15–16).
Patent Owner argues that by asserting the Petition did not use the term
central node or forwarding node, Petitioner “concedes the novelty of its
forwarding-nodes-are-also-central-nodes argument.” Sur-reply 4 (citing
Reply 6). As discussed supra, in response to Patent Owner’s arguments that
forwarding nodes cannot receive packets from outside the ring, Petitioner
has argued, and persuasively shown, that all of the nodes, including the
forwarding nodes, can receive data packets from outside the ring. In its
Reply, Petitioner noted Patent Owner argues that inclusion of central node
features, such as receiving data packets from outside the ring, “would
transform a node from a forwarding node to a central ingress node.” Reply 6
(citing PO Resp. 22, 24). In response, and consistent with its previous
argument, Petitioner stated that receiving data packets from outside the ring
network is a feature of all of Dantu’s nodes, not merely a central node. Id.
Petitioner also stated that, “even if [Patent Owner] is correct that these
forwarding nodes would be transformed into central nodes, they would
satisfy the claim limitations because regardless of whether technically
labeled as central or forwarding, they would each perform the
routing/forwarding described in Dantu.” Id. (citing Ex. 1016 ¶ 18). Thus,
Petitioner merely responded to Patent Owner’s argument that receiving data
IPR2020-00580
Patent 9,667,534 B2
23
packets from outside the ring network would transform forwarding nodes
into central nodes. Petitioner did not assert a new theory of unpatentability.
Fourth, regarding Figure 8, Petitioner argues, and we agree, that
“whether node 812 is just a forwarding node or a central node, Dantu
discloses receiving packets from outside the ring.” Id. at 8–9 (citing Ex.
1016 ¶ 21). Petitioner asserts that it used the example of node 812 in Figure
8 as the node receiving data packets “because Dantu chose to show the data
paths coming from that node.” Id. at 6–7 (citing Pet. 72). However,
Petitioner also asserts “that selection is irrelevant to the analysis” because
any of Dantu’s nodes, whether labelled forwarding nodes or central nodes, is
“configured to receive data packets from outside the ring network and
forward them through the ring.” Id. at 7 (citing Ex. 1016 ¶¶ 19–20).
In that regard, Petitioner argues, and we agree, that even central
ingress node 800 in Figure 8 contains three separate forwarding tables for
separate VPNs and other data (id. (citing Ex. 1004, 14:63–15:35, Fig. 8)),
and Figures 4 and 5 also show that both types of nodes contain VPN-specific
forwarding tables (404B and 504A) and the same set of network interfaces
(id. at 7–8). Petitioner asserts that Dantu discloses that in alternate
embodiments, “any of all of the remaining nodes may also serve as central
nodes for IP traffic that is received and routed/forwarded through the fiber
optic ring network.” Id. at 8 (citing Ex. 1004, 9:1–4). Petitioner also asserts
that Dantu discloses an embodiment in which “each node on the network
serves as a central node and provides forwarding tables for each of the other
nodes for the TCP/IP packets it receives via its connection to the internet.”
Id. (citing Ex. 1004, 17:59–63). Thus, Petitioner further asserts, and we
agree, that “whether node 812 is just a forwarding node or a central node,”
IPR2020-00580
Patent 9,667,534 B2
24
Dantu discloses receiving packets from outside the ring. Id. at 8–9 (citing
Ex. 1016 ¶ 21).
For the above reasons, we determine Petitioner has shown that Dantu
teaches limitation 1.1.
c) Limitation 1.2
Petitioner contends that Dantu discloses, or at least renders obvious,
limitation 1.2, which recites “identifying the received packets as either
associated with a virtual private network or not associated with the virtual
private network.” Pet. 26–30. Petitioner persuasively shows that Dantu
teaches this limitation.
Dantu describes “the nodes (shown as 800, 804, 808, and 812) in
Figure 8 as ‘having three tables’ and explains that ‘at least two of the
forwarding tables shown within each node of [Figure] 8 represent a
forwarding table for a [VPN]’ and ‘[t]he third forwarding table is either for
all other user traffic or, perhaps, merely for a third subscriber of a virtual
private network.’” Ex. 1004, Fig. 8, 15:19–26; Ex. 1003 ¶ 68. Dantu also
describes that “after user packets are received by one of the nodes of the
fiber optic ring network, ‘a processor, similar to the one of [Figure] 5,
examines computer instructions within a storage device to determine a
corresponding memory portion holding a corresponding forwarding table for
a specified VPN according to the identity of the path from which a data
packet was received.’” Ex. 1004, 15:60–64; Ex. 1003 ¶ 69; see also Ex.
1004, Fig. 10 (step 1008) (emphasis omitted)). Thus, we find, as Petitioner
argues, that by analyzing the data packet, including its corresponding path
information and the appropriate forwarding table, Dantu is performing the
recited identifying step. Pet. 30 (citing Ex. 1003 ¶ 70).
IPR2020-00580
Patent 9,667,534 B2
25
Patent Owner does not contest specifically Petitioner’s arguments
with respect to limitation 1.2. See PO Resp. 2–3, 29–31. Patent Owner,
however, notes that Petitioner relies on a forwarding node to perform this
step, and argues that Petitioner points to no evidence that the central ingress
node performs the step. Patent Owner’s argument is unavailing because, as
discussed supra in regard to limitation 1.1, Petitioner has shown that the
machine performing the receiving step, as well as the subsequent identifying
step, is a forwarding node, rather than a central ingress node. To the extent
Patent Owner is reiterating its argument that Petitioner’s contentions for
claim 1 as a whole are limited to relying on the functionality of the
forwarding node, we disagree for the reasons stated below.
For the above reasons, we determine Petitioner has shown that Dantu
teaches limitation 1.2.
d) Limitation 1.3
(1) Petitioner’s Arguments
Petitioner contends that Dantu in view of Aziz renders obvious
limitation 1.3, which recites “encapsulating packets identified as associated
with the virtual private network.” Pet. 31–37. Petitioner initially argues that
the ’534 patent does not specify a particular type of encapsulation, and refers
generally to encapsulation by conventional, known methods, such as
“conventional or custom firewall/VPN technology.” Id. at 31 (citing Ex.
1001, 4:47–49, 12:27–29; Ex. 1003 ¶ 72) (emphasis omitted). Petitioner
then argues that Dantu discloses a conventional method of encapsulating
packets identified as associated with a VPN using a multi-protocol label
switching (MPLS) scheme in which data packets are inserted into another
data packet along with the packet label (MPLS label). Id. at 31–33 (citing
IPR2020-00580
Patent 9,667,534 B2
26
Ex. 1004, Fig. 11, 16:3–5, 16:49–53, 1[6]:56–605). Petitioner also argues
that a person of ordinary skill would have understood that “this disclosure
(i.e., inserting a data packet in another packet) was a widely used
conventional type of encapsulation in 2000.” Id. at 33–34 (citing Ex. 1003 ¶
75 (citing Ex. 1008, 344)).
Petitioner further argues that to the extent Patent Owner argues that
this limitation is not explicitly disclosed in Dantu or was not known as
conventional, “Aziz discloses, or at least renders obvious, this limitation
because it teaches encapsulating selected packets (i.e., encapsulating the data
packets selected for encryption within a new packet by adding an
encapsulation header).” Id. at 34–35 (citing Ex. 1005, Fig. 6 (items 240,
250, 260), 2:15–24, 5:19–20, 8:34–38; Ex. 1003 ¶¶ 72–77). Petitioner
argues that Figures 7 and 8 of Aziz, both of which are reproduced below, are
examples of this encapsulation process. Id. at 36.

5 As Patent Owner notes, Petitioner mistakenly cited column 11 of Dantu,
rather than column 16. PO Resp. 34 n.5; Pet. 33.
IPR2020-00580
Patent 9,667,534 B2
27

Figure 7 of Aziz illustrates a conventional data structure for data
packet 400, which includes data 410 and header 420. Ex. 1005, 3:3–4, 4:6–
7. Figure 8 illustrates data structure 402 in which “original data 410 and
original header 420 are now encrypted, indicated as (410) and (420),” and
“new IP header 450” includes “the address of the source and destination
hosts.” Id. at 5:52–59. According to Petitioner, in this example, “the
entirety of original data packet 400 (shown in Figure 7) is encapsulated into
new data packet 40[2]6 (shown in Figure 8 as encrypted data packet (400))

6 Petitioner refers to “new data packet 404,” but we believe this was a
mistake because Figure 8 depicts data packet or structure 402, and does not
use reference number 404. See Ex. 1005, 5:51–52, Fig. 8.
IPR2020-00580
Patent 9,667,534 B2
28
by adding new encapsulation header 450.”7 Pet. 36–37 (citing Ex. 1003
¶ 78). Petitioner also asserts that “[e]ncapsulating headers as disclosed in
Aziz is precisely the type of encapsulating packets that was conventional at
the time of the alleged invention and disclosed by the ’534 patent.” Id. at 37
(citing Ex. 1008, 1055; Ex. 1003 ¶ 79).
(2) Patent Owner’s Arguments
Patent Owner contends that Dantu’s forwarding nodes do not
encapsulate packets and a person of ordinary skill in the art would not have
combined Aziz and Dantu. PO Resp. 31–53.
First, Patent Owner addresses the meaning of “encapsulation.” Id. at
32–33. Patent Owner asserts that Petitioner’s expert defines encapsulation
as “the process of enclosing packets of one type of protocol within another,”
based on two dictionary definitions, which are consistent with the ’534
patent’s use of the term “encapsulate.” Id. at 32 (citing Ex. 1003 ¶ 73; Ex.
1006, 4; Ex. 1008, 4). Patent Owner states that the ’534 patent’s abstract
describes “encapsulat[ing] these packets in other IP packets,” and the
specification’s other references to “encapsulation” do the same. Id. (citing
Ex. 1001, code (57), 8:60, 14:50–52) (alteration in original). According to
Patent Owner, “[t]he result is always a bigger IP packet than the pre-
encapsulation packet; encapsulation enlarges the packet by adding
something to it.” Id. at 32–33 (citing Pet. 31, 34; Ex. 1003 ¶¶ 75, 77).

7 Aziz states that in Figures 7–11, “the fields with reference numerals in
parentheses are encrypted, and the other fields are unencrypted.” Ex. 1005,
5:66–6:1. Aziz also states, “[t]hus, in Fig[ure] 8, the original data field 410
and address field 420 are encrypted, while the new encapsulation header
430, including the key management information 440 and the IP header 450,
is not encrypted.” Id. at 6:1–4.
IPR2020-00580
Patent 9,667,534 B2
29
Patent Owner also argues that Petitioner acknowledges this size increase
graphically by citing Dantu’s Figure 11 as illustrating the result of
encapsulation. Id. at 33 (citing Pet. 33; Ex. 1004, Fig. 11).
Second, Patent Owner argues that Dantu by itself does not satisfy the
claimed encapsulation. Id. at 34–39. Patent Owner asserts that in
attempting to establish encapsulation with Dantu, Petitioner “begins its shell
game in earnest” by shifting between “what happens at the central node
when the packet first arrives at the ring” and at other times, “to a different
step in the process at the forwarding nodes.” Id. at 34–35. In that regard,
Patent Owner states that Dantu’s specification “makes clear that the central
node is what generates what is shown in Figure 11” and that Dantu then
“describes the MPLS-addressing process at the central node.” Id. at 34 n.5
(citing Ex. 1004, 16:49–52, 16:56–60). Patent Owner also states that
Petitioner refers to the “label-swapping process at the forwarding node” on
page 33 of the Petition, but “label swapping is very different from the
original MPLS addressing step.” Id. at 35 n.6 (“Compare Ex. 1004, 16:49–
52 (MPLS addressing at the central node) with 14:46–53 (label swapping at
the forwarding node).”).
Patent Owner then asserts there are two problems with Petitioner’s
reliance on what happens at the central ingress node when the ring first
receives a data packet. Id. at 35. The first is “that it contradicts
[Petitioner’s] position with the three prior limitations—that ‘the machine’
accomplishing those elements was a forwarding node accomplishing its
forwarding function. This is [Petitioner’s] shell game.” Id. The second
problem is that the order of steps in claim 1’s method precludes reliance on
MPLS addressing at the central node. Id. Patent Owner argues that in claim
IPR2020-00580
Patent 9,667,534 B2
30
1, step 1.2 of “identifying the received packets as either associated with a
virtual private network or not” “must precede” step 1.3 of “encapsulating
packets identified as associated with the virtual private network.” Id. at 36.
Patent Owner argues that Petitioner, however, relies on the forwarding
process at the forwarding node to satisfy the “identifying” step and that
process “occurs after the MPLS addressing that occurs initially at the central
node.” Id. (citing Ex. 1004, Fig. 3 and 8; 4:45–48) (emphasis omitted).
Thus, Patent Owner asserts that even if Petitioner were allowed to rely on
MPLS addressing at the central node, “its attempt to establish [the] claimed
‘encapsulating’ would fail, because the encapsulating would occur before
the identifying.” Id. at 36–37.
Patent Owner further argues that Petitioner cannot rely on MPLS
addressing at the forwarding node to establish “encapsulation” because
Dantu describes the forwarding node process as “label swapping,” which
fails to meet Petitioner’s definition. Id. at 38–39 (citing Ex. 1004, 12:6–9,
14:46–54; Ex. 2004 ¶¶ 33–34). In that regard, Patent Owner argues as
follows:
Label swapping does not ‘enclose a packet . . . in another.’ The
packet that arrives at the forwarding node matches what Figure
11 shows. Id., 16:60–64. Label swapping does not enclose what
is in Figure 11 with additional header data; it merely switches
data within that existing header. Id., 14:49–54. As a result, label
swapping also does not create a new packet by adding a new data
protocol header. Ex. 2004, ¶ 33–34. The header protocol
remains the same both before and after label swapping. Id. The
fact that label swapping does not change the length demonstrates
that label swapping is different from encapsulation.
Id.
IPR2020-00580
Patent 9,667,534 B2
31
Third, Patent Owner contends that the combination of Dantu with
Aziz fails to meet the claimed “encapsulation.” PO Resp. 39–53. Although
Patent Owner states “it does not dispute” that Aziz’s encryption process
could be characterized as “encapsulation,” Patent Owner also states “there
are three problems” with Petitioner’s attempt to combine Aziz’s encryption
with Dantu’s fiber-optic ring. Id. at 39. Patent Owner asserts the first
problem is that Petitioner “never explains how the two references would be
combined, such as where in Dantu’s ring Aziz’s encryption and decryption
would occur.” Id. Patent Owner argues that this information is important
for determining whether the combination would satisfy claim 1’s order of
steps, such as “identifying” followed by “encapsulating,” and that “[p]utting
encryption at the central node would get the claim order wrong.” Id. at 40.
Patent Owner asserts that Petitioner’s second problem is Petitioner’s
failure to establish a motivation to combine Aziz with Dantu. Id. at 40. In
regard to Petitioner’s argument that a person of ordinary skill would have
been motivated to modify Dantu with Aziz to provide added security for the
data packets being sent according to each VPN, Patent Owner argues there is
no such motivation to combine because the proposed combination would not
achieve the purported motivation. Id. at 41. Patent Owner argues that
“[a]dding encryption at the forwarding node (as would seem to be required
to attempt to satisfy claim 1) would leave everything from the originating
site, through the internet and the central ingress node, up to the forwarding
node, completely unsecure.” Id. at 42 (citing Ex. 2004 ¶¶ 40, 44–45).
IPR2020-00580
Patent 9,667,534 B2
32
Patent Owner also argues that based on the testimony of Petitioner’s expert,8
“decryption would need to occur before leaving the ring.” Id. (citing Ex.
2004 ¶ 41).
Patent Owner then asserts that the result of adding encryption at the
forwarding node can be illustrated by the following annotated Figure 3 from
Dantu.

Id. at 43. Figure 3 of Dantu is an annotated functional block diagram of a
fiber optic ring network according to a preferred embodiment of the
invention. Ex. 1004, 5:26–28. Figure 3 depicts central node 300, and
forwarding nodes 312, 316, and 320, each of which is coupled in a ring
topology by fiber optic rings 108 and 110. Id. at 8:1–2, 8:6–10. Patent
Owner asserts that in this annotated version of Figure 3, the origin and
destination sites were added and that “everything left unsecured [is]

8 See PO Resp. 42 n.7 (citing Dr. Hass’s testimony at Ex. 2005, 63:9–14,
stating, “You know, sending a key on the internet is a big no-no when we
talk about security schemes. Aziz’s invention does not require sending the
key . . . in the clear over a channel to the destination. If it did, it would be
useless.”).
IPR2020-00580
Patent 9,667,534 B2
33
highlighted in red, and the only aspect with added security [is] highlighted in
green.” PO Resp. 42 (citing Ex. 2004 ¶ 44).
Patent Owner asserts that its annotated diagram shows the proposed
combination does not significantly increase data security, leaving far too
much of the path unsecured. Id. at 43. Patent Owner also asserts that this
diagram illustrates that Petitioner’s argument that a desire for added security
“would motivate one to put encryption at a forwarding node” commits
obviousness law’s “cardinal sin” of “using the claim itself as a road map for
the combination.” Id.
Patent Owner also argues that any attempt by Petitioner to argue that
data could enter from the internet at one of the forwarding nodes “should be
rejected because it was absent” from the Petition. Id. 43. Patent Owner also
asserts that in Dantu, any node configured to receive data from the internet
becomes a central node and cannot meet the encapsulation requirement for
the reasons already provided. Id. at 43–44 (citing Ex. 1004, 9:1–4). Further,
Patent Owner argues that even that configuration would leave all parts of the
communication path unsecured, except for the few within the ring network.
Id. at 44 (citing Ex. 2004 ¶ 45).
Patent Owner next quotes a portion of our Institution Decision, which
Patent Owner states summarizes Petitioner’s other purported motivation-to-
combine arguments, and states “here are the many flaws in that theory.” Id.
at 44–46 (citing Inst. Dec. 32–33). For example, Patent Owner argues that
Petitioner’s contention that both references use tables to determine how the
data packets are routed “is precisely the same type of ‘general’ commonality
in the field that is so broad as to be meaningless.” Id. at 44–45 (citing Ex.
2004 ¶ 50).
IPR2020-00580
Patent 9,667,534 B2
34
Patent Owner asserts that Petitioner’s third problem in trying to
combine Aziz’s encryption with Dantu’s fiber-optic ring is that “both
references each teach away” from their combination in a manner that would
satisfy claim 1. PO Resp. 47–53. Regarding Aziz, Patent Owner argues its
clear teaching is that packets “need to be encrypted before they reach the
[i]nternet, and decrypted after they leave the [i]nternet.” Id. at 47–48 (citing
Ex. 1005, 1:21–24, 2:3–18, 2:25–29; Ex. 2004 ¶¶ 49, 52, Fig. 3). Patent
Owner argues that Petitioner’s proposed combination “does the opposite,”
because in that combination “packets traverse the [i]nternet both before
encryption and after decryption.” Id. at 49. Patent Owner then asserts that a
person of ordinary skill in the art would have been led in a very different
direction than the configuration Petitioner proposes. Id. at 50.
Regarding Dantu, Patent Owner argues that it teaches away from
Petitioner’s proposed combination, which adds Aziz’s encryption to Dantu’s
forwarding nodes, because “[a]dding an element to a reference that would
render the original reference ‘inoperable for its intended purpose’ teaches
away from that addition.” Id. According to Patent Owner, “[t]he entire
Dantu specification consistently and repeatedly emphasizes the structural
and functional distinctions between a central node and the forwarding
nodes.” Id. at 50 (citing, for example, Ex. 1004, Figs 3, 4, 5; 4:45–68, 8:41–
51, 9:36–13:23). Patent Owner argues that the central node does the
complex work, and all the forwarding nodes do is forward packets. Id. at
50–51 (citing Ex. 1004, 8:31–51, 16:24–31, 16:46–64). Patent Owner also
argues that Dr. Haas “conceded to these differences between Dantu’s two
node types.” Id. at 51 (citing Ex. 2005, 53:24–54:5, 54:10–14 (Haas
deposition)).
IPR2020-00580
Patent 9,667,534 B2
35
Patent Owner asserts that the central purpose of Dantu’s patented
configuration is to keep the forwarding nodes simple and inexpensive. Id. at
51–52 (citing Ex. 1004, 4:54–59, 8:40–45). Patent Owner also asserts that
“[t]his aspect of Dantu does not ‘merely express[] a general preference,” but
“it is part of the core purpose for the specific structure core to Dantu’s
invention.” Id. at 52 (second alteration in original). But, according to Patent
Owner, “adding Aziz’s encryption capability to Dantu’s forwarding nodes
would frustrate that purpose and require an entirely different structure.” Id.
In particular, Patent Owner argues that encrypting data packets, particularly
high volumes of data packets, requires additional computing power, and
“would require adding the cost and complexity that Dantu sought to avoid.”
Id. (citing Ex. 2004 ¶¶ 54–55).
(3) Analysis
Petitioner persuasively shows that both Dantu alone and the
combination of Dantu and Aziz teaches limitation 1.3, which recites
“encapsulating packets identified as associated with the virtual private
network.” As explained below, Dantu teaches the claimed encapsulating by
teaching using an MPLS operation at a forwarding node. Ex. 1004, 14:46–
51,16:3–5; Ex. 1003 ¶¶ 73–76. In addition, Aziz teaches encapsulating data
packets selected for encryption within a new packet by adding an
encapsulation header. Ex. 1005, 2:15–24; 5:19–20, 5:53–58, 8:34–38, Figs.
6–8; Ex. 1003 ¶¶ 77–80. Petitioner persuasively shows that one of ordinary
skill in the art would have combined the teachings of Dantu and Aziz for
several reasons, including providing additional security for the data packets
being sent according to each VPN, and would have had a reasonable
expectation of success in doing so. Ex. 1003 ¶¶ 81–90.
IPR2020-00580
Patent 9,667,534 B2
36
(i) Dantu
As summarized above, Patent Owner argues that Dantu does not teach
the claimed encapsulating because Dantu does not teach increasing the size
of the packet and because Dantu describes the MPLS-addressing process at
the central node and Dantu’s forwarding nodes do not encapsulate packets.
We are not persuaded.
Patent Owner agrees that Petitioner’s understanding of the term
“encapsulation” as “the process of enclosing packets of one type of protocol
within another” is consistent with the ’534 patent’s use of the term
“encapsulate,” but argues that “encapsulation” also requires the packets to
increase in size. PO Resp. 32–33. Petitioner argues, and we agree, that even
under Patent Owner’s narrow interpretation, Dantu’s MPLS system teaches
or suggests encapsulating packets as claimed. Reply 9–11. In that regard,
we find that Dantu’s disclosure of “label swapping” teaches “encapsulating,”
under both Petitioner’s and Patent Owner’s interpretation, because after the
node removes the old label, the packet is enclosed with a new packet
containing a new label, which new packet is longer than the packet that does
not contain the label. Ex. 1004, 14:46–53; Ex. 1010, 18 (describing MPLS
as attaching a local label “to the packet via a lightweight encapsulation
mechanism”); Ex. 1016 ¶ 27 (“Dantu’s MPLS system is necessarily
encapsulating the data packet when the new MPLS label is added”).
Regarding Patent Owner’s argument that Dantu’s forwarding nodes
do not encapsulate packets, Petitioner argues that Patent Owner’s argument
is flawed because it “relies on the narrow scheme raised in its analysis of the
previous claim elements (i.e., that only the central ingress node can receive
packets from outside the ring).” Reply 9. However, as Petitioner argues,
IPR2020-00580
Patent 9,667,534 B2
37
and as discussed above regarding limitation 1.1, Dantu teaches that all of
Dantu’s nodes, including the forwarding nodes, can receive packets from
outside the ring. See supra § III.D.3.b. Based on Dr. Haas’s testimony,
Petitioner argues, and we agree, that a person of ordinary skill would have
understood that Dantu teaches that for data packets first entering the ring at a
certain node from an IP router or IP node, whether it be at a central ingress
node or a forwarding node, the MPLS encapsulation in which the packet
data is encapsulated in a header is done at that first node on the ring that
receives that packet. Ex. 1016 ¶ 24.
Patent Owner also advances several arguments for why Dantu’s
teaching of an MPLS scheme does not teach the claimed encapsulating. We
are not persuaded. Instead, for the reasons discussed below, we find
Petitioner has shown that Dantu teaches “encapsulating” packets at a
forwarding node using either an MPLS “push” or “swap” operation.
First, Patent Owner argues that Dantu’s description of the process at
the forwarding nodes as “label swapping” is not “encapsulation.” PO Resp.
38–39). We disagree. Petitioner argues that Patent Owner fails to
understand that MPLS can be implemented via three types of operations: (1)
a swap operation, in which the label is swapped with a new label; (2) a push
operation, in which a new label is pushed on top of the existing label,
encapsulating the packet in another layer of MPLS; and (3) a pop operation,
in which the label is removed from the packet, which may reveal an inner
label below. Reply 10 (citing Ex. 1016 ¶ 25; Ex. 1009, 21–22). Petitioner
also argues, and we agree, that although Dantu does not disclose which type
of MPLS operation its nodes perform, a person of ordinary skill would have
understood that Dantu’s disclosed MPLS scheme could use any of the three
IPR2020-00580
Patent 9,667,534 B2
38
types of MPLS operations. Id.; see also Ex. 1016 ¶ 26. Although Patent
Owner argues that “Dantu describes the forwarding process at the
forwarding nodes as ‘label swapping,’” we understand Dantu as teaching
that “label swapping” is an example of the process if an MPLS scheme is
used. PO Resp. 38 (citing Ex. 1004, 12:6–9). As Petitioner notes, Dr.
Rabinovich admits that MPLS’s push operation creates a packet that “would
have more labels than it had before,” satisfying Patent Owner’s requirement
that encapsulation requires packets to increase in size. Reply 10 (citing Ex.
1017, 27:6–28:6). Thus, Petitioner also argues, and we agree, that a person
of ordinary skill would have understood Dantu to teach encapsulating the
packets via MPLS “push” operations. Id. (citing Ex. 1016 ¶ 26).
Patent Owner also asserts that Petitioner’s arguments regarding MPLS
“push” and “label swapping” operations constituting encapsulation are new
arguments that should be disregarded. Sur-reply 4, 12–13. We do not agree
that Petitioner’s argument regarding an MPLS “swap” operation or “label
swapping” is a new argument because it is a further explanation of the
description of Dantu’s MPLS conventional type of encapsulation in the
Petition. Pet. 33–34 (citing Ex. 1004, 11:56–60, 14:47–51; Ex. 1003 ¶ 75).
Nor do we agree that Petitioner’s argument regarding an MPLS “push”
operation is a new argument because it is an expanded discussion of MPLS
encapsulation, as discussed in the Petition, and in any event was properly
made by Petitioner in response to Patent Owner’s arguments made in Patent
Owner’s Response. See PO Resp. 37–39; see also 37 C.F.R. § 42.23(b).
Moreover, Petitioner argues that even assuming a person of ordinary
skill would read Dantu as only disclosing the “swap” operation of MPLS, a
person or ordinary skill would have understood that Dantu’s MPLS system
IPR2020-00580
Patent 9,667,534 B2
39
teaches “encapsulating,” even under Patent Owner’s interpretation. Reply
11. Petitioner asserts, and we agree, that a person of ordinary skill would
have understood that “the node removes the old label first, ‘and then inserts
the replacement label in the header of the data packet.’” Id. (citing Ex.
1004, 14:49–53; Ex. 1016 ¶ 27). Petitioner also asserts, and we agree, that
after the old label is removed, the packet is enclosed within a new packet
containing a new label, which new packet longer than the packet that does
not contain the label. Id. (citing Ex. 1010, 18 (describing MPLS as attaching
a local label “to the packet via a lightweight encapsulation mechanism.”)).
Thus, Petitioner further asserts, and we agree, that Dantu’s MPLS system is
“encapsulating” the data packet when the new MPLS label is added, even
under Patent Owner’s interpretation. Id. (citing Ex. 1016 ¶ 27).
Regarding Patent Owner’s argument that because Petitioner chose
Dantu’s “forwarding nodes” as “the machine” recited in claim 1, Petitioner
is “bound” with respect to claim 1 to argue features of only Dantu’s
“forwarding nodes,” we do not agree because, as stated, Petitioner’s
contentions are not so limited. Moreover, Petitioner has shown through the
testimony of Dr. Haas that Dantu “discloses a conventional method of
encapsulating packets (i.e., through an MPLS scheme whereby data packets
are inserted into another data packet identified as associated with a virtual
private network (e.g., VPN A)). See Pet. 31–34; Ex. 1003 ¶¶ 73–75.
Petitioner has also shown that, although Dantu does not disclose which type
of MPLS operation its nodes perform, a person of ordinary skill would have
understood that Dantu’s disclosed MPLS scheme could use any of the three
types of MPLS operations—swap, push, and pop. Ex. 1016 ¶ 26; Ex.1009,
21–22. In view of Dantu’s teachings regarding MPLS operations, we
IPR2020-00580
Patent 9,667,534 B2
40
determine that Petitioner properly relies on Dantu’s MPLS operations at a
forwarding node to teach encapsulating packets identified as associated with
a VPN, as recited in limitation 1.3.
Although Petitioner has shown that Dantu teaches “encapsulating”
packets at a forwarding node using either an MPLS “push” or “swap”
operation, Patent Owner asserts that Petitioner still fails to establish that
Dantu teaches limitations 1.1–1.3 because its ‘“encapsulation’ and
‘identifying’ occur in the wrong order.” Sur-reply 5–11 (emphasis omitted).
Petitioner disagrees, explaining that Dantu teaches the claimed order. Tr.
64:17–65:3. Based on Petitioner’s arguments and evidence, and our findings
discussed above regarding limitations 1.1–1.3, we agree with Petitioner and
determine that Dantu teaches performing limitations 1.1–1.3 in the order set
forth in claim 1.
In that regard, Petitioner has persuasively shown Dantu discloses that,
after Dantu’s forwarding node receives packets from an external source,
such as the internet (as in “receiving” limitation 1.1) (see Ex. 1004, 16:24–
25, Figs. 8, 10; Ex. 1003 ¶¶ 61–65), the node analyzes the packets to
determine the forwarding table for a VPN or other user traffic to use in
routing each packet (as in “identifying” limitation 1.2) (Ex. 1004, 15:60–64,
6:26–31, Fig. 10 (step 1008), Ex. 1003 ¶¶ 69–70). Thus, Dantu discloses
that to select the correct forwarding table from the correct memory, the node
first identifies the received packets as either associated with a VPN or not.
Ex. 1003 ¶¶ 66–71. Dantu also discloses encapsulating packets identified as
associated with a VPN using an MPLS scheme (as in “encapsulating”
limitation 1.3). Ex. 1004, 16:3–11, 16:49–17:3; Ex. 1003 ¶ 74–76. Patent
Owner’s argument that Petitioner’s reliance on the process at the forwarding
IPR2020-00580
Patent 9,667,534 B2
41
node to satisfy the identifying step fails because the encapsulating step
would occur at the central ingress node before the identifying step, rather
than after the identifying step (see PO Resp. 35–37), is not persuasive
because it based on Patent Owner’s flawed argument that only the central
ingress node can receive packets from outside the ring. Ex. 1016 ¶ 23. As
discussed above regarding limitation 1.1, all of Dantu’s nodes, including the
forwarding nodes, can receive packets from outside the ring. In addition,
Petitioner has shown through Dr. Haas’s testimony that a person of ordinary
skill would have understood that “for data packets first entering the ring at a
certain node from an IP router or from an IP node, whether it be at a central
node or a forwarding node, the MPLS encapsulation in which the packet
data is encapsulated in a header is done at such a first node.” Id. ¶ 24. Thus,
Dantu teaches that the encapsulating step would occur at the forwarding
node after the identifying step in accordance with the order of steps in claim
1.
(ii) Combination of Dantu and Aziz
We also determine Petitioner has shown that the combination of
Dantu and Aziz teaches encapsulating packets as recited in limitation 1.3.
See Reply 11–19. Petitioner has shown that Aziz teaches or suggests
“encapsulating packets” because, as discussed above, Aziz teaches
encapsulating data packets selected for encryption within a new packet by
adding an encapsulation header. Pet. 34–37 (citing Ex. 1005, Fig. 6 (items
240, 250, 260), Figs. 7–8, 2:15–24, 5:19–20, 5:52–59, 8:34–38; Ex. 1003
¶¶ 77–80).
Patent Owner does not dispute that Aziz’s process “could be
characterized as ‘encapsulation,’” but contends that there are three problems
IPR2020-00580
Patent 9,667,534 B2
42
with the proposed combination of Dantu and Aziz. PO Resp. 39–53; see
also Sur-reply 13–22. Petitioner contends that “none of them hold water.”
Reply 11. We agree with Petitioner.
First, we are not persuaded by Patent Owner’s argument that
Petitioner “never explains how the two references would be combined.” See
PO Resp. 39. Petitioner argues that as we noted in the Institution Decision,
“Petitioner’s proposed combination would modify the routing system of
Dantu’s forwarding nodes to include Aziz’s encryption and encapsulation
technique, rather than physically combining Aziz’s private customer
network tunneling bridge before packets reach the [i]nternet, as [Patent
Owner] describes.” Reply 11–12 (citing Inst. Dec. 30–31). Petitioner also
argues that it adequately explained how a person of ordinary skill would
have combined the two references by “modifying the routing system of
Dantu to incorporate the encapsulation/encryption system of Aziz.” Id. at 12
(citing Ex. 1003 ¶¶ 77–90; Ex. 1016 ¶¶ 28–30). Although Petitioner’s
explanation is at a high level, we agree with Petitioner. Further, Petitioner
persuasively shows that the tunneling disclosed in Aziz was a conventional
method of encapsulating packets in 2000, and was well known at the time of
the alleged invention. Ex. 1003 ¶¶ 79–80. As Petitioner asserts, and we
agree, contrary to Patent Owner’s contentions, “it is not necessary that the
inventions of the references be physically combinable to render obvious the
invention under review.” Reply 12 (citing In re Sneed, 710 F.2d 1544, 1550
(Fed. Cir. 1983); In re Keller, 642 F.2d 413, 425 (CCPA 1981) (“[T]he test
is what the combined teachings of the references would have suggested to
those of ordinary skill in the art.”)).
Patent Owner also argues Aziz’s IP-packet encryption “could not be
IPR2020-00580
Patent 9,667,534 B2
43
implemented during the forwarding process at the forwarding nodes” of
Dantu because “[t]he data at that stage is in TDM [(time division
multiplexed)] format, not IP-packet format.” Sur-reply 15 (citing Ex. 1004,
14:17–22). We are not persuaded by Patent Owner’s argument. Although
the cited portion of Dantu states that the central node “converts the IP user
traffic to TDM format,” it also states the central node transmits it onto the
ring network, where the nodes “forward the converted IP user traffic as
specified in their forwarding tables.” Ex. 1004, 14:17–22. Thus, there is
nothing in Dantu teaching or suggesting that the IP-packets cannot be
encrypted prior to forwarding. In addition, there is no evidence that suggests
that because the “data” is in TDM format, the IP-packets cannot be
encrypted and encapsulated, and then forwarded, by the forwarding node.
Rather, as Petitioner’s expert, Dr. Haas, explained in his deposition, a large
packet may be sent “in several TDM slots, for example,” and “TDM format
is simply the format of the TDM slots and frames.” Ex. 2005, 47:10–12;
47:15–16. We are not persuaded that converting “data” to TDM slots and
frames prevents the IP-packets from being encrypted and encapsulated, and
then forwarded, by the forwarding node.
Second, we are not persuaded by Patent Owner’s argument that
Petitioner has failed to establish a motivation to combine Aziz with Dantu.
See PO Resp. 40–46. Instead, we agree with Petitioner that it has shown a
person of ordinary skill would have been motivated to modify the VPN
routing system of Dantu to use the private network encapsulation and
encryption system of Aziz and would have been able to do so with a
reasonable expectation of success. Pet. 37–43; Ex. 1003 ¶¶ 81–90; Reply 12
(citing Ex. 1003 ¶¶ 81–90). As explained by Dr. Haas, both Dantu and Aziz
IPR2020-00580
Patent 9,667,534 B2
44
are in the same field of endeavor as the claimed invention, as they are both
systems and methods of routing packets over networks. Ex. 1003 ¶ 82.
Further, each of these references is reasonably pertinent to the problem
addressed by the ’534 patent: the issue of routing packets to lower cost,
“while not suffering from the aforementioned latency, privacy and
bandwidth availability problems” associated with prior art systems. Id. ¶ 83;
Reply 12–13 (comparing Ex. 1001, 4:64–67, with Ex. 1004, 4:26–27, 4:30–
31, 4:35–36, and Ex. 1005, 1:20–24).
Petitioner also persuasively shows that a person of ordinary skill in
the art would have been motivated to modify the routing system of Dantu to
incorporate the private network encapsulation and encryption system of Aziz
to provide additional security for the data packets being sent according to
each VPN. Pet. 40–41 (citing Ex. 1003 ¶¶ 86–87). As explained by
Dr. Haas, a person of ordinary skill would have understood that “data
privacy and security (data integrity) are also important aspects of a VPN
which need to [be] taken into consideration when considering any particular
VPN implementation.” Ex. 1003 ¶ 87 (alteration in original); Ex. 1010, 5;
see also Ex. 1001, 3:60–63. Thus, Petitioner argues, and we agree, that a
person of ordinary skill in the art would have been motivated to modify the
routing system of Dantu to incorporate the encapsulation and encryption
system of Aziz because “if the communications between each VPN
subnetwork (or between each VPN host) is securely encrypted as it transits
the common communications infrastructure, then it can [be] said that the
privacy aspect of the VPN is relatively high.” Reply 13 (citing Ex. 1010, 5;
see also Ex. 1006, 5); see also Ex. 1003 ¶ 87.
Regarding Patent Owner’s argument that its annotated version of
IPR2020-00580
Patent 9,667,534 B2
45
Dantu’s Figure 3 shows “the proposed combination does not significantly
increase data security, leaving far too much of the path unsecured” (see PO
Resp. 43), Petitioner argues that it is based on Patent Owner’s “flawed
understanding that only the central ingress node can receive packets from
outside the ring network”9 and that Patent Owner “manipulated the figure to
add uni-directional arrows, when the only arrow actually on the figure is bi-
directional.” Reply 13–14 (emphasis omitted). Petitioner asserts that a
correct way Figure 3 could be marked up to show how Dantu’s ring network
would work with the encapsulation and encryption system of Aziz is shown
in its annotated version of Figure 3, which is reproduced below.

Id. at 14–15 (citing Ex. 1004, Fig. 3, annotated to add an origin site (at the
right), label interfaces (Interface 512A or 512B between the origin site and
forwarding node 316, and Interface 412A between central node 300 and a

9 Consistent with our discussion and findings supra regarding limitation 1.1,
Petitioner states, that as explained with respect to Dantu’s Figures 4 and 5,
“every node can receive or send data packets from/to outside the ring.”
Reply 14 (citing Ex. 1016 ¶¶ 31–33).
IPR2020-00580
Patent 9,667,534 B2
46
drawing of a cloud labeled internet), and highlight the
encapsulated/encrypted packet traffic in green).
Petitioner argues that as can be seen in this version of Figure 3, traffic
can be received by forwarding note 316 from an IP router via interface 512A
or an IP node attached to node 316 via interface 512B.10 Id. at 15 (citing Ex.
1016 ¶ 34). Petitioner asserts the packet would be encapsulated and
encrypted at node 316 when received and then sent via the ring through
nodes 312 and 300 before being sent to its final destination on the internet.
Id. Thus, Petitioner also asserts, and we agree, that contrary to Patent
Owner’s argument, “in such a scenario, the packet would be protected
through the entirety of its route.” Id. (citing Ex. 1016 ¶ 34). Accordingly,
we determine Petitioner has shown that a person of ordinary skill would
have been motivated to modify the routing system of Dantu to incorporate
the encapsulation and encryption system of Aziz to provide “additional
security” for the data packets being sent according to each VPN. Moreover,
we are not persuaded by Patent Owner’s argument that Petitioner is “using
the claim itself as a road map for the combination” by putting encryption at a
forwarding node, rather than at the originating and destination sites. PO
Resp. 43. In that regard, Petitioner has shown that the combination of Dantu
and Aziz with encryption at a forwarding node provides additional security
for the data packets based on the references and “takes into account only
knowledge which was within the level of ordinary skill at the time the

10 Patent Owner argues that Petitioner’s version of Figure 3 is “misleading
for four reasons.” See Sur-reply 16–18. In view of Petitioner’s explanation
concerning this version of Figure 3, and Petitioner’s arguments and evidence
discussed above, we are not persuaded by Patent Owner’s arguments.
IPR2020-00580
Patent 9,667,534 B2
47
claimed invention was made, and does not include knowledge gleaned only
from [the] applicant’s disclosure.” In re McLaughlin, 443 F.2d 1392, 113–
14 (CCPA 1971).
We also are not persuaded by Patent Owner’s argument that Petitioner
should not be permitted to argue that “data could enter from the [i]nternet at
one of the forwarding nodes and be encrypted at that point” because “it was
absent” from the Petition. See PO Resp. 43. Petitioner argues, and we
agree, that “the Petition made exactly this argument” with respect to the
multiple-VPN embodiment shown in Figure 8. Reply 16 (citing Pet. 72; see
also Pet. 66, 69; Ex. 1004, Fig. 8 annotated in Petition). Petitioner notes that
Patent Owner repeatedly refers to Petitioner’s reliance on “forwarding node
812” in its Response (see, e.g., PO Resp. 27–28, 30), all while attempting to
argue that Petitioner never argued that forwarding nodes could receive
packets from outside the ring network. Reply 16 (citing PO Resp. 43).
As discussed above, Patent Owner argues that Petitioner’s additional
motivations for combining Dantu and Aziz, as summarized in our Institution
Decision, are flawed. Petitioner notes that Patent Owner quotes the
Institution Decision stating, “in view of the similarities in Dantu and Aziz of
receiving a data packet, determining whether it should be encrypted, and
then routing the packet according to a table,” and then Patent Owner states
that “Dantu never determines whether a packet should be encrypted, so no
such similarity can exist.” Id. at 17 (citing PO Resp. 45). Petitioner argues,
however, that this “misstates” its argument, which was that:
“Dantu’s nodes receive the data packet and then determine
whether the packet is associated with a specified VPN, and if so,
the packet is routed according to a specific table for that VPN”
and “Aziz teaches receiving a data packet and then determining
if each packet should be encrypted based on a set of tables, and
IPR2020-00580
Patent 9,667,534 B2
48
if so, the packet is encrypted and routed according to that table.”
Id. (citing Pet. 41–42; see also Ex. 1003 ¶ 88). Thus, based on the Petition,
and Dr. Haas’s declaration testimony, we agree with Petitioner that Patent
Owner’s argument is not persuasive. Although the Institution Decision may
be interpreted as incorrectly stating that Dantu teaches encryption,
Petitioner’s position is that “the encryption is done based on the combination
of Dantu and Aziz and not based on Dantu alone.” Id. (citing Ex. 1016
¶¶ 35–36). Thus, while Dantu is not similar to Aziz in regard to teaching
encryption, Petitioner has shown that both Dantu and Aziz are similar in that
they disclose methods of routing packets over networks along dedicated
paths using tables. Ex. 1003 ¶¶ 84–85, 88. Petitioner has also shown that a
person of ordinary skill would have been motivated to modify the VPN
routing system of Dantu to use the encapsulation and encryption system of
Aziz for the reasons discussed supra.
Thus, for these reasons, we determine Petitioner has shown
persuasively through articulated reasoning with rational underpinning that a
person or ordinary skill would have been motivated to combine the teachings
of Dantu and Aziz as in claim 1 with a reasonable expectation of success.
See KSR, 550 U.S. at 418–19 (citing In re Kahn, 441 F.3d at 988(requiring
“articulated reasoning with some rational underpinning to support the legal
conclusion of obviousness”)).
Third, we are not persuaded by Patent Owner’s argument that Dantu
and Aziz teach away from each other. See PO Resp. 47–53. A reference
that “merely expresses a general preference for an alternative invention but
does not criticize, discredit, or otherwise discourage investigation into” the
claimed invention does not teach away. Meiressone v. Google, Inc., 849
IPR2020-00580
Patent 9,667,534 B2
49
F.3d 1379, 1382 (Fed. Cir. 2017) (quoting Galderma Labs., L.P. v. Tolmar,
Inc., 737 F.3d 731, 738 (Fed. Cir. 2013)). Petitioner argues, and we agree,
that Patent Owner “provides no evidence of such discouragement,” but
instead relies on its misapprehension that Dantu requires all data packets to
traverse the internet prior to reaching the ring network at the central ingress
node and then traversing the internet after leaving the ring network. Reply
18 (citing PO Resp. 47–48). As discussed supra, Petitioner argues, and we
agree, that Dantu “requires no such thing,” and a person of ordinary skill
would have understood Dantu to disclose that any of the nodes (including a
forwarding node) can receive data packets from an IP router (e.g., on a local
area network) via interface 512A/412A or from a local IP node via interface
512B/412B. Id. (citing Ex. 1016 ¶ 37). In this regard, Dr. Haas opines as
follows:
As I explained above, such a data packet generated by a node on
a local area network or by a local IP node would be received by
the forwarding node on a ring network. This forwarding node
would encrypt and encapsulate the data packet using Aziz’s
operation. Once that is understood, Patent Owner’s argument
that “packages need to be encrypted before they reach the
Internet, and decrypted after they leave the Internet” does not
teach away from Dantu at all. It is important to understand that
Aziz’s operation does not require the end communicating nodes
to exchange any security information in the clear, even if the
communicating nodes are separated by the Internet.
Ex. 1016 ¶ 37 (citing Ex. 1005, 2:47–50).
Accordingly, we agree with Petitioner that Patent Owner’s argument
that Aziz’s teaching that “packages need to be encrypted before they reach
the [i]nternet, and decrypted after they leave the [i]nternet” does not teach
IPR2020-00580
Patent 9,667,534 B2
50
away from Dantu.11 Id.
We also are not persuaded by Patent Owner’s argument that Dantu
teaches away from Aziz. See PO Resp. 50–53. Patent Owner argues that
Dantu states “the individual nodes are not required to have full IP router
capability thereby reducing complexity and cost” and that “adding Aziz’s
encryption capability to Dantu’s forwarding nodes would frustrate that
purpose and require an entirely different structure.” Id. at 51–52 (citing Ex.
1004, 4:54–59, 8:40–45; Ex. 2004 ¶¶ 54–55). This argument is not
persuasive because as Petitioner argues, and we agree, Dantu specifically
discloses that “any of all of the remaining nodes may also serve as central
nodes for IP traffic that is received and routed/forwarded through the fiber
optic ring network” (Reply 18 (citing Ex. 1004, 9:2–4)), and “the invention
includes an embodiment wherein each node on the network serves as a
central node and provides forwarding tables for each of the other nodes for
the TCP/IP packets it receives via its connection to the internet.” Id. at 18–
19 (citing Ex. 1004, 17:59–63; Ex. 1017, 53:22–54:5). Petitioner also
argues, and we agree, that Dantu does describe a system, which can save in
cost and complexity by having a central node that performs certain functions
that are not performed by other nodes, but it does not teach away from
adding encryption capability to any of the nodes. Id. at 19 (citing Ex. 1016

11 Patent Owner also asserts that (1) Petitioner’s argument that packets enter
the ring from a “local IP node” is new and should be disregarded, (2)
Petitioner’s argument is false because Dantu’s only embodiments shown in
Figures 1–3 “all show data entering via the internet,” and (3) “there is no
such thing as ‘local IP Nodes’ in Dantu.” Sur-reply 19–22. Based on
Petitioner’s arguments and evidence, and our findings, discussed supra
regarding limitations 1.2 and 1.3, we are not persuaded by Patent Owner’s
assertions.
IPR2020-00580
Patent 9,667,534 B2
51
¶¶ 38–41; Ex. 2005, 64:10–66:2). Thus, we agree with Petitioner that
because Dantu teaches each of the nodes being able to receive and send data
packets from outside the ring network and explicitly provides for
embodiments in which each node performs all of the functions the other
nodes perform, it does not teach away from being combined with Aziz. Id.
(citing Ex. 1016 ¶¶ 39–41).
e) Limitation 1.4
Petitioner contends that Dantu in view of Aziz discloses, or at least
renders obvious, limitation 1.4, which recites “routing the encapsulated
packets via a dedicated connection to a specific destination associated with
the first network.” Pet. 43–49. Specifically, Petitioner argues that Dantu in
view of Aziz teaches or suggests nodes containing multiple forwarding
tables, one for a specific VPN, and “[e]ncapsulated data packets identified as
associated with a particular VPN (e.g., VPN A) are routed according to its
corresponding forwarding table.” Id. at 45 (citing Ex. 1004, Fig. 8, 15:19–
26, 15:30–38; Ex. 1003 ¶ 93). Petitioner also argues that Dantu’s routing is
done via a dedicated connection between the node and its destination or
endpoint along the ring network by which the packets are sent. Id. at 46–47
(citing Ex. 1004, 15:26–35; Ex. 1003 ¶ 94). According to Petitioner, in all
embodiments of Dantu, “the packets are routed to a specific destination
associated with the first network (i.e., the fiber optic ring network) according
to the destination address located in the header of the packet.” Id. at 47–48
(citing Ex. 1003 ¶ 95; Ex. 1004, 8:55–58, 13:62–67, 14:54–57).
Patent Owner does not contest specifically Petitioner’s arguments
with respect to limitation 1.4. See generally PO Resp. Based on Petitioner’s
arguments and evidence as summarized above, we determine Petitioner has
IPR2020-00580
Patent 9,667,534 B2
52
shown that Dantu in view of Aziz teaches limitation 1.4.
f) Limitation 1.5
Petitioner contends that Dantu discloses, or at least renders obvious,
limitation 1.5, which recites “routing the packets from one or more third
party sources which are not associated with the virtual private network
exclusively over at least one second connection, different than the dedicated
connection.” Pet. 49–52. Citing its evidence and arguments relating to
limitation 1.1, Petitioner argues that “Dantu discloses a node which receives
packets from one or more third party sources.” Id. at 50 (citing Pet. Section
IV.C.1). Petitioner also argues that Dantu describes nodes 800, 804, 808,
and 812 shown in Figure 8 as “having three tables” and explains that “at
least two of the forwarding tables . . . represent a forwarding table for a
[VPN]” and “[t]he third forwarding table is either for all other user traffic or,
perhaps, merely for a third subscriber of a virtual private network.” Id. at 51
(citing Ex. 1004, 15:19–26). Petitioner further argues, “[i]f the node
determines that the received packets are not associated with the VPN (e.g.,
VPN A), then the packets are routed over a second connection, different than
VPN A’s dedicated connection.” Id. at 52 (citing Ex. 1004, 15:29–35 (“for
each VPN, there exists dedicated paths within the fiber optic ring network
and dedicated output ports and unique forwarding tables”).
Patent Owner does not contest specifically Petitioner’s arguments
with respect to limitation 1.5. See generally PO Resp. Based on Petitioner’s
arguments and evidence as summarized above, we determine Petitioner has
shown that Dantu teaches limitation 1.5.
g) Limitations 1.6, 1.8, and 1.9
Limitations 1.6, 1.8, and 1.9 relate to first and second routing tables.
IPR2020-00580
Patent 9,667,534 B2
53
Petitioner asserts that Dantu discloses or renders obvious limitations 1.6 and
1.9 and that the combination of Dantu and Aziz renders obvious limitation
1.8. Pet. 52–54, 58–64. Patent Owner argues these claim limitations
together and asserts that Dantu’s disclosure of “forwarding tables” does not
teach or suggest “routing tables.” PO. Resp. 53–56. Specifically, Patent
Owner argues that Petitioner relies on “forwarding tables” to meet these
limitations, although Dantu “distinguishes routing tables from forwarding
tables.” Id. (citing Pet. 52–54); Sur-reply 22–23 (citing Ex. 1004, 8:1–4,
13:50–52, 14:2–4). Petitioner responds that as Patent Owner admits,
Dantu’s forwarding tables “contain portions of and are ‘extracted from the
routing tables.’” Reply 20 (citing PO Resp. 55 (quoting Ex. 1004, 14:2–4)).
Petitioner also asserts that Dantu’s forwarding tables are derived from the
“routing tables,” and “contain enough information to identify routes,” as
required of the claimed routing tables. Id. (citing Ex. 1016 ¶ 42). In our
analysis below, after quoting each of these limitations, and describing
Petitioner’s contentions with respect to each of them, we consider the
limitations together in view of Petitioner’s and Patent Owner’s arguments
with respect to the issue of whether Dantu’s “forwarding tables” teach or
suggest “routing tables.”
Limitation 1.6 recites “wherein the method further comprises storing a
first routing table and at least one second routing table,” and Petitioner
contends that Dantu discloses this limitation. Pet. 52–54. Petitioner argues
Dantu discloses that “each node includes a plurality of memories within the
node” and that “[e]ach of the memories stores a forwarding table for each of
a plurality of so called virtual private networks.” Id. at 52 (citing Ex. 1004,
15:10–14 (emphasis omitted)). Petitioner also argues that Dantu specifies
IPR2020-00580
Patent 9,667,534 B2
54
that “a node having three tables illustrates the presence of at least two virtual
private networks” and that “at least two of the forwarding tables shown
within each node of [Figure] 8 represent a forwarding table for a [VPN]” and
“[t]he third forwarding table, is either for all other user traffic or, perhaps,
merely for a third subscriber of a virtual private network.” Id. at 52–53
(citing Ex. 1004, 15:19–26; Ex. 1003 ¶ 102) (emphasis omitted, alterations
in original). Petitioner further argues Dantu explicitly states that “[Figure] 9
is a functional schematic diagram of a node having a plurality of forwarding
tables, each corresponding to a virtual private network according to a
preferred embodiment of the invention.” Id. at 53–54 (Ex. 1004, 15:35–38,
Fig. 9).
Limitation 1.8 recites “wherein routing the encapsulated packets
includes using only one or more routes of the first routing table to route the
encapsulated packets,” and Petitioner contends that Dantu in view of Aziz
discloses, or at least renders obvious, this limitation. Pet. 58–61 (citing Ex.
1003 ¶¶ 109–111). In particular, Petitioner argues that as discussed in
regard to limitation 1.3, Dantu in view of Aziz teaches “the routing of
encapsulated packets.” Id. at 58. Petitioner argues that as discussed with
respect to Figure 9, Dantu discloses each “node having a plurality of
forwarding tables, each corresponding to a virtual private network,” and
“separate paths for separate VPNs, wherein routing the encapsulated packets
(i.e., VPN A . . .) includes using only one or more routes of the first routing
table (i.e., Table 1 in Figure 9).” Id. at 59 (citing Ex. 1004, 15:35–38, Fig. 9,
Ex. 1003 ¶ 109). Petitioner further argues that as shown in Figure 9, “the
paths for VPN A (e.g., PTH B and IP Node C) are separate from the paths
for the other VPNs, or any non-VPN user traffic.” Id. (citing Ex. 1004, Fig.
IPR2020-00580
Patent 9,667,534 B2
55
9, 15:12–14, 15:33–35). In addition, Petitioner argues that as shown in
Figure 8, Dantu discloses that “[e]ach virtual private network includes its
own forwarding table” and “that, for each VPN, there exists dedicated paths
within the fiber optic ring network and dedicated output ports and unique
forwarding tables.” Id. at 60–61 (citing Ex. 1004, Fig. 8, 15:21–22, 15:33–
35) (alteration in original).
Limitation 1.9 recites “wherein routing the packets which are not
associated with the virtual private network includes using only one or
more routes of the at least one second routing table,” and Petitioner contends
that Dantu discloses this limitation. Pet. 61–64 (citing Ex. 1003 ¶¶ 112–
114). Petitioner argues Dantu discloses separate paths for separate VPNs,
“wherein routing the packets which are not associated with the virtual
private network (i.e., those associated with VPN B or other non-VPN user
traffic . . . in Figure 9) includes using only one or more routes of the at least
one second routing table (i.e., Tables 2 or 3 in Figure 9).” Id. at 62 (citing
Ex. 1004, Fig. 9) (emphasis omitted). Petitioner also argues that as shown in
Figure 9, “the paths for VPN B and non-VPN user traffic (e.g., PTH E and H
and IP Nodes F and I) are separate from the paths for VPN A.” Id. (citing
Ex. 1004, Fig. 9, 15:33–35, 15:12–14). Petitioner further argues Dantu
specifies with respect to Figure 8, that “a node having three tables illustrates
the presence of at least two virtual private networks” and that “at least two
of the forwarding tables shown within each node of [Figure] 8 represent a
forwarding table for a [VPN]” and “[t]he third forwarding table, is either for
all other user traffic or, perhaps, merely for a third subscriber of a virtual
private network.” Id. at 62–63 (citing Ex. 1004, Figure 8, 15:19–26; Ex.
1003 ¶ 113) (alteration in original).
IPR2020-00580
Patent 9,667,534 B2
56
Patent Owner does not dispute Petitioner’s arguments concerning
limitations 1.6, 1.8, and 1.9, except to assert that Dantu distinguishes
between forwarding tables and routing tables throughout its specification,
and Petitioner’s “reliance on forwarding tables to qualify as ‘routing tables’
is improper.” PO Resp. 54; Sur-reply 22–23. In particular, Patent Owner
argues that Dantu’s central node shown in Figure 4 “shows that the two
different types of tables are separate even when found on the same node.”
PO Resp. 54 (citing Ex. 1004, Fig. 4 (with routing table 404A highlighted in
blue, and forwarding table 404B highlighted in red)). Patent Owner notes,
however, that Dantu’s Figures 5 and 9 show storage solely of forwarding
tables. Id. at 54–55 (citing Ex. 1004, Fig. 5 (with forwarding table 594A
highlighted in red) and Fig. 9 (with VPN forwarding tables 904, 908, 912
highlighted in red)). Patent Owner also argues Dantu explains that routing
tables contain different information than forwarding tables. Id. at 55. Patent
Owner asserts that “[r]outing tables store the complete route of a packet,
from its source to its destination, ‘specifying routing through a fiber optic
ring network (and beyond).’” Id. (citing Ex. 1004, 8:1–3). Patent Owner
also asserts that “[f]orwarding tables, on the other hand, contain only
information about the path to the packet’s next hop.” Id. (citing Ex. 1004,
17:1–3). Patent Owner further asserts that Dantu discloses “forwarding
tables are ‘extracted from the routing tables’ at the central node and then
sent to the forwarding nodes.” Id. (citing Ex. 1004, 13:50–52, 14:2–4). In
addition, Patent Owner quotes a portion of Dr. Haas’s deposition testimony
and argues that Dr. Haas confirmed the fundamental difference between
routing tables and forwarding tables, which Patent Owner asserts is that
“forwarding tables [] contain[] limited information about the next hop only,
IPR2020-00580
Patent 9,667,534 B2
57
while routing tables contain much more complete route information.” Id. at
56 (citing Ex. 2005, 52:8–18; Ex. 2004 ¶ 57).
For several reasons, we determine Petitioner has shown that Dantu’s
“forwarding tables” teach or suggest “routing tables” as recited in these
limitations. First, as Petitioner notes, Patent Owner acknowledges that
Dantu discloses that its forwarding tables “are extracted from the routing
tables.” Reply 20 (citing PO Resp. 55 (quoting Ex. 1004 14:2–4)). Thus,
we agree with Petitioner that because Dantu’s forwarding tables are directly
derived from the routing tables, they contain enough information to identify
routes as required of the routing tables in these limitations. Id. (citing Ex.
1016 ¶ 42). Second, claim 1 recites routing tables that each identify “one or
more routes.” Ex. 1001, 16:19–24. As Petitioner argues, Dantu specifically
discloses that its forwarding tables identify one or more path routes for the
data packets. Reply 21 (citing Ex. 1004, 4:60–62, 11:19–23). In that regard,
Dantu discloses that “the forwarding table provides path routes and
forwarding for the data packets on a packet by packet basis.” Ex. 1004,
4:60–62 (emphasis added). Dantu also discloses that “[t]he forwarding
tables for each of the nodes are then created so that the other nodes will
forward user traffic at the packet level through the fiber optic ring network
along path routes that are consistent with those defined in the routing
tables created by logic device 324.” Id. at 11:19–23 (emphasis added).
Third, consistent with Petitioner’s argument, we determine that the
testimony of Patent Owner’s expert, Dr. Rabinovich, that a person of
ordinary skill would have known the difference between routing and
forwarding tables around 2000 does not persuasively support Patent Owner’s
argument. Reply 20 (citing Ex. 2004 ¶ 57). This testimony is based on what
IPR2020-00580
Patent 9,667,534 B2
58
Dr. Rabinovich refers to as “a core preparation textbook” for Cisco’s CCIE
certification. Ex. 2004 ¶ 57 (citing Ex. 2008). In his declaration, Dr.
Rabinovich states that the textbook “discusses RIB (‘Routing Information
Base,’ technology term for a routing table) and FIB (‘Forwarding
Information Base,’ for a forwarding table) as distinct concepts.” Id.
However, at his deposition, Dr. Rabinovich testified, “I didn’t read the entire
document. I just needed substantiation of my opinion that the routing tables
are distinct from forwarding tables that would come from that period of
time.” Ex. 1017, 74:7–75:6. However, as Petitioner argues, and we agree,
“the document makes exactly the opposite point.” Reply 20. Although Dr.
Rabinovich states that the FIB discussed in the document is a forwarding
table, the document states that “IP prefixes from each routing process are
inserted in the central forwarding information base (FIB). This is the
routing table used for actual packet forwarding.” Id. at 20–21 (citing Ex.
2008, 109). Thus, even the document Patent Owner relies on to prove that
forwarding tables cannot be routing tables states explicitly that “the
forwarding table is a routing table.” See Ex. 1016 ¶¶ 43–44.
Fourth, the portion of Dr. Haas’s deposition testimony quoted by
Patent Owner is not persuasive of Patent Owner’s argument. PO Resp. 56
(citing Ex. 2005, 52:8–18). Petitioner argues that Patent Owner attempts to
use the quote to “suggest that routing tables and forwarding tables are
disparate and divorced concepts.” Reply 21. However, Petitioner also
argues, and we agree, the deposition discussion was about the way those
terms are used in Dantu, and Dr. Haas was specifically referring to the text
of Dantu. Id. at 21–22 (citing Ex. 2005, 52:8–18). And, we note that in the
quoted portion of Dr. Haas’s deposition, he testified that the forwarding
IPR2020-00580
Patent 9,667,534 B2
59
table at the forwarding node “does not include the full route. [It o]nly
includes pieces of these routes.” See PO Resp. 56 (emphasis omitted). This
testimony is consistent with Petitioner’s position, as discussed supra, that
the forwarding table at the forwarding node provides path routes for the data
packets entering that node.
In its Sur-reply, Patent Owner implies that Petitioner contends the
terms “forwarding table” and “routing table” are the same or synonymous in
Dantu. See Sur-reply 23. That is incorrect because Petitioner does not argue
they are the same or synonymous in Dantu, but, rather, that Dantu’s
forwarding tables teach the routing tables recited in claim 1. Reply 21
(citing Ex. 1004, 4:60–62 (“the forwarding table provides path routes and
forwarding for the data packets on a packet by packet basis”), 11:19–23).
We agree with Petitioner that a person of ordinary skill in the art
would have understood that Dantu’s forwarding tables identify routes, as
required of the routing tables in these limitations of claim 1. Id. at 22 (citing
Ex. 1016 ¶¶ 45–47).
For the reasons stated above, we determine that although Dantu
describes both “forwarding tables” and “routing tables,” Petitioner has
shown Dantu teaches that the “forwarding tables” in the forwarding nodes
perform the function of routing packets, i.e., identify path routes for packets
to be forwarded or routed through the fiber optic ring network or output to
an external internet destination. Thus, we determine Petitioner has shown
that Dantu teaches that the forwarding tables perform the routing
functionality of the “routing tables,” as recited in limitations 1.6, 1.8, and
1.9. We also determine Petitioner has shown that Dantu teaches or suggests
limitation 1.6 because the nodes shown in Figures 8 and 9 include a
IPR2020-00580
Patent 9,667,534 B2
60
“forwarding table” for each of a plurality of VPNs (i.e., “first routing table”
and “second routing table”) and each “forwarding table” performs the
function of the claimed “routing table” by specifying the routes or paths for
packets to be forwarded through the fiber optic ring network or output to an
external internet destination. Similarly, Petitioner has shown that Dantu in
view of Aziz teaches or suggests limitation 1.8 because the packets
identified as associated with the VPN, and encapsulated, would be routed
“using only one or more routes of the first routing table.” As discussed
supra, Petitioner persuasively shows that one of ordinary skill in the art
would have combined the teachings of Dantu and Aziz for several reasons,
including providing additional security for the data packets being sent
according to each VPN, and would have had a reasonable expectation of
success in doing so. See § III.D.3.(d)(3). And, Petitioner has shown that
Dantu teaches or suggests limitation 1.9 because the packets that are not
associated with the VPN would use “only one or more routes of the at least
one second routing table.”
h) Limitation 1.7
Limitation 1.7 recites “wherein one or more routes identified by the
first routing table are mutually-exclusive to one or more routes identified by
the at least one second routing table,” and Petitioner contends that Dantu
discloses, or at least renders obvious, this limitation. Pet. 54–58 (citing Ex.
1003 ¶¶ 105–108). As discussed above regarding limitation 1.6, Dantu
teaches that each node as shown in Figure 8 has a forwarding table for a
specified VPN and additional tables for all other traffic. Ex. 1004, 15:19–
26, 15:35–38, Fig. 8; Ex. 1003 ¶ 106. Petitioner also argues Dantu discloses
that each VPN shown in Figure 8 contains “dedicated paths within the fiber
IPR2020-00580
Patent 9,667,534 B2
61
optic ring network and dedicated output ports and unique forwarding
tables.” Pet. 56 (citing Ex. 1004, 15:33–35). Petitioner provides a version
of Figure 8 (with color added), which is reproduced below.

Id. Petitioner argues this colored version of Figure 8 shows the table that
corresponds to VPN A (shown in red) routes packets over one or more
routes (e.g., highlighted in orange) and the other tables (shown in yellow)
route packets not associated with the VPN over at least one or more different
routes (e.g., external internet destinations highlighted in green or other
dedicated paths). Id. Thus, according to Petitioner, Figure 8 of Dantu
“discloses paths separate from the specified VPN path to external internet
IPR2020-00580
Patent 9,667,534 B2
62
destinations,” and “[t]hese paths are ‘dedicated paths,’ which are mutually
exclusive.” Id. at 57 (citing Ex. 1004, 15:12–14 (“In a virtual private
network, a subscriber is allocated a path and supporting resources for
the subscriber’s exclusive use.”). Moreover, as also discussed above,
Petitioner argues Dantu Figure 9 shows ‘“a functional schematic diagram of
a node having a plurality of forwarding tables, each corresponding to a
virtual private network,’ and each having separate paths.” Id. (citing Ex.
1004, 15:35–38, Fig. 9).
Patent Owner contends that Dantu does not teach limitation 1.7
because, even assuming Dantu’s forwarding tables could be read as “routing
tables,” the forwarding tables do not store “mutually-exclusive” routes. PO
Resp. 57–60; Sur-reply 23–26. Patent Owner argues that in the MPLS
embodiment of Dantu, the MPLS label specifies “a time slot in embodiments
with a single ring, or both a time slot and which ring to use in a dual ring
configuration.” PO Resp. 57–58 (citing Ex. 1004, 13:62–14:2). Patent
Owner argues that in non-MPLS embodiments of Dantu, the IP addresses in
the forwarding tables indicate a specified port of the node through which the
packet is to be output to the internet or the channel through which the packet
is to be transmitted, or both. Id. at 58 (citing Ex. 1004, 14:54–62).
According to Patent Owner, “[t]o the extent that the forwarding table
identifies a channel, that channel cannot specify a ‘route mutually exclusive’
of other routes. All that is exclusive for the channels is the time slot; they all
travel around the same ring.” Id. Patent Owner also asserts that “[a]ll
packets, whether VPN or non-VPN travel on the same ring. The VPN and
non-VPN paths, therefore, cannot be mutually exclusive.” Id. at 59. Patent
Owner further argues that Dantu states that “the VPNs have ‘dedicated paths
IPR2020-00580
Patent 9,667,534 B2
63
within the fiber optic ring network’” (id. at 60 (citing Ex. 1004, 15:33–34)),
“[b]ut what is ‘dedicated’ is the time slot, not the link in the ring.” Id. at 60.
Moreover, Patent Owner argues that to the extent the forwarding table
specifies an egress port to the internet, “that fact does not apply a route
exclusive of non-VPN traffic.” Id.
After considering Patent Owner’s and Petitioner’s arguments, we
determine Petitioner has shown that the routes provided in each of Dantu’s
VPN “routing tables” are mutually-exclusive, as required by limitation 1.7.
First, as Petitioner argues, and Patent Owner admits, Dantu discloses that
“for each VPN, there exists dedicated paths within the fiber optic ring
network and dedicated output ports and unique forwarding tables.” Reply
23 (citing Ex. 1004, 15:32–34; PO Resp. 60). Petitioner persuasively shows
that a person of ordinary skill in the art would have understood Dantu’s
“dedicated paths” to be mutually-excusive routes because Dantu discloses
that “[i]n a virtual private network, a subscriber is allocated a path and
supporting resources for the subscriber’s exclusive use.” Id. at 23 (citing
Ex. 1004, 15:14–16, 5:1–5 (“for at least one virtual private network . . . a
subscriber is assigned specified communication channels or resources for
transporting the subscriber data”)) (alteration in original). Petitioner has also
persuasively shown that a person of ordinary skill in the art would have
understood that “setting aside dedicated paths with exclusive use of those
paths and resources meets the mutually-exclusive route requirement, as this
is precisely what the ’534 patent does.” Id. (citing Ex. 1016 ¶¶ 48–50). As
Dr. Haas opines, the ’534 patent makes this clear by explaining that the
patented system “route AlterWAN packets through high-bandwidth, low
hop-count paths and route other internet traffic along other paths.” Ex.
IPR2020-00580
Patent 9,667,534 B2
64
1016 ¶ 51 (citing Ex. 1001, 4:38–41, 15:2–8).
Second, Petitioner argues, and we agree, that although Dantu
describes routing packets from different VPNs along the same ring network,
“this does not mean that these dedicated exclusive paths are not mutually
exclusive routes.” Reply 24. Petitioner argues that Patent Owner relies on
disclosures in Dantu that the MPLS labels identify the channel on which the
packet is to be transmitted, and “[t]hus, the label defines the ring (assuming
a two ring system), the frequency and the time slot in which the data packet
is to be transmitted, and then Patent Owner “makes the leap” that “all that is
exclusive for the channels is the time slot.”12 Id. (citing PO Resp. 57–58
(quoting Ex. 1004, 13:62–14:2)) (alteration in original); see also Sur-reply
23–24 (stating “nothing about Dantu’s paths is exclusive except the time
slot”). In response, Petitioner asserts that even if Dantu’s exclusive paths
are limited to teaching exclusive frequency and time slot, a person of
ordinary skill would have understood that such dedicated paths are mutually
exclusive routes. Id. (citing Ex. 1016 ¶¶ 51–54). We agree with Petitioner
because, as Petitioner asserts, “[l]ike Dantu, the ’534 patent does not teach
the use of totally separate facilities for packets belonging to the VPN, but for
example, the ’534 patent specifically discusses the “selection of only

12 Petitioner also asserts this argument should be rejected because it is
“based purely on attorney argument.” Reply 22. We note Patent Owner
quotes portions of Dantu regarding specifying “a channel” (see Exhibit
1004, 13:17–22, 13:62–14:2, 14:54–62), but Patent Owner has not cited any
evidence to specifically support its argument that “all that is exclusive for
the channels is the time slot.” See PO Resp. 58–60; see In re Geisler, 116
F.3d 1465, 1470 (Fed. Cir. 1997) (explaining that attorney arguments that
are unsupported by factual evidence are entitled to little probative value).
Thus, we give this argument little weight.
IPR2020-00580
Patent 9,667,534 B2
65
ISX/ISP facilities that limit the traffic in their data paths so as to have a
great deal of spare capacity.” Id. (quoting Ex. 1001, 7:15–20) (emphasis
added). Thus, relying on Dr. Haas’s testimony, Petitioner persuasively
shows that “the ’534 patent does not require their mutually-exclusive routes
to use totally different routers or nodes, and instead, like Dantu requires
them to use separate paths and resources that are made available only to
VPN traffic.” Id. (citing Ex. 1016 ¶ 55).
For the above reasons, Petitioner persuasively shows that Dantu
teaches “wherein one or more routes identified by the first routing table are
mutually-exclusive to one or more routes identified by the at least one
second routing table.”
i) Conclusion
For the above reasons and on the complete trial record, we determine
Petitioner has shown by a preponderance of the evidence that the
combination of Dantu and Aziz teaches or suggests the subject matter of
claim 1 and has provided sufficient reasoning with rational underpinning for
combining these references in the manner claimed with a reasonable
expectation of success.
4. Dependent claim 6
Claim 6 depends from claim 1 and further recites (with paragraph
notations added as in the Petition):
[6.1] wherein the machine is associated with a first endpoint of the
first network;
[6.2] the specific destination corresponds to a second endpoint of the
first network;
IPR2020-00580
Patent 9,667,534 B2
66
[6.3] the dedicated connection connects said first endpoint with the
second endpoint of the first network;
[6.4] identifying includes examining header information for received
packets,
[6.5] comparing a network destination address from said header
information with a predetermined destination address outside of the
first network, and
[6.6] determining that packets are associated with the virtual private
network when the network destination address matches the
predetermined destination address; and
[6.7] the specific destination is to forward packets associated with the
virtual private network from the first network toward the network
destination address.
Ex. 1001, 16:54–17:3.
Petitioner contends that Dantu in view of Aziz teaches or suggests the
limitations of claim 6 and that a person of ordinary skill would have been
motivated to combine these references as set forth in the claim with a
reasonable expectation of success. Pet. 64–84. Patent Owner does not
contest specifically Petitioner’s arguments with respect to limitations 6.1–
6.3 and 6.7, but Patent Owner does contest Petitioner’s arguments regarding
limitations 6.4, 6.5, and 6.6. See PO Resp. 61–72; Sur-reply 27–30. We
consider each limitation of claim 6 below, and we determine Petitioner has
shown that the combination of Dantu and Aziz teaches or suggests the
subject matter of claim 6.
IPR2020-00580
Patent 9,667,534 B2
67
a) Limitations 6.1, 6.2, and 6.3
Limitation 6.1 recites that “the machine is associated with a first
endpoint of the first network,” and limitation 6.2 recites that “the specific
destination corresponds to a second endpoint of the first network.” Ex.
1001, 16:54–57. Petitioner has shown that Dantu teaches these limitations
because Figure 8 shows “a ring network in which packets are routed from
one node that serves as an (origin) endpoint (i.e., a first endpoint of the first
network) to another node that serves as an (destination) endpoint (i.e., a
second endpoint of the first network).” Pet. 65–70 (citing Ex. 1004, Fig. 8,
14:67–15:10, 15:25–30, 15:48–52; Ex. 1003 ¶¶ 116–123).
Regarding limitation 6.3, Petitioner has shown that Dantu discloses
“the dedicated connection connects said first endpoint with the second
endpoint of the first network.” Id. at 71–73. In that regard, as discussed
with respect to limitation 1.4, Dantu discloses routing packets identified as
associated with a virtual private network via a “dedicated connection” to a
specific destination associated with the first network. Id. at 71 (citing Ex.
1004, 15:14–16, 15:26–30, 15:30–35; Ex. 1003 ¶ 124); see supra § III.D.3.e.
Petitioner has also shown Dantu discloses the dedicated connection connects
the first endpoint with the second endpoint of the first network. Id. at 71–73
(citing Ex. 1004, 14:67–15:10, Fig. 8; Ex. 1003 ¶¶ 124–126).
b) Limitation 6.4
Limitation 6.4 recites “identifying includes examining header
information for received packets.” Ex. 1001, 16:60–61. Petitioner argues
Dantu teaches that the “identifying” step of limitation 1.2 “includes
examining header information for received packets.” Id. at 73–75 (citing
Ex. 1003 ¶¶ 127–128). Petitioner argues that, as discussed with respect to
IPR2020-00580
Patent 9,667,534 B2
68
limitation 1.2, Dantu discloses “identifying packets as associated with a
virtual private network by analyzing incoming packets in order to determine
which forwarding table to use in routing each received packet.” Id. at 73
(citing Ex. 1004, 14:63–66, 15:19–26, 15:60–64, Figs. 8 and 10). Petitioner
also argues that a person of ordinary skill in the art would have understood
that this analysis requires an examination of the header information “to
determine the source and destination of the packet.” Id. Specifically,
Petitioner asserts that Dantu discloses central IP router 204 receives user
traffic and “routes it through the fiber ring network of IP routers according
to IP addresses specified in the headers of the IP packets according to
TCP/IP formats and protocols.” Id. at 73–74 (citing Ex. 1004, 7:44–47).
Petitioner also asserts that Dantu discloses “the node examines specified
destination information (e.g., destination node ID) within the header to
determine whether the packet of user traffic is to be output or forwarded.”
Id. at 74 (citing Ex. 1004, 14:54–57). Petitioner further asserts Dantu
discloses that “[i]in addition to determining the forwarding table, the node
also examines the header to determine if it includes an egress port address
that is a port of the node (step 1010).” Id. (citing Ex. 1004, 16:32–35, Fig.
10; Ex. 1003 ¶ 127).
Patent Owner contends Petitioner cannot establish that Dantu teaches
or suggests limitation 6.4 because Dantu does not identify received packets
as associated with a virtual private network by examining header
information for the received packets. PO Resp. 61–69. Patent Owner argues
that the portions of Dantu cited by Petitioner with respect to the identifying
step make clear that
the forwarding node’s determination of which forwarding table
to use is based on the identity for the path from which the packet
IPR2020-00580
Patent 9,667,534 B2
69
is received. It is not based on examining header information.
The ‘path ID’ is not information contained in the header.
Id. at 62 (citing Ex. 1004, Fig. 11). Figure 11 of Dantu, as reproduced by
Patent Owner, is reproduced below.

Id. at 63. Figure 11 is a diagram illustrating the elements of a data packet
transmitted by a node on a fiber optic ring network. Ex. 1004, 5:57–61.
According to Patent Owner, Figure 11 shows the Dantu packet with the
fields of the header, and Path ID is not one of them. PO Resp. 62.
Patent Owner argues that Figure 9 “also illustrates this point, with the
path being what dictates which forwarding table to use.” Id. at 63–64 (citing
Ex. 1004, Fig. 9).
Patent Owner asserts that because claim 1’s step of “identifying”
received packets as associated with a VPN or not at the forwarding nodes
does not include “examining header information,” Petitioner “returns to the
shell-game approach” and argues that a person of ordinary skill in the art
would have understood that “this analysis requires the examination of the
header information of the received packet in order to determine the source
and destination of the packet.” Id. at 64 (citing Pet. 73). Patent Owner
IPR2020-00580
Patent 9,667,534 B2
70
argues that this statement is unsupported attorney argument, and is incorrect
because ‘“this analysis’ uses the ‘path ID’ of the path from which the data
packet was received and thus does not require the determination of the
source and destination of the packet.” Id. (citing Ex. 2004 ¶ 62).
Patent Owner then argues that Petitioner’s quotation of a portion of
Dantu concerning Figure 2 and describing a central IP router receiving user
traffic and routing it through the fiber optic ring network “according to IP
addresses in the headers of the IP packets” is different from what Petitioner
contends does the identifying (i.e., the forwarding node) and is in Dantu’s
“Potential Solutions” section, rather than the “Preferred Solutions” section.
Id. at 65–67 (citing Pet. 73–74 (quoting Ex. 1004, 7:44–47); Ex. 2004 ¶¶ 63–
64; Ex. 1004, Fig. 2). And, Patent Owner also argues that Dantu’s Figure 5
of a forwarding node “makes clear that forwarding nodes are separate from
IP routers, separating the forwarding node from the IP node graphically.”
Id. at 66–67 (citing Ex. 1004, Fig. 5).
In regard to Petitioner’s citation to Dantu’s disclosure about
examining header information in column 14, lines 54–57, Patent Owner
argues “that section concerns forwarding in a non-VPN embodiment with a
single forwarding table, an embodiment that never does what [Petitioner]
contends is ‘identifying.’ Even if it did, it would still concern a separate
step, one using a selected forwarding table, not selecting a particular
forwarding table.’” Id. at 68.
With respect to Petitioner’s citation to the portion of Dantu stating
“the node also examines the header to determine if it includes an egress port
address that is a port of the node (step 1010)” (Pet. 74 (quoting Ex. 1004,
16:32–35)), Patent Owner argues that step 1010 occurs “after the selection
IPR2020-00580
Patent 9,667,534 B2
71
of the forwarding table.” PO Resp. 68 (citing Ex. 1004, Fig. 10; Ex. 2004 ¶
68). According to Patent Owner, “[t]hat step concerns whether to forward
the packet outside the ring using the previously selected forwarding table
and is independent of the selection of the forwarding table.” Id. Patent
Owner also argues that Figure 10 graphically demonstrates that selection of
a forwarding table (in step 1008) and the determination on whether to send
the packet to the egress port (in step 1010) are two separate stages, “again
contradicting the point [Petitioner] is trying to make.” Id. at 69.
After considering all of Patent Owner’s and Petitioner’s arguments,
we determine Petitioner has shown that Dantu teaches limitation 6.4. In
describing Figure 10, Dantu discloses that once a node is set up with
forwarding tables, it begins to receive user traffic in packet form and, if the
fiber optic ring network includes VPNs, “the node determines the
appropriate forwarding table according to the path ID from which the packet
was received (step 1008).” Ex. 1004, 16:24–31. Petitioner has persuasively
shown that a person of ordinary skill would have understood that “the [p]ath
ID is exactly the type of information that would be found in the packet
header.” Ex. 1016 ¶ 57; Ex. 1004, Fig. 11. Although Patent Owner argues,
citing Dantu’s Figure 11, that the path ID is not information contained in the
header, Petitioner argues, and we agree, that “Figure 11 . . . clearly shows
the ‘Path Route’ as being present in the label, which is part of the header.”
Reply 25–26 (citing Ex. 1004, Fig. 11 (highlighting the “Path Route”
information in the label 1116)). Petitioner also argues, and we agree, that a
person of ordinary skill in the art would have understood that in the context
of Dantu’s packet routing system, determining the path route also determines
the destination. Id. at 26 (citing Ex. 1016 ¶ 57). Dr. Haas opines that “[t]he
IPR2020-00580
Patent 9,667,534 B2
72
path route is unique to a particular destination, and therefore identifies the
destination.” See Ex. 1016 ¶ 57. Thus, as Petitioner argues, we determine
that Dantu teaches “identifying the received packets as associated with a
VPN by examining header information for source and destination address
information.” Reply 26.
Patent Owner argues that Petitioner then “returns to the shell-game
approach.” PO Resp. 64–69. We do not agree. First, as Petitioner argues,
Patent Owner’s focus on Figure 2 of Dantu as being different and in the
Potential Solutions section is inapposite because Figure 2 shows the general
architecture of the ring topology present in the other figures, and a person of
ordinary skill would have understood that “the earlier figures and
‘embodiments’ describe the underlying way in which the multiple-VPN
embodiment discussed with respect to Figure 8 operates.” Reply 27 (citing
Ex. 1016 ¶¶ 58–59). Second, Patent Owner’s argument that the IP router
attached to interface 512A in Dantu’s Figure 5 suggests that forwarding
nodes cannot perform functions like IP routing is not persuasive because as
Petitioner argues, and as discussed above, the exact same configuration is
shown with respect to a central ingress node in Figure 4, “which [Patent
Owner] does not dispute functions as an IP router.” Id.
Third, regarding Patent Owner’s argument that Dantu’s disclosure
about examining header information in column 14, lines 54–57 is not
pertinent because “that section concerns forwarding in a non-VPN
embodiment with a single forwarding table” (see PO Resp. 67–68),
Petitioner argues, and we agree, that Patent Owner again ignores the fact that
a person of ordinary skill reading Dantu would have understood that “the
earlier embodiments describe background information about the working of
IPR2020-00580
Patent 9,667,534 B2
73
the system that would also apply to the embodiment with multiple VPNs.”
Id. at 27 (citing Ex. 1016 ¶ 60).
Fourth, Patent Owner’s argument concerning Dantu’s statement that
“[i]n addition to determining the appropriate and corresponding forwarding
table, the node also examines the header to determine if it includes an egress
port address that is a port of the node (step 1010)” is unavailing. PO Resp.
68 (citing Ex. 1004, 16:28–35) (emphasis omitted). Patent Owner argues
this statement means that Dantu does not teach examining the header in
selecting the proper VPN because, as illustrated in Figure 10, step 1010
occurs “after the selection of the forwarding table.” Id. (citing Ex. 1004,
Fig. 10; Ex. 2004 ¶ 68). However, as discussed above, and as Petitioner
argues, the step of identifying the path route does require identifying the
source and destination via the packet header. Reply 28 (citing Ex. 1016
¶ 61). Petitioner also argues, and we agree, that a person of ordinary skill in
the art would understand that “these two steps can be performed
simultaneously.” Id. As Petitioner argues, and we agree:
Indeed, the language “the node also examines the header to
determine if it includes an egress port address that is a port of the
node” suggests that the header was examined for at least two
items: (1) to determine the corresponding forwarding table to be
used for received user traffic and (2) to determine if it includes
an egress port address that is a port of the node.
Id.
c) Limitations 6.5 and 6.6
Limitation 6.5 recites “comparing a network destination address from
said header information with a predetermined destination address outside of
the first network.” Limitation 6.6 recites “determining that packets are
associated with the virtual private network when the network destination
IPR2020-00580
Patent 9,667,534 B2
74
address matches the predetermined destination address.”
Patent Owner argues these limitations together and contends “Dantu
does not determine that packets are associated with a virtual private network
based on a destination address.” PO Resp. 70. Patent Owner then sets forth
several arguments that are the same or substantially the same as the
arguments Patent Owner presented regarding limitation 6.4. Id. at 71–72;
see also Sur-reply 27–30.
As discussed above regarding limitation 6.4, Petitioner has shown that
Dantu teaches identifying packets as associated with a VPN by examining
header information for source and destination address information.
Petitioner has also shown Dantu discloses that when “a data packet is
received, the node examines the contents of the forwarding table in
relation to specific information within or known about the received user
traffic,” and that “the node examines specified destination information
(e.g., destination node IP) within the header to determine whether the
packet of user traffic is to be output or forwarded.” Pet. 75 (citing Ex. 1004,
14:42–46, 14:54–57; Ex. 1003 ¶¶ 129–130). As also discussed above,
Petitioner has shown that Dantu discloses “the node also examines the
header to determine if it includes an egress port address that is a port of the
node (step 1010).” Id. at 75–76 (citing Ex. 1004, 16:32–35, Fig. 10; Ex.
1003 ¶ 131). Moreover, Petitioner has shown that Dantu provides an
example in which “an entry in the forwarding table would define an egress
port ID or a forwarding path ID for the given data packet” and “[t]he packet
either is then routed to an external destination (step 1012) or is forwarded
onto the fiber optic ring network (step 1014).” Id. at 76 (citing Ex. 1004,
16:32–35, 16:39–43, Fig. 10; Ex. 1003 ¶ 132).
IPR2020-00580
Patent 9,667,534 B2
75
For the same reasons discussed above regarding limitation 6.4, Patent
Owner’s arguments that Dantu does not identify or associate packets with a
VPN based on “a destination address” are unpersuasive. Thus, with respect
to limitation 6.5, we agree with Petitioner that Dantu discloses “comparing a
network destination address (e.g., destination node ID) from said header
information with a predetermined destination address outside of the first
network (e.g., external destination address contained in the routing table).”
Id. at 77 (citing Ex. 1003 ¶¶ 129–133).
Regarding limitation 6.6, Petitioner contends that Dantu discloses or
renders it obvious. Pet. 77–78. Petitioner argues that because Dantu teaches
that each VPN is associated with its own forwarding table, determining the
appropriate forwarding table includes determining that packets are
associated with a virtual private network. Id. at 78 (see Ex. 1004, 15:21–22;
Ex. 1003 ¶ 135). Petitioner also argues “[t]his is done by the node, which
examines the header information, including the destination node ID.” Id.
(citing Ex. 1003 ¶ 135).
As stated, for the same reasons discussed above regarding limitation
6.4, Patent Owner’s arguments that Dantu does not identify or associate
packets with a VPN based on “a destination address” are unpersuasive or
unavailing. Thus, with respect to limitation 6.6, we agree with Petitioner
that Dantu discloses “determining that packets are associated with the virtual
private network (i.e., by selecting the proper forwarding table) when the
network destination address (e.g., destination node ID) matches the
predetermined destination address (i.e., destination address in the forwarding
table).” Id. (citing Ex. 1003 ¶¶ 134–135) (emphasis omitted).
IPR2020-00580
Patent 9,667,534 B2
76
d) Limitation 6.7
Limitation 6.7 recites “the specific destination is to forward packets
associated with the virtual private network from the first network toward the
network destination address.” Ex. 1001, 17:1–3. Petitioner contends that
Dantu in view of Aziz discloses or at least renders obvious this limitation.
Pet. 79–84. Specifically, Petitioner argues that as explained regarding
limitation 1.4, Dantu discloses that the packets identified as associated with
the specified VPN are “routed according to the corresponding table to a
specific destination according to the destination address located in the packet
header,” and a person of ordinary skill in the art “would understand that
once the packets are received by the specific destination router, they must be
forwarded to the network destination address (e.g., a server, printer,
computer workstation, etc.).” Id. at 80 (citing Ex. 1003 ¶ 138). Petitioner
also argues that to the extent it is determined Dantu does not explicitly
disclose this limitation, Aziz does so. Id. at 81. As also discussed in regard
to limitation 1.4, Petitioner argues Aziz discloses that the encapsulated
packets are “transmitted to the destination network” (id. at 81–82 (citing Ex.
1005, 8:25–27, Fig. 6 (step 270))), where the packets are decrypted and
“then sent on as in box 340” (id. at 82–83 (citing Ex. 1005, 8:41–43, Fig. 6
(step 340 of transmitting the packet to Host B); Ex. 1003 ¶ 140)).
Patent Owner does not dispute specifically Petitioner’s arguments
regarding limitation 6.7. Based on Petitioner’s arguments and evidence as
summarized above, we determine Petitioner has shown that Dantu discloses
routing packets associated with the virtual private network to a specific
destination, and Aziz discloses that such packets are forwarded from the first
network toward the network destination address (Host B) by the specific
IPR2020-00580
Patent 9,667,534 B2
77
destination. Id. at 83 (citing Ex. 1003 ¶ 142). Thus, we also determine
Petitioner has shown that the combination of Dantu and Aziz teaches
limitation 6.7.
e) Motivation to combine Dantu and Aziz
Petitioner contends that as explained regarding limitation 1.3, a person
of ordinary skill would have been motivated to modify the VPN routing
system of Dantu to use the encapsulation and encryption system of Aziz and
would have been able to do so with a reasonable expectation of success. Pet.
84 (citing Ex. 1003 ¶¶ 81–90, 143). Petitioner also contends that a person of
ordinary skill would have been motivated to look to the teachings of Aziz,
particularly its teachings of forwarding data packets towards the network
destination address, because Dantu “discloses routing the packets from the
ring network to an external IP router, and a [person of ordinary skill in the
art] would look to references like Aziz when determining how to forward the
packets from the external router” to the final network destination address.
Id. (citing Ex. 1003 ¶ 144).
Patent Owner does not present arguments specifically regarding the
motivation to combine Dantu and Aziz with respect to claim 6. See
generally PO Resp. For the reasons discussed regarding limitation 1.3 above
(see supra § III.D.3.d), and Petitioner’s additional argument summarized
above, we find Petitioner has shown that a person of ordinary skill would
have been motivated to combine Dantu and Aziz as in claim 6 and would
have been able to do so with a reasonable expectation of success.
f) Conclusion regarding claim 6
For the above reasons and on the complete trial record, we determine
Petitioner has shown by a preponderance of the evidence that the
IPR2020-00580
Patent 9,667,534 B2
78
combination of Dantu and Aziz teaches each limitation of claim 6 and has
provided sufficient reasoning with rational underpinning for combining
these references in the manner claimed with a reasonable expectation of
success.
5. Dependent claim 8
Claim 8 also depends from claim 1 and further recites:
[8.1] wherein encapsulating packets identified as associated with the
virtual private network includes encrypting those packets using an
encryption key corresponding to a decryption key known a priori to
the destination associated with the first network.
Ex. 1001, 17:13–17.
Petitioner contends that Dantu in view of Aziz discloses or at least
renders obvious claim 8. Pet. 85–88. Initially, Petitioner asserts that the
’534 patent does not define or use the term “known a priori” in the
Specification, but discloses that the “[k]eys are preassigned for each ‘private
tunnel.’” Id. at 85 (citing Ex. 1001, 5:49–51). Petitioner also asserts that as
discussed regarding limitations 1.2 and 1.3, Dantu discloses identifying
packets as associated with a virtual private network, and Aziz discloses
encapsulating packets before routing them over a private network. Id.
Petitioner further asserts that Aziz discloses encrypting the identified packets
“using an encryption key corresponding to a decryption key known a priori
(provided in advance) to the destination associated with the first network”
because Aziz teaches that “the receiving tunnelling [sic] bridge decrypts the
data packets according to locally stored information indicating the
encryption type and decryption key for all packets coming from the source
tunnelling bridge.” Id. at 86–88 (citing Ex. 1005, 2:19–22, 2:47–50, 5:15–
IPR2020-00580
Patent 9,667,534 B2
79
16, 6:39–44, 8:32–38, code (57); Ex. 1003 ¶¶ 146–150). Petitioner also
argues that, as explained in regard to limitation 1.3, a person of ordinary
skill would have been motivated to modify the VPN routing system of Dantu
to use the private network encapsulation and encryption system of Aziz as in
claim 8 and would have been able to do so with a reasonable expectation of
success. Id. at 88 (citing Ex. 1003 ¶¶ 81–90, 151).
Patent Owner does not dispute specifically Petitioner’s arguments
concerning claim 8, but asserts that claim 8 depends from claim 1 and all the
“problems” with the Petition concerning claim 1 “apply to claim 8 as well.”
PO Resp. 72. However, as discussed above, we determine Petitioner has
demonstrated by a preponderance of the evidence that the combination of
Dantu and Aziz teaches the subject matter of claim 1, and we are not
persuaded by Patent Owner’s arguments.
Thus, based on Petitioner’s arguments and evidence as discussed
above, we find Petitioner has demonstrated by a preponderance of the
evidence that the combination of Dantu and Aziz teaches claim 8 and that a
person of ordinary skill in the art would have been motivated to modify
Dantu with Aziz as in claim 8 with a reasonable expectation of success.
IV. CONCLUSION13

13 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. See 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-00580
Patent 9,667,534 B2
80
For the above reasons, we determine Petitioner has proven by a
preponderance of the evidence that claims 1, 6, and 8 of the ’534 patent are
unpatentable on the ground asserted in the Petition.
In summary:

V. ORDER
In consideration of the foregoing, it is hereby
ORDERED that claims 1, 6, and 8 of the ’534 patent are held
unpatentable as obvious under 35 U.S.C. § 103(a) in view of Dantu and
Aziz; 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.

Claims

35
U.S.C. §
Reference(s)/Basis Claims
Shown
Unpatentable
Claims
Not shown
Unpatentable
1, 6, 8 103(a) Dantu, Aziz 1, 6, 8
Overall
Outcome
1, 6, 8
IPR2020-00580
Patent 9,667,534 B2
81
For PETITIONER:
Jordan Rossen
Ashraf Fawzy
UNIFIED PATENTS LLC
jordan@unifiedpatents.com
afawzy@unifiedpatents.com

For PATENT OWNER:
Ragnar Olson
Alison Richards
C. Graham Gerst
Hannah Sadler
GLOBAL IP LAW GROUP, LLC
rolson@giplg.com
arichards@giplg.com
ggerst@giplg.com
hsadler@giplg.com