throbber
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-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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket