Trials@uspto.gov
`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
`
`
`
`
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
