`
`IN THE UNITED STATES PATENT & TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`
`TALARI NETWORKS, INC.,
`
`Petitioner,
`
`v.
`
`FATPIPE NETWORKS INDIA LIMITED,
`
`Patent Owner.
`______________________
`
`Case IPR2016-00976
`Patent U.S. 6,775,235
`______________________
`
`
`
`RESPONSE TO PETITION FOR INTER PARTES REVIEW
`
`Pursuant to 37 C.F.R. § 42.120 Exclusive Licensee, FatPipe, Inc. (“FatPipe”
`
`
`
`or “Patent Owner”), submits this Response to Petition for Inter Partes Review
`
`(“Response”) to the Petition for Inter Partes Review of United States Patent No.
`
`6,775,235 filed by Petitioner, Talari Networks, Inc. (“Talari” or “Petitioner”).
`
`
`
`
`
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`I.
`Introduction ...................................................................................................... 1
`II. WAN-path selection technology ..................................................................... 1
`III.
`Person of ordinary skill in the art .................................................................... 7
`IV. Claim construction ........................................................................................... 8
`A.
`“selects between network interfaces on a per-packet
`basis”/“make network path selections on a packet-by-packet
`basis.” .................................................................................................... 9
`“dynamic load-balancing” ................................................................... 15
`B.
`V. Overview of Karol ......................................................................................... 18
`VI. Claim 4 is not anticipated by or obvious over Karol. .................................... 23
`A. Karol does not disclose or render obvious the claimed “packet
`path selector which selects between network interfaces on a
`per-packet basis.” ................................................................................ 23
`Karol does not disclose the claimed “site interface.” .......................... 28
`B.
`VII. Claims 5 and 7–15 are not anticipated by Karol or obvious over Karol
`alone or in view of Stallings. ......................................................................... 34
`A.
`Claim 5 is patentable over Karol alone or in view of Stallings. ......... 34
`1.
`Karol does not anticipate claim 5.............................................. 34
`2.
`Karol does not render obvious claim 5. .................................... 37
`3.
`Karol in view of Stallings does not render obvious claim
`5. ................................................................................................ 40
`Claim 7 is not anticipated by or obvious over Karol. ......................... 42
`Claim 8 is not anticipated by or obvious over Karol. ......................... 45
`Claim 9 is not anticipated by or obvious over Karol. ......................... 51
`Claims 11–13 are not anticipated by Karol or obvious over
`Karol alone or in view of Stallings...................................................... 51
`VIII. Claim 19 is not anticipated by Karol or obvious over Karol alone or in
`view of Stallings. ........................................................................................... 55
`
`B.
`C.
`D.
`E.
`
`
`
`
`i
`
`

`

`
`
`C.
`
`A. Karol does not disclose the claimed “site interface.” .......................... 56
`B.
`Karol does not disclose the claimed “a packet path selector
`which selects between the network interfaces on a per-session
`basis to promote load-balancing.” ....................................................... 56
`Karol does not disclose the claimed “step of sending a packet to
`the controller site interface is repeated as multiple packets are
`sent, and the controller sends different packets of a given
`message to different parallel networks.” ............................................. 59
`IX. Conclusion ..................................................................................................... 60
`
`
`
`
`
`
`ii
`
`

`

