AlterWAN, Inc.Download PDFPatent Trials and Appeals BoardAug 12, 2021IPR2020-00580 (P.T.A.B. Aug. 12, 2021) Copy Citation 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 Copy with citationCopy as parenthetical citation