`571-272-7822
`
`
`Paper 8
`Entered: June 11, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`ARISTA NETWORKS, INC.,
`Petitioner,
`
`v.
`
`CISCO SYSTEMS, INC.,
`Patent Owner.
`
`
`
`Case IPR2016-00309
`Patent 7,224,668 B1
`
`
`
`Before BRYAN F. MOORE, MATTHEW R. CLEMENTS, and
`PETER P. CHEN, Administrative Patent Judges.
`
`CLEMENTS, Administrative Patent Judge.
`
`DECISION
`Instituting Inter Partes Review and
`Granting Motion for Change of Filing Date
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`INTRODUCTION
`I.
`Arista Networks, Inc. (“Petitioner”) filed a Petition requesting inter
`partes review of claims 1–10, 12, 13, 15–28, 30, 31, 33–43, 48, 49, 51–64,
`66, 67, and 69–72 (“the challenged claims”) of U.S. Patent No. 7,224,668
`B1 (Ex. 1001, “the ’668 patent”). Paper 1 (“Pet.”). Cisco Systems, Inc.
`(“Patent Owner”) filed a Preliminary Response. Paper 7 (“Prelim. Resp.”).
`We have jurisdiction under 35 U.S.C. § 314(a), which provides that an
`inter partes review may not be instituted unless the information presented in
`the Petition shows “there is a reasonable likelihood that the petitioner would
`prevail with respect to at least 1 of the claims challenged in the petition.”
`Upon consideration of the Petition and Preliminary Response, we are
`persuaded that Petitioner has met its burden of showing a reasonable
`likelihood that it would prevail in showing that claims 1–10, 12, 13, 15–28,
`30, 31, 33–43, 48, 49, 51–64, 66, 67, and 69–72 are unpatentable.
`
`A. Related Proceedings
`The ’668 patent is involved in Cisco Systems, Inc. v. Arista Networks,
`Inc., Case No. 4:14-cv-05343 (N.D. Cal.) and Cisco Systems, Inc. v. Arista
`Networks, Inc., Network Devices, Related Software and Components Thereof
`(II), ITC Inv. No. 337-TA-945. Pet. 1; Paper 6, 1. Petitioner also has filed
`IPR2015-00974 (“the ’974 IPR”) and IPR2015-01710 (“the ’1710 IPR”).
`Paper 6, 1. Petitioner also has filed over a dozen other petitions requesting
`inter partes review of other patents owned by Patent Owner: IPR2015-
`00973 (U.S. Patent No. 6,377,577), IPR2015-00975 (U.S. Patent No.
`8,051,211), IPR2015-00976 (U.S. Patent No. 7,023,853), IPR2015-00978
`(U.S. Patent No. 7,340,597), IPR2015-01049 (U.S. Patent No. 6,377,577),
`IPR2015-01050 (U.S. Patent No. 7,023,853), IPR2016-00018 (U.S. Patent
`
`2
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`No. 8,051,211), IPR2016-00119 (U.S. Patent No. 7,047,526), IPR2016-
`00244 (U.S. Patent No. 7,953,886), IPR2016-00303 (U.S. Patent No.
`6,377,577), IPR2016-00304 (U.S. Patent No. 7,023,853), IPR2016-00306
`(U.S. Patent No. 7,023,853), and IPR2016-00308 (U.S. Patent No.
`7,162,537).
`
`B. The ’668 patent
`The ’668 patent relates generally to an internetworking device, such
`as a router, with improved immunity to Denial of Service (“DoS”) attacks.
`Ex. 1001, Abstract. At the time, a router typically separated its functionality
`into a data plane, responsible for accepting transit packets at input ports and
`routing or switching them to output ports, and a control plane, responsible
`for higher layer functions, such as establishing routing tables. Id. at 1:52–
`59. Denial of Service attacks were commonly directed at the control plane.
`Id. at 1:59–67. Attempts to solve such problems were difficult to administer
`and could result in poor performance when control-plane policies were
`applied not only to control plane packets, but also to transit packets. Id. at
`2:24–3:2.
`To address these and other issues, the ’668 patent discloses an
`internetworking device whose control plane processes are collectively
`arranged as a single addressable port such that all packets intended for the
`control plane always pass through this designated port, which thereby
`provides the ability to better manage control plane traffic. Id. at 3:42–50. A
`set of port services unique to the control plane may be applied to the
`aggregate control plane port. Id. at 3:54–56.
`
`3
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`Figure 1 is reproduced below.
`
`
`
`Figure 1 is a block diagram of internetworking device 100, such as a router,
`comprising control plane port 140, which defines a single access path
`between switch engine 130 and control plane 150. Id. at 4:47–67. Line
`cards 110 and central switch engine 130 accept packets received on a given
`port 120 and route them through to another output port 120. Id. at 5:5–7.
`Because all packets destined to control plane 150 pass through central switch
`engine 130 prior to being routed to functions 155, central switch engine 130
`can be used to implement aggregate control plane protection. Id. at 5:36–42.
`Control plane port services determine if a given packet is destined to a
`control plane process 150. Id. at 5:56–58. Control plane port 140 may be a
`single physical port or may be a virtual address, but either way, it can be
`
`4
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`treated as a traditional hardware port to which a full range of traditional port
`control features—e.g., rate limiting, access lists, hierarchical queues based
`on priority—can be applied to help protect control plane 150 from a DoS
`attack, or to provide other QoS (quality of service). Id. at 5:1–4, 5:66–6:44.
`
`C. Illustrative Claim
`Of the challenged claims, claims 1, 19, 37, and 55 are independent.
`Claim 1 is reproduced below:
`1.
`An internetworking device comprising:
`a.
`a plurality of physical network interface ports,
`each for providing a physical connection point to a network for
`the internetworking device, the ports being configurable by
`control plane processes;
`b.
`port services, for operating on packets entering and
`exiting the physical network interface ports, the port services
`providing an ability to control and monitor packet flows, as
`defined by control plane configurations;
`c.
`a control plane, comprising a plurality of
`internetworking control plane processes, the control plane
`processes for providing high-level control and configuration of
`the ports and the port services;
`d. wherein:
`i.
`a control plane port entity provides access to
`the collection of control plane processes, so that a set of
`control plane port services can be applied thereto; and
`ii.
`the control plane port services operate on
`packets received from specific, predetermined physical
`ports and destined to the collection of control plane
`processes in a way that is independent of the physical
`port interfaces and services applied thereto.
`Ex. 1001, 9:17–40.
`
`5
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`D. Evidence Relied Upon
`Petitioner relies upon the following references:
`Amara
`US 6,674,743 B1
`Jan. 6, 2004
`Moberg
`US 6,460,146 B1
`Oct. 1, 2002
`Subramanian
`US 6,970,943 B1
`Nov. 29, 2005
`Hendel
`US 6,115,378
`Sept. 5, 2000
`3Com, COREBUILDER 3500 IMPLEMENTATION GUIDE, 3Com
`MSD Technical Publications, November 1999 (“CoreBuilder”)
`
`Ex. 1004
`Ex. 1005
`Ex. 1006
`Ex. 1007
`Ex. 1009
`
`Pet. 2–3. Petitioner also relies upon the Declaration of Dr. Bill Lin (“Lin
`Decl.”) (Ex. 1002).
`
`E. The Asserted Grounds of Unpatentability
`Petitioner argues that the challenged claims are unpatentable based on
`the following grounds (Pet. 2–3):
`References
`Amara & CoreBuilder
`
`Basis Claims challenged
`§ 103 1–6, 8, 9, 15–22, 24–27,
`33–40, 42, 51–58, 60–63,
`and 69–72
`Amara, CoreBuilder, & Moberg § 103 7, 23, 41, and 59
`Amara, CoreBuilder, &
`§ 103 10, 12, 13, 28, 30, 31,
`Subramanian
`43,48, 49, 64, 66, and 67
`Amara, CoreBuilder, & Hendel § 103
`
`II. ANALYSIS
`A. 35 U.S.C. § 325(d)
`Patent Owner argues that this Petition should be denied under
`§ 325(d) because this is Petitioner’s third Petition directed to the ’668 patent.
`Prelim. Resp. 2–13. In the ’974 IPR, we denied institution because
`Petitioner did not show sufficiently that Amara anticipates the independent
`claims. In the ’1710 IPR, we exercised our discretion under § 325(d)
`
`6
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`because we determined “that [the ’1710 Petition] presents the same
`argument[s] as to the disclosure of ‘a plurality of physical network interface
`ports . . . the ports being configurable by control plane processes.’” Arista
`Networks, Inc. v. Cisco Systems, Inc., ’1710 IPR, Paper 7, slip op. at 12
`(PTAB Feb. 16, 2016) (“’1710 DI”). Here, in contrast, we are not persuaded
`that Petitioner’s arguments based on the combination of Amara and
`CoreBuilder are the same or substantially the same as those previously
`presented because we have not previously addressed substantively a
`challenge to the independent claims based on obviousness over Amara. In
`the ’974 IPR, we addressed substantively only a challenge to the
`independent claims based on anticipation by Amara. ’974 DI 7–14.
`Although Petitioner also challenged the independent claims based on a
`combination of Amara and Habraken, we did not address that ground
`substantively because we found it insufficiently articulated. ’974 DI 15–17.
`In the 1710 IPR, the asserted obviousness combination was based on Frazier
`and Habraken, not based on Amara. Not being persuaded that the same or
`substantially the same prior art or arguments were previously presented to
`the Office, we decline to exercise our discretion under 35 U.S.C. § 325(d).
`
`B. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are
`interpreted according to their “broadest reasonable construction in light of
`the specification of the patent” in which they appear. 37 C.F.R. § 42.100(b);
`see also In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1278–79 (Fed. Cir.
`2015), cert. granted sub nom. Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct.
`890 (2016) (mem.). Applying that standard, we interpret the claim terms
`according to their ordinary and customary meaning in the context of the
`
`7
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`patent’s written description. In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007). Petitioner proposes constructions for “specific,
`predetermined ports,” and nine means-plus-function terms. Pet. 6–12.
`Patent Owner disputes some of those constructions. Prelim. Resp. 20–24.
`For purposes of this Decision, we determine that only the following
`require express construction.
`1. “specific, predetermined ports” (claims 1, 19, 37, and 55)
`Petitioner contends that this term should be construed broadly enough
`to encompass all ports of the internetworking device, and should not be
`limited to a subset of the ports. Pet. 6–7. According to Petitioner, claim 8,
`which depends from claim 1, specifies that the “control plane port services”
`recited in claim 1 “are implemented as an aggregate control plane function”
`in which control plane port services are applied to all ports of the device. Id.
`at 7. Patent Owner contends that this term is unambiguous, requires no
`construction, and, in any event, is not outcome determinative. Prelim. Resp.
`20.
`
`Based on our review of the Specification, we agree with Petitioner
`that the control plane port services are described as operating on packets
`received on any of the physical ports of the internetworking device, not only
`on those received on particular physical ports. On this record, we are
`persuaded that the broadest reasonable interpretation of “specific,
`predetermined ports” encompasses all ports of the networking device, and is
`not limited to a subset of the ports.
`
`8
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`2. “means for configuring a plurality of physical network interface
`ports” (claim 37)
`Petitioner asserts that this is a means-plus-function limitation that
`should be construed in accordance with § 112 ¶ 6. Pet. 8. Petitioner
`contends that the term is indefinite because the only disclosed means are
`software-implemented “control plane processes,” and the ’668 patent does
`not disclose an algorithm for performing the claimed function. Id. at 8.
`Petitioner contends, in the alternative, that the structure for performing the
`recited function is the set of control plane processes described at column 5,
`lines 18–23. Id.
`Patent Owner argues that the control plane processes are not the only
`structure disclosed in the ’668 patent for performing the recited function.
`Prelim. Resp. 22. Patent Owner identifies instead “structures such as
`internetworking device 100 and/or processor 125.” Patent Owner further
`contends that, even if the structure is software-implemented, the ’668 patent
`discloses an algorithm for performing the recited function, such as by
`changing the state of one of port interfaces 120 in line card 110 to effect a
`route change. Id. at 22–23 (citing Ex. 1001, 5:19–21).
`Based on our review of the record, the ’668 patent discloses only
`control plane 150, comprised of control plane processes 155, as performing
`the claimed function. See, e.g., Ex. 1001, 5:11–23 (“The control plane 150
`is responsible for processing routing, signaling, and control protocols that
`dictate the packet forwarding behavior of the data plane 135. . . . The
`control plane 150 is typically not a single process or processor but rather a
`collection of processes.”). The ’668 patent further describes a software
`implementation of control plane 150 processes. Id. at 4:58–62 (“A control
`
`9
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`plane 150 associated with the device 100 is defined as a collection of
`processes, typically running on the route processor 125. These control plane
`150 processes collectively provide high level control for most router/switch
`Input/Output Services (IOS) functions.”). Although the ’668 patent also
`states that control plane processes 150 may be implemented in hardware (id.
`at 4:62–64 (“These control plane 150 processes could be implemented as
`software at any level of a system, or as hardware.”), the ’668 patent does not
`disclose any hardware that performs the functions of control plane 150
`processes.
`As the Federal Circuit has stated:
`In cases such as this, involving a claim limitation that is
`subject to § 112, para. 6 that must be implemented in a
`special purpose computer,
`this court has consistently
`required that the structure disclosed in the specification be
`more
`than
`simply a general purpose computer or
`microprocessor. E.g., Aristocrat Techs. Austl. Pty Ltd. v. Int’l
`Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008) (citing
`WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339
`(Fed. Cir. 1999)). We require that the specification disclose
`the claimed function. Net
`an algorithm for performing
`MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1367 (Fed. Cir.
`2008). The algorithm may be expressed as a mathematical
`formula, in prose, or as a flow chart, or in any other manner
`that provides sufficient structure. Noah, 675 F.3d at 1312
`(citing Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323,
`1340 (Fed. Cir. 2008)).
`Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1352 (Fed. Cir. 2015).
`Patent Owner points to disclosure in the ’668 patent to “change the state of
`one of the port interfaces 120 in a line card 110 to effect a route change.”
`Prelim. Resp. 22–23 (quoting Ex. 1001, 5:19–21). This disclosure, however,
`is merely a function of control plane 150 processes. The ’668 patent does
`
`10
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`not set forth an algorithm for performing the claimed functions—e.g., how to
`change the state of one of the port interfaces 120 in a line card 110 to effect
`a route change. Even if Patent Owner were permitted expert testimony on
`this issue, “[t]he testimony of one of ordinary skill in the art cannot supplant
`the total absence of structure from the specification.” Williamson, 792 F.3d
`at 1354.
`As a result, we do not find sufficient disclosure of an algorithm that,
`in combination with the route processor 125, constitutes a structure for the
`claimed “means for configuring.”
`
`C. Claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42,
`51–58, 60–63, and 69–72 –Obviousness Over Amara and CoreBuilder
`Petitioner argues that claims 1–6, 8, 9, 15–22, 24–27, 33–40, 42,
`51–58, 60–63, and 69–72 are unpatentable under 35 U.S.C. § 103 as obvious
`over the combination of Amara and CoreBuilder. Pet. 12–40.
`Amara (Exhibit 1004)
`Amara, titled, “Method and Apparatus for Providing Policy-based
`Services for Internal Applications,” describes a packet-forwarding device that
`provides policy-based services for internal applications. Ex. 1004, Title,
`Abstract.
`
`11
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`Figure 3 is reproduced below.
`
`
`Figure 3, above, is a block diagram of packet forwarding device 200.
`Device 200 includes interfaces 202–206 that are able to transmit packets to
`and to receive packets from nodes 208–212, respectively. Id. at 5:51–55.
`Packet classifiers 214–218 classify the packets received by nodes interfaces
`202–206, respectively, as either internally-destined packets or external
`packets, based on the packets’ destination addresses. Id. at 5:55–58. Packet
`classifiers 214–218 forward the internally-destined packets to internal
`interface 220, and packet classifiers 214–218 forward the external packets to
`packet forwarder 222 via policy engines 224–228, respectively. Id. at 5:58–
`62. Internal interface 220 forwards the internally-destined packets from
`packet classifiers 214–218 to internal applications 230 and forwards the
`internally-generated packets from internal applications 230 to packet
`forwarder 222. Id. at 5:63–6:2. Packet forwarder 222 forwards the external
`packets from packet classifiers 214–218 and the internally-generated packets
`from internal interface 220 to one or more of interfaces 202–206, via policy
`engines 224–228, based on the destination addresses of the packets. Id. at
`6:3–8.
`
`12
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`Device 200 applies policies to the internal packets and to the external
`packets. Specifically, policy engine 232 applies a policy to the internally-
`destined packets used by internal applications 230 and to the internally-
`generated packets generated by internal applications 230. Id. at 6:9–12.
`Policy engines 224–228 apply policies to the external packets forwarded by
`packet classifiers 214–218, respectively, and typically also apply policies to
`the external packets forwarded by packet forwarder 222. Id. at 12–16. The
`policies applied to internal packets may differ from those applied to external
`packets. Id. at 6:17–19.
`CoreBuilder (Ex. 1009)
`CoreBuilder describes features of the 3Com CoreBuilder 3500 Layer
`3 High-Function Switch. Ex. 1009, 21, 27. CoreBuilder “is intended for the
`system or network administrator who is responsible for configuring, using,
`and managing the CoreBuilder 3500 system.” Id. at 21. CoreBuilder
`teaches multiple management interfaces, including an Administration
`Console and Web Management software. Id. at 29. The Administration
`Console “is a menu-driven command line interface that is embedded in the
`system software.” Id. at 28. Web Management software is a suite of
`HTML-based applications that are embedded in the software and which can
`be accessed from a web browser. Id. at 29. The management interfaces may
`be used to configure, e.g., port state, port mode, autonegotiation, VLANs,
`routing interfaces, packet filters, and quality of service (QoS). Id. at 29–30.
`Packet filters allow a router “to make a permit-or-deny decision for each
`packet based on the packet contents.” Id. at 210. A filter may be applied to
`the receive path, to the transmit path, or to the receive internal path. Id. at
`211–212. The administrator “can control and manage packet filters from the
`
`13
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`bridge packetFilter menu of the Administration Console.” Id. at 215. The
`administrator can create standard or custom packet filters, delete packet
`filters, edit, save, and load custom filters, and assign filters to one or more
`ports and processing path. Id. at 215–216.
`Analysis
`1. Claims 1–6, 8, 9, 15–22, 24–27, 33–36,
`55–58, 60–63, and 69–72
`Petitioner asserts that a combination of Amara and CoreBuilder
`renders obvious claims 1–6, 8, 9, 15–22, 24–27, 33–36, 55–58, 60–63, and
`69–72. Pet. 12–40. For example, independent claim 1 recites “a plurality of
`physical network interface ports . . . the ports being configurable by control
`plane processes.” Petitioner relies upon Amara’s internal applications 230
`as teaching the recited “control plane processes,” and relies upon
`CoreBuilder’s explicit teaching of such internal applications, such as the
`Administration Console, configuring the plurality of physical network
`interface ports. Id. at 25. Independent claim 1 also recites “port services”
`that “operat[e] on packets entering and exiting the physical network
`interface ports, the port services providing an ability to control and monitor
`packet flows.” Petitioner relies upon Amara’s teaching of policy engines
`224–28 that execute and apply policies—e.g., dropping, logging,
`encrypting/decrypting, network address translation, and prioritization—to
`external packets passing through device 200. Id. at 26–27. Independent
`claim 1 also requires that the recited “port services” are “defined by control
`plane configurations.”
`Petitioner relies upon Amara’s internal applications 230 and upon
`CoreBuilder’s teaching of an Administration Console, or other management
`
`14
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`interface, for defining various port services. Id. at 27. Independent claim 1
`also recites that “the control plane port services operate on packets received
`from specific, predetermined physical ports and destined to the collection of
`control plane processes.” Petitioner relies upon Amara’s internal interface
`220 as the recited “control plane port entity” and upon Amara’s policy
`engine 232 for applying the recited “control plane port services” to internal
`interface 220. Id. at 29–31. Petitioner sets forth reasons to combine Amara
`and CoreBuilder on pages 18–23 of the Petition. Petitioner performs a
`similar analysis for claims 2–6, 8, 9, 15–22, 24–27, 33–36, 55–58, 60–63,
`and 69–72. Pet. 31–50.
`Patent Owner argues that Petitioner fails to establish that policy
`engines 224–28 apply port services that are “defined by control plane
`configurations,” as recited in claim 1. Prelim. Resp. 28–30. On this point,
`we credit the testimony of Dr. Lin, who testifies that “a [person of ordinary
`skill in the art] would consider [CoreBuilder’s Administration Console] to
`be equivalent to one of [Amara’s] internal applications 230.” Ex. 1002 ¶ 60.
`As a result, we are persuaded by Petitioner’s contention that it would have
`been obvious to a person of ordinary skill in the art that Amara’s internal
`applications 230 would provide the functionality of CoreBuilder’s
`Administration Console, including the ability to define port services.
`Patent Owner further contends that this combination fails for at least
`the same reasons as the combination of Amara and Habraken, which was
`asserted in the ’974 IPR. Prelim. Resp. 30. When we denied institution of
`the ground based on Amara and Habraken in the ’974 IPR, however, we did
`so because the ground was not sufficiently articulated in the ’974 Petition;
`not because of a failure of the two references to teach an element in the
`
`15
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`claim. Arista Networks, Inc. v. Cisco Systems, Inc., ’974 IPR, Paper 7, slip
`op. at 15–17 (PTAB Oct. 6, 2015) (“’974 DI”). In the ’974 IPR, the ground
`based on Amara and Habraken was among four obviousness grounds
`ostensibly articulated in just the final two pages of the Petition. Id. at 15.
`Here, in contrast, Petitioner articulates the combination of Amara’s
`teachings and CoreBuilder’s teachings on which it relies over eighteen
`pages.
`Patent Owner also argues that Amara’s policy engines 224–28 are not
`“port services” because they do not provide “an ability to control and
`monitor packet flows.” Prelim. Resp. 31–33. Specifically, Patent Owner
`argues that policy engines 224–28 operate only on “external” packets—i.e.,
`those not destined for internal applications—and therefore cannot control or
`monitor packet flows on physical ports because it is unaware of the
`“internal” packets that enter and exit a port. Id. This argument is not
`commensurate with the claim language, which requires that the port services
`operate only on “packets entering and exiting the physical network interface
`ports” (Ex. 1001, 9:22–23), not on every packet entering and exiting the
`physical network port. Moreover, Amara describes internally-generated
`packets from internal applications 230 as being sent to packet forwarder 222,
`which forwards “the internally-generated packets from internal interface 220
`to one or more of interfaces 202–206, via policy engines 224–228.” Ex.
`1004, 5:65–6:8. Thus, even if the claim language required operating on
`every packet exiting a port, Amara’s policy engines 224–228 do so. Finally,
`we are not persuaded that “an ability to control and monitor packet flows,”
`as recited in claim 1, requires that the port services operate on every packet
`that enters or exits a physical network port. The ability to drop, prioritize, or
`
`16
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`filter external packets is sufficient to teach “an ability to control and monitor
`packet flows.”
`Finally, Patent Owner argues that Petitioner fails to establish that
`Amara’s policy engine 232 applies control plane port services that “operate
`on packets received from specific, predetermined physical ports,” as recited
`in claim 1. Prelim. Resp. 34–35. Specifically, Patent Owner argues that
`“the mere existence of ports generally ‘before the policies are applied’ as
`Petitioner alleges, without anything else, does not mean that those policies
`are applied to ‘packets received from specific, predetermined ports’ as the
`claims require.” Id. at 34. Patent Owner does not, however, explain why
`ports 202, 204, and 206 of Amara’s device 200 are not “specific,
`predetermined ports.” Patent Owner did not propose a construction of this
`term, and as discussed in the claim construction section, supra, we agree
`with Petitioner that the broadest reasonable interpretation of this term
`encompasses all ports of the claimed internetworking device. Because the
`“internal” packets to which Amara’s policy engine 232 applies control plane
`port services are received from any of Amara’s ports 202, 204, and 206, we
`are persuaded by Petitioner’s contentions that those “control plane services
`operate on packets received from specific, predetermined physical ports,” as
`required by claim 1.
`2. Claims 37–40, 42, and 51–54
`As indicated in the claim interpretation section, supra, we are unable
`to arrive at an interpretation of the requirements of claim 37 due to the lack
`of disclosed structure corresponding to the recited “means for configuring.”
`A lack of sufficient disclosure of structure under 35 U.S.C. § 112 ¶ 6 renders
`a claim indefinite, and thus not amenable to construction. See In re Aoyama,
`
`17
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`656 F.3d 1293, 1298 (Fed Cir. 2011) (“If a claim is indefinite, the claim, by
`definition, cannot be construed.” (quoting Enzo Biochem, Inc. v. Applera
`Corp., 599 F.3d 1325, 1332 (Fed. Cir. 2010))); see also Blackberry Corp. v.
`MobileMedia Ideas, LLC, IPR2013-00036, Paper No. 65, slip op. at 12–20
`(PTAB Mar. 7, 2014) (terminating inter partes review proceeding because
`specification did not disclose specific algorithm to perform recited function
`of a computer-implemented means plus-function term). Because we cannot
`construe the means-plus-function limitation recited in independent claim 37,
`we cannot determine whether the teachings of Amara and CoreBuilder teach
`that limitation. Accordingly, Petitioner has not demonstrated a reasonable
`likelihood that it would prevail with respect to independent claim 37, or
`claims 38–40, 42, and 51–54, which depend therefrom.
`Conclusion
`On this record, we are persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 1–6, 8, 9,
`15–22, 24–27, 33–36, 55–58, 60–63, and 69–72 are unpatentable as obvious
`over the combination of Amara and CoreBuilder, but we are not persuaded
`that Petitioner has established a reasonable likelihood that it would prevail
`with respect to independent claim 37, and claims 38–40, 42, and 51–54,
`which depend therefrom.
`
`D. Claims 7, 23, 41, and 59 –
`Obviousness over Amara, CoreBuilder, and Moberg
`Petitioner argues that dependent claims 7, 23, 41, and 59 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over the combination of
`Amara, CoreBuilder, and Moberg. Pet. 40–42. The claims require the
`control plane processes to be distributed across multiple processors.
`
`18
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`Petitioner relies upon Moberg’s teaching of primary and secondary CPUs.
`Id. at 42. Specifically, Petitioner cites Moberg’s teaching that “it would be
`desirable for . . . the secondary processor [to be] able to off load work from
`the primary processor, thus making use of both processors simultaneously”
`(Ex. 1005, 2:26–30) and, in reference to step 608 of Figure 8, that “anything
`that was off-loaded from the primary processor to the secondary processor is
`run by the secondary processor” (id. at 8:25–28). Petitioner sets forth
`reasons to combine Amara, CoreBuilder, and Moberg on pages 41–42 of the
`Petition.
`Patent Owner argues that Moberg “fails to disclose distributing
`control plane processes across multiple processors” because it identifies
`“routing table computations” and “network management” router tasks in
`relation to only the primary CPU. Prelim. Resp. 38. On this record, we are
`not persuaded by Patent Owner’s argument because Moberg discloses that
`“any processing” may be offloaded to the primary processor (Ex. 1005,
`8:10–14) and nothing elsewhere in Moberg suggests that particular types of
`processes may not be offloaded to the secondary CPU.
`On this record, we are persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 7, 23, and
`59 are unpatentable as obvious over the combination of Amara, CoreBuilder,
`and Moberg. We are not persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claim 41 is
`unpatentable for the same reasons discussed above with respect to
`independent claim 37, from which it depends.
`
`19
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`E. Claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66, and 67 –
`Obviousness over Amara, CoreBuilder, and Hendel
`Petitioner argues that claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66,
`and 67 are unpatentable under 35 U.S.C. § 103(a) obvious over the
`combination of Amara, CoreBuilder, and Hendel. Pet. 52–60. Petitioner
`sets forth reasons to combine Amara, CoreBuilder, and Hendel on pages 54–
`57 of the Petition.
`Patent Owner argues that this ground is redundant to ground 3
`(asserted obviousness over Amara, CoreBuilder and Subrumanian). Prelim.
`Resp. 40–41. We are not, however, instituting ground 3, see infra. Patent
`Owner also argues that Hendel does not overcome the alleged deficiency of
`Amara and CoreBuilder with respect to “control plane port services
`operat[ing] on packets received from specific, predetermined physical
`ports.” Id. at 41–42. As discussed above, however, we are persuaded by
`Petitioner’s contentions that the combination of Amara and CoreBuilder
`teaches this limitation.
`On this record, we are persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 10, 12, 13,
`28, 30, 31, 64, 66, and 67 are unpatentable as obvious over the combination
`of Amara, CoreBuilder, and Hendel. We are not persuaded that Petitioner
`has established a reasonable likelihood that it would prevail in showing that
`claims 43, 48, and 49 are unpatentable for the same reasons discussed above
`with respect to independent claim 37, from which they depend.
`
`20
`
`
`
`IPR2016-00309
`Patent 7,224,668 B1
`
`
`F. Claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66, and 67 –
`Obviousness over Amara, CoreBuilder, and Subramanian
`Petitioner argues that claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66,
`and 67 are unpatentable under 35 U.S.C. § 103(a) obvious over the
`combination o