`TABLE OF AUTHORITIES
`
`
`
`
`
`
`
`
`
` Page(s)
`
`Case
`
`ActiveVideo Networks, Inc. v. Verizon Commc’ns., Inc.,
`694 F.3d 1312 (Fed. Cir. 2012) .......................................................................... 37, 44
`
`Arendi S.A.R.L. v. Apple Inc.,
`832 F.3d 1355 (Fed. Cir. 2016) ................................................................................ 45
`
`Innogenetics, N.V. v. Abbott Labs.,
`512 F.3d 1363 (Fed. Cir. 2008) .......................................................................... 38, 44
`
`In re Gordon,
`733 F.2d 900 (Fed. Cir. 1984) .................................................................................. 39
`
`In re GPAC Inc.,
`57 F.3d 1573 (Fed. Cir. 1995) .................................................................................... 7
`
`In re NTP, Inc.,
`654 F.3d 1279 (Fed. Cir. 2011) ............................................................................ 9, 12
`
`In re Nuvasive,
`842 F.3d 1376 (Fed. Cir. 2016) .......................................................................... 37, 44
`
`In re Translogic Tech., Inc.,
`504 F.3d 1249 (Fed. Cir. 2007) .................................................................................. 8
`
`Kinetic Concepts, Inc. v. Smith & Nephew, Inc.,
`688 F.3d 1342 (Fed. Cir. 2012) .................................................................... 37, 38, 44
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ..........................................................................................passim
`
`PPC Broadband Inc. v. Corning Optical Comm’cns. RF LLC,
`815 F.3d 747 (Fed. Cir. 2016) .................................................................................... 9
`
`Tinnus Enters., LLC v. Telebrands Corp.,
`2017 U.S. App. LEXIS 1198 (Fed. Cir. Jan. 24, 2017) ..................................... 39, 45
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`iii
`
`

`

`TABLE OF AUTHORITIES (Con’t)
`
`
`
`
`
`
`
`
`
`Rules
`
`37 C.F.R. §42.100(b) ................................................................................................. 8
`
`37 C.F.R. § 42.120 ............................................................................................. Cover
`
`Other Authorities
`
`MPEP § 2143.01(V) ................................................................................................. 39
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Page(s)
`
` Page(s)
`
`
`
`
`iv
`
`

`

`
`
`I.
`
`Introduction
`
`The technologies described in the Karol reference and the ’235 patent differ
`
`fundamentally both in their purpose and their routing solutions. Among other
`
`things, those differences raise the issue of whether the inventive per-packet path
`
`selection and dynamic load-balancing described the ’235 patent can be anticipated
`
`by conventional routing tables and routing functions that the ’235 patent expressly
`
`distinguishes from the inventive technology. This Response demonstrates that
`
`Karol and the conventional routing technologies applied in the Petition do not
`
`render the challenged claims unpatentable.
`
`II. WAN-path selection technology
`Petitioner’s own founder, Andrew Gottlieb, has praised FatPipe for its
`
`innovations in the field of WAN-path selection: “FatPipe was perhaps the first
`
`company to deliver WAN aggregation technology focused on supporting WAN
`
`links with dissimilar loss [or] latency characteristics, like multiple public Internet
`
`connections.” (Ex. 2005). The ’235 patent takes that concept even a step further in
`
`describing a system that dynamically load-balances over WAN paths on disparate
`
`networks. Specifically, the ’235 patent is directed to a controller that interfaces
`
`with a site and “two or more disparate networks in parallel” to “provide load
`
`balancing across network connections, greater reliability, and/or increased
`
`security.” (Ex. 1001, Abstract). The ’235 patent’s claimed invention represented a
`
`
`
`1
`
`

`

`
`
`major advancement in the field of computer networking. (See, e.g., Ex. 2011, p. 2).
`
`Sanchaita Datta, the first-named inventor on the ’235 patent, was even honored as
`
`a “Women Innovator” by the Women Tech Council for her major impact on
`
`technology for, among other things, the innovations claimed in the ’235 patent.
`
`(Ex. 2006).
`
`Prior art approaches did not combine two or more disparate networks in
`
`parallel to provide benefits such as dynamic per-packet load-balancing. (Ex. 1001,
`
`col. 4:40–45). Prior art Fig. 2 (below), for example, used a primary network (the
`
`frame relay network 106) and only used the secondary network (the ISDN network
`
`204) when the primary network failed. (Ex. 1001, col. 3:18–28). The primary
`
`network path is used for most or all of traffic while the other path is used only
`
`when the primary path fails. (Ex. 1001, col. 9:55–65). The prior art configuration
`
`of Fig. 2 does not consider load balancing on a packet-by-packet basis, or provide
`
`security by splitting and distributing pieces of messages between disparate
`
`networks. (Ex. 1001, col. 9:65–10:3).
`
`
`
`2
`
`

`

