Trials@uspto.gov
`571.272.7822
`
`
`Paper No. 32
`Filed: November 1, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`TALARI NETWORKS, INC.,
`Petitioner,
`
`v.
`
`FATPIPE NETWORKS INDIA LIMITED,
`Patent Owner.
`____________
`
`Case IPR2016-00976
`Patent 6,775,235 B2
`____________
`
`
`
`Before STACEY G. WHITE, MICHELLE N. WORMMEESTER, and
`CHRISTA P. ZADO, Administrative Patent Judges.
`
`WHITE, Administrative Patent Judge.
`
`
`
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`571.272.7822
`
`
`Paper No. 32
`Filed: November 1, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_______________
`
`TALARI NETWORKS, INC.,
`Petitioner,
`
`v.
`
`FATPIPE NETWORKS INDIA LIMITED,
`Patent Owner.
`____________
`
`Case IPR2016-00976
`Patent 6,775,235 B2
`____________
`
`
`
`Before STACEY G. WHITE, MICHELLE N. WORMMEESTER, and
`CHRISTA P. ZADO, Administrative Patent Judges.
`
`WHITE, Administrative Patent Judge.
`
`
`
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`I. INTRODUCTION
`
`A. Background
`Talari Networks, Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”)
`seeking to institute an inter partes review of claims 4, 5, 7–15, and 19 of
`U.S. Patent No. 6,775,235 B2 (Ex. 1001, “the ’235 patent”) pursuant to
`35 U.S.C. §§ 311–319. FatPipe Networks India Limited. (“Patent Owner”)
`filed a Preliminary Response. Paper 6 (“Prelim. Resp.”). Based on our
`review of these submissions, we instituted inter partes review of claims 4, 5,
`7–15, and 19 on the following specific grounds:
`Reference(s)
`Basis Claims Challenged
`Karol1
`§ 102 4, 5, 7–11, 14, and 19
`Karol
`§ 103 4, 5, 7–15, and 19
`Karol and Stallings2
`§ 103 5, 11–15, and 19
`
`
`Paper 7 (“Dec.”), 22. Patent Owner filed a Patent Owner’s Response (Paper
`22, “PO Resp.”), and Petitioner filed a Reply (Paper 26, “Reply”). An oral
`hearing was held on August 14, 2017. Paper 31 (“Tr.”).
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`Decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons discussed below, Petitioner has demonstrated by a
`preponderance of the evidence that claims 4, 5, and 7–15 of the ’235 patent
`are unpatentable. Petitioner has not meet its burden to establish the
`unpatentability of claim 19.
`
`
`1 U.S. Patent No. 6,628,617 B1 (“Karol,” Ex. 1006).
`2 William Stallings, Data and Computer Communications, Prentice-Hall, 5th
`Ed, 1997, ISBN-81-203-1240-6 (“Stallings,” Ex. 1011).
`
`2
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`B. Related Proceedings
`The parties inform us that FatPipe, Inc. v. Talari Networks, Inc., No.
`5:16-CV-54-BO (E.D.N.C.) and FatPipe, Inc. v. Viptela, Inc., No. DED-1-
`16-cv-00182 (D. Del.), may be impacted by this proceeding. Pet. 1; Paper
`30, 2–3. In addition, Petitioner has a pending petition for inter partes review
`of a related patent, U.S. Patent No. 7,406,048 B2 (“the ’048 patent”)
`(IPR2016-00977). Pet. 2. Viptela, Inc. and Cisco Systems, Inc. also have
`filed petitions seeking inter partes review of various claims of the ’235 and
`’048 patents. Paper 30, 3.
`
`C. The ʼ235 Patent
`The ’235 patent describes a system and method for communicating
`using two or more disparate networks in parallel. Ex. 1001, Abstract. For
`example, an embodiment of this system could be composed of a virtual
`private network (“VPN”) in parallel with a frame relay network. Id. at 1:19–
`24. These parallel networks back each other up in case of failure and when
`both networks are operational their loads are balanced between the parallel
`networks. Id. at Abstract. An embodiment of this system is depicted in
`Figure 10, which is shown below.
`
`3
`
`
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`Figure 10 depicts an example of the network topology described in the ’235
`patent. Id. at 8:29–30. Two sites 102 transmit and/or receive data from one
`another. Id. at 2:38–40. These sites are connected by two disparate
`networks, Internet 500 and frame relay network 106. Id. at 8:30–32. Each
`location has frame relay router 105 and Internet router 104. Id. at 8:32–33.
`“Access to the disparate networks at site A and site B is through an inventive
`controller 602 at each site.” Id. at 6:34–36. Controller 602 “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 frame relay/point-to-point router according to the criteria.” Id. at
`9:12–17.
`
`Figure 7 of the ’235 patent is reproduced below.
`
`
`Figure 7 depicts controller 602. Id. at 10:59–60. Controller 602 is
`connected to site 102 via site interface 702. Id. at 10:60–63. Packet path
`selector 704 is hardware or software that determines which path a given
`packet is to travel. Id. at 11:2–6. The criteria used to determine which path
`a packet travels may be based on concerns such as redundancy,
`
`4
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`load-balancing, or security. Id. at 11:9–63. Controller 602 also has two or
`more network interfaces 706 (at least one per each network for which
`controller 602 controls access). Id. at 11:64–67.
`
`D. Illustrative Claim
`As noted above, we instituted review of claims 4, 5, 7–15, and 19 of
`the ʼ235 patent, of which claims 4, 5, and 19 are independent. Claim 5 is
`illustrative of the challenged claims and is reproduced below:
`5. A method for combining connections for access to multiple
`parallel disparate networks, the method comprising the
`steps of:
`obtaining at least two known location address ranges which
`have associated networks;
`obtaining topology information which specifies associated
`networks that provide, when working, connectivity
`between a current location and at least one destination
`location;
`receiving at the current location a packet which identifies a
`particular destination location by specifying a destination
`address for the destination location;
`determining whether the destination address lies within a
`known location address range;
`selecting a network path from among paths to disparate
`associated networks, said networks being in parallel at
`the current location, each of said networks specified in
`the topology information as capable of providing
`connectivity between the current location and the
`destination location;
`forwarding the packet on the selected network path.
`
`
`II. CLAIM CONSTRUCTION
`In an inter partes review, “[a] claim in an unexpired patent shall be
`given its broadest reasonable construction in light of the specification of the
`patent in which it appears.” 37 C.F.R. § 42.100(b). Under this standard, we
`
`5
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`construe claim terms using “the broadest reasonable meaning of the words in
`their ordinary usage as they would be understood by one of ordinary skill in
`the art, taking into account whatever enlightenment by way of definitions or
`otherwise that may be afforded by the written description contained in the
`applicant’s specification.” In re Morris, 127 F.3d 1048, 1054 (Fed. Cir.
`1997).
`
`A. “selects between network interfaces on a per-packet basis” (claim 4)
`/“make network path selections on a packet-by-packet basis” (claim 9)
`Patent Owner contends that one of ordinary skill in the art would have
`understood these phrases to mean “for each packet, make[] a discrete choice
`between network paths/interfaces.” PO Resp. 9 (citing Ex. 2003 ¶¶ 34–41).
`Petitioner asserts that if we determine that these phrases need construction
`the proper construction is “for each packet a network interface/path is
`chosen.” Reply 6. The parties dispute whether path selections must occur
`once for each individual packet or whether such selection may be made for a
`group of packets. PO Resp. 10; Reply 2–3.
`First, Patent Owner asks that we construe the select/selections terms
`to mean making a discrete choice between two or more possibilities. PO
`Resp. 9. Petitioner asserts that there is no basis for Patent Owner’s proposed
`“discrete choice” language. Reply 4. We are not persuaded that, for the
`purposes of this Decision, there is meaningful information to be gleaned by
`construing the words select/selections to mean “make a choice.” We also
`are not persuaded that there is a basis for inserting the word “discrete” into
`this construction. Therefore, based on the disputes before us, we see no
`reason to provide an express construction for the common terms
`select/selections.
`
`6
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`Patent Owner contends that the terms “per” and “packet-by-packet”
`would have been understood to require a selection for each packet. PO
`Resp. 10. Thus, Patent Owner asserts that there must be a path selection
`process performed for each individual packet. Id. Petitioner argues that this
`is too narrow of a view of the claim terms and asserts that the specification
`describes making a single selection that applies to each packet in a group.
`Reply. 2–3.
`In support of their arguments both parties direct us to Figure 9 and its
`supporting text. Figure 9 is reproduced below.
`
`
`Figure 9 “is a flowchart illustrating methods of the present invention for
`combining connections to send traffic over multiple parallel independent
`disparate networks.” Ex. 1001, 5:48–50. The parties direct us to the
`discussion of step 908, which 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
`
`7
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`network 106 than the other. The disparate networks are
`independent parallel networks. This path selecting step 908
`may be performed once per packet, or a given selection may
`pertain to multiple packets.
`Id. at 14:40–46.
`As described in the specification, Figure 9 depicts “methods” for
`selecting paths. See id. 5:48–50. These methods allow for the selection to
`“be performed once per packet, or a given selection may pertain to multiple
`packets.” Id. at 14:40–46 (emphasis added). Thus, we find that the
`specification discloses both selection for each individual packet and
`selection for a group of packets.
`Next, we examine the claims to see whether claims 4 and 9 cover both
`of the embodiments or whether they are directed only to the embodiment
`wherein the selection occurs for each individual packet. Independent claim
`4 recites, in relevant part, “a packet path selector which selects between
`network interfaces on a per-packet basis.” This stands in contrast to claim 5,
`which recites, in relevant part, “selecting a network path from among paths
`to disparate associated networks.” While independent claim 5 refers to
`“receiving at the current location a packet,” its selection step does not make
`reference to this “packet,” but rather it recites the selection of a network path
`without requiring this selection to be made “per-packet.” We are persuaded
`that this difference is significant in that it evidences that the Patentee
`intended claim 4 to have a more narrow scope than claim 5.
`This distinction is supported by the language of claim 5’s dependent
`claims. Claim 9 depends from claim 5 and further recites “wherein repeated
`instances of the selecting step make network path selections on a packet-by-
`packet basis.” Also, claim 10 depends from claim 5 and further recites
`
`8
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`“wherein repeated instances of the selecting step make network path
`selections on a per session basis.” Thus, claim 9 narrows the breadth of
`claim 5’s selection step by requiring it to occur “on a packet-by-packet
`basis” and claim 10 narrows the breadth of claim 5 by requiring selection to
`occur on a “per session basis.” Therefore, claim 5 is broad enough to
`encompass selection for more than one packet at a time (a session) and
`selection for an individual packet.
`Petitioner argued that claim 4 must be broad enough to encompass the
`embodiment in which selections were performed for multiple packets
`because it would be improper to construe claim 4 in a manner that would
`exclude that embodiment. Reply 2. We do not agree. The Patentee
`described multiple embodiments in the specification and as such, the
`Patentee was free to determine which embodiments would be encompassed
`by which claims. Here, we are presented with evidence that the Patentee
`drafted claim 5 to cover both embodiments and drafted dependent claims to
`focus on the individual embodiments. Such a drafting choice is within the
`purview of the Patentee and we see no reason why we must construe claim 4
`in a manner that would encompass all embodiments. The Patentee’s choice
`to describe the selection as occurring on a “per packet basis” when viewed in
`light of the specification and the other claims indicates a decision to direct
`claim 4 to the embodiment in which routes are selected for each packet. As
`such, we find that the language of claims 4 and 9 indicates that these claims
`are directed to the embodiment wherein path selection is performed for each
`individual packet. Therefore, we construe the disputed phrases to mean
`“selecting a network path/interface for each packet.”
`
`9
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`B. “dynamic load-balancing” (claims 11–13)
`Patent Owner asserts that the term “dynamic load-balancing” would
`have been understood by a person of ordinary skill in the art to mean
`“distributing packets based on actual traffic assessed after the packet
`arrives.” PO Resp. 15 (citing Ex. 2003 ¶¶ 42–48). Petitioner responds by
`arguing that Patent Owner’s proposed construction is overly narrow and that
`if we determine that a construction is necessary a proper construction would
`be “sending packets in distributions that balance the load of a given network,
`router, or connection relative to other networks, routers, or connections
`available to the controller without manual intervention.” Reply 7 (citing Ex.
`1001, 9:30–33, 11:21–24, 11:33–38).
`Patent Owner directs us to a passage in the specification that it
`contends supports its position that the load is balanced in response to actual
`traffic. PO Resp. 15
`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.
`Id. (quoting Ex. 1001, 2:61–65). Patent Owner’s declarant, Joel Williams,
`explains that
`[t]he phrase “as that term is used herein” in this passage
`informs a [person of ordinary skill in the art] 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
`
`10
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`on the basis of the actual traffic observed at the time of
`balancing on the available lines.
`Ex. 2003 ¶ 43.
`Patent Owner asserts that actual traffic is determined at some point in
`time after the packet arrives. PO Resp. 16. In support of this assertion,
`Patent Owner directs us to the specification’s disclosure that “in 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.” Id. (quoting Ex. 1001, col. 14:53–58) (emphases
`added).
`Petitioner disputes this construction and argues that Patent Owner’s
`view of the claim language is “a blatant, improper attempt to read additional
`limitations into the claims.” Reply 7. According to Petitioner, the cited
`“passage only highlights the difference between the prior art (manual
`switchover) and the alleged invention (no manual intervention). It is
`unrelated to balancing traffic based on traffic loads that existed at the time of
`a packet’s arrival or at some undefined period thereafter.” Id. at 8. Thus,
`Petitioner argues that “[t]he specification uses ‘dynamic load-balancing’ to
`mean that no manual switchover is required.” Id.
`We are not convinced by Petitioner’s arguments. The cited portion of
`the specification discusses a configuration in which a LAN “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.” Ex. 1001,
`2:55–61. Petitioner argues that the key point here is that this prior art
`configuration required a manual switchover. Reply 8. There, however, is no
`reason for us to conclude that dynamic load balancing should be equated
`
`11
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`with either a manual or an automated environment. The cited passage
`distinguished routing by departments from dynamic load balancing by
`stating that the department-based routing is not dynamic because in dynamic
`load balancing the “router loads dynamically in response to actual traffic.”
`Id. at 2:63–64. We find that the cited passages show that the contemplated
`load balancing is performed based on actual traffic, but are insufficient to
`establish that the Patentee intended load balancing to be equated with a
`manual selection process. See Id. at 2:61–65, 7:31–32.
`Further, we are not convinced by Patent Owner’s arguments regarding
`the alleged requirement that traffic be assessed at some point after the
`packet’s arrival. The portion of the specification cited in support of this
`assertion refers to multiple scenarios or “cases.” See PO Resp. 16 (citing
`Ex. 1001, 14:53–58). The specification states that in one of those cases the
`path may be determined after the packet arrives and states that, for example,
`the path determination may be done using dynamic load balancing. See
`Ex. 1001, 14:53–58. This passage does not provide any specific temporal
`limitation to the term “dynamic load balancing,” but rather it illustrates an
`example of when load balancing could be used. It is improper to limit the
`claims to this one exemplary embodiment without more express language in
`the claims or the specification that would narrow the scope of this term.
`Thus, we find that the proper construction of dynamic load balancing is
`“distributing packets based on actual traffic.”
`
`III. ANALYSIS
`
`Petitioner bears the burden of proving unpatentability of the
`challenged claims, and the burden of persuasion never shifts to Patent
`Owner. Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375,
`
`12
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`1378 (Fed. Cir. 2015). To prevail, Petitioner must establish the facts
`supporting its challenge by a preponderance of the evidence. 35 U.S.C.
`§ 316(e); 37 C.F.R. § 42.1(d). Thus, we examine the full record in this
`matter to determine whether Petitioner has met its burden under 35 U.S.C.
`§ 316(e).
`
`A. Asserted Ground of Unpatentability over Karol
`Petitioner asserts that claims 4, 5, 7–11, 14, and 19 are anticipated by
`the disclosures of Karol. Pet. 10–30. Petitioner also contends that claims 4,
`5, 7–15, and 19 would have been obvious over the teachings of Karol. Id. at
`42–60. Petitioner supports its arguments with a declaration from Dr. Kevin
`Negus. Ex. 1005.
`1. 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, 1:7–10. Connectionless (“CL”) networks
`require no explicit connection setup prior to transmitting datagrams. Id. at
`1:19–24. In contrast, connection oriented (“CO”) networks determine a
`route for the connection and allocate bandwidth resources along the route.
`Id. at 1:31–39. Figure 1 of Karol is reproduced below.
`
`13
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`
`Figure 1 depicts CO and CL networks in a parallel configuration. Id. at
`4:12–14. Datagrams ultimately destined for endpoint 151 may be sent from
`source 101 to node 111 in CL network 110. Id. at 4:39–40. The source or
`destination may be connected directly to CL-CO gateway 140 or they may
`be connected through a node in the network. Id. at 5:5–8. The datagrams
`may be routed over either the CO or CL network in order to arrive at
`endpoint 151. Id. at 4:40–43. CL-CO gateways 140 and 150 interconnect
`the CL and CO networks and “allow[] datagrams (sometimes hereinafter
`called messages) originated on the CL network to be transported . . . on the
`CO network.” Id. at 3:30–37. “When a datagram arrives at CL-CO gateway
`140 of FIG. 1, a determination is made if that packet should be carried by
`CO network 160.” Id. at 5:23–25. CL-CO gateway 140 is described in more
`detail in Figure 4, which is reproduced below.
`
`14
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`
`
`Figure 4 illustrates the internal arrangements of CL-CO gateway 140. Id. at
`6:31–32.
`Generally speaking, each CL-CO gateway arranged in
`accordance with the present invention includes hardware and
`software modules that typically comprise (a) a switch fabric for
`CO networking, shown in FIG. 4 as CO switch 410, (b) a CL
`packet forwarding engine, shown in FIG. 4 as CL router/switch
`420, (c) a protocol converter 450, (d) a moderately sized
`packet buffer 440 for temporarily storing packets waiting for
`CO network setup or turnaround; and (e) a processor 430 and
`associated database 431 for controlling the gateway packet
`handling operations and for storing forwarding, flow control,
`header translation and other information. Input line cards 401
`and output line cards 402 connect the gateway of FIG. 4 to
`external networks, such that datagrams received in input line
`cards 401 can be directed either to CO switch 410 or CL
`router/switch 420, and such that output line cards 402 can
`receive datagrams from either of the last mentioned elements
`and direct them to external networks.
`
`Id. at 6:32–50. The elements depicted in Figure 4 are controlled by
`processor 430 and such control is implemented via programs stored in the
`processor. Id. at 6:55–59. The routing procedures used by gateway 140
`may adjust routing dynamically “to divert connections away from
`
`15
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`overloaded call processors.” Id. at 17:64–67. In other words, routing “can
`be adjusted to reflect bandwidth availability.” Id. at 18:1–2.
`2. Independent Claim 4
`Claim 4 recites a controller, which controls access to multiple
`networks. Petitioner’s arguments as to independent claim 4 may be
`summarized as follows: Petitioner argues in the alternative that the claimed
`controller that provides access to multiple networks may be either Karol’s
`CL-CO gateway alone or the gateway in combination with one or more
`routers or switches. Pet. 10–12. If the controller is the gateway alone, then
`Petitioner asserts that the site interface is disclosed by one or more of
`Karol’s input line cards 401 or the network connection depicted in Figure 1
`between source 101 and node 111. Id. at 12. If the controller is the gateway
`in combination with routers and/or switches, then Petitioner asserts the site
`interface is a network connection. Id. According to Petitioner, Karol
`discloses at least two output line cards 402 that receive datagrams from the
`CO switch or CL router/switch and directs the datagrams to external
`networks. Id. at 12–13. In addition, we note that Karol discloses that “the
`source or destination may be directly connected to a CL-CO gateway (e.g.,
`gateway 140) as opposed to being connected through a CL node.” Ex. 1006,
`5:5–8. As to the packet path selector, Petitioner points to Karol’s gateway
`processor, CL router/switch, CO switch, packet buffer, protocol converter
`and input line cards to disclose this element of the claim. Pet. 14. Petitioner
`asserts that these items work together in Karol to determine if a packet
`(“datagram”) from a source should be forwarded to either the CL or CO
`network. Id. Petitioner relies on Karol’s disclosure of routing datagrams
`based on “‘bandwidth availability’ that can be ‘dynamically allocated to
`
`16
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`flows on an as-needed basis’ and can ‘divert[] connections away from
`congested links.” Id. at 15 (citing Ex. 1006, 17:18–26, 17:63–18:2;
`Ex. 1005 ¶ 182).
`Patent Owner argues that Karol does not disclose “a packet path
`selector which selects between network interfaces on a per-packet basis.”
`PO Resp. 23. Patent Owner supports its contentions with declarations from
`Joel Williams. Exs. 2001, 2003.
`Specifically, Patent Owner contends that Karol does not disclose the
`selection of paths on a per packet basis as required by claim 4. PO Resp.
`23–28. This argument is based on Patent Owner’s contentions that (1) Karol
`does not select a network when a packet arrives, but rather it routes packets
`based on precomputed routes; and (2) Karol’s path selection occurs
`infrequently and not on a per-packet basis. Id.
`Petitioner asserts that Karol’s system “selects between network
`interfaces on a per-packet basis” (e.g., packet path selector compares
`information in each packet received at the CL-CO gateway to determine if
`the packet will be routed to the CL or CO network interface output line
`card). Pet. 15–16. Petitioner’s declarant, Dr. Kevin Negus, testifies that this
`path selection occurs by examining the packet’s destination, the optional
`presence of alternative paths to that destination, and at least one specified
`criteria for selecting between alternative paths. Ex. 1005 ¶ 187.
`Karol states that “[w]hen a datagram arrives at a CL-CO gateway 140
`of FIG. 1, a determination is made if that packet should be carried by the CO
`network 160.” Ex. 1006, 5:23–25. Patent Owner, however, asserts that this
`determination is not an individualized selection of a route for a specific
`packet, but rather it is a determination as to whether a packet is part of a
`
`17
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`group of packets (a flow) for which a routing decision previously has been
`made. PO Resp. 24. Figure 5 of Karol is reproduced below.
`
`
`Figure 5 of Karol depicts the packet forwarding process. Ex. 1006, 3:6–8.
`In step 501, a packet arrives at Karol’s CL router/switch 420. Id. at 8:56–58.
`Step 503, then inquires as to whether the received packet is “a packet from a
`flow that needs CO Service.” Id. at Fig. 5, element 503 (emphasis added).
`Thus, we determine that Karol’s routing decisions are made for a flow of
`packets and not for an individual packet.
`As discussed above, we construe claim 4’s “per packet basis” to
`require “selecting a network path/interface for each packet.” See supra
`§ II.A. Thus, we find that Karol does not disclose the per packet selection
`
`18
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`required in claim 4. Therefore, we determine that Petitioner has not met its
`burden to establish that claim 4 is anticipated by Karol.
`Petitioner, however, also argues that claim 4 would have been obvious
`over Karol. Petitioner expands upon its anticipation arguments with
`arguments in which it explains why Karol combined with the knowledge of
`one of ordinary skill in the art would have rendered claim 4 obvious. Pet.
`42–60.
`Petitioner argues that if we construe “per-packet basis” to require
`selection for each packet then Karol would have rendered this limitation
`obvious. Pet. 45. Petitioner asserts that this limitation would have been
`obvious because (1) modifying Karol to select networks on a per-packet
`basis would have amounted to nothing more than the simple substitution of
`one known element for another to obtain predictable results (id. at 45); and
`(2) the combination of Karol and the knowledge of one of ordinary skill in
`the art would have been obvious to try (id. at 46).
`Petitioner contends that the ’235 patent describes the “prior art [as]
`disclos[ing] routing decisions that are independent of the particular flows or
`sessions of particular packets.” Id. at 45 (citing Ex. 1001, 4:15–23; Ex. 1005
`¶ 192). Petitioner relies upon a passage from the ’235 patent, which
`describes a “prior approach[] for selecting which network to use for which
`packet(s)” in which decisions are made based on the origin of the packet.”
`Ex. 1001, 4:15–23. In contrast, Karol describes a selection process in which
`the gateway makes a determination as to which network should receive the
`packet based on its examination of the fields of Karol’s flow database, which
`includes “source address” as one of its fields. Id. at 46. Petitioner asserts
`that it would have been obvious to modify Karol by limiting the routing
`
`19
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`decision to an analysis of the packet’s source address. Id. In support of this
`position, Dr. Negus testifies that such a modification would entail “a much
`simpler and known packet path selection process.” Ex. 1005 ¶ 193.
`Patent Owner asserts that Karol’s gateway uses OSPF (Open Shortest
`Path First) to determine routing prior to a packet being received at the
`gateway. PO Resp. 26. Patent Owner further contends that “[t]he OSPF
`routing protocol expressly excludes the possibility of making packet routing
`decisions on a per-packet basis.” Id. at 27. We find this to be an overly
`narrow view of Karol’s disclosures because Karol is not limited to OSPF.
`See Ex. 1006, 14:20–22 (“the description below assumes the OSPF routing
`protocol, the concept is readily applicable to other IP routing protocols”).
`We determine that Petitioner has shown that it would have been
`obvious to modify Karol to select networks on a per packet basis. Petitioner
`has proposed a modification to Karol that is “much simpler” and therefore,
`we find that one of ordinary skill in the art would have been motivated to
`make this modification in order to reduce system complexity. Petitioner has
`provided arguments and evidence sufficient to show that this modification
`would be within the abilities of one of ordinary skill in the art and that there
`would have been a reasonable expectation of success. Thus, we find that
`Petitioner has set forth sufficient evidence to demonstrate that it would have
`been obvious to modify Karol in a manner that would have taught this
`limitation.
`Patent Owner also argues that Petitioner has not shown that claim 4’s
`“site interface” would have been taught by Karol. PO Resp. 28. Petitioner
`asserts that a “‘site’ in Karol could be either the routers/switches connected
`to the CL-CO gateway and/or the source 101 and/or destination 151
`
`20
`
`
`
`IPR2016-00976
`Patent 6,775,235 B2
`
`endpoints, if the CL-CO gateway alone is the ‘controller,’ and the ‘site
`interface’ would be one or more of the input line cards 401 or a network
`connection.” Pet. 44 (citing Ex. 1005 ¶ 175). Patent Owner contends that
`Karol does not teach the recited “site interface” because Karol’s gateway
`(controller) only has “network interfaces” and does not have a “site
`interface.” PO Resp. 28. According to Patent Owner, “[t]he ‘site interface’
`and the ‘network interfaces’ are separately claimed components that
`specifically connect the controller to a site and two or more networks,
`respectively.” Id. at 30. Patent Owner acknowledges that Karol’s Figure 1
`shows an interface between source 101 and node 111. Id. at 32. Patent
`Owner, however, contends that this is not the site interface because the
`controller must be a single device (CL-CO gateway) and thus, the interface
`between source 101 and node 111 is not part of the controller as required by
`claim 4. Id. at 33.
`Petitioner points out that claim 4 recites a controller “comprising” a
`site interface, at least two network interfaces, and a packet path selector.
`Petitioner contends, and we agree, that the use of the open-ended term
`“comprising” shows that the controller can include other elements and other
`devices. Reply 12–13. Thus, Petitioner argues that claim 4 explicitly
`defines the controller as a plurality of devices. Id. at 12 (citing Ex. 1001,
`17:39–55). Further, [t]he claims [] do not preclude the use of routers and
`switches as part of the ‘controller’ to connect to the site. Id. at 13.
`Therefore, the controller properly may include the gateway and node 111.
`Id. at 14. Node 111 contains an interface to Source 101, and therefore
`Petitioner argues that these disclosures would have taught the recited site
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
