`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-00977
`Patent 7,406,048 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-00977
`Patent 7,406,048 B2
`
`
`I. INTRODUCTION
`
`A. Background
`Talari Networks, Inc. (“Petitioner”) filed a Petition (Paper 1, “Pet.”)
`seeking to institute an inter partes review of claims 1–24 of U.S. Patent No.
`7,046,048 (Ex. 1003, “the ’048 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 1–24 on the
`following specific grounds:
`Reference(s)
`
`Basis
`
`Claims Instituted
`1, 3, 4, 6, 7, 9, 10, 12, 13, 15,
`16, 18, 19, 21, 22, and 24
`1–24
`1–5, 7–11, 13–17, and 19–23
`
`Karol1
`
`§ 102
`
`§ 103
`Karol
`Karol and Stallings2 § 103
`
`
`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 1–24 of the ’048 patent are
`unpatentable.
`
`
`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-00977
`Patent 7,406,048 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, 1–2. In addition, Petitioner has a pending petition for inter partes review
`of a related patent, U.S. Patent No. 6,775,235 B2 (“the ’235 patent”)
`(IPR2016-00976). Pet. 2. Viptela, Inc. and Cisco Systems, Inc. also have
`filed petitions seeking inter partes review of various claims of the ’048 and
`’235 patents. Paper 30, 3.
`
`C. The ʼ048 Patent
`The ’048 patent describes a system and method for communicating
`using two or more disparate networks in parallel. Ex. 1003, 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-00977
`Patent 7,406,048 B2
`
`Figure 10 depicts an example of the network topology described in the ’048
`patent. Id. at 8:22–23. Two sites 102 transmit and/or receive data from one
`another. Id. at 2:39–41. These sites are connected by two disparate
`networks, Internet 500 and frame relay network 106. Id. at 8:23–25. Each
`location has frame relay router 105 and Internet router 104. Id. at 8:25–26.
`“Access to the disparate networks at site A and site B is through an inventive
`controller 602 at each site.” Id. at 6:30–31. 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:6–9.
`
`Figure 7 of the ’048 patent is reproduced below.
`
`
`Figure 7 depicts controller 602. Id. at 10:48–49. Controller 602 is
`connected to site 102 via site interface 702. Id. at 10:48–51. Packet path
`selector 704 is hardware or software that determines which path a given
`packet is to travel. Id. at 10:54–58. The criteria used to determine which
`path a packet travels may be based on concerns such as redundancy,
`load-balancing, or security. Id. at 10:61–11:50. Controller 602 also has two
`
`4
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`or more network interfaces 706 (at least one per each network for which
`controller 602 controls access). Id. at 11:51–53.
`
`D. Illustrative Claims
`As noted above, we instituted review of claims 1–24 of the ʼ048
`patent, of which claims 1, 7, 13, and 19 are independent. Claims 1 and 7 are
`illustrative of the challenged claims and are reproduced below:
`1. A controller which controls access to multiple independent
`disparate networks in a parallel network configuration,
`the disparate networks comprising at least one private
`network and at least one network based on the Internet,
`the controller comprising:
`a site interface connecting the controller to a site;
`at least two network interfaces which send packets toward the
`disparate networks; and
`a packet path selector which selects between network
`interfaces, using at least two known location address
`ranges which are respectively associated with disparate
`networks, according to at least: a destination of the
`packet, an optional presence of alternate paths to that
`destination, and at least one specified criterion for
`selecting between alternate paths when such alternate
`paths are present;
`wherein the controller receives a packet through the site
`interface and sends the packet through the network
`interface that was selected by the packet path selector.
`
`
`7. A method for combining connections for access to disparate
`parallel networks, the method comprising the steps of:
`receiving at a controller a packet which has a first site IP
`address as source address and a second site IP address as
`destination address;
`selecting, within the controller on a per-packet basis, between a
`path through an Internet-based network and a path
`through a private network that is not Internet-based; and
`forwarding the packet along the selected path toward the second
`site.
`
`5
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`
`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
`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).
`
`“selecting . . . on a per-packet basis, between a path through an
`Internet-based network and a path through a private network that is not
`Internet-based” (Claim 7) / “selects . . . on a per-packet basis, between
`a path through an Internet-based network and a path through a private
`network that is not Internet-based” (claim 19)
`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 a path through an Internet-based network and a path
`through a private network that is not Internet based.” 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 path is
`chosen.” Reply 7.
`First, Patent Owner asks that we construe the selecting/selects terms
`of this phrase to mean making a discrete choice between two or more
`possibilities. PO Resp. 9–10. 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
`
`6
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`information to be gleaned by construing the words selecting/selects 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/selection.
`Patent Owner contends that the term “per-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. 3–4.
`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
`
`7
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`disparate networks.” Ex. 1003, 5:44–47. 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
`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:27–33.
`As described in the specification, Figure 9 depicts “methods” for
`selecting paths. See id. at 5:46. These methods allow for the selection to
`“be performed once per packet, or a given selection may pertain to multiple
`packets.” Id. at 14:32–33 (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 7 and 19 cover
`both of the embodiments or whether they are directed only to the
`embodiment wherein the selection occurs for each individual packet.
`Independent claim 7 recites, in relevant part, “selecting, within the controller
`on a per-packet basis.” Independent claim 19 recites, in relevant part, “a
`packet path selector which selects, within the controller on a per-packet
`basis.” The language of both claims is similar and may be contrasted with
`the language of the other independent claims. Claim 1 recites in relevant
`part, “a packet path selector which selects between network interfaces.”
`Similarly, claim 13 recites, in relevant part, “selecting between at least two
`network interfaces of the controller.” The path selection terms found in
`claims 1 and 13 do not include language tying the path selection to a packet.
`
`8
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`Claims 7 and 19, in contrast, expressly state that the selection occurs on a
`per-packet basis. We find that this language indicate a that the Patentee
`intended claims 7 and 19 to have a different scope than claims 1 and 13.
`In the “per-packet” claims, the specification and claim language lead
`us to conclude that the Patentee drafted its claim language in a manner so as
`to focus on the embodiment discussed in the ’048 patent wherein the
`selection occurs for each individual packet. The language of claims 1 and
`13 is broader and encompasses both selection for an individual packet and a
`selection performed for a group of packets. Such a drafting choice is within
`the purview of the Patentee, and we see no reason why we must construe
`claim 1 and 19 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 claims 7 and 19 to the embodiment in which
`routes are selected for each packet. As such, we find that the language of
`claims 7 and 19 indicates that these claims are directed to the embodiment
`wherein path selection is performed for each individual packet. Therefore,
`we construe “selecting/selects . . . on a per-packet basis” to mean “selecting
`a network path for each packet.”3
`
`
`3 Patent Owner’s proposed construction also included language specifying
`the networks (Internet-based and not Internet-based), however, there was no
`specific argument on this point. In addition, the claims already specify the
`networks from which the selection is to be made and thus, we see no reason
`to include this in the construction.
`
`9
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`
`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,
`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 1, 3, 4, 6, 7, 9, 10, 12, 13, 15, 16, 18, 19,
`21, 22, and 24 are anticipated by the disclosures of Karol. Pet. 10–30.
`Petitioner also argues that claims 1–24 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.
`
`10
`
`
`
`IPR2016-00977
`Patent 7,406,048 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.
`
`11
`
`
`
`IPR2016-00977
`Patent 7,406,048 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
`
`12
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`may adjust routing dynamically “to divert connections away from
`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 Claims 1 and 13
`Petitioner asserts that claims 1 and 13 are anticipated by (Pet. 10–18,
`27) or would have been obvious over Karol (id. at 42–48, 57–58). Based on
`our review of the full record, we determine that Petitioner has demonstrated
`by a preponderance of the evidence that claims 1 and 13 are anticipated by
`Karol and would have been obvious over Karol.
`Claim 1 recites “a controller which controls access to multiple. . .
`networks.” Independent claim 13 recites limitations similar to those of
`claim 1, and Petitioner cites similar disclosures from Karol in support of its
`contention that claim 13 is anticipated by Karol. Compare Pet. 10–18
`(assertions regarding claim 1), with Pet. 27 (assertions regarding claim 13).
`In addition, Patent Owner puts forth similar arguments with respect to
`Petitioner’s contentions regarding claims 1 and 13. For brevity, we shall
`discuss these claims together. Petitioner’s arguments as to independent
`claims 1 and 13 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 the site interface is a network connection. Id. at 12–13. As to the “at
`
`13
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`least two network interfaces,” Petitioner relies on Karol’s disclosure of 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 13–
`14. In regard 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. Id. at 14.
`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. at
`14–15. We find that this evidence, when considered in light of Patent
`Owner’s arguments and evidence, is sufficient to show the unpatentability of
`claims 1 and 13.
`Patent Owner argues that Petitioner has not shown that the recited
`“site interface” is disclosed by Karol. PO Resp. 26. 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 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. 12 (citing
`Ex. 1005 at ¶¶ 164–165, 167; Ex. 1006, 3:44–51, 4:36–44, 4:65–67, 6:44–50
`and Figs. 1 and 4). In the alternative, Petitioner asserts that the “controller”
`could be the gateway in combination with one or more routers and/or
`switches and then the “site” would be Karol’s source 101 or destination 151
`endpoints and the “site interface” would be the network connection. Id. at
`12–13.
`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. 26. According to
`
`14
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`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 28. Patent Owner
`acknowledges that Karol’s Figure 1 shows an interface between source 101
`and node 111. Id. at 30. 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 claims 1 and 13. Id. at 26–27.
`Petitioner points out that claim 1 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” permits the controller to include other elements and other
`devices beyond those specifically recited. Reply 11. Thus, Petitioner argues
`that claim 14 explicitly defines the controller as a plurality of devices. Id. at
`10–11. Further, “[t]he claims [] do not preclude the use of routers and
`switches as part of the ‘controller’ to connect to the site because there is no
`requirement of a ‘direct connection’ between the site and controller.” Id. at
`11. Therefore, the controller properly may include the gateway and node
`111. Id. Node 111 contains an interface to Source 101, and, therefore,
`Petitioner argues that these disclosures would have taught the recited site
`interface. Id. at 10.
`
`
`4 Claim 13 is a method claim that does not include the same comprising
`language, but we have not been directed to any evidence sufficient to show
`that the controller of claim 1 should be construed in a different manner from
`the controller of claim 13. See Wilson Sporting Goods Co. v. Hillerich &
`Bradsby Co., 442 F.3d 1322, 1328 (Fed. Cir. 2006) (construing the term gap
`to have the same meaning in two different claims).
`
`15
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`
`We find Petitioner’s arguments and evidence to be persuasive. We
`agree with Petitioner’s contention that the “comprising” language used in
`claim 1 is broad enough to encompass a controller that includes multiple
`devices. As such, we see no impediment to considering node 111 as part of
`the constellation of devices that is within the scope of the recited controller.
`We determine that the interface between node 111 and source 101 would
`have taught the recited site interface. As an additional finding, we note that
`Karol discloses a direct connection between the source or destination site
`and the gateway. Ex. 1006, 5:5–8. Thus, we find that Petitioner has put
`forth sufficient evidence to show the recited site interface is disclosed in
`Karol.
`Patent Owner also argues that Karol does not disclose “using at least
`two known location address ranges which are respectively associated with
`disparate networks.” PO Resp. 32–35. According to Patent Owner, “Karol
`does not explicitly or inherently disclose the use of address ranges in the
`flow database, only singular source and destination IP addresses.” Id. at 32.
`Patent Owner explains that in the ’048 patent
`an ‘address range’ is represented as an IP address with portions
`containing an “x,” which indicates that the full range of values
`possible for that address portion. The use of “.x.x” notation in
`the ’048 specification makes it clear that an address range is not
`a single address and is not a collection of disjoint addresses as
`in a routing table, but is instead a group of contiguous
`addresses.
`
`Id. at 34 (citing Ex. 1003, 8:37–59).
`We, however, are not convinced that the ’048 patent’s disclosure is so
`limited. The specification provides examples of address ranges, but it does
`not require a specific format. For example, “[a]ddress ranges may be
`
`16
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`specified as partial addresses, e.g., partial IP addresses in which some but
`not all of the address is specified. Thus, ‘198.x.x.x’ indicates an IP address
`in which the first field is 198 and the other three address fields are not
`pinned down, corresponding to the range of addresses from 198.0.0.0 to
`198.255.255.255.” Ex. 1003, 13:27–33 (emphasis added). This passage
`describes one way in which an address range may be represented. It,
`however, does not establish that a range must include more than one address.
`In addition, “a network may have more than one associated contiguous range
`of addresses which collectively constitute the address range for that
`network.” Id. at 13:34–36. Here, the specification provides an example of
`an address range composed of one or more ranges, but it does not require
`any particular number of addresses to be included in the range. We further
`note that the specification states that “in the claims a reference to an item
`normally means at least one such item is required.” Ex. 1003, 16:43–45
`(emphasis added). Thus, based on our review of the intrinsic record, we find
`that the claimed address range is broad enough to include a single address.
`Petitioner relies upon Karol’s discussion of “routing table
`information, which include[s] the location address ranges associated with the
`CL and CO network paths” to disclose this limitation. Ex. 1005 ¶ 180; Pet.
`14–15. Specifically, Petitioner directs us to Karol’s forwarding database
`432, which stores the address of the next hop router, destination address, and
`the outgoing port. Id. at 15–16 (citing Ex. 1006, 7:36–41; Ex. 1005 ¶ 94,
`178). In addition, Karol has a flow database 433, which stores similar
`information for use in the CO network. Id. at 16 (citing Ex. 1006, 7:42–54,
`Ex. 1005 ¶¶ 95, 179). Petitioner contends that the addresses stored in these
`databases are used to route flows to either the CO or CL network. Id. at 14–
`
`17
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`15 (citing Ex. 1006, 16:3–9; Ex. 1005 ¶¶ 104–108, 180). We find that
`Petitioner has shown sufficiently that Karol’s routing tables are used to
`obtain addresses that are associated with Karol’s CO and CL networks.
`Thus, we find that Petitioner has made a sufficient showing as to this
`limitation and we are not convinced by Patent Owner’s arguments.
`Based on our review of the full record, we find that Petitioner has
`demonstrated the unpatentability of claims 1 and 13 as anticipated by Karol.
`Thus, we determine that Petitioner has met its burden to demonstrate by a
`preponderance of the evidence that Karol anticipates claims 1 and 13.
`Petitioner, however, also argues that claims 1 and 13 would have been
`obvious over Karol. Petitioner relies upon the above described disclosure
`from Karol and 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 claims 1 and 13 obvious. Pet.
`42–48, 57–58.
`Petitioner argues that the recited address ranges would have been
`obvious over Karol and the knowledge of one of ordinary skill in the art.
`Pet. 42–48, 57–58. Petitioner contends that if this claim were construed to
`require the range to contain more than one address then it would have been
`obvious to modify Karol to use a range that includes more than a single
`address. Id. Petitioner asserts that this would have been obvious because
`such address ranges were known in the art and it “would have amounted to
`nothing more than the use of a known technique to improve similar methods
`in the same way or the combination of prior art elements according to known
`methods to yield predictable results.” Id. at 46.
`
`18
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`
`Patent Owner argues that such a modification would not have been
`obvious because the purpose of the flow database is to identify a specific
`flow between source and destination hosts. PO Resp. 35–38. Thus, a person
`of ordinary skill “would have understood that the flow database would not
`be able to determine how to handle packets from flows requiring a CO
`connection if the source and destination addresses were ranges.” Id. at 37.
`This proposed modification, therefore, would render Karol inoperable. Id. at
`38.
`
`We do not find Karol’s flow database to be so limited. As described
`in Karol, “[f]low database 433 stores information used to determine how to
`handle packets from flows requiring a connection-oriented service.” Ex.
`1006, 7:41–44. Karol describes “[t]ypical fields in each record in the
`database,” but we find that this description of an exemplary database schema
`does not limit Karol to a single way to describe or handle a flow. See id. at
`7:44–45. Petitioner provides evidence that one of ordinary skill in the art
`would have known how to use address ranges to identify a flow, see Ex.
`1005 ¶¶ 188–190, and thus, we determine that the proposed modification
`would not have rendered Karol inoperable. Thus, we are persuaded that
`Petitioner has shown by a preponderance of the evidence that claims 1 and
`13 would have been obvious over Karol.
`3. Independent Claims 7 and 19
`Claim 7 recites a method for combining connections for access to
`multiple parallel disparate networks. Independent claim 19 recites
`limitations similar to those of claim 7, and Petitioner cites similar
`disclosures from Karol in support of its contention that claim 19 is
`anticipated by Karol. Compare Pet. 22–26 (anticipation assertions regarding
`
`19
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`claim 7) with Pet. 28–29 (anticipation assertions regarding claim 19). In
`addition, Patent Owner puts forth similar arguments with respect to
`Petitioner’s contentions regarding claims 7 and 19. For brevity, we shall
`discuss these claims together.
`Petitioner’s allegations regarding independent claims 7 and 19 may be
`summarized as follows: Karol discloses combining multiple parallel
`disparate networks through its discussion of internetworking CL and CO
`networks. Pet. 11–12; see Ex. 1006, 1:7–10. Karol discloses a controller
`(CL-CO gateway alone or in combination with routers and/or switches) with
`an interface that connects the controller with source and destination
`endpoints. Pet. 22. Karol discloses IP addresses for the source and
`destination in its discussion of routing tables (datagram forwarding database
`432 in the CL network and flow database 433 in the CO network). Id. at 17–
`18; Ex. 1005 ¶ 308 (citing Ex. 1006, 7:42–54). According to Petitioner,
`Karol “selects the CL or CO network by comparing information such as the
`destination address for each datagram to information in routing tables.” Id.
`at 25 (citing Ex. 1005 ¶¶ 324–329).
`According to Patent Owner, Karol does not disclose the recited
`“selecting/selects, . . . within the controller on a per-packet basis.” PO Resp.
`21. 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
`claims 7 and 19. PO Resp. 21–25. 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)
`
`20
`
`
`
`IPR2016-00977
`Patent 7,406,048 B2
`
`Karol’s path selection occurs infrequently and not on a per-packet basis. Id.
`at 21.
`
`Petitioner contends that Karol “compares information in each packet
`received at the CL-CO gateway to determine if the packet will be routed to
`the CL network interface output line card or to the CO network interface
`output line card) on a ‘per-packet basis’ (e.g., each packet routing decision is
`unique to a part