`
`
`
`
`(Ex. 1001, Fig. 2).
`
`Nor did prior art approaches provide dynamic load balancing over multiple
`
`disparate networks. (Ex. 1001, col. 2:56–65). Prior art Fig. 1 (below), for example,
`
`requires that networks agree upon factors relating to communications prior to
`
`traffic being sent. (Ex. 1001, col. 2:52–55). They can provide a rough balance by
`
`sending different types of traffic or flows through particular routers (e.g., router A
`
`or router B), but this does not balance router loads dynamically in response to
`
`actual traffic. (Ex. 1001, col. 2:56–65). The prior art approaches required set-up
`
`with broad granularity and did not load balance dynamically in response to actual
`
`traffic. (Ex. 1001, col. 9:4–9). Other prior art approaches, such as those described
`
`in Figs. 3 and 4 of the ’235 patent, did not provide networks in parallel (Ex. 1001,
`
`col. 3:29–4:4) and could not provide load-balancing or improve reliability (Ex.
`
`1001, col. 3:63–4:4).
`
`
`
`3
`
`

`

`
`
`
`
`(Ex. 1001, Fig. 1).
`
`Other parallel networks, such as those in Fig. 5, did not have the “fine
`
`grained packet routing of the present invention.” (Ex. 1001, col. 5:24–28). These
`
`networks only had coarse routing of traffic or flows where “all packets from
`
`department X might be sent over the frame relay connection 106 while all packets
`
`from department Y are sent over the Internet 500. Or the architecture might send
`
`all traffic over the frame relay network unless that network fails ….” (Ex. 1001,
`
`col. 4:18–22). Such prior-art architectures did not provide dynamic packet-by-
`
`packet routing between disparate networks.
`
`
`
`4
`
`

`

`
`
`
`
`(Ex. 1001, Fig. 5).
`
`The ’235 patent describes numerous parallel networks that can be of many
`
`different types (Ex. 1001, col. 7:6–20) where the networks are divided and routed
`
`by known address ranges. (Ex. 1001, col. 8:23–28). These ranges, for example, can
`
`include 192.168.x.x for a LAN, 200.x.x.x for the Internet, or 196.x.x.x for a Frame
`
`Relay. (Ex. 1001, col. 8:50–53). Packets can be re-routed to different networks by
`
`changing their destination address ranges. (Ex. 1001, col. 9:12–29, col. 13:39–57).
`
`For example, a packet bearing a destination address 10.0.x.x can be changed to
`
`198.x.x x to route it through the frame relay network. (Ex. 1001, col. 9:12–29).
`
`This provided for easy routing of packets between disparate networks. “Without
`
`the invention, . . . network devices are pre-configured … such that all such packets
`
`with [a given] destination address must be sent to [the addressed network], even
`
`though there is [second network] connectivity between the two locations.” (Ex.
`
`1001, col. 8:55–63).
`
`
`
`5
`
`

`

`
`
`The ’235 patent also describes routing packets to improve reliability,
`
`security, and to balance loads in parallel networks. (Ex. 1001, col. 4:40–45, Fig. 9,
`
`col. 13:32–38). As illustrated in the flowchart of Fig. 9 (below), the path selection
`
`may use one or more load balancing, connectivity, or security criteria. (Ex. 1001,
`
`col. 14:59–15:3; col. 11:11–63). Loads can be balanced across the parallel
`
`disparate networks, on a per-packet basis, to load balance after packets leave a
`
`network interface. (Ex. 1001, col. 11:24–27). Packet-by-packet load balancing
`
`provides a finer granularity than what was found in the prior art. (Ex. 1001, col.
`
`9:12–19). Additionally, to improve security, messages can be divided up between
`
`networks. (Ex. 1001, col. 11:46–49). These criteria are applied on parallel
`
`networks, not those which use one network as a fail-over or as an alternative for
`
`another network. (Ex. 1001, col. 9:55–65).
`
`
`
`6
`
`

`

`
`
`
`
`(Ex. 1001, Fig. 9).
`
`III. Person of ordinary skill in the art
`The level of ordinary skill in the art is evidenced by the prior art, among
`
`other things. See In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995). The prior
`
`art discussed herein, and in the declaration of Joel Williams (Ex. 2003),
`
`demonstrates that a person of ordinary skill in the art (“POSA”) would have been a
`
`person with at least a bachelor’s of science or equivalent degree in Computer
`
`
`
`7
`
`

`

`
`
`Science or Electrical Engineering or related technical field with at least 2 years of
`
`experience in a technical field related to network design, administration,
`
`configuration, and/or diagnosis. (Ex. 2003 ¶¶ 49–50).
`
`This Response is supported by the declaration of Joel Williams, an expert in
`
`the field of computer networking. For 38 years, Mr. Williams has worked
`
`extensively in the networking industry, including working with many computer
`
`routing systems. Over the course of his career, Mr. Williams has developed
`
`extensive expertise in the specification, design, and development of networking
`
`equipment and computer systems. (Ex. 2003 ¶¶ 7–18). Mr. Williams offers his
`
`opinion as to the skill level of POSA (¶¶ 49–50), the content and state of the prior
`
`art (¶¶ 56–61), the ’235 patent (¶¶ 51–55), claim construction (¶¶ 30–48), and the
`
`teachings and suggestions that POSA would understand based on the alleged prior
`
`art presented in the Petition (¶¶ 62–113).
`
`IV. Claim construction
`In an inter partes review, claim terms in an unexpired patent are interpreted
`
`according to their broadest reasonable interpretation (“BRI”) in view of the
`
`specification in which they appear. 37 C.F.R. §42.100(b). Under BRI, claim terms
`
`receive their ordinary and customary meaning as would be understood by one of
`
`ordinary skill in the art in the context of the entire disclosure. In re Translogic
`
`Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). “While the Board must give the
`
`
`
`8
`
`

`

`
`
`terms their broadest reasonable construction, the construction cannot be divorced
`
`from the specification and the record evidence.” In re NTP, Inc., 654 F.3d 1279,
`
`1288 (Fed. Cir. 2011).
`
`FatPipe adopts the ordinary meaning of all terms, subject to the constraints
`
`imposed by the specification to inform a POSA “as to precisely which ordinary
`
`definition the patentee was using.” PPC Broadband Inc. v. Corning Optical
`
`Comm’cns. RF LLC, 815 F.3d 747, 752 (Fed. Cir. 2016).
`
`A. “selects between network interfaces on a per-packet basis”/“make
`network path selections on a packet-by-packet basis.”
`
`Claim 4 recites “selects between network interfaces on a per-packet basis”
`
`and claim 9 recites “make network path selections on a packet-by-packet basis.” A
`
`POSA would have understood these terms to mean “for each packet, makes a
`
`discrete choice between network paths/interfaces.” (Ex. 2003 ¶¶ 34–41).
`
`The first part of these claim terms requires a selection process. The ’235
`
`patent’s specification and file history use the term “select” (and all alternative
`
`forms of the word) to mean that a choice is made between two or more
`
`possibilities. (Ex. 1001, col. 4:16–21, col. 6:62–7:5, col. 11:2–10, col. 12:60–61,
`
`col. 14:40–43, col. 14:59–67, col. 15:65–16:4, col. 16:15–27). For example, the
`
`specification states that “[d]uring a path selecting step 908, the path selector 704
`
`selects the path over which the packet will be sent; selection is made between at
`
`least two paths, each of which goes over a different network 106 than the other.”
`
`
`
`9
`
`

`

`
`
`(Ex. 1001, col. 14:40–43, emphasis added). A POSA would understand the plain
`
`and ordinary meaning of the term “select” to be “to choose from a number or
`
`group.” (Ex. 2003 ¶ 35, citing Ex. 2004, p. 1059). Accordingly, a POSA would
`
`understand that the terms “selects between network interfaces” and “make network
`
`path selections” require that a choice is being made between at least two available
`
`network paths/interfaces.
`
`The ’235 patent’s specification and file history use the term “per-packet”
`
`and “packet-by-packet” in accordance with its plain and ordinary meaning. (Ex.
`
`1001, col. 6:67–7:5, col. 9:12–17, col. 14:44–46, col. 16:15–21). A POSA would
`
`understand the plain and ordinary meaning of the term “per” to be “for each.” (Ex.
`
`2003 ¶ 36, citing Ex. 2004, p. 861). Accordingly, a POSA would have understood
`
`that a process occurring on a per-packet or packet-by-packet basis requires the
`
`process to occur for each packet.
`
`Consistent with its use of the term “select” and “per-packet,” the ’235 patent
`
`expressly distinguishes path selection applied on a per-packet basis from path
`
`selection applied to multiple packets:
`
`This path selecting step 908 may be performed once per packet, or a
`given selection may pertain to multiple packets. (Ex. 1001, col. 14:44–
`46).
`
`This passage is important because it distinguishes per-packet path selection from
`
`conventional routing tables which associate a single, preferred path for each
`
`
`
`10
`
`

`

`
`
`destination. With conventional routing, the selection of the preferred path occurs,
`
`for example, when the routing table is updated, and all incoming packets for a
`
`given destination will be routed on the same preferred path until the routing table is
`
`updated again with a new preferred path. Thus, the selection of a path would apply
`
`to multiple packets until the routing table is updated.
`
`The ’235 patent makes a similar distinction between granular and coarse
`
`network selection. The selecting function may divide network traffic at the packet-
`
`by-packet, TCP/UDP session, per-department, or per-router level:
`
`In particular, prior approaches for selecting which network to use for
`which packet(s) are coarse. For instance, all packets from department X
`might be sent over the frame relay connection 106 while all packets from
`department Y are sent over the Internet 500. (Ex. 1001, col. 4:17–21).
`
`Load-balancing is preferably done on a per-packet basis for site-to-site
`data traffic over the Internet or frame relay net, or done on a TCP or UDP
`session basis for Internet traffic, as opposed to prior approaches that use a
`per-department and/or per-router basis for dividing traffic. (Ex. 1001, col.
`7:38–42).
`
`[T]he invention allows load-balancing, redundancy, or other criteria to be
`used dynamically, on a granularity as fine as packet-by-packet, to direct
`packets to an Internet router and/or a frame relay/point-to-point router
`according to the criteria.” (Ex. 1001, col. 9:12–17).
`
`A POSA would understand from these examples of coarse network selection that
`
`an initial selection is made between networks, and subsequent packets are checked
`
`
`
`11
`
`

`

`
`
`against that initial selection to determine which network to route the packets
`
`toward. This initial selection is enforced by the routing table until a routing table
`
`change occurs. Thus, coarse selection does not entail making a discrete choice
`
`between network paths for each incoming packet.
`
`This difference must be taken into account when construing claims under the
`
`BRI because the terms cannot be construed so broadly as to encompass prior art
`
`technologies excluded by the use of those terms in the patent specification. The
`
`Federal Circuit considered such a situation in In re NTP, Inc. and determined that
`
`the inventor’s use of the term “electronic mail” excluded prior art electronic
`
`messages such as pager messages. In re NTP, Inc., 654 F.3d 1279, 1289 (Fed. Cir.
`
`2011). Here, the per-packet path selection should be construed using the same
`
`principles to exclude the routing of packets based on a single selection that applies
`
`to multiple subsequent packets, as in the case of per-department network selection
`
`and per-router network selection.
`
`Even the Petitioner’s own marketing literature is consistent with the ’235
`
`patent’s description of per-packet path selection:
`
`
`
`12
`
`

`

`
`
`
`
`(Ex. 10
`
`
`
`
`
`
`
`
`
`
`10, Appendix I, p. 7)). Petitioneer also acknnowledgess the differeence betweeen
`
`
`
`
`
`
`
`per-sesssion load bbalancing aand per-paccket: “The
`
`
`
`
`
`
`
`
`
`most simpplistic loadd balancingg
`
`
`
`
`
`
`
`assigns individuall sessions tto a path, ooften withoout regard tto link chaaracteristicss
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`and appplication reequirementts. More soophisticatedd ones balaance by thee packet.”
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Ex.
`
`
`
`2008, p. 1). Similaarly, Petitiooner distinnguishes itss own prodduct’s “perr-packet”
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`networkk path selecctions fromm its comp
`
`
`
`
`
`
`
`etitor’s “peer-flow” ddecision maaking
`
`
`
`
`
`
`
`configuuration: “WWe make peer-packet foforwarding
`
`
`
`
`
`decisions,, not simplly per-floww.”
`
`
`
`
`
`
`
`
`
`
`
`(Ex. 2010, p. 1).
`
`
`
`FFurther, witth referencce to Fig. 99, the ’235
`
`
`
`
`
`
`
`
`
`
`
`
`
`patent furtther elaborrates on thee
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`distinctiion betweeen selectingg on a per--packet bassis and seleecting on aa multiple-
`
`- h
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`packet bbasis. The packet seleection proccess in Figg. 9 can (1)) be repeateed for each
`
`
`
`packet ((Ex. 1001, col. 16:155–21) or (2
`
`
`
`
`
`
`
`) occur jusst once for
`
`
`
`each receiive-send paair
`
`
`
`
`
`of addreesses such that each ffollowing ppacket withh the samee receive-s
`
`
`
`
`
`
`
`
`
`
`
`
`
`end pair off
`
`
`
`addresses is routedd accordinng to the prreviously s
`
`
`
`
`
`
`
`
`
`elected nettwork pathh (Ex. 10011,
`
`
`
`
`
`
`
`13
`
`

`

`col. 16:21–32). The difference between per-packet selection and standard routing
`
`based on pre-selected network path is shown in the annotations to Fig. 9 below.
`
`
`
`
`
`Per-packet Network Selection
`Repeats The Selection Loop
`For Each Packet
`
`
`Alternatively, The Selection
`Loop Occurs Once And Then
`Each Packet Is Simply Routed
`
`
`(Ex. 1001, Fig. 9). This description informs a POSA that selections on a per-packet
`
`or packet-by-packet basis require the selection process to occur for each packet
`
`that enters the controller and are not applied to multiple packets. (Ex. 2003 ¶ 40).
`
`
`
`14
`
`

`

`
`
`Accordingly, a POSA would have understood the terms “selects between
`
`network interfaces on a per-packet basis” and “make network path selections on a
`
`packet-by-packet basis” to mean “for each packet, makes a discrete choice between
`
`network paths/interfaces.” (Ex. 2003 ¶ 41).
`
`B. “dynamic load-balancing”
`
`Challenged claims 11–13 recite the term “dynamic load-balancing.” In the
`
`context of the ’235 patent’s specification, a POSA would have understood the term
`
`“dynamic load-balancing” to mean “distributing packets based on actual traffic
`
`assessed after the packet arrives.” (Ex. 2003 ¶¶ 42–48).
`
`The ’235 patent’s specification explicitly and repeatedly describes dynamic
`
`load balancing as balancing loads in response to actual traffic. For example, the
`
`’235 specification distinguishes load-balancing between routers that are associated
`
`with different departments within the enterprise from load-balancing dynamically
`
`to account for actual traffic:
`
`For instance, a local area network (LAN) at site 1 may be set up to send
`all traffic from the accounting and sales departments to router A1 and
`send all traffic from the engineering department to router B1. This may
`provide a very rough balance of the traffic load between the routers, but it
`does not attempt to balance router loads dynamically in response to
`actual traffic and thus is not “load-balancing” as that term is used herein.
`(Ex. 1001, col. 2:61–65, emphasis added).
`
`
`
`15
`
`

`

`
`
`The phrase “as that term is used herein” in this passage informs a POSA that the
`
`’235 specification imposes constraints on the meaning of the term “load-
`
`balancing,” relative to the way that term was used conventionally to describe
`
`balancing traffic loads between routers. In particular, dynamic load-balancing in
`
`the context of the patented invention requires that load-balancing is performed on
`
`the basis of the actual traffic observed at the time of balancing on the available
`
`lines.
`
`Thus, a POSA would understand from the above-quoted passage that
`
`dynamic load-balancing is limited to “balanc[ing] router loads dynamically in
`
`response to actual traffic.” A POSA would also understand that “actual traffic” is
`
`the traffic existing at or shortly after the time of the packet’s arrival, as opposed to
`
`traffic conditions that existed sometime in the past. (Ex. 2003 ¶ 44, citing Ex.
`
`2004, p. 12).
`
`The ’235 patent further describes dynamic load-balancing as being based on
`
`the actual traffic after the packet arrives at the controller:
`
`[I]n some cases the path for the next packet may be determined by the
`packet path selector before the packet arrives, e.g., in a round-robin
`manner, while in other cases the path is determined after the packet
`arrives, e.g., using per-packet dynamic load balancing. (Ex. 1001, col.
`14:53–58).
`
`
`
`16
`
`

`

`
`This pa
`
`
`
`ssage distinguishes (A) pre-seleection of ppacket pathhs prior to tthe arrival
`
`
`
`
`
`
`
`
`
`
`
`of
`
`
`packets
`
`
`
`
`
`
`
`at the conntroller fromm (B) dynaamic selecttion of paccket paths,
`
`
`
`
`
`
`
`
`
`arrival oof each paccket, basedd on actual
`
`
`
`traffic connditions.
`
`after the
`
`
`
`paths becaause
`
`
`
`TThe round-rrobin approach, for eexample, prre-selects tthe packet
`
`
`
`
`
`
`
`
`
`
`
`
`
`each inccoming paccket is alreeady destinned for a paarticular linne, for exaample, a
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`packet tto line 1, nnext packett to line 2, nnext packeet to line 3,, next packket to line 11
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`and so-oon. This prre-selectionn approachh is similarr to a conveentional roouting tablee
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`that mapps each destination aaddress to aa particularr path, insoofar as all iincoming
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`packets for a partiicular destiination adddress are foorwarded oon the pre-
`
`
`
`
`
`selected beest
`
`
`
`
`
`
`
`
`
`
`
`path unttil the routting table iss updated. (Ex. 2003
`
`
`
`
`
`
`
` ¶ 46).
`
`
`
`
`
`
`
`
`
`OOn the otheer hand, dyynamic loadd balancingg selects a
`
`
`
`path for e
`
`
`
`ach packett
`
`
`
`after arrrival of thee packet baased on thee actual traaffic condittions on eaach availabble
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`line. Thhis advantaageously diistributes ppackets oveer multiplee lines intellligently,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`based on the actuaal traffic, innstead of uusing a pre
`
`
`
`
`
`
`
`
`
`determinedd best pathh stored in
`
`
`
`a
`
`routing
`
`
`
`
`table or a rround-robiin distributtion algoritthm. Petitiioner’s ownn marketinng
`
`
`
`
`
`
`
`
`
`
`
`
`
`literaturre acknowlledges the distinctionn between ppredetermiined policiies and actuual
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`networkk performaance (Ex. 22008, p. 1)::
`
`
`
`
`
`
`
`
`
`
`
`17
`
`

`

`
`
`Similarly, Petitioner emphasizes the importance of basing the decision on actual
`
`network conditions: “Talari measure the loss, latency, jitter, availability and
`
`congestion of every path in the WAN with every packet that traverses the WAN.
`
`This creates an extremely detailed repository of network information based on
`
`ACTUAL application data – not probe data, not occasional test data and not round
`
`trip ping times.” (Ex. 2009, p. 1). These descriptions from Petitioner further
`
`demonstrate that a POSA, reading the ’235 patent, would have understood the
`
`significance and advantages of making load-balancing decisions based on actual
`
`network traffic instead of based on traffic information that is updated only
`
`occasionally.
`
`Accordingly, the ’235 patent distinguishes dynamic load balancing from
`
`other methods of load balancing where the controller pre-selects the packet’s path
`
`before it arrives at the controller, such as in a round-robin manner. Therefore, a
`
`POSA would have understood the term “dynamic load-balancing” to mean
`
`“distributing packets based on actual traffic assessed after the packet arrives.” (Ex.
`
`2003 ¶ 48).
`
`V. Overview of Karol
`Karol is directed “to the internetworking of connectionless (e.g. Internet
`
`Protocol or “IP”) and connection oriented (e.g. ATM, MPLS, RSVP) networks
`
`….” (Ex. 1006, Abstract). Karol’s system uses “nodes called CL-CO gateways,
`
`
`
`18
`
`

`

`
`
`[which] are arranged to have connectivity to both the CL network and the CO
`
`network.” (Ex. 1006, col. 2:13–15). Karol’s CL-CO gateway uses standard routing
`
`techniques in making network path decisions. (Ex. 1006, col. 13:43–15:30). Karol
`
`touts its invention as a method for handling CO-network bound packets that arrive
`
`at the CL-CO gateway while a CO network connection is being established. (Ex.
`
`1006, col. 2:13–62, col. 4:12–15).
`
`In Karol’s shortest path system, a packet only ends up at a CL-CO gateway
`
`if it happens to be along the shortest path to the destination—the endpoints do not
`
`control which packets reach the gateway. For example, a packet from a source
`
`endpoint “(such as a personal computer, workstation, or other processor attached to
`
`any information source)” is directed to a CL network. (Ex. 1006, col. 4:36–40).
`
`The packet is then routed through the CL network using the standard IP routing
`
`mechanism, which may be controlled by the well-known Open Shortest Path First
`
`(OSPF) routing protocol. (Ex. 1006, col. 4:45–67, col. 13:43–15:30). The packet’s
`
`route to the destination will result in the packet arriving at one of the CL-CO
`
`gateways only if it is part of the shortest path according to the other IP routers’
`
`routing tables: “Packets only appear at a CL-CO gateway if it is part of the shortest
`
`path according to the IP routing tables.” (Ex. 1006, col. 14:52–54, see also col.
`
`4:45–67, col. 14:36–43, col. 13:43–15:30).
`
`
`
`19
`
`

`

`
`
`Once at the CL-CO gateway, the gateway consults the forwarding
`
`database—which is a routing table—to find the packet’s predetermined “shortest”
`
`path to the destination. (Ex. 1006, col. 13:43–15:30). Determination of the shortest
`
`path is the first step (step 503) in Karol’s packet handling process:
`
`
`
`(Ex. 1006, Fig. 5, cropped). If the shortest path is over the CL network, the result
`
`of step 503 is “NO.” If the shortest path is over the CO network, the result of step
`
`503 is “YES.”
`
`Karol describes two techniques for creating the forwarding database, which
`
`is an OSPF-based routing table: (1) representing the CO network as a “non-
`
`broadcast network” (a well-known technique used in OSPF) or (2) not
`
`broadcasting the CO network and creating an integrated routing table. (Ex. 1006,
`
`col. 13:43–50). Using the first method, Karol explains that the CO network path is
`
`only chosen if it is the shortest:
`
`Routing tables constructed in the IP routers 911–917 (including the
`CL-CO gateways 960–962) take into account the presence of the non-
`
`
`
`20
`
`

`

`
`
`broadcast network, and enable traffic to flow from CL network 901 to
`CO network 950 and back to the CL network if paths through the CO
`network are “shorter” according to some measure of interest. (Ex.
`1006, col. 14:12–17).
`
`Likewise, using the second method, Karol explains that CO network path is only
`
`chosen if it is the shortest:
`
`Each CL-CO gateway 960–962 determines shortest paths to IP
`destinations by comparing its path on the two networks for each
`destination. The shorter of the two paths is maintained at the CL-CO
`gateway in an integrated IP-CO routing table for each destination
`address. (Ex. 1006, col. 14:57–62).
`
`When a packet arrives at the CL-CO gateway, the predetermined routes in the
`
`forwarding database will dictate the network path for the packet.
`
`Karol’s forwarding database can also include user-specific information.
`
`Karol states that user-specific routing information can be integrated into the
`
`forwarding database to advantageously allow the user to request and receive a
`
`guaranteed quality of service. (Ex. 1006, col. 13:50–54, col. 17:20–22). Implicitly,
`
`the CL network cannot provide such benefits, which is why Karol seeks to take
`
`advantage of the CO network whenever possible. (Ex. 2003 ¶ 59).
`
`Karol’s forwarding database can be updated “from time to time” using
`
`standard Link State Advertisements (LSAs). Karol further explains that the link
`
`weights used to